Blockchain Scaling Using Rollups: A Comprehensive Survey

Blockchain systems have seen much growth in recent years due to the immense potential attributed to the technology behind these systems. However, this popularity has outlined a critical scalability issue that most blockchain systems are now confronted with. With their increasing popularity comes an increasing amount of load on the system. Several scaling solutions that modify either the functioning of the underlying protocol or that build on top of them have already been proposed; however, each of these solutions comes with their advantages and disadvantages. This paper aims to survey the current state-of-the-art of rollups as a scaling solution. We discuss the mode of operation of the different types of rollups, outline state-of-the-art implementations of each type together with their features and limitations. We also conduct a performance analysis comparing these implementations. Finally, we outline avenues for future research around rollups as a scaling solution.

in terms of transactions processed per second (TPS) is the 23 usual metric used to compare different blockchain systems. 24 By design, popular systems are providing low numbers to 25 their users, e.g. up to 7 TPS for the Bitcoin network [6] 26 and around 15 for Ethereum [7], [8]. More recent blockchain 27 systems (e.g., Solana [9], Avalanche [10]) have been able 28 to achieve higher throughput by proposing novel layer one 29 protocols [11]. One of the main reasons behind these low 30 performances is that using proof of work, as a consensus 31 The associate editor coordinating the review of this manuscript and approving it for publication was Baoping Cai . mechanism, implies that each network node processes each 32 transaction. Having several thousands [12] of networks nodes 33 coordinate on the order in which transactions are processed is 34 a difficult task; this reduces the network capacity, along with 35 other limiting factors like having a maximum block size [13]. 36 Scaling blockchain systems has been an open problem 37 since the emergence of these systems, as capacity limitations 38 were bound to happen by design. Recently, coming up with 39 scaling solutions has been considered with utmost urgency; 40 indeed, these capacity limitations have become one of the 41 biggest challenges to overcome in order to reach mass adop-42 tion of blockchain and cryptocurrency systems. Several scal- 43 ing solutions have been proposed by industry and academia 44 members [14]. These solutions can be classified in two cat-45 egories: first layer and second layer scaling solutions. Layer 46 one solutions provide performance enhancement by changing 47 parameters of the blockchain system (e.g. block size and 48 block time), changing the consensus mechanism, sharding the 49 network into a set of subnetworks or a combination of these. 50 Second layer solutions are solutions that build ''on top'' of 51 the first layer; they operate outside of the main blockchain 52 but still interact with it (usually in order to ensure security and 53 data availability to guarantee the soundness of the solution). 54 Sharding is a well-studied concept that was first introduced 98 in database systems in order to increase performance and 99 uptime. The idea behind sharding in a blockchain system is 100 to divide the set of network nodes into subsets called shards 101 (or committees) [15]. In this system, each shard executes a 102 subset of the network transactions. This alleviates the load 103 on network nodes; they are only required to execute and 104 achieve consensus on transactions processed by their com-105 mittee. Without sharding, network nodes have to execute 106 and achieve consensus on every transaction processed by the 107 network [16]. This system offers parallelism on transaction 108 execution as a processor with several cores would offer par-109 allelism on instructions. 110 However, sharding comes with its own security risks; mali-111 cious actors have the possibility of synchronizing an attack 112 on a specific committee. These actors could successfully 113 perform a 1% attack [17] on a single shard and control 114 transaction execution in this subnetwork. There exist ways 115 to counter such attacks, e.g. assigning nodes to a random 116 shard every certain amount of time. This shuffle of nodes 117 over shards makes it hard for an attacker to gather all its 118 malicious nodes in a single shard and perform the attack. 119 Therefore, the shard takeover attack is practically impossible 120 to execute [18], [19]. 121 Sharded networks often require having a decentralized syn-122 chronizing system (e.g., the beacon chain on Ethereum) that 123 manages shards. This implies shuffling nodes every epoch 124 to ensure security and managing cross-shard transactions. 125 Relying on such a system creates a certain overhead in the 126 network; shuffled nodes have to synchronize with their newly 127 assigned shard every shuffling cycle [20], [21]. This overhead 128 is required for a sharded system to behave correctly which 129 enables an increase in transaction throughput. 130 2) PROOF-OF-STAKE 131 Proof-of-Stake (PoS) is a consensus mechanism where block 132 creators are selected based on the amount of tokens (or stake) 133 they hold in the system. Whereas Proof-of-Work (PoW) is 134 a consensus mechanism where block creators are selected 135 based on the amount of hash power they possess. [22]. This 136 has several advantages; in particular, it makes blockchain 137 systems much more energy efficient [23] and frees block 138 creators (and therefore the whole blockchain system) from 139 energy costs. Block creators being bounded by energy costs 140 in a system based on an adjusted difficulty Proof-of-Work 141 consensus mechanism can lead to unexpected behavior. For 142 example, if the price of electricity is too high, miners can 143 reduce their mining effort to decrease the block difficulty. The 144 game theoretic strategies at play can lead to inconsistency in 145 block time in a Proof-of-Work network [24]. Proof-of-Stake 146 systems avoid these problems by dissociating block creation 147 from electrical power. incoherent; for example, two conflicting transactions (e.g., 151 same UTXOs or same nonce) from the same sender may be 152 included in different forks. It is feasible for block creators 153 to work on several different forks since working in a fork 154 does not require intensive computing power. This means that 155 these block creators can reap benefits from creating blocks 156 while hindering the system from achieving consensus. This is In state channels, users must be online at all times to be able 200 to distribute transactions through the network and signal mis-201 behavior from other actors (e.g., an actor unilaterally attempts 202 to close a channel). Therefore, there is an assumption that all 203 actors always live on the network. Sidechains (e.g., Polygon PoS) are secondary chains that 206 operate in parallel to a parent chain with their own consensus 207 mechanism; they are connected to the parent chain by a two-208 way bridge. The fact that sidechains are employing a different 209 consensus mechanism (e.g., Proof-of-Stake) means that there 210 is leeway for innovation and performance. This also means 211 that security is not guaranteed by the layer one protocol [31]. 212 Sidechains are pegged to a main blockchain system. 213 Tokens from the main blockchain network can be transferred 214 to the sidechain via a two-way peg. In fact, users can deposit 215 (lock) their tokens by sending a transaction to a smart contract 216 on the main blockchain. They are then converted to tokens 217 that live on the sidechain. Users can then transact on the 218 sidechain with these tokens, and transfer them back to main 219 chain tokens if they want to.

