The Truth about L2 Trust Assumptions ​ Imagine you are a DeFi user on a rollup. Your favourite app gets hacked and you are down five figures. ​ Would you want the chain to be stopped to retrieve the funds? ​ Imagine you hold six figures on a L2 with billions in TVL. ​ Would you want to have a single entity in control of this financial system? If you have never really thought about that, you are not alone. ​ After all, your favourite L2 inherits Ethereum security anyhow, right? ... Right???? ​ Wrong anon. ​ Yesterday's exploit of @RhoMarketsHQ on @Scroll_ZKP and the subsequent delay of the network's finalization, have once again sparked controversial discussions around rollup decentralization. ​ The same discussions that we already had when @LineaBuild halted its chain in a similar situation a few weeks ago. ​ That's why today, we unveil the truth about L2 trust assumptions. We talk through L2 issues with no filter and show you who & what you actually trust. This will be a long read, so get a coffee and get comfortable anon. ​ Due to recent events, we will use @Scroll_ZKP as an example. ​ Problem #1 - Multisigs in Control ​ Scroll consists of a set of smart contracts on Ethereum. ​ This includes the 𝚂𝚌𝚛𝚘𝚕𝚕𝙲𝚑𝚊𝚒𝚗 contract, which is the main contract of the rollup. It allows to post transaction data and state roots, alongside corresponding validity proofs. ​ There is also a bunch of other contracts, including proof verifiers or bridge and messaging contracts. The core contracts are upgradeable through the Scroll multisig¹, which is a @Safe with a 4/5 threshold. ​ ¹ ) 0xEfc9D1096fb65c832207E5e7F13C2D1102244dbe ​ The multisig, a.k.a. security council can upgrade proxies and the verifier without delay and propose transactions within certain timelocks. ​ It can also revert non finalized batches, remove sequencers and provers and pause contracts. ​ The multisig signers are: ​ 0xFCf6364F5157901f533DD3615A5d8c375F13c072 0xE2e6345baAD18f779167443Dc4886495507b3249 0xEbbeeAA424AE904508465a41c927Be594C43Dc68 0xfc31892C5500AbE00974280b28907BaA9190E384 0x9337B41709c1C2B938Cb460ea3fA9DB586B172E0 ​ Why does upgradeability matter? ​ Because a malicious upgrade to the rollup contracts could make you lose all your funds anon. ​ Timelocks that enforce delay periods can mitigate this problem to at least some degree. ​ If it's a 7 day delay and you're on vacation for two weeks, it won't help you much though. ​ What makes matters worse, is that many rollups don't have delay periods at all. ​ In the case of @Scroll_ZKP for example, there is no window for users to exit in case of an unwanted regular upgrade since some of the contracts are instantly upgradable (see above). ​ For certain other types of upgrades, timelocks are implemented though. ​ Nontheless, this design gives the Scroll multisig, a.k.a team a high degree of control over the network. ​ Note: The situation with other rollups looks just like this, it's not a Scroll-specific issue. ​ Problem #2 - Trust the Sequencer (and the Prover) ​ To make matters worse though, @Scroll_ZKP is running on a centralized sequencer. ​ What is the sequencer? ​ The sequencer is the only entity in the system that can propose blocks. Having a live and trustworthy sequencer is crucial to the functioning of any rollup. ​ Today, all major rollups rely on centralized sequencers though. Aside @Scroll_ZKP, this also includes OP stack chains such as @Optimism mainnet, @base or @0xMantle, as well as chains like @arbitrum or @zksync and @LineaBuild. ​ This design choice is made deliberately in a trade-off between decentralization and scalability/UX. ​ By receiving and ordering transactions that are later submitted to the L1, the sequencer provides users with what is known as a fast pre-confirmation. ​ These pre-confirmations (a.k.a. promises of a transaction later being included in a L1 block), enable the seamless UX we have grown used to on L2s. ​ However, a centralized sequencer that exploits their centralized position and frontruns user transactions, can pose a significant risk to the health of an ecosystem. ​ Aside MEV extraction risks, a centralized sequencer introduces liveness and single-point-of failure risks and raises questions with regards to censorship resistance. ​ While some rollups have mechanisms that allow users to force transaction inclusion, @Scroll_ZKP (among others) currently lacks this feature. ​ Consequently, users can be censored if the operator refuses to include their transactions, which could result in funds being frozen. ​ An often overlooked component of the system is the proving layer, that generates the cryptographic validity proofs that are posted to L1 alongside the rollup data blobs. ​ What few know, is that reliance on a centralized prover that runs a singular proof system comes with considerable risk. If the cryptography is broken or implemented incorrectly, funds can be stolen. ​ Note: Scroll is working to decentralize both the sequencer and the prover down the line. ​ Problem #3.1 - Decentralization is a Journey ​ So is Scroll "bad tech"? ​ No anon. ​ Actually the opposite. We're bullish @Scroll_ZKP. ​ However, the road to decentralization for rollups is a progressive process. ​ Rollups are complex systems with multiple components on various layers that each introduce trust assumptions that have to be optimized. ​ To understand what we mean, let's look at rollups from a more functional perspective than before. ​ Again, we take @Scroll_ZKP as an example. ​ Scroll's high level architecture consists of: ​ ✦ Sequencing layer (operator that receives and orders transactions, proposing blobs to L1) ✦ Execution layer (the Scroll rollup, defined by the contracts on L1) ✦ Proving layer (proving system that creates the execution proofs that are submitted to L1 alongside data blobs) ✦ Settlement layer (Ethereum, where the contracts sit and proofs are verified) ✦ DA layer (Ethereum, or rather EIP4844 blobs where rollup data is published to) ​ Is it realistic that a rollup launches with immutable contracts, based sequencing and a decentralized prover? ​ No. ​ We have to keep in mind that the first rollup (Arbitrum) just went live three years ago. ​ This is very nascent technology and teams working on rollups with ambitious plans to decentralize all these different layers of the stack are pioneering the frontier of innovation. ​ Due to the complexity of these systems, some degree of control that allows the teams to remain flexible and sequentially build out their vision is a mere necessity. ​ Just like an initially centralized sequencer and prover to not introduce too much complexity to the system in early stages. ​ Nevertheless, the end goal has to be to build a fully decentralized and secure network. ​ @Scroll_ZKP just launched mainnet a few months ago. Its in the early stages of a progressive process towards decentralization. More is yet to come and the same goes for most of these L2s. ​ With a maturing ecosystem of modular infra building blocks, which includes crypto-economically secured and decentralized, shared sequencing and proving layers and more, decentralizing L2s will become easier as well. ​ While many L2s are building towards decentralized sequencing & proving solutions of their own, especially the long tail of rollups will benefit significantly from this modular, plug-and-play infrastructure. ​ Out of the box decentralization, pooled crypto-economic security and specialized technology. ​ The future looks bright. ​ Problem #3.2 - But no one knows ​ The fact that decentralization is a journey is actually not a problem itself. ​ What makes it a problem, is that often the marketing of all these L2s in the market suggests that the user is interacting with "decentralized" systems. ​ Many users really believe they are "inheriting security from Ethereum". ​ They are not. At least not today. ​ As we have seen in this post, with the current "training wheels", rollups are all but decentralized today. ​ What is important to point out here again though, is that by no means we want to bash @Scroll_ZKP as a "bad example". ​ What we are talking about is simply the reality in the L2 market today. Final Thoughts As an industry, we will continue to innovate and build. ​ One day, we will have solved all these issues and rollups will be fully decentralized systems. ​ However, we should strive to be transparent about the trust assumptions that exist in the meantime. ​ Imagine you are a DeFi user on a rollup. Your favourite app gets hacked and you are down five figures. ​ Would you want the chain to be stopped to retrieve the funds? ​ Imagine you hold six figures on a L2 with billions in TVL. ​ Would you want to have a single entity in control of this 'financial system'? ​ The reality is, rollups aren't real (yet) and most people are not aware of this reality ​ That's what @RedactedRes aims to change. ​ Education > predatory marketing. ​ That's a wrap! DYOR and drop us a follow to access institutional-grade research entirely for free. 🀄️✨