Original translation: Block unicorn

Original translation: Block unicorn

“Blockchain cannot scale’ You’ve probably heard it a million times. A few years ago, this felt like a real threat to the industry. How are we going to bank the unbanked if we can’t even process 15 transactions per second?

But big questions drive innovation, and blockchain scalability is a big one. It quickly caught the attention of engineers and scientists, and today we are increasingly confident that blockchains can scale. In fact, most of the current debate focuses on which scalability solution will win.

first level titlesummary

Facing the "scalability trilemma"

We can't talk about scalability without mentioning the famous "scalability trilemma". The term was coined by Vitalik to explain the three properties blockchains are designed to possess: scalability, decentralization, and security. Clearly, we can implement two of these properties so far. But getting all three at the same time is very, very difficult.

Before we understand why, let's make our terms clear.

1. ScalabilityIt simply means that the blockchain can handle a high number of transactions, measured in transactions per second (TPS).

2. DecentralizationMeaning the blockchain is run by many "trustless" nodes around the world - rather than a small cluster of "trusted" nodes.

3. SecurityIt means that even if a certain percentage of nodes in the network are malicious, the blockchain can resist attacks. Ideally, it should be able to handle up to 50% of malicious nodes.
first level title

decentralization and security

At the bottom of the triangle are traditional blockchains such as Bitcoin and Ethereum 1.0 (one-tier).

These types of blockchains are:

• Decentralized: yes. Because anyone in the world can choose to become a mining node. Thousands of miners around the world are involved in securing the Bitcoin and Ethereum networks. There is also no need to authorize yourself as a miner; it is completely trustless.

• Safe: Yes. Because every node in the network keeps a copy of the blockchain and verifies every transaction. Additionally, Proof of Work is designed to handle up to 50% malicious nodes.

• secure and scalable

secure and scalable

The right side of the triangle isTypical high TPS chainSafety

• Safety:Yes. Every "election" node is authorized, so we control the opponents in the system.

• Scalable:Can. Since a small number of elected nodes produce new blocks at any time, we can achieve higher transaction throughput and lower latency, which means lower interaction fees than if every node had to verify every transaction .

• Decentralization :first level title

Scalable and decentralized

On the left side of the triangle are multi-chain ecosystems such as Cosmos, Polkadot, and Avalanche. These systems have many independent blockchain networks that all communicate as part of a larger blockchain network.

• Scalable:Decentralization:

• Decentralization:It depends. Each blockchain in the ecosystem has a set of nodes that validate the blockchain. Some chains in the ecosystem will have many validators (e.g. stablecoin chains that require decentralization), while others may have few or even one (e.g. enterprise chains that do not require much decentralization). So the degree of decentralization depends on which chain in the ecosystem we are referring to.

• Safety:Not very safe. If one chain in the ecosystem is compromised, it could have a ripple effect on the rest of the system. For example, if chain B is attacked, and chains A, C, and D all depend on it, then other chains will also be affected.

As you can see, there are many different attempts at scaling blockchains, but it almost always comes at the expense of one of these three properties. Vitalik and the Ethereum community have been reluctant to make this compromise, and their goal is to get all three.

first level title

Understanding Layer 1 and Layer 2 Extensions

Tier 1Tier 1Scaling refers to extending the core blockchain itself. Layer 2 scaling, by contrast, refers to moving transactions from the main blockchain layer into a separate layer that can communicate with the main chain.

first level title

The earliest two-layer solution of Ethereum

text

state channel

State channels have been around for a long time, so they are nothing new. Here's a quick explanation of how they work. Let's say we have two people, Alice and Bob, who want to trade with each other. Alice pays Bob $1 every time she tweets. But since Bob tweets a lot every day, it would be too slow and too expensive to use Ethereum for transactions.

Instead, they use "state channels":

• Alice has invested $500 in an Ethereum smart contract.

• Whenever Alice wants to give Bob $1, she signs a message indicating how much she wants to give Bob. She keeps signing messages until Bob is ready to "cash out" his funds.