220
This interoperability is a key functionality of sidechains. 221 This way, a sidechain could be used to execute recurrent 222 transactions (e.g. minting tokens) that do not necessarily need 223 to go through the layer one consensus mechanism. Then, the 224 previously minted tokens can be transferred back to the main 225 chain.

226
It is worth noting that sidechains do not rely on their main 227 chain for security or consensus; they only rely on the main 228 chain for asset transfer. Therefore, no data critical to the 229 well-functioning of the sidechain is published on the main 230 chain.

231
3) PLASMA 232 A plasma system [28] is a separate blockchain that is pegged 233 to a main blockchain. Plasma systems run independently from 234 the main chain (i.e., as sidechains do) but publish data to the 235 main chain if it is needed. The published data usually consists 236 of data that needs to be secured by the layer one network 237 or that needs to always be available (e.g., the plasma block 238 headers). The original idea behind Plasma chains comes from 239 the fact that layer one blockchains would ideally not store 240 smart contract code for sophisticated systems. This would 241 bloat the layer one chain and make it harder to operate. Thus, 242 it is better practice to create another chain (Plasma) and have 243 the sophisticated software live on this network. Plasma works with an optimistic system; it is assumed 256 that at least one watcher is active at every moment to ensure 257 transactions published to the first layer are not fraudulent.

