The Case for Ethereum Scalability
Understanding What’s Possible & What Comes Next
By Hunter Hillman (Connext), Steven McKie (Amentum), and Eric Olszewski; this post originally appeared on the Connext blog.
Over the past few months, we have noticed a significant number of articles proclaiming the imminent failure and collapse of the Ethereum platform due to its inability to scale and its overall lack of user traction. This is hardly a surprise; with many new emerging technologies, we see a similar hype cycle: the “Peak of Inflated Expectations” is followed rapidly by the “Trough of Disillusionment”. In the case of Ethereum, we have passed the former and are well on our way through the latter.
The concerns raised in these articles are legitimate, but generally ignore the staggering progress being made daily in regards to scalability. No, Ethereum cannot scale to become sort of world computer in its current state. The throughput is low and the cost is exorbitant. However, these issues were anticipated and have been well understood, since before the launch of Ethereum as a blockchain. In this editorial, we will discuss the various solutions which have been created the past few years to address these limitations.
In the midst of the ICO bubble, high transaction volumes crowded the network and raised gas prices. This brought scaling challenges — which Ethereum developers were well aware of and had already begun addressing — though to the media’s attention would make you think otherwise.
While Ethereum scaling may be a brave new world for some, the options for addressing throughput have been on developers radar’s for years:
Scale Ethereum itself to be able to handle the increased transaction load (e.g., Serenity and Casper)
Reduce the load on the main chain by moving the bulk of transactions to a second layer an only using the base layer during transaction settlement (e.g., Payment Channels, State Channels, Plasma, and Sidechains)
“Layer One” solutions like Sharding and Casper have been on the Ethereum roadmap for a few years, but have been plagued by multiple setbacks that have prevented significant progress on the implementation and development front. Even after these improvements, there will still be a need for “Layer Two” scaling mechanisms which provide even higher throughput, private transactions, and lower transaction fees.
Before diving into the various Layer Two solutions, we ask that you think of Ethereum as a global settlement layer rather than a holistic world computer. This means that Ethereum serves to settle any and all transactions which have been conducted off the main chain and enforce value transfers accordingly. It is this use case of the blockchain serving as an unbiased third party for arbitration on which all second layer solutions operate.
At a high level, any layer two solution follows this formula, or some variation of it:
Two or more parties agree to a set of rules by which they will be to join and exit a Layer Two solution.
These parties then encode those rules into a smart contract which requires that each party put down a security deposit.
After putting down their security deposits, all parties can operate between each other off-chain while submitting intermittent updates to the on-chain smart contract.
When one or more parties wished to exit the layer two solution, they will typically provide some cryptographic proof that is an accurate representation of each parties’ remaining security deposit.
There is a challenge period where the proof can be disputed and thrown away. If the challenge period elapses, then the related parties will exit the layer two solution with their updated balances.
Layer Two innovations like Plasma™ and Payment Channels/State Channels, some of which are already processing real payments in production, will facilitate the bulk of Ethereum transactions. Scaling a public blockchain (particularly one with such a robust consensus mechanism) is difficult, to be sure. But it is by no means impossible; in fact, smart contract support and the EVM allow for novel scaling solutions and greater extensibility than other chains attempting to scale with a second layer on strictly UTXO-based scripts, which aren’t as extendable, by design (a different set of trade-offs and benefits, like everything in Computer Science).
DApps’ struggles with user retention are well publicized, but years of scaling research and implementation are enabling the UX and low latency necessary to support high MAU dApps. In short, Ethereum’s Layer Two solutions are nearly ready for primetime (with firms like Cent and Spankchain [NSFW], and others, already serving mainnet users) and are poised to upend the narrative that Ethereum can’t scale. The proceeding sections discuss limitations of highly-touted traditional scaling methods and make the case for Ethereum’s suite of robust, generalizable solutions.
Traditional Scaling Methods: Off-chain and Lightning
Most traditional scaling methods boil down to the observation that many interactions don’t require rigorous consensus to be considered final by the parties involved. For example, if a retailer and a customer agree that a service was rendered satisfactorily in exchange for a specified payment, there’s no reason for third-, fourth-, and fifth-party confirmation to occur. What matters are two factors: (i) certainty that the payer will fulfill their side of the bargain, and (ii) that neither payer nor payee has to trust that a third party will faithfully execute the transaction on their behalves.
This framework allows us to consider off-chain scaling, wherein transactions are conducted off the main blockchain and later settled on the chain. To comply with (i), payers must cryptographically and irrevocably commit to transfer funds; to comply with (ii), those funds must be transferred in a trust-less manner and the transaction must be enforceable on-chain if need be.
These criteria underpin Bitcoin’s Lightning Network, which has (rightly) been the subject of widespread media coverage. Think of it like a bar tab: participants agree to pay small amounts over the course of an evening but only settle up at the end of the night. This is an oversimplification of Lightning Network of course; a more detailed explanation can be found here.
Lightning Network is undeniably good for Bitcoin and holds great potential for Layer Two bitcoin scaling. Due in part to extensive media coverage, Lightning Network is often viewed as a panacea for Bitcoin’s scaling issues. Meanwhile, there’s been a slew of articles hailing “Ethereum-killer blockchains” and opining that Ethereum is incapable of scaling. In a few words, this is wrong.
First, Ethereum is more than capable of scaling payment volume in a very similar manner to Lightning Network. Hashed Timelock Contract (HTLC)-based payment channels are just as feasible on Ethereum as they are on Bitcoin, and in fact Ethereum enables more innovative and user-friendly multi-hop strategies than Bitcoin can, and they can be deployed far more easily.
Because Bitcoin uses an unspent transaction output model (UTXOs), funds must actually be passed utilizing traditional cryptographic messaging methods to conduct transactions (even those off-chain). In contrast, Ethereum’s account balance system allows for simpler and less costly off-chain balance updates.
For example, Connext’s implementation of payment channels (which has been processing payments in production for Spankchain for nearly a few months) uses “threads”, a multi-hop implementation that allows parties to directly pass balance updates amongst themselves rather than relying on hash-locked payment routing. This is a computationally cheaper, equally fast, and equally secure approach that’s likely better suited to many transaction patterns than Lightning Network.
Moreover, complex contract interactions are a bit more overhead intensive to deploy, as bitcoin scripting is somewhat limiting. The UTXO model, though an excellent method for sending/receiving signed transactions to be verified on a blockchain-based network, means you have to augment your scripts for more novel use cases (i.e. escrows). With the generalizability of Ethereum, and the capability to create tokens/registries/non-fungible assets and other community accepted smart contract standards, building modular and interoperable contracts that target the EVM, is simply more seamless.
Generalized State Channels and Counterfactual Instantiation
Smart contract and EVM support on Ethereum enables a wide variety of applications that are not currently feasible on non-Turing-complete platforms like Bitcoin, due to its architecture and design decisions — which lower its overall attack surface, which in-turn puts greater focus on its permission-less P2P payments use case as its most touted feature.
Because Turing-complete scripts are more complicated to execute than simple transactions, however, these capabilities increase the overall congestion on Ethereum (and causes the size of the state to grow at a must faster pace).
We’ve already discussed how payment channels can cut fees and latency for peer-to-peer payments, but Ethereum supports much more complex transaction logic that payment channels don’t address.
Generalized State Channels, however, propose one solution to scaling issues associated with complex contract interactions. Right now, stateful contract interactions that enable the use cases that Ethereum is known for must be executed on the blockchain. The thinking of many Ethereum bears is that as more and more contracts are deployed, function calls will slowly overwhelm the network and drive gas prices through the roof (!!).
Layer One scaling, which has received the vast majority of media coverage, asks how we can accommodate more of these complex interactions on mainnet; Layer Two solutions like Generalized State Channels and Plasma (more on this later) ask how we can move more of these functions off-chain, while retaining the security and integrity we’re provided by the mainnet (given certain trade-offs).
The security of payment channels relies on the ability of each party to “go on-chain” and use a smart contract to adjudicate and rectify disputes. That is, payment channels let two parties behave as though they are transacting on-chain even though they aren’t. Because they have the ability to go on-chain at any time, as the balance updates that they send back and forth carry the weight of on-chain transactions; in a dispute the contract simply decides whose balance update is more recent by polling the mainnet chain. On-chain dispute resolution is costly though in terms of time and gas, so rational actors would avoid this scenario. And, if most state channels are using secure and audited standards, we can create interoperable systems with fast finality, that are bound by the same cryptographic assurances as mainnet interactions, with drastically reduced/almost zero gas cost.
This approach begs the question: if we can incentivize parties to behave as though a simple contract exists on-chain, can we do the same for more complex logic? One strategy is known as counterfactual instantiation. There are a few different implementations, but they revolve around the same principle: state is passed into the generalized framework once at the onset and can be manipulated according to a contract specified (but not deployed) when the channel is opened. Dispute cases are adjudicated by the contract as well. Because participants have the ability to go on-chain and invoke the contract, though, all are incentivized to behave as though it exists.
The effects of production-ready Generalized State Channels that leverage counterfactual instantiation will be two-fold:
Operations involving contracts that can now be counterfactually instantiated and will all occur off-chain; the sheer volume of deployed contracts will decrease relative to the status quo. This will reduce network congestion, benefitting contracts that must be deployed on-chain.
Operations that occur off-chain in Generalized State Channels don’t incur confirmation times or gas fees; this will radically improve user experience and allow Ethereum (as a whole) to accommodate orders-of-magnitude-larger transaction volume.
Connext, Counterfactual, Perun, and others are actively working towards Generalized State Channel frameworks which will directly address the network congestion, user experience, and cost issues that many cite as Ethereum’s Achilles heels. These solutions are enabled by smart contract functionality, are significantly more extensible than UTXO-based scaling solutions, retain the security of the underlying blockchain, and have the potential to unlock the new markets and business opportunities promised by Ethereum. We believe that Generalized State Channels have the potential to be as transformative for Ethereum as Serenity; whether due to poor information accessibility or inadequate publicity efforts, they have not gotten their (rightfully) due attention.
Exploring Lightning Network & Plasma
Lightning
Lightning was the starting ground for UTXO based payment channels, atomic swaps, and more. The work that has been done by Olaoluwa Osuntokun, Joseph Poon, and the entire ecosystem of Lightning researchers and engineers is impressive.
There are a few working implementations of the Lightning protocol and specification, including the LND project (by Lightning Labs, headed by its Chief Scientist, Olaoluwa — written in Go), and the C-lightning project (written in C).
On top of exciting additions like “Watchtowers” (services that watch your payment channels for fraud, and remain online so your node does not have to be — in return for a fee), the Neutrino wallet (Lightning Lab’s experimental light client — also written in Go), there are a slew of other improvements in the pipeline as the Lightning specification and developer community matures and grows.
Some of the hard research is currently focused on: Splicing (partial deposit/withdraw and parallel channel deployment); Wumbo (removal of the channel capacity limit); Multi-Path Payments (breaking a payment into several, allowing for it to be routed over multiple routes — think sharding); Hidden Destinations (public routes for payments to private channels) and more hard work is being done repeatedly at conferences and by independent teams all over the world.
The work by the Lightning team and scaling UTXO-based chains — utilizing some bleeding-edge implementations of crypto — is no small feat, and cannot be downplayed. The often problem is that people seek to directly compare Lightning and Ethereum’s Layer Two scaling measures using similar methodologies that don’t consider the trade-offs and unique capabilities the two varying solutions offer, due to the unique architecture of the underlying root chain (i.e. UTXO model versus the account model in Ethereum).
Plasma
Generalized state channels are far from the only option for scaling Ethereum.
Plasma is a second-layer scaling solution that, in-tandem with state channels, seek to provide additional throughput, and finality, but with some additional trade-offs.
Plasma, which you can think of as more a “proto-chain”, one that seeks to mimic as much of the root chain’s integrity and security as possible, just with a varying cost component, which is typically higher than when compared to state channels (due to replicating more of the main chain’s functionality onto a new substrate above it).
Plasma takes the entirety of the off-chain state, and maintains a fullstate of it, hashed to the root mainnet chain (which has its own set of risk trade-offs, though that’s constantly being improved through additional research).
Though throughput can be greater than the main chain’s, unlike state channels where there is no formal consensus algorithm, Plasma chains can bring their own unique consensus algorithm, complete with its custom blocktimes, too (which possess their own series of trade-offs). Although throughput/finality is not as fast, they are far more permissible and accessible when compared to state channels, as anyone can access the root chain’s state that’s been broadcasted and join — whereas state channels are only available to their agreed upon counter-parties (in most current implementations). And, state channels are no longer available after a channel closes, making them economic machines with finite lifespans, as they are purposely built to be more semi-permanent.
Though in Plasma, since you have to save every state interaction into the root chain, from your child chain, these costs are higher depending on which version of Plasma you opt to implement. With breakthroughs in how to best implement Plasma happening regularly with many teams spread globally, we’re sure a common standard will arise with a sensible set of trade-offs that can be applied to a wide array of use cases.
Power of Interoperable Standards
Non-custodial liquidity and how to most efficiently and securely transmit it in a number of different scenarios involving n >1 participants is an on-going discovery that continues to expand on the emerging science of cryptoeconomics and how various mechanisms operate in adversarial conditions.
ERC standards like ERC-20/ERC-721 make make Ethereum Layer Two scalability tech and dApps more socially secure, given there are community accepted norms and best-practices around which standards to implement for certain use cases. This is especially important when these various standards — which eventually seek to interact with one another fluidly to enable “decentralized finance” — can talk and communicate interoperably, with minimal friction and cost.
Those frictionless interactions and economies that spring up from the novel interoperability between tokens, non-fungible assets, and Layer 2 scalability create further security for the greater Ethereum network, because all participants are now intertwined in complex economic activity on the additional layers above it; all being built on secure standards, that were audited and accepted by the greater technical community.
The importance of non-custodial architecture, combined with the path of least resistance to the most extendable and generalizable functionality, cannot be understated. These are crucial components and primitives to bringing new and novel economic machines to life, that thanks to expense, regulation, and computational limitation, were once thought impossible to implement into the real-world.
Time For A New Narrative
Scaling blockchains is difficult, and Ethereum is no exception. But lionizing “Ethereum-killer” blockchains, or its pre-existing alternatives, all because Ethereum supposedly can’t scale, minimizes the remarkable work that the Ethereum community is doing on Layer Two technology. Layer One solutions are in the works and will likely prove transformative for the network down the road, but Layer Two solutions are hitting the market now.
The narrative that Ethereum can’t scale and the idea that Layer One solutions are the only plans to scale the network are tiresome and are being actively disproven in production environments on a daily basis. Today, Ethereum is a slow and unstoppable platform for programmable money; the potential of such a system is self-evident. An entirely novel financial system could be built on top of Ethereum, and Layer Two solutions will pave the way for radical new markets that leverage this decentralized financial stack.
Value transfer, governance, new kinds of markets and incentive structures, community coordination, and even proper implementation of tax policy are possible on Ethereum. Ethereum developers see this future and are building the dApps to make it happen. Other Ethereum developers are building the protocols to make the network usable at a large enough scale to usher in that future.
This editorial is not intended as a knock on alternative blockchain implementations, many of which are pushing forward the bleeding edge of cryptographic research as stated prior. Nor is it a case for ICOs, shilling, and misguided hype. Rather, it is a case for Ethereum scalability, for a decentralized economic future that uses the Ethereum blockchain as a settlement layer and facilitates the bulk of transactions with Layer Two technologies. It is a case for the Ethereum that we see, and that we hope will get its due in the public eye, and see the light of day.
Subscribe to our Newsletter to get this in your inbox:
Amentum GP Newsletter
Essays and analyses from the Amentum GP team.amentum.substack.com
State Channel Resources & Guides:
General Discussion and Articles:
ETHResear.ch
LearnChannels
Github Curated Resource List
Lightning Ecosystem Breakdown
Getting Started with State Channels:
State Channels For Babies: Part 1
State Channels For Babies: Part 2
State Channels For Babies: Part 3
State Channels for Developers:
The Redemptive Greed That Will Drive Decentralization: Part 1
The Redemptive Greed That Will Drive Decentralization: Part 2
State Channels For Dummies: Part 1
State Channels For Dummies: Part 2
State Channels For Dummies: Part 3
State Channels For Dummies: Part 4
State Channels For Dummies: Part 5
State Channels For Dummies: Part 6