Rollups

From CryptoWiki

Basics

What are Rollups? Rollups are non-custodial sidechains that solve Plasma's data availability problem. Rollup blocks include enough data for anyone to reconstruct & challenge their state. In Plasma, only a subset of validators can challenge blocks sent to the main chain.

Rollups come in two flavours:

  1. Optimistic rollups - ORs depend on a dispute game run by active validators.
  2. ZkRollups - ZKRs rely on cryptographic zero-knowledge (ZK) proofs, which are instantly validated by a smart contract.

"Rollup scaling implementations are relatively new entrants to the market. They aim to solve the data availability problem by keeping the transaction data stored on the Ethereum’s blockchain in a bundled/compressed format. The main goal of this transaction grouping is to reduce validation costs. The grouped transactions are not validated directly by the Ethereum consensus mechanism. Instead, a different mechanism is used to prove the validity of these transactions."

History

"But zk-Rollup came with its own set of tradeoffs. Namely, validity proofs are computationally expensive to generate (details here). These zk-SNARKS are produced every block and can take upwards of 10 minutes to generate while costing up to 350,000 gas per verification (post Istanbul). For reference, that’s about 3.5% of an entire block (was 8% pre Istanbul).

Additionally, it is currently not possible to deploy general smart contracts on zk-Rollup sidechains. Proposals are under development for specialized zero-knowledge VMs that would enable this, such as zkVM and ZEXE, but they still require lots of specialized knowledge to interact with them. For the most part, zk-Rollups limit general programmability.

By mid-2019, these new developments had re-energized the Ethereum research community. zk-Rollup seemed to solve many of the problems that had plagued the layer-2 narrative. Companies such as Matter Labs (one of our portfolio companies) and LoopRing began actively developing zk-Rollups, and both have testnet implementations live today. With optimizations, Matter Labs believes that it can achieve upwards of 2,000 TPS on its ZK Sync network.

Additionally, Starkware (also a portfolio company) is building a variation on zk-Rollup they call StarkExchange. StarkExchange uses a STARK to prove the validity of sidechain transactions, but delegates the problem of data hosting off-chain (if the sidechain ever halts, exits are guaranteed through on-chain checkpointing). They are implementing a DEX in partnership with DeversiFi with this design and will be launching on mainnet in the near future."

Rollup Consensus Roles

  1. Sequencers / Proposers
  2. Provers
  3. Node runners

"Proposers construct rollup blocks from users’ L2 transactions and propose them to L1. Sometimes these are referred to as Sequencers in other rollup systems. Proposers decide which transactions to include in a block and how to order them. This is a powerful position as it can extract profit from transaction ordering and decide which transactions to exclude, and is thus able to censor certain transactions, applications, or users.

As we established —> a decentralized rollup should allow users to expect the inclusion of all of their valid transactions.

Provers generate SNARK proofs asserting the validity of L2 transactions and blocks from the aforementioned proposed blocks. Provers decide which proposed blocks to turn into on-chain verified blocks. This position decides when a block can reach its on-chain verified state, but not which txs go in a block or how they are ordered. Until this on-chain verified state, the prover can leave hanging certain transactions that depend on the validity proof, or leave hanging certain would-be on-chain verified blocks that are waiting for their parent block to be on-chain verified.

As we established —> a decentralized rollup should allow users to expect verification of all of their valid transactions.

Node runners execute transactions from on-chain (L1) data to stay in sync with the rollup state. Proposers and provers need to run full rollup nodes to fulfill their respective roles. Other actors would also want to run nodes, such as those offering services like a block explorer, infrastructure providers, and users who want to stay in sync with the chain state for other reasons.

As we established —> a decentralized rollup should allow users to expect the execution of all of their valid transactions.

Note: while decentralizing proposers/provers is an explicit rollup protocol decision (e.g. the smart contracts may be configured to only accept blocks or proofs from allowlisted addresses), running a node is mostly a resource consideration that depends on state growth, hardware requirements, etc., and is not an outright protocol decision."

Optimistic Rollups

  • Settles transactions as L1 calldata. Assumes every transaction is valid by default as it does not compute the transaction. Uses fraud proofs to dispute transactions, hence the seven-day withdrawal period.
  • The following comes from this Twitter thread by Token Terminal (24-6-2020):

What are Optimistic rollups? ORs resemble Plasma sidechains, but tradeoff some of their scalability to run fully general smart contracts (whereas ZKRs are currently better suited for simple payment transactions). ORs can run anything Ethereum can.