258
As with state channels, there is an assumption about the 259 liveness of certain actors; at least one watcher needs to be 260 live for the system to be secure.  Optimistic rollups require watchers to function properly.

273
Therefore, there is a liveness assumption, i.e. it is assumed 274 that there is at least one active watcher at every moment.  Table 1 compares different second layer scaling solu-295 tions in terms of data availability, liveness assumption (i.e., 296 whether or not users need to be active to ensure security) and 297 withdrawal time (i.e., time before users can retrieve the funds 298 they locked in layer one to use the solution).

301
Blockchain systems are still far from offering a quality of 302 service comparable to what centralized systems currently 303 offer in terms of transactions per second [6], [8]. Popular 304 systems are held back from offering efficient and accessible 305 services mainly because of resource limitations. Indeed, each 306 network node participating in the Proof-of-Work consensus 307 mechanism needs to validate every transaction. This takes 308 large amounts of computing power, storage capacity, and 309 time. Rollups are a way of reducing the resources and time 310 required to validate transactions by reducing the amount of 311 data each node needs to process. They provide this enhance-312 ment by using a second layer network composed of actors 313 who process transactions outside of the main chain. Then, the 314 transaction data is rolled up in batches which are published to 315 the layer one blockchain. Figure 3 shows how layer one and 316 two interact in a rollup context. Rollup systems are implemented through layer one smart 318 contracts. Different actors in rollups systems (e.g., aggre-319 gators, sequencers, verifiers) interact with this smart con-320 tract. Aggregators can publish the transaction data and other 321 information (e.g., state root) through this contract. Verifiers 322 also use it to dispute transactions when need be. Figure 4 323 shows the relations between the layer one and two users, 324 the aggregators and the layer one smart contracts in rollup 325 systems.

326
Users engage with rollups by transacting with the rollup 327 smart contract. Such a contract lives on the first layer; this 328 means that layer one fees need to be paid in order to start 329 using the layer two system. Users first need to deposit funds 330 via this contract. This deposit gives the user an amount of 331 second layer tokens of proportional value. With these tokens, 332 users can transact on the second layer system. They are 333 then less bounded by the first layer fees. To transact on the 334 layer two system, users send their transactions to aggregators 335 either directly or through a layer one smart contract (the 336 latter not shown in Figure 4). Aggregators then select a set 337    The name optimistic comes from the way these rollups 349 function. In this type of rollup, a layer two actor, which we

358
While detailed steps vary depending on the specific imple-359 mentation, optimistic rollups systems usually follow the same 360 high-level structure.

361
There are at least two second layer actors involved in opti-362 mistic rollups: aggregators (also called operators) and veri-363 fiers (also called watchers). First, transactions are received by 364 an aggregator either directly from a layer two network broad-365 cast or by an inter-chain smart contract. An inter-chain smart 366 contract is a contract that allows communication between the 367 layer one and layer two chains. In this case, an inter-chain 368 contract can be used to receive transactions of layer one and 369 forward them to an aggregator (see Figure 4). The aggregator 370 then selects an arbitrary number of transactions, processes 371 them, and publishes the compressed transaction data and state 372 root on the layer one chain. Verifiers continuously monitor 373 data published by the aggregator. If a verifier disagrees with 374 the published data, it initiates a dispute phase. This happens 375 when the verifier disagrees that the published transactions, 376 once executed, lead to the published state root. We will dis-377 cuss implementation specific dispute resolution protocols in 378 section IV; they are generally concluded by a generated fault 379 proof that determines the inconsistency.

380
Since the dispute resolution process is generally resource 381 intensive, attempts at fraud and disputes are disincentivized 382 VOLUME 10, 2022 with bonds. Aggregators stake a bond which will be slashed 383 if a fault proof shows that they were dishonest. Verifiers 384 stake a bond that will be slashed if a dispute phase they trig-385 gered shows that the aggregator was honest. The finality of a 386 transaction is guaranteed after a certain amount of time has 387 been spent without the system entering the dispute resolution 388 process.