• Bob submits a new message indicating that he is ready to close the state channel. A smart contract on Ethereum verifies Alice and Bob's signatures, pays Bob the amount due, and returns the rest to Alice.

Note that only the first and last steps require us to make a transaction on the blockchain, between these steps Alice and Bob can send an unlimited number of signed messages to each other indicating payment.
In this case, the Ethereum blockchain is only used as a settlement layer to process the final transaction of the one-time payment, which reduces the burden on the underlying blockchain.

first

• first, most transactions happen off-chain, which means payments can be processed instantly, as off-chain updates between two parties do not require additional time to process and verify on the blockchain network.

• secondly, payments incur lower fees because we only need to make on-chain transactions when opening and closing state channels. This means that most transactions take place off-chain with much lower fees.

So why isn't this the final solution? Well, there are limits to what state channels can do.
For example, we cannot use state channels to transact with people who are not part of the state channel, and we are limited to the types of state updates possible in state channels. Complex applications like Uniswap cannot be used in state channels because when we swap two tokens on Uniswap, the smart contract automatically executes a series of intermediate steps to make the swap without authorizing the user on each step signature.
Another downside of state channels is that they require us to lock up liquidity to instantiate the channel and prevent situations where a malicious counterparty may never actually pay the committed funds. This might be fine for a single channel, but the liquidity locked in an intermediate channel makes it rather "capital inefficient" when we try to make payments through a network of state channels.
Finally, state channels require someone who can regularly monitor the network (or delegate this responsibility to someone else). This keeps your funds safe, which adds another layer of complexity and inefficiency.
side chain

side chain

Sidechains have also been around for a long time and are well understood. Simply put, a sidechain is an independent blockchain that is "pegged" to the main blockchain.

When we "hook" one blockchain to another, it means we can move assets between the two blockchains. The "one-way" peg is where we move assets from the main blockchain to the sidechain, and not the other way around. This is accomplished by “burning” tokens on the main blockchain by sending them to unusable addresses, and then “minting” equivalent tokens on the sidechain.

A "two-way peg," then, is when we can move assets in and out of the main blockchain and sidechains. This requires "locking" our tokens on the main chain, and then "minting" an equal amount of tokens on the side chain. When we want to switch back to the original tokens, we "burn" the tokens on the sidechain and unlock the tokens on the mainchain.

So a sidechain is when we create a new blockchain that is bi-directionally pegged to the main blockchain. When we want to transact faster, we can transfer our funds from the main chain to the side chain and do the transaction there. Once done, we transfer the funds back to the main chain.

An example of a Bitcoin sidechain is the Liquid Network. The Liquid Network is pegged to Bitcoin, allowing faster and cheaper Bitcoin payments. Another popular example is Polygon, which is a sidechain pegged to Ethereum.

When users want to transact faster, they can lock up some ETH and create an equivalent amount of Matic tokens on the Polygon sidechain. On the Polygon sidechain, they can enjoy faster and cheaper transactions. When they complete the transaction, they can convert their Matic tokens back to ETH.

Note: Matic is technically not a sidechain as it periodically commits the state of the sidechain to Ethereum. Hence, they like to call themselves "commit chains".

Overall, sidechains are scalable because they typically trade off decentralization and/or security by using different consensus algorithms that allow for scalability.
first level title

Plasma

Plasma is another "layer 2" solution that allows us to move transactions out of the base layer. Before we get into Plasma, it's important to note that Plasma has had several iterations over time, each with its own trade-offs. You can check out the Plasma world map, which lists many different types of designs that people have tried to create to solve the challenges that Plasma poses, there are many!

Of course, for the purposes of this article, I have to generalize the concept of Plasma without focusing too much on individual implementations. If you want to dig deeper, be sure to check out the world map.
So, what is plasma? Plasma is essentially a series of smart contracts (or "Plasma chains") that run outside of the main blockchain.

