Posts

Polkadot vs Ethereum Comparison Blog Banner

Choosing a Platform: A Comparison of Ethereum vs Polkadot

Polkadot is one of the most highly-anticipated next-generation, developer-focused blockchains. This comparison with Ethereum, the most widely adopted developer-oriented chain, is meant to help newcomers to the networks understand the differences between the two, and may help developers choose which one to build on.

At a high level, the two projects are only partially overlapping. Ethereum is a platform for deploying smart contracts, or pieces of logic that control the movement of native assets or state on the single Ethereum chain. In contrast, Polkadot aims to provide a framework for building your own blockchain and an ability to connect different blockchains with each other. Despite these differences, both platforms are designed for developers to build decentralized applications.

Despite Similarities, Very Different Strengths

In terms of similarities, both Ethereum and Polkadot aim to provide a space where developers can create decentralized applications. Both platforms include smart contract functionality, based on Solidity for Ethereum and Ink! for Polkadot. If we look forward to Ethereum 2.0, both platforms are pursuing a scaling strategy based on parallelized execution. Each thread of execution is called a shard in Ethereum 2.0, and a parachain or parathread in Polkadot. Both Ethereum 2.0 and Polkadot will use Wasm as an underlying technology to power on-chain logic and state transitions.

There are, however, important differences between Ethereum and Polkadot.

One of the biggest differences is design goals. Ethereum aims to be a platform for distributed finance and smart contract execution, whereas Polkadot has a vision of helping people build entire blockchains and integrating these blockchains with each other.

I have attempted to summarize what I consider some key points of difference below:

Ethereum 1.0 Ethereum 2.0 Polkadot
Architecture Single chain Multiple chains (shards) Multiple chains (parachains, parathreads)
Backend Development Solidity (JavaScript-like), Vyper (Python-like) Solidity (JavaScript-like), Vyper (Python-like) Rust, Substrate Framework
Execution Environment Single VM Multiple homogenous shards Multiple heterogeneous parachains
Composability Smart contracts can call each other synchronously Smart contracts can call each other synchronously in the same shard, or asynchronously between shards Smart contracts can call each other synchronously in the same parachain, or asynchronously across parachains
Governance Off chain Off chain On chain (e.g. Democracy, Council, Treasury modules)
Consensus Mechanism Ethash Proof of Work Casper Proof of Stake BABE/GRANDPA Proof of Stake
Program Execution Fees Per-call gas/metering-based Per-call gas/metering-based Market cost for parachain slot with unlimited usage or per-call parathread fee
Status (as of Nov 2019) Live since 2015 Will be released in phased milestones through 2021 MainNet launch expected in Q1 2020

LEARN MORE ABOUT STAKING ON POLKADOT WITH PURESTAKE

Ethereum: Large & Thriving, But Hitting Scalability Challenges

Ethereum’s key strength is its large and established ecosystem of developers, users, and businesses including its rich set of developer tools, tutorials, etc. It already enjoys significant network effects from this ecosystem, making it the de-facto smart contract platform to develop on. Ethereum standards, in many cases, become industry standards such as ERC-20.

The value of the Ethereum network is similarly significant, providing a high degree of economic security based on the value of the underlying Ether token. The DeFi space, which is one of the areas in the crypto space with the most developer traction, is largely built on Ethereum and leverages the composability between different Ethereum smart contracts that can call each other in the single Ethereum virtual machine that powers Ethereum 1.0.

The key challenge facing Ethereum is scalability. The success of the CryptoKitties application demonstrated some of the scalability limits that affect Ethereum 1.0. One popular application was able to significantly degrade the performance and throughput of transactions on the network.

Another challenge is the gas cost required to run smart contracts on the platform. Gas fees are required for the security of the system overall, and to protect the system from being stalled by runaway programs. But as the value of Ether has risen, gas fees for running smart contracts has also risen and has made certain use cases prohibitively expensive. These costs tie back to scalability, because if there were more capacity, the fees for each transaction could be lowered.

Ethereum 2.0 aims to solve all of these scalability issues, but it is multi-year roadmap with the execution risk that comes with a multiyear re-platforming initiative. Most of the Ethereum core dev energy is going into Ethereum 2.0, which leaves not much in the way of upgrades and improvements in the existing Ethereum 1.0 chain.

Polkadot: Built on a Flexible Framework, But It’s New and Unproven

Polkadot’s greatest strength is Substrate. Substrate is a development framework for creating Polkadot-compatible blockchains, offering different levels of abstraction depending on developer needs. Polkadot is itself built using Substrate. It dramatically reduces the time, energy, and money required to create a new blockchain.

