If you’ve been here long enough, you would have already heard of the blockchain trilemma where you can only pick two out of three between security, speed, and decentralization. But that is so 2020.

Some years ago, we expect one single blockchain to perform various functions for us. For instance, Ethereum has become congested because it was juggling between validating incoming transactions, arranging them into blocks, executing them, and finally keeping all these growing records available at all times. That was a lot of tasks. And it slows down the network. So Layer 2’s and sidechains were made to decongest it by delegating the task of computation for L1s and then pushing the result of multiple transactions within a single transaction to L1.

Sounds simple. And then we ask clarifying questions like, how do these L2 solutions prove to L1 that the transaction they process is actually valid? That’s how we get to proving systems, and there are two types:

1. Fraud Proofs

   Fraud proofs are used by optimistic rollups. Optimistic rollups just assume that all transactions are valid and pushes them to their block, which sounds a little crazy but is actually secure because there are fraud proofs. There will be a time window for anyone to challenge the block made in L2 before it becomes accepted in L1.

   To challenge a transaction’s validity, anyone can compute a fraud proof which is basically a proof of mismatch between specific parts of the merkle tree and the condensed data on the merkle root. When a fraud proof is accepted, the rollup simply re-updates its state and the block builder who included the invalid transaction gets a penalty.

   You gotta note that we require that data from L1 be accessible to L2 in order for challengers to produce a fraud proof.

2. Zero-Knowledge Proofs

   Zero-knowledge rollups also bundle up transactions and summarizes their blocks to L1. But unlike fraud proofs, validity proofs don’t need a challenge period to finalize state changes. It uses zero-knowledge cryptography to prove that the changes being pushed to L1 is indeed a result of executing valid transactions made on the rollup. Once the validity proof is submitted to L1, then the state changes are instantly accepted.

   Now this wouldn’t require any access to L1 data, because they are merely sending a proof of computation that happened within the zk rollup.

   There are many cool ways to design a zk rollup, and there are many flavors of this cryptography to choose from (eg. SNARKS, STARKS, etc.), but I would have to write the comparison in a separate post. Hekk, I might wanna write about how a typical proving circuit in zk-rollups look like. But moving on…

You might notice that data availability is sometimes an issue if the historical transaction needs to be proven as valid by other chains. But storage in the blockchain is expensive, and nodes have to continuously store a growing history if they want to make the data available. So to give us options, we have at least three types of L2 solutions:

1. Rollups – a layer that executes the transactions and then sends a proof AND a record of all these processed transactions as call data to L1.

2. Validiums – only executes the transaction and sends a proof of validity to L1. Incredibly cheap but has a chance of locking your funds in the validium. Great use for not-so important transactions like on-chain games.

3. Volitions – lets the user decide whether to use a validium or a rollup for their transaction.

And then there are also sidechains whose history is separate from the L1 and has its own consensus model (they don’t do any proving to L1 and don’t inherit its security). Sidechains are merely connected to L1s by a two-way bridge that can move assets between the chains.

Ok folks, that’s the execution layer. Now people can have the option of faster transaction processing through these L2s. Although with this design we are still putting strain on L1 because it has three jobs to do: making the network agree on just one version of truth (the blockchain’s state), deciding on how to sequence the transactions, and storing all that transaction history. We’re gonna be munching on these next, but for now GN!

If you’ve been here long enough, you would have already heard of the blockchain trilemma where you can only pick two out of three between security, speed, and decentralization. But that is so 2020.

Some years ago, we expect one single blockchain to perform various functions for us. For instance, Ethereum has become congested because it was juggling between validating incoming transactions, arranging them into blocks, executing them, and finally keeping all these growing records available at all times. That was a lot of tasks. And it slows down the network. So Layer 2’s and sidechains were made to decongest it by delegating the task of computation for L1s and then pushing the result of multiple transactions within a single transaction to L1.

Sounds simple. And then we ask clarifying questions like, how do these L2 solutions prove to L1 that the transaction they process is actually valid? That’s how we get to proving systems, and there are two types:

1. Fraud Proofs

   Fraud proofs are used by optimistic rollups. Optimistic rollups just assume that all transactions are valid and pushes them to their block, which sounds a little crazy but is actually secure because there are fraud proofs. There will be a time window for anyone to challenge the block made in L2 before it becomes accepted in L1.

   To challenge a transaction’s validity, anyone can compute a fraud proof which is basically a proof of mismatch between specific parts of the merkle tree and the condensed data on the merkle root. When a fraud proof is accepted, the rollup simply re-updates its state and the block builder who included the invalid transaction gets a penalty.

   You gotta note that we require that data from L1 be accessible to L2 in order for challengers to produce a fraud proof.

2. Zero-Knowledge Proofs

   Zero-knowledge rollups also bundle up transactions and summarizes their blocks to L1. But unlike fraud proofs, validity proofs don’t need a challenge period to finalize state changes. It uses zero-knowledge cryptography to prove that the changes being pushed to L1 is indeed a result of executing valid transactions made on the rollup. Once the validity proof is submitted to L1, then the state changes are instantly accepted.

   Now this wouldn’t require any access to L1 data, because they are merely sending a proof of computation that happened within the zk rollup.

   There are many cool ways to design a zk rollup, and there are many flavors of this cryptography to choose from (eg. SNARKS, STARKS, etc.), but I would have to write the comparison in a separate post. Hekk, I might wanna write about how a typical proving circuit in zk-rollups look like. But moving on…

You might notice that data availability is sometimes an issue if the historical transaction needs to be proven as valid by other chains. But storage in the blockchain is expensive, and nodes have to continuously store a growing history if they want to make the data available. So to give us options, we have at least three types of L2 solutions:

1. Rollups – a layer that executes the transactions and then sends a proof AND a record of all these processed transactions as call data to L1.

2. Validiums – only executes the transaction and sends a proof of validity to L1. Incredibly cheap but has a chance of locking your funds in the validium. Great use for not-so important transactions like on-chain games.

3. Volitions – lets the user decide whether to use a validium or a rollup for their transaction.

And then there are also sidechains whose history is separate from the L1 and has its own consensus model (they don’t do any proving to L1 and don’t inherit its security). Sidechains are merely connected to L1s by a two-way bridge that can move assets between the chains.

Ok folks, that’s the execution layer. Now people can have the option of faster transaction processing through these L2s. Although with this design we are still putting strain on L1 because it has three jobs to do: making the network agree on just one version of truth (the blockchain’s state), deciding on how to sequence the transactions, and storing all that transaction history. We’re gonna be munching on these next, but for now GN!