"A major project in the Optimistic Rollups (OR) domain is Optimism. Optimism is building the Optimistic Virtual Machine (OVM) which aims to scale arbitrary Ethereum transactions on L2. The team recently ran a demo to scale DeFi protocol in collaboration with Synthetix. The results from the demo were encouraging. Another effort along the lines of OR is IDEX's own scaling solution. The IDEX team ran a demo for the solution in October of last year."

Difference with Plasma

"The main difference between Plasma and Optimistic Rollups (OR’s) is that OR’s can run virtual machines - so-called Optimistic Virtual Machines (OVMs) - which allows for the execution of smart contracts on layer 2."

Cons

  • From a blog post by Kain from Synthetix (which will use Optimistic Rollups) (21-10-2020):

"Where these concerns arise is from the perceived position of the sequencer in the Optimistic Ethereum network. It is important to note that the sequencer is not necessary to access  Optimistic Ethereum - it is there to provide significant UX improvements. Most people also assume a single sequencer means a single point of failure, which would be bad, but the failure case is just the shitty L1 UX we already have. Obviously falling back to L1 blocktimes is not ideal, but there are numerous potential solutions including backup sequencers that can step in if the active sequencer fails or is attacked. All of these concerns are only temporary, as the goal is still to move towards a network of sequencers as quickly as possible."

Zk Rollups

  • Settle on L1 as cryptographic proofs. Utilizes zero-knowledge cryptography (SNARKs or STARKs). The state can only be updated with validity proofs, securing transactions cryptographically.
  • The following comes from this Twitter thread by Token Terminal (24-6-2020):

What are ZkRollups? In a ZKR, validators generate ZK proofs of all state transitions. ZK proofs are instantly verified by the Rollup contract on Ethereum. This means that it is extremely difficult to manipulate a block or commit a block with an invalid state."

"zk Rollups, the other Rollup scaling option, aims for larger scalability of Ethereum L2 in terms of L2 transactions per second (TPS). However, the technology is still limited to specific use cases, e.g., payments or exchanges, and is bottlenecked by the complexity of the generation of zk proofs. In this area, there are two competing projects: Loopring and Matterlab’s zkSync. Loopring initially used zk Rollups to implement an L2 DEX and have since expanded into the L2 payments arena, with the launch of Loopring Pay. In contrast, zkSync first focused on L2 payments. The team recently launched the product."

"Optimistic Rollups are a layer 2 sidechain construction which seeks to alleviate the burden on Ethereum’s main chain. The basic idea is that instead of validating all transactions on the rollup sidechain, the mainchain simply publishes them and "optimistically" assumes they're valid unless explicitly challenged.

The core benefit to employing rollups is lower gas costs for users, which translates to more transactions per second (several hundred TPS at least) for the network as a whole. Cheaper transactions also means that certain applications that would otherwise be too gas intensive to even be possible, like privacy solutions that employ complex cryptography, now become feasible. Thus, while rollup itself doesn't inherently offer privacy benefits, it's a fitting substrate on which to build privacy preserving technology. Likewise, rollup doesn't inherently increase transaction latency (speed), but gives a nice environment on which channels, which can offer virtually instant transactions, can be built.

The way Optimistic Rollups handle data gives the constructions some nice simplicity, especially relative to alternative layer 2 protocols. Crucially, this translates to UX for end users that could (and should!) feel nearly identical to that of using layer 1. Likewise, for developers and protocol designers, much of the tools and thought-models they are accustomed to will still be available, though as we'll see, tackling some challenges around composability may require some additional work.

First, a user deposits some funds (“funds” could be Ether, ERC20s, ERC721s, etc.) onto a rollup chain; this first step mirrors the UX of many layer 1 dApps, in which the user must initially transfer funds into a contract before using it. At this point, a user can issue transactions on the application as they usually would; if the rollup chain is designed to prioritize censorship resistance, getting one’s transaction included doesn't depend on any more trust, reputation, or goodwill—and doesn’t invite any more potential censorship or front-running—than publishing an L1 transaction.

When a user wants to bring their assets back to layer 1, they issue a special withdrawal transaction. Here we see a potential difference: recall that Optimistic Rollup’s security model depends on the ability for parties to issue challenges; thus, we need to allow a grace period for any parties monitoring the activity to (potentially) prove fraudulence. This means that once a withdrawal is requested, the user must wait before the funds are accessible again on layer 1; the economic security this mechanism gives is a function of both the amount of stake required to produce rollup blocks and the length of this waiting period (Ed Felten argues here that 3 hours is sufficient). 

With that said, the hope/expectation is that users will rarely, if ever, have to actually wait through this grace period. Third parties can offer to purchase ownership of your pending withdrawal by sending you the equivalent value on layer 1, minus some fee, enabling you to access your funds without having to wait. Thus, as long as such liquidity providers are indeed available, and with an interface that abstracts the complexity away, even withdrawals will hit UX parity with layer 1."

