This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at Polkadot and the challenge it poses to today’s dominant platform, Ethereum.

Polkadot, by itself, is not a smart contract platform; it is a network that connects heterogeneous blockchains. However, Polkadot’s flexible and adaptive architecture facilitates building technology, including smart contract platforms, that can pose a credible threat to Ethereum’s dominance. That technology will be covered in this article as we compare Polkadot’s first smart contract platform implementation to Ethereum’s. In the near future Polkadot will likely support and interconnect a variety of different smart contract platforms, so this analysis presents just an early glimpse of what is to come. Tracking the evolution of the Polkadot species will be an ongoing task.

As a fully extensible and scalable blockchain testbed that can host and connect a wide range of upgradable smart contract platforms, Polkadot could significantly accelerate the pace of innovation in smart contracts, dApps, consensus, governance, and other decentralized Web technologies. Polkadot’s parallel chain design will deliver, at launch, a base layer transaction capacity and security properties similar to what is expected of Ethereum’s Serenity years from now. By providing a scalable and secure platform that facilitates experimentation, unencumbered by the need to coordinate hard forks, Polkadot could attract Ethereum projects and users and disrupt its network effects. As of January 5, 2019 at least 27 projects, including 0x and Aragon, have announced their intent to build on Polkadot.

Many Polkadot projects will be built on the powerful, open source Substrate framework, which greatly simplifies the process of creating, deploying, upgrading, and experimenting with different types of application-specific blockchains. Launching a custom blockchain was previously a prohibitively expensive proposition for many projects, but Substrate makes it a viable option, allowing dApp builders to focus more on their innovations than the mechanics of building and operating a blockchain.

One interesting project being built on Substrate is Edgeware, a smart contract platform that will support development in languages that compile to WebAssembly (Wasm). Edgeware is designed to be an adaptive, actively-governed platform intended to serve as a testbed for innovation in blockchain governance. While Ethereum’s thought leaders continue to make philosophical arguments against on-chain governance by autonomous software, Edgeware will, on June 1, launch a Proof-of-Stake (PoS) mainnet with on-chain governance and self-improvement via an automated upgrade capability. The experiments conducted on Edgeware should provide some real data and insight into the viability of these approaches to governance and smart contract platforms on Polkadot.

History

Polkadot is the brainchild of Gavin Wood, a seminal figure in Ethereum’s early history. Wood was co-founder, initial CTO, and core developer of Ethereum. He coded the platform’s first implementation, wrote its formal specification, and invented the Solidity smart contract programming language. On January 11, 2016 Wood bid farewell to the Ethereum community and turned his attention toward a new venture that would deliver on the promises that, in Wood’s opinion, Ethereum could not. According to Wood, the original idea for Polkadot came to him in the summer of 2016 while waiting for Ethereum 2.0 sharding specs to solidify enough to start implementing them. Prompted by developer Marek Kotewicz, he started trying to design a sharded version of Ethereum that was as simple as possible. By October 2016 Wood had finished the first draft of the Polkadot White Paper.

While still at Ethereum, Wood co-founded, along with several members of the Ethereum team, the for-profit EthCore blockchain technology company, which later became Parity Technologies (hereafter referred to as Parity). Parity has developed important blockchain infrastructure technology, such as the Parity Ethereum Client, the Substrate development framework, Polkadot network, and the Parity multisignature wallet smart contract.

On July 19, 2017 a vulnerability in Parity’s multisig wallet code affecting a total of 596 wallet instances holding over 500k ETH was exploited by a hacker who drained 153k ETH (about 33 million USD at the time) from 3 different wallet instances. Funds left in the other 593 wallets (about 164 million USD) were rescued and returned by the skillful volunteer hacker collective known as the White Hat Group. The next day, Parity published a blog post explaining what happened and their plans to ensure it didn’t happen again.

In the summer of 2017, Wood and Parity’s Peter Czaban co-founded the non-profit Web3 Foundation to support research and development of decentralized web software protocols. One of Web3 Foundation’s primary functions would be to manage the funds raised in the Polkadot token sale that was planned for October of 2017. The token sale, which ran from October 15–27, 2017, raised around 145 million USD, making it one of the largest ICOs up to that time.

Just 10 days after the token sale ended, on November 6th, 2017, a second attack on the Parity multisig contract froze the remaining 513,774 ETH and other tokens held in all wallet instances, resulting in a combined loss of around 150 million USD. Most affected was the Web3 foundation’s wallet, which held about 306k ETH (over 90 million USD) or 2/3 of the total proceeds of the Polkadot ICO. A week later the Web3 Foundation reported that it still had enough funds left to deliver Polkadot, and Parity’s founders expressed optimism that the frozen funds would likely to be recovered within 4–6 months.

That optimism faded over time as Parity’s various proposals to unfreeze the funds failed to gain traction in the Ethereum community. The stuck funds spawned a long and vigorous debate within the Ethereum community that included a much-criticized community coinvote, the resignation of an EIP editor, and a pull request to update the state of Ethereum Improvement Proposal 999 from Draft to Accepted. EIP-999 was a formalized proposal for a controversial hard fork that would unfreeze the stuck funds but could also risk splitting the community like the DAO hard fork did.

Despite ongoing efforts to gain community support, the funds remain frozen at the time of writing. However, it’s rumored that Edgeware’s lockdrop token distribution mechanism may provide some relief for Polkadot (which owns 60% of the frozen ETH) and other affected parties. The lockdrop distributes EDG tokens to users who voluntarily lock up ETH and could provide the owners of ETH frozen in Parity’s multisig contract with commensurate amounts of EDG.

Polkadot achieved several major milestones in 2018, including the development of Proof of Concept (PoC) 1, the first successful on-chain governance-based protocol upgrade from PoC-1 to PoC-2, and the launch of the BBQ Birch testnet, which demonstrated the capability to build and deploy a Web Assembly smart contracts chain with Substrate. At the Web3 Summit in Berlin, Gavin Wood gave an impressive live-coding demo where he built a blockchain and dApp from scratch in about 15 minutes using Substrate. In December the Web3 Foundation announced the launch of its grants program funding efforts to improve the Web3 ecosystem. Awards were granted to ChainSafe and Soramitsu to implement the Polkadot Runtime Environment in Go and C++, respectively.

In January 2019, Polkadot announced the completion of its PoC-3 milestone and launch of its Alexander testnet. PoC-3, which included a novel consensus finality gadget and improved governance, brought Polkadot within one milestone (interchain communication) of being feature complete and ready for mainnet launch (expected by the end of 2019).

Although Polkadot does not yet have a running mainnet, and Edgeware has yet to launch, there is enough information available to compare the technology stack to Ethereum’s, so let’s dive in.

Scalability

Polkadot was conceived as a scaling solution for blockchains like Ethereum, whose transaction throughput is severely limited by the need for every node to validate every transaction. Polkadot scales via multiple, parallelizable chains, called parachains, whose nodes need only validate the transactions on the parachain. This allows independent transactions on different parachains to be executed in parallel, increasing transaction throughput, and scaling transaction capacity with each additional parachain.

Parachains are connected by a central relay chain that stores the headers of parachain blocks and enables reliable communication across parachains. The relay chain is a PoS blockchain, with a pool of validators that are randomly assigned to validate blocks on the different parachains. Validators are selected by nominators who stake DOTs (Polkadot tokens) that can be lost if the validator misbehaves. Having real monetary consequences for nominators distinguishes Polkadot’s Nominated Proof-of-Stake (NPoS) algorithm from traditional Delegated Proof-of-Stake (DPoS) algorithms.

Polkadot’s pooled security model allows new parachains to launch without having to find new validators to secure them. In theory, it also encourages cooperation, since the parachains don’t have to compete for exclusive validator resources. However, for a fixed-sized validator pool, adding new parachains does reduce the amount of validator resources that can be allocated to each parachain.

Consensus on the relay chain is achieved through two single-responsibility consensus mechanisms, one for block production and the other for finality. Separation of block production from finality addresses the scalability limitations of instant finality consensus protocols (e.g. Tendermint), enabling fast production of blocks and allowing a greater number of validators to participate in consensus. The two mechanisms are named by their highly contrived acronyms: BABE (Blind Assignment for Blockchain Extension), for production of new blocks; and GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement), for finality of old blocks.

BABE is an algorithm for generating relay chain blocks, which consist of headers from all valid and available parachain blocks produced by collators on those parachains. BABE is a slot-based algorithm, where the right to produce a relay chain block for a given time slot is randomly assigned to a validator known as the slot leader. Eligibility to issue the next block is decided by a private, local calculation using a verifiable random function (VRF). BABE’s design draws heavily from the block production component of Ouroboros Praos, Cardano’s PoS consensus protocol. However, it addresses certain practical limitations such as clock drift by implementing relative time, and identifying validators who skip slots by requiring periodic “proofs of losing” that demonstrate the validator had no assigned slots in the given time period. BABE is asynchronously safe and live under partial synchrony assumptions as long as more than two-thirds of stake belongs to validators correctly following the protocol.

GRANDPA is a finality gadget where, instead of voting on a single block, each validator votes on the highest block they think is valid, which is effectively a vote for all of the block’s ancestors. All blocks common to the votes of more than two-thirds validator stake get finalized. Since multiple blocks can be finalized simultaneously, validators can take longer than one block time to reach consensus on finality. This allows GRANDPA to support a larger validator set than traditional BFT algorithms that must finalize each block individually. If a validator equivocates, watchtower nodes, called fishermen, can construct proofs containing the validator’s conflicting votes to earn a bounty by slashing the validator’s stake deposit. Deposit slashing enables GRANDPA to provide asynchronous accountable safety, meaning that finalization of any two conflicting blocks will result in the responsible validators losing their stake deposits (at least one-third of all validator stake). GRANDPA also provides plausible liveness, which means that as long as the block production mechanism satisfies certain criteria, the finalized chain will grow.

The GRANDPA finality gadget is used for all parachains in Polkadot. In exchange for sovereignty over finality, each parachain gains interoperability with other parachains. This tradeoff enables Polkadot to provide a simple, interchain communication mechanism that allows parachain collators to directly communicate with each other through inbound and outbound message queues. Each collator must accept messages on the parachain’s inbound queue and must include proofs of processing on that queue with the blocks it submits for validation. Shared finality allows interchain communication to be simpler and offer much lower latency than cross-shard or cross-chain communication with shards/chains that can reorganize.

Although parachains share the same finality gadget, each may implement different block production mechanisms with different properties and parameters optimized for a particular class of applications. One of the key tenets of Polkadot’s heterogeneous design is that specialization enables optimization and removes scalability bottlenecks. In many cases, application-specific blockchains provide better performance and security, sovereign governance, and increased flexibility to innovate.

Parachain Development Kits (PDKs) are tools that greatly simplify the development of application-specific parachains. Substrate is one PDK that facilitates building blockchains. The Substrate Runtime Module Library (SRML) includes built-in implementations of some block production algorithms, including BABE, Aura, and others. Another PDK, called Cumulus, contains the glue code necessary to connect a Substrate-based chain to the Polkadot network. Together Substrate and Cumulus make it easy to build and connect parachains to the Polkadot network, expanding its transaction throughput capacity.

Depending on the block production algorithm and parameters, the transaction throughput of each chain can vary, and thus the overall throughput of the Polkadot network can only be estimated. The first version of Polkadot will allow up to 100 parachains, and assuming each can support at least 10 transactions per second (TPS), a lower bound on throughput would be about 1000 TPS. Future versions of Polkadot will allow a parachain to function as a second-level relay chain with additional parachains attached, forming a tree structure that enables theoretically infinite capacity. At some point the main relay chain becomes a bottleneck, but only to validate input queue processing since parachains communicate directly with each other. According to one estimate, the tree design will enable Polkadot to scale to 10,000x the capacity of single PoS chains.

With 1024 shards, an eight-second block time, and 8M block gas limit, Ethereum 2.0 is estimated to increase layer 1 transaction throughput more than 1000x. Layer 2 solutions such as Plasma and state channels can multiply transaction capacity of both Ethereum 1.x and Ethereum 2.0 by orders of magnitude.

At a high level, Polkadot’s architecture closely resembles the sharding designs proposed for Ethereum 2.0. Both designs scale by having a number of chains that execute transactions in parallel (parachains in Polkadot, shards in Ethereum) and synchronize with each other through a main heartbeat chain (relay chain in Polkadot, beacon chain in Ethereum). Both will employ a slot-based PoS consensus algorithm with separate mechanisms for block production (BABE in Polkadot, block proposal in Ethereum) and finality (GRANDPA in Polkadot, Casper FFG in Ethereum). Both systems will utilize a common validator pool shared by all shards/parachains, where the validators’ deposits can be slashed for not following the protocol.

One of the key differences between the platforms is that unlike shards, all of which must run the same consensus algorithm with the same parameters, parachains are heterogeneous. They can employ different block production mechanisms and network parameters to facilitate isolated experimentation and optimization for certain use cases.

Another difference is that block finality times in Polkadot are variable, in contrast to Casper FFG, which has fixed checkpoints every 100 blocks. Polkadot’s adaptive finality enables it to finalize blocks very quickly under normal conditions, and very efficiently when a backlog of produced blocks builds up.

Fast finality dramatically reduces the latency for cross-chain communication between chains or shards that can reorganize and thus rely on finalized blocks. In Polkadot, shared finality allows the blocks of normal (non-bridged) chains to be finalized together, facilitating low-latency cross-parachain calls under normal circumstances. It remains to be seen how Ethereum’s cross-shard implementation will perform relative to Polkadot’s cross-chain implementation, but currently it appears that Polkadot’s will be simpler and faster.

Whereas Ethereum 2.0 will launch with a fixed number of shards defined by the core protocol, Polkadot will launch with a soft limit of 100 parachains, which can be launched by anyone. Deploying a parachain on Polkadot requires obtaining a lease for a parachain slot in the network. The price of admission in Ethereum is the gas cost of deploying a smart contract, which is a one-time fee in exchange for a perpetual lease.

Perhaps one of the biggest, and ultimately most important differences between Polkadot and Ethereum 2.0 is in the timeframe for delivery of a scalable layer 1 system that provides functionality comparable to Ethereum 1.x. For Ethereum this will occur at the end of phase 2, and for Polkadot at the mainnet release of PoC-4. Below is a table listing the milestones on Polkadot’s development roadmap and the Ethereum’s sharding roadmap.

The delivery dates for these milestones are not anywhere close. At the time of writing Polkadot had completed PoCs 1–4 and was 83% complete with PoC-5, while Ethereum’s first Phase 0 implementation had just been launched.

Governance

How best to implement blockchain governance (or not) remains an open question with many important factors to weigh and a wide variety of opinions and approaches. As new platforms, Polkadot and Edgeware have the opportunity to learn from and improve upon the governance processes employed by Ethereum and other predecessors. Polkadot and Edgeware will be experimenting with new, more formalized processes that are generally eschewed by the Ethereum community.

Ethereum’s approach to governance is modeled after the Internet Standards process and is largely inherited from Bitcoin’s improvement proposal model. Whereas Bitcoin’s lack of formal governance is somewhat culpable for the slow deployment of the Segwit upgrade and various community splits, Ethereum’s stakeholders have been relatively effective at coordinating and implementing change in a timely manner without splitting the community. Hard forks were developed, tested, and deployed in a matter of days during the DevCon2 denial of service attacks and successfully postponed in a matter of hours after a critical bug was discovered in the Constantinople hard fork. It’s been suggested that any improvements Ethereum has made are largely due to the community’s ability to coordinate around Ethereum’s recognized leader.

The ability for a single person or group of people to enact state changes on a blockchain can be problematic, as it can undermine the security and censorship resistance of the network. Even when governance participants are trustworthy, real world legal authorities can compel them to exercise their power to make state changes that comply with laws of a certain jurisdiction. Andreas Antonopoulos warns that governance powers that expand a compelled participant’s ability to answer “can’t” into “won’t” cross an important line that makes a refusing participant vulnerable to criminal prosecution. The difference between “can’t” and “won’t,” he says, is “two life sentences plus forty years,” referring to the harsh sentencing of the Silk Road online marketplace’s operator as evidence that this is not some nebulous theoretical line, but one with serious consequences.

Such consequences weighed heavily on prominent Ethereum researcher Yoichi Hirai who, in February 2018, resigned from his position as EIP editor out of fear that he might be criminally prosecuted for recusing himself or otherwise failing to block EIP 867. EIP 867 describes a standard process for recovering lost funds in Ethereum. It was motivated by the failure of prior proposals to recover funds frozen in the Parity multisig wallet by working through Ethereum’s informal governance processes.

Ethereum’s failure to recover the frozen funds is, according to Ethereum researcher Vlad Zamfir, evidence that Ethereum’s governance is based on bad political/legal foundations. The worst among them is what Zamfir calls “Szabo’s Law” — the minimalist approach to blockchain governance based on immutability. Under Szabo’s Law, making changes to the blockchain protocol is not an option for resolving disputes. When enforced by autonomous software this law of immutability empowers governance participants to say “can’t” rather than “won’t” when requested by authorities to enact some irregular state change. However, Zamfir strongly believes that a law of immutability will make it so difficult for real-world legal systems to resolve disputes that their only recourse will be to make immutable blockchains illegal.

Ethereum violated the immutability law once, in July 2016, when a decision to hard fork was enacted to restore stolen DAO funds. This resulted in a community split where many in the community rejected the fork and remained on the immutable blockchain now called Ethereum Classic. Whereas the popularity of Ethereum relative to Ethereum Classic suggests that hardline immutability is a minority view in the Ethereum community, the community has not enacted any bailout forks since the DAO despite the persistent efforts of the Parity/Polkadot community to unfreeze funds in the Parity multisig wallet. Preventing the fracture of the community is a primary goal of blockchain governance that often favors non-action, though long periods of non-action can also create mounting frustration that culminates in a community and chain split.

Lane Rettig on Twitter

Ethereum governance has failed. We are a de facto technocracy, where a small group of technocrats, the core devs, have final say over what goes into the protocol.

Ethereum’s governance has been characterized by many (including Gavin Wood) as a technocracy, with its ability to coordinate and act largely facilitated by a few key individuals that the community trusts. This system has worked relatively well in coordinating changes in a timely manner, but lack of transparency in decision making has raised some concerns. One visible example was the controversial decision by a small team of core developers to enact EIP-1057, which institutes a new ASIC-resistant proof-of-work scheme called ProgPoW. This major change to the protocol would require a (possibly contentious) hard fork that, if enacted without addressing the concerns of community members, could run the risk of causing a community and chain split.

However, Ethereum is making efforts to address the community’s concerns by making decision processes more transparent and vetting decisions through a “multifactorial consensus” process. In the case of ProgPoW, a coin vote, hashrate vote, and other types of votes were held to gauge sentiment and risk in moving forward. With overwhelming support from miners, majority support in the community, and crowdsourced funding of a ProgPoW audit, the hard fork to switch to ProgPoW should not be contentious.

The Ethereum community uses on-chain voting only as a signaling mechanism, not to pass binding legislation that would automate hard forks. Ethereum thought leaders have argued that automated forks disempower node operators because they change the default (result of doing nothing) from opt-out to opt-in. Viewing governance as a social coordination game, they point out how game-theoretic flaws in coin-holder voting schemes can lead to cartel formation and capture by oligarchs. They claim that, in contrast to binding on-chain voting mechanisms, “loosely coupled” (non-binding) voting enables capture to be thwarted by political coordination, for example, by the community agreeing to ignore the coin votes of known exchange addresses. They warn that “tightly coupled” (binding) stakeholder voting mechanisms often lead to governance capture by a few whales who possess disproportionately large amounts of tokens. In fact, this form of capture has been documented in several running systems.

Often, a single whale’s vote is enough to overturn a community’s decision, as was evidenced in some recent stakeholder votes on various Aragon Governance Proposals (AGPs). AGP-42 is a proposal to keep Aragon, a project that had announced intention to build on Polkadot, focused on Ethereum. The vote on AGP-42 was leaning slightly toward yes, until a single vote backed by a large stake came in right at the end of the voting period to change the outcome to no. Similarly, AGP-35, was opposed by the community by a 15% margin until a single whale vote at the end caused it to pass. AGP-35 is a proposal for Aragon to lock funds in Edgeware’s lockdrop program, which distributes EDG tokens to holders of ETH who voluntarily lock their ETH in a smart contract for some number of months.

A subjective, technocratic, politics-based approach to governance may work well enough for a platform where strong network effects make opting out difficult and political coordination is facilitated by trusted leaders — two properties Ethereum currently enjoys. However, platforms operating under different conditions might need to make different tradeoffs in designing their governance mechanisms. Without established network effects, controversial decisions that are perceived as illegitimate due to a lack of transparency and accountability can engender community splits. Without trusted leaders to coordinate around, agreements that are not binding can be slow to enact or fail to get enacted, forestalling progress. For most decentralized platforms a high degree of transparency, accountability, and bindingness of decisions will be necessary to maintain cohesion in the community and to support innovation.

To those ends, Polkadot is taking a significantly more structured and formalized approach to governance than Ethereum. Transparency and accountability are achieved by requiring all proposed changes to be approved by a stake-weighted coin vote process. Decisions are made binding through a built-in upgrade mechanism in the node software that automatically deploys voter-approved upgrades. These design tradeoffs are based on the assumptions that a transparent, countable voting mechanism will improve cohesion by making governance decisions more acceptable to opposing minorities and that a default to accept upgrades is optimal for enabling innovation. Polkadot’s governance design takes into account the theoretical and empirically observed issues with stakeholder voting, and introduces a number of different mechanisms to address them.

Human subjectivity is an important ingredient in governance that also serves as a check and balance on automated processes. To check and assist its automated upgrade process Polkadot’s governance structure includes a council of elected officials whose purpose is analogous to a corporate board of directors. The council’s primary functions are to propose sensible referenda and cancel non-controversially dangerous or malicious referenda. Council members are elected by a stake-weighted approval vote and serve fixed, one-year terms. Polkadot’s council will initially include 6 people, but will grow to 24 over the first 9 months.

Voter apathy, which can result in insufficient quorums is a problem in many blockchain and real-world voting systems. To keep governance functioning well in the face of low voter participation, Polkadot employs an adaptive quorum biasing mechanism that adjusts the supermajority required to reach a decision based upon turnout based on a mathematical formula. The lower the turnout the larger a supermajority of votes required to approve or reject a proposal. For proposals submitted by the public, a supermajority of stake in favor is needed to approve. Proposals with unanimous council support require a supermajority of opposing stake to reject.

Vote buying, which can be accomplished through stake pool rewards, is a common method for cartels to capture voting systems. To ensure economic buy-in to decisions and discourage vote selling, Polkadot employs time-locked vote multiplying and delayed enactment of approved referenda. Voters must lock their tokens for some time period greater than the enactment delay, and can multiply the weight of their stake vote with longer lock times. This creates a futarchy-like mechanism, where voters with conviction on a certain issue can bet bigger on it, i.e. multiply their influence by staking more tokens for longer. Delayed enactment creates a period prior to enactment during which opposers to a decision can exit their tokens from the system while the supporters tokens remain locked, thereby providing some protection against tyranny of the majority.

With these mechanisms Polkadot is hoping to improve on previous governance implementations and deliver an open, transparent, efficient governance process that encourages innovation and cohesion of decentralized communities. The designers of Polkadot’s on-chain governance system acknowledge there are limitations in its initial implementation, saying, “We know this is far from perfect, but we hope and expect that it is good enough to deliver the platform on which a truly great governance system can evolve and adapt over the course of Polkadot’s lifetime.”

One project whose mission is to evolve automated on-chain governance — specifically Polkadot’s governance — by facilitating experimentation is Edgeware. Most likely to become Polkadot’s first smart contract parachain, Edgeware is built on the same Substrate governance modules that power Polkadot. Edgeware includes Substrate’s democracy module to enable stakeholder voting and council module to support electing representatives and managing proposals, and will thus inherit Polkadot features such as adaptive quorum biasing, time-locked vote multiplying, and delayed enactment. Edgeware plans to extend this framework with identity, delegated stake voting, signaling (non-binding votes), and other features that will facilitate experimentation with various governance mechanisms such as identity-based voting, quadratic voting, DAOs, and essentially any mechanism that can be expressed in WASM code.