Plasma chains are like branches of a tree, Ethereum is the backbone, each Plasma chain is a branch, and each branch is considered a blockchain with its own blockchain history and computation.
The "root blockchain" (i.e. the Ethereum blockchain) uses something called "fraud proofs" to enforce the validity of the state in the Plasma chain. Fraud proofs are a mechanism by which we provide certain data that anyone can use a mathematical proof to determine if the data is invalid.

Each Plasma blockchain does not need to publish transaction data to the root chain. Instead, each Plasma chain has an "operator". This could be a centralized actor, a multisig representing multiple individuals, or even a committee that participates as an operator. The operator of the Plasma chain submits the Merkle root of the transfers that occur on the Plasma chain.
NOTE: If you don't know how Merkle trees work, then I highly recommend reading this explainer before proceeding. At a high level, Merkle trees allow us to take a large dataset (e.g., the transactions in a block) and produce a single root hash that represents the entire dataset.

Later, we can easily prove that a piece of data from a large dataset (i.e., a single transaction from a block of transactions) exists in that dataset, simply by providing a branch to that data.

If someone were to try to prove the existence of a fraudulent transaction, the hashes would not match and we would know immediately.

OK, back to Plasma.

Each Plasma chain is committing the Merkle root of the transfer that happened on it. When a user later tries to move their asset from the Plasma chain back to the root chain, the user can submit the Merkle branch of the latest transaction that sent the asset to them (recent enough for us to know the current balance is waiting on Plasma). This starts a challenge period where anyone can try to prove that a user's Merkle fork is fraudulent. If a Merkle branch is fraudulent, a fraud proof can be submitted.
Since the root blockchain only tracks Merkle roots, it has to deal with far less data than those transactions that occur on the main chain. This significantly reduces the amount of data stored on the root blockchain and allows us to scale the root chain.
Furthermore, if a particular Plasma chain is maliciously attacked, one can "mass exit”。

Etc. Plasma is more beneficial than state channels because you can send assets to anyone, whereas with state channels you can only transact with people in the state channel. Also, the benefit of Plasma over sidechains is that Plasma chains are secured by Ethereum.

The fundamental difference between the two (Plasma vs. sidechains) is that sidechains have their own security model. They have their own consensus mechanism and a separate set of nodes to validate the state. Even if the sidechain is attacked, nothing will happen to the mainchain and vice versa. In case of an attack on the side chain, the main chain cannot protect users.

On the other hand, etc. Plasma hasdependent security model, each Plasma chain can use its own mechanism to verify transactions, but it still uses the Ethereum blockchain as the final arbiter of truth. In the event of a Byzantine attack, Plasma users can exit to Ethereum.

But Plasma has several drawbacks that make it a lackluster scalability solution.

First, when users want to transfer their assets from the Plasma contract to the main Ethereum blockchain, they need to wait 7 days. This is enough for people to verify that the withdrawal transaction is not fraudulent. If so, they can construct fraud proofs using the Merkle tree on the Plasma chain.

Second, each Plasma chain requires an operator to post Merkle root commitments to the main chain. This requires us to rely on a third party to accurately publish the Merkle root commitment to the chain. Unfortunately, operators can perform so-called "data availability attacks", where they refuse to publish certain transactions to the main chain for malicious reasons.

In this case, operators can convince the network to accept invalid blocks without being able to prove invalid blocks. This prevents other users from knowing the exact state of the blockchain. This also prevents people from creating blocks or transactions because they lack the information to build proofs. Unlike fraud, data availability attacks are not uniquely attributable. We have no way of knowing that an attack is happening.

Operators can also operate maliciously in more explicit ways, such as by submitting fraudulent transactions. In this case, people can "massively withdraw," as mentioned above. But these have proven to be far more difficult to implement in practice. If many users want to withdraw on a large scale, it may cause congestion on the main chain, and users may not be able to withdraw in time, resulting in loss of funds.

Third, Plasma requires the owner of the asset being traded to be present. This ensures the security of the Plasma chain as it effectively makes transactions (such as sending ERC 20 tokens to approved addresses) impossible without the consent of the owner. Plasma works best for simple transfers, but as transactions become more complex, the design space becomes irregular.

