Good Chains Are Built on Strong Foundations

One of the major decisions we had to make for Topl was whether to build on an existing blockchain or develop our own. Here I’ll attempt to explain our thought process on the matter.


It’s not unusual, given the exuberance in the blockchain space, to ignore or marginalize the question of whether a blockchain solution is beneficial or even necessary for a given problem. Often, it’s assumed that since blockchains provide some interesting properties (e.g. redundancy, easily bootstrapped applications) they’re the best solution. In reality, problems that benefit from blockchain solutions tend to have a few specific features:

  • Parties naturally lacking trust with opposed economic incentives
  • Reliance on integrity of past data for guidance of future action
  • Allocation and manipulation of shared (and scarce) resources

Solutions to these sorts of problems tend to rely heavily on tight incentives, hashed data structures, and decentralized consensus. It’s important to realize that an offering that provides implementations for each of these doesn’t necessarily apply equally well to all such problems. Incentives built for one system use-case will not sufficiently equilibrate another. A consensus algorithm may produce inappropriate load, finality time, or decentralization factor for one application but be perfectly suitable for another.

Specialized problems require specialized solutions. For decentralized applications, that often means specialized chains.


Topl’s goal is to connect investors and producers across the world to form project-based joint ventures. In this process, investors require privacy in their actions, yet producers need the ability to share past investment information. In addition, the network relies on consensus over not only digital information but also the storage of real goods.

Both of these require implementation of a sophisticated scheme that prevents undue investor exposure, defines access roles over shared information, and avoids potential information leakage of transactions. These transactions rely on reputation of parties and ultimately require physical audits as anchors. For these reasons, the consensus has to be built around “real stake” (a combination of reputation and stake) and potentially fuzzy asset tracking — something which can’t be earnestly tackled given current development of general-purpose chains. Even Ethereum, which is working to include zk-SNARKs in its Metropolis release will be unprepared to seriously handle private transactions — such as those produced in ZCash — for some time.

That’s not to say that there aren’t potentially significant benefits to being part of these chains. Look at Ethereum:

Benefits:
 — Existing clients with JSON-RPC integration
 — High-quality development team and set standards (ERC20/223)
 — Relatively high number of users
 — Fairly simple development process for smart contracts

Downsides:
 — Consensus is limited to Ethereum
 — Pay to deploy contracts and contract upgrades
 — Double-cost barrier for token monetization
 — Smart contract development is limited in terms of complexity (largely due to EVM)
 — Smart contract languages (Solidity, Serpent, LLL) still very immature
 — Gas price stickyness compared to exchange rate

It’s obvious that one of the largest obstacles for any platform, user acquisition, has been addressed with great success in Ethereum. Ethereum has thrived at building to assist new applications in growth and attracting users. However, significant obstacles overshadow these benefits. Consider that Augur, Gnosis, and Aragon — along with many other projects of significant scope — use dozens of smart contracts and hundreds or thousands of lines of code. The costs and logistical challenges of these deployments are certainly not insignificant.

A general-purpose compute blockchain like Ethereum can work very well for small applications now and in the longer term for consumer-focused, app-like contracts. Nevertheless, unless Ethereum becomes a “master chain”, it’s difficult to imagine the future of blockchains as anything other than an internet of blockchains instead of a single app store and platform.

In the grand scheme of things, what Topl aims to provide is arguably far more specialized than what can currently or should ever be represented on an app-oriented chain. As a result, we’ve decided that the best course forward, both from a technical and logistical standpoint, is to build our own client on a tested foundation: the Scorex blockchain framework.

However, in terms of liquidity, crypto-assets can still benefit from the nascent standards spearheaded by Ethereum. Given that many crypto-exchanges (e.g. Poloniex) have already begun accepting ERC20/223 tokens, this presents an opportunity for new crypto-assets to gain access to a more developed market. Other decentralized platforms with specific needs have already chosen this route (e.g. Golem, Mysterium).

Liquidity benefits can also be realized to some extent in other chains as well, such as Stellar and Ripple. These can help extend these markets to those in the developing world — and specifically the unbanked.

Consequently, we intend to develop functionality to port assets to other blockchains. Early on, users ought to be able to submit these asset transfer transactions to, for example, a contract on Ethereum (think Project Alchemy). The corresponding tokens should be subject to the ERC20/223 standard and be able to be re-imported from the contract back onto the Topl chain. In this way, we hope to improve access to Topl chain assets while avoiding any technical compromise. In the longer term, we hope to make use of tighter interoperability, such as the solutions proposed by Cosmos (formerly Gnuclear) and Polkadot.

And perhaps most importantly, this hybrid approach will allow us to better offer our users the opportunity to participate in collaborative, pooled ventures in areas across the globe. The end result? Investments which benefit communities along with the enterprises that are built in them — all on blockchains.


I appreciate you taking the time to understand more about our development. We’ll also be adding another post in the near future providing greater detail on how we are using the Scorex 2 framework. Thanks!