Edgeware will serve as a low-risk, rapid-feedback testbed for governance mechanisms whose best innovations can, through contributions to Substrate, feed back into Polkadot, improving its governance in a low-risk fashion. Meanwhile, Ethereum’s governance will continue to evolve as the platform faces real issues with large amounts of money on the line, as we’ve seen with the Parity multisig wallet freeze and ProgPoW.

Edgeware will also enhance Polkadot by providing a parachain for deploying smart contracts. This will allow projects to build dapps on Polkadot without having to build, connect, and manage their own parachain. Whereas Polkadot can support any number of smart contract platforms, Edgeware will likely be the first platform to directly compete with Ethereum. So let’s take a look at how Edgeware’s smart contract offering compares to Ethereum’s.

Smart Contract Security

Edgeware is a smart contract platform that addresses the need for simple, permissionless deployment of applications on Polkadot. It allows projects to build dApps and deploy them on the Edgeware parachain without having to build, connect, and manage their own parachain. As such, Edgeware will serve as a soft on-ramp for developers wishing to interact with the Polkadot ecosystem. The platform is built on Substrate and thus inherits Substrate’s networking, NPoS consensus, and GRANDPA finality implementations. This allows Edgeware’s developers to focus on the platform’s innovative features: governance and smart contracts. Edgeware’s WASM execution engine for smart contracts allows contracts to be written in any high level language that can compile to WASM, such as C, C++, and Rust. This significantly lowers the barrier to entry for developers from outside the crypto ecosystem, since many will be able to start developing smart contracts in a familiar programming environment.

In many respects Edgeware’s smart contract platform works like Ethereum’s. Edgeware implements an Ethereum-like system of accounts and balances that facilitates porting Ethereum contracts, e.g. ERC-20 implementations, and dApps to the platform. It uses gas, denominated in EDG, to limit execution of smart contract code and prevent spam. As in Ethereum, smart contracts can call other smart contracts synchronously. In addition to leveraging code in other contracts, Edgeware also allows smart contracts access to some of its built-in modules such as Identity and Council. These APIs will facilitate experimentation with governance mechanisms implemented in smart contracts.

Edgeware will not initially support Solidity or Vyper, but likely will if/when tooling for compiling those languages to WASM matures. Despite this, there are some prominent Ethereum projects already working on Polkadot implementations. Although they will have to rewrite their Solidity code, the process will be facilitated by the mature tooling available for languages targeting WASM.

Using WASM as a common target allows any number of general-purpose languages to run and interoperate on Polkadot. This makes the platform accessible to more developers, lowers the developer learning curve, leverages tooling from the broader open source community, and facilitates experimentation with smart contract programming languages. However, a primary responsibility of smart contracts is to manage funds securely, and writing them in an unconstrained, general-purpose programming language can create a very large attack surface.

Too much flexibility and complexity in a smart contract programming language can have disastrous effects, as Ethereum’s long history of smart contract breaches has shown. This problem has been covered extensively in this series so to summarize: Ethereum’s smart contract vulnerabilities are the result of poor language design, not just sloppy coding. The two Parity multisig wallet hacks showed that even the best teams of developers using best practices and tools to ensure the safety of their smart contract code cannot prevent major vulnerabilities in their code. The funds frozen by the second Parity wallet hack created a governance crisis for Ethereum not unlike 2016’s DAO hack that led to a community split. These threats to community cohesion are traceable to a single root cause: smart contract vulnerabilities resulting from too much language complexity.

Ethereum’s Vyper smart contract language is designed on the principle that constraining a language to prevent vulnerabilities, hacks, and governance crises is much better than having to deal with the consequences of full-featuredness reactively. Vyper reduces the attack surface on smart contracts by removing several language features that can result in surprising and thus vulnerable code. The code is easier to audit and more amenable to formal verification than most full-featured languages. Unfortunately, the vast majority of smart contracts running on Ethereum today are written in Solidity, and the Ethereum community remains vulnerable to major crisis-inducing exploits.

Perhaps no one understands and appreciates the lessons learned on Ethereum more than Polkadot’s creator, Gavin Wood, who is one of the original designers of Solidity. It’s likely that those experiences will have some impact on the design of smart contract programming languages developed for Polkadot, such as Parity’s ink! language. ink! is a Rust-based embedded domain-specific language that compiles smart contract code to WASM so that it can be deployed on parachains. As a component of Substrate, ink! will allow any chain built on Substrate to support smart contracts. ink! exemplifies how to leverage the tooling of a general-purpose target such as WASM to get the built-in safety features of supported high-level languages, while adding constraints that reduce attack surface. At the time of writing, ink! was still a work in progress, as are Substrate and Polkadot. It will be interesting to see how ink! and other languages developed for Polkadot incorporate lessons learned to improve the security of smart contracts developed with them.

Conclusion

When its mainnet launches in June, Edgeware will provide a high-throughput, fast finality, pure PoS chain and WASM-based smart contracts platform, well ahead of Ethereum 2.0. However, as a standalone chain that doesn’t support Solidity or Vyper, it is unlikely to realize network effects that significantly disrupt Ethereum.

Those dynamics could start to change after Polkadot launches and grows the network’s utility by adding useful parachains. When Edgeware’s parachain is able to send messages to WASM-based dApps running on other high speed parachains, and vice versa, the Ethereum 2.0 vision will be essentially realized on Polkadot. If Polkadot launches its mainnet in 2019 as planned, it will likely have several months to build up a large network of communicating parachains before Ethereum 2.0 has communicating shards.

In those months, projects will have to weigh the advantage of tapping into Ethereum’s network effects against Polkadot’s transaction throughput and scalability advantage. The viability of layer 2 solutions on Ethereum could lessen Polkadot’s scalability advantage, while achieving a critical mass of parachain applications and network utility could erode Ethereum’s. A strong preference for automated, on-chain governance or informal, multi-process governance could be the decider for a number of projects.

One of the most threatening aspects of Polkadot is that it is not a smart contract system, but a network upon which any number of smart contract platforms can be developed. If Edgeware fails, any lessons learned can be used to inform the design of a new and improved smart contract platform that can launch on a new parachain (or be installed as an upgrade on Edgeware’s parachain). The ability to experiment, gain empirical evidence, and improve can greatly speed the pace of innovation in governance, smart contract security, user experience, and other key areas of research in decentralized systems. The heterogeneity and ephemerality of parachains supports this iterative process and the Substrate framework significantly speeds it up.

Of course, this threat is completely theoretical until Polkadot actually launches a mainnet. Only when that happens can the assumptions that underpin Polkadot’s path to world domination be validated. A running Polkadot mainnet will reveal how well on-chain algorithmic governance mechanisms work to support innovation, how much the Substrate framework simplifies building parachains for a wide variety of use cases, and whether the scalability, heterogeneity, and interoperability of parachains will attract innovators to build on Polkadot. If the Polkadot network gains enough traction to have a significant amount of funds at stake, the security of its smart contract platform(s) will be tested, as will the ability of its governance processes to keep the community together when it is faced with difficult decisions.

Without a running mainnet Polkadot currently resides at a Challenger threat level, having numerous promising and disruptive innovations. However, once the Polkadot mainnet launches and applications are deployed the threat level could rise quite rapidly.

Thanks to Gavid Wood, Nate Johnson, Alfonso Cevallos, Luke Schoen, and Logan Saether for their input on earlier drafts of this article.

If you’d like to follow me on Twitter, I’m @edposnak

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Polkadot was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at Stellar and the challenge it could pose to today’s dominant platform, Ethereum.

In a crypto winter that has seen Ripple take over Ethereum’s long held number 2 market cap ranking, Ripple’s offspring, Stellar, has quietly risen into the top 10. Though it began as a Ripple-like consortium chain, Stellar has since evolved into an open, decentralized platform that supports smart contracts.

Stellar’s co-founder Jeb McCaleb has a long history of creating globally dominant systems in the decentralized space. In 2000, long before Bitcoin was a glimmer in Satoshi’s eye, McCaleb and Sam Yagan created the eDonkey peer-to-peer file sharing network, which in 2004 became the most widely used file sharing network on the Internet until it was overtaken by Bittorrent in 2007.

In 2007 McCaleb’s brief interest in creating a trading site for Magic: The Gathering cards, led him to create the Magic: The Gathering Online Exchange (Mt. Gox). In July 2010, wanting “a good way to buy and sell Bitcoins,” he turned Mt. Gox into a bitcoin exchange that would eventually become the world’s largest, handling over 70 percent of all Bitcoin transactions at its peak.

In February 2011 McCaleb sold the Mt. Gox exchange to Mark Karpelès. Under Karpelès watch 850k bitcoins were stolen from Mt Gox’s wallets, fueling a downward spiral that ultimately led to the company’s bankruptcy in February 2014 and the arrest of Karpelès on charges of fraud and embezzlement in August 2015.

While Mt. Gox was imploding, McCaleb and Chris Larsen co-founded Opencoin to create a new digital currency based on the Ripplepay protocol developed by Ryan Fugger in 2004. McCaleb and team worked to evolve Ripplepay toward a more decentralized system based upon a web of trust among nodes, a concept foundational to Stellar. McCaleb remained with OpenCoin until July 2013 when he left over personal conflict with Larsen and perhaps other issues. A couple of months later OpenCoin officially became Ripple Labs Inc. and fully open sourced its code. It also launched the XRP coin, which is now the second largest cryptocurrency by market cap (McCaleb owns billions of XRP).

In February 2014, McCaleb announced he was working on a secret bitcoin project. The project was revealed as Stellar in July 2014 with the creation of the non-profit Stellar Development Foundation (SDF). SDF’s stated mission is “to promote global financial access, literacy, and inclusion […] through the development and maintenance of technology and partnerships.” Fueled with seed funding from Stripe and other investors SDF launched the Stellar network and the Lumens (XLM) token in July 2014.

On December 2, 2014 Stellar’s consensus protocol experienced a ledger fork that rolled back hours of transactions. This prompted Stellar to temporarily centralize the network to a single node until it could launch a new provably safe, decentralized consensus protocol that was being designed by Stanford professor Dr. David Mazières. In April 2015, amid McCaleb’s legal battles with Ripple, the Stellar Consensus Protocol white paper was published.

The new consensus protocol went live in November 2015 and Stellar began building on it immediately, forming partnerships to facilitate cross-border payments that bridge crypto and fiat currencies. By the end of 2016 Stellar had announced several remittances and payments projects built on the Stellar network. In May 2017 McCaleb and Brit Yonge co-founded the for-profit Lightyear to build a universal payment network on Stellar. Lightyear recently acquired Chain.com to form InterStellar, which is building tools, products, and services that make it easier to use and build on Stellar. In September 2017, Stellar announced the Stellar Partnership Grant Program, which would fund projects building on Stellar network and filling unmet needs of the Stellar ecosystem.

2018 was a year of major ICOs on Stellar, starting with Mobius’s 39 million USD raise in January and continuing with several other large token sales throughout the year. Whereas Ethereum is still far and away the leading platform for ICOs, concerns about Ethereum’s fees, security, scalability, and other issues have led some to consider Stellar a better alternative for issuing their token.

Stellar is not a typical smart contract platform in that it does not have a smart contract language or virtual machine that can be directly compared to Ethereum’s. Instead it provides a well-defined set of operations that it claims “can be used to build sophisticated smart contracts.” This is just one example of how Stellar’s approach is very different from Ethereum’s and other platforms we’ve looked at in this series. Other distinguishing factors include the fact that Stellar’s consensus protocol is not proof-of-anything, it has no mining or other sybil resistance mechanism, no one knows who all the nodes are, anyone can issue tokens for any real world asset and immediately trade them on the platform’s built-in exchange, and users can pay for goods and services in sheep even when the seller explicitly does not accept sheep.

It may be like comparing apples to sheep, but it will be interesting to see how Stellar’s novel approach to building an open smart contract platform compares to Ethereum’s. Let’s dive in.

Scalability

The Stellar network is often claimed to support thousands of transactions per second (TPS). The figure given on Stellar’s website is 1000 operations per second (OPS). The distinction between a Stellar transaction and a Stellar operation is important to understanding practical throughput limitations of Stellar and evaluating the various TPS claims that conflate the two.

Stellar transactions are used to send payments and execute state changes on the blockchain. They most closely resemble Ethereum transactions, having a source account, account sequence number, a list of operations to execute, digital signature(s), and some transaction fee specifications. The list of operations in a Stellar transaction is a sequence of state mutating actions that allow the transaction to create, pay, and manage accounts and perform other predefined functions. The operations in a Stellar transaction must be executed sequentially and atomically such that the failure of any operation will cause the whole transaction to fail, reverting all state changes from prior operations. Thus Stellar operations most closely resemble state mutating Ethereum smart contract functions with revert failure semantics, where the sequence of function calls is determined by the execution path that the Ethereum transaction takes through the smart contract(s).

A ledger in Stellar is a collection of ordered transactions that the network reaches consensus on and chains together to create an immutable history, much like a block in Ethereum and other blockchains. Stellar has a protocol parameter limiting the number of transactions per ledger to 50 and a fixed limit of 100 operations per transaction. Since the network produces a new ledger containing up to 50 transactions and 5000 operations every 5 seconds on average, Stellar’s max capacity is 10 TPS and 1000 OPS.

However, that 1000 OPS is a theoretical maximum that can be orders of magnitude larger than what the network actually achieves in practice. A load test analysis conducted by the Kin Ecosystem Foundation set out to empirically determine the actual maximum TPS their application could achieve on Stellar. Expectations of high throughput, based on the common conflation of operations and transactions, were shattered when Kin discovered that their most common use case, which used 1 operation per transaction, achieved at most 10 operations per second using the network’s entire capacity. Kin assumed that this was a temporary problem that Stellar would fix and announced their decision to reissue their ERC20 token on Stellar, but shortly thereafter decided to build on their own fork of Stellar citing “business scale” issues with the original Stellar platform.

A mix of different application types can significantly reduce the overall OPS the network realizes in practice. Data from Stellar’s mainnet, shown in the figure above, illustrates how the ratio of operations to transactions varies from ledger to ledger (each vertical bar is one ledger) and averages below 10-to-1 for a typical transaction mix. This results in an actual network-wide throughput that is nowhere near the theoretical maximum of 5000 operations per ledger (1000 OPS) even as the transaction count approaches the limit of 50 transactions per ledger (10 TPS).

The gross inefficiencies in achieving Stellar’s theoretical OPS limits arise from the fact that Stellar’s capacity is limited by transactions and not operations. If Stellar replaced the transactions per ledger limit with an operations per ledger limit (of 5000 operations per ledger) then it could actually achieve 1000 OPS and over 100 TPS under a typical transaction mix. This is essentially what Ethereum does with its block gas limit protocol parameter, which allows miners to fill each block with as many transactions as possible within the gas limit.

Currently, Ethereum’s Proof of Work (PoW) mining chain and Stellar’s Federated Byzantine Agreement System both realize on the order of 10 TPS in practice. Whereas Ethereum hopes to (someday) scale its base layer throughput 1000x with sharding (covered extensively in our last article), Stellar has, to date, provided few details on upcoming base layer scaling solutions. As recently as July 2018 Jed McCaleb publicly stated that “At some point — to reach scalability — we will have to do things like sharding and subnetworks” but, at the time of writing, the only scaling solution that Stellar has publicly announced is the layer 2 payment channels project called Starlight.

Starlight works like other payment channel protocols such as Lightening Network and Raiden Network by locking up funds on-chain and allowing counterparties to make payments off-chain by exchanging signed messages, which are not broadcast to the network. Thus payments happen instantly, privately, and without fees. The counterparties can later close the channel cooperatively or force close if the other party misbehaves or goes silent. Like all layer 2 solutions, Starlight requires all parties (or their agents) to be online and monitoring the network while the channel is open so they can resolve any conflicts in a timely manner.

Starlight is currently an early demo deployed only on the testnet and only supports payments in the platform’s native XLM token. Support for non-native assets, routed payment channels, compatibility with other payment channel networks such as Lightening and Interledger, and deployment on the Stellar mainnet are in the Starlight roadmap for the coming year, but the delivery timelines are not specified.

The timeline for production ready layer 2 solutions on Ethereum is equally fuzzy. After years of development (and 33 million USD in ICO funding) Raiden recently announced deployment of an “alpha testing” release on the Ethereum mainnet, which is “not yet production ready.” Various flavors of Plasma have been running testnet implementations and aspirations for Ethereum mainnet deployment in early 2019. Whereas Ethereum’s research and development resources are unparalleled among blockchains, they are spread out among a large number of layer 2 projects, none of which, at present, appears substantially more mature than Stellar’s Starlight project.

Although it’s currently unclear how Stellar plans to scale its base layer, we do know that it has at least one key advantage over Ethereum when it comes to implementing sharding: its federated byzantine agreement consensus protocol (described in the next section) provides instant finality (i.e. non-forking). Forks and chain reorganizations are naturally occurring phenomena in blockchains like Ethereum. A transaction appearing in the latest block may be reverted or invalidated when the fork is resolved, which is why Ethereum users and applications must typically wait for several confirmations before considering a transaction to be final. A chain reorganization that reverts/invalidates some transactions on one shard will affect all dependent transactions on other shards and any transactions dependent on them, and so on, making cross-shard communication complicated and slow. Ethereum’s current approach to preventing this is to use checkpoints (blocks that cannot be reverted) as anchors for cross-shard communication, though the cost of achieving safety this way is a latency of several block times (on the order of minutes) for cross-shard interactions.

Unlike Ethereum, Stellar’s consensus protocol does not fork. Once the network reaches agreement on a ledger, the transactions in that ledger are final and can never be reverted. Having instant, not probabilistic, finality greatly simplifies and reduces the latency of cross-shard communication and even makes it possible to implement synchronous cross-shard transactions. It will be interesting to see what sort of sharding mechanism Stellar comes up with and how it compares to Ethereum’s in terms of throughput and latency.

Consensus Safety

The Stellar Consensus Protocol (SCP) is an interesting alternative to the Nakamoto Consensus style protocols implemented in Bitcoin, Ethereum, and several other blockchains. Both are designed to enable agreement on the order of transactions in a decentralized network where participation in consensus is open to anyone, including malicious actors.

To be viable, a consensus protocol must simultaneously exhibit safety — agreement on the canonical sequence of valid transactions — and liveness — ability to continue sequencing transactions without getting permanently stuck. Both can be easily achieved on a centrally managed network, where the set of participating nodes is well known and it is reasonable to make assumptions about the eventual delivery of messages. However, achieving this on an open, decentralized network with bad actors and unbounded delays is difficult. In fact, it’s theoretically impossible to achieve both safety and liveness with even one faulty node participating in the consensus process. Yet both Stellar and Ethereum seem to achieve safety and liveness in practice on the Internet while allowing open participation in consensus. Both platforms incorporate novel approaches to achieve this, though each has very different tradeoffs.

Ethereum employs Nakamoto Consensus, which utilizes cryptoeconomic mechanisms (e.g. mining, staking) to incentivize block production and keep the system live. Nakamoto Consensus favors liveness over safety, as it does not prevent forks, nor the double spends that forks enable. It is a common misconception that Nakamoto consensus “solves” the double spend problem. The solution lies not in the protocol, but in users and applications waiting an appropriate number of confirmations before accepting a payment as “final enough” to enact their end of the transaction. There is always some probability that a chain reorganization will cause the payment to be reverted (enabling a double spend), but the more confirmations that have accumulated, the lower that probability becomes. This scheme works well enough in practice, though it can take minutes or hours to gain enough assurance that a payment will not be double spent.

Stellar employs Federated Byzantine Agreement (FBA), which favors safety over liveness. An FBA protocol is essentially a Byzantine Fault Tolerant (BFT) protocol with an open participation model that allows consensus nodes to freely join and leave the network. Stellar’s FBA has been proven to be optimally safe in an asynchronous setting, meaning that it guarantees agreement under any failure scenario in which it’s possible for some protocol to provide such a guarantee. In contrast to Nakamoto consensus, SCP stalls when nodes cannot reach agreement, but, like most BFT protocols, the agreements it reaches are immediately final, so forks, chain reorganizations, and double spends are impossible (within some fault tolerance limits). However, unlike BFT protocols, SCP nodes cannot reach consensus by a fixed quorum (e.g. 2/3 of consensus nodes agreeing) because the set of nodes participating at any given time is unknown. Instead, they reach consensus through peer-to-peer trust arrangements managed locally at each node.

Much in the way Ethereum’s safety depends on the judicious use of confirmations, Stellar’s safety depends on prudent configuration of these trust arrangements. The provably optimal safety and “plausible” liveness properties of SCP only exist as long as the trust arrangements maintain a property called quorum intersection despite Byzantine failures. Otherwise the SCP network is as susceptible to safety failures as Ethereum is without confirmations.

What is quorum intersection despite Byzantine failures and how is it maintained? An SCP node defines its trust arrangements as a list of node sets, called quorum slices, that the node trusts to provide truthful information. The node will only agree to a ledger if all of the nodes in at least one of its quorum slices agrees to it. Nodes gossip their intentions to each other in a multi-stage federated voting process that reaches consensus once a quorum — a set of nodes that encompasses at least one quorum slice of each of its members — agrees on the same ledger. A network has quorum intersection if any two quorums we can construct overlap in at least one node (kind of like how actor relationships overlap with Kevin Bacon). With quorum intersection it’s not possible for two quorums to finalize different ledgers unless all of the overlapping nodes violate the protocol by voting for conflicting ledgers. If at least one of the overlapping nodes follows the protocol it will prevent conflicting ledgers from being finalized.

The above slide illustrates a situation where Quorum A and Quorum B intersect at node V7. If V7 equivocates by telling all members of Quorum A it supports one ledger and telling all members of B it supports another conflicting ledger, then Quorum A and Quorum B can finalize those conflicting ledgers, violating all safety guarantees. This is where the “despite Byzantine failures” part of the property comes in; safety depends on the setup having quorum intersection after all the Byzantine nodes are removed.

If preserving quorum intersection despite Byzantine failures is so critical and, as the SCP whitepaper states, each node is responsible for preserving it, then how should each node operator design their quorum slices to ensure this? Stellar advises picking “conservative slices that lead to large quorums” and Stellar’s blog recommends “ensuring slices are large enough and that the nodes they contain are important enough not to risk their reputations by lying and feeding different information to different people.” Whereas larger quorum slices are more conservative with respect to safety (they increase the probability of maintaining quorum intersection), they do so at the expense of liveness (they are more likely to become blocked due to a single offline node). Stellar’s website offers some detailed guidance on choosing quorum slices and thresholds to balance liveness and safety, and even provides instructions for monitoring and repairing unhealthy quorum slices. However, these are just best practice recommendations, not an objective set of rules that a node administrator can follow to ensure quorum intersection despite Byzantine faults.

The consensus safety of the Stellar network hinges on the configuration choices of node operators, which are entirely subjective and loosely coordinated at best. However, Stellar points to the success of autonomously administered peering arrangements in inter-domain routing as an example of robust architecture emerging from market forces. But, as Greg Maxwell pointed out in a 2015 discussion with David Mazières, inter-domain routing is hardly a convincing precedent because routing systems can (and often must) work with inconsistencies, but ledgers require the strong safety properties of consensus systems.

Nonetheless, Mazières believes that an architecture that ensures safety through quorum intersection despite Byzantine faults will emerge from sets of pairing agreements. He envisions a specific architecture where quorum slices are configured to form a hierarchy with “anywhere from four to dozens of widely known and trusted financial institutions” residing at the top tier and individual “countries or geographic regions” in the middle tiers.

In the figure above, Mazières presents an example of how market forces could allow a de facto group of four top-tier banks to emerge from peering relationships. In this example, these banks only have trust relationships with each other, but the middle tier nodes include 2/4 top tier banks in each of their quorum slices (the presentation later shows how “paranoid” middle tier nodes could add non-profit nodes like Stellar, EFF, and ACLU to their quorum slices to act as watchdogs on colluding banks). Stellar is nudging node operators toward this architecture by providing syntax and examples that encourage structuring quorum slices in tiers and publishing a list of known validators with uptime stats on their website. These tools, along with the diligent monitoring and repair of quorum slices by node administrators, may be enough support to allow the Stellar network to maintain safety as Stellar grows and becomes more decentralized.

Like many blockchain projects, including Ethereum, Stellar is experimenting with adding some elements of centralization and trust to build a practically useful (vs theoretically pure), open, decentralized system. It’s not clear whether Stellar’s network can maintain consensus safety without these elements, but the mainnet has been running with open participation for 3 years without a major consensus failure.