For the above reasons, Polygon and OMG Networks initially pursued a Plasma architecture for scaling, but later abandoned it.
summary

summary

Just like state channels, sidechains, and Plasma, rollups are "layer 2" solutions. In fact, rollup is very similar to Plasma in that we batch transactions off-chain and publish updates to the main blockchain. However, the key difference is that with aggregation, we also publish the transaction data for each batch of transactions on-chain. With Plasma, we only publish Merkle roots.

In other words, with aggregation, we do transaction processing off-chain, but we publish transaction data on-chain. The amount of data we publish on-chain is the minimum amount required to locally validate aggregated transactions. By putting data on-chain, anyone can detect fraud, initiate a withdrawal, or start generating transaction batches themselves. Therefore, rollups provide us with higher security guarantees than Plasma chains or sidechains.
Another key difference between rollups and Plasma is that we don't have to worry about data availability. After all, we publish transaction data to the main chain. This is a huge win.
Using rollup, we effectively run a version of the EVM inside the rollup layer. This means that any possible transaction on Ethereum can be executed in the rollup.
This begs the question: if we still publish transaction data on-chain, how does this scale layer 1? Isn't scalability still limited by the data bandwidth of the main chain?
Yes. The key here is that we get 5x to 100x scalability with rollup, but not infinite scalability. Rollups also use a lot of fancy compression tricks to minimize the amount of transaction data we post on-chain, so much less data is stored on-chain than it would be otherwise.

At the same time, we outsource all the heavy lifting of off-chain transaction execution to Rollup. Recall that during transaction execution, the transaction must be executed by the Ethereum Virtual Machine (EVM) handles and interacts with state (e.g. storage, account balance, etc.). This is expensive.

first level title

Take a closer look at the summary

Now, let's see how rollup works behind the scenes.
There is a "rollup contract" on the main chain that maintains the current state of the rollup layer. This includes the account balances of users making transactions on it and the smart contract code of the contracts that exist within it. In short, the rollup contract keeps track of the "state root" of transactions in the rollup layer.

The "state root" consists of a key-value map, where the keys are addresses and the values ​​are accounts. Each account has up to 4 properties: balance, nonce, code (only for smart contracts) and storage (only for smart contracts).

A state change occurs when a transaction occurs at the aggregation layer. Of course, this means that the state root also needs to be updated. But instead of updating the state root for each transaction, transactions are "batched" to a summary contract on the main chain. The batch will include a compressed form of the batch's transactions and an updated state root representing the processed data for the batch's transactions.
The rollup contract on the main chain checks whether the previous state root in the batch matches its current state root - if so, it switches the state root to the new state root.

Since the posted transaction data isn't actually interpreted by the EVM, we don't access or write state - that would be too expensive. Instead, we post the compressed transaction data to the aggregate contract as a "calldata" parameter.

That's why this is neat, in Solidity, calldata (which is a way of storing data structures) is the cheapest form of storage. In fact, the parameters passed as calldata parameters are not stored in the state of Ethereum at all, which means we avoid a lot of gas costs. At the same time, Ethereum nodes can still store transaction data (in the history log) when creating blocks.

Astute readers may wonder what the difference is between Plasma and Rollup. This is the key difference: with aggregation, we publish transaction data on-chain along with the state root. With Plasma, we simply publish the state root of the transaction.

Unlike Plasma, where we have an operator that publishes the Merkle root to the root chain, rollups allow anyone to publish a new batch of transactions to the on-chain rollup contract, which we'll explore in more depth later.

Again, this begs the question: Since we are only posting transaction data to the main chain and not executing transactions on-chain, how do we know that the transaction data and state roots posted on the main chain are not fraudulent?

first level title

optimistic summary