Usage

"After integrating with OMG Network, Tether is now planning to add support for another Layer-2 scaling solution — ZK-Rollups."

Pessimistic Rollup

  • From ethresea.rch (28-7-2020):

"Current scalability solutions move the users into another domain where their transactions are validated. If they want to leave that domain they may have to pay a high cost. There are ways to minimize 1 these costs.

The concern remains that if we do not allow layer 2 to call smart contracts on layer 1 then arbitrage opportunity and price differences between assets will cause problems.

There seems to be some urgency to scale interactions between users and smart contracts given the current gas market fluctuations.

Here we propose a temporary scalability improvement of 3x on layer 1 by putting many users in a smart contract “super” wallet and batching their various uniswap interactions. This solution can realistically be build audited and deployed in a few months. It is composable with smart contracts that allow batched user interactions for example uniswap where matching pool operations are very similar no matter how many users funds are included. Something like DAI where users have a specific smart CDP that they own is not so well suited.

This will work in the short term. In the medium term a zkrollup with similar properties can be built. Which will allow this to scale orders of magnitude more.

Another benefit of this approach is that it prepares the defi and broader smart contract communities for building on layer 1 in a way that can easily interface with layer 2."

Enshrined Rollup

  • Rollups intertwined with the consensus and data availability layer. Slow to update, considered in a "final" state with governance required to upgrade. A route Tezos is embarking on (2022).
  • From r/ethereum (8-2022) which planned to incorporate this, but later Vitalik seemed to have moved away from the idea:

"An enshrined rollup is a rollup that enjoys some sort of consensus integration at L1. Enshrined rollups contrast smart contract rollups which live fully at L2, outside of consensus. Consensus integration can endow enshrined rollups with superpowers at the cost of significant tradeoffs—see below for a detailed discussion of pros and cons. Zooming out, enshrined rollups and smart contract rollups are complementary. This means building a state root equivalent zkEVM to provide L1 Ethereum blocks with succinct cryptographic proofs (SNARKs) that the corresponding state roots are valid. This comes with various benefits:

  1. no reexecution: Validators and other full nodes no longer have to reexecute transactions to validate a block. This removes compute as a consensus bottleneck for validators, potentially an opportunity to increase the EVM gas limit. Removing the need for reexecution also accelerates most sync strategies.
  2. simpler consensus: The removal of execution from consensus means that validators can run ultra-simple execution clients, where tens of thousands of consensus-critical EVM execution code collapse to a few hundred lines of SNARK verification code.
  3. no state witnesses: Stateless execution clients no longer have to download witnesses (e.g. Merkle paths or Verkle proofs)—state diffs suffice. This greatly increases the consensus bandwidth efficiency for validators and unlocks a higher EVM gas limit.
  4. safer light clients: Light clients can quickly filter invalid state roots, in contrast to the slow filtering of invalid state roots with fraud proofs. This allows for safer Ethereum-to-L1 bridges.

advantages

  1. social consensus: Enshrined rollups inherit L1 social consensus, removing the need for governance tokens to perform rollup upgrades. In contrast, most smart contract rollups may be exposed to governance attacks.
  2. subsidised proof verification: Enshrined rollups can subsidise the fixed per-block cost of proof verification for settlement. In contrast, smart contract rollups have to pay EVM gas for settlement.
  3. settlement latency: Enshrined rollups naturally benefit from per-block settlement latency.
  4. optimal liveness: Many smart contract rollups may elect to have an external consensus mechanism for sequencing, as well as on-chain escape hatches. Such sequencing infrastructure suffers from suboptimal liveness because the external consensus may fail and escape hatches only activate after a timeout.
  5. state root EVM equivalence: Tooling and light clients for an enshrined zkEVM work out of the box. Many smart contract rollups may elect to not have EVM state root equivalence, instead targetting a Solidity-compatible VM (e.g. zkSync) or a bytecode-equivalent EVM (e.g. Scroll).
  6. network effects: The canonical EVM instance enjoys network effects from being a first-mover and the upgrade to an enshrined preserves these network effects.

