@adlrocha - Enter the world of Layer 2 improvements
i.e. how to escape the nightmare of high transaction fees
Originally published at BlockchainWorks. Read it here!
With Ethereum’s price soaring over the psychological threshold of $1,000, sending a single transaction to Ethereum’s chain (L1) is becoming prohibitively expensive. The figure below depicts the average transaction fee of an Ethereum transaction in USD throughout the past year. At the time of writing, the average transaction fee is over 5$ per transaction (not too bad), but a few days ago we almost reached the 18$ mark. If you’ve been regularly interacting with Ethereum DApps these days, your ETH balance may be suffering trying to fund all of your transaction; if, on the other hand, you are a blockchain startup subsidising the transaction fees of your thousands of users, well… I wouldn’t be surprised if you are bankrupt by now.
Fortunately, this is a well-known limitation of the Ethereum network, along with its scalability, and as such there are already schemes in place to circumvent these issues in the shorter and longer term. Allow me to welcome you to the fascinating world of Layer 2 (L2) improvements.
On the importance of L2 schemes
The term “Layer 2” is used to refer to any solution or protocol designed to help scale Ethereum applications. They are called Layer 2 solutions because they complement Ethereum’s core protocol, i.e. the Layer 1. Their use doesn’t require any change over the base protocol (no forks or node updates required). The main goal of Layer 2 solutions is to minimize the number of transactions that an application needs to commit to the Ethereum blockchain for its right (and secure) operation. This has several interesting consequences:
By minimizing the number of transactions sent to mainnet, we are minimizing the fees we need to pay for our application’s operation. So these Layer 2 solutions enable us with an escape boat to the “fees nightmare” Ethereum is becoming these days.
The fact that through L2 solutions one can perform valid transactions without having to commit them immediately to the main chain gives developers the ability to build high-throughput applications. No more worrying about Ehtereum’s 15 secs average block validation time or 15 transactions per second.
Finally, being able to perform transactions without having to wait 15 secs for them to be validated is a huge leap forward in terms of UX for decentralized applications. Who has not despaired more than once waiting for its transaction to come through before doing something else?
L2 solutions pave the way for Ethereum’s scalability. They offer an infrastructure on top of the network to scale without compromising its base decentralization and security, and avoiding breaking changes in the core protocol right away (enabling a progressive migration).
L2 solutions for all tastes
All L2 solutions are based on the same principles. They build an infrastructure on top of Ethereum which accepts user transactions, validates them, aggregates them, and commits them to Layer 1 (i.e. Ethereum’s main chain). The aggregation of transactions is done in a way where they can still be individually verified once they are anchored to mainnet. Thus, L2 transactions can be considered secure and immutable the moment the L2 batch they belong to has been anchored to mainnet. The specifics of how this is done varies substantially among L2 solutions, but let’s have a look at two wide-spread L2 solutions to understand their operation in detail.
Rollups are solutions that bundle (or “roll up”) sidechain or off-chain transactions into a single transaction that is then committed to L1. To secure all of these bundled transactions, and to make them individually verifiable, a cryptographic proof is generated from the bundle. In the early days, this proof could be something as simple as a Merkle Proof, but with the recent advancements in cryptography, these proofs are now generated through zk-SNARKs (zero knowledge succinct non-interactive argument of knowledge), and other zero-knowledge constructions.
A requirement for rollups to work is to have some kind of Ethereum-compatible independent blockchain (either with a reduced number of nodes or with additional features for high-performance) responsible for handling signature verification, contract execution, etc. able to verify the validity of the transactions that are afterwards bundled for their commitment in the main Ethereum chain. L2 rollup sidechains are responsible for verification and contract execution, while the L1 exclusively stores immutably transactions’ data.
Rollups are the perfect L2 solution if you want to reduce users fees (you pay fees for a single L1 transaction for each X transactions bundled from the side-chain); open participation (there are no prerequisites to start using rollups, just install your preferred sidechain compatible client, and start sending transactions seamlessly); and fast transactions throughput (bear in mind that the sidechain is in the end an independent Ethereum-compatible blockchain with its own ledger, its own consensus, and its own economy. Without any changes in Ethereum’s L1 protocol we can leverage its trust while operating in a high-performant sidechain).
Actually, this approach of sharding several sidechain networks processing and bundling transactions independently, and committing them to a main chain is the core architecture proposed for Ethereum 2.0 (which was already briefly introduced in this newsletter).
Rollups can be classified into two types according to the security model they use:
Zero-Knowledge Rollups (a.k.a ZK-Rollups) perform the computations of bundling hundreds of transactions into a single transaction off-chain. This process generates a proof of validity (using zk-SNARKs) of all the transfers included in the bundle. This transaction including the proof is then submitted to a smart contract on-chain that through the proof verifies the validity of all the transactions in the bundle, committing their state accordingly in the main chain. This process is known as “the validity proof”. Validating blocks using ZK-rollups is quicker and cheaper than individually sending the transactions to mainnet (even for small computations), as the information of the hundreds of transactions included in the bundle is compressed and sent on-chain in a proof of a few KBs. Some examples of technologies using ZK-rollups are: Loopring, StarkWare, MatterLabs, Aztec.
Optimistic Rollups: In this scheme, participants are “optimistic” about the validity of the transaction being performed in the sidechain. There is no need for any computation to commit sidechain transactions into the main chain. And how can be sure that sidechain transitions are actually valid? Optimistic rollups use faud-proofs to ensure that all transactions are legit. If someone notices a fraudulent transaction, the rollup will execute this fraud-proof and run the transaction’s computation to verify its validity. This means that instead of performing a verification for every single transaction, like in ZK-rollups, we only perform the proof computation if we have suspicions that a transaction is fraudulent. This significantly reduces the gas costs compared to ZK-rollups, and opens the door to the ability of achieving x10-x100 improvements in the transaction throughput. This rollup approach is the one being considered for Etheruem’s 2.0 shard chains, and is already used by Optimism, Offchain Labs and Fuel Network.
But L2 improvements does not live by rollups alone! Another wide-spread L2 solution used by many DApps in the Ethereum ecosystem are state channels and payment channels. Channels allow participants to transact a finite number of times while only submitting two transactions to the network on chain: one to open the channel, and another one to close it and commit the state updates. This allows for extremely high transactions throughput without the need of side-chains or an external infrastructure. Bitcoin Lightning network and Ethereum’s Raiden, which you have probably already heard about, are two well-known L2 solutions based on channels.
These L2 solution are really useful if your app needs to perform lots of state updates (like in micropayments or games). The only thing to keep in mind before using channels is that they can only be used when the number of participants are known upfront, and if we can be sure participants will be available throughout the life of the channel.
Channels work as follows:
Participants lock a portion of Ethereum’s state, like an ETH deposit, into a multisig contract in the main chain to account for the payments and computations of the state channel. A multisig contract implements logic that requires the signature (and thus the agreement) of multiple users to run. Bitcoin also supports multisig transactions in its scripting language, so we will be able to use simple L2 channels even without support for the execution of smart contracts.
This first transaction locking the funds opens up the channel. With the channel open, participants are allowed to perform transactions off-chain between them up to the amount locked in the contract. The acknowledgement of an off-chain transaction is a voucher signed by all the participants involved in it. Every new transaction bundles in its voucher the previous one (i.e. every new voucher is an update of the previous one building a chain).
When the interaction is finished, the participant with the last acknowledgement submits it on-chain in a final transaction to the contract. This transaction verifies the final state of the off-chain interactions, updates the balances of the participants, returns the corresponding balance to each of the participants, and closes the channel.
There are infinite ways of implementing these channels, but according to their complexity, they are usually categorized in these two types: payment channels (simpler and only used to deal with payments, these are the ones used in Bitcoin); state channels (more complex and able to support more complex computations and not just payments, these are used for complex applications such as games).
Finally, to learn the details about channels, I highly recommend checking this simple Solidity example that explains how to build your own micropayments channels for Ethereum. If you are not afraid of code, this is the perfect way to get your hands dirty and deeply understand how channels work.
And there’s more!
You may be wondering, all L2 solutions are rollup or channel-based? Well, not exactly. There are hybrid solutions, more complex constructions of optimistic and ZK rollups, full-fledged sidechains, and much more. But I think this is enough for today. If you want to keep learning about L2 solutions in my absence take a look here and here. I hope that if you've made it this far you're not as scared about Ethereum’s transaction fees and its scalability limitations anymore and you start BUIDLing hard!. Remember, there is always an elegant L2 solution for everything 😎 See you next week!
Publication originally written for BlockchainWorks. If you want to see one of my publications premiered in your site (before making it to the newsletter), or you want to be featured in this newsletter with one or your pieces, do not hesistate to get in touch with me! 📲