Governance

Elements of centralization and trust are found in the current governance structures of both Ethereum and Stellar. The SDF, which oversees the distribution of the 100 billion XLM created at Stellar’s genesis, funds most of Stellar’s core development and selectively offers grants to certain projects building on Stellar. There are many autonomous Stellar-based projects, though some of the more prominent ones are run by McCaleb’s for-profit company Interstellar.

Similarly, the Ethereum Foundation, which controls the proceeds of the Ethereum crowdsale, funds much of Ethereum’s core development and selectively offers grants to certain projects building on Ethereum. There are a large number of other, autonomous projects building on Ethereum, over 50 of which are Consensys spokes, incubated by the for-profit Consensys Labs.

Stellar’s monetary policy and governance over its native currency is somewhat different than Ethereum’s. All of the XLM tokens created at genesis were allocated to SDF, which has full discretion over their distribution. Stellar has no block rewards, but increases supply of XLM 1% annually through an inflation voting mechanism that allows existing stakeholders to earn interest on the coins they possess.

Ethereum’s genesis block allocated less than 20% of the genesis ETH to the Ethereum Foundation, but nearly half of the ETH in existence today has been minted via block rewards earned by PoW miners. The size of the block rewards determines the inflation rate. Ethereum’s primary block reward will be reduced from 3 to 2 ETH in the upcoming Constantinople hard fork. This fundamental change to Ethereum’s monetary policy resulted from an informal governance process that entailed community debate over three competing proposals, a disregarded community poll, and ultimately agreement among roughly 15 Ethereum core developers.

The Constantinople hard fork was scheduled for January 16, 2019; however, the day before it would have taken effect, Chain Security revealed that an upgrade to reduce gas costs of storage operations would make existing smart contracts vulnerable to reentrancy attacks (like the one that enabled draining all funds from the DAO). In response, “key stakeholders around the Ethereum community” decided to postpone the hard fork and released a statement instructing node operators to upgrade to new versions of the Geth and Parity software. The last-minute postponement resulted in about 10% of miners failing to install the upgrade and mining on the Constantinople fork. The swift coordination of 90% of miners might be viewed as a community governance success, but perhaps not to those who lost revenue by mining on the minority chain.

The events surrounding the Constantinople hard fork illustrate that Ethereum governance today is still somewhat centralized, informal, and suboptimal. However, there are coordinated efforts aimed at evolving Ethereum toward a more inclusive and formalized (legitimate) process, even as Ethereum’s thought leaders debate what that should look like.

Stellar’s governance structure is mostly centralized within the SDF, whose board of directors oversee all policy decisions. Institutions who are approved by SDF and make recurring financial donations can become part of the SDF’s Expansion Board and earn the right to participate in some of SDF’s governance processes through voting. Other stakeholders and community members are apparently excluded from this process.

Some amount of governmental power in Stellar can be wielded by anchors, the trusted entities that issue assets on the Stellar network. Anchors enable real world assets to be exchanged on Stellar by issuing digital credits in exchange for deposits of the asset. Users must trust that the issuer will properly redeem the credits and formally declare this trust by creating trustlines to the anchor that holds their deposit. By default, anchors have the ability to authorize and revoke access to the assets they issue. The power to refuse to credit or freeze any account at the anchor’s discretion can be used to support compliance with various regulations, and Stellar provides a built-in compliance protocol to enable anchors to comply with Anti-Money Laundering (AML) laws that require these powers. However, Stellar also supports open and non-revokable issuance of assets by allowing Anchors to remove these powers over the assets they issue.

Ethereum, in accordance with its maximally general and featureless design principles has no built-in compliance mechanisms. However, various projects within the Ethereum ecosystem are developing mechanisms to support compliance with anticipated regulations around security tokens. Whether Ethereum will be the top platform for issuing security tokens has a lot to do with the security of the smart contracts that issue and manage those assets.

Smart Contract Security

Whereas most smart contract platforms come with a virtual machine that executes smart contract code written in one or more high-level languages, Stellar does not. Stellar smart contracts are just a collection of transactions constructed to work together to perform the intent of the contract. Each transaction consists of one or more predefined operations that can be executed by nodes without the need for a virtual machine. The operations in a transaction execute sequentially, atomically, and deterministically with semantics defined by the stellar-core implementation. By having no virtual machine, Stellar avoids a number of safety issues associated with the EVM.

Stellar smart contract developers can satisfy some common financial application use cases by creating transaction sets from a vocabulary of about a dozen operations and setting various constraints on accounts and transactions. For example, consider a multisignature escrow contract that allows Alice to fund an escrow account that disburses funds to Bob after some specified time and allows her to later recover the funds if Bob does not withdraw them in a timely manner. Such a contract can be created from a set of five Stellar transactions using operations that create the escrow account, fund it, set up the signers and signature weights on the escrow account, and set sequence numbers and time bounds on the disbursement and recovery transactions.

The limited set of operations and constraints available on Stellar greatly limits the types of applications and use cases that it can support compared to platforms like Ethereum, which provide general-purpose smart contract languages. However, the attack surface on such a highly constrained environment is significantly lower. The more features a language has, the more opportunities for an attacker to exploit surprising interactions of those features. Compare Stellar’s simple multisig implementation to the Solidity implementation of the Parity multisig wallet smart contract. The use cases aren’t identical, but are functionally similar enough to illustrate how attack surface increases with language features. The Solidity implementation, which was authored by Ethereum’s founder Gavin Wood and reviewed by a team of experts, has been exploited twice, resulting in large losses of funds both times.

Solidity has a long and never-ending history of vulnerabilities arising from its numerous features and surprising interactions among them. Just recently, Ethereum’s Constantinople hard fork was postponed at the 11th hour, when it was discovered that a reentrancy vulnerability would be introduced by a seemingly unrelated change to the gas cost of storage instructions. In contrast, Stellar transactions do not use gas metering and the concept of reentrancy (or even calling into another contract) does not exist.

The Etherum community has and will continue to expend a great deal of energy documenting best practices for preventing reentrancy and other Solidity vulnerabilities, but this will never be enough to overcome the massive attack surface arising from the language’s complexity. That the reentrancy vulnerability in Constantinople went undetected by the entire Ethereum community for so long suggests that Solidity is too generalized and full featured to ever be a viable language for smart contracts that control high-value assets.

Whereas Ethereum’s next generation Vyper language is aimed at improving security by making the code simpler and less likely to mislead developers and users about its behavior, this step in the right direction may not be soon or large enough. At the time of writing, the percentage of Ethereum mainnet contracts written in Vyper is almost negligible. As long as the vast majority of Ethereum contracts are written in Solidity, there will remain a large number of Ethereum contracts that are vulnerable to all the known and unknown vulnerabilities inherent in Solidity.

Stellar smart contracts take a much larger step toward safety by providing a highly constrained environment that minimizes features and thus vulnerabilities. Stellar’s thesis is that most blockchain applications don’t need the flexibility of a Turing-complete language, “they just want to issue digital assets and process transactions.” Rather than begin with maximal flexibility and evolve toward improved security, Stellar begins with maximal security and will evolve toward greater flexibility as needed.

Stellar’s laser focus on financial applications could lead them to dominate that application space and, in a scenario where blockchain applications are mostly financial, the lion’s share of the smart contracts platform space. However, in order to maintain that dominance Stellar will have to develop increasingly general features to support increasingly complex financial and non-financial applications, including scaling solutions. If Stellar does this by expanding its constrained set of operations, it will likely be unable to foresee and implement all the operations necessary to build the next killer apps/scaling solutions, and thus will slow the pace of innovation compared to platforms supporting generalized programming languages. Stellar may be able to encourage innovation on its platform by introducing a more generalized programming language or framework, but it will have to do so in a way that maintains the safety of its financial applications, i.e., by being significantly more constrained than the Solidity/EVM framework.

If confidence in Ethereum smart contracts continues to be eroded by the loss of funds due to Solidity exploits, then projects may look to build their financial applications on a platform that trades some flexibility for increased safety as Stellar does.

Conclusion

Stellar differs from Ethereum — and many of the smart contract platforms examined thus far in this series — in many ways, but faces similar challenges. For example, Stellar and Ethereum have very different consensus mechanisms, but they both currently achieve low throughput and plan to scale with sharding and layer 2 solutions. The cost to subvert consensus safety may be lower on Stellar (depending on what architecture for maintaining quorum intersection emerges), but if safety is maintained, instant finality will enable simpler and more efficient sharding than Ethereum’s checkpointed architecture. Despite having very different monetary policies, the current structure and operation of governance on each platform is roughly the same.

When it comes to smart contract security, however, Stellar and Ethereum make fundamentally different design tradeoffs, with Stellar favoring safety and Ethereum favoring general programmability. This tradeoff makes Stellar simultaneously an attractive alternative to Ethereum for deploying financial applications and no threat to Ethereum’s dominance as a generalized smart contracts platform. However, achieving dominance in financial applications could lead to network effects that enable dominance in other applications, even if innovation is slowed resulting in inferior applications. However, as Vitalik Buterin points out, innovation in non-financial blockchain applications may outpace financial ones since most can be deployed and iterated on quickly without fear of loss when they break. In a world where mostly non-financial blockchain applications flourish, Ethereum is poised to dominate.

Whereas I am critical of fully generalized smart contract programming languages such as Solidity because of the vulnerabilities and financial damages they incur, I also find it difficult to envision scaling solutions such as Plasma, generalized state channels, and sharding being implemented within the constraints of Stellar’s current smart contract framework. Although it’s likely that Stellar will expand their platform to support certain scaling solutions, the platform will not enjoy the pace of innovation that can occur in a community building on a general purpose platform such as Solidity/EVM.

Stellar, with its leadership track record, solid technology, running mainnet (since 2014), large community, and numerous partnerships and projects around the globe is currently a viable threat to disrupt Ethereum. However, it appears that its path to dominance as a smart contract platform would come through dominance of financial applications, a position which is firmly held by Ethereum at the present time. Whereas Ethereum’s stronghold may quickly unravel with the next Solidity exploit and/or governance crisis, the platform has been remarkably resilient to such events and remains the prevailing target for financial and non-financial applications.

Thanks to Nate Johnson for his input on earlier drafts of this article.

If you’d like to follow me on Twitter, I’m @edposnak

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Stellar was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at Zilliqa and the challenge it poses to today’s dominant platform, Ethereum.

Zilliqa is a smart contract platform built on a sharded blockchain that has clocked in at thousands of transactions per second (TPS). It includes a new functional language for developing smart contracts that facilitates automated formal verification of security properties. It is intended to function as an open, public blockchain for running smart contracts and thus is a direct competitor to Ethereum.

The project’s name is apparently a play on “silica” that means “Silicon for the high-throughput consensus computer.” The company was founded by a group of researchers from the National University of Singapore including Xinshu Dong (CEO), Yaoqi Jia (Head of Technology), Amrit Kumar (Head of Research), and Prateek Saxena (Chief Scientific Advisor), and others. Saxena had worked with Loi Luu (founder and CEO of Kyber Network and advisor to Zilliqa) and other researchers at NUS on the ELASTICO protocol for sharding permissionless blockchains. The ELASTICO paper would serve as the basis for Zilliqa’s sharding technology.

Zilliqa incorporated in Singaport on June 1, 2017. By September 1 the team had launched its first testnet (v0.1), and on October 12 announced that the testnet (v0.5) had achieved a peak throughput of 2,488 transactions/sec. On December 1 the testnet (v1.0) was opened to the public, and in January 2018 the code was open sourced. Zilliqa raised about 20 million USD in private funding in the Fall of 2017, and then raised another 2 million USD during the one week (December 27, 2017 to January 4, 2018) ICO for its ZIL token.

Zilliqa directed some of its funding toward creating the #BuildonZIL Ecosystem Grant Programme to support teams and developers building on its platform. On August 14, 2018 the company announced its first round of grants to fund a wide range of projects to develop wallets, libraries, developer tools, and applications. Zilliqa is also the platform being used in Project Proton, a joint initiative to assess the viability of blockchain technology to bring transparency and accountability to programmatic advertising. The launch of Project Proton’s first phase was recently announced. Presumably, a number of the #BuildonZIL projects will launch with Zilliqa’s mainnet release, which should occur sometime in the winter of 2018-2019.

Will 2019 be the year Zilliqa’s high throughput smart contract platform makes a big disruptive splash? Or will it be the year that scaling advances in Ethereum magnify its network effects and move it into an even more dominant position? Will another high profile Solidity hack create a community crisis sending smart contract developers heading towards safer platforms? No one can know for sure, but an in-depth look at the technology being developed on these two platforms should give us some clues. This article will take a closer look at the scalability and smart contract security of the Ethereum and Zilliqa projects.

Scalability

The most recent benchmarks run on Zilliqa’s (v1.0) testnet demonstrated a throughput of 2000–3000 TPS. Zilliqa achieves this two orders of magnitude increase over Ethereum through sharding, a base layer scaling solution that increases throughput by allowing transactions to be processed in parallel. Without sharding, all mining nodes in the network must validate every transaction added to the blockchain, creating a throughput bottleneck. With sharding, the mining nodes are partitioned into groups, called shards, that are only responsible for validating the subset of transactions that have been allocated to their shard. This allows transactions on different shards to be processed in parallel, increasing transaction throughput.

In theory, demand for higher transaction throughput can be met by simply adding new shards and increasing parallelism. This ability to increase capacity with demand is known as linear scaling. In practice, linear scaling can be realized for simple transfers of funds from account to account, but difficult to achieve for smart contract transactions that need to manage state across shards because of the parallel slowdown that can occur due to the overhead of cross-shard communication and state synchronization.

The plan for both Zilliqa and Ethereum is to first implement basic transaction sharding (i.e. simple payments within shards) and then tackle the much more difficult problem of state sharding (i.e. arbitrary state changes that must be kept consistent across shards) in later phases. The remainder of this section will be broken into two parts, with the first covering the latest implementations of transaction sharding in both projects and the second discussing the research and approach each is taking to address state sharding.

Transaction Sharding

In Zilliqa’s first, payment only implementation, each transaction is assigned to a shard based on the rightmost bits of the sending account’s address. For example, in a network of 16 shards numbered (in hex) 0…f, the last hex digit of the sender’s account would identify the shard a transaction is assigned to.

Assigning all transactions originating from the same account to a single shard is the simplest and most efficient way of preventing double spends in a sharded blockchain. All shards can run in parallel since miners don’t have to worry about a potentially conflicting spend being mined on another shard. An account can receive funds on any shard, but can only spend them on their assigned shard and only after the receiving transaction has been immutably hashed into a final block on the main chain. Below is a diagram illustrating how this process works.

Zilliqa’s sharding implementation consists of two consensus layers. At the bottom layer, miners in the individual shards create micro blocks of the transactions assigned to their shard. The header and signature of each micro block is sent to a Directory Services (DS) committee at the top layer, which aggregates the headers into final blocks that make up the global ledger for the system.

For simple transaction sharding the DS committee does not process the individual transactions, just the micro block headers. Doing otherwise would eliminate the benefits of parallel processing and defeat the whole purpose of sharding. The DS committee assumes that the lower layer consensus process has correctly validated all transactions in its micro blocks. Thus secure shards are key to overall system security.

To reach consensus on blocks, Zilliqa employs a Byzcoin-inspired, optimized version of the Practical Byzantine Fault Tolerance (PBFT) protocol that achieves about 415 TPS per shard. The primary optimization is to replace message authentication codes with aggregated Schnorr signatures. This greatly reduces the number of messages required to reach consensus (from quadratic to linear in the number of nodes) and makes it practical to implement shards with hundreds of miners.

A nice property of PBFT that greatly simplifies the sharding implementation is instant finality. Once consensus on a micro block is achieved, the block can be immediately processed by the DS committee without having to wait for confirmations since chain reorganization in the shard is impossible.

The safety and liveness of the PBFT protocol requires more than 2/3 honest nodes in each shard and some bounds on message delivery time (i.e. partial synchrony of the network). Achieving this in an open, public network where anyone can participate in consensus requires some defense against Sybil attacks, in which an attacker can subvert consensus by creating a large number of nodes.

To deter Sybil attacks, Zilliqa requires each node to generate a proof of work (PoW) before it can participate in either the DS or shard consensus process. PoW is not used to qualify each block produced (as in Ethereum), but only to qualify nodes to participate in a consensus process. Once a node has qualified for participation it can generate blocks as fast as possible without having to perform PoW again until it needs to re-qualify (much like the Bitcoin-NG algorithm used in æternity). This allows the protocol to achieve high transaction throughput with a low energy footprint.

The PoW algorithm used by Zilliqa is Ethash, Ethereum’s PoW algorithm. Ethash is designed to be ASIC-resistant; however, Bitmain is currently shipping an Ethash ASIC miner that could be used to mine Zilliqa. Whereas the first generation miners were marginally more efficient than GPU rigs, the next generation will likely deliver significant gains in energy efficiency that could lead to centralization of mining power. Zilliqa has an opportunity to avoid this issue (at least for a while) by choosing a different memory hard algorithm for which no ASIC currently exists.

Ethereum is slowly evolving toward a sharded version of its blockchain. The latest Ethereum 2.0 spec describes a two-tiered system that has architectural similarities to Zilliqa’s (see the figure below).

Much like Zilliqa, Ethereum has a number of shards on which blocks of transactions are produced in parallel by committees of validators randomly assigned to the shard. Signed hashes of the shard blocks are mined into Beacon blocks on the Proof of Stake (PoS) Beacon Chain. The Beacon Chain functions much like a combination of Zilliqa’s DS committee and Main Chain, aggregating shard blocks as well as managing the assignment, rotation, and financial incentives of validators. Ethereum’s PoW mined main chain (Legacy Chain) plays a very small role, accepting validator deposits and transferring them to the Beacon Chain. The “Legacy Chain” moniker now being used reinforces that Ethereum is following Vitalik’s proposal for moving to full PoS in which the PoS Beacon Chain ultimately replaces the PoW Legacy Chain as Ethereum’s main chain.

The validators assigned to a shard can act as Proposers, who produce shard blocks, or Attesters, who vote for blocks. Each Attester vote is signed and serves as an attestation to the existence and validity of a shard block and a corresponding block on the Beacon Chain. Attestations from a quorum of validators create crosslinks, which finalize checkpoints on the Beacon Chain and the individual shard chains. These checkpoints can be used to enable safe cross-shard communication (see State Sharding below).

Consensus and finalization of blocks is achieved using a modified version of Casper FFG (described here and here) that is (accountably) safe and (plausibly) live provided there is an honest majority of validators. If an attacker controls 1/3 to 1/2 of validator stake then safety depends on partial synchrony assumptions and above 1/2 the attacker can revert recent (non-checkpointed) blocks. Although it assumes no bounds on message transmission delay, the Ethereum 2.0 spec requires each validator’s clock to be synchronized with all others in order to process blocks in fixed 8 or 16 second slots.

The throughput of Ethereum 2.0 with 1024 shards has been estimated at 13,410 TPS. This is a theoretical number that doesn’t take into account that throughput slows down when transactions must synchronize across shards, and the number of transactions requiring cross-shard synchronization increases with the number of shards. The next section looks at why this cross-shard synchronization is a necessary and challenging aspect of implementing smart contracts on sharded architectures.

State Sharding

Throughput estimates and benchmarked measurements can show very high theoretical transaction rates when they are based on simple payment transactions, which are highly parallelizable. However, when smart contracts are involved, practical throughput is significantly lower because parallelization is not as simple as just assigning the transaction to a shard based on the sending account’s address.

Consider a simple contract that allows users to reserve a seat on a train by sending a payment to the contract. If Alice’s account address and Bob’s account address map to different shards and each issues a transaction to reserve a seat, the two transactions cannot run independently in parallel on different shards because the state of the contract, i.e. the number of reserved/available seats, creates a dependency among the transactions. If there is only one seat left, and Alice’s transaction succeeds in reserving it, then Bob’s transaction must fail because there are no seats left. One might consider assigning such transactions to a single shard based on the contract address (and somehow deal with potential double spends from Alice and Bob, for example by requiring them to generate and pay with addresses that map to the contract’s shard) but this strategy breaks down whenever two or more contracts (whose addresses don’t coincidentally map to the same shard) are involved.

A wide variety of transactions do more than one thing involving more than one contract and/or more than one user’s account. For example, a simple ERC20 token exchange will involve updating state on two separate ERC20 contracts for both buyer and seller. The balances to be updated map to buyer and seller accounts whose addresses, and thus assigned shards, aren’t easily changed, and the contracts are deployed by independent organizations with little incentive to coordinate their contract addresses.

Transactions that span multiple shards are unavoidable. Thus a viable sharding solution must provide a secure and efficient cross-shard communication mechanism. The Ethereum community has developed such a mechanism that involves breaking the transaction into two transactions that run sequentially on different shards. When the first transaction is mined on its shard a receipt is created that can be used by the second transaction to prove to miners on its shard that the first transaction executed. Once the second transaction is mined, the receipt is considered “spent” so no other transaction can use it.

This split transaction mechanism is referred to in the Ethereum community as asynchronous cross-shard communication because the mining of each transaction into a block happens independently. There is no bound on the amount of time it will take for the second transaction to be mined once the first transaction has been mined or even any guarantee that it ever will. This presents a practical issue for transactions that make dependent state changes, such as an ERC20 exchange transaction. If Alice and Bob are swapping tokens it’s a poor user experience for Alice to have the tokens in her account for an unbounded period of time before Bob has his, and unacceptable for Alice to receive Bob’s tokens without Bob ever receiving hers.

One proposal for addressing this atomicity issue is contract yanking, wherein one ERC20 contract’s state is frozen and temporarily “yanked” over to the shard where the other ERC20 contract resides. There both contract states are updated atomically and the yanked contract’s updated state is returned to its shard and unfrozen. This solution also leverages receipts to move the contracts across shards and thus has some latency issues that could keep a contract frozen for an impractical amount of time.

The Holy-Grail solution is what the Ethereum community calls synchronous cross-shard communication. Ideally transactions spanning multiple shards would get executed at the same block height across all shards involved. This is especially challenging to accomplish on Ethereum, since any one of the involved shards could undergo a chain reorganization (Zilliqa’s PBFT consensus does not fork). A couple of proposals (involving state execution engines and chain fibers) have surfaced but a working solution still appears to be a long ways off.

The state of sharding development in Ethereum appears to be somewhere between phase 0 and phase 1 on the sharding roadmap. However, at the EthBerlin hackathon in early September a team of developers, including Casper Researcher Vlad Zamfir, created a milestone proof of concept for asynchronous cross-shard communication. According to Zamfir, the implementation “prevents finalization of cross-shard atomicity failure, so it will never be that a send is finalized and a not received is finalized.” Whereas finalized checkpoints enable this safety guarantee, relying on them introduces an additional latency between the time the send and receive are finalized on their respective shards.

The instant finality of blocks in Zilliqa prevents forking and provides an opportunity to significantly reduce and tightly bound the latency of safe cross-shard communication. Zilliqa’s approach to the problem is described in this blog post, which is also an excellent exposition on the challenges of implementing smart contracts on a sharded blockchain. Zilliqa’s proposed solution categorizes transactions into three types: (I) simple payments between two users, (II) simple transactions where a single user interacts with a single smart contract that does not transfer funds to another user nor call another smart contract, and (III) all other transactions involving smart contracts. All category I and the subset of category II transactions where the user’s address and smart contract address map to the same shard can be validated on the shard; all other Category II and III transactions must be processed by the DS committee on the main chain.

As the proportion of transactions that must be processed serially by the DS committee increases, parallelism decreases and the overall transaction throughput approaches that of the main chain. Metaphorically, if a six lane highway requires certain types of vehicles to stay in a single lane, then the extent to which it experiences a traffic jam will depend on how many vehicles are assigned to that lane. Zilliqa’s analysis estimating the percentage of serial vs parallel transactions omits all Category III transactions involving multiple contracts or multiple users, 100% of which would need to be processed serially on the main chain. I believe that many typical transactions will fall under this category and omitting them from the analysis paints an overly optimistic picture of the throughput Zilliqa will achieve in practice.