389
Verifiers are incentivized to initiate dispute phases when  prover and the verifier. Indeed, a prover is able to convince a 437 verifier with a single message that a valid computation (i.e. 438 executed with coherent inputs and outputs) has been made. 439 Furthermore, this is achieved without the verifier having to 440 make all of the computations themselves. The fact that these 441 proofs are non-interactive is a key element of their useful-442 ness in blockchain technology and peer-to-peer networks. 443 Blockchain systems are far too large to require back and forth 444 communication between several actors; ZK-SNARKs have 445 the advantage of convincing peers that a computation is exact 446 with only one message. 447 However, ZK-SNARKs require a trusted setup for the ini-448 tialization of a proof system, which implies trusted actors. 449 Blockchain systems have been designed to function under a 450 majority of honest participants without having to trust any 451 single participant to be honest. Requiring a trusted setup 452 means that in order to use ZK-SNARKs, one actor needs to 453 allow some level of trust to another actor. This can be done 454 by way of an in-person ceremony. Once the system is setup, 455 an arbitrarily large amount of proofs can be generated and 456 verified. In contrast, ZK-STARKs (Zero-Knowledge Scalable 457 Transparent Arguments of Knowledge) require no trusted 458 setup, yet produce larger proofs and require more time for 459 generation and verification (see Table 2).  While implementation-specific mechanisms will be dis-468 cussed in section IV, let us present the general idea behind 469 ZK rollups. Similarly to optimistic rollups, ZK rollups work 470 with second layer nodes (i.e., aggregators) that aggregate 471 transactions received on the layer two network. Upon recep-472 tion of the transactions, the aggregator executes them. Then, 473 it publishes to the main chain the new state root, the com-474 pressed data of the transactions, and a proof of validity. This 475 proof of validity ensures the computation made to execute the 476 transactions was correct (i.e., coherent inputs and outputs). 477 This publication of data is done through function calls to a 478 layer one smart contract. Such a contract verifies that the 479 ZK proof is correct. If it is, then everything is recorded on 480 the blockchain. If it is not, the transaction batch is rejected. 481 In contrast to optimistic rollups, ZK rollups do not require 482 second layer verifiers and there is no dispute resolution. 483 This means transactions achieve finality rapidly; there is 484 no extended period of time where verifiers can trigger a 485 dispute phase.

486
An in-depth explanation of how ZK-SNARKs work is out 487 of the scope of this paper but let us overview the idea behind 488 this kind of proof. Such a proof involves two actors: the 489 prover, who generates the proof, and the verifier, who verifies 490 that the proof is correct. In this scheme, the prover is trying 491 to convince the verifier that a computation was executed 492 correctly.    After this transformation, for each gate, vectors of con-505 stants a i , b i and c i are found such that

507
These are the constraints of our system. Once we have 508 these sets of vectors, we can derive 3 sets of poly-509 nomials (one per set of constraints) such that for all Note that by construction, the polynomial computed in (5) 520 will have roots at the target points {1, . . . , m} when a valid 521 solution s is used in the calculations.

522
What we have described here is called a quadratic arith-523 metic program (QAP) [35]. We have reduced our ''compu-524 tation'' to a polynomial on which we can do some checks 525 (e.g. divide (5) by t(x) and verify that the remainder is 0) that 526 ensure a coherent solution s is known by a prover without 527 necessitating disclosure of the solution. We now understand 528 the idea with which a prover can transform a computation 529 into a mathematical object that guarantees the computation 530 was executed correctly. Using this simple construction, the 531 zero-knowledge and succinct properties of ZK-SNARKs are 532 not attained. Intricate details of the different approaches used 533 to achieve these properties in zero knowledge proofs are 534 out of the scope of this paper. Broadly, zero-knowledge is 535 achieved using strong homomorphic encoding over finite 536 fields before communication to the verifier. Succinctness is 537 achieved through performing checks on random samples of 538 the polynomial h(x)t(x) [34], [36].