You can probably guess what an optimistic rollup is from the name, when a new batch of transactions is "rolled up" to the main chain, the state root and hash of each batch are published, but we don't actually verify that the transactions were executed correctly, At least not at the time of publication.
In this way, we "optimistically" publish new state roots and transaction data to the aggregation contract on the main chain. When someone posts a new state root to the main chain, the rollup smart contract simply takes their word for it.
If someone discovers that an invalid state transition was issued to the rollup smart contract, they can generate a "fraud proof".
Proof of fraud includes:

• Proof of the "pre-state", or, how things looked before the transaction was applied

• Proof of "post-state", or how state should be handled after applying transactions

• Transaction proofs applied during state transitions

The workflow is simple: this fraud proof is published to the summary contract on the main chain. The proof of contract verification is then aggregated and transaction logic is applied to the pre-state. Then, it compares the result with the post state. If there is a mismatch, it proves that whoever issued the batch did not apply the transaction correctly. The smart contract then reverts that batch of transactions and all subsequent batches.

first level title

ZK summary

If optimistic rollup uses the "innocent until proven guilty" mentality, then ZK rollup uses the "don't trust, verify" mentality.
With ZK rollups, each batch contains a cryptographic proof called a ZK-SNARK that proves that the state root is the correct result of executing the batch's transactions. A ZK-SNARK proof is a hash representing the change in the state of the blockchain after a transaction is executed in the zk-rollup layer. This proof of validity is published to the rollup contract, so anyone can use it to verify transactions in a specific batch on the rollup layer.
The magic here is in the way ZK-SNARKs work. They allow us to generate proofs of the underlying data without revealing the data. Anyone can later verify that the data exists, even if they don't have access to the data itself.
text

Which is better?

cost

cost

"Cost" doesn't mean much in the abstract, but when we break it down, the performance of optimistic and ZK rollups starts to diverge.

• Gas cost for publishing new batches on the chain: Optimistic rollup costs less. We optimistically release new state roots and data, so it's an easy transaction. ZK rollups are more expensive. When we release a new batch on-chain, we must verify the ZK-SNARK proof of validity. This is computationally more expensive.

• Gas cost per transaction published on chain: Optimistic aggregates are more expensive. We must publish enough data on-chain to verify the fraud proof later. ZK rollup costs are lower. We can omit most of the transaction data, since the proof of validity is sufficient for anyone to verify the correctness of the batch.

• Off-chain computational cost: Optimistic aggregation is less costly. We only publish new state roots, not execute/validate transactions. That said, we still need someone to watch the creation of new batches and the execution of new transactions to ensure that the batches are correct. ZK rollups are more expensive. ZK-SNARKs are computationally expensive (20 to 1000x more expensive, although it continues to get cheaper with innovation).

speed

speed

Optimistic rollups are slow. Typically, users have to wait about a week before they can withdraw their assets. This may give someone enough opportunity to issue proof of fraud if a user tries to withdraw tokens on the rollup layer that they don't actually own.
ZK rollups are fast. Users typically wait less than 10 minutes to withdraw their assets. We just have to wait until the next batch to process withdrawals, since all aggregated statuses are already verified.
Sidenote: There are a few ways to get around this one week waiting period by using "Quick Withdrawal". This is done through liquidity providers who maintain a "cookie jar" of funds on the main chain. When users quickly withdraw funds, they give the liquidity provider an IOU for the funds in the pool, and they get paid (fee) immediately by the liquidity provider on the main chain.
Later, when the one-week period ends and users get their assets back from the pooling layer, users can send the funds owed to them to liquidity providers. Liquidity providers can even choose to run a validator node to verify users’ transactions on the rollup before releasing funds to them on the main chain, further reducing their risk.
However, this "quick withdrawal" scheme is impossible with NFTs, since only one of any NFT exists, and liquidity providers cannot create identical NFTs on-chain.

complex

Optimistic rollups are simpler, and the concept of fraud proofs has been around for a long time, so the solution is relatively simple.
ZK rollups are more complex, ZK-SNARKs are new and mathematically complex.

Extensive

Optimistic rollup is easier to generalize, and engineers have built an EVM-compatible virtual machine called OVM (Optimistic Virtual Machine), which allows optimistic rollup to process any transaction that can be processed on Ethereum.
scalability