It will be interesting to see what TPS numbers Zilliqa achieves when running real smart contract transactions on an operational mainnet. If things go according to Zilliqa’s plan, this will occur before Ethereum smart contracts are running on shards, so there could be some period of time during which Zilliqa’s platform offers a higher throughput base layer than Ethereum. However, scalability — the degree to which throughput can be increased by adding new shards — will depend on the implementation of cross-shard communication mechanisms that don’t become major bottlenecks as the number of shards increases. Zilliqa will likely need some innovative mechanism to overcome its current cross-shard communication bottleneck and deliver on its promise of linear scaling. If it does, the significant reduction in cross-shard latency that instant finality brings can make Zilliqa a better target than Ethereum for certain classes of latency-sensitive applications.

Smart Contract Security

As a first generation smart contracts platform, Ethereum has revealed the practical challenges in developing secure smart contracts. Even the most experienced developers following the best security practices have deployed contracts with exploitable bugs that resulted in loss of users’ funds. In the wake of these hacks debate has ensued between those advocating for some governance action (often a hard fork) to restore lost funds and those who are opposed to arbitrary bail outs and/or wishing to prevent a community split. Indeed, a community split over this very issue is what led to the creation of the Ethereum Classic fork.

Ethereum is still in the early stages of defining government processes to address such issues, and until it does the community’s general (and perhaps majority) opposition to bailouts suggests that lost funds will not restored. In the absence of a governance process the community must take a preventive, rather than reactive approach, to securing users’ funds.

Several projects within the Ethereum community are addressing this issue by developing code analysis tools and safer programming languages including the proprietary Axlang and SolidityX languages and the open source Vyper language. Vyper is designed to improve security by making the code simpler (easier to audit) and less likely to mislead developers and users about its behavior. As such it is non-Turing complete, decidable, strongly typed, and intentionally omits several features that can result in surprising and thus vulnerable code. Vyper is currently in beta, and not yet widely used to develop smart contracts on the Ethereum mainnet.

Zilliqa’s approach to smart contract security was likely informed by the work of its Lead Language Designer, Ilya Sergey, and Chief Scientific Advisor, Prateek Saxena, on MAIAN. MAIAN is a static code analysis tool that finds bugs that allow EVM smart contracts to lock funds indefinitely, leak them to arbitrary users, or be killed by unauthorized users. To prevent those types of bugs, Sergey and other researchers from Zilliqa/NUS developed Scilla, a functional, strongly typed, non-Turing complete programming language that is being used to develop safer smart contracts on the Zilliqa platform.

Scilla is designed to facilitate formal verification of smart contract programs. Formal verification doesn’t guarantee that a smart contract is free of bugs, but it can be used to develop proofs that a contract cannot violate certain specified security properties. Such proofs can give a contract’s users confidence that their funds cannot be stolen or frozen due to vulnerabilities in the code.

To facilitate construction of proofs, Scilla makes a few key design tradeoffs. It is designed to be an intermediate-level language, onto which more expressive and developer friendly languages (including Solidity) can be compiled. It follows functional programming paradigm by clearly separating purely functional computation from state-modifying actions, which are always made explicit in the code. Finally, it requires all contracts to be structured as communicating automata. In this structure programs are defined as a set of state transitions that are triggered by incoming messages with all interactions between contracts occurring at well-defined boundaries within the code.

Scilla smart contracts are written as a set of transitions, which are like functions in most other languages except that all calls to other contracts can only be executed as the transition’s final step. This restriction allows formal verification tools to assert how the state of the contract will change during a single transition without having to worry about an external call causing arbitrary state changes (e.g. by calling back into the calling contract). This enables the detection and prevention of a certain class of reentrancy vulnerabilities, including the one exploited in the DAO hack.

Most smart contracts can (and should) be written in this so-called tail-call programming style. The Scilla whitepaper originally described a method of using continuations — blocks of code that are invoked by the execution environment when an external call completes — to translate non-tail-call contract code from existing contracts into Scilla’s communicating automata form. However, the Zilliqa team has informed me that continuations are no longer part of the language, so existing contracts would need to be rewritten in tail call style before being compiled to Scilla.

It’s still possible to develop reentrant code in Scilla, but vulnerabilities due to reentrancy are less likely because tail call style makes the developer (and verifier) explicitly aware of what state changes are happening at any given point in the program. Looping constructs are implemented via recursive function definitions so their termination can be proved statically. To address recursive loops that could exhaust resources Zilliqa implements structural recursion on lists and requires transactions to pay gas like Ethereum.

Although Scilla is still under development and tooling around it needs to be developed, its focus on simplicity and formal verification will make it a solid building block upon which safer smart contracts can be built. While Ethereum is also moving in this direction, the evolution has been slow and thousands of contracts deployed on the platform remain vulnerable. As we’ve seen with the DAO and Parity hacks, high profile exploits can be highly disruptive to the community, though surviving them makes the platform stronger and safer going forward. To date, one reason Ethereum has survived these events is the lack of a safer alternative. At some point, when high level languages and tooling built on Scilla exist, Zilliqa may be able to provide that alternative.

Conclusion

Zilliqa is a project that grew out of research at NUS and that research continues as the project addresses some of the major challenges that Ethereum faces concerning scalability and smart contract security.

Both projects are addressing base layer scalability with sharding and doing so with roughly similar architectures and road maps. The easy problem, transaction sharding, has been solved and one can expect implementations from both projects to be deployed in 2019. Zilliqa has an advantage in starting from scratch without the burden of supporting a PoW main chain holding billions of USD in assets. Ethereum is minimizing this disadvantage by reducing the role of the “legacy” main chain and building on a pure PoS beacon chain, which should ultimately replace the main chain. The estimated and benchmarked throughput on these initial implementations will be promising — in the thousands of TPS — but mostly meaningless in the context of a general purpose smart contract platform.

Scaling throughput while supporting non-trivial smart contracts presents challenges that neither project can claim to have solved at this point. Both are in the early stages of their roadmaps to becoming a fully sharded smart contract platform. The latest research from both projects suggests that the subsequent phase of deployments will provide some form of cross-shard communication that comes with new scaling challenges. State sharding is a solved problem, but scalable, decentralized, state sharding is not.

A key contrasting factor — that Ethereum’s blockchain forks and Zilliqa’s doesn’t — will likely result in the respective projects taking different approaches to state sharding with different tradeoffs. Based on current proposals it appears Ethereum’s approach will trade off latency for greater parallelization/scalability than Zilliqa’s, which creates a scalability bottleneck by requiring all non-trivial transactions be executed on the main chain. This may result in certain applications being better suited to one platform or the other, but longer term one can expect both platforms will continue to research innovations that enable fast, safe, and scalable support for a wide range of applications.

As a project under development Zilliqa has the advantage of taking what’s good from Ethereum’s smart contract platform and improving on the rest. The researchers at Zilliqa have applied the lessons learned in building and deploying Ethereum contracts to design a language that prioritizes safety and simplicity over expressivity. The result is an intermediate programming language that supports formal verification and can serve as a compilation target for higher level languages.

If Zilliqa can deliver a practically useful development environment (high level languages, compilers, static analysis tools, etc.) before Ethereum evolves to Vyper or some other safer language, it will present a viable and attractive alternative to Solidity. Until then the Solidity development community will be forced to accept exploits and loss of funds as a fact of life that must be tolerated because nothing better exists. When a safer alternative does exist however, projects will be financially incentivized to build on it.

The Achilles’ Heel of Ethereum might not be scalability, but the inertia of Solidity’s monopolistic success creating a general complacency toward addressing the problem that split the community once and, despite lessons learned, continues to do so.

Zilliqa’s preventive vs reactive approach to smart contract vulnerabilities may reduce the amount and complexity of governance structures required to maintain cohesion in a growing community. Even if vulnerabilities can be prevented to the extent that “code is law” becomes a viable policy, some governance mechanisms will still be needed to decide on software upgrades and parameter changes that are necessary for a platform to evolve and incorporate new innovations. Zilliqa’s governance strategy (not covered here due to lack of public information) will play an important role in attracting projects away from Ethereum and other smart contract platforms trying out various governance strategies.

Zilliqa has some major challenges to address if it is to become a high-throughput, scalable, smart contract platform. If it can address these and at the same time provide a demonstrably safer alternative to Solidity, with a functional governance process, then it may present a challenge to Ethereum’s dominance. Otherwise, it may end up being just a high-throughput simple payment network that does not compete in the smart contract space. It will be interesting to watch this project evolve through its main net launch and beyond.

Thanks to Amrit Kumar and Nate Johnson for their input on earlier drafts of this article.

If you’d like to follow me on Twitter, I’m @edposnak

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Zilliqa was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at æternity and the ways it could supplant today’s dominant platform, Ethereum.

æternity is a decentralized, trustless smart contracts platform that is designed to provide better scalability, governance, smart contract security, privacy, and access to real world data than Ethereum. The project shares many similarities with Ethereum, including a Proof of Work (PoW) blockchain and support for Solidity contracts running on an EVM-compatible virtual machine. In contrast to Ethereum, which is featureless by design, æternity has opted to include certain features in the platform as “first class objects” to simplify the development of decentralized applications (dApps, or æpps in æternity lingo).

The æternity platform is written in Erlang, a concurrent, functional language that is designed for 0% downtime. Erlang provides built-in support for hot code loading, which allows new features and bug fixes to be deployed while the system is running. The æternity core development team consists of several Erlang developers, many of whom came to the project by way of a partnership with the Erlang Solutions consultancy.

The æternity project was founded in Liechtenstein in late 2016 by Yanislav Malahov. Malahov had been working to build more generalized functionality on top of Bitcoin for many years, having, in 2013, collaborated with a teenage Vitalik Buterin on the colored coins-based Keidom project, now known as ascribe.io. In January 2017 Malahov and coauthors Zack Hess and Jack Petterson published the original æternity white paper, which describes some of the early goals and ideas for the project (though much has since changed).

From April to June 2017 æternity ran a successful token sale raising 224,750 ETH and 1456 BTC (worth roughly 50 million USD at the time of completion). Just weeks later æternity had the misfortune of being one of three wallets drained by an attacker exploiting a vulnerability in the Parity Multisig wallet. As a result, æternity lost 82000 ETH, nearly 40% of the total raised.

In the second half of 2017, two coauthors of the original white paper, lead developer Hess and smart contract language guru Petterson, left the æternity project. A second white paper titled “æternity Reimagined” was started by then CTO Joel Reymont, but was soon abandoned when Reymont also left the project in November 2017. Despite these setbacks, æternity managed to launch its Epoch testnet in Dec 2017 and has continuously been updating the testnet with new features since. A full-featured mainnet launch is currently scheduled for August 2018.

In May 2018 æternity announced the launch of æternity Starfleet, a project incubator providing resources and support to blockchain projects that will likely be building applications on the æternity platform. Shortly thereafter æternity released a two part list of 17 projects selected for participation in the first wave of Starfleet incubation. Many of these projects are based in Sofia Bulgaria, where Starfleet’s cooperating partners æternity Ventures and Software University are based.

Although the project does not yet have a running mainnet or an up-to-date white paper, many of æternity’s ideas are in the process of being fleshed out on their Epoch testnet. There is enough documentation about these ideas to compare æternity’s design to that of Ethereum and assess the threat æternity poses to Ethereum’s dominance. Let’s see how they match up.

Scalability

Scalability is a well-known problem with Ethereum, and nearly every platform we’ve looked at in this series is looking to scale transaction throughput at the blockchain layer with some type of Proof of Stake (PoS) based consensus algorithm. In contrast, æternity implements a Proof of Work (PoW) based consensus protocol and is primarily focused on scaling with layer 2 solutions.

æternity’s PoW is based on the Cuckoo Cycle algorithm, a memory bound puzzle, which is believed to be ASIC-resistant. This means that the algorithm is designed with a memory bottleneck so that running it on an Application Specific Integrated Circuit (ASIC) does not provide a significant efficiency gain over a CPU or GPU, so that anyone with general purpose hardware, such as a mobile phone, can participate in the consensus process.

The æternity vision of users mining on their mobile phones was set back when cryptocurrency mining on iPhones was banned by Apple. Nonetheless, æternity’s PoW algorithm might be closer to realizing Satoshi’s egalitarian vision of “one-CPU-one-vote” than Ethereum’s. The EthHash algorithm used in Ethereum was also believed to be ASIC-resistant, but Bitmain has recently announced an Ethash ASIC miner, which will begin shipping in late July. The impact these miners will have is uncertain, but they will not (as some have claimed) be rendered obsolete by the upcoming deployment of Casper the Friendly Finality Gadget or reduction of the block reward.

Ethereum improves base layer scalability by having a relatively high block frequency (about 240 blocks/hour vs 12 in æternity). More blocks per hour equates to more transactions per second, but also more temporary forks and stale blocks. Stale blocks are valid blocks which, due to another valid block being found at the same time, do not end up in the main chain and thus do not contribute to network security and provide no reward for their miners. When such races occur block rewards more often go to better-connected miners, which, over time, economically weeds out less equipped miners and increases miner centralization. To prevent this Ethereum implements a variant of the Greedy Heaviest Observed Subtree (GHOST) rule, which rewards miners of stale blocks.

Although æternity’s Reimagined white paper describes using GHOST to improve transaction throughput, this no longer appears to be on the project’s development roadmap. Instead, æternity is employing Bitcoin-NG to scale the base layer. Bitcoin-NG obviates the need for GHOST because, even though the average time between blocks remains relatively long, Bitcoin-NG allows additional transactions to be processed during this time. The miner who finds a solution to the Cuckoo Cycle puzzle earns the right to produce a key block with their solution and then can continue producing microblocks with additional transactions until the next miner solves the puzzle and earns the right to do the same. The protocol includes a fee sharing mechanism to incentivize miners to build on the longest chain of microblocks rather than serialize existing microblock transactions into their own microblocks.

Since æternity will be deploying the world’s first Bitcoin-NG on PoW implementation, one can only speculate on the performance gains it will bring. However, based on measurements of the Waves-NG (Bitcoin-NG on PoS) implementation, we can estimate that æternity with Bitcoin-NG will have about an order of magnitude more base layer capacity than Ethereum’s non-sharded PoW implementation. However, once its first phase sharding implementation is deployed, Ethereum’s base layer capacity should increase by at least two orders of magnitude.

Layer 2 solutions are a key component of both projects’ scaling roadmaps. State channels, which scale throughput by executing most transactions off chain, are one of æternity’s built-in first class objects. State channels are a generalized form of payment channels (e.g. Lightning Network), that allow off-chain transfer of not just payments but arbitrary application state (e.g. wagers and cards in a poker game, moves and state of a chess board, etc.). For parties that interact repeatedly (e.g. playing several games of poker) state channels provide a huge boost to transaction throughput because nearly all interactions occur in off-chain transactions. There are additional benefits to participants in that off-chain transactions are nearly instant, free of gas costs, and private to the parties involved.

To use a state channel, interacting parties must initially deposit funds in a smart contract on the main chain, after which they can update state (including balances) through a series of off-chain signed transactions, and finally close out the channel by posting the last transaction with the final balances to the smart contract. The smart contract dispenses the funds to participants after some time period in which challenges may be made. Recent transactions invalidate previous ones, so if one party tries to close out with an earlier state, the other party can simply post the final state to ensure the correct payouts. Since there is a limited time for users to do this, each party must watch the blockchain for any fraudulent closing transactions.

Whereas state channels will be built-in to the æternity platform, they are not included with Ethereum. However, the Ethereum Foundation is funding L4’s research on state channels, which has produced an excellent white paper on the subject, and several third party implementations of state channels are currently being developed. State channel development exemplifies the difference between Ethereum’s featureless platform philosophy and æternity’s thesis that providing built-in features simplifies development, allowing developers to focus on their application. Whereas the early developers of state channel applications on Ethereum may have borne some hardship by having to roll their own implementations, it’s likely that open source versions of state channels will ultimately give Ethereum dApp developers as much leverage as æternity æpp developers will have. An open source defacto standard implementation on Ethereum could emerge before æternity’s mainnet goes live with built-in state channels that support the same use cases.

State channels are not the ideal solution for scaling every type of dApp. They work best when a small number of participants repeatedly transact with each other. Altcoin.io investigated using state channels to build a high speed digital currency exchange, but found Plasma, a layer 2 scaling solution based on “baby” chains, to be more suitable for maintaining state among a large number of interacting participants. Whereas built-in state channels will provide a scalability boost from day one, æternity will likely need to incorporate other solutions to cover use cases less suitable for state channels.

Governance

Lead developer Sascha Hanse once described æternity as “a platform enabling decentralised and trustless applications, with a strong focus on governance.” Indeed, on-chain governance is another feature baked in to the æternity platform. æternity proposes to use on-chain, stake based voting to decide on protocol improvements, which can range from simple parameter changes (block size, frequency, rewards, etc.) to new feature implementations. The built-in mechanism will allow users to make proposals for software upgrades and vote on them using their stake (balance of AE tokens). Votes are weighted by the amount of stake, and users may delegate their voting stake to (presumably) more knowledgeable voters to vote on their behalf.

Like many other platforms we’ve looked at, æternity’s design is based on the belief that the less formal governance processes employed by Bitcoin and Ethereum would be improved by a more formal, on-chain governance mechanism. Indeed Bitcoin’s notorious block size debate and Ethereum’s DAO fork controversy both resulted in community splits and forked chains with thriving new currencies. Whereas the specific governance issues that fractured these communities were different, the solutions are essentially the same: getting users to agree to run compatible software that doesn’t create a fork, even when doing so is not their preference. Although æternity’s marketing team may have created some confusion by describing their platform as implementing hybrid PoW/PoS consensus, this illustrates their view that governance is essentially a separate but related consensus layer. In æternity PoW consensus is used to get nodes to agree on the order of transactions and PoS consensus (i.e. stake based voting) is used to get community participants to agree on the PoW consensus rules.

The general viability of on-chain governance is the subject of much debate. A core belief underpinning on-chain governance is that users will be more likely to go along with a decision they oppose if they believe that it was decided by a legitimate and ostensibly fair process in which all parties in the ecosystem have a say. There is empirical evidence from the real world that democratic governance systems tend to have relatively low fork rates even in the face of strong idealogical differences. However, forking a nation tends to be vastly more difficult and and expensive than forking blockchains. Still, there is a common belief among many smart contract platform designers that some formalized process will be better than none at keeping a community together and preserving the integrity of the platform’s base currency. After all, smart contract platforms do seem ideal for enabling transparent and tamper-proof electronic voting, and software upgrades are easily automated. But smart contracts also provide mechanisms that make it easier for cartels to coordinate to buy elections and automated deployments effectively neuter the voting power of node operators, who are, according to Vlad Zamfir, an “absolutely necessary” pillar of blockchain governance. Arguments against on-chain governance from Ethereum’s thought leaders have led the Ethereum community toward a more multi-faceted and less automated approach to the problem.

At present, Ethereum’s approach seems to be evolving and working relatively well. In the wake of the Parity multisig library self-destruct exploit that froze over 500,000 ETH, and the community’s rejection of various proposals to unfreeze the funds, Parity restated their commitment to keeping the community together. Whereas affected users were not made whole, damage to the greater community was minimized. Contrast this to the notoriety EOS received for the events that occurred in the first week of the platform’s existence, when the EOS Core Arbitration Forum issued multiple “Emergency Measure of Protection Orders” to freeze several presumed malicious accounts without justification. These and other problems faced by early deployments, such as cartel control of the Lisk platform indicate that significant innovation will be needed to develop a viable on-chain governance solution. Until a viable solution is deployed, one could say Ethereum’s is the worst form of government, except for all the others.

Smart Contract Security

The root cause of Ethereum’s community split and its more recent controversy over unfreezing funds is the same: exploit of Solidity code resulting in loss of funds. It seems there would be less contentious debate about how to recover funds if Ethereum smart contracts were not so easily and often exploited.

Progress on this front continues to be slow and steady in the Ethereum community. Based on lessons learned from Solidity contracts, a new smart contract language called Vyper has been developed. Vyper is a strongly typed, non-Turing complete language designed with security and auditability in mind. It does not contain many of the language constructs (e.g. function modifiers, inheritance, inline assembly, etc.) that can be misleading to developers and auditors and thus eliminates entire classes of vulnerabilities. A beta version of Vyper was recently released and it is being used in the development of a new decentralized exchange for ERC20 tokens.

The æternity project plans to support three different smart contract environments that each serve a different purpose.

The first environment is Solidity running on an EVM-compatible virtual machine called the Æternity Ethereum Virtual Machine (AEVM). This environment allows existing Solidity smart contracts to run on æternity unmodified, making it easy for contract authors to migrate to æternity with minimal friction and preserving their investment in Solidity code and expertise. The AEVM improves on the EVM by adding a safe self-destruct mechanism that prevents destruction of libaries actively in use, a feature which would have prevented the libary self-destruct vulnerability that allowed over 500,000 ETH in 587 instances of Parity’s multisig wallet to be frozen. Whereas this feature addresses one specific, well-known security issue, Solidity has so many more that this environment should be considered as insecure as Solidity running on Ethereum’s EVM.

For contracts requiring greater security, æternity has developed a second environment that uses the Sophia programming language and Functional Typed Warded Virtual Machine (FTWVM). Sophia is a strongly typed functional programming language (a dialect of ML) that has restricted mutable state. These properties make it easier to automatically prove properties of the contract code and, like Vyper, are intended to make it maximally difficult to write misleading code. Sophia also includes a rich set of blockchain specific primitives and types, as well as standard mechanisms to interface to oracles, which are another built-in feature of the platform. The FTWVM is also designed for improved security by supporting functional languages, strong typing, and being warded (i.e. preventing overflow/underflow of arithmetic operations). It will be interesting to see how this environment compares to Vyper running on the EVM in terms of safety and programmability. Of course, by providing an EVM-compatible environment, æternity can immediately adopt Vyper (and later port it to FTWVM) if it turns out to be safer or more popular with developers.

The third smart contracts environment is aimed at eliminating the issues around decidability of contract code that introduce complexity such as gas metering. This environment consists of a restricted non-Turing complete scripting language called Varna and a very simple VM called High Level Machine (HLM). Varna is a primitive, Bitcoin Script-like language that contains no loops and so can execute within a predictable, bounded number of steps. For basic use cases (e.g. simple multisig functionality) Varna/HML will enable the development of “blindingly fast and cheap contracts with a known cost”.

To further assist developers and users æternity is also building a set of core æpps that provide foundational functionality such as account management, currency activation, app launching, and more. Built-in support for oracles, which æternity claims will be more flexible and universal than those currently being built on Ethereum, may enable a wider range of applications to be built on æternity. At a minimum, having a standard, built-in mechanism for oracle interaction simplifies the developer’s life by allowing them to focus on their application, rather than having to set up and integrate with a third-party oracle. This omakase approach to framework design was fundamental to the power and popularity of the Ruby on Rails web development platform. A key to Rails’s success, which æternity would be wise to emulate, is the ability and willingness to swap out the default components as better technologies come along.

Conclusion

The æternity project aims to provide a full featured platform that includes a number of built-in components (oracles, naming system, state channels, on-chain governance) to provide a better experience for developers and users of the system. This design philosophy is opposite that of Ethereum, which intentionally minimizes built-in features to allow innovation to come from the broader community. Remaining featureless has worked well for Ethereum because it has such a large and vibrant community. Given the current size of æternity’s community, providing key features might be the best approach to attracting developers and users to the platform near term. As the community grows and innovation flourishes, æternity could evolve to incorporate innovations coming from outside its core team.

Of all the platforms we’ve looked at so far, æternity plans to deliver the most complete set of smart contract environments, each optimized for specific classes of use cases. By providing an EVM-compatible environment, æternity should be able to support any application that can be built on Ethereum, leverage innovations coming from the Ethereum community, and minimize friction in deploying Ethereum dApps on æternity. Whereas there is essentially no security improvement in deploying on another Solidity/EVM environment, if æternity’s other environments and features bring developers and users to its platform, then the cost/benefit ratio might compel Ethereum dApp owners to do so.

There is still a lot of work to be done before these features are delivered and æternity is in position to challenge Ethereum. While that work is being done by æternity’s team of developers, innovation on layer 2 scaling solutions, oracles, prediction markets, and developer tooling in the Ethereum community continues unabated. Until æternity’s smart contract environments and features are deployed on a live mainnet with contracts securing significant value, we won’t really know whether and to what extent æternity will become a viable and/or compelling alternative to Ethereum. It will be interesting to see how things progress once æternity launches its mainnet later this year.

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of æternity was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at how Waves could challenge today’s dominant platform, Ethereum.

