Posts

Blockchain Scalability Trade-offs Banner

Blockchain Scalability Trade-offs: How to Choose a Platform

Blockchain scalability is one of the most frequently cited reasons that blockchain adoption isn’t happening faster.

The truth is, most blockchain networks are slow when compared to traditional centralized technologies and networks like AWS or the Visa network. Ethereum, for example, can process transactions in the range of 15 transactions per second — and Bitcoin is even slower.

On the other hand, blockchain networks have unique properties, such as native digital scarcity and unstoppability, that cannot be achieved in the same way with centralized approaches.

As developers continue to experiment and iterate on novel uses of these properties in decentralized software applications, popular platforms are hitting up against scalability and transaction limits. In this context, blockchain scalability is widely seen as a limiting factor in further blockchain adoption among software developers and end users.

In response to these blockchain scalability issues, the community has poured a lot of energy into developing scalability solutions at Layer 2 (e.g. Lightning, Plasma) and migrating existing platforms to faster consensus mechanisms (e.g. Ethereum 2.0). These solutions are all interesting in their own right, but I would argue that they are less important for scalability than design decisions in the protocol itself, and the use cases which are being targeted by those designs.

Developers who are investigating which decentralized platform to build on should carefully consider their requirements and the design goals of the platform they are choosing relative to those requirements.  Two important trade-offs in order to achieve your optimum level of scalability for your application are the level of decentralization and the level of programmability that you require. Not every application needs maximum decentralization nor programmability.

The Top Two Trade-offs to Blockchain Scalability

Level of Decentralization

The Blockchain Trilemma

For those who are unfamiliar with the famous blockchain trilemma, it states that when designing a blockchain protocol, you can only have two of these three properties: security, decentralization, and scalability. The insight is that it is hard to achieve all three simultaneously.

From my point of view, the most interesting use cases for blockchains are related to the storage and movement of value, so any significant sacrifices to security seem like a non-starter.

The key point behind the trilemma is the relationship between decentralization and scalability. It is easy to achieve scalability if you sacrifice decentralization. For example, traditional deployments using AWS infrastructure achieve very high scalability in a centralized model. But in this deployment model, the key properties that make blockchains interesting — namely, native digital scarcity combined with unstoppability — disappear.

Some projects use this relationship to their advantage. Take the example of EOS. In the EOS network, there are 21 block-producing nodes. This is far fewer than Ethereum or Bitcoin. By becoming more centralized, EOS achieves far higher transaction throughput than either Ethereum or Bitcoin. Twenty-one nodes isn’t totally centralized, but it is much more centralized than many other blockchain networks.

EOS’s goal is to be decentralized enough to keep the most interesting blockchain properties intact, but centralized enough to achieve significantly higher performance than competing blockchain networks. The question to ask yourself as a DApp developer is, what level of decentralization does your use case require? How worried are you about censorship of your application? Many high-value-oriented use cases may require higher levels of decentralization; for others, it may not matter.

Level of Programmability

The level of programmability that is supported by a blockchain protocol is at least as important a factor for blockchain scalability as decentralization. The key question is, what use cases are your applications going after, and what level of on-chain logic do you need to achieve your goals?

I can think of a range of applications with varying needs for platform programmability, running from money and asset transfer use cases on one end of the spectrum to Web3/decentralized applications on the other end of the spectrum. A money transfer application, a securitized tokenization platform, or a marketplace for digital collectibles may be perfectly well served by a platform that supports a rich set of asset transfer use cases. Whereas, a DAO or decentralized exchange that needs extensive onchain logic would require a full Turing-complete programming environment.

All other things being equal, platform scalability degrades as you move toward a more decentralized model. Bitcoin seems to be an exception to this rule as it is firmly on the “money” end of the spectrum, but it also isn’t scalable. The point is that Bitcoin would be even less scalable if it had full Turing-complete smart contracting functionality.

Platform scalability also decreases as you add Turing-complete smart contract functionality. With Turing-complete smart contracts, you need a gas concept to meter contract execution and produce deterministic behavior, which adds fees and operational costs to your application. You also need to allow smart contracts to store arbitrary state or data on the chain, which leads to more fees and increased storage requirements for the underlying blockchain nodes. Most smart contract platforms have a single one-size-fits-all virtual machine for all contracts on the platform, which can also become a scalability bottleneck. All of these factors reduce the scalability and throughput of Turing-complete smart contract platforms.

Opposite Ends of the Blockchain Scalability Spectrum: Algorand and Ethereum

Let’s take a couple of concrete platform examples to illustrate the point.

Algorand Prioritizes Performance Over Turing-Complete Programmability

Algorand is a high-performance, next-generation blockchain that focuses on the money and asset end of the design spectrum, and is also highly decentralized (unlike EOS). It achieves very high performance and transaction throughput by focusing on money, asset, and asset transfer use cases and doing them well.

Algorand’s new scripting language, TEAL, is intentionally non Turing-complete to avoid the gas fees, arbitrary storage, and infinite loops that come along with Turing-complete smart contract platforms. These are specific choices that allow it to achieve high performance for the money, asset, and asset transfer scenarios. This is why applications supporting these use cases that have high throughput requirements, such as Tether and Securitize, are porting their applications to run on Algorand.

However, if your use case requires Turing-complete onchain logic such as DAOs, onchain DEXes, or the development of onchain decentralized protocols sitting above the base protocol layer like Compound or 0x, then the level of programmability in Algorand isn’t as good of a fit.

GET STARTED WITH PURESTAKE’S API SERVICE FOR ALGORAND

Ethereum Prioritizes Turing-Complete Programmability Over Performance

By contrast, Ethereum is the most prevalent full smart contract platform. Ethereum puts programmability first, at the expense of throughput and scalability.

Scalability issues on Ethereum result from arbitrarily complex logic execution and arbitrarily large storage that comes along with its smart contracts. Logic and storage are metered by gas fees, and these fees have increased over time as the number of smart contracts has increased. The underlying blockchain on an Ethereum full node (let’s leave out archival nodes for now) takes over 100GB of storage and growing. Ethereum has a small fraction of the scalability of Algorand from a transaction-per-second and node storage perspective.

However, what you get in return is the ability to express arbitrary smart contract logic in the Ethereum virtual machine. And since all the programs run in the same virtual machine, you get composibility between different contracts which is driving a lot of advances in the DeFi space right now.

For DApp developers, you should carefully consider which parts of your application need to be de-centralized / onchain, and if you really need a full Turing-complete smart contract language to build your application. Turing-complete smart contract platforms allow for arbitrary expressions of onchain logic, but often at a cost in terms of scalability and throughput.

Choosing the Right Platform for Your Application

The scalability of the underlying platform is a critical part of choosing where to build. Even if your application itself doesn’t need high levels of scalability, those scalability challenges inevitably lead to high transaction fees, which will increase your operating costs as an application project, and may make certain use cases unviable from an economic perspective.

You should carefully consider the level of decentralization and programmability you need to support your use cases when choosing a platform. For a use case that requires only an ERC-20 contract on Ethereum, but does not require interoperability with other Ethereum smart contracts, it may make sense to look at platforms that are optimized for this scenario, such as Algorand. On Ethereum, you could be paying a lot more unnecessarily without realizing the benefit of the increased programmability.

 

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