Substrate provides a much larger canvas for developers to experiment on, as compared to smart contract platforms like Ethereum. It allows for full control of the underlying storage, consensus, economics, and state transition rules of the blockchain, things which you generally cannot modify on a standard smart contract platform.

The design of Polkadot — which allows for shared security within its network — is another strength. Shared security has 2 key benefits.

First, it reduces the burden on parachain builders by providing security-as-a-service from the relay chain. This is different than the approach taken by other networks such as Cosmos, where each zone is fully responsible for its own security. This shared security simplification lowers friction for builders and simplifies the process of launching a new parachain.

Second, shared security provides a framework for parachains to talk to each other, which ultimately allow will parachains to specialize. It reminds me of the old Unix philosophy, where you create tools that do one job and do it well. Then you can achieve higher order goals by combining these purpose-built tools together. I can see something similar happening in the Polkadot ecosystem. This is the power of the Polkadot design that should create strong network effects on the network.

To mirror the old real estate saying, the top three challenges for Polkadot are in my mind are: adoption, adoption, and adoption. Ethereum has a dominant position and the largest developer community of any developer-oriented platform. Further, there are a lot of new platforms coming to market that are looking to compete with Ethereum and gain developer mindshare.

At present, there are only so many developers to go around. We are in a situation where there are more developer platforms than there are developers to support and build on them. The real challenge for Polkadot is getting enough traction and building enough of an ecosystem and developer community for the network effects of their architecture to start to kick in.

How to Choose

In summary, if you are a developer researching these two platforms for your decentralized application, it is a little bit of an apples-and-oranges comparison.

Building on Ethereum is a safe choice and makes sense if your application can be expressed easily as a smart contract, if your use case is affordable in terms of gas fees, if you don’t need a large amount of transaction throughput or control over the underlying economics of your system, or if you need interoperability with other Ethereum ecosystem projects at launch. Development on Ethereum is generally going to be simpler than Polkadot.

If on the other hand, your application is best served by a dedicated blockchain, if it needs higher transaction throughput performance, if you want full control of the environment, state transition function, storage, and economics that your application runs under, and if you are okay with higher implementation complexity, or have use cases that require integration across blockchains, Polkadot will satisfy these requirements.

Have KSMs on Kusama? Nominate PureStake via This Address:

GhoRyTGK583sJec8aSiyyJCsP2PQXJ2RK7iPGUjLtuX8XCn

Validating on Polkadot: The First 11 Days Banner Image

11 Days Validating on Kusama: First Impressions & Emerging Power Dynamics

It has been 11 days since we joined the active validator set for Kusama, and I wanted to share some initial thoughts on the experience in case this is helpful to other validators, nominators, or other participants thinking about engaging with Kusama or Polkadot.

The first impression to convey is that interest in Kusama and Polkadot is high. Currently there are 140 validators that have signaled their intent to validate. Since Kusama switched from PoA to PoS thus switching block production from a limited set of Web3 Foundation-run validators to a decentralized set of validators, the number of validator slots has incrementally increased from 20 to 50, 60, 75, and currently stands at 100. At no time have there been any empty slots and there are currently 40 validators waiting for an opportunity to validate.

This stands in contrast to many other projects that have struggled to recruit enough competent validators to launch their networks. This is a really good sign for Polkadot as they near their MainNet launch.

Parity Team Actively Addresses Bumps in the Road

The process of launching Kusama has and continues to flush out issues.

There have been several point releases: 0.6.7, 0.6.8, 0.6.9, including an issue with 0.6.8 that led to database corruption for some validators. There are performance issues actively being worked on now, which will undoubtedly lead to more releases. Some validators have been slashed or removed from the active set, either due to issues with the software or a failure to run nodes properly.

However, the number of issues has really been relatively small. In each case, the Parity team has been very responsive in diagnosing and fixing issues. All things considered, for a system as complex as Kusama, this has been a very smooth launch process.

Two Primary Types of Validators

The validators in the active set are ones that meet the minimum effective staked KSM levels needed to be in the top 100.

Many of these appear to be representing DOT holders who could claim KSM based on their DOT holdings and thus, have large bonded amounts. I’m inferring this from the fact that transfers are not yet enabled, so large positions would have to come from claimed KSM.

The other set of validators are those that are not existing DOT holders and received KSM grants from W3F to be able to validate. The grants were 10 KSM, so I’m assuming that many validators with bond amounts less than 10 KSM are likely in this bucket. Many of these validators have received nominations, presumably from W3F and possibly others, to get into the active set.

There hasn’t been enough time for validators to really start to market themselves to try to attract nominations. This will presumably start to happen as the Kusama launch process continues to unfold, transfers are enabled, and the validator limit is potentially raised further.

LEARN MORE ABOUT STAKING ON KUSAMA WITH PURESTAKE