The Waves Platform aims to address some key limitations of existing blockchains in the areas of scalability and user experience. It implements a Proof of Stake (PoS) flavor of Bitcoin-NG’s scaling solution and provides some novel mechanisms, such as integrated fiat gateways, token launcher, and decentralized exchange, that greatly simplify the process of issuing and trading custom tokens. Waves is applying its user-focused philosophy to roll out smart contract functionality, starting with a limited and possibly more secure offering that could provide a compelling alternative to Ethereum’s.

The Waves Platform was founded in early 2016 by a theoretical physicist Sasha Ivanov, whose appreciation for gravitational waves reportedly inspired the name. The project’s philosophical and technical roots come from the Nxtblockchain project, upon which Ivanov had built decentralized businesses such as Coinomat, which was launched in 2013. Ivanov saw potential in Nxt’s innovative and powerful features but, frustrated by the platform’s limitations and the project’s direction, he decided to create the Waves platform to better serve the needs of businesses building and operating decentralized applications.

Waves held an ICO that ran from April — June of 2016 and raised 30,094 Bitcoins. At the time, this was equivalent to about $16 million USD, making Waves the third largest crowdfunded cryptocurrency project behind Ethereum and The Dao. After the completion of the ICO, Waves was able to quickly launch its mainnet by leveraging ideas and code from multiple projects including Nxt, Scorex, SuperNet/Komodo, and BitShares. A large development budget enabled Waves to quickly roll out important UX and scalability features, such as an integrated decentralized exchange, gateways to support the trading of external fiat and blockchain currencies, and an implementation of the Bitcoin-NG protocol.

At the end of 2017, Waves announced the launch of Waves Lab incubator to provide advice, expertise, and resources to projects wishing to build on Waves. These developments have attracted dozens of projects from a wide range of industries and countries to launch on the Waves platform. At the time of writing Waves is the second most popular platform next to Ethereum for hosting ICO tokens.

Waves recently announced its first phase support of smart contacts, which will provide built-in support for the most common use-cases to make deploying them simpler and more secure than rolling your own. The next phase will support all possible use cases by implementing Turing-complete smart contracts. With this strategy Waves could become the preferred platform for issuing custom tokens and ultimately challenge Ethereum to become the dominant platform for all smart contract use cases. To get a better sense of how this might happen let’s take a closer look at how Waves technology compares to that of Ethereum.

Scalability

Waves once claimed to be the “fastest decentralized blockchain” platform in the world. This claim was based on a stress test of the Waves testnet in which an average throughput of 33 tx/sec and a peak throughput 283 tx/sec was measured. From this data, Waves extrapolated an expected throughput of 100 tx/sec, which is anywhere from 8–14 times the current capacity of Ethereum’s non-sharded, Proof of Work (PoW) implementation.

Waves, like most platforms we’ve looked at thus far in this series, implements a PoS consensus algorithm in which all stakeholders can participate and earn rewards, but block production is handled by a small subset of stakeholders who are able to consistently stay online to process transactions and blocks. However, the set of Waves block producers isn’t elected by vote, as in delegated Proof of Stake (DPoS) systems, but through a stake leasing system called Leased Proof of Stake (LPoS).

LPoS effectively serves the same purpose as PoW mining pools, allowing users with a small stake (and thus a small probability of winning the right to produce a block) to pool funds and share profits, so that payouts are more consistent overtime. Instead of contributing hash power to the pool, users lease WAVES tokens to full nodes (analogous to a mining pool operators) that do the work of validating transactions and maintaining the ledger. Participation in consensus is open to any full node that has at least 1000 WAVES (currently about 6K USD) leased to it. The node gets selected to produce blocks with a probability proportional to its total leased stake, and earns transaction fees which it normally shares with its lessors.

Unlike Ethereum’s Casper, where deposits are locked up, in Waves leased funds can be spent or leased to a different node at any time. The Waves Lite Client allows users to lease their WAVES balances to full nodes with two clicks, and terminate these leases just as easily. Once funds are leased they begin earning rewards after 1000 blocks (about 16 hours). The ability to easily redirect one’s stake toward any node that wishes to mine can help address the issues of voter apathy and cartel formation common to many DPoS systems, where a fixed number of delegates are elected by user votes and hold tenure between voting cycles.

Much like PoW consensus, Waves miners earn the right to produce blocks by broadcasting a solution to a cryptographic puzzle, but instead of expending energy constructing billions of solutions, they periodically perform a very small amount of computation to check if they are eligible to produce a block at the current time. Unlike some PoS systems where every time interval is associated with a block producer, in Waves LPoS a long and variable time may pass before some node becomes eligible and produces a block. During this time transaction serialization is indefinitely paused, resulting in a relatively low transaction throughput (on par with PoW systems).

To address this, Waves has implemented the Bitcoin-NG protocol for scaling. Bitcoin-NG allows transactions to be continuously serialized throughout the long and variable periods of leader selection. The miner who finds a solution to a cryptographic puzzle produces a single key block, which contains their qualifying solution. This grants the miner the right to extend that block with a sequence of microblocks that serialize additional transactions and earn the miner transaction fees until a new leader emerges by publishing a valid key block on the latest microblock. To incentivize miners to build key blocks on the longest chain of microblocks rather than serialize existing microblock transactions into their own microblocks, Bitcoin-NG splits the transaction fees in a chain of microblocks between the miner that produces it (40%) and the miner that builds on it (60%).

Concerns have been raised about certain protocol deviations not being properly disincentivized in Bitcoin-NG because the production of microblocks is relatively free (in terms of electricity in PoW systems). However, since Waves-NG is a PoS system without deposit slashing, all block production is cheap, and protocol deviations are disincentivized only by the threat of losing transaction fee revenue. The PoS implementation that Waves inherited from NXT is vulnerable to multibranching attacks such as the nothing at stake problem.

In June 2018, Waves is planning to activate a new and improved PoS implementation that makes these kinds of attacks less effective. Rather than introduce major changes like requiring miner deposits, the Waves team is trying to improve their current PoS algorithm with a few simple changes that they hope will sufficiently disincentivize these attacks.

For years Ethereum has been planning to implement a pure PoS consensus algorithm that is highly resilient against such attacks and would likely increase transaction throughput. However, with over 70 billion USD in assets at risk, evolution toward that goal has been necessarily slow and cautious. The first small step in gaining experience with PoS on Ethereum will come with the deployment of Casper The Friendly Finality Gadget, which provides a PoS layer on top of PoW consensus and no increase in transaction throughput.

The more immediate performance boost for Ethereum will likely come from sharding. Despite a recent change in direction, the design for sharding is now “well-established” according to Vitalik Buterin, who pointed to the existence of proof of concept code as evidence that sharding is nearing deployment. The first phase rollout of sharding is slated to add 100 additional high capacity chains to the Ethereum mainnet, which would increase on-chain throughput by at least 100x. So, when sharding goes live on the Ethereum mainnet, Ethereum will most likely surpass Waves in transaction throughput, despite using PoW to secure the main chain. For now Waves maintains a distinct advantage of having a live mainnet capable of processing an order of magnitude more transactions per second than Ethereum’s.

Another scaling solution that may come to Ethereum even sooner than sharding is Plasma. Plasma is a specification for adding high capacity baby chains that are secured by smart contracts on the main chain. Practical implementations, such as Plasma Cash are being developed and launched. One interesting implementation is Altcoin’s use of Plasma to develop a high speed, decentralized exchange for cryptocurrency tokens. If this project or one like it succeeds, it could narrow or eliminate a key advantage Waves currently holds over Ethereum, which is providing an integrated, low cost, high speed token exchange with fiat onramps.

Decentralized Exchange

One of the novel features of the Waves platform is a built-in decentralized exchange (DEX) that supports direct swaps of custom tokens issued on the platform. It is designed to provide the speed of a centralized exchange with the security of a decentralized exchange. Specifically, this means orders are matched with the same speed and efficiency of centralized exchange, but the exchange never has custody of the tokens, avoiding the creation of the kind of honeypot that attracts hacks to centralized exchanges.

This is achieved by combining a centralized Matcher with decentralized settlement on the blockchain. Users who wish to exchange tokens submit signed limit orders to the Matcher, who maintains an order book. When the Matcher finds pairs of orders that satisfy each other’s limits (e.g. Alice will purchase 1000 XRP for at most 1.1 ETH and Bob will purchase 1 ETH for at most 1100 XRP) it combines them into a settlement transaction that it submits to the blockchain. Settlement is not executed in smart contracts (as in Ethereum), but the token swap is performed by executing the built-in Exchange Transaction. Having support for token exchange integrated into the protocol layer makes the settlement process more efficient and cheaper to execute than through a series of smart contracts at the application layer.

Having a centralized Matcher addresses some common problems related to race conditions that occur in decentralized exchanges on Ethereum. Although Waves is designed to allow for multiple matchers, every order must specify a specific Matcher, which eliminates race conditions by ensuring that only one Matcher can successfully execute an Exchange Transaction containing that order. I was unable to find any documentation on how Waves plans to thwart denial of service attacks on Matchers.

With multiple Matchers maintaining exclusive order books, practical liquidity issues can arise. A single Matcher that maintains a book of all orders in the system would be able to perform optimal order matching and create the most efficient market. Conversely, if liquidity is fragmented across the order books of several Matchers, market efficiency is reduced, and can result in degraded user experience and price volatility that can wreak havoc on crowdfunded projects. The Liquidity Wave and BlackBot projects are aimed at adding liquidity and reducing price volatility in the DEX, but guaranteeing liquidity for tokens post ICO remains an issue for Waves.

Liquidity is also a practical concern for ERC20 tokens traded through Ethereum’s myriad of decentralized exchanges and protocols. The Bancor project has developed a novel approach to adding liquidity using smart contracts to act as counterparty to buyers and sellers, adjusting prices based on demand. The viability of Bancor’s implementation has been questioned, but Bancor has become one of the most heavily used DEXs on Ethereum. Bancor currently handles more than 4x the volume of the Waves DEX.

Today, decentralized exchanges account for just a small fraction of overall trade volume, which is dominated by centralized exchanges. The first implementations are experiencing a variety of problems, but the technology is evolving rapidly due to a tremendous amount of desire to realize a viable system. High speed DEX’s built on Plasma chains and layer 2 payment channels are just a couple of examples of innovation happening in the Ethereum ecosystem right now.

Ethereum’s choice to be a featureless platform has made the development of a viable DEX more difficult than it is on Waves, where token exchange is an inexpensive built-in feature. However, this choice also enabled unfettered innovation by an unlimited number of competing and cooperating projects. If the decentralized exchange of tokens turns out to be the next killer blockchain app, then the platform that provides the first adequate solution could attract a significant number of investors and token issuers and ultimately benefit from the network effects that Ethereum currently enjoys.

Governance

Like many of the projects covered in the series, Waves touts decentralized voting as a feature of its platform. Despite being slated for a Q1 2018 delivery in the Waves Roadmap, very little public information about this or any governance feature of Waves currently exists.

In October 2017, Waves announced its participation in a collaborative effort to create a blockchain-based voting system, based on the concept of liquid democracy. The system would allow voters to cast votes directly or delegate their votes to others on an issue-by-issue basis. No subsequent information on this project appears to have been made public.

We’ll defer an in-depth comparison of Ethereum’s governance model with Waves’ to a future article when more information about Waves governance is available.

Smart Contract Security

If you’ve read any of the previous articles in this series, you already know that Ethereum’s dominance is threatened by the poor security of its smart contracts. The DAO and Parity wallet are evidence of a systematic problem: the deficiencies of the Solidity programming language that make it unsafe for smart contract programming. For a more detailed explanation, please see this expanded treatment of the subject.

The Waves approach to smart contracts appears to be a step forward in terms of smart contract security. The first phase release will provide a highly constrained scripting language that, similar to Bitcoin’s scripting language, provides a limited set of operations for constructing simple predicates that can be efficiently evaluated to determine whether or not a transaction is valid. This language is powerful enough to support many common use cases without the complexity of gas metering or the broad attack surface of a Turing complete language such as Solidity. Waves is planning to build into its client the ability to configure and deploy pre-built smart contract implementations for most popular use cases without having to write code.

One key use case that can be supported is multisig wallets. If developing this functionality with a highly constrained scripting language results in a vulnerability-free implementation that can deployed with a few clicks, this could provide a significant advantage for Waves over Ethereum. Consider the damage caused by the Solidity implementation of the popular Parity multisig wallet. Despite being implemented by a highly respected team of developers following a rigorous code review process, the Solidity code contained vulnerabilities that resulted in theft and freezing of ETH worth hundreds of millions of USD. The ongoing debate on whether and how to unfreeze those funds is as contentious as the one that resulted a permanent Ethereum community split. Such are the wide-ranging effects of using a language that is too complex for the job at hand.

The Ethereum community is working to improve the current situation by developing new, more constrained programming languages such as Bamboo, Vyper, Flint, and Pyramid-scheme that allow compilers and other analysis tools to catch a wider class of vulnerabilities before they get deployed. Although Solidity is currently the leading smart contracts language on Ethereum, it is likely that safer languages will start to gain adoption soon. Additional high profile attacks on Solidity contracts could speed this process and/or cause users to look to other platforms for safer smart contracts.

The Waves first phase smart contract implementation was launched on the Waves testnet on April 28, 2018. This deployment will allow users to experience an easier to use and lower cost option for common smart contract use cases. However, until smart contracts are deployed to the Waves mainnet (scheduled for July 2018) with real money at stake, we won’t really know for sure the extent to which security is improved by the Waves approach.

Conclusion

The Waves project contrasts itself to Ethereum by its focus on mass adoption in two specific areas that it claims are “very ripe for disruption”: crowdfunding and fiat transfers. As such the platform’s design is heavily focused on making the issuance and trading of custom tokens as easy as possible. The Waves platform includes a built-in Token Launcher that allows users with no programming experience to create and issue custom tokens that can be traded immediately on an integrated decentralized exchange. In addition to its built-in DEX, Waves supports token exchange by providing numerous fiat and cryptocurrency gateways that allow users to move these external assets in and out of Waves with less friction. By focusing development efforts on meeting the specific needs of crowdfunding projects, Waves already provides a compelling offering that has made it the second most popular platform for issuing tokens.

Although the Waves mainnet currently does not support smart contracts, the first phase implementation on the testnet indicates that basic smart contract functionality will likely be available on the mainnet by July as planned. Despite its limited capability, the simpler scripting language will allow Waves to add some key pieces of functionality including a secure multisig wallet and ERC20 gateways to enable trading of Ethereum’s ERC20 tokens in the Waves DEX. These could be the missing pieces that allow Waves to threaten Ethereum’s dominance as a crowdfunding platform. If Waves can provide a secure multisig wallet that adequately protects funds before Ethereum can, it will attract crowdfunding projects that don’t want to risk losing their funds due to Solidity vulnerabilities (i.e. all crowdfunding projects).

Crowdfunding is arguably the killer app for Ethereum at present, and a platform that provides a better user experience (including not losing funds) has a good shot at disrupting the network effects Ethereum currently enjoys as the number one ICO platform. Even though Waves lags Ethereum in many important ways and will face numerous challenges as it grows, its focus on crowdfunding and approach to smart contracts represent a clearly visible path to disruption. However, until smart contract functionality is being used on the Waves mainnet, its ability to provide a more secure, easier to use, less expensive offering remains unproven. If and when that does happen the level of threat it poses to Ethereum will likely rise. For now Waves remains a solid challenger, with promising and possibly disruptive innovations.

Thanks to @kimbimlim for input on early drafts. Thanks to David Bleznak for enlightening discussions about decentralized exchanges and liquidity.

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Waves was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at how Qtum could challenge today’s dominant platform, Ethereum.

Qtum (pronounced Quantum) is a smart contracts platform designed to be Ethereum-compatible while addressing some perceived deficiencies of Ethereum such as scalability, lack of formal verification tooling, and lack of lite mobile solutions using simple payment verification (SPV). Qtum addresses these issues with a different underlying blockchain and consensus algorithm that Qtum believes will enable the platform to provide better support for lightweight mobile and Internet of Things (IoT) applications. The project aspires to become the “public blockchain for business” by bringing its technology to financial services, supply chain management, social media, gaming, and other industries in the future. By positioning itself as an Ethereum-compatible platform with several improvements, Qtum is directly competing with Ethereum to become the dominant smart contracts platform.

Qtum was founded in 2016 by Patrick Dai (AKA Steven Dai), Jordan Earls, and Neil Mahi. Their ICO, held in March 2017, raised approximately 15.6 million USD in just five days. The funds are managed by the Singapore-based Qtum Foundation, whose stated functions are to “oversee the development of the Qtum blockchain, to advocate governance transparency, and promote the safety and harmony of the open source ecosystem.” The Foundation and development team have quickly and consistently achieved delivery milestones. In June, 2017, just three months after the ICO, Qtum launched its first testnet, Sparknet, and followed with the deployment of a second, upgraded testnet, Skynet, two months later. On September 13, 2017 Qtum’s Ignition mainnet officially went live.

One of the reasons for Qtum’s fast track to launch is that, rather than building an entirely new blockchain from scratch, Qtum integrated open source code from the Bitcoin, Ethereum, and Blackcoin projects. Qtum is essentially an Ethereum-based smart contracts system running on top of a Bitcoin-based blockchain using a modified version Blackcoin’s Proof of Stake (PoS) implementation for consensus. Qtum has added a custom adaptation layer that maps Ethereum account balances to sets of Bitcoin Unspent Transaction Outputs (UTXOs).

This integration of existing systems has resulted in Qtum becoming the world’s first proof of stake smart contracts platform based on the UTXO transaction model. Qtum also became the first blockchain in space when the Singapore-based SpaceChain launched a satellite running a Qtum full node. At the time of writing, there were 25 decentralized applications (dApps) running in various stages (such as demo, prototype, live, and stealth) on the Qtum mainnet and about 5K transactions per day were being processed. Although Qtum is off to an impressive start, it still has a long way to go to catch up with Ethereum, which currently supports over 1000 dApps and processes about 700K transactions per day.

The remainder of this article will look in depth at Qtum’s technology and how it compares to Ethereum’s to illuminate how Qtum could pose a challenge to Ethereum’s position of dominance in the decentralized application space.

Performance

A common theme for improving on-chain transaction throughput among Ethereum challengers is replacing Proof of Work (PoW) with a faster PoS consensus mechanism, and Qtum is no exception. In keeping with the project’s apparent philosophy to not reinvent the wheel, Qtum chose to reuse an existing PoS algorithm from the Blackcoin project.

Unlike many of the Ethereum challengers we’ve looked at so far, Qtum’s PoS doesn’t use delegates or depend on voting; anyone staking QTUM can produce a block. This makes Qtum’s implementation even more inclusive than Ethereum’s plan for CASPER, since there is no minimum amount required to stake. However, a downside is that Qtum’s implementation has some of the same scaling limitations as Bitcoin’s PoW implementation.

Qtum’s PoS consensus works much like Bitcoin’s PoW consensus in that the right to produce a block is granted to the first staker who can produce a hash that is below a target threshold. This threshold gets lower (increasing the difficulty) as the power of the network increases, so that rate of block production remains relatively constant. The probability that any given staker will win the right to produce a block is proportional to the percentage of total network power they possess.

However, in Qtum, power is not determined by the number of hashes per second a staker can perform, but by the amount of QTUM they have staked. Rather than perform billions of hashes over slightly different inputs trying to find one below a fixed threshold, Qtum stakers perform one hash per UTXO they control over a fixed input (only the UTXO changes) to see whether or not the result falls below a weighted threshold. The threshold is weighted for each hash by the amount held in the UTXO being hashed so that UTXOs with higher amounts have a proportionally higher chance to win. If a winning hash is produced, the user broadcasts their block; if not, they simply stop hashing and wait for the next chance to play.

Every 16 seconds the fixed input changes, creating a new opportunity for stakers to generate new hash values for their UTXOs and see if any are winners. This is analagous to holding a lottery every 16 seconds, where each computed hash represents a weighted ticket. Each UTXO corresponds one unique ticket per lottery, and weighting ensures that splitting a high value UTXO into several smaller value ones will get you more tickets but not increase your chance of winning. The difficulty is set such that most lotteries do not have winners and a winning ticket is found only once every 128 seconds on average. Any lottery can produce multiple winning tickets and, as in Bitcoin, all rewards go to one winner while the rest get nothing.

An important consequence of adopting Bitcoin’s competitive winner-take-all lottery model is Qtum’s target block time for PoS must remain relatively high to keep the probability of multiple simultaneous winners very low. Otherwise, the competition results in too many forks and stale blocks. Producers of stale blocks are lottery winners that lose because they staked but received nothing. These races provide an unfair advantage to the most powerful and well-connected stakers that disincentivizes others from staking and ultimately leads to concentration of block rewards in the hands of a few stakers. Ethereum’s target block times are 10x faster than Qtum’s because when such races occur the block rewards are shared more fairly among the simultaneous winners, incentivizing them to keep mining. Faster block times equate to higher transaction throughput. By adopting Bitcoin’s consensus model for its PoS implementation, Qtum inherited Bitcoin’s primary scaling bottleneck and will struggle to achieve the transaction througput possible with other forms PoS.

Scalability

One of the primary changes Qtum makes to Ethereum is to implement account balances using UTXOs on a Bitcoin blockchain. Qtum’s choice to use Bitcoin core software was primarily driven by the network effects of being compatible with what they consider to be “the most mature, stable and secure blockchain” and leveraging all the benefits of innovation in a thriving ecosystem. However, the Qtum white paper also suggests some scaling benefit, “we consider the Ethereum account model to be a scalability bottleneck and see clear advantages of the Bitcoin-network UTXO model.”

The scalability benefit relates to the difference in how spending of an account balance works using Bitcoin’s stateless UTXOs vs Ethereum’s state-based balances. Transactions in both systems have inputs, which name sources of funds to be spent, and outputs, which name destinations of funds to be credited. In Bitcoin, transaction inputs point to UTXOs that named the spender as the destination of funds in some previously mined transaction. UTXOs are analogous to notes and coins that have accumulated in your pocket from previous transactions. Each has a specific value and when you spend them you might get some change back if, as often occurs, the sum of their values comes to more than the exact amount owed. In Ethereum, spending works more like a debit card where the transaction input is just the spender’s account, the output is the receiver’s account, and an exact amount is always transferred (i.e. no need for change). An account’s balance is stored as a single number that is updated in the blockchain whenever a transaction naming the account as input or output is mined. Transactions are ordered so that the balance available to each transaction is consistent and can be used to prevent overdrawing/double spending.

To see how this works in practice, let’s say Alice possesses four UTXOs in amounts 18, 16, 9, and 7, and she wants to send 20 to Bob. Her Bitcoin transaction could use the 16 and 7 UTXOs as inputs. Since the sum of the inputs is 23, the transaction would have an output of 20 to Bob and a second output of 3 to Alice (for change). Alice’s spending capability would be decreased by the two now-spent TXOs totalling 23 and increased by the one new UTXO for 3, resulting in a net of change of -20. Similarly, Bob’s spending capability would be increased by the one new UTXO for 20. In Ethereum, if Alice has a balance of 50 and wants to send 20 to Bob, she would just create a transaction specifying her account as an input, Bob’s account as output, and an amount of 20. Running the transaction would update the state of both accounts to show Alice’s balance is now 30 and Bob’s 20.[1]

Whereas Ethereum’s debit card model is simpler to implement, it has a scalability limitation in that all transactions involving an account must be executed and validated in a deterministic order, so that the initial account balance for each transaction is consistent across all nodes executing the transaction. The UTXO transaction model allows transactions involving the same account but not spending the same UTXOs to be run in parallel. In our Bitcoin example, Alice could send one transaction spending two of her four UTXOs (as above) and another spending the other two UTXOs, and because the transactions have no dependencies they could be processed in parallel without concerns for overdraft/double spending. In theory, this allows Qtum nodes to process more transactions per second by using multiple CPU cores to simultaneously process transactions that would otherwise need to be executed sequentially on Ethereum.

How much of a performance gain can be practically realized from the UTXO model will depend on how many opportunities to exploit parallelism exist. Since transaction outputs must be fully spent or not at all, it’s sometimes not possible to find mutually exclusive sets of UTXOs to create parallel spending transactions even when sufficient funds exist. For example, if Alice’s account controlled only two UTXOs in amounts 43 and 7, then it would be impossible to parallelize any two transactions spending more than 7. In such cases, Alice must use the change UTXO from one transaction as input to the other, thereby serializing the transactions and losing any scaling benefit.