disadvantages

  1. no public goods funding: Enshrined zkEVM rollups would be constrained in their discretionary power to fund public goods. Unlike Optimism which has governance to fund any public good, enshrined zkEVMs will be limited to funding L1 security and contributing to the scarcity of ETH.
  2. suboptimal compression: Smart contract rollups may choose to settle on-chain less than once per block allowing for better data compression. Smart contract rollups may also have a custom or frequently-updated dictionary for improved data compression.
  3. VM inflexibility: An Ethereum enshrined VM would likely be an EVM. In contrast smart contract rollups have the option to adopt a popular VM (e.g. WASM, RiscV, MIPS) or create a new VM (e.g. Cairo). A custom zkVM may be able to achieve better data compression than a zkEVM.
  4. harder preconfirmations: Smart contract rollups may choose to have a centralised sequencer that provides instant (~100ms) preconfirmations for improved UX. Such fast preconfirmations are harder to achieve with decentralised sequencing, both in the context of enshrined rollups and smart contract rollups.
  5. last mover: Enshrined zkEVMs will be the last mover because of the slowness and conservatism of the L1. To hedge against circuit bugs a redundant multi-circuit setup (e.g. 2-of-3) or heavy formal verification may be required."

Upgradability

"The eventual goal of current Ethereum rollups is that the rollups should not be upgradeable by a multisig or a committee, because if they can, they are not trust-minimized as funds can be stolen via an upgrade. In this model, rollups can only be upgraded by hard forking the L1 because the canonical chain is defined by the L1's settlement layer, meaning the rollups have no sovereignty."

Comparison

"There are two types of rollups: (i) ZK Rollups, and (ii) Optimistic Rollups. ZK Rollups, although faster and more efficient than Optimistic Rollups, do not provide an easy way for the existing smart contracts to migrate to layer 2. Optimistic Rollups, on the other hand, run an EVM compatible virtual machine called Optimistic Virtual Machine (OVM) which allows for executing the same smart contracts that can be executed on Ethereum."

"There are 2 schools of thought when understanding layer-2 solution trade-offs:

  1. Zero-knowledge proof is the superior solution while optimistic rollups has critical flaws.
  2. The recursive zero-knowledge proof tech required for generalized smart contract support is very difficult and even if achieved, proof sizes would be too big and costly making optimistic rollups the winning layer-2 solution.

What those in the optimistic rollup camp say about zero knowledge proofs (ZKPs):

  1. It’s too new and risky: STARKs and PLONKs are recent innovations while SNARKs have been around since 2013
  2. Generic turing complete smart contracts require recursion, something ZkSync wasn’t expected to be capable of (though Starkware has recently rolled this out)
  3. Proof sizes will be big and expensive
  4. Use new programming languages which needs to be transpiling from Solidity code (something not yet available)

What those in the ZKP camp say about optimistic rollups:

  1. 1 rollup can support a max of $10m -$50m in value before it can be profitably exploited
  2. Very slow withdrawal times
  3. Inferior security compared with layer-1 Ethereum
  4. Rolling back state would be unworkable in practice

Optimism is nearly ready; simpler, will have a decentralized network and does not require porting of code to a new language. It also has the backing of two DeFi giants Synthetix and Uniswap.

Although ZKP solutions might be technically better, Optimism has the first mover advantage combined with simple onboarding and backing.

As the 2 leading DeFi giants launch Optimism in the new year it will be key to watch how much usage and liquidity they attract to the layer-2 instances. If the migration is fast then this would amount to a hard to disrupt network effect. If the migration of leading layer-1 projects to layer-2 does not quite happen, then this may give ZkSync time to roll general smart contract support with transpiling and attract some early adopters.

Starkware’s ZKP based StarkEx platform is ready now. It is using their Turing complete Cairo language which is capable of general smart contract support and has been adopted and is in production use by DeversiFi and dYdX."

Compared with Modular chains

"Celestia and Polygon Avail (and probably others that we’re not yet aware of) are new blockchains that have been specially designed to solve the data availability problem, in what is called ‘modular blockchain’ architecture. These blockchains don't verify transactions, but simply check that each block was added by consensus and that new blocks are available to the network.

Rollups do not post their blocks to a smart contract, but directly onto data availability chain as raw data. The Celestia consensus and data availability layer doesn’t interpret or perform computations on the rollup blocks, nor run an on-chain light client for the rollup."

Shared Security

"If an attacker can 51% attack the smaller chain, how much damage can they do?

If the smaller chain is a "rollup", they can delay transactions and perhaps even force users to pay L1 fees, but they can't steal anything. This is because there is an on-chain mechanism (whether fraud proofs or data availability proofs) that can actually check that the events on the smaller chain leading up to the attacker's withdrawal are all valid.

This is what we mean by "shared security". If you are hodling assets and doing stuff on the smaller chain, are you as secure as if you were doing it on the larger chain, or are you less secure? On a rollup or a plasma, you are just as secure. On an independent L1 or a sidechain, you are much less secure. On a validium, you're somewhere in the middle."

Retrieved from "https://cryptowiki.me/index.php?title=Rollups&oldid=19180"