539
Once these steps are done, every node on the network can 540 verify (in a computationally efficient manner) that the com-541 putation result published by the aggregator (i.e., the prover) 542 is coherent with some input.

543
ZK-STARK (Zero-Knowledge Scalable Transparent Argu-544 ments of Knowledge) technology is a newer concept that 545 provides similar functionalities as ZK-SNARKs, but with-546 out the need for an initially trusted setup between the two 547 parties. While the construction of such proofs varies greatly 548 from ZK-SNARKs, the basic idea of reducing a computa-549 tion to a polynomial remains. ZK-STARKs do not rely on 550 elliptic curve cryptography to achieve zero-knowledge as 551 ZK-SNARKs do; hash functions are used instead. Finally, the 552 proof size is generally several orders of magnitude bigger (see 553 Table 2). 554 We can summarize that the role of rollups is to provide 555 relief on the layer one network by executing transactions 556 off-chain and ensuring data availability by publishing trans-557 action data on-chain. Rollups either work optimistically with 558 watchers or using zero-knowledge proofs.  terms of processing fees [37]. Data compression is achieved 564 by only publishing to the main blockchain the transaction 565 information needed to ensure a deterministic re-execution of 566 transactions. Table 3 shows the data size of certain fields, Arbitrum (see Table 4). In fact, it only took one year after V. 589 Buterin's Ethereum paper [8] for a team of Princeton students   However, the Optimism team did not think this paradigm 626 was suited for the exponentially growing Ethereum ecosys-627 tem. They then decided to transition to make the OVM an 628 EVM equivalent environment to benefit from all the mature 629 infrastructure already available for Ethereum. Such a change 630 would imply that this second layer environment complies 631 with Ethereum's Yellow Paper [38], making every applica-632 tion and more broadly software, natively work on Optimism. 633 In order to reach this goal, the Optimism team decided to keep 634 a minimal codebase, and built their client using Geth -the 635 official Go implementation of the EVM. 1 Hence, the whole 636 protocol has been build with simplicity as a core value.

637
Users interact with a sequencer (i.e., an aggregator) on 638 layer two; it collects the transactions, executes them, and 639 creates a rollup to send the data to layer one. If a verifier 640 detects a fraudulent rollup, it submits a fault proof for a 641 single transaction in the batch. This is done by interacting 642 with the rollup smart contract. This challenge is public and 643 second layer nodes provide the appropriate data for the smart 644 contract on layer one to verify the batch of transactions. This 645 smart contract automatically finds the fraudulent transaction 646 by verifying state transitions one by one for every transaction 647 in the batch. If the fraudulent transaction exists, it will be 648 invalidated along with all the transactions following it. The 649 sequencer will also be penalized. However, if the challenge 650 fails, the verifier will get penalized.

651
This dispute resolution mechanism is simple and allows for 652 a smaller codebase but requires layer one to compute a whole 653 transaction. This could range from a simple token transfer to 654 a complex smart contract execution, hence placing the burden 655 on the Ethereum chain on every disagreement. 656 However, a lot more progress is expected for Optimism, 657 and especially on the sequencer node. In fact, the only one to 658 date is operated by Optimism itself, which is a major threat for 659 censorship resistance. 2 In order to decentralize this role, the 660 1 https://github.com/ethereum/go-ethereum 2 The sequencer technically cannot censor any user because the protocol allows them to interact directly with the smart contract on layer one, bypassing the Sequencer -but forcing the users to pay higher gas fees and waiting for at least 24 hours.    Bob has to select r s from r 1 and r 2 and claim it contains a fraudulent instruction 5: range ← r s 6: end while 7: ins ← single instruction obtained 8: return ins Arbitrum's Challenge Period is composed of two phases: a 705 dissection (finding the conflicting instruction), and the one-706 step proof (proving to layer one that the instruction is valid, 707 or failing at doing so). After entering the Challenge Period, 708 Alice and Bob will play an iterative, multi-round game to find 709 the contentious instruction (see Algorithm 1). After obtaining 710 a single instruction ins, Alice will have to send a one-step 711 proof for it to layer one.