Vitalik Buterin has pointed out that many Bitcoin wallet implementations fail to make the optimizations necessary to enable parallelization, effectively minimizing the benefits in practice. In a response to that very point, Qtum Founder Jordan Earls wrote: “This is fair, however, you should notice that Bitcoin does not encourage this optimization he said in any manner. […] Qtum doesn’t have a simple answer to this, but there is more to parallizability than parallel execution on the blockchain.” Earls goes on to describe a situation where offline wallets can generate parallel transactions using carefully assigned UTXOs, which essentially is just a manual implementation of the optimization that would only allow for parallelization if the wallets were synchronized to come on line and send their transactions simultaneously.

A key advantage of the UTXO model touted by Qtum is that, by enabling the use of Bitcoin’s Simplified Payment Verification (SPV) scheme, the platform can support a wider range of light client applications on mobile and IoT devices. Client applications using SPV can transact without having to download the entire blockchain or trust a centralized server. They can efficiently query the network for specific transactions they care about and can verify for themselves whether the responses they get are valid based on their own determination of the canonical block chain.

Whereas adoption of the UTXO model allowed Qtum to leverage existing implementations of SPV, it did not create any significant advantage for Qtum over Ethereum. Ethereum research on light client protocols suggests that UTXOs aren’t necessary to build clients light enough to run on mobile and IoT devices. Unlike Qtum’s SPV light clients, which are limited to transfers of the QTUM token, Ethereum light clients can track arbitrary state changes such as the transfer of ERC20 tokens. At the time of writing the Light Ethereum Subprotocol and Parity Light Protocol are fully specified and have been integrated into multiple Ethereum clients (in experimental mode). If/when the need for completely trustless light client applications arises, these protocols will enable such applications to be built on Ethereum.

Both Qtum and Ethereum are looking to leverage layer 2 protocols for massive scaling of transaction throughput. Qtum’s adoption of Bitcoin’s UTXO-based blockchain enables it to leverage existing implementations of the Lightening Network. The Lightening Network scales transaction throughput by allowing a large number of payments to be made off chain via payment channels, which are secured by a single on-chain funding transaction. As with SPV, the implementation is limited to payments using only the native QTUM token. Ethereum’s Raiden Network, a self-proclaimed work in progress, will someday enable the use of off-chain payment channels to transfer arbitrary ERC20 tokens.

Both Lightening and Raiden implement a single application, the trustless offchain transfer of payment. Generalized State Channels in Ethereum have been developed to enable the off-chain operation of any application, allowing multiple applications to leverage the same funding transaction. Each application has its own smart contract that encodes the rules of engagement over application-specific contract state (e.g. moves in a game of chess, determining the winner of a bet, etc.). The contract is not actually deployed to the blockchain, but participants act as if it was because each participant holds a copy signed by all parties that can be deployed if necessary to resolve a dispute. This is similar to how payment channels are settled, except instead of sending a signed agreement on channel balances to the blockchain, a signed agreement on application state and a contract that interprets that state to enact arbitrary state changes (payouts, awards, statistics, etc.) is sent. Currently, Ethereum lacks mature tooling and frameworks for building applications on Generalized State Channels, but these are being developed and there is at least one implementation that is slated to go live on the Ethereum mainnet in April 2018. By supporting Solidity smart contracts, Qtum will likely be able to leverage these implementations as they are deployed on Ethereum.

Governance

Like many of the Ethereum challengers we’ve looked at so far, Qtum aims to overcome perceived governance challenges in Bitcoin and Ethereum with an on-chain governance mechanism, which they call the Decentralized Governance Protocol (DGP). The specific issues DGP is designed to address include the Bitcoin community’s gridlock over a block size parameter and Ethereum’s hard forks adjusting gas prices to prevent Denial of Service (DoS) attacks.

DGP automates updating blockchain parameters, such as block size or gas price, without forking or requiring users to download new software. The intent isn’t to completely eradicate the need for forks, which, according to Qtum, would be necessary for significant changes or new features. However, automating cryptoeconomic parameter changes via DGP could allow Qtum to respond more quickly to DoS attacks and speed the pace of innovation by avoiding community gridlock in some cases.

The governance process is run by a set of governing parties, who may be people or smart contracts. The governing parties submit proposals to change network parameters. The proposals are stored in a standard, machine readable format such that the Qtum software can incorporate them in an automated fashion. If a proposal receives enough on-chain votes from governing parties, then the proposal becomes active in the current version of software without requiring users to download and run a new version.

Qtum will initially launch with a set of “trusted” people acting as governing parties. However, Qtum expects to outgrow this structure quickly, and outlines a scenario where the governing parties could vote on a “meta-proposal” to replace them with a two bodies, board members and core developers, that would both need to approve a proposal before it can be enacted. Qtum claims that DGP “is powerful enough that its governance structure can be completely replaced” through such meta-proposals, while at the same time emphasizing the system’s narrow focus on protocol parameter changes. It seems unlikely that fundamental changes such as replacing the underlying structure of the DGP could be automated by the DGP itself without some amount of off-chain coordination within the community.

Qtum envisions a scenario in which smart contracts can serve as governing parties. A simple smart contract could be used to incorporate votes from stakers and other users. A more complicated smart contract could monitor the network and generate proposals for parameter changes in response to certain conditions, such as too many full blocks. According to Qtum, such contracts would enable the blockchain to be “self-regulating, self-modifying, and self-aware.” Imagine a self-aware Bitcoin network that proposes a block size increase whenever it detects the past 10,000 blocks are 90% full. This is Qtum’s vision of the future of blockchain govenernance.

Whereas having a formalized mechanism for enacting changes can be useful, the key challenge of governance is to enact only the changes that are agreed upon by a sufficiently large majority of users. Determining what constitutes a sufficiently large majority is not straightforward and can depend on the situation. Both Ethereum and Bitcoin have experienced community splits over governance decisions that were supported by a significant majority of the community, resulting in the creation of the Ethereum Classic and Bitcoin Cash blockchains. Automation of upgrades may be useful for non-contentious changes, but when there is even a small amount of contention, automation of community splits may not be the best approach.

Automated community splits and other hazards of a “self-modifying” blockchain could be prevented, in theory, by the votes of governing party seats that are still held by people. However, this theory raises several important questions. Who are the people in governing party seats? How were they elected? Do they represent the wishes of the larger community? How easy is it to replace them when they don’t? At the time of writing specific answers regarding Qtum’s governing parties could not be found online. It’s reasonable to assume that, like most nascent blockchains, the governing parties will initially be appointed and later elected by some kind of vote involving community members. There are, however, numerous challenges with on-chain voting systems that would need to be overcome.

The problems with on-chain governance and coin holder voting have been discussed at length in thought pieces by Ethereum thought leaders Vitalik Buterin and Vlad Zamfir. Getting enough user interest and participation to ensure that votes are representative of the whole community is always a challenge. Representative democracy can give a small cartel of governing parties too much power to change the rules in their favor. The inevitability of cartel formation in a delegated on-chain governance system isn’t just theoretical; it has manifested as a real world problem for the Lisk community and vote buying continues to plague EOS.

The question of whether on-chain governance can work and in what form(s) remains open and is an important facet of the evolution of smart contract platforms. Much like real world governance, it seems we will learn slowly by trial and error. Whereas Ethereum may not have found a silver bullet solution to governance, they certainly have looked carefully at the various on-chain mechanisms being proposed and have thus far avoided falling into the traps of existing naive implementations.

Smart Contract Security

Smart contract security is the area in which Ethereum’s dominance is most vulnerable to disruption. Continued high profile attacks costing users hundreds of millions of USD are a sure path to extinction. In July, 2017 a popular Ethereum smart contract used in nearly 600 wallets to protect more than 500k ETH was exploited, resulting in the theft of over 150k ETH. A postmortem from the contract’s developer, Parity Technologies, outlined an extensive list of things Parity would do to ensure this wouldn’t happen again. Less than four months later, a second attack on the new and improved version of the contract froze all the ETH and other tokens held in all of the wallets using it.

It’s not that this one contract was uniquely buggy or its developers especially reckless. On the contrary, the contract was entrusted with a large amount of funds largely due to Parity’s reputation for smart contract expertise. Parity Technologies founder and CTO Gavin Wood, is one of the primary developers of both Ethereum and the Solidity smart contract language. The pedigree of Party Technologies team, the level of effort they devoted to securing the contract after the first hack, and the fact that thousands of other deployed Solidity contracts exhibit similar vulnerabilities suggest there is a more fundamental and systematic problem at play.

The common thread in the Parity wallet hacks as well as the famous DAO hack, which ultimately led to an Ethereum community split, was the ability for an attacker to call methods in ways the contract authors didn’t intend. These vulnerabilities arise commonly in Solidity code due to fundamental flaws in the language that make the behavior of, for example, reentrant and delegated methods surprising to developers. When significant funds are at stake, all potential suprises will be tested and any vulnerability exploited.

By being fully EVM compatible and supporting Solidity contracts Qtum inherits all of Ethereum’s smart contract security weaknesses. However, this compatibility does afford Qtum the opportunity to leverage all the innovation in the Ethereum community aimed at addressing them. There is currently a vibrant ecosystem of projects aimed at developing better code analysis tools as well as new, programming, languages that are more suitable for formal verification and static analysis that can detect bugs at the compilation stage. If, despite these efforts, users continue to experience Solidity exploits in which their funds aren’t successfully rescued by white hat hackers or returned by contentious hard forks, they may leave Ethereum, but they won’t be flocking to Qtum for its Solidity and EVM compatibility.

Qtum does plan to extend their smart contracts offering to include an x86 virtual machine that would enable the development of smart contracts in languages such as C++, Java, and Haskell. While this would allow Qtum projects to tap into a wider base of developers and leverage existing tooling, it doesn’t specifically address the security issues inherent to Solidity’s design. In fact, each new general purpose language supported comes with news ways to surprise developers and introduce vulnerabilities into smart contracts. Qtum founder and CTO Joran Earls identifies features such as “cooperative-multitasking, pause and resume execution (ie, resuming execution in a later transaction), and watchdog timers” as improvements the x86 VM could bring to Qtum smart contracts. These are among the most difficult programming constructs for developers to reason about, and would likely expand the attack surface of contracts that use them. Whereas some general purpose languages (e.g. Haskell) will be better suited to meeting the stringent security requirements for smart contract programming, others (e.g. C++) will be more unsuitable than Solidity for smart contracts managing valuable assets.

The Qtum white paper states that it is Qtum’s objective to develop a Qtum Smart-Contract Language (QSCL) that is claimed to be “backed by formal verification means.” No details are provided other than a reference to an academic paper from one of the white paper authors describing another language, developed by that same author, defining a “cross-organizational collaboration ontology.” Given the lack of information available about QSCL, it appears that Qtum has not and is not pursuing this initiative.

Conclusion

Qtum has made rapid progress by integrating the source code from multiple open source projects. They have successfully deployed a working blockchain based on Bitcoin UTXOs and Blackcoin PoS consensus that supports smart contracts compiled for the EVM. A handful of dApps are running in production on Qtum, and a Qtum node is running on a satellite orbiting the earth. Still, it is difficult to envision a scenario in which Qtum unseats Ethereum as the dominant smart contracts platform. Whereas EVM compatibility significantly lowers the cost of switching from Ethereum to Qtum, dApp developers still need some motivation to do so.

If users were to become spooked by continued high profile exploits of Solidity code they would most likely switch to platforms such as Cardano and Tezos that provide languages designed specifically to meet the security needs of smart contract programming. In such a scenario, Qtum’s offering of Solidity plus general purpose languages not designed for smart contract programming would be no less spooky than Ethereum’s.

If Ethereum’s scaling solutions such as sharding, plasma, and state channels don’t come soon enough to handle growing user demand, applications would likely move to platforms such as DFINITY and EOS offering significantly higher on chain througput from PoS implementations that provide synchronous, high frequency block production. Qtum’s PoS implementation, in which block times follow a Poisson distribution and need to be kept at low frequency, won’t be able to come close the throughput of those platforms without greatly sacrificing decentralization. If the Lightening Network succeeds on Bitcoin, why would it be used on Qtum? It wouldn’t be for Qtum’s smart contract capability because Lightening only provides a throughput increase for transactions that send simple payments in the platform’s native token, not the execution of arbitrary smart contract code.

If a large number of users decide to leave Ethereum over governance concerns, they would likely switch to an EVM-compatible platform such as DFINITY, whose on-chain governance model puts voting power in the hands of all users. Qtum’s DGP, which concentrates power in the hands of a few governing parties, would, even if it implemented user voting, likely face the same problems experienced by other platforms employing on-chain representative democracy without a solid plan to unseat cartels.

Qtum’s compatibility play may increase its chances of survival through coevolution with Bitcoin and Ethereum, but it also lessens Qtum’s chances for disruption. Unseating Ethereum as incumbent would require some disruptive innovation in scalability, governance, security or other aspect that is important enough to users that they would leave Ethereum for Qtum. At present Qtum’s technology has no such innovation, and the project does not seem to have any on the horizon.

[1] for simplicity, transaction fees are ignored in these examples

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Qtum was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at how Lisk could challenge the dominant platform, Ethereum.

Lisk evolved out of the now defunct Crypti blockchain project. On January 30, 2016 community manager Max Kordek and developer Oliver Beddows announced that they were leaving the project to create Lisk from a fork of the Crypti code. The new, fully open source, project would feature several improvements to the network, applications, ecosystem, and project management that would make Lisk more viable and sustainable. A few weeks after the initial announcement, Lisk conducted a four week long ICO that raised over 14,000 Bitcoin plus about 1000 Crypti. Crypti was accepted to provide “an escape route to a fresh project for the whole Crypti community.”

On May 24th 2016, just five months after the project announcement, the Lisk mainnet was launched, enabling investors to acquire and trade the native LSK token on exchanges. Kordek and Beddows then created the Zug based, non-profit Lisk Foundation to manage those funds, and the Berlin based for-profit Lightcurve to provide software and community development services to the foundation. On February 20, 2018 Lisk held a Relaunch Event to announce the completion of software development milestones, launch the Lisk Academy for blockchain education, and showcase a new product suite, website, logo, and brand identity for Lisk.

Lisk is the first project in this series that is actually not a smart contract platform. It is a blockchain application platform in which smart contract execution is an optional add-on service. The Lisk blockchain does not store application code, as is normally done with smart contract platforms, but supports a primitive (but extensible) set of predefined transaction types. While this architecture is significantly different from other projects that we’ve looked at in this series, Lisk is worth studying because the project is competing to become the global platform for decentralized applications (dApps).

Although Lisk already has a running blockchain, the project is significantly less mature than Ethereum. The blockchain application SDK, a key component that facilitates building decentralized applications on Lisk, was slated for release in 2017, but that release has been delayed due to unexpected architectural and code quality issues requiring rewrites of several key subsystems. Nonetheless, there is enough documentation on Lisk’s basic design to compare it to Ethereum.

This article will examine the technologies of both projects to assess whether Lisk can supplant Ethereum as dominant platform (and whether this series of articles will need to be renamed “On the Origin of Decentralized Application Platforms”). Let’s dive in.

Performance

A key performance advantage that Lisk currently has over Ethereum is that it uses Proof of Stake (PoS) consensus algorithm rather than Proof of Work (PoW). In PoS consensus, a node is granted the right to produce a block probabilistically based on the number of tokens it has staked, rather than by winning a race to solve computationally difficult puzzle, as in PoW. Since PoS nodes don’t burn computational resources solving puzzles, blocks can be produced at very tight, fixed intervals and significantly more transactions per second can be processed by relatively inexpensive nodes.

In PoW, attempting to increase throughput by increasing block size or shortening the average time between blocks (by reducing the puzzle difficulty) increases the probability of stales. Stales are valid blocks that lose the propagation race to another valid block mined around the same time, so they don’t end up in the canonical chain and produce no reward for their miners. Shorter block times result in more close races that will most often be won by well-connected, higher bandwidth miners. Over time this economic advantage weeds out less equipped miners and increases miner centralization. Ethereum’s PoW algorithm addresses this issue to some extent by including valid blocks that lose the race and rewarding their producers. This allows Ethereum to achieve higher throughput with somewhat lower, but still variable, block times.

Due to the scalability, environmental, and security issues inherent to PoW, a switch from PoW to PoS consensus is in the Ethereum roadmap. This switch has been slow to roll out, however, because PoS introduces several new challenges in securing the network. When entire chains can be easily and cheaply constructed, great care must be taken to ensure that block producers are financially incentivized to always follow the consensus rules.

Ethereum’s Casper family of PoS protocols are being rigorously constructed to address several known issues with PoS in a public blockchain context. They are designed to work in an open network in which all stakeholders can participate in consensus and any number can be considered adversarial. They make it expensive to attack the network by requiring consensus participants to make deposits, which can be forfeited for not following the protocol rules. The roll out of these protocols will happen in at least two phases. The first phase will continue to use PoW for block production but will overlay a PoS consensus algorithm to create economic finality on every 50th block. A later phase will replace PoW entirely with PoS, at which point increases in throughput will be realized.

Lisk implements a modified version of the Bitshares Delegated Proof of Stake (DPoS) consensus algorithm, which has some significant differences from Casper-style PoS. In DPoS most stakeholders don’t produce blocks, but instead vote their stake for delegates who do. Delegates are presumed honest by virtue of having been elected, and can ostensibly be voted out for dishonest behavior. Delegates share a portion of their earnings with stakeholders who vote for them. At the beginning of a round — a period in which 101 blocks are produced — the 101 delegates with the most stake voted for them are each allocated one 10 second slot in which to produce a block. The selection of delegates and allocation of slots is predetermined by the consensus rules using votes recorded on the blockchain.

In an open blockchain setting, DPoS has a number of well-known challenges associated with stakeholder voting such as low voter participation, insufficient individual incentivization, difficulty of voters staying informed, and centralization of voting power (in whales, pools, and exchanges). These are not just theoretical concerns; the Bitshares DPoS implementation was afflicted with voter apathy and now the same issues are playing out in Lisk. Under current conditions, control of all 101 delegates can be obtained with as little as 20% of the total stake. The Lisk Elite, a delegate pool that requires stakeholders to vote for all (currently 54) of its members in order to receive any rewards, has effectively created a perpetual delegate majority that is accumulating stake (and thus voting power) faster than the rest of the community combined, making it increasingly more difficult to vote out the cartel.

We discuss the issue of cartel formation in more detail in the Governance section below, but, with regard to performance, it should be clear that increasing transaction throughput with DPoS can introduce centralization and censorship issues that are antithetic to principles of an open public blockchain.

Scalability

The current scaling hurdle for Ethereum and most blockchain platforms is that every node has to process every transaction so transaction throughput cannot scale beyond the processing power of a single node. There has been a lot of research into mechanisms in which nodes only have to process a subset of transactions. Some of the more promising approaches include state channels, verifiable offchain computation, sharding, and sidechains.

Lisk addresses scalability by introducing sidechains as a fundamental component of the platform. The Lisk SDK is called a Sidechain Development Kit because it creates an independent sidechain for each application. Having each application run its own sidechain allows the network to scale by adding more transaction bandwidth as new applications are deployed. It also allows each application to set its own network parameters to best meet the needs of its use case.

Initially, Lisk sidechains will have to use the same consensus algorithm as the main Lisk network, so each sidechain will need a set of validators to secure it. Procuring enough validators to secure an application’s sidechain in perpetuity is the application developer’s responsibility. Ideally, the developer can create a transaction fee structure that attracts delegators and serves the needs of users. Otherwise, she can rent services from a pool of DPoS delegates found in the Lisk delegate marketplace. In any case, placing this operational burden on developers may limit participation to only those application builders that can adequately secure their sidechain. This would work against Lisk’s core value proposition to make it easy to build and deploy blockchain applications.

The total supply of delegates in the marketplace must continually grow in proportion to the number of applications, otherwise the cost to secure an application sidechain will rise (making the system even more exclusionary) and the overall security of Lisk sidechains will be reduced. According to Ethereum researchers, simply adding more chains has the following flaw: “an N-factor increase in throughput using this method necessarily comes with an N-factor decrease in security.” Although this formula may be overly pessimistic in assuming that the total capacity to validate transactions would not grow with the number of chains, it illustrates that there is a scalability for security tradeoff involved in adding an unlimited number of independent chains.

Awareness of this tradeoff has directly influenced the design of Ethereum’s sharding, a scaling solution similar to Lisk’s sidechains, but with some important differences. In Ethereum, each shard has its own sidechain, but there are a fixed number of sidechains that act more like extensions to the main chain than independent application-specific databases. The state of each shard’s sidechain is hashed and periodically recorded in the main chain, and all sidechains leverage the security of the main chain (i.e. the fork choice rule is based on the state hashes recorded in the heaviest fork of the main chain). In contrast, Lisk has a variable and unlimited number of application-specific sidechains that are secured independently of the main chain.

Shard sidechains are secured by a global pool of validators running the main chain consensus protocol (Casper PoS for Ethereum), similar to Lisk’s delegate marketplace. However, in Ethereum, validators aren’t contracted to work on specific shards; instead any participating validator can be randomly selected to secure any shard at any point in time. To accomplish this without requiring each validator to store the full state of each shard, transaction senders will have to provide pointers to the specific branches in the state tree that the transaction affects. The upside is that random assignment of validators to shards makes it impossible to attack the sharded system by compromising just a small number of validators on one specific shard. To compromise one shard the attacker must compromise enough of the global validation pool to compromise them all. Under Lisk’s current design, where the set of elected delegates assigned to a sidechain is publicly known and fairly static, compromising a single sidechain can be relatively cheap.

In theory, the independent functioning of Lisk sidechains would prevent security breaches, failures, and congestion in one application from affecting other Lisk applications. However, a key part of the Lisk vision is to enable “blockchain services” such as identity and smart contract execution that can be leveraged by other applications in the Lisk ecosystem. Such shared services would make it possible for congestion in one client to affect other clients by overloading the service, and for a security breach or failure in the service sidechain to affect a large number of client applications (more on this in the Security section below).

Ethereum’s initial sharding implementation will consist of 100 sidechains, so the increase in network capacity across all applications will initially be capped at 100x. Sharding is a scaling solution, however, because additional shards can be added as the capacity of the validator pool grows. Similarly, the growth of Lisk’s delegate pool capacity will determine the degree to which it can scale by adding new application sidechains. Whereas expansions of the Ethereum network with shard sidechains will come about through carefully controlled protocol upgrades, Lisk will add sidechains organically as applications are deployed.

If the demand for securing Lisk sidechains outpaces the growth of the delegate pool, we could see delegates allocating their resources to the most lucrative sidechains and leaving most other applications without adequate security. Max Kordek once wrote that the the biggest weakness of Lisk is sidechain security, “small dApps probably won’t have a chance long-term to attract enough nodes to secure them.” Although this form of natural selection might be an efficient way to allocate resources towards the best applications, it could lead to an application oligarchy that limits open participation.

Plasma is another Ethereum scaling solution that supports an unlimited amount of sidechains that are secured by smart contracts on the main chain. In Plasma, no assumptions are made about the honesty of block producers on the sidechain. If block producers misbehave, users can exit the sidechain and reclaim their funds on the main chain via the smart contract. Similarly, fraudulent exits can be challenged and blocked via the smart contract. Like all layer 2 mechanisms, Plasma requires users to pay careful attention to transactions on their sidechain and take swift action when necessary. The overall scalability of Plasma is limited by the capacity of the main chain to handle mass disputes. At the present time, Lisk sidechains are not secured by the main chain, but once they are deployed and experience is gained securing them, some kind of main chain adjudication could be introduced.

Plasma, sharding, and Lisk sidechains are all currently under development and their implementations could deviate significantly from current specifications. It’s not clear when any of these will be deployed but sharding and sidechains are key components of their respective project roadmaps. Once deployed, innovations can be rolled out more quickly without risk to funds stored in existing accounts because of the relative independence of sidechains from existing accounts in both projects.

Governance

At present, Lisk is still in its very early stages and thus all decisions about the main chain protocol are dictated by the core development team and Lisk Foundation. One might expect that Lisk sidechains will enable the possibility for application-specific governance models, but this topic is not currently covered in the Lisk documentation. The extent to which application developers can govern their own sidechains will be determined by the sidechain customization capabilities granted to them and their ability to get their software changes adopted by delegates.

