On the Origin of Polkadot

Published in

On The Origin of Smart Contract Platforms

25 min readMay 27, 2019

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.

Image from A brief summary of everything Substrate and Polkadot

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.

Image from GRANDPA Block Finality in Polkadot: An Introduction (Part 1)

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.

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.

Image of AGP-35 support over time from Brett Sun

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.