NPoS Validator Strategies

While it is too early to tell what strategies validators will use to go to market, there is one notable strategy that has emerged: the “sprawl” strategy.

Cryptium Labs is currently running 19 of the 100 validators in the active set. This is far more than anyone else on the network at this time. In NPoS (Nominated Proof of Stake) this is not only allowed, but perhaps expected. Given the fact that validators are compensated a flat fee for their service, running as many validators as can get into the active set is an economically rational validator strategy.

However, for some, the realization that large players could occupy may of the available slots was disheartening. Here is an exchange from the Riot rooms (where most of the discussions are happening) that illustrates the sentiment:

Fredy from DragonStake started with:

@derfredy:matrix.org

I wonder how the core ( Gav Bill | W3F federico … ) feel about the current adrianbrink | Cryptium Labs sybil attack.

Once we enable the TXs, the whole slots table could be filled with just 2 or 3 independent validators teams. Any concern?

Adrian from Cryptium Labs was quick to respond:

adrianbrink | Cryptium Labs

[snip…] public blockchains need to be designed so that they are secure against rational actors. Security based on altruism isn’t going to last long.
Btw, I’m not suggesting that Polkadot consensus is insecure. Maybe there needs to be more education about it though

And finally from Gavin:

Gav

i think it’s reasonable for w3f to use its KSM to keep the validator community pluralistic.

[snip…]

w3f has its funds;
w3f should act in whatever way it feels is best for the network;
having an active validator community with well-dispersed knowledge is good for kusama;
w3f should use some of its funds to help keep lesser staked validators of high reputation engaged.

This short exchange cuts right to the heart of some of the interesting ideas and dynamics around NPoS and how it will play out. Some good questions that this exchange raises: Will the NPoS design ultimately favor a smaller set of larger validators occupying multiple slots, or will it drive greater validator diversity? Is there such a thing as economically rational behavior that conforms to the protocol, but that nevertheless should be sanctioned or discouraged by social norms and convention?

NPoS is meant to be an improvement over standard DPoS in networks like Cosmos or Tezos. Its design does appear to be intended to discourage or prevent the concentration of stake behind any one validator, as doing this would lead to less staking returns for rationally-motivated nominators.

It is also meaningfully different from standard DPoS (Delegated Proof of Stake) because it has a separation between political power and validator services. This could guard against scenarios where, for example, validators are run for free to gather political power, as appears to be the case with the largest Cosmos validator. Many feel this leads to a weaker validator set, as it becomes difficult to fund legitimate validator businesses.

But if validator power can still be expressed in NPOS by allowing organizations or entities to have more than one — or perhaps dozens — of validators, it seems that some of the decentralization benefit of NPoS may not be as great as many believed would be the case.

I sympathize with Fredy from DragonStake’s point of view that the health of the network is greater with a more diverse set of validators, and that smaller validators shouldn’t have to rely on the goodwill of the W3F to have a shot at making it into the active set. And while W3F’s commitment to validator diversity is admirable, I also agree with Adrian from Cryptium Labs that what happens on these platforms is largely determined by the actions of rational economic actors playing by the rules codified in the protocol. Even if you have a set of social norms you try to enforce in your community, the permissionless nature of these systems means that someone can always come along and ignore your community and norms and do anything that the protocol allows.

It is always hard to predict how these systems will play out. But it seems likely that larger and better-established validator companies will pursue a Cryptium-style strategy on Polkadot. We may not see this yet, as they don’t want to tip their hand or take on the infrastructure expense on Kusama where the opportunity for profit is not possible. It will be interesting to see if, in the end, there is more or less validator diversity in Polkadot with NPoS versus Cosmos, Tezos, and other networks employing the simpler DPoS mechanism.

Decentralized Networks Are Magic

In the end, what has happened over the last 10 days demonstrates the magic of these new decentralized platforms. Probably something on the order of 100 organizations or people from different backgrounds, locations, skills all came to the table with complicated setups of software and infrastructure to help launch and support a network.

This network is something larger than any one participant could have created and wouldn’t be possible without the contributions of all of the participants. I can think of no better example of the power of platforms like Polkadot to organize people and activity in ways that weren’t previously possible, to allow anyone to join, to compensate the participants for their contributions, and to create something emergent and higher order as a result.

Keep an eye out as transfers will be enabled on Kusama soon, and I expect further shifts of stake and in the active validator set once that happens. Also feel free to leave me feedback on Riot if you agree (or disagree) with anything in this post: @mechanicalwatch:matrix.org.

Interested in staking with PureStake on Kusama? Nominate this address:

GhoRyTGK583sJec8aSiyyJCsP2PQXJ2RK7iPGUjLtuX8XCn