The Lisk mainnet is secured by a set of 101 elected delegates. As mentioned above, the tenure of the Lisk Elite delegate group has caused significant consternation among community members regarding the distribution of rewards and transaction fees. Max Kordek has stated that the Lisk Foundation is concerned about the dominance of cartels and is forming a new Science Team to address this issue with protocol changes.

It will be interesting to see what types of protocol changes are deployed and to what extent these changes addresses the inevitable issue of cartel formation in an open blockchain context. The fact that all the necessary coordination to form a cartel can occur off chain makes it difficult to combat solely with on chain protocols.

One defense often proposed is for users to notice and coordinate (off chain) against the cartel, though the Lisk community is struggling with some real barriers to mounting this type of defense. However, the Lisk Ascend delegate pool, a group of verified Lisk contributors promising a more equitable distribution of block rewards to their constituents, is making headway. They are employing a pledge system to make it more cost effective for users to coordinate their votes and unseat the cartel. At the time of writing, Lisk Ascend has about 15% of the pledges it needs to be voted into forging positions, but that number appears to be growing steadily.

Ethereum’s Casper is attempting to address cartel formation at the protocol layer by heavily penalizing block producers who appear to be censoring other block producers. This approach can be effective in the context of Ethereum’s egalitarian (i.e. non-delegated) PoS model, where the only privilege afforded to participating stakeholders is producing blocks. Under these constraints the censorship of non-cartel blocks is machine detectable, though some false positives can occur when validators are simply offline versus being censored.

However, in Lisk’s DPoS, where block production rewards go to a small group of elected delegates who set the rules for participation and redistribution, cartels can accumulate wealth and power and shut out non-cartel members in ways that appear completely democratic and fair to machines. Allowing delegates to make rules with their delegated voting power provides powerful incentives for cartel formation that could not be addressed by protocol code. Imagine how the game of Monopoly would change if the banker were allowed to set prices and make rules versus being limited to just processing no fee transactions.

If on-chain voting enables a form of censorship that is undetectable by machines, and incentives to coordinate extend beyond mere block production, it’s unlikely that protocol changes alone will be able to completely disincentivize cartel formation. Without vigilant watch and significant off chain coordination, DPoS implementations on open public blockchains can end up functioning more like consortium chains where a high degree of trust must be placed in the elected group of delegates to benevolently wield their power. This is what we see playing out with the Lisk Elite and Lisk Ascend factions.

Unless the issues of voting in a representative democracy are miraculously solved (after nearly a century of game theory research and millenia of democracy have failed), platforms that use DPoS to gain transaction throughput at the expense of censorship resistance (or worse) are not likely to succeed in dominating the decentralized public blockchain space. In contrast, Ethereum, by limiting the capabilities of (non-elected) stakeholders to block production, may be able to effectively disincentivize cartel formation with protocols that govern the production of blocks.

Security

On April 19th 2016, Max Kordek wrote, “If a dApp fails, the Lisk network doesn’t even hiccup. However, if one smart contract fails at Ethereum, it can mean game over for Ethereum.” Two months later a hacker exploited a bug in the DAO contract and stole nearly 15% of all ETH in existence at the time. The theft was reversed by a controversial hard fork that led to a community split and the formation of the still vibrant Ethereum Classic platform. In July and November of 2017 two vulnerabilities in the Parity multisig wallet, which affected nearly 600 wallets and put over 500k ETH at risk, were exploited allowing funds to be stolen and frozen. There were no bailouts and no community splits for Ethereum in 2017. Although these hacks did not spell “game over” for Ethereum this time around, one has to wonder how much more ETH can be lost before the Ethereum platform goes extinct due to lack of security.

Max’s statement may be more relevant today than it was when bailouts were more acceptable in the Ethereum community. However, the premise of that statement — that a vulnerability in one Lisk application would not affect other Lisk applications because they run on separate blockchains — is false. The reason nearly 600 wallets were simultaneously affected by a single vulnerability is because they shared the same code, not the same blockchain. If each wallet instance existed on its own blockchain, all of them would have the same vulnerability to a single exploit.

Regardless of how applications are deployed they will share common code. Whether this be in the form of shared services, libraries, or even cut and pasted from other projects, software developers do not like to reinvent the wheel. Max Kordek writes, “The best part is, if you need one of these services in your Lisk blockchain app you don’t need to re-implement everything. You can just plug into third party technologies and leverage their functionalities from within your Lisk blockchain app.” Later in the same post, examples of such services are given: identity, storage, smart contract execution, and oracles. A vulnerability in any one of these could have severe consequences for all client applications simultaneously. For example, a compromise of the identity service that allowed an attacker to pose as anyone could allow that attacker to drain all accounts in all applications relying on that service.

It’s important to note that the currently proposed implementation for Lisk’s smart contract execution service is to use Ethereum. This implementation would expose all applications using that service to the same vulnerabilities that currently plague Ethereum. So it could be the case that a single vulnerability spells game over for Ethereum as well as all Lisk applications using the Ethereum-based smart contracts service.

Conclusion

Lisk is markedly different from other platforms covered in this series in that its focus is not on smart contracts; they are an add on service that will initially just leverage the Ethereum platform. Lisk’s focus is on addressing two key barriers to growing a vibrant blockchain application ecosystem: scalability and ease of application development. Lisk plans to scale using DPoS sidechains and to enable creators to build blockchain applications using a familiar language and a powerful SDK.

Lisk has a running blockchain, but the only application it currently supports is the transfer of tokens. When the remaining SDK pieces that allow applications to be developed are released and Lisk applications are built and deployed, we’ll know more about the viability of Lisk as a decentralized application platform. As Lisk grows, we’ll see how it addresses the issues related to voting and cartel formation in DPoS systems, whether it can attract enough validators to make sidechain scaling viable, and whether it can deliver on its promise to isolate faults and security breaches in applications that use shared blockchain services.

These are non-trivial problems that will likely require a sizable research effort and significant changes to the current architecture to solve. This effort must be comparable Ethereum’s, which is addressing similarly difficult challenges. At present, Lisk’s research and development efforts are not comparable to Ethereum’s, but Lisk is a well-funded project that is progressing quickly and pragmatically. It’s likely that Lisk R&D will ramp up significantly in the coming months.

At present Lisk is far behind Ethereum in deployed technology, research, and network effects with no signs of revolutionary ideas that would flip this. Lisk’s primary innovations — Scaling with sidechains and providing a pure Javascript development environment for building blockchain applications — are advances that Ethereum can approximate easily enough with sharding and improved development tools. If Ethereum is to see a mass migration of developers and applications, it will most likely be due to continued security breaches resulting in major losses of funds held in smart contracts. In this scenario Lisk would not be the likely place of refuge, especially if it uses Ethereum as a smart contract service.

Thanks to Pham Cong Dinh for his input on early drafts.

Thanks to @akvo for his input, encouragement and support from the very beginning

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Lisk was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of smart contract projects in the cryptocurrency ecosystem. Today we’ll look at Cardano and the ways it could supplant today’s dominant platform, Ethereum.

Cardano is a project that aims to create a next generation smart contract platform and ecosystem by learning from and improving on lessons learned in the Bitcoin and Ethereum communities. The project claims to be “the first blockchain platform to evolve out of a scientific philosophy and a research-first driven approach.” The project’s goals include improved scalability, security, governance, and interoperability with traditional financial systems and regulations. Whereas Cardano’s design focus and approach to meeting these goals are somewhat different than Ethereum’s, Cardano’s innovations can be directly compared with those of Ethereum.

Like Ethereum, Cardano has a funded non-profit organization, The Cardano Foundation, that supports the research and development of the protocol, as well as community development. Much of this research and development is currently led by the for-profit technology company, IOHK, working in conjunction with researchers at several universities. Charles Hoskinson and Jeremy Wood were both involved with the Ethereum project in its early days but left to found IOHK in 2014. Much of IOHK’s funding comes from a five-year contract with Emurgo, a blockchain applications company that is looking for a platform with better support for regulatory oversight.

A crowdsale of Cardano’s Ada token raised approximately $62 million. The Ada token is named after Ada Lovelace, a 19th century mathematician recognized as the first computer programmer and daughter of the poet Lord Byron. Cardano’s first major release, named Byron, went live on September 29, 2017, launching the Cardano mainnet.

Although having a live mainnet puts Cardano a step ahead of all the Ethereum challengers we’ve looked at thus far, Cardano is still many steps behind Ethereum in terms of deployed technology. The Cardano network is still in a bootstrap state, with all consensus nodes under the control of IOHK and partners, no smart contract support, and many key innovations still under development. However, those innovations are well-documented in IOHK’s extensive research library, and online documentation, as well as in peer-reviewed academic journals. This gives us an excellent basis on which to compare Cardano to Ethereum, so let’s dive into the details.

Performance and Scalability

All the platforms we’ve looked at thus far utilize some form of Proof of Stake (PoS) consensus to achieve fast, deterministic block times, and Cardano is no exception. The Ouroboros protocol used in Cardano is a chain-based PoS protocol, where in each time slot a leader, randomly chosen from a pool of stakeholders, produces the next block, which links to the previous one in the chain. Unlike BFT-style PoS algorithms, where validators finalize (i.e. permanently agree on) blocks as they are produced, blocks become canonical with increasing probability as more blocks are built on top of them (like in proof of work schemes).

The probability of any stakeholder being selected as the leader is proportional to the size of their stake — the percentage of all coins they control, either by direct ownership or via delegation. As transactions are recorded in blocks, the stake distribution (i.e. the set of stakeholders and their respective stakes) used for leader selection changes. To deal with a changing stake distribution, Ouroboros defines the notion of an epoch as some number of slots in which the stake distribution is fixed. It is either hardcoded (in the initial bootstrapping stage) or (in later stages) computed from a snapshot of the blockchain at a sufficiently deep block. At the beginning of each epoch a set of leaders is chosen and each is assigned the right to produce a block in a specific slot. The leaders and slot assignments are chosen based on the fixed stake distribution and a random seed, which is generated by a multi party computation (MPC) among stakeholders in the previous epoch.

To ensure that leaders are incentivized to always follow the protocol, Ouroboros introduces a check on block production via transaction endorsing. In each epoch a set of input endorsers is assigned to each slot based on stake. The input endorsers are responsible for endorsing transactions to be included in the block produced by the leader. The leader’s block is only valid if all the transactions it includes have been endorsed by an eligible input endorser. Each epoch rewards leaders, input endorsers, and MPC participants to ensure that following the protocol is an equilibrium when all players are rational.

This structure of economic rewards enables the protocol authors to develop several proofs about properties of the system, which has led IOHK to proclaim Ouroboros the “first provably secure proof of stake algorithm.” The safety and liveness proofs presented are based on assumptions of a partially synchronous network with an honest majority and an upper limit on how long honest nodes may be offline. These assumptions may work well for permissioned blockchains and the commercial applications envisioned by Emurgo, but perhaps not as well for a permissionless world computer. The assumptions underpinning Ouroboros security have been criticized as “unrealistic”, “impractical for a global blockchain”, and “way too convenient”.

The last critique above came from Vlad Zamfir, who is leading research on Ethereum’s Casper The Friendly Ghost (TFG) protocol. In contrast to Cardano’s approach, Casper TFG is designed to address the faults that are likely to occur on an open public blockchain, rather than make assumptions that may only hold for permissioned chains.

Whereas Ouroboros and Casper TFG both employ economic rewards to achieve safety and liveness, Casper TFG also incorporates penalties based on fault attribution. Casper TFG is proven safe without any synchrony assumptions and it’s likely to be proven live under partial-synchrony. Moreover Casper TFG assumes no bounds on being offline and addresses attacks from majority coalitions. The design of Casper TFG takes into account faults that are likely to occur on an open public blockchain, rather than making assumptions that may only hold for permissioned chains. Neither Ouroboros nor Casper TFG has been deployed on an open public blockchain with significant assets at stake.

Another way Cardano hopes to use Ouroboros to scale is by partitioning transactions to different sets of elected leaders. According to Cardano’s vision paper, this is “trivial” to do. However, there doesn’t appear to be any additional information at this time on how blocks from different partitions fit together or how input endorsers would coordinate to prevent double spends across partitions. Ethereum’s EIP 648 describes a mechanism for parallelizing transaction processing that works in the existing block structure and thus might be deployed before Cardano accomplishes the same.

Cardano’s vision paper hints at using similar techniques to implement sharding but it’s unclear how much progress (if any) has been made on this front. Sharding is under active research in the Ethereum community but is still years away from production. Sharding is so far off for both Cardano and Ethereum that no clear advantage can be inferred for either project at the current time.

With expectations of very high transaction throughput, Cardano hopes to build a scalable network that doesn’t require every node to process every transaction. Their plan is to use the Recursive Internetwork Architecture (RINA) technology to accomplish this, though not much detail has been provided to date.

At the present time scalability and performance are major issues for Ethereum, and its scaling solutions are in various stages of research and development. Although Cardano has presented some ideas for scaling, the implementations are still a long way off. The first version of Ouroboros deployed with the Byron release is completetely centralized, with only IOHK-controlled nodes participating in consensus. Community participation via delegated staking will begin with the Shelley release (2018) and work on scaling will continue through 2019 and 2020. So it is not clear if or when Cardano will be able to gain a practical performance and scalability advantage over Ethereum, which will also evolve over the next 2–3 years.

Governance

The Cardano project aims to learn from and improve on the governance mechanisms of Bitcoin and Ethereum. The goal is to create a more formalized process that reduces the perceived gridlock of the Bitcoin process without creating the appearance of centralized governance that has been blamed for Ethereum’s community split. Criticisms of Bitcoin’s and Ethereum’s informal governance processes are highly subjective but it is a fact that both have experienced hard forks and fractured communities due to the failure to reach agreement on governance issues.

Like Tezos, DFINITY, and other platforms experimenting with decentralized governance processes, Cardano intends to provide on-chain mechanisms for making decisions about the future of the protocol. The goal is to prevent community splits and keep pace with innovation by having a well-defined process for making decisions that everyone can accept. The hypothesis is that if users feel represented by a fair “rule of law” system, they may be less likely to resort to forking over simple protocol changes and more likely to stay invested even when they don’t get their way. Cardano plans to implement this by creating a constitution that lays out in detail the mechanism for agreeing on protocol updates and a program for creating and voting on Cardano Improvement Proposals in a transparent and censorship-free way.

One key governance concern that Cardano hopes to automate is platform sustainability — the mechanism by which the decentralized Cardano community can continue to pay for things it needs. Right now both Cardano and Ethereum have well-funded foundations that fund specific development and community building projects. If it turns out that the funds raised in a one-time ICO don’t generate an eternal source of funding for these organizations (unthinkable, I know), Cardano has a plan. The idea, which is not new, is to create a treasury system, funded by transaction fees, to support future development. Stakeholders decide how to spend treasury funds by voting on proposed projects (i.e. Cardano Improvement Proposals).

Cardano hopes to realize a long-term vision of expressing Cardano Improvement Proposals in terms of machine understandable specifications that can be tested and verified using software tools. A less ambitious governance process, which is slated to arrive with the Shelley release of the platform, starts out with IOHK making all improvement proposals and evolves to provide “an increasingly better mechanism for gaining consent for them.”

There are some well known issues with democratic processes in general, and specifically with on-chain voting. Whether proposals under vote are machine understandable or just human readable, they will be highly technical, and are unlikely to be fully understood by the average stakeholder. Stakeholder votes will be informed by abstracted explanations from a small tech-savvy minority that understands how the proposals really work. Getting enough users to participate such that the result of any vote is representative of the whole community is also a challenge. If some form of delegated voting is employed, it can give a small cartel of delegates (e.g. stake pools) too much power to change the rules and enrich themselves at the expense of other users.

Ethereum’s PoS researcher Vlad Zamfir has articulated the difference between stake-based voting in PoS, which provides minimal power with strong penalties for abuse, and stake-based voting on proposals, which provides maximal power with essentially no accountability. He argues that on-chain voting is dangerous because it forces rule changes on full nodes, removing an important check and balance provided by informed node operators. Similarly, Ethereum founder Vitalik Buterin argues that, because of these known issues, stakeholder voting systems shouldn’t be the single mechanism for all governance, but just one component that is checked by other mechanisms such as miner voting, user voting, core developers, and established norms.

It remains to be seen whether or not the on-chain mechanisms based on stakeholder voting that Cardano proposes can overcome these challenges to facilitate protocol evolution and bind communities together. In the near term, Ethereum’s less formal off-chain processes do not seem to be impeding innovation or enacting contentious hard forks just to make users whole. When Parity, a company founded by Ethereum creator and thought leader Gavin Wood, published proposals to hard fork to resurrect over 500 thousand ETH that was frozen in Parity multisig wallets by a deleted contract, those proposals were met with strong resistance by prominent members of the Ethereum community. Ethereum governance has evolved and may be shedding its reputation for haphazard bail outs.

Cardano’s long-term governance vision includes “the creation of a modular regulation DAO that can be customized to interact with user written smart contracts in order to add mutability, consumer protection and arbitration”, however their greatest and most immediate advantage may come from eradicating the need for bail outs in the first place. The root cause of both the debate on Parity’s hard fork proposals, as well as the Ethereum hard fork that actually resulted in a community split, was the exploit of vulnerabilities in Solidity code that could have been avoided entirely with better software development languages, tools, and processes. Cardano appears poised to deliver significant improvement in these areas.

Smart Contract Security

The design of the Cardano Computation Layer (CCL), Cardano’s smart contracts platform, is heavily focused on making it easier to provide guarantees that a smart contract behaves as designed without hidden vulnerabilities. The CCL consists of two layers: a formally specified virtual machine and language framework, and formally specified languages that facilitate automated verification of human readable smart contract code.

The lowest layer, called IELE, provides a virtual machine designed to make building formal verification tools easy, and a universal language framework for translating smart contracts from higher-level languages into executable instructions. Research and development of IELE is funded by IOHK and led by UIUC Professor and founder of Runtime Verification, Grigore Rosu. Rosu and team are applying insights from their research on KEVM, a formal semantics in the K framework for the Ethereum Virtual Machine, and KLLVM, a formal semantics in K for LLVM, to build a more secure and efficient virtual machine.

Unlike the EVM, which is a stack-based machine, IELE will be a register-based machine, like LLVM. IELE will have an unbounded number of registers and will also support unbounded integers. Avoiding the use of a bounded stack and not having to worry about stack or arithmetic overflow will make specification and verification of smart contracts significantly easier. Like Ethereum, IELE will use gas to limit resource usage and prevent DoS attacks. This presents some challenges to formal verification that are considered “tricky but manageable” by the research team. IELE leverages the K framework to simplify the development of automated tools that verify smart contracts match specifications. This allows IELE to support smart contracts written in any programming language that has a formal semantics in K.

One such language may be Simon. Briefly described in the Cardano vision paper, Simon is a highly constrained, domain specific transaction language that provides a precisely specified set of basic financial transaction primitives that can be combined to create more complicated contracts with verifiable properties. Not much else has been written about Simon, but it is reportedly inspired by concepts from the paper Composing contracts: an adventure in financial engineering, by Simon Peyton Jones and colleagues.

Simon Peyton Jones is one of the principal designers of Haskell, a statically typed, purely functional language that is often used in applications where runtime bugs have a high cost (it is used to implement Ouroboros). Haskell’s design makes it amenable to automated verification tools that can identify and eliminate defects early in the software development process. Another Haskell designer and ACM Fellow, Phil Wadler, is a programming languages advisor to IOHK, so it’s no surprise that Cardano’s primary high level, general purpose smart contract language, Plutus, incorporates many of the concepts behind Haskell.

Plutus is a statically typed, functional language with a human readable, Haskell-like syntax. Like Haskell, Plutus translates to a simpler language, Plutus Core, that makes formal verification easier. Formal verification tools can help developers to reason about contracts and to prove certain properties about the behavior of the smart contract. These proofs can be a powerful tool to highlight and eliminate the primary sources of contract vulnerabilities such as handling of invalid input, type mismatches, nonobvious unintended code paths, confusion around scope, typos, overflows, etc. For example, a proof of the property that there is no code path in which the owner of a contract can be changed would have prevented vulnerabilities that led to both exploits of the Parity multisig wallet. This specific property is obvious in hindsight; it’s entirely possible for important properties to be left out of a formal specifications, allowing vulnerabilities that only becomes obvious after they are exploited. So, while formal verification is a very powerful tool, it is only as effective as the human being(s) ability to cover all bases when creating a specification.

Cardano plans to support other high level languages, including Solidity. However it supports Solidity for “for low assurance applications [and Plutus] for higher assurance applications requiring formal verification.” While it’s hard to imagine any smart contract writer choosing the low assurance option, support for Solidity will make it easier for Ethereum developers and perhaps some existing contracts to migrate to Cardano. The primary reason for developers and contracts to migrate to Cardano, however, won’t be its support for Solidity, but rather its ability to reduce the risk of vulnerabilities that put funds at risk. If IELE, Plutus, and supporting verification tools can enable the development of smart contracts that are demonstrably free of the types of vulnerabilities that plague Solidity code, Cardano could become the platform of choice for deploying contracts that need better security around the funds they control (i.e. all smart contracts)

In order for Ethereum to remain the dominant smart contracts platform, it will need to adapt, by upgrading its smart contract language and tool chain before a better alternative exists. The Ethereum community is developing new programming languages such as Bamboo and Vyper that are more suitable for formal verification and constrained such that many vulnerabilities can be discovered by compilers rather than by hackers. These languages compile to EVM code, so it would be necessary to formally verify both the high-level code as well as the EVM bytecode produced (and/or the compiler producing the bytecode). Currently there are multiple projects in the Ethereum community investigating the formal verification of smart contracts and the Ethereum virtual machine itself. Ethereum is in a race to eliminate the regular occurrence of high profile exploits of Solidity contracts before a competing platform does.

Conclusion

The Cardano project promises to bring several innovations to the smart contracts platform space. It is working with professors from universities around the world to incorporate peer reviewed academic research into its design, more so than any platform we’ve looked at thus far, including Ethereum. It has developed a “provably secure” proof of stake protocol that should work well in permissioned networks and may work well enough for a public, global, permisionless blockchain. It is trying to improve on the perceived shortcomings of Bitcoin and Ethereum governance, while borrowing governance ideas from other blockchains. Its verification-focused design of a smart contracts platform could provide a demonstrably more secure alternative to Ethereum.

Perhaps the biggest threat Cardano poses to Ethereum is that its innovations in language and VM design address the security concerns that are Ethereum’s Achilles’ heel. Exploits of Solidity vulnerabilities have resulted in significant loss of funds and created crises for the Ethereum community. As long as Solidity remains Ethereum’s only viable option for writing smart contracts, all Ethereum contracts will be subject to the risk of exploit and the community will be limited to reactive solutions, such as relying on white hat hackers to rescue funds and enacting bail out hard forks. This situation is only acceptable because an alternative platform offering preventive solutions does not exist today. With IELE, Simon, and Plutus, Cardano is designed from the ground up to enable formal verification tools that can eliminate vulnerabilities before they are deployed. If Ethereum cannot solve its vulnerability problem before Cardano delivers a better alternative it may lose its position of dominance to a more secure platform. However, Cardano has lot of work to do before it can be considered a viable alternative platform, so there is still plenty of time for Ethereum to adapt.

A platform is only as secure as its weakest link and it remains to be seen whether the Ouroboros PoS protocol can secure a global, permissionless network with significant value at stake. If not, Cardano may find a niche in providing high assurance applications on permissioned networks. One advantage of Cardano’s strict separation of computation layer (IELE + languages) from settlement layer (Ouroboros) is that each can change independently. If the Ouroboros-based settlement layer is not suitable for global blockchains, then the great work being done at the computation layer could be ported to a different settlement layer that does. It’s conceiveable that Ethereum could incorporate Cardano’s innovations in language and VM design to solve its smart contract security issue. In any case, thanks to the research coming from the Cardano project, we can look forward to more secure smart contract platforms in the future, and regular exploits of Solidity contracts becoming a thing of the past.

Thanks to Christopher Mead and Steven J. Owens for their input on early drafts.

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of Cardano was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at EOS and how it could threaten to supplant Ethereum as the dominant smart contracts platform.

EOS is a blockchain-based smart contract platform that promises great advances in addressing some of the key challenges in current blockchain technology: performance, user experience, and governance. Currently EOS is still undergoing development; there is no public blockchain on which to build and deploy applications. However, the ideas behind EOS are based on years of practical experience implementing the Bitshares and Steem platforms and the project is well funded.