scalability

Optimistic rollups are less scalable. When we publish data on-chain, it usually includes some state (such as transaction details) and witnesses (such as digital signatures proving the consent of the transaction parties). With optimistic rollups, we have to publish a witness for every transaction so people can later prove fraud. Witnesses take up a lot of storage space, 3-10 times that of transaction data.
ZK rollups are more scalable:Safety

Safety

Optimistic rollups are less secure, optimistic rollups rely on cryptoeconomics to ensure chain security. In other words, they must incentivize people to watch batches posted on-chain and detect fraud.

ZK rollups are more secure,ZK rollups rely on mathematics, they do not require incentives. They use cryptography rather than cryptoeconomics.
So, now that we've broken these down, which is better? Still hard to tell, but it's a testament to the great work done by the engineers behind these programs. We have teams like Optimism and Arbitrum working hard on optimistic rollups, which are already available to Ethereum developers. We have companies like StarkWare and Zksync bringing generic ZK-rollups to Ethereum.
Both solutions are in their infancy. But optimistic rollups are closer to adoption because they are less complex and can be used for general-purpose computing today. On the other hand, ZK rollups will take some time to catch up, but many engineers will consider ZK rollups to be a superior technology. After all, they rely on mathematics rather than cryptoeconomics, and they are more scalable than optimistic rollups.
first level title

the cleverness of summing up

Before we discuss some of the persistent challenges of rollups, let's look at the compression tricks rollups use so efficiently.

• Nonce: In a typical Ethereum transaction, we include nonces to prevent double spend attacks. Rollups omit them entirely, since they can be recalculated using the previous state of the blockchain. In this way, summarization replaces data with calculations whenever possible.

• Gas price: Instead of denominating in gwei (where 1 gwei is 10^-9 ETH), it is better to limit the gas price to a fixed price range, thereby significantly reducing the amount of storage required to record the gas price in the transaction data. It adds up!

• Fee: Same as above.

• To: An address is 20 bytes long, plus 1 byte for RLP encoding. Instead of including addresses, a summary can store a mapping of indices to addresses, and only include indices in the "to" field (for example, 1234). It's like leaving the coordinates to the destination instead of rendering the whole location itself.

• Value: The "Value" field is 9 bytes because ETH and ERC-20 tokens have a maximum of 9 decimal places. Aggregate can instead limit the value to a maximum of 3 decimal places, saving us 6 bytes. Looks very functional!

• Signatures: As mentioned above, digitally signed "witnesses" take up a lot of storage space. Rollups can use BLS signatures (an algorithm for signature aggregation and key aggregation), which allows us to aggregate many signatures into one, which saves a lot of storage space!

Let's put this all into action, using all these compression tricks, how many bytes can we save for ETH transfers? A typical ETH transfer takes 112 bytes, but with all these compression tricks? At only 12 bytes, that's almost a 10x improvement in efficiency!
text

text

first level title

Scalability has a ceiling

So far, you've seen the main differences between rollups and other layer 2 solutions like Plasma and sidechains. As you will recall, rollups move computation off-chain, but store data on-chain. This can be very helpful for troubleshooting data availability issues. But since we store transaction data on-chain (albeit in a very compressed form), we are still limited by Ethereum's storage capacity.
We can do some rough math to see what the theoretical TPS would be using rollups.

• Data cost per byte stored on-chain: 16 gas

• Data cost per byte stored on-chain: 16 gas

• Maximum bytes per block: ~781,000 bytes (12.5 million gas / 16 gas per byte)

• Data bytes required for ETH transfer using rollup: 12 bytes (see math in previous section)

• Transactions per block: ~65,000 (~781,000 bytes per block / 12 bytes per ETH transfer)

• Average block time on Ethereum: 13 seconds

• Transactions per second: ~5000 TPS (about 65,000 transactions per block / 13 seconds per block)

