# A newbie journey into Ethereum Rollups

It began with the authority, the [ethereum.org docs](https://ethereum.org/en/developers/docs/layer-2-scaling):
>Layer 2 is a collective term for solutions designed to help scale your application by handling transactions off the main Ethereum chain (layer 1). Transaction speed suffers when the network is busy which can make the user experience poor for certain types of dapps. And as the network gets busier, gas prices increase as transaction senders aim to outbid each other. This can make using Ethereum very expensive.

## Rollups
Rollups are solutions that perform transaction execution outside layer 1 (off-chain), but post transaction data on layer 1. As transaction data is on layer 1 (on-chain), this allows rollups to be secured by layer 1. Inheriting the security properties of the main Ethereum chain (layer 1), while performing execution outside of layer 1, is a defining characteristic of rollups.

An off-chain component takes over some more complex and computation heavy parts, and communicates with the on-chain smart contracts. In order for that to happen without giving up the security, all changes to the state of the system need to be certified with proofs, by proof-based L2 scalability solutions.
Verifying a proof on-chain is exponentially cheaper and faster than executing the business logic fully on-chain.

To simplify rollups properties:
1. transaction is executed **off-chain**
2. transaction/s data, or validity proof is **on-chain**
3. a rollup smart contract is needed, that will enforce correct transaction execution by using transaction data **on-chain**.

Important part that needs to be understood:
>Rollups require operators to stake a bond in the rollup contract. This incentivises operators to verify and execute transactions correctly.

It seems that rollups solutions use PoS to ensure operators' good behaviour, but what is rollup contract and does it affect rollup users?

There are two types of rollups with different security models:
* [**Zero knowledge**](https://ethereum.org/en/developers/docs/layer-2-scaling/#zk-rollups)
Runs computation off-chain and submits a validity proof to the chain

* [**Optimistic**](https://ethereum.org/en/developers/docs/layer-2-scaling/#optimistic-rollups)
Assumes transactions are valid by default and only runs computation, via a fraud proof, in the event of a challenge.

🧐❓ **Questions**

1. Why `calldata` is cheeper?

>With Optimistic rollups transactions are written to the main Ethereum chain as calldata, optimising them further by reducing the gas cost.

👀 Research:
[Answer](https://ethereum.stackexchange.com/questions/74442/when-should-i-use-calldata-and-when-should-i-use-memory)

>Calldata is a non-modifiable, non-persistent area where function arguments are stored, and behaves mostly like memory. This is the cheapest memory location to use.
>`Calldata` limitations:
>* It can **only** be used for function declaration parameters (and not function logic)
>* It is **immutable** (it can't be overwritten and changed)
>* It **must** be used for dynamic parameters of an external function
>* It is **non-persistent** (the value does not persist after the transaction has completed)

And even better explanation:
>One good way to think about the difference between `memory` and `calldata`, is that `calldata` is allocated by the caller, while `memory` is allocated by the callee.

💡 And this, finally, explains how they reduce the gas cost even more. 🤓

2. Meaning of the following ZK rollups con?

>Limited to simple transfers, not compatible with the EVM.

👀 Research:

[Vitalik](https://vitalik.ca/general/2021/01/05/rollup.html) answers:
>Rollups move computation (and state storage) off-chain, but keep some data per transaction on-chain. To improve efficiency, they use a whole host of fancy compression tricks to replace data with computation wherever possible. The result is a system where ==scalability is still limited by the data bandwidth of the underlying blockchain==, but at a very favorable ratio: whereas an Ethereum base-layer ERC20 token transfer costs ~45000 gas, an ERC20 token transfer in ==a rollup takes up 16 bytes of on-chain space== and costs under 300 gas.

The 16 bytes explained why it is limited, but reading further made it not clear again, as he states that this is a key. I still don't understand why key limits the transaction to simple transfers.
>The fact that data is on-chain is key (note: putting data "on IPFS" does not work, because IPFS does not provide consensus on whether or not any given piece of data is available; the data must go on a blockchain). Putting data on-chain and having consensus on that fact allows anyone to locally process all the operations in the rollup if they wish to, allowing them to detect fraud, initiate withdrawals, or personally start producing transaction batches.

Vitalik further explains the benefits of using a key instead of the available data.

>The lack of data availability issues means that a malicious or offline operator can do even less harm (eg. they cannot cause a 1 week delay), opening up a much larger design space for who has the right to publish batches and making rollups vastly easier to reason about. And most importantly, the lack of data availability issues means that there is no longer any need to map assets to owners, leading to the key reason why the Ethereum community is so much more excited about rollups than previous forms of layer 2 scaling: rollups are fully general-purpose, and ==one can even run an EVM inside a rollup==, allowing existing Ethereum applications to migrate to rollups with almost no need to write any new code.

Well, the fact that we can run an EVM inside a rollup, contradicts with the same statement that sparked this research. Unless this fact is true only for optimistic rollups and explains why it is a con for ZK rollups.

Nevertheless, this is a strong statement, and for me it means that I will continue researching rollups and will not switch yet to the other scaling solutions like I intended...

❓Another question that rises is why there is no longer a any need to map assets to owners, and what will that mean for us? Remember to come back to it...

Fortunately, Vitalik continues on explaining [how how exactly does a rollup work](https://vitalik.ca/general/2021/01/05/rollup.html) (thanks a lot!) and also answers my previous silent question about what is a batch.

>Anyone can publish a **batch**, a collection of transactions in a highly compressed form together with the previous state root and the new state root (the Merkle root after processing the transactions). The contract checks that the previous state root in the batch matches its current state root; if it does, it switches the state root to the new state root.

Actually, it sounds too easy. I hope that the obviosly needed proofs won't ruin the magic.

>To support depositing and withdrawing, we add the ability to have transactions whose input or output is "outside" the rollup state.

It took me a while to understand that inputs/outputs are the assets to transfer as the result of the transactions batch execution.

>If a batch has inputs from the outside, the transaction submitting the batch needs to also transfer these assets to the rollup contract. If a batch has outputs to the outside, then upon processing the batch the smart contract initiates those withdrawals.

And if all this magic happens in one transaction this's exactly what we need!

And finally the answer to the question 2:

Vitalik writes that the generalizability for ZK rollups is harder, since "ZK-SNARK proving general-purpose EVM execution is much harder than proving simple computations (though there are efforts (eg. Cairo) working to improve on this)". Regarding Optimistic rollups it seems different and "easier, as general-purpose EVM rollups are already close to mainnet".
I guess he refers to [Optimism](https://optimism.io/) that recently has delayed its mainnet launch from March to July at least as they say. I wonder why...
Anyway, now it is clear that, as I suspected, there was no contradiction above, and you can run an EVM inside a rollup, and this is a con for ZK rollups, since you can do it only with optimistic rollups. Yey! 😃

Now, in case we choose rollups (we can't choose nothing else at the moment, since we don't understand anything else😄, yet), how to decide which type?

I'll map our specific needs and using that excellent tradeoffs table between the two flavors of rollups, from Vitalik's blog, we'll decide which one of the rollup types is better for us. Though it really tickles to try [Optimism tutorial](https://github.com/ethereum-optimism/optimism-tutorial/blob/main/README.md), as like now 😂.

Rollups are young, and as Vitalik said: "there are still many areas of rollup design that have not been well explored", I understand that we are jumping head to one of the most complex areas as our first project on Ethereum or any blockchain.
The kind of challenges I like!

---
###### tags: `blockchain`