EOS has been called an “Ethereum Killer” based on claims of high transaction throughput, zero fee transactions, and structured governance. Any one of these could potentially disrupt Ethereum’s incumbency as dominant smart contract platform, so let’s take a deeper look at each.

Transaction Throughput

EOS promises to achieve orders of magnitude performance improvements over Ethereum by implementing a number of scaling techniques, such as Delegated Proof of Stake (DPoS), parallel execution, partial evaluation and other optimizations. Similar improvements are also being researched and developed in the Ethereum ecosystem, allowing for a direct comparison of each project’s current approach, though both are likely to change as research progresses.

Despite sounding like similar technology, EOS’s DPoS has little in common with Ethereum’s proposed Casper The Friendly Ghost (TFG) protocol. In EOS’s DPoS a set of 21 elected block producers take turns in creating blocks with very high throughput. Producers who do not perform or misbehave can be voted out of their lucrative positions. In Casper TFG, anyone willing to deposit ETH can participate in the consensus mechanism and malicious/faulty activity is penalized by loss of deposit.

DPoS consensus works well in a consortium model, where a high degree of trust must be placed in a very small group of block producers. EOS’s viability as a public blockchain will depend on whether malicious/faulty producers can be promptly removed by a decentralized voting process. To achieve this EOS will have to overcome several challenges associated with stakeholder voting such as low voter participation, insufficient individual incentivization, difficulty of voters staying informed, and centralization of voting power (in whales and exchanges).

EOS hopes to significantly improve throughput by using parallel execution in the production of blocks. The primary purpose of block production is to provide a total ordering of transactions, which must be executed sequentially, but transactions which do not affect the same accounts can be executed in parallel. The EOS white paper describes a method of breaking blocks into threads that can run in parallel but lacks details on how the determination of transaction independence can be accomplished. EOS has announced that it’s parallel execution engine will be complete by June 2018. Ethereum’s EIP 648 describes a mechanism for parallelizing transaction processing that works in the existing block structure. It’s likely both platforms will eventually have parallel execution but not clear which will be first or whether one will provide a significant performance benefit over the other.

In theory, significant scaling can be achieved by having nodes only validate a subset of transactions rather than the entire blockchain. In practice it’s difficult to implement. The EOS white paper describes the benefit and challenges of partial evaluation, but presents no details for an implementation. In Ethereum, a great deal of research has gone into sharding (summarized here) but a working solution is not on the near term horizon. It’s possible the EOS could leverage the work done in Ethereum to deliver an implementation on its brand new platform first, or that Ethereum could use lessons learned from EOS’s implementation to speed up their deployment, though it may be years before either of these happens.

The use of Web Assembly instruction set provides performance benefits by allowing pre-compiled contracts to execute at near native speeds. The EOS virtual machine will be based on Web Assembly, while the Ethereum Flavored Web Assembly (eWASM) project is looking into replacing the existing EVM in a manner compatible with existing smart contracts.

In the race for higher transaction throughput, building an EVM and blockchain from scratch without billions of dollars at risk in existing contracts gives EOS an innovative advantage. Whereas Ethereum is applying rigorous theoretical validation and cautiously phasing in its PoS implementation, EOS is moving quickly to roll out a repackage of the existing Bitshares DPoS implementation. If Ethereum cannot keep pace, it may lose application market share to EOS, but as the value of the EOS network increases it will likely attract new kinds of attacks. Successful exploitation of a vulnerability introduced at any weak point in EOS’s high-performance design could be devastating. It remains to be seen whether DPos as implemented in EOS will be resistant to censorship, denial of service (DoS), and other collusion attacks when there is significant value at stake. If stakeholder voting mechanisms work well enough to successfully stave off attacks, EOS’s performance advantage could pose a credible threat to Ethereum’s dominance.

Zero Fee Transactions

Both EOS and Ethereum transactions are powered by tokens held by users. In EOS users get transaction allocations by making deposits that are visible to block producers, whereas in Ethereum users pay the producers (miners) directly via transaction fees.

EOS promotes a zero fee transactions model based on the philosophy that service providers (i.e. the smart contracts) will be able to monetize users and will therefore be motivated subsidize the required deposits. This is based on a common web app model where users receive service for “free” — i.e. in exchange for their personal data, attention to ads, etc. However, transaction fees make spam and DoS attacks expensive to carry out; without them smart contracts and blockchains are vulnerable to these kinds of attacks. Even with fees, such attacks have occurred on Ethereum, requiring hard forks with price changes to make them more expensive.

EOS tries to address spam/DoS issues by using a dynamic fractional reserve system for allocating transaction bandwidth to users. The idea is that block producers allocate transaction bandwidth to users proportional to the balance of their token deposits and depending on how congested the network is at the time. Attacks are defended by dynamically tightening reserves and thereby increasing the overall cost of the attack. This reactionary defense approach stands in contrast to Ethereum’s preventive approach of using transaction fees to set the price of an attack a priori.

Zero fee transactions could provide EOS some advantage over existing Ethereum contracts if the dynamic fractional reserve defense will secure them with significant value at stake. If zero fees win out, Ethereum dApps could remain competitive by implementing transaction fee refunds to users or taking advantage of mechanisms proposed in the upcoming Constantinople upgrade to allow contracts to pay for gas. If it turns out that transaction fees are necessary for certain types of contracts, then the flexibility to support either model on a per-application basis gives Ethereum the advantage.

Structured Governance

Ethereum is modeled after Bitcoin’s governance structure, in which the balance of power is distributed among developers, miners, and users. Evolution of the protocol is governed through a community driven process based on Ethereum Improvement Proposals but some capacity parameters (e.g. block gas limit) can be adjusted dynamically by miners of blocks.

Ethereum’s governance process was tested in the wake of the DAO hack, where nearly 15% of all ETH in existence was stolen. A hard fork to restore funds was proposed by a small group of thought leaders and supported by the majority of the community, but resulted in a community split where an opposed minority continued supporting the non-forked chain, now called Ethereum Classic. Such splits are believed to reduce the security and network value of the respective communities so there is interest in more structured governance mechanisms that can resolve issues without causing splits. There are proposals in the Ethereum community for some additional on-chain governance mechanisms, but no formalized structure has been put in place.

In contrast, the EOS white paper describes some formal and powerful governance mechanisms built into the protocol. In EOS, block producers finalize the transaction ledger and, as elected representatives of users, also carry out certain governance functions. A majority (17/21 or roughly 80%) of elected block producers can freeze accounts, update code in defective smart contracts, and enact hard forks. These actions can be an effective defense against obvious theft or malfunction if the power vested in the small group of block producers is not abused.

As the Ethereum community split showed, what constitutes theft or malfunction is more subjective than obvious, but by employing voting and majority rules, EOS hopes to systematically act in the interests of a large majority. However, it’s not clear that users would be happier giving censorship authority to delegates they elect by vote or that this structure would necessarily prevent an opposing minority from splitting due to actions taken by the majority.

Conclusion

EOS addresses some key challenges faced by Ethereum with various scaling improvements, new fee models, and formalized governance processes. This is achieved by granting significant powers to elected delegates and putting in place reactive security mechanisms that require increased trust in those delegates. A fundamental assumption is that users will actively exercise their voting power to prevent abuse of that trust.

If these mechanisms work well enough to defend the network when considerable value is at risk, EOS can deliver major advances in scalability, governance, and usability of decentralized blockchains. If not, EOS could become a public blockchain controlled by a wealthy cartel and/or experience exploits that destroy confidence in the platform.

The smart contract breaches that occurred in Ethereum remind us that transaction throughput and features are secondary concerns to bugs that allow the funds in an account to be drained. The biggest threat to Ethereum’s dominance right now is the vulnerability of its smart contracts. Any platform that delivers significantly better smart contract security before Ethereum can improve has an excellent shot at becoming dominant.

EOS is not that platform. The decision to implement smart contracts in general purpose languages such C++ and Javascript exemplifies a design focus that favors performance and features over security. In contrast to the safety and liveness proofs, costs of attack, failure thresholds, and other indicators of rigorous security engineering found in Ethereum research, the EOS literature to date consists mostly of handwavy claims that proposed mechanisms that will just “work” with no analysis of the conditions under which they won’t. With time and funding this situation could change, and EOS could publish more detailed analyses of the costs, limits, and effectiveness of its security mechanisms. However, there is no evidence at present to suggest such a shift in design priorities is taking place. Until it does, EOS runs the risk of its limits being discovered empirically through exploits, and failing to beat Ethereum at what matters most in a smart contract platform.

Dominance threat levels are explained in the introduction to the series. Below is a brief legend.

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of EOS was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is part of the ongoing “Origin” series that tracks the emergence and evolution of projects in the cryptocurrency-based smart contract ecosystem. Today we’ll look at NEO and the ways it could supplant today’s dominant platform, Ethereum.

NEO’s goal is to enable the digitization of all real world assets by tying them to real world identities through blockchain and smart contract technology. Note the emphasis on real world; NEO’s tight integration with existing legal and governmental frameworks and support for familiar software development environments are distinguishing features of this platform. Thus NEO has some sharper contrasts to Ethereum than the other projects examined thus far in this series that will set the stage for some interesting competitive scenarios.

The NEO project dates back to 2014, when the Antshares blockchain was conceived and became China’s first open source public chain project. The Antshares technology was used as a foundation for the DNA blockchain framework for permissioned networks, developed by Antshares creators and their company, Onchain. In mid 2017 Antshares rebranded itself as NEO, projecting an image of newness punctuated with a second, all new “initial” coin offering. At the same time the network was upgraded to NEO 2.0, signalling an intensified focus on smart contracts to build what the project calls the Smart Economy.

This shift was likely influenced by the advances in technology to support smart contracts that occurred between 2014 and 2017, most notably in the Ethereum community, and led to NEO being labeled “Chinese Ethereum.” While that moniker represents a simplistic, perhaps speculator-fueled association that overlooks some fundamental differences, NEO nonetheless is well-positioned to challenge Etherum’s position as dominant smart contract platform.

Despite it’s long life (in blockchain years), the project is less mature than Ethereum in some ways; major pieces of functionality are still being developed and the consensus mechanism remains highly centralized. However, the project is evolving at a healthy pace thanks to a thriving open-source developer community and an organized steering committee, the NEO Council, that sets and funds project initiatives. NEO development and community support is well-funded by token sales and the venture capital backing of Onchain. Unlike some other competing smart contract platforms we’ve looked at in this series, NEO already has a live production blockchain, running a few smart contracts, and has supported at least one ICO at the time of writing.

Let’s take a deeper look at some of the different approaches NEO takes and examine how the competition could play out in the near future.

Performance

Nearly every competing smart contract platform is touting orders of magnitude performance increases over Ethereum, and NEO is no exception, claiming 1000 transactions/second throughput with 15–20 seconds confirmation times. Like the others, NEO promises to achieve this by doing away with Proof of Work (PoW) in favor of a more synchronous, and thus faster consensus mechanism. However, unlike most platforms that use some form of Proof of Stake (PoS), NEO has chosen instead to implement Byzantine Fault Tolerance (BFT) consensus.

In both PoW and PoS consensus, chains can split and those splits must be resolved (or reach a suitably high cost of reversal) before transactions can be considered confirmed. NEO’s designers believe that using BFT consensus, which does not produce chain splits, can increase performance and overall adoption of its platform. Rather than split the chain, the BFT process simply stops making new blocks whenever consensus cannot be reached. A nice side-effect is that the transactions contained in a block can be considered finalized (100% irreversible) immediately after consensus on the block is reached. So using a BFT algorithm that can produce a block of 15–20 thousand transactions every 15–20 seconds, can achieve throughputs on the order of 1000 transactions per second with a 15–20 second confirmation time.

So, if BFT has all these wonderful properties, why isn’t it being used to secure all blockchains? BFT performance is best when a high percentage of validators follow the protocol (i.e. are “honest” nodes), but degrades as that percentage decreases, and comes to a dead stop below 2/3 (roughly 67%) honest nodes. So more often BFT is used in permissioned, “consortium” blockchains, where stronger identification of validators makes it much more difficult for bad actors to join, and the higher degree of trust allows the BFT consensus to run at optimal speeds.

Public blockchains, such as Bitcoin and Ethereum, are designed to allow open participation without requiring any trust among participants. These designs intentionally trade off on-chain performance with the belief that scaling can be more effectively accomplished using off-chain technologies such as layer 2 networks and baby chains. The off-chain networks can support a variety of different participation and trust models, which can be adjudicated as necessary by a fully permissionless and trustless base layer chain. Although NEO, like any platform hoping to dethrone Ethereum as world computer, will likely need to implement off-chain mechanisms to reach worldwide scale, its commitment to BFT in the base layer will require permission to participate in consensus and a greater degree of trust among users that consensus nodes do not collude or act malevolently.

This “real world” influenced design philosophy is antithetical to a some people’s vision of what a public blockchain should be. NEO has been criticized for calling itself a public blockchain while creating significant barriers to public participation in the consensus process. The process for becoming a consensus node involves staking a large amount of money, obtaining an identification certificate from a government-authorized Certificate Authority, and then getting elected by voters.[1] The NEO Council’s response to this criticism is that, because NEO uses delegatedByzantine Fault Tolerance (dBFT) consensus, where validator nodes are elected by users who have stake in the NEO coin, users will have a say in determining who the validating entities are and thus serve as a check against abuse of power. The extent to which this theory works in practice will depend on whether NEO can overcome the well-known challenges associated with stakeholder voting such as low voter participation, insufficient individual incentivization, difficulty of voters staying informed, and centralization of voting power (in whales and exchanges).

In contrast, Ethereum, which does employ a BFT-like consensus protocol in its “Friendly Finality Gadget”, shuns voting and delegation in favor of imposing financial penalties on malevolent validators to allow open participation in the consensus process with minimal trust. Ethereum’s choice to deter malevolence through loss of funds rather than loss of job distinguishes it from NEO and several other emerging platforms (e.g. Tezos, DFINITY, and EOS) that rely on voting for delegated consensus nodes. If any one of these challengers succeeds in creating a secure, robust consensus implementation before Ethereum can improve its transaction throughput (via pure PoS or other mechanisms) that platform’s performance advantage will pose a serious threat to Ethereum’s public chain dominance.

This challenge is far off however, as any platform will need to reach significant size for its resilience to collusion, censorship, and other attacks to be fully tested and most challengers don’t even have running production blockchains yet. At the time of writing NEO does have a functioning main net and a healthy market cap, but does not yet have a functioning voting mechanism.

NEO and other challengers will have the advantage of learning from each other’s approach to voting challenges, but the disadvantage of competing with each other with variations on the same basic design. If delegation turns out to be a winning strategy, these platforms will likely converge toward the same implementation (with the same performance characteristics), and the ultimate winner will have to distinguish itself in other ways.

Governance

NEO has yet to distinguish itself from Ethereum in terms of improved blockchain governance. At the present time, NEO provides no mechanism for users to vote, and most, if not all, operating consensus nodes appear to be affiliated with projects funded by the NEO Council. Even if voting gets fully implemented and all of the aforementioned issues with stakeholder voting overcome, one of the glaring issues is that 50% of all NEO (i.e. voting power) is currently held by the NEO Council. So until that is somehow resolved, NEO’s governance could be considered a more formalized version of the benevolent dictatorship model often attributed to Ethereum’s thought leaders.

In a broader sense, NEO is looking to leverage governance from existing legal systems to enable the digitization and management of real world assets. According to the NEO white paper “Assets registered through a validated digital identity are protected by law.” To take advantage of such protections, NEO users will need to be issued a digital identity from a Certificate Authority that is recognized within the jurisdiction of the legal system in which they seek protection.

In many legal jurisdictions, ownership of financially significant assets (e.g. car, house, stock) is recorded in a ledger maintained or regulated by a government agency and tied to identification established by a government-issued form of ID. This enables the government’s legal system to authoritatively determine the ownership of any registered property. The process of transferring assets in such systems is often beaurocratic and expensive, so transfer via the blockchain can be much faster and cheaper. However, in order for asset transfers via the blockchain to be enforceable under existing law (in those jurisdictions), the blockchain owner ids must be linked to the government-issued ID that establish ownership under that legal system. NEO claims that this linkage enables digital asset management applications that are “no longer limited to just the issuance of native tokens on the blockchain.”

Ethereum does not appear limited in this way despite its identification as a “world computer” that is not tied to any one government system of registry, identity, or law. It aims to provide a decentralized, global ledger, where anyone may participate without asking permission, identity is self-sovereign (i.e. private to and fully controlled by the user), and matters of ownership are decided by smart contracts (mostly[2]). Decentralized applications (dApps) to exchange non-governmentally managed real world assets such as file storage, computation, and user attention have already been built on Ethereum. Applications that may require stronger linkage to real world identity could be provided this information by users via identity management dApps, such as uport, and numerous dApps to digitize such real world assets are being developed. The Mattereum project is working on creating a “blockchain aware” legal infrastructure and smart contracts technology that makes the legal transfer of property possible on the Ethereum blockchain.

We are still in the early chapters of the asset digitization story, but we are already starting to witness how technology can change our relationship to traditional assets in ways that facilitate their digitization. Ride sharing and self-driving cars are predicted to change our relationship to automobile ownership and at least one company is building smart locks and Ethereum smart contracts to automate sharing economy transactions. More immediately, we are seeing how blockchain technology is changing our relationship to traditional stock ownership. Whereas Overstock pioneered issuance of traditional stock certificates on the Bitcoin blockchain after being granted approval by the US Securities and Exchange Commission (SEC), we’ve since witnessed hundreds of projects raising collectively over 2 billion USD by issuing their own tokens to a global market of investors, without the permission of any authority. These tokens don’t represent “real world” stock shares, but many of them serve effectively the same purpose as stocks in the eyes of investors and government regulatory bodies.

Initial Coin Offerings (ICOs) have created an alternative to traditional stocks for raising capital that is more inclusive of investors and projects, and not tied to any specific governmental jurisdiction or ID system, though local governments are beginning to impose restrictions and warnings that have real impact on the ability to raise funds from investors in their jurisdictions. So, even as the globalization and transformation of real world assets plays out, our brief glimpse at ICOs suggests that the local government agencies and systems of law that have been traditionally involved in asset regulation and ownership will be modernizing to stay involved. In the foreseeable future, decentralized applications will be subject to these local systems of law, whether they run on NEO or Ethereum. Platform differences may not matter nearly as much as differences in how local governments modernize, and it’s entirely possible to see NEO dApps rise to dominance in China, while Ethereum dApps dominate the west.

Smart Contract Security

The strategy of building bridges to legacy systems to facilitate adoption is pervasive in NEO’s approach to smart contract development. NEO is building bridges to existing developer communities by allowing smart contracts to be written in a number of popular general purpose programming languages, such as C#, VB.NET, F#, Java, and Kotlin. This strategy has the obvious benefit of facilitating ecosystem growth by allowing a wide range of developers to start building NEO smart contracts without the barrier of having to learn a new language and toolchain. The mature tooling around existing languages can be leveraged to improve productivity and reduce certain classes of bugs (as compared with the less mature Solidity programming language and tooling).

However, the use of existing languages are no “silver bullet” for smart contract development. Smart contracts have requirements for determinism and decidability that these languages were not designed for. All non-deterministic features, such as threads, I/O, random number generation, and time of day functions will need to be completely disabled for programs that run on a blockchain. Execution will require gas, and regardless of language, programmers will need to be cognizant of gas usage, and handle problems that arise when a transaction doesn’t provide enough. Contracts will need to call other contracts (that consume gas), verify digital signatures, send and receive funds, and perform other domain-specific operations that are not built into these languages, but will have to be implemented by libraries. In contrast, the Solidity programming language, which was designed specifically for smart contract programming, provides built-in support for a number of domain-specific entities such as addresses, cryptography, contracts, transactions, gas, and blocks. Whether or not the ability to develop smart contracts in in a familiar programming language speeds adoption and/or provides a significant productivity advantage over Solidity remains to be seen.

What’s far more important is whether bugs that introduce very costly vulnerabilities (which can extinguish an otherwise viable and thriving smart contract platform) can be prevented. The ability to call methods in ways the contract authors didn’t intend is a general vulnerability that was common to two high value exploits on the Ethereum platform, one via reentrancy and the other via delegation to library methods. Both of these useful programming mechanisms are found in the general purpose programming languages supported by NEO, and are not likely to be disabled by NEO’s smart contract-specific compilers. However, NEO’s runtime does prevent contracts from directly calling arbitrary methods on other contracts (they can only call Main), which effectively makes all non-Main methods in all NEO smart contracts private by default. This safety feature would likely have prevented the delegation to library methods exploit. There has been some discussion around changing the Solidity default from public to private, but until the language is officially changed Solidity programs will remain vulnerable to this kind of developer oversight.

The root problem affecting Ethereum and NEO equally is that programming a smart contract is more like programming a nuclear reactor than a website; it requires a completely different approach to development because the cost of any bug is potentially catastrophic. Even Solidity code that has been developed using best practices and subjected to code review, audit, and bug bounty hacking can still have exploitable vulnerabilities. The use of familiar programming languages will not help this situation, and might even make it worse if programmers unwittingly follow familiar programming paradigms.

NEO does have an advantage in not yet having large amounts of assets stored in smart contracts like Ethereum. As long as that is the case, most exploits will target high-value Ethereum contracts, putting the full cost of lessons learned on Ethereum while the resulting language modifications and best practices can be adopted for free by NEO and other platforms.

However, Solidity’s history shows that best practices followed by the best developers aren’t enough to prevent exposure to major loss of funds. Ultimately, languages and tools specifically designed to overcome human limitations and eliminate such vulnerabilities will replace the inadequate ones we have today. The platform that first supports these on a production blockchain will be on the fast track to dominance as it watches challengers suffer extinction by exploit. Although no platform has achieved this yet, the efforts of projects such as DFINITY and Tezos are ahead of those in the NEO and Ethereum communities in terms of vision and implementation.

Conclusion

NEO is a very ambitious project with a lot more innovation and development going on than we were able to touch on in this article. The NEO Council is funding numerous projects to support smart contract development, parallel execution, stakeholder voting, cross-chain asset exchange, distributed storage, a standard for token issuance, secure messaging, offchain order matching, and the incorporation of quantum resistant cryptography. That’s just a sampling; the NEO ecosystem is firing on all cylinders.

NEO distinguishes itself from Ethereum and other emerging smart contract platforms in some uncommon ways. It foregoes creating a domain specific language for developing smart contracts in favor of supporting a large number of existing, general purpose languages to speed adoption and community growth. By using BFT consensus and relying on a centrally controlled digital certificate authority for identity, it trades off decentralization and censorship resistance for high performance and streamlined integration with existing legal systems.

Although it’s fairly common for projects to have a roadmap that starts out more centralized and becomes increasingly decentralized over time, the tradeoffs NEO is making to bridge to existing systems could result in a long evolutionary path toward full decentralization, censorship resistance, and smart contract security in the wild. This path may turn out to be a winning strategy for permissioned consortium chains, especially in China, where NEO is most likely to leverage the existing legal system. In the quest for global dominance as a public chain, however, Ethereum and other platforms making different design tradeoffs, may have an advantage. However, a more global and revolutionary approach threatens to disrupt and potentially disintermediate some very powerful institutions, so these platforms might face some more institutional friction than NEO.

In China, it’s common for homegrown technology from providers such as Alibaba, Baidu, Weibo, Tencent to completely dominate and shut out western competitors like Amazon, Google, and Facebook. So it may very well turn out that NEO becomes the dominant smart contract platform in China, while another project achieves global dominance everywhere else.

Dominance threat levels are explained in the introduction to the series. Below is a brief legend.

[1] It may be possible to get elected without an identity certificate, we’ll know when the voting system is implemented

[2] In Ethereum’s early days, the DAO smart contract was overruled by Ethereum’s thought leaders with a small amount of community support, but still jurisdictional legal systems were not involved

Thanks to Ethan Fast for his input on early drafts.

If you’d like to support this series with an ETH donation, please send it to 0x7e83982eb92502ad5d38c400ba2af7b135469ac9

Your support allows and encourages me to devote more time to these articles and is greatly appreciated.

On the Origin of NEO was originally published in On The Origin of Smart Contract Platforms on Medium, where people are continuing the conversation by highlighting and responding to this story.