Difference between revisions of "Rollups"
m (1 revision imported) |
m |
||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Basics == | == Basics == | ||
* [[Second Layer]] scaling technology for [[ | * [[Second Layer]] scaling technology initially proposed within the [[Ethereum]] community. Later on more widely experimented with by for example [[Tezos (XTZ)|Tezos]]. | ||
*The following comes from this [[Twitter]] [https://twitter.com/tokenterminal/status/1275827569561153539 thread] by [[Token Terminal]] (24-6-2020): | |||
* The following comes from this [[Twitter]] [https://twitter.com/tokenterminal/status/1275827569561153539 thread] by [[Token Terminal]] (24-6-2020): | ''What are Rollups? Rollups are non-[[custodial]] sidechains that solve [[Plasma|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.'' | ||
''What are Rollups? Rollups are non-custodial sidechains that solve [[Plasma|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:'' | ''Rollups come in two flavours:'' | ||
# ''Optimistic rollups - ORs depend on a dispute game run by active validators.'' | # ''Optimistic rollups - ORs depend on a dispute game run by active validators.'' | ||
# ''ZkRollups - ZKRs rely on cryptographic [[Zero-knowledge proof|zero-knowledge]] (ZK) proofs, which are instantly validated by a smart contract.'' | # ''ZkRollups - ZKRs rely on cryptographic [[Zero-knowledge proof|zero-knowledge]] (ZK) proofs, which are instantly validated by a smart [[contract]].'' | ||
* From this [https://www.tokendaily.co/blog/the-state-of-ethereum-l2 blog] by [[Token Daily]] (7-7-2020): | * From this [https://www.tokendaily.co/blog/the-state-of-ethereum-l2 blog] by [[Token Daily]] (7-7-2020): | ||
"''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."'' | "''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 == | == History == | ||
* From [https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad this deep dive] (27-1-2020 done by [[Dragonfly Capital Partners|Dragonfly]]) into why [[Plasma]] died, and how zk-Rollup came out of it: | * From [https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad this deep dive] (27-1-2020 done by [[Dragonfly Capital Partners|Dragonfly]]) into why [[Plasma]] died, and how zk-Rollup came out of it: | ||
''"But zk-Rollup came with its own set of tradeoffs. Namely, validity proofs are computationally expensive to generate (details [https://medium.com/starkware/validity-proofs-vs-fraud-proofs-strike-back-4d0bf90eed15 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).'' | ''"But zk-Rollup came with its own set of tradeoffs. Namely, validity proofs are computationally expensive to generate (details [https://medium.com/starkware/validity-proofs-vs-fraud-proofs-strike-back-4d0bf90eed15 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 [https://github.com/stellar/slingshot/tree/main/zkvm zkVM] and [https://github.com/scipr-lab/zexe 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|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 [https://github.com/matter-labs/zksync ZK Sync] network.'' | |||
''Additionally, [[Starkware]] (also a portfolio company) is building a variation on zk-Rollup they call [https://medium.com/starkware/starkexchange-8045695b798 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 == | |||
# [[Sequencer|Sequencers]] / Proposers | |||
# Provers | |||
# Node runners | |||
* From [[Taiko]]'s [https://mirror.xyz/labs.taiko.eth/sxR3iKyD-GvTuyI9moCg4_ggDI4E4CqnvhdwRq5yL0A blog] (21-12-2023): | |||
''"Proposers construct rollup [[Block|blocks]] from users’ L2 [[Transaction (Tx)|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 Contract (SC)|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 == | == Optimistic Rollups == | ||
* The following comes from this [[Twitter]] [https://twitter.com/tokenterminal/status/1275827569561153539 thread] by [[Token Terminal]] (24-6-2020): | * Settles transactions as [[Layer One|L1]] calldata. Assumes every transaction is valid by default as it does not [[compute]] the transaction. Uses [[Fraud Proofs|fraud proofs]] to dispute transactions, hence the seven-day withdrawal period. | ||
*The following comes from this [[Twitter]] [https://twitter.com/tokenterminal/status/1275827569561153539 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.'' | ''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.'' | ||
* From this [https://www.tokendaily.co/blog/the-state-of-ethereum-l2 blog] by [[Token Daily]] (7-7-2020): | * From this [https://www.tokendaily.co/blog/the-state-of-ethereum-l2 blog] by [[Token Daily]] (7-7-2020): | ||
''"A major project in the Optimistic Rollups (OR) domain is [https://optimism.io/ Optimism]. Optimism is building the Optimistic Virtual Machine (OVM) which aims to scale arbitrary Ethereum transactions on L2. The team [https://medium.com/ethereum-optimism/synthetix-exchange-meets-the-ovm-2de3a572d6df 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 [https://blog.idex.io/all-posts/o2-rollup-overview own scaling solution]. The IDEX team ran a demo for the solution in October of last year."'' | ''"A major project in the Optimistic Rollups (OR) domain is [https://optimism.io/ Optimism]. [[Optimism]] is building the Optimistic [[Virtual Machine]] (OVM) which aims to scale arbitrary Ethereum transactions on L2. The team [https://medium.com/ethereum-optimism/synthetix-exchange-meets-the-ovm-2de3a572d6df 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 [https://blog.idex.io/all-posts/o2-rollup-overview own scaling solution]. The IDEX team ran a demo for the solution in October of last year."'' | ||
* [https://ethresear.ch/t/rollup-diff-compression/7933 Rollup diff compression]. Using that compression, optimistic rollup [https://twitter.com/fuellabs_/status/1300468388695810050 Fuel benchmarks] 2500 [[TPS|tps]] for token transfers. | * [https://ethresear.ch/t/rollup-diff-compression/7933 Rollup diff compression]. Using that compression, optimistic rollup [https://twitter.com/fuellabs_/status/1300468388695810050 Fuel benchmarks] 2500 [[TPS|tps]] for [[token]] transfers. | ||
=== Difference with Plasma === | === Difference with Plasma === | ||
Line 34: | Line 56: | ||
=== Cons === | === Cons === | ||
* From a [https://blog.synthetix.io/why-optimism/ blog] post by [[Kain Warwick|Kain]] from [[Synthetix]] (which will use Optimistic Rollups) (21-10-2020): | * From a [https://blog.synthetix.io/why-optimism/ blog] post by [[Kain Warwick|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."'' | "''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 == | == Zk Rollups == | ||
* The following comes from this [[Twitter]] [https://twitter.com/tokenterminal/status/1275827569561153539 thread] by [[Token Terminal]] (24-6-2020): | * Aka Validity 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]] [https://twitter.com/tokenterminal/status/1275827569561153539 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."'' | ''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."'' | ||
* From this [https://www.tokendaily.co/blog/the-state-of-ethereum-l2 blog] by [[Token Daily]] (7-7-2020): | * From this [https://www.tokendaily.co/blog/the-state-of-ethereum-l2 blog] by [[Token Daily]] (7-7-2020): | ||
"''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 [[Matter Labs|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 [https://medium.com/matter-labs/zksync-is-live-bringing-trustless-scalable-payments-to-ethereum-9c634b3e6823 launched] the product."'' | "''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 [[Matter Labs|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 [https://medium.com/matter-labs/zksync-is-live-bringing-trustless-scalable-payments-to-ethereum-9c634b3e6823 launched] the product."'' | ||
* From [[Bankless]] (16-4-2020): | * From [[Bankless]] (16-4-2020): | ||
''"[https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/ Optimistic Rollups] are a [[layer 2]] [[sidechain]] construction which seeks to alleviate the burden on [[Ethereum (ETH)|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.'' | ''"[https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/ Optimistic Rollups] are a [[layer 2]] [[sidechain]] construction which seeks to alleviate the burden on [[Ethereum (ETH)|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 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 [https://www.theblockcrypto.com/post/16705/understanding-plasma-part-2-make-plasma-fungible-again 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.'' | ''The way Optimistic Rollups handle data gives the constructions some nice [[simplicity]], especially relative to [https://www.theblockcrypto.com/post/16705/understanding-plasma-part-2-make-plasma-fungible-again 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]], [[ERC20]]s, [[ERC721]]s, 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 [https://medium.com/offchainlabs/eleven-questions-to-ask-your-rollup-provider-b0831ee6b864 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.'' | ''First, a user deposits some funds (“funds” could be [[Ether]], [[ERC20]]s, [[ERC721]]s, 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 [https://medium.com/offchainlabs/eleven-questions-to-ask-your-rollup-provider-b0831ee6b864 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 [https://medium.com/offchainlabs/fighting-censorship-attacks-on-smart-contracts-c026a7c0ff02 here] that 3 hours is sufficient). '' | ''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 [https://medium.com/offchainlabs/fighting-censorship-attacks-on-smart-contracts-c026a7c0ff02 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."'' | ''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 === | === Usage === | ||
* [https://research-development.nomadic-labs.com/future-validity-rollups.html From] [[Nomadic Labs]] (5-2023): | |||
''"Currently available validity rollups and their approach:'' | |||
''currently available validity rollups and their approach:'' | |||
''Optimizing for throughput (and cost): [[ZkSync (ZKS)|ZkSync]] Lite, [[DYdX (DYDX)|dYdX]], [[Loopring (LRC)|Loopring]], [[Immutable X (IMX)|Immutable X]] follow the same philosophy as Tezos’ Epoxy – relying on application specific ZK circuits to get good scalability (in the order of 1000 transactions per second). Building those circuits, however, is an expensive and delicate task, and compatibility is limited.'' | |||
''Optimized for compatibility (and cost): ZkVM projects, such as ZkSync Era and [[Polygon (MATIC)|Polygon]] ZkEVM, go for a compatibility-first approach. Even though this technology is promising, we’ve yet to see them achieve high throughput."'' | |||
* [https://ethhub.substack.com/p/ethhub-weekly-130?token=eyJ1c2VyX2lkIjoxMzk3OTAwLCJwb3N0X2lkIjoxMzA2NTQ2LCJfIjoiMG96ZDgiLCJpYXQiOjE1OTk1Njc5ODYsImV4cCI6MTU5OTU3MTU4NiwiaXNzIjoicHViLTM5MTAiLCJzdWIiOiJwb3N0LXJlYWN0aW9uIn0.JtJUqFUDPPr3ShbSbLPCEZypQbQBpiDxkquQMmyHTGw From] [[EthHub]] #130 (7-9-2020): | * [https://ethhub.substack.com/p/ethhub-weekly-130?token=eyJ1c2VyX2lkIjoxMzk3OTAwLCJwb3N0X2lkIjoxMzA2NTQ2LCJfIjoiMG96ZDgiLCJpYXQiOjE1OTk1Njc5ODYsImV4cCI6MTU5OTU3MTU4NiwiaXNzIjoicHViLTM5MTAiLCJzdWIiOiJwb3N0LXJlYWN0aW9uIn0.JtJUqFUDPPr3ShbSbLPCEZypQbQBpiDxkquQMmyHTGw From] [[EthHub]] #130 (7-9-2020): | ||
"''After integrating with [[OMG Network (OMG)|OMG Network]], [[Tether]] is now [https://www.theblockcrypto.com/linked/76552/tether-plans-zk-rollups-support-reduce-pressure-on-ethereum planning] to add support for another [[Layer-2]] scaling solution — [[ZK-Rollups]]."'' | "''After integrating with [[OMG Network (OMG)|OMG Network]], [[Tether]] is now [https://www.theblockcrypto.com/linked/76552/tether-plans-zk-rollups-support-reduce-pressure-on-ethereum planning] to add support for another [[Layer-2]] scaling solution — [[ZK-Rollups]]."'' | ||
== Based Rollups == | |||
[https://www.bankless.com/based-rollups-primer From] [[Bankless DAO (BANK)|Bankless]] (26-9-2024): | |||
''"Unlike traditional rollups that rely on their own [[Sequencer|sequencers]], based rollups tap into the security, liveness, and decentralization of the L1 by outsourcing transaction sequencing to the L1’s infrastructure. This infrastructure includes proposers, searchers, builders, and other actors who [[Permissionless|permissionlessly]] include based rollup blocks in L1 blocks.'' | |||
''Initially, this approach seemed inefficient — [[Vitalik Buterin|Vitalik]] once called it "total anarchy" in his 2021 article on rollups. But today based rollups have become much more feasible. In 2023, Ethereum researcher [[Justin Drake]] brought the concept back into focus, arguing that based rollups not only align more closely with Ethereum but also eliminate the need for separate security assumptions for each new rollup.'' | |||
''Based rollups use the L1 for [[consensus]], [[Data availability (DA)|data availability]], and settlement layers, while handling execution independently. For instance, when Ethereum is the base L1, the key layers of based rollups are as follows:'' | |||
# ''Execution Layer — Managed by the rollup itself, where transactions are executed off-chain.'' | |||
# ''Consensus Layer — Relies on Ethereum validators to sequence transactions.'' | |||
# ''Data Availability Layer — Uses Ethereum as the DA layer to ensure that transaction data is available for validation by anyone.'' | |||
# ''Settlement Layer — Also part of Ethereum, where final transaction states of the rollup are recorded.'' | |||
''It has a few key projects emerging:'' | |||
* ''[[Taiko (TAIKO)|Taiko]] — an Ethereum-equivalent (Type 1) ZK-EVM that is maximally compatible with Ethereum and does not introduce additional trust assumptions.'' | |||
* ''KeySpace — a zk-rollup by [[Coinbase (COIN)|Coinbase]] aimed at creating smart wallets usable across any chain.'' | |||
* ''Taiko Gwyneth — a based rollup using pre-confirmations, designed for synchronous composability with Ethereum.'' | |||
* ''UniFi — a based rollup developed by the [[Puffer Finance|PufferFi]] team that employs pre-confirmations to enhance user experience.'' | |||
* ''[[Spire Labs]] — a framework on Ethereum that allows developers to build based appchains.'' | |||
''One of the key advantages of based rollups is their ability to inherit the liveness guarantees of the base L1 chain. As long as the L1 is operational, so is the rollup."'' | |||
One of its downsides is that it is 'as slow' as the L1, and do all the interactions, also is more expensive than other rollups. | |||
== Pessimistic Rollup == | == Pessimistic Rollup == | ||
* [https://ethresear.ch/t/pessimistic-rollup-scalable-batched-smart-contract-interactions/7765 From] ethresea.rch (28-7-2020): | * [https://ethresear.ch/t/pessimistic-rollup-scalable-batched-smart-contract-interactions/7765 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 [https://ethresear.ch/t/mass-migration-to-prevent-user-lockin-in-rollup/7701 minimize] 1 these costs.'' | ''"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 [https://ethresear.ch/t/mass-migration-to-prevent-user-lockin-in-rollup/7701 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.'' | ''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.'' | ''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.'' | ''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|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 (XTZ)|Tezos]] is [https://news.tezoscommons.org/rollups-on-tezos-part-ii-316d7dc8ecbd embarking] on (2022): | |||
''"Tezos having “enshrined” rollups means that when the rollups are originated, they become part of the Tezos protocol (layer 1) and are not deployed as smart contracts like we see on other chains (i.e.; ethereum).'' | |||
''Tezos will be the first blockchain to implement enshrined rollups bringing along a lot of benefits. To name a few:'' | |||
# ''There won’t be the need for any “[[Admin Keys|admin keys]]” or [[Multisig|multi-sigs]] that allow the originator or any single entity to have control over them.'' | |||
# ''They will be much more computation and gas efficient for the Layer 1.'' | |||
# ''They allow for more complex features to be enabled that would normally be nearly impossible to implement on a smart contract-based rollup."'' | |||
* | |||
*[https://www.reddit.com/r/ethereum/comments/vrx9xe/comment/if7auu7/ From] r/ethereum (8-2022) which planned to incorporate this, but later [[Vitalik Buterin|Vitalik]] seemed to have [https://vitalik.eth.limo/general/2023/03/31/zkmulticlient.html moved away] from the idea: | |||
''"An enshrined rollup is a rollup that enjoys some sort of [[consensus]] integration at [[Layer One|L1]]. Enshrined rollups contrast smart contract rollups which live fully at [[Layer Two|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:'' | |||
# ''no reexecution: [[Validators]] and other [[Full Node|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.'' | |||
# ''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 [[Zk-SNARK's|SNARK]] verification code.'' | |||
# ''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.'' | |||
# ''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'' | |||
# ''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.'' | |||
# ''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.'' | |||
# ''settlement [[latency]]: Enshrined rollups naturally benefit from per-block settlement latency.'' | |||
# ''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.'' | |||
# ''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 (ZKS)|zkSync]]) or a bytecode-equivalent EVM (e.g. [[Scroll]]).'' | |||
# ''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'' | |||
# ''no public goods funding: Enshrined zkEVM rollups would be constrained in their discretionary power to fund public goods. Unlike [[Optimism (OP)|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.'' | |||
# ''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.'' | |||
# ''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.'' | |||
# ''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.'' | |||
# ''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 == | |||
* As of 7-11-2022, most rollup based projects have [[centralized]] [[Admin Key|admin keys]] and are upgradable. Most do claim to be working towards [[Decentralized|decentralizing]] the [[sequencer]] and the contracts. | |||
* As the team at [[Celestia]] [a competitor with rollups] [https://blog.celestia.org/sovereign-rollup-chains/ puts it]: | |||
''"The eventual goal of current Ethereum rollups is that the rollups should not be upgradeable by a [[Multi-Signature|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 Fork|hard forking]] the [[Layer One|L1]] because the canonical chain is defined by the L1's settlement layer, meaning the rollups have no sovereignty."'' | |||
== Comparison == | == Comparison == | ||
* A breakdown in security differences can be read in [https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/ this post] by [[Vitalik Buterin]] (1-2-2022). | * A breakdown in security differences can be read in [https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/ this post] by [[Vitalik Buterin]] (1-2-2022). He goes into different zkEVMs [https://vitalik.eth.limo/general/2022/08/04/zkevm.html here](4-8-2022). | ||
* From this [https://medium.com/plotx/what-is-l2-and-why-is-it-needed-1138c39230e3 blog] by [[PlotX (PLOT)|PlotX]] (25-1-2021): | * From this [https://medium.com/plotx/what-is-l2-and-why-is-it-needed-1138c39230e3 blog] by [[PlotX (PLOT)|PlotX]] (25-1-2021): | ||
''"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 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."'' | ||
*[http://go.pardot.com/webmail/875501/85523681/2b20a6f8dc8c121fae6b65873b77f1016b78c2da4f7c265daab00f17699471cd From] [[Delphi Digital]] (12-2020): | *[http://go.pardot.com/webmail/875501/85523681/2b20a6f8dc8c121fae6b65873b77f1016b78c2da4f7c265daab00f17699471cd From] [[Delphi Digital]] (12-2020): | ||
"''There are 2 schools of thought when understanding layer-2 solution trade-offs:'' | "''There are 2 schools of thought when understanding layer-2 solution trade-offs:'' | ||
# ''Zero-knowledge proof is the superior solution while optimistic rollups has critical flaws.'' | # ''[[Zero-knowledge proof]] is the superior solution while optimistic rollups has critical flaws.'' | ||
# ''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.'' | # ''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):'' | ''What those in the [[optimistic rollup]] camp say about [[zero knowledge proofs]] (ZKPs):'' | ||
# ''It’s too new and risky: [[STARKs]] and [[PLONK|PLONKs]] are recent innovations while [[Zk-SNARK's|SNARKs]] have been around since 2013'' | # ''It’s too new and risky: [[STARKs]] and [[PLONK|PLONKs]] are recent innovations while [[Zk-SNARK's|SNARKs]] have been around since 2013'' | ||
# ''Generic [[turing Complete|turing complete]] smart contracts require recursion, something [[ZkSync]] wasn’t expected to be capable of (though [[Starkware]] has recently rolled this out)'' | # ''Generic [[turing Complete|turing complete]] smart contracts require recursion, something [[ZkSync]] wasn’t expected to be capable of (though [[Starkware]] has recently rolled this out)'' | ||
Line 96: | Line 201: | ||
''Although ZKP solutions might be technically better, Optimism has the first mover advantage combined with simple onboarding and backing.'' | ''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.'' | ''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|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 === | |||
* [https://doseofdefi.substack.com/p/the-market-opportunity-of-modular From] [[Dose Of DeFi|Dose of DeFi]] (4-11-2022): | |||
''"[[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 [[Transaction (Tx)|transactions]], but simply check that each [[block]] was added by [[Consensus Algorithm|consensus]] and that new blocks are available to the network.'' | |||
'' | ''Rollups do not post their blocks to a [[Smart Contract (SC)|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|on-chain]] [[Node|light client]] for the rollup."'' | ||
== Shared Security == | == Shared Security == | ||
Line 108: | Line 221: | ||
''If the smaller chain is a "rollup", they can delay [[Transaction (Tx)|transactions]] and perhaps even force users to pay [[Layer One|L1]] [[Transaction Fee|fees]], but they can't steal anything. This is because there is an [[On Chain|on-chain]] mechanism (whether [[Fraud Proofs|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.'' | ''If the smaller chain is a "rollup", they can delay [[Transaction (Tx)|transactions]] and perhaps even force users to pay [[Layer One|L1]] [[Transaction Fee|fees]], but they can't steal anything. This is because there is an [[On Chain|on-chain]] mechanism (whether [[Fraud Proofs|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."'' | ''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."'' | ||
[[Category:Jargon/Various]] | [[Category:Jargon/Various]] |
Latest revision as of 09:32, 9 October 2024
Basics
- Second Layer scaling technology initially proposed within the Ethereum community. Later on more widely experimented with by for example Tezos.
- The following comes from this Twitter thread by Token Terminal (24-6-2020):
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:
- Optimistic rollups - ORs depend on a dispute game run by active validators.
- ZkRollups - ZKRs rely on cryptographic zero-knowledge (ZK) proofs, which are instantly validated by a smart contract.
- From this blog by Token Daily (7-7-2020):
"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
- From this deep dive (27-1-2020 done by Dragonfly) into why Plasma died, and how zk-Rollup came out of it:
"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
- Sequencers / Proposers
- Provers
- 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.
- From this blog by Token Daily (7-7-2020):
"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."
- Rollup diff compression. Using that compression, optimistic rollup Fuel benchmarks 2500 tps for token transfers.
Difference with Plasma
- From Daily Gwei (25-9-2020):
"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
"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
- Aka Validity 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."
- From this blog by Token Daily (7-7-2020):
"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."
- From Bankless (16-4-2020):
"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
- From Nomadic Labs (5-2023):
"Currently available validity rollups and their approach:
currently available validity rollups and their approach:
Optimizing for throughput (and cost): ZkSync Lite, dYdX, Loopring, Immutable X follow the same philosophy as Tezos’ Epoxy – relying on application specific ZK circuits to get good scalability (in the order of 1000 transactions per second). Building those circuits, however, is an expensive and delicate task, and compatibility is limited.
Optimized for compatibility (and cost): ZkVM projects, such as ZkSync Era and Polygon ZkEVM, go for a compatibility-first approach. Even though this technology is promising, we’ve yet to see them achieve high throughput."
"After integrating with OMG Network, Tether is now planning to add support for another Layer-2 scaling solution — ZK-Rollups."
Based Rollups
"Unlike traditional rollups that rely on their own sequencers, based rollups tap into the security, liveness, and decentralization of the L1 by outsourcing transaction sequencing to the L1’s infrastructure. This infrastructure includes proposers, searchers, builders, and other actors who permissionlessly include based rollup blocks in L1 blocks.
Initially, this approach seemed inefficient — Vitalik once called it "total anarchy" in his 2021 article on rollups. But today based rollups have become much more feasible. In 2023, Ethereum researcher Justin Drake brought the concept back into focus, arguing that based rollups not only align more closely with Ethereum but also eliminate the need for separate security assumptions for each new rollup.
Based rollups use the L1 for consensus, data availability, and settlement layers, while handling execution independently. For instance, when Ethereum is the base L1, the key layers of based rollups are as follows:
- Execution Layer — Managed by the rollup itself, where transactions are executed off-chain.
- Consensus Layer — Relies on Ethereum validators to sequence transactions.
- Data Availability Layer — Uses Ethereum as the DA layer to ensure that transaction data is available for validation by anyone.
- Settlement Layer — Also part of Ethereum, where final transaction states of the rollup are recorded.
It has a few key projects emerging:
- Taiko — an Ethereum-equivalent (Type 1) ZK-EVM that is maximally compatible with Ethereum and does not introduce additional trust assumptions.
- KeySpace — a zk-rollup by Coinbase aimed at creating smart wallets usable across any chain.
- Taiko Gwyneth — a based rollup using pre-confirmations, designed for synchronous composability with Ethereum.
- UniFi — a based rollup developed by the PufferFi team that employs pre-confirmations to enhance user experience.
- Spire Labs — a framework on Ethereum that allows developers to build based appchains.
One of the key advantages of based rollups is their ability to inherit the liveness guarantees of the base L1 chain. As long as the L1 is operational, so is the rollup."
One of its downsides is that it is 'as slow' as the L1, and do all the interactions, also is more expensive than other 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):
"Tezos having “enshrined” rollups means that when the rollups are originated, they become part of the Tezos protocol (layer 1) and are not deployed as smart contracts like we see on other chains (i.e.; ethereum).
Tezos will be the first blockchain to implement enshrined rollups bringing along a lot of benefits. To name a few:
- There won’t be the need for any “admin keys” or multi-sigs that allow the originator or any single entity to have control over them.
- They will be much more computation and gas efficient for the Layer 1.
- They allow for more complex features to be enabled that would normally be nearly impossible to implement on a smart contract-based rollup."
- 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:
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- settlement latency: Enshrined rollups naturally benefit from per-block settlement latency.
- 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.
- 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).
- 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
- 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.
- 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.
- 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.
- 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.
- 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
- As of 7-11-2022, most rollup based projects have centralized admin keys and are upgradable. Most do claim to be working towards decentralizing the sequencer and the contracts.
- As the team at Celestia [a competitor with rollups] puts it:
"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
- A breakdown in security differences can be read in this post by Vitalik Buterin (1-2-2022). He goes into different zkEVMs here(4-8-2022).
- From this blog by PlotX (25-1-2021):
"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."
- From Delphi Digital (12-2020):
"There are 2 schools of thought when understanding layer-2 solution trade-offs:
- Zero-knowledge proof is the superior solution while optimistic rollups has critical flaws.
- 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):
- It’s too new and risky: STARKs and PLONKs are recent innovations while SNARKs have been around since 2013
- Generic turing complete smart contracts require recursion, something ZkSync wasn’t expected to be capable of (though Starkware has recently rolled this out)
- Proof sizes will be big and expensive
- 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 rollup can support a max of $10m -$50m in value before it can be profitably exploited
- Very slow withdrawal times
- Inferior security compared with layer-1 Ethereum
- 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
- From Dose of DeFi (4-11-2022):
"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."
- A breakdown in security differences can be read in this post by Vitalik Buterin (1-2-2022):
"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."