712
The internal design of the Arbitrum Virtual Machine 713 (AVM) was designed to minimize the data required to dis-714 close when the aggregator has to submit a one-step proof. 715 Indeed, the AVM uses a approach similar to lazy lists to 716 obfuscate the rest of the data. Such a data structure can be 717 recursively defined as follows: When having to provide a one step proof, the aggregator 722 can provide the first value alongside its hash as well as the 723 hash of the rest of the list. Since the state root hash of the 724 previous transaction was built with the root hash of this list, 725 it is easy to verify that this data structure is the same as the 726 one at the end of the previous transaction. After receiving 727 values and hashes for the data and instruction of the contested 728 VOLUME 10, 2022 operation, the smart contract on layer one can easily execute 729 it and determine its validity.
If it is valid, Alice will receive half of Bob's bond; oth-731 erwise, she will forfeit half of her bond to Bob. From this algorithm, multiple properties emerge:

733
• Correctness: If Alice provided a valid rollup, she will 734 always be able to win the game. If it is incorrect however, 735 Bob will always be able to win.    Note that the last transaction of the rollup is fraudulent; the 779 5 The general K-way Dissection converging after log K (N ). 6 https://developer.offchainlabs.com/docs/rollup_basics#throughput FIGURE 6. Initial state tree. The leaves of the tree represent the address of the account (e.g., 0xCAFE) and their balance (e.g., 10).  When this rollup is published, a verifier will replay the pub-782 lished transactions on its local state and compare the resulting 783 state roots. A discrepancy will be found and the verifier will 784 trigger a fault proof. This is where the behaviors of Optimism 785 and Arbitrum fork.

786
In Optimism, the verifier triggers the fault proof by target-787 ing one invalid transaction from the rollup batch. It is worth 788 noting that in Optimism, intermediate state roots (state roots 789 obtained after the execution of a single transaction on layer 790 two) are published by aggregators and stored on layer two. 791 A verifier can identify which transaction is fraudulent by 792 replaying them one by one and comparing the intermediate 793 state roots. In our example, there are three intermediate state 794 roots: S 1 , S 2 and S 3 . S 1 is obtained after executing the first 795 transaction, and so on. The verifier triggers the fault proof 796 for the third transaction (i.e., for S 3 ). It is worth noting that in 797 S 2 , the balances for accounts 0xCAFE and 0xCAFF are 10 798 and 6 respectively; this is stored on layer two and associated 799 to the layer two ERC20 smart contract.

800
A fault proof is played out as follows: 801 1) The verifier deploys on layer one the ERC20 token smart 802 contract that was on layer two. This is done so layer one can 803 simulate the disputed transaction. 804 2) Then, the verifier asks the rollup smart contract to 805 verify that this freshly deployed smart contract has the same 806 bytecode as the one on layer two. At this stage, the rollup 807 smart contract has ensured that the layer one and two ERC20 808 93048 VOLUME 10, 2022 contracts have the same bytecode. The layer one duplicate 809 smart contract has no data from layer two yet.  (0xCAFF, 6)). This is the minimum information 814 needed for layer one to simulate the disputed transaction.   2) In order to prove that the assertion is false, the verifier 854 will provide to the layer one rollup smart contract the nec-855 essary information for the execution of the instruction. The 856 AVM is a stack-based virtual machine; therefore, only the 857 data at the top of the stack and the hash of the rest of the stack 858 needs to be sent to layer one for the proof to be complete.

859
Explicitely, the verifier will send the ADD opcode, the hash 860 of the rest of the instruction stack, the value of $0xCAFE, the 861 immediate value 2, and the hash of the rest of the data stack 862 (see Figure 9).