Of course, this math assumes that all transactions in a block are ETH transfers, and that there is nothing in a block other than batch aggregated transactions, which is highly unlikely. Most blocks will contain various transactions, including some layer 1 transactions that will cost more than 16 gas fees. Also, if these are ZK-rollup batches, the cost of verifying the SNARK proof on-chain will not be included, which is approximately 500,000 gas.
Still, this gives you a starting point to use aggregated TPS, 5,000 is nowhere near the 65,000 TPS Visa apparently has, but it's much better than today's TPS for Ethereum.

broken mobility

Rollup technology was created as an independent project, not by the Ethereum protocol itself. So there will be several different aggregation techniques in parallel, and this is where the liquidity breaks.
reduce composability

reduce composability

One of the main benefits of building on Ethereum is composability. Every new protocol built on Ethereum is like Lego bricks that other protocols can easily build on top of. For example, this is what makes DeFi so powerful. It allowed us to create money Lego bricks.
We lose some composability when applications and liquidity move to rollups. After all, passing messages and transactions between the aggregation layer and the main chain is not as easy as it is in the context of the base layer.
But it may only be a matter of time before this problem is resolved. I can certainly see a world where smart contracts that exist on different aggregates can still communicate with each other. As always, we're only a few bright engineers away from solving these problems.

centralization

We neglected to discuss who is actually responsible for posting new batches to the main chain, so let’s get back to that.

Most rollups rely on a "sequencer" to do the job: a sequencer is a node that batches transactions and publishes the results to the rollup contract on-chain. For Arbitrum, Optimism, and StarkNet, the sequencer is a single node running by itself.

I know. "Decentralization" is the core of the blockchain. Although it is very efficient, it is obviously very centralized. What if the sequencer fails or censors the transaction?

Well, it's not that simple. The reason these projects are currently taking this route is because it is easier and faster to iterate using this method. To reduce the risk of centralization, over time most rollups would like some kind of decentralization of the sorter - and many of them do have plans to do so.

How will the decentralization of sequencers work? There are several methods. On the one hand, we could create a Proof-of-Stake-like system where sequencers must stake tokens to have a chance to come up with the next batch. Or we could do a Delegated-Proof-of-Stake, where a sorter is elected and not elected if it doesn't do well.
first level title

side by side comparison

Pooh. Hopefully you have a better understanding of rollups — and why Ethereum is betting on it (and sharding!) as a scalability solution. Of course, Rollups sits on the shoulders of the giants that came before it — we wouldn’t have it without sidechains, state channels, and Plasma.

It is also instructive to compare Rollup to other layer 2 solutions using the “trilemma” framework of decentralization, security, and scalability. Except I'll add an extra dimension: versatility. Over the years, we've realized that it's important for layer 2 solutions to be versatile so that it can be used to do anything that can be done on the main chain.

This clearly shows that Rollups gives us modest scalability without sacrificing decentralization, security, and generality.

However, the tradeoff is scalability. Because we still store data on-chain, we are limited in scalability compared to layer 2 scaling solutions that store data off-chain. Also, in the short term, rollups rely on a centralized sorter, which reduces security. But this is a short-term problem, and over time rollups are likely to decentralize the orderer, making it a technology superior to Plasma, sidechains, and state channels.

So is rollup the holy grail? I'll let you decide.

PS..

For the sake of brevity, I left out a lot of interesting details about how rollup works. But I'm also missing a new layer 2 scaling scheme called "Validium".
Validium is similar to Plasma in that we move data and computation off-chain. The key difference is that Validium does not rely on fraud proofs to validate transactions. Instead, operators need to make new state commitments using zero-knowledge proofs, which make it impossible for operators to advance invalid state transitions.
in conclusion

in conclusion

This post was much longer than I expected, if you're still reading then you're my type.
Although rather lengthy, this is really the minimum you need to know to have a basic understanding of aggregation. After all, rollups are only half of Ethereum's scalability solution. The other half is sharding, if you're interested in building Web 3.0 applications, sign up for our next DappCamp cohort where you'll learn how to build and deploy secure smart contracts on Ethereum.