863
3) With this information, the rollup smart contract will 864 execute the instruction by emulating the AVM. The resulting 865 AVM state root will be computed by the rollup smart contract 866 using the freshly computed values and the provided hashes 867 (see Figure 10). 868 4) The post-execution AVM state root is computed by the 869 rollup smart contract. The new state root (i.e., "ABCF...") 870 is different than the one asserted by the aggregator (i.e., 871 "ABCE..."); therefore, the aggregator was fraudulent.

872
In both Optimism and Arbitrum, the bond the aggregator 873 had previously staked is slashed; half is burned and half is 874 claimed by the verifier that triggered the dispute. 875 Finally, Table 5 shows a comparison between Optimism 876 and Arbitrum in terms of TPS, fee reduction, fault proof 877 execution, general computability, and EVM compatibility.    Sorare, 10  StarkEx already offers cutting-edge performance. Plat-907 forms like DiversiFy allows traffic reaching 9 000 TPS for 908 trades and going up to 18 000 TPS for self-custodial token 909 transfers when data is stored off-chain for example [47]. 910 Starkware also participated in Reddit Scaling Bake-Off in 911 2020 to present their technology stack [48]. This initiative 912 launched by Reddit and the Ethereum Foundation was created 913 to see if the Ethereum Network was ready to support big 914 scale applications like Reddit (reporting 430 million monthly 915 users). Starkware submited a proposal based on their ZK 916 rollup technology and reached 3 000 TPS with only 315 gas 917 units per transaction (i.e., $0.005 for Ether price $238.36), 918 a record in the Rollups space. Finally with StarkNet, expected 919 throughput and benchmarks were not disclosed at the time of 920 writing. However, the platform is expected, in the long run, 921 to offer fees that are cheaper by a factor bigger than a hundred 922 compared to layer one. 923 Starkware innovations are far from being over as the team 924 is currently working on Volition. This is a novel project com-925 bining the security of ZK rollups with the speed of Validiums 926 to offer a flexible service. Users will choose the data avail-927 ability scheme they want to use for each of their transactions: 928 either secured on layer one (on-chain) or stored off-chain 929 and regulated through a data availability Committee. This 930 would allow users to have a fine grained control over their 931 transactions, as they will be able to use this service based on 932 their risk tolerance and desired throughput. Matter Labs wants to offer layer two scaling to general pur-935 pose computation through their product, zkSync. This proto-936 col is open source and allows users to build their applications 937 on top of it to benefit from the low transaction cost and 938 speed of ZK rollups. Even though this project is also based 939 on ZK rollups, it uses ZK-SNORKs for their validity proofs, 940 requiring a trusted setup: initial parameters to generate the 941 ZK-SNORKs have been determined during the Multi-party 942 Computation Ceremony. 14 Like StarkNet, zkSync is EVM 943 compatible and uses Zinc, a new programming language 944 that is not Turing-complete, for the development of Smart 945 Contracts.

946
Regarding performance, Matter Labs claimed a theoretical 947 throughput of 2 000 TPS 15 with the previous block gas limit 948 of 12.5M. 16 This means fee reduction ranging from 20 times 949 for ETH transfers up to 100 times for ERC20 tokens.
The Loopring Foundation also developed the first publicly 1001 available decentralized exchange platform (DEX) using ZK 1002 rollups -Loopring Exchange. This platform differs from 1003 current DEXs; it uses automated market makers like Uniswap 1004 to match buyers and sellers and implements orderbooks like 1005 most centralized exchanges (CEX).

1006
The Loopring protocol uses ring miners and liquidity 1007 providers to fill orders. Both these actors get rewarded for 1008 filling orders either in Loopring utility token (LRC) or by 1009 getting a margin on the filled order. The LRC token is also 1010 used by users who want to use Loopring to create a DEX: such 1011 users have to deposit between 250 000 and a million LRC, 1012 depending of the usage.

1013
Similarly to the other discussed solutions, Loopring 1014 reports an expected 2 025 TPS with transaction fees ranging 1015 from 450 to 800 gas units 20 3 4 of all 1028 money locked on layer two comes from optimistic rollups. 1029 However, quoting Vitalik Buterin [39], it is believed that ZK 1030 rollups will gain more in popularity in the long term com-1031 pared to optimistic rollups thanks to their privacy advantages. 1032 However, there is no EVM equivalent ZK rollup currently 1033 available to the public, making it had for developers to build 1034 application on ZK rollups.

1035
There are several possible causes for the low adoption of 1036 rollups; 1) users are still unfamiliar with this technology and 1037 their usability is not developed enough. For example, mer-1038 chants and charities generally do not accept cryptocurrency 1039 payments via rollups [39]; 2) rollups are not yet decentral-1040 ized [49] In fact, many of the protocols display it as their 1041 core value yet are the only one operating a sequencer in 1042 their platforms. To our knowledge, Polygon Hermez was 1043 the only available protocol working in a fully decentralized 1044 manner at the time of writing; 3) optimistic rollups have 1045 long withdrawal periods. Although applications like fast exits 1046 via liquidity pools already exist, the two most important 1047 optimistic rollups do not offer a fast and easy way to withdraw 1048 funds.

V. ANALYSIS
some of the current rollup implementations. Table 7 compares both the theoretical throughput and the expected fee 1053 reduction of each project, as well as the validity proof type, still important to mention that more costly payments will 1092 have to be made on all platforms to deposit and withdraw 1093 funds. Although the fees for transactions differ between ZK 1094 Rollups implementations, every implementation reports a 1095 similar theoretical throughput of around 2 000 to 3 000 TPS. 1096 Some solutions also offer an off-chain data storage and allow 1097 for even greater throughput, ranging from 16 000 to 20 000 1098 TPS, at the cost of security. As validiums are not rollups, their 1099 performance numbers were not included in Table 7 1100 We can estimate the usage with the Total Value Locked 1101 (TVL), which is currently $6.3B, for each of these layer two 1102 solutions. Arbritrum is undoubtedly the most important rollup 1103 with more than half of all TVL. 24 Although Optimism repre-1104 sents a smaller share (only 10%), Metis Andromeda and Boba 1105 Network, being forks of this protocol, collectively account 1106 for another 7%. Projects built using StarkEx also account 1107 for an important part of the TVL, with dYdX aggregating 1108 a little less than 16% by itself. Loopring represents 5% of 1109 the TVL; most of it comes from the staking of LRC tokens 1110 to operate a DEX. Finally, zkSync registers less than 2%, 1111 Polygon Hermez 0.01% and StarkNet has yet to have any 1112 TVL as it does not have a bridge on mainnet at the moment. 1113 Table 2 outlines the differences in complexity of different 1114 zero-knowledge and their cryptographic assumptions. While 1115 ZK-SNARKs offer relatively smaller proof sizes and compu-1116 tation time for both provers and verifiers, they come with the 1117 burden of requiring a trusted setup before being able to per-1118 form proofs for a specific application [34]. Therefore, every 1119 time a new application (i.e. smart contract) is deployed on 1120 the blockchain, trusted parties are required to communicate 1121 honestly and agree on some key bits of information that will 1122 be used to craft the ZK-SNARK at an ulterior moment.

1123
Acquiring a trusted setup in trustless environments like 1124 blockchain systems can be an arduous task; ZK-SNORKs and 1125 ZK-STARKs can help with this challenge. ZK-SNORKs can 1126 relieve users of this burden by reusing and modifying one ini-1127 tial trusted setup for all further smart contracts deployed [44]. 1128 ZK-STARKs no not require a trusted setup at all.

1129
As for the cryptographic requirements, ZK-SNARKs and 1130 SNORKs rely on the hardness of the elliptical curve dis-1131 crete logarithm problem (ECDLP) and on elliptic curve 1132 bilinear mappings (or pairings). Note that this means that 1133

1139
In this section, we highlight any future work that could 1140 improve the state of rollup technology.

1141
There are three key factors that need to be more thoroughly