diff --git a/README.md b/README.md index 000cc12..a29a792 100644 --- a/README.md +++ b/README.md @@ -96,7 +96,7 @@ This framework aims to establish a foundation for basic best practices and trans In the ideal case, both technical and non-technical users are able to use this framework to evaluate whether a rollup is operating securely, honestly, and can be trusted with funds, with various levels of detail. The framework is intended to outline what information the rollup operators should expose to the community in order to justify that their operation implements features that users may take for granted. ## How to use this Framework -The goal of this framework is to provide a risk assessment of different attack vectors and evaluate rollup properties. For any rollup, this framework evaluates its components and returns the possible consequences for different design decisions and properties. +The goal of this framework is to provide a risk assessment of different attack vectors and evaluate rollup properties. For any rollup, this framework evaluates its components and returns the possible consequences for different design decisions and properties. The evaluation consists of several questions that interested parties can ask. Each question is accompanied by context and has several potential answers. Each answer implies a consequence and, wherever possible, includes examples of rollups to which this answer applies. Examples are accurate at the time of writing but may become inaccurate as these systems are constantly changing. @@ -124,7 +124,7 @@ This document will first review known rollup attack vectors and security concern Each of these topics are defined more precisely in their respective section. Within each section, questions are proposed that users may want to ask in order to evaluate the concerns raised by a particular rollup for a particular topic. Note that some questions may also relate to concerns in another topic. Wherever possible, examples of real-world rollup code and documentation serve to illustrate a concern or a method to mitigate the concern. -At the end of each section, a description of how the answers to the questions presented may impact a rollup’s risk to particular attack vectors is presented as an outcome table. These attack vectors are defined in detail in the Attack Vector section. +At the end of each section, a description of how the answers to the questions presented may impact a rollup’s risk to particular attack vectors is presented as an outcome table. These attack vectors are defined in detail in the Attack Vector section. The outcome tables will use the following levels for each attack vector risk and scoring outcome. @@ -136,7 +136,7 @@ The outcome tables will use the following levels for each attack vector risk and | 🟨🟨 Medium | 🟑🟑 Fair | | 🟨🟧 Medium - High | 🟑🟠 Mediocre | | 🟧🟧 High | 🟠🟠 Poor | -| 🟧πŸŸ₯ Very High | πŸŸ πŸ”΄ Very Poor | +| 🟧πŸŸ₯ Very High | πŸŸ πŸ”΄ Very Poor | | | πŸ”΄πŸ”΄ *Special Rating* | Note that not every attack vector or score will be present in an outcome table, only those which may be impacted by the questions in the section used to construct the table. Furthermore, even if an attack vector risk or score is present in a table, a row for every risk or score level above may not be present. The *Special Rating* scoring outcome is reserved for scoring which may not be possible because a feature is missing; it should be considered the worst outcome for a particular score. For a given set of values, the topmost row which is satisfied by the values should be considered the final result. @@ -155,11 +155,11 @@ Both optimistic and ZK rollups are operating or in development on the Ethereum b ### Escape hatches This framework pays special attention to escape hatches. Escape hatches serve as fail-safe mechanisms, ensuring successful user interaction with the rollup and minimizing the dependence on the sequencer and state proposer. The framework expands [previous work](https://dl.acm.org/doi/abs/10.1145/3565383.3566107) by including detailed distinctions between sequencer and state proposer failures and formally models current escape hatch approaches. -This framework also considers operational risks for end-users and developers. While these features may be well thought-out and implemented, they might not be feasible. Furthermore, interaction with the rollup through escape hatches may require different levels of technical expertise or sufficient assistance through available tools. For example, a forced withdrawal (defined below) from some ZK rollups requires the user to generate proof; therefore hardware requirements and user knowledge limit such an escape hatch’s feasibility. +This framework also considers operational risks for end-users and developers. While these features may be well thought-out and implemented, they might not be feasible. Furthermore, interaction with the rollup through escape hatches may require different levels of technical expertise or sufficient assistance through available tools. For example, a forced withdrawal (defined below) from some ZK rollups requires the user to generate proof; therefore hardware requirements and user knowledge limit such an escape hatch’s feasibility. This framework differentiates between two different types of escape hatches: *force inclusion* and *force withdrawal*. -Force *inclusion* escape hatches serve to circumvent the sequencer. If the sequencer is offline or censors a transaction, the user can use such an escape hatch to include their transaction in a block. The risk of being offline and censorship decreases with the decentralization of sequencers, but it is a good practice to implement a force inclusion escape hatch to prevent collusion. To use such an escape hatch, users call a dedicated function in the rollup’s L1 smart contract, often related to an β€œOutbox” structure. Using a force inclusion escape hatch inflicts additional gas costs on the user but guarantees (eventual) inclusion in the block. This framework captures nuances in this process. To do so, *force appension* is defined as the process of including a transaction in a queue on L1. This transaction is not in the committed sequence of L2 transactions yet; however, the sequencer can typically only process this queue in order and cannot discard transactions from this queue. Subsequently, *force inclusion* is the process of a user including a transaction from the queue into the sequence of L2 transactions. Some only allow force appension, while others also allow force inclusion. For example, Optimism allows users to force include transactions immediately, while Arbitrum only allows force inclusion at least 24 hours after the force appension was performed. +Force *inclusion* escape hatches serve to circumvent the sequencer. If the sequencer is offline or censors a transaction, the user can use such an escape hatch to include their transaction in a block. The risk of being offline and censorship decreases with the decentralization of sequencers, but it is a good practice to implement a force inclusion escape hatch to prevent collusion. To use such an escape hatch, users call a dedicated function in the rollup’s L1 smart contract, often related to an β€œOutbox” structure. Using a force inclusion escape hatch inflicts additional gas costs on the user but guarantees (eventual) inclusion in the block. This framework captures nuances in this process. To do so, *force appension* is defined as the process of including a transaction in a queue on L1. This transaction is not in the committed sequence of L2 transactions yet; however, the sequencer can typically only process this queue in order and cannot discard transactions from this queue. Subsequently, *force inclusion* is the process of a user including a transaction from the queue into the sequence of L2 transactions. Some only allow force appension, while others also allow force inclusion. For example, Optimism allows users to force include transactions immediately, while Arbitrum only allows force inclusion at least 24 hours after the force appension was performed. *Force withdrawal* escape hatches guarantee the ability to exit funds from the L2 without relying on the state proposer. Such functionality is relevant in case state proposers are offline or censoring transactions in order to guarantee the successful withdrawal of assets from L2. In optimistic rollups, this also protects against malicious (colluding) state proposers refusing to include a transaction in their posted state update. However, if fraud proofs are enabled, and at least one honest party can challenge state updates, the risk of censorship is further reduced. @@ -188,7 +188,7 @@ Ideally, L2s would be censorship resistant, just like Ethereum. However, censors Misbehaving sequencers can choose to censor transactions submitted by users. If there is only one sequencer (or a small number of them), then this censorship can be very effective. A vulnerable decentralized sequencer protocol may also allow for censorship. This is partially why many rollups implement force inclusion escape hatches. However, the escape hatches themselves have [varying degrees of effectiveness](https://quantstamp.com/blog/rollup-escape-hatches) and may not completely mitigate censorship by the sequencer. -Some optimistic rollups have not yet fully implemented fraud proofs. Such rollups allow submitting undisputed fraudulent transaction batches to L1. These state proposers may exclude transactions from the state they propose back to L1 in order to censor users. Since there is no way to successfully dispute the fraudulent state, it will likely get finalized on L1. However, even if fraud proofs are implemented, there is a risk of fraudulent states going unchallenged. This can be achieved by colluding state proposers or simply a lack of incentive to challenge invalid states. To reduce the trust required in state proposers and prevent censorship, some rollups implement a force withdrawal escape hatch. +Some optimistic rollups have not yet fully implemented fraud proofs. Such rollups allow submitting undisputed fraudulent transaction batches to L1. These state proposers may exclude transactions from the state they propose back to L1 in order to censor users. Since there is no way to successfully dispute the fraudulent state, it will likely get finalized on L1. However, even if fraud proofs are implemented, there is a risk of fraudulent states going unchallenged. This can be achieved by colluding state proposers or simply a lack of incentive to challenge invalid states. To reduce the trust required in state proposers and prevent censorship, some rollups implement a force withdrawal escape hatch. ### Delay Attack A delay attack involves the delay of state confirmation on L1. This risk assessment considers intentional delays and delays incurred due to a lack of incentive. Multiple misbehaving components of rollups could cause a delay in state confirmation. The simplest version of this attack would be for a misbehaving centralized validator to simply not propose a rollup block to L1. Sequencers could also perform delay attacks by censoring or excluding transactions from the L2 blocks, forcing users to [potentially force the transaction on L1 with a delay](https://developer.arbitrum.io/sequencer#unhappyuncommon-case-sequencer-isnt-doing-its-job). @@ -230,7 +230,7 @@ Rollup nodes run their own client, which is distinct from Ethereum clients. [Bug Client diversity should extend to L2s for both sequencers and validators. Each client should also be thoroughly tested and audited to ensure that no such bugs are present. ### Compatibility Risk -Ethereum Virtual Machine (EVM) equivalence is one of the most desired properties of an Ethereum rollup. EVM equivalence allows smart contracts on L1 to be used with no additional complications on L2. At the time of writing, there are no rollups which are fully EVM equivalent. Some rollups do not support all the opcodes, and others implement opcodes differently than Ethereum. Also, several rollups do not support the precompiled contracts on Ethereum.These differences can lead to unexpected behavior when the same contracts from L1 are deployed on L2. This could lead to users’ assets becoming locked or perhaps even stolen in extreme cases. +Ethereum Virtual Machine (EVM) equivalence is one of the most desired properties of an Ethereum rollup. EVM equivalence allows smart contracts on L1 to be used with no additional complications on L2. At the time of writing, there are no rollups which are fully EVM equivalent. Some rollups do not support all the opcodes, and others implement opcodes differently than Ethereum. Also, several rollups do not support the precompiled contracts on Ethereum.These differences can lead to unexpected behavior when the same contracts from L1 are deployed on L2. This could lead to users’ assets becoming locked or perhaps even stolen in extreme cases. Compatibility risk can also extend to differences between the testnet and the mainnet of the rollup. Developers may test their applications successfully on the testnet, mistakenly assuming that they will also work perfectly on the mainnet. However, differences between the testnet and the mainnet limit the effectiveness of testing on the testnet. When it comes to rollups, there are some special differences between the testnet and the mainnet to consider. For example, optimistic rollups have a much higher dispute time on their mainnet compared to their testnet. @@ -263,7 +263,7 @@ It should be noted that this score is more relevant on a permissioned system whe ### Incentive Compatibility Incentive compatibility is an important consideration when assessing the security aspects of decentralized systems, including rollups. The reliable progression and security risks of a rollup depend to a large part on its incentive compatibility. Therefore, an *incentive compatibility score* is introduced that reflects how likely protocol participants, such as sequencers and state proposers, will participate in and follow the protocol. -The importance of a protocol-level incentive increases with the system’s decentralization. If anyone can participate, the only mechanisms to ensure correct honest participant behavior are incentives and disincentives (assuming a correct technical implementation). The protocol needs to incentivize honest behavior, like a reward for winning a fraud proof challenge, and disincentivize malicious behavior, such as spamming fraud proofs. +The importance of a protocol-level incentive increases with the system’s decentralization. If anyone can participate, the only mechanisms to ensure correct honest participant behavior are incentives and disincentives (assuming a correct technical implementation). The protocol needs to incentivize honest behavior, like a reward for winning a fraud proof challenge, and disincentivize malicious behavior, such as spamming fraud proofs. However, the degree of incentive compatibility required also depends on the possible actions an actor can take. In ZK rollups, state proposers can only delay all or no transactions, by either submitting a state update or not submitting a state update. Furthermore, one honest participant is sufficient to ensure correct state progression. As a result, a relatively small incentive should suffice to ensure eventual state progression in a permissionless system, as someone will eventually process the state update to get the reward. The higher the incentive, the more reliable is state progression. The incentive should be large enough that honest behavior is profitable; if a ZK proof costs more to generate than the incentive, then the incentive will not be effective. @@ -280,7 +280,7 @@ All questions should be asked for every rollup. The first questions asked are related to the maturity of a rollup. In order to assess the maturity of a rollup accurately, as well as to assess a number of other questions presented in this framework, insight into the development process is necessary, without the veil of any marketing claims. The following question is therefore very important. -**MTP1** Is the source code available? +**MTP1** Is the source code available? | Level | Consequences | Example | | --- | --- | --- | | 1 - Yes | The system can be thoroughly reviewed. | Optimism is fully [open-source](https://github.com/ethereum-optimism/optimism). | @@ -318,8 +318,8 @@ While source code may be open, the internal processes may not be clear. A comple **MTP4** Are tests present? Are CI/CD pipelines present? | Level | Consequences | Example | | --- | --- | --- | -| 1 - Tests are present and CI/CD pipelines are configured | Developers gain confidence in the process used to develop the code. The community gains some trust in the system because these processes reduce the likelihood of errors being introduced to updates and changes. | The Polygon zkEVM [repository](https://github.com/0xPolygonHermez/zkevm-node/pulls) has tests triggered prior to merging pull requests. | -| 2 - Tests are present but CI/CD pipelines are not configured | Developers gain some confidence in the process used to develop the code. The community gains some trust in the system because tests safeguard against single developers introducing errors. | The DeGate [repository](https://github.com/degatedev/protocols) is a fork from Loopring which includes tests, but the [only open pull request](https://github.com/degatedev/protocols/pulls) does not suggest CI/CD is configured. | +| 1 - Tests are present and CI/CD pipelines are configured | Developers gain confidence in the process used to develop the code. The community gains some trust in the system because these processes reduce the likelihood of errors being introduced to updates and changes. | The Polygon zkEVM [repository](https://github.com/0xPolygonHermez/zkevm-node/pulls) has tests triggered prior to merging pull requests. | +| 2 - Tests are present but CI/CD pipelines are not configured | Developers gain some confidence in the process used to develop the code. The community gains some trust in the system because tests safeguard against single developers introducing errors. | The DeGate [repository](https://github.com/degatedev/protocols) is a fork from Loopring which includes tests, but the [only open pull request](https://github.com/degatedev/protocols/pulls) does not suggest CI/CD is configured. | | 3 -Tests are not present and CI/CD pipelines are not configured | The rollup is being tested in production. The code may function, but corner cases may bring the system to a halt or cause loss of funds. This basic requirement of software engineering is not met and the rollup should be considered risky. | The Base [repository](https://github.com/base-org/node) is essentially a configuration file with dependencies; it does not test that these configurations are not breaking; there is no evidence of CI/CD pipelines. | **MTP5** Are processes for code changes well documented? Is there evidence that pull requests are reviewed prior to merging? @@ -333,7 +333,7 @@ While source code may be open, the internal processes may not be clear. A comple | Level | Consequences | Example | | --- | --- | --- | | 1 - Yes | Documents, code, and tests are easy to review. Developers can focus on the functionality of the code in a consistent and easy to understand manner. | Optimism has contribution [guidelines](https://github.com/ethereum-optimism/optimism/blob/develop/CONTRIBUTING.md). | -| 2 - No | Documents, code, and tests are not easy to review. The average developer may find themselves lost in minor stylistic issues, rather than focusing on key functionality. | The β€œContributing” header on the Boba repository [README](https://github.com/bobanetwork/boba) is empty, and there is no evidence that internal contributors follow a guide. | +| 2 - No | Documents, code, and tests are not easy to review. The average developer may find themselves lost in minor stylistic issues, rather than focusing on key functionality. | The β€œContributing” header on the Boba repository [README](https://github.com/bobanetwork/boba) is empty, and there is no evidence that internal contributors follow a guide. | There are special procedural and transparency concerns for the smart contracts implementing a rollup. Audits are an important part of the smart contract deployment process (**MTP7**), and the rollup contracts should be verified on a public block explorer like [Etherscan](https://etherscan.io/) (**MTP8**). @@ -347,7 +347,7 @@ There are special procedural and transparency concerns for the smart contracts i | Level | Consequences | Example | | --- | --- | --- | | 1 - Yes | The community can review the rollup contracts themselves, determining if they match an audit and fully understand the risks with enough effort. | Optimism’s code is available on Etherscan ([example contract](https://etherscan.io/address/0x99c9fc46f92e8a1c0dec1b1747d010903e884be1)). | -| 2 - No | The functionality of the rollup is not known and the rollup should be considered risky. | No example at this time. | +| 2 - No | The functionality of the rollup is not known and the rollup should be considered risky. | No example at this time. | Turning to the security posture, it is important that secrets are not present in a public repository (**MTP9**) and there is evidence that relevant cryptographic protocols were run honestly (**MTP10**). @@ -355,7 +355,7 @@ Turning to the security posture, it is important that secrets are not present in | Level | Consequences | Example | | --- | --- | --- | | 1 - No | Privileged accounts and systems are only accessible by the intended parties, provided that secrets are handled correctly by the relevant parties. | [Boba](https://github.com/bobanetwork/boba/pulls) includes a check for secret publishing in their pull request pipeline. | -| 2 - Yes | Privileged accounts or systems may be accessible by malicious actors; the system should change the secrets as soon as possible. This may require redeploying or instantiating parts of the rollup. | No example at this time. | +| 2 - Yes | Privileged accounts or systems may be accessible by malicious actors; the system should change the secrets as soon as possible. This may require redeploying or instantiating parts of the rollup. | No example at this time. | **MTP10** Are trusted setups public and open? | Level | Consequences | Example | @@ -384,7 +384,7 @@ Finally, as rollups may not be fully decentralized, it is important to understan | Level | Consequences | Example | | --- | --- | --- | | 1 - Yes | End users can get a feel for whether or not the use of this rollup may have legal implications | Base lists its [terms and conditions](https://base.org/terms-of-service). | -| 2 - No | End users may not be aware of the legal implications of using this rollup. | Boba does not list any specific terms and conditions. | +| 2 - No | End users may not be aware of the legal implications of using this rollup. | Boba does not list any specific terms and conditions. | ### Outcomes The primary considerations for questions regarding maturity, transparency, and security posture are operational risks, dependency on third parties, and access to secrets. @@ -467,7 +467,7 @@ Questions in this section are all relevant if the rollup claims to be EVM compat ![Interoperability and Compatibility Concerns](/images/ec.svg) -The first question considers the rollup’s supported opcodes. An exact equivalence with the Ethereum EVM’s supported set of opcodes (and their execution) makes the integration of already existing smart contracts on Ethereum seamless and avoids unexpected behaviors and security vulnerabilities. On the other hand, if some opcodes work differently, then there is a chance that contracts ported from L1 will not have the same behavior in L2. This could lead to serious security vulnerabilities. +The first question considers the rollup’s supported opcodes. An exact equivalence with the Ethereum EVM’s supported set of opcodes (and their execution) makes the integration of already existing smart contracts on Ethereum seamless and avoids unexpected behaviors and security vulnerabilities. On the other hand, if some opcodes work differently, then there is a chance that contracts ported from L1 will not have the same behavior in L2. This could lead to serious security vulnerabilities. **EC1** Does the rollup treat opcodes in the same way as Ethereum? | Level | Consequences | Example | @@ -492,7 +492,7 @@ Precompiled contracts are special contracts that allow a user to call some logic Note that a rollup which has an answer of β€œ4 - No precompiled contracts from Ethereum are supported without changes” may be intentional, as in the case of the answer to **EC2**. -A rollup that doesn’t support the native L1 asset (Ether on Ethereum) needs further code and tools to be used for the interaction with the chain that may introduce security vulnerabilities. Moreover, tools and code developed to interact with Ethereum may introduce unexpected behaviors and further security concerns. +A rollup that doesn’t support the native L1 asset (Ether on Ethereum) needs further code and tools to be used for the interaction with the chain that may introduce security vulnerabilities. Moreover, tools and code developed to interact with Ethereum may introduce unexpected behaviors and further security concerns. **EC3** Is ETH (or other native L1 asset) supported? | Level | Consequences | Example | @@ -585,7 +585,7 @@ Canonical bridges consist of at least two smart contracts, one on L1 and one on | 3 - Upgrades are not timelocked but are secured by a multi-sig | If no time lock is used, then users will not have an opportunity to detect and react to the incoming malicious upgrade. | The zkSync bridge upgrader is a Gnosis safe as seen in [this upgrade transaction](https://explorer.phalcon.xyz/tx/eth/0xa462b66e80e973da1eaea5a5bde5a1b4ff6a1a3b29ac4db25922712e71900e80). However, there appears to be no time lock control for the upgrade. The upgrades can happen immediately after sufficient signatures have been received.

Arbitrum also uses a multi-sig for the upgrade transaction, but there appears to be no timelock.

Optimism also uses a multi-sig for the bridge/gateway upgrade. The owner was set in [this transaction](https://explorer.phalcon.xyz/tx/eth/0x3c053ab4e3039f84451c30117e32592e2e6ad430f6c02486cba7762a8bb8b59f) to a [multi-sig](https://etherscan.io/address/0x9ba6e03d8b90de867373db8cf1a58d2f7f006b3a).

Metis has the same setup as Optimism. The multi-sig can be found [here](https://etherscan.io/address/0x48fe1f85ff8ad9d088863a42af54d06a1328cf21#readProxyContract). | | 4 - Upgrades are controlled by an EOA | The risk of a malicious bridge upgrade is medium to high as an EOA can be easily compromised compared to a multi-sig wallet. | The Starknet WBTC bridge [upgrades](https://explorer.phalcon.xyz/tx/eth/0xb638d945b6a6feba94d6219f1618a6e279720e105d4476db19063abd4164117f) are currently controlled by an [EOA](https://etherscan.io/address/0xdc29f0f7742ec462af475aceececc57601991d23).

The Boba Gateway upgrades are also currently controlled by an EOA. | -Testnets are critical for any chain, whether L1 or L2. Ideally, the canonical bridge for a rollup behaves the same whether it bridges to a testnet or the mainnet implementation of the rollup. +Testnets are critical for any chain, whether L1 or L2. Ideally, the canonical bridge for a rollup behaves the same whether it bridges to a testnet or the mainnet implementation of the rollup. **CB6** Does the canonical bridge behave differently on a testnet? | Level | Consequences | Example | @@ -602,9 +602,9 @@ Canonical bridges may be related to concerns about compatibility, third-parties, | | 🟩🟨 Low - Medium | **CB4**: Level 2 | It may not be possible to reverse an L1 to L2 transaction that cannot be completed on L2. This may result in lost funds in the case of bridging transactions. | | | 🟨🟨 Medium | **CB4**: Level 3 | There is no way for a user to cancel or reverse an L1 to L2 transaction that cannot be completed on L2. This may result in lost funds in the case of bridging transactions. | | **Compatibility Risk**

If WETH or the wrapped native coin of the L1 is bridged incorrectly, it may result in the inability to unwrap the native asset on the L2 chain. This may violate assumptions made by developers of applications on the rollup.
Additional compatibility risk may come from the differences between the rollup testnet and mainnet. This is because assumptions made about contracts tested on the testnet may not hold for the mainnet. | 🟦🟩 None | **CB1**: Level 1 and
**CB6**: Level 1 | WETH is handled in an appropriate manner and the testnet resembles mainnet for bridging purposes. | -| | 🟩🟩 Low | **CB1**: Level 2 and
**CB6**: Level 1 | Wrapped Ether is not unwrapped before bridging to L2. This leaves a risk that WETH may not be unwrapped on L2 due to a lack of ETH balance on the WETH contract. | -| | 🟩🟩 Low | **CB1**: Level 1 and
 **CB6**: Level 2 | There are some differences between the testnet and mainnet which impact the testing of smart contracts. This leaves the possibility that testing on the testnet may not reveal issues that will only show on the mainnet. | -| | 🟩🟨 Low - Medium | **CB1**: Level 2 and
**CB6**: Level 2 | Wrapped Ether is not unwrapped before bridging to L2. This leaves a risk that WETH may not be unwrapped on L2 due to a lack of ETH balance on the WETH contract.
There are some differences between the testnet and mainnet which impact the testing of smart contracts. This leaves the possibility that testing on the testnet may not reveal issues that will only show on the mainnet. | +| | 🟩🟩 Low | **CB1**: Level 2 and
**CB6**: Level 1 | Wrapped Ether is not unwrapped before bridging to L2. This leaves a risk that WETH may not be unwrapped on L2 due to a lack of ETH balance on the WETH contract. | +| | 🟩🟩 Low | **CB1**: Level 1 and
 **CB6**: Level 2 | There are some differences between the testnet and mainnet which impact the testing of smart contracts. This leaves the possibility that testing on the testnet may not reveal issues that will only show on the mainnet. | +| | 🟩🟨 Low - Medium | **CB1**: Level 2 and
**CB6**: Level 2 | Wrapped Ether is not unwrapped before bridging to L2. This leaves a risk that WETH may not be unwrapped on L2 due to a lack of ETH balance on the WETH contract.
There are some differences between the testnet and mainnet which impact the testing of smart contracts. This leaves the possibility that testing on the testnet may not reveal issues that will only show on the mainnet. | | | 🟨🟨 Medium | **CB1**: Level 2 and
**CB6**: Level 3 | Significant differences between the testnet and mainnet limit the effectiveness of smart contract testing on the testnet. Issues are more likely to arise on mainnet due to the difference. | | **Third-Party Risk**

Bridges are some of the most vulnerable systems in Web3 and among the most attractive targets for hackers. If the canonical bridge is not extensible enough, developers must use third-party solutions or develop their own solutions. This leads to an increased risk of vulnerabilities. | 🟩🟩 Low | **CB2**: Level 1 and
**CB3**: Level 1 | Different, custom tokens are supported. Care must still be taken to ensure that they are handled correctly. | | | 🟩🟨 Low - Medium | (**CB2**: Level 2 and
**CB3**: at most Level 3) or
**CB3**: Level 2 | The canonical bridge is extensible enough to allow the developers some way to extend it. However, the effort and complexity involved may result in higher risk when implementing these extensible components. | @@ -615,7 +615,7 @@ Canonical bridges may be related to concerns about compatibility, third-parties, | | 🟧🟧 High | **CB5**: Level 4 | A single EOA is capable of upgrading the bridge contracts. If the EOA is compromised or abused, all funds held by the bridge could be stolen. | ## State Proposer Concerns -In this section the concerns related to rollup state proposers are discussed. These components of the network ensure that state updates are constantly committed on the L1 chain and that their validity is guaranteed by an on-chain verification. All of this is crucial for the correct progression of L1-recorded L2 state and withdrawal operations that allow users to bridge back assets from the L2 to the L1. The following questions aim at defining the trustworthiness of the system of state proposers and ultimately define the security of a crucial component of the rollups. Then, the outcome tables for ZK rollups are constructed. For optimistic rollups, the questions following in the Validator section are also relevant. Finally, the section concludes with the outcome tables for optimistic rollups based on the answer path taken in this section. +In this section the concerns related to rollup state proposers are discussed. These components of the network ensure that state updates are constantly committed on the L1 chain and that their validity is guaranteed by an on-chain verification. All of this is crucial for the correct progression of L1-recorded L2 state and withdrawal operations that allow users to bridge back assets from the L2 to the L1. The following questions aim at defining the trustworthiness of the system of state proposers and ultimately define the security of a crucial component of the rollups. Then, the outcome tables for ZK rollups are constructed. For optimistic rollups, the questions following in the Validator section are also relevant. Finally, the section concludes with the outcome tables for optimistic rollups based on the answer path taken in this section. ### State Proposer Questions The following flow chart helps to identify which questions need to be asked dependent on the state proposer design. After all questions have been asked, the outcome tables for ZK rollups can be configured. For optimistic rollups, the additional Validator questions have to be answered as well. @@ -654,7 +654,7 @@ If the question above is answered with level 1, the following question **SP3** s While force withdrawal escape hatches help users with offline and malicious state proposers, users are still required to interact with the respective smart contracts. This would result in all users having to interact with the smart contract in case state validators are offline for an extended period of time. -However, idle proposer escape hatches remove the need for all users to rescue their assets. Instead, after a certain period of time without state progress, anyone can become a state proposer and update the state. Idle proposer escape hatches can exist in addition to or without other force withdrawal escape hatches. +However, idle proposer escape hatches remove the need for all users to rescue their assets. Instead, after a certain period of time without state progress, anyone can become a state proposer and update the state. Idle proposer escape hatches can exist in addition to or without other force withdrawal escape hatches. **SP4** What happens if the state proposer(s) is/are offline for an extended period of time? | Level | Consequences | Example | @@ -703,11 +703,11 @@ The centralized state proposer can either delay and potentially censor all or no | Attack Type | Risk | Levels | Specific Comment | | --- | --- | --- | --- | | **Censorship Attack** | 🟩🟩 Low | **SP2**: Level 1 or
**SP4**: Level 1 | The centralized state proposer can censor all transactions by not submitting validity proofs anymore. However, users can either use the implemented Force Withdrawal escape hatch or anyone can validate states after some time. Withdrawals cannot be ultimately censored. | -| | 🟧🟧 High | **SP2**: Level 2
**SP4**: Level 2 | The centralized state proposer can only decide to censor all transactions by not submitting any validity proofs anymore. However, if the state proposer does not submit any states anymore, funds of all users will be stuck on L2. | -| **Delay Attack** | 🟨🟨 Medium | **SP2**: Level 1 and
**SP4**: Level 1 | The centralized state validator can only delay all transactions until anyone can become a state proposer. Alternatively, you can pay additional L1 gas fees to force withdraw and circumvent the state proposer. | +| | 🟧🟧 High | **SP2**: Level 2
**SP4**: Level 2 | The centralized state proposer can only decide to censor all transactions by not submitting any validity proofs anymore. However, if the state proposer does not submit any states anymore, funds of all users will be stuck on L2. | +| **Delay Attack** | 🟨🟨 Medium | **SP2**: Level 1 and
**SP4**: Level 1 | The centralized state validator can only delay all transactions until anyone can become a state proposer. Alternatively, you can pay additional L1 gas fees to force withdraw and circumvent the state proposer. | | | | **SP2**: Level 1 and
**SP4**: Level 2 | The centralized state validator can indefinitely delay all transactions. However, you can pay additional L1 gas fees to force withdraw and circumvent the state proposer. -| | 🟨🟧 Medium - High | **SP2**: Level 2 and
**SP4**: Level 1 | The centralized state validator can delay all transactions until anyone can become a validator. As there is no force withdrawal escape hatch, an offline state validator causes a delay. | -| | 🟧🟧 High | **SP2**: Level 2 and **SP4**: Level 2 | The centralized state validator can indefinitely delay all transactions. It is not possible to circumvent the state proposer. This can occur if the state proposer goes offline due to malfunction or turns malicious. | +| | 🟨🟧 Medium - High | **SP2**: Level 2 and
**SP4**: Level 1 | The centralized state validator can delay all transactions until anyone can become a validator. As there is no force withdrawal escape hatch, an offline state validator causes a delay. | +| | 🟧🟧 High | **SP2**: Level 2 and **SP4**: Level 2 | The centralized state validator can indefinitely delay all transactions. It is not possible to circumvent the state proposer. This can occur if the state proposer goes offline due to malfunction or turns malicious. | | **Centralization**
*State proposer* | 🟠🟠 Poor | **SP1**: Level 3 | There is a single entity controlling state proposers. | | | πŸ”΄πŸ”΄ Does not apply | **SP1**: at most Level 2 | _Not possible - this table is for a single entity state proposer._ | | **Escape Hatch Feasibility**
*Force withdrawal feasibility* | 🟒🟒 Very Good | **SP2**: Level 1 and
**SP3**: Level 1 | It is easy to use the force withdrawal escape hatch for any user. This reduces the delay, should the state proposer not submit states anymore. | @@ -728,12 +728,12 @@ While an increased number of state proposers seems more secure, caution is advis | | 🟩🟨 Low - Medium | **SP2**: Level 1 and
Β **SP4**: Level 2 and
**SP6**: Level 1 | The state proposers are incentivized to submit states with sufficient frequency.

If all state proposers happen to be offline, users can use the force withdrawal escape hatch. Nevertheless, there is no mechanism to allow other state proposers in case the current set remains offline. | | | 🟨🟨 Medium | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 1 | The state proposers have a strong incentive to progress L2 state on L1.

There is no force withdrawal escape hatch for users to force state updates.

As a result, if state proposers decide to not progress state anymore or are offline despite the strong incentive system, users cannot circumvent this. | | | 🟨🟨 Medium | **SP2**: Level 1 and
**SP4**: Level 2 and
**SP6**: Level 2 | The state proposers have some incentive to progress L2 state on L1. The incentive system could be stronger.

There is a force withdraw escape hatch for users to force state updates (on their transaction) by paying L1 gas. | -| | 🟨🟨 Medium | **SP2**: Level 2 and
**SP4**: Level 1 and
**SP6**: at most Level 3 |The state proposers may or may not have some incentive to progress L2 state on L1.

There is no escape hatch for users to force state updates. However, after a time, anyone can be a state proposer, though this may not be sufficiently incentivized. | +| | 🟨🟨 Medium | **SP2**: Level 2 and
**SP4**: Level 1 and
**SP6**: at most Level 3 |The state proposers may or may not have some incentive to progress L2 state on L1.

There is no escape hatch for users to force state updates. However, after a time, anyone can be a state proposer, though this may not be sufficiently incentivized. | | | 🟨🟧 Medium - High | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 2 | The state proposers have some incentive to progress L2 state on L1. The incentive system could be stronger.

There is no escape hatch for users to force state updates.

If there is a stronger incentive for all state proposers to delay (a set of) transactions, they can halt state progression. Users will not be able to circumvent this. | | | 🟨🟧 Medium - High | **SP2**: Level 1 and
**SP4**: Level 2 and SP6: Level 3 | The state proposers have no incentive to submit state updates. There are no consequences for all state proposers to (collude to) being offline.

There is a force withdraw escape hatch for users to force state updates (on their transaction) by paying L1 gas.

If there is an incentive for all state proposers to delay (a set of) transactions, there is nothing preventing them to do so. | | | 🟧🟧 High | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 3 | The state proposers have no incentive to submit state updates. There are no consequences for all state proposers to (collude to) being offline.

There is no escape hatch for users to force state updates and there is no mechanism to allow new state proposers after them being offline for some time.

If there is an incentive for all state proposers to delay (a set of) transactions, there is nothing preventing them to do so. | | **Censorship Attack**

In ZK rollups, state proposers can only censor all transactions committed by the sequencer, or none. Therefore, censorship implies that no state update is posted ever again. As long as one honest state proposer is (eventually) online, state will progress and censorship is not possible. | 🟩🟩 Low | (**SP2**: Level 1 or
**SP4**: Level 1)
and
**SP6**: at most Level 3 | The state proposers can censor all transactions by not submitting validity proofs anymore. However, users can either use the implemented Force Withdrawal escape hatch or anyone can validate states after some time. Withdrawals cannot be ultimately censored. | -| | 🟩🟨 Low - Medium | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: at most Level 2 | The state proposers can only decide to censor all transactions by collaboratively not submitting any validity proofs anymore.
However, if there is an incentive for state proposers to submit state. This makes it highly unlikely that there will not be a state proposer that eventually collects that incentive by posting a validity proof. | +| | 🟩🟨 Low - Medium | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: at most Level 2 | The state proposers can only decide to censor all transactions by collaboratively not submitting any validity proofs anymore.
However, if there is an incentive for state proposers to submit state. This makes it highly unlikely that there will not be a state proposer that eventually collects that incentive by posting a validity proof. | | | 🟨🟨 Medium | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 3 | The state proposers can only decide to censor all transactions by collaboratively not submitting any validity proofs anymore.
There is no proper incentive system and no force withdrawal escape hatch. Therefore, if the incentive to censor all transactions is high enough for all state proposers, there wouldn't be a way to circumvent them. | | **Centralization**
*State proposer* | 🟒🟑 Good | **SP1**: Level 2 and
**SP5**: Level 1 and
**SP7**: Level 1 | The whitelisted set of state proposers is improved over a single state proposer. A transparent selection process and well-known node operators reduce the risk of state proposer collusion. However, if the incentive is large enough, state proposers may still have an advantage through collusion. | | | 🟑🟑 Fair | **SP1**: Level 2 and
(exactly one of **SP7**: Level 2 or
**SP5**: Level 2) | The whitelisted set of state proposers is improved over a single state proposer. The state of decentralization is improved by employing a transparent state proposer selection process or having some well-known node operators defending a reputation. As long as one of these state proposers behaves honestly, the rollup state will progress. However, there is still a risk of collusion. | @@ -756,10 +756,10 @@ In the worst-case scenario for a permissionless system, all active state propose | **Censorship Attack**

It takes only one honest state proposer in ZK rollups to reliably advance the state. Assuming that there is or eventually will be at least one honest state proposer, it is impossible to achieve censorship. | 🟦🟩 None | **SP6**: Level 1 | Even if the incentive system is not aligned, there just needs to be one entity with an incentive to advance the rollup state. | | **Delay Attack** | 🟦🟩 None | **SP6**: Level 1 | It takes only one honest state proposer in ZK rollups to reliably advance the state. When there is an incentive to submit a state, it would be hard for an attacker to create a stronger incentive for the entire network to delay transactions. Therefore, even a minor delay is unlikely. | | | 🟨🟨 Medium | **SP6**: at most Level 3 | While one honest state proposer is sufficient to advance the state, the entire network needs to be incentivized to reliably submit states. As no incentive system is built in, there might be a delay until a state proposer picks up the next batch without monetary incentive. | -| **Centralization**
*State proposer* | πŸ”΅πŸŸ’ Excellent | **SP5**: Level 1 | With permissionless onboarding of state proposers and a sufficiently decentralized network, the centralization of state proposers is minimized. | +| **Centralization**
*State proposer* | πŸ”΅πŸŸ’ Excellent | **SP5**: Level 1 | With permissionless onboarding of state proposers and a sufficiently decentralized network, the centralization of state proposers is minimized. | | | 🟒🟒 Very Good | **SP5**: Level 2 | The onboarding of state proposers is permissionless, meaning anyone can run such an entity. While the current state proposers are not sufficiently decentralized, anyone can run such an entity to ensure state progression. | -| **Escape Hatch Feasibility**
*Force withdrawal feasibility* | πŸ”΅πŸŸ’ Excellent | **SP6**: Level 1 | An escape hatch is not needed in a permissionless setting.

Anyone can run a state proposer. While this may be infeasible for some users, it gives a sufficient guarantee that the state will eventually progress. | -| | 🟑🟑 Fair | **SP6**: at most Level 3 | An escape hatch is not needed in a permissionless setting.

Anyone can run a state proposer, so anyone can progress their own state without explicit additional incentive in principle. While this may be infeasible for some users, it gives a sufficient guarantee that the state will eventually progress. | +| **Escape Hatch Feasibility**
*Force withdrawal feasibility* | πŸ”΅πŸŸ’ Excellent | **SP6**: Level 1 | An escape hatch is not needed in a permissionless setting.

Anyone can run a state proposer. While this may be infeasible for some users, it gives a sufficient guarantee that the state will eventually progress. | +| | 🟑🟑 Fair | **SP6**: at most Level 3 | An escape hatch is not needed in a permissionless setting.

Anyone can run a state proposer, so anyone can progress their own state without explicit additional incentive in principle. While this may be infeasible for some users, it gives a sufficient guarantee that the state will eventually progress. | | **Incentive Compatibility** | πŸ”΅πŸŸ’ Excellent | **SP6**: Level 1 | There is an incentive for state proposers to submit states. In ZK rollups, only one honest state proposer is needed to prevent censorship. For all validators to have an incentive means that someone will eventually include your transaction as they are rewarded. However, short-term incentive settings may still deviate in favor of delaying all transactions. | | | 🟒🟒 Very Good | **SP6**: Level 2 | There is some incentive for state proposers to submit states. This gives a good enough guarantee that the state will eventually progress. Most of the time this incentive will be strong enough for the rollup to reliably progress. | | | 🟑🟑 Fair | **SP6**: Level 3 | There is no incentive for the state proposer to submit states. While reputation is also an incentive, this will not suffice for every state proposer to reliably submit states. This may incur a delay. Furthermore, this incentive system may not suffice to withstand monetary incentives NOT to submit states. | @@ -868,14 +868,14 @@ A strong incentive system is required (but not sufficient) to minimize delay att | | 🟨🟨 Medium | **SP2**: Level 2 and
**SP4**: Level 1 and
**SP6**: at most Level 3 | The state proposers may or may not have some incentive to progress L2 state on L1.

There is no escape hatch for users to force state updates. However, after a time, anyone can be a state proposer, though this may | | | 🟨🟧 Medium - High | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 2 | The state proposers have some incentive to progress L2 state on L1. The incentive system could be stronger.

There is no escape hatch for users to force state updates.

If there is a stronger incentive for all state proposers to delay (a set of) transactions, they can halt state progression. Users will not be able to circumvent this. | | | 🟨🟧 Medium - High | **SP2**: Level 1 and
**SP2**: Level 2 and

**SP6**: Level 3 | The state proposers have no incentive to submit state updates. There are no consequences for all state proposers to (collude to) being offline.

There is a force withdraw escape hatch for users to force state updates (on their transaction) by paying L1 gas.

If there is an incentive for all state proposers to delay (a set of) transactions, there is nothing preventing them to do so. | -| | 🟧🟧 High | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 3 and
**V4**: Level 1 | The state proposers have no incentive to submit state updates. There are no consequences for all state proposers to (collude to) being offline.

There is no escape hatch for users to force state updates and there is no mechanism to allow new state proposers after them being offline for some time.

If there is an incentive for all state proposers to delay (a set of) transactions, there is nothing preventing them to do so.

State branching mitigates impact. | +| | 🟧🟧 High | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 3 and
**V4**: Level 1 | The state proposers have no incentive to submit state updates. There are no consequences for all state proposers to (collude to) being offline.

There is no escape hatch for users to force state updates and there is no mechanism to allow new state proposers after them being offline for some time.

If there is an incentive for all state proposers to delay (a set of) transactions, there is nothing preventing them to do so.

State branching mitigates impact. | | | 🟧πŸŸ₯ Very High | **SP2**: Level 2 and
**SP4**: Level 2 and
**SP6**: Level 3 and
**V4**: Level 2 | The state proposers have no incentive to submit state updates. There are no consequences for all state proposers to (collude to) being offline.

There is no escape hatch for users to force state updates and there is no mechanism to allow new state proposers after them being offline for some time.

If there is an incentive for all state proposers to delay (a set of) transactions, there is nothing preventing them to do so.

Rollbacks may be very damaging. | | **Delay Attack**
*Fraud-based delay*

Delay attacks through dispute resolution delays or invalid state submission may generally result in longer delays. However, for permissioned validators, the delay that can incur because of extended dispute resolution, is limited. This is because there is a limited number of nodes that can engage with the fraud proof protocol.

As long as there is one honest state proposer, invalid states will be immediately challenged and resolved fairly quickly. However, if there is currently no state proposer honest and online, invalid states may go unchallenged for an extended period of time.

There will always be a risk of collusion that could lead to a coordinated delay attack. Please review the centralization score to assess this risk. | 🟩🟩 Low | **V2**: Level 1 and
**V3**: Level 1 and
**V5**: Level 1 | All challenges can be processed at the same time. Therefore, no delay can occur because of a sequence of challenges.
Furthermore, submitting invalid states is disincentivized and submitting fraud proofs is incentivized.

The whitelisted set of state proposers would have to collude in order to effectively delay transactions | | | 🟩🟩 Low | **V2**: Level 1 and
**V3**: Level 1 and
(**V5**: Level 2 or Level 3) | There is a good incentive system for validators to submit fraud proofs and there is a disincentive to submit invalid states.

Due to the limited number of state proposers, the delay that can occur because of extended dispute resolution is limited. Due to the incentive system, invalid states should be resolved quickly. | | | 🟨🟨 Medium | (Exactly one of
**V2**: Level 1 or
**V3**: Level 1) and
**V5**: at most Level 3 | There is no incentive to submit fraud proofs OR challenge a state update. As a result, the incentive system is not strong enough to either disincentivize submitting invalid states or to incentivize challenging invalid states. | | | 🟨🟧 Medium - High | **V1**: at most Level 2 and
**V2**: Level 2 and
**V3**: at most Level 2 | There is no incentive to submit fraud proofs and challenge a state update. Furthermore, there is no disincentive to submit invalid states.

As a result, there is no consequence for state proposers to submit an invalid state and no negative impact if it remains unchallenged.

If challenges are submitted, they are not processed sequentially. | -| | 🟧🟧 High | **V1**: at most Level 2 and
**V2**: Level 2 and
**V3**: Level 3 | There is no incentive to submit fraud proofs and challenge a state update. Furthermore, there is no disincentive to submit invalid states.

There is no consequence for state proposers to submit an invalid state and no negative impact if it remains unchallenged. | -| **Centralization**
*State proposer* | 🟒🟑 Good | **SP5**: Level 1 and
**SP7**: Level 1 | The whitelisted set of state proposers is improved over a single state proposer. A transparent selection process and well-known node operators reduce the risk of state proposer collusion. However, if the incentive is large enough, state proposers may still have an advantage through collusion. | +| | 🟧🟧 High | **V1**: at most Level 2 and
**V2**: Level 2 and
**V3**: Level 3 | There is no incentive to submit fraud proofs and challenge a state update. Furthermore, there is no disincentive to submit invalid states.

There is no consequence for state proposers to submit an invalid state and no negative impact if it remains unchallenged. | +| **Centralization**
*State proposer* | 🟒🟑 Good | **SP5**: Level 1 and
**SP7**: Level 1 | The whitelisted set of state proposers is improved over a single state proposer. A transparent selection process and well-known node operators reduce the risk of state proposer collusion. However, if the incentive is large enough, state proposers may still have an advantage through collusion. | | | 🟑🟑 Fair | Exactly one of
**SP7**: Level 2 or
**SP5**: Level 2 | The whitelisted set of state proposers is improved over a single state proposer. The state of decentralization is improved by employing a transparent state proposer selection process or having some well-known node operators defending a reputation. As long as one of these state proposers behaves honestly, the rollup state will progress. However, there is still a risk of collusion. | | | 🟠🟠 Poor | **SP5**: Level 2 and
**SP7**: Level 2 | While there is a whitelisted set of state proposers, there is no transparent selection process and their identities are unknown. As a result of a high risk of collusion, the centralization score cannot be assumed to be improved over a single state proposer. | | **Escape Hatch Feasibility**
*Force withdrawal feasibility* | 🟒🟒 Very Good | **SP1**: Level 2 and
**SP3**: Level 1 | It is easy to use the force withdrawal escape hatch for any user. This reduces the delay, should the state proposer not submit states anymore. | @@ -887,7 +887,7 @@ A strong incentive system is required (but not sufficient) to minimize delay att | | 🟑🟑 Fair | **SP6**: at most Level 2 and
(exactly one of **V2**: Level 1 or **V6**: Level 1) | There is a good enough incentive system implemented in this optimistic rollup. State progression is incentivized while incorrect state progression is somewhat disincentivized. | | | 🟑🟠 Mediocre | **SP6**: Level 3 and
(**V2**: Level 1 or **V6**: Level 1) | There is no incentive for the state proposers to submit states. While reputation is also an incentive, this may not suffice to withstand monetary incentives NOT to submit states.

However, with an incentive to submit fraud proofs or disincentive to submit incorrect states, at least incorrect state progression is disincentivized. | | | 🟠🟠 Poor | **SP6**: at most Level 2 and
**V2**: Level 2 and
**V6**: Level 2 | Some incentives to submit (only correct) states exist, but there is no incentive to submit fraud proofs or the challenge period may be too small. | -| | πŸŸ πŸ”΄ Very Poor | **SP6**: Level 3 and
**V2**: Level 2 and
**V6**: Level 2 | This optimistic rollup implements weak incentive compatibility. There is no incentive to submit states and no disincentive to progress state incorrectly. | +| | πŸŸ πŸ”΄ Very Poor | **SP6**: Level 3 and
**V2**: Level 2 and
**V6**: Level 2 | This optimistic rollup implements weak incentive compatibility. There is no incentive to submit states and no disincentive to progress state incorrectly. | #### Outcomes: Permissionless State Proposers In the context of optimistic rollups, employing a permissionless set of validators to update the rollup state introduces unique implications. It significantly reduces the likelihood of all proposers going offline due to malfunction, as the system can continue to function correctly with just one honest and active state proposer. @@ -907,11 +907,11 @@ In this context, the transparency of validators' actions, the effectiveness of t | | 🟩🟨 Low - Medium | **V2**: Level 2 and
**V5**: Level 1 | There is a good incentive system around fraud proofs, minimizing the delay through invalid state submission. | | | 🟩🟨 Low - Medium | **V2**: Level 1 and
**V5**: Level 2 | There is a good incentive system for validators to submit fraud proofs, and some level of parallelization to challenge resolution. | | | 🟨🟨 Medium | **V2**: Level 1 and
**V5**: Level 3 | There is a good incentive system for validators to submit fraud proofs. However, due to the sequential processing of challenges, the dispute resolution timeline could potentially expand in direct proportion to the number of participants. This means that as the number of validators grows, the duration required for resolving disputes may increase linearly, thereby potentially slowing down the overall operation of the rollup. | -| | 🟨🟧 Medium - High | **V2**: Level 2 and
**V3**: at most Level 3 and
**V5**: at most Level 3 and not (**V3**: Level 3 and **V3**: at most Level 3) |There is no incentive to submit fraud proofs, but proposers can be slashed or challenges have some level of parallelization. Both of those features mitigate this risk. | +| | 🟨🟧 Medium - High | **V2**: Level 2 and
**V3**: at most Level 3 and
**V5**: at most Level 3 and not (**V3**: Level 3 and **V3**: at most Level 3) |There is no incentive to submit fraud proofs, but proposers can be slashed or challenges have some level of parallelization. Both of those features mitigate this risk. | | | 🟧🟧 High | **V2**: Level 2 and
**V3**: Level 3 and
**V5**: Level 3 | There is no incentive to submit fraud proofs and challenge a state update. The only incentive is correct state progression. | | **Sybil Attack**

An attacker can create multiple state proposers to gain an advantage.

Optimistic rollups can either employ decentralized entities to prevent sybil attacks, or design the rollup in a way that does not give an attacker controlling several identities any advantage.

This case only considers whether challenges can be processed in parallel. It is assumed that the consensus protocol is sybil resistant. | 🟩🟩 Low | **V5**: at most Level 2 | This optimistic rollup can process challenges in parallel. Therefore, an attacker cannot delay progress by initiating a long sequence of challenges. | | | 🟧🟧 High | **V5**: Level 3 | This optimistic rollup processes challenges sequentially. An attacker creating several state proposer identities can delay the chain by initiating numerous sequential challenges. | -| **Centralization**
*State proposer* | πŸ”΅πŸŸ’ Excellent | **SP5**: Level 1 and
**SP6**: Level 1 | With permissionless onboarding of state proposers and a sufficiently decentralized network, the centralization of state proposers is minimized. +| **Centralization**
*State proposer* | πŸ”΅πŸŸ’ Excellent | **SP5**: Level 1 and
**SP6**: Level 1 | With permissionless onboarding of state proposers and a sufficiently decentralized network, the centralization of state proposers is minimized. | | 🟒🟒 Very Good | **SP5**: Level 2 and
**SP6**: at most Level 3 | The onboarding of state proposers is permissionless, meaning anyone can run such an entity. While the current state proposers are not sufficiently decentralized, anyone can run such an entity to ensure state progression. | | **Escape Hatch Feasibility**
*Force withdrawal feasibility* | 🟒🟒 Very Good | **SP2**: Level 1 and
**SP3**: Level 1 | It is easy to use the force withdrawal escape hatch for any user. This reduces the delay, should the state proposer not submit states anymore. | | | 🟑🟑 Fair | **SP2**: Level 1 and
**SP3**: Level 2 | In order to make use of the force withdrawal escape hatch, the user has to interact with a smart contract or run some software. This may be an obstacle to some non-technical users. | @@ -919,11 +919,11 @@ In this context, the transparency of validators' actions, the effectiveness of t | | πŸ”΄πŸ”΄ No escape hatch | **SP2**: Level 2 and
**SP2**: at most Level 3 |There is no force withdrawal escape hatch implemented. | | **Incentive Compatibility**

The paramount importance of incentive compatibility cannot be overstated for permissionless state proposers within optimistic rollups. It is this alignment of incentives that maximizes the likelihood of fraudulent states being continually challenged, while ensuring state progression.

However, it should be noted that there are incentives beyond the protocol level that are not considered here. Those incentives include reputation and stake in the rollup itself.

It is hard to assess the off-chain incentive system, which is why users should assess the risk based on the incentive system implemented on the protocol level. | πŸ”΅πŸŸ’ Excellent | **SP6**: Level 1 and
**V2**: Level 1 and
**V3**: Level 1 | This incentive system maximizes the likelihood of state progression and fraudulent states never passing the challenge window. | There is an incentive to submit states, to challenge states, not to submit invalid states, and not to submit invalid fraud proofs. | | | 🟒🟒 Very Good | **SP6**: Level 2 and
Β **V2**: Level 1 and
**V3**: Level 1 | This incentive system encourages the likelihood of state progression and fraudulent states never passing the challenge window.

There is an incentive to submit states, to challenge states, not to submit invalid states, and not to submit invalid fraud proofs. | -| | 🟒🟑 Good | **SP6**: Level 2 and
**V2**: Level 2 and
**V3**: Level 1 | The validators on this optimistic rollup may be incentivized to submit states and challenge fraudulent states. Fraud proofs may not be incentivized, but incorrect challengers are slashed. | +| | 🟒🟑 Good | **SP6**: Level 2 and
**V2**: Level 2 and
**V3**: Level 1 | The validators on this optimistic rollup may be incentivized to submit states and challenge fraudulent states. Fraud proofs may not be incentivized, but incorrect challengers are slashed. | | | 🟒🟑 Good | **SP6**: at most Level 2 and
**V2**: at most Level 2 and
(**V3**: Level 2 or 3) | The validators on this optimistic rollup are incentivized to submit states and challenge fraudulent states.
However, the disincentive to prevent submission of fraudulent state updates or fraud proofs is not strong enough.

This may result in more delays but should not impact the honest state progression and challenges. | | | 🟑🟠 Mediocre | **SP6**: Level 3 and
**V2**: Level 1 and
**V3**: at most Level 3 | There is no incentive to submit states. However, there is an incentive to challenge invalid states.

Therefore, preventing invalid states from passing the challenge window is sufficiently ensured, but state progression is not incentivized.

This incentive system can work if a central validator is committed to always posting updates. | | | 🟠🟠 Poor | **SP6**: at most Level 1 and
**V2**: Level 2 and
**V3**: at most Level 3 | There is an incentive to submit states but no incentive to challenge invalid states.

Β Therefore, this optimistic rollup carries the risk of invalid states passing the challenge period.

There is no reward for challenging invalid states and it is attached to some cost. In certain situations, no validator may have the incentive to challenge invalid states. | -| | πŸŸ πŸ”΄ Very Poor | **SP6**: Level 3 and
**V2**: Level 2 and
**V3**: at most Level 3 | The incentive system for validators of this optimistic rollup is insufficient. It is not ready to be permissionless and there are severe risks attached - users cannot assume honest state progression. | +| | πŸŸ πŸ”΄ Very Poor | **SP6**: Level 3 and
**V2**: Level 2 and
**V3**: at most Level 3 | The incentive system for validators of this optimistic rollup is insufficient. It is not ready to be permissionless and there are severe risks attached - users cannot assume honest state progression. | ## Sequencer Concerns Recall that the sequencer component of a rollup is responsible for the construction and commitment of the transactions (and therefore blocks) of a rollup. To do so, it collects L2 transactions from users directly and deposit transactions from its underlying L1. The sequencer takes these transactions and forms blocks that are batched and written on the L1 chain (see also [Data Availability Concerns](#data-availability-concerns)). @@ -986,7 +986,7 @@ Turning away from escape hatches, users need to determine how the sequencer hand | Level | Consequences | Example | | --- | --- | --- | | 1 - No user interaction required | The user does not have to resubmit their transaction to the sequencer if there is an L1 reorg. | No example at this time. | -| 2 - User may have to resubmit transaction | An additional burden is placed on the user to verify whether their transaction was included. A user may mistakenly assume that the transaction was included and that the L2 state was updated. If the user then submits a subsequent transaction whose effects depend on the execution of the first transaction, unexpected consequences could occur, possibly including the loss of funds. | Most rollups at this time fall into this category. | +| 2 - User may have to resubmit transaction | An additional burden is placed on the user to verify whether their transaction was included. A user may mistakenly assume that the transaction was included and that the L2 state was updated. If the user then submits a subsequent transaction whose effects depend on the execution of the first transaction, unexpected consequences could occur, possibly including the loss of funds. | Most rollups at this time fall into this category. | *Note: It is unlikely that an L2 can re-submit an L1 on behalf of the user following a reorg. However, this framework includes this question in part to make sure that readers of the framework understand this risk.* @@ -1059,7 +1059,7 @@ Sequencers who misbehave should not go unpunished. It is important to penalize d | --- | --- | --- | | 1 - Any sequencer | Any sequencer can trigger the punishment of the dishonest sequencer, comparable to how any Ethereum validator can submit a dispute to a block proposer. This maximizes the probability that the punishments are actually executed for dishonest sequencers. | No example at this time.

This category can be compared to validator slashing in Ethereum, which can be initiated by any other validator. | | 2 - DAO | The most powerful members of the DAO may collude to reject slashing a dishonest sequencer. This may be because the sequencer is operated by a member of the DAO that is trying to protect the sequencer’s stake. The risk of collusion is lower than that of a centralized committee. | No example at this time.

Tellor (which is a decentralized oracle protocol) allows TRB holders to vote on price disputes. Ideally, sequencer slashing should not be based on voting, and should be undisputable. | -| 3 - Committee | The committee may collude to reject slashing a dishonest sequencer. This may happen if one of the committee members operates the sequencer. The risk of collusion is lower than if a single centralized entity is responsible for the decision. | No example at this time.

A committee might be used in the early stages of decentralized sequencer protocol to slash sequencers. | +| 3 - Committee | The committee may collude to reject slashing a dishonest sequencer. This may happen if one of the committee members operates the sequencer. The risk of collusion is lower than if a single centralized entity is responsible for the decision. | No example at this time.

A committee might be used in the early stages of decentralized sequencer protocol to slash sequencers. | | 4 - Individual account | An individual account whether to slash a sequencer or not. This may be a bot created by the rollup team. The owner of the individual account may choose not to slash the sequencer if it is also the operator of the sequencer. It may also solicit or accept bribes from the operator of the dishonest sequencer not to slash it. | No example at this time.

One possible case is if the rollup team develops a bot to slash sequencers in the early stages of decentralization. | Sequencers should act honestly, and it should be difficult for malicious actors to influence their behavior. Bribes should be difficult so that sequencers are not tempted to deviate from their expected behavior in favor of personal profit. @@ -1097,10 +1097,10 @@ The centralization of this entity has further implications worth considering: | **Centralization** _Sequencer_ | 🟑🟠 Mediocre | **S7**: Level 3 and
**S12**: at most Level 2 | A single centralized sequencer has the ability to censor user transactions if no escape hatch is available. Even if an escape hatch is present, the sequencer effectively forces a user to delay their transaction by not including it. Some steps have been taken to mitigate MEV concerns. | | | 🟠🟠 Poor | **S7**: Level 3 and
**S12**: Level 3 | A single centralized sequencer has the ability to censor user transactions if no escape hatch is available. Even if an escape hatch is present, the sequencer effectively forces a user to delay their transaction by not including it. A dishonest sequencer could maliciously optimize its MEV. It can frontrun any transaction, as it has full control over the transaction order. | | | πŸ”΄πŸ”΄ Does not apply | **S7**: at most Level 2 and
**S12**: at most Level 3 | _This table is for a single entity sequencer._ | -| **Escape Hatch Feasibility**
*Force inclusion feasibility* | 🟒🟒 Very Good | **S1**: Level 1 and
**S2**: at most Level 2 and
**S3**: Level 1 and
Β **S4**: Level 1 and
S5: at most Level 3 | Force inclusion does not require any technical knowledge in this case and does not require finding a counterparty. The user can thus activate force inclusion without any impediments.

**S5** has no effect: the force append cannot be disabled. | +| **Escape Hatch Feasibility**
*Force inclusion feasibility* | 🟒🟒 Very Good | **S1**: Level 1 and
**S2**: at most Level 2 and
**S3**: Level 1 and
Β **S4**: Level 1 and
**S5**: at most Level 3 | Force inclusion does not require any technical knowledge in this case and does not require finding a counterparty. The user can thus activate force inclusion without any impediments.

**S5** has no effect: the force append cannot be disabled. | | | 🟑🟑 Fair | **S1**: Level 1 and
**S2**: at most Level 2 and
((**S3**: Level 2 and **S4**: Level 1) or
Β (**S3**: Level 1 and S4: Level 2)) and
**S5**: at most Level 3 | If force inclusion requires technical skill, then it may be inaccessible to most users. These users may not be able to circumvent the sequencer which censors them.

 **S5** has no effect: the force append cannot be disabled. | | | 🟠🟠 Poor | **S1**: Level 1 and
Β **S2**: at most Level 2 and
(**S3**: Level 3 or
**S4**: Level 2) and
**S5**: at most Level 3 | If the user is not well-versed with Web3 and CS in general, the user will not be capable of using force inclusion. The user will be effectively censored by the sequencer.

**S5** has no effect: the force append cannot be disabled. | -| | πŸŸ πŸ”΄ Very Poor | (**S1**: Level 2 or
**S2**: Level 3) and
**S3**: at most Level 3 and
**S4**: at most Level 2
or
Β **S5**: at most Level 3 | There is an escape hatch, but it is one that can be disabled (possibly by a single party), or an incomplete one. | +| | πŸŸ πŸ”΄ Very Poor | (**S1**: Level 2 or
**S2**: Level 3) and
**S3**: at most Level 3 and
**S4**: at most Level 2
or
Β **S5**: at most Level 3 | There is an escape hatch, but it is one that can be disabled (possibly by a single party), or an incomplete one. | | | πŸ”΄πŸ”΄ Does not apply | **S1**: Level 3 and
**S2**: at most Level 3 and
**S3**: at most Level 3 and
**S4**: at most Level 2
and
**S5**: at most Level 3 | There is no escape hatch. | #### Outcomes: Permissioned Sequencers @@ -1122,15 +1122,15 @@ The natural decentralized progression from a single trusted sequencer, would be | | 🟨🟨 Medium | **S6**: Level 2 | Users may have to re-submit transactions in some edge cases. The ordering of re-organized transactions may change. | | **Centralization**
*Sequencer*

In a permissioned setting, the degree of centralization depends on the number of sequencers and well-known identities. If no identities are known, one cannot expect a permissioned sequencer infrastructure to be different from a single centralized entity, at least from a security perspective.
In the worst case, all operators are run by the same identity or all operators collude. In both cases, the same outcome as with a single sequencer can be achieved. | 🟒🟑 Good | **S8**: at most Level 2 and
**S9**: Level 1 and
**S12**: at most Level 2 | The process to operate a sequencer is subject to approval, but has been thought out. In some cases (**S8**: Level 1), it may be transparent.

There are enough well-known identities with an incentive to defend their reputation as operators. While collusion is still feasible, the likelihood is minimized for a permissioned setting.

There are MEV mitigating approaches in use. | | | 🟑🟑 Fair | **S8**: at most Level 2 and
**S9**: Level 1 and
**S12**: at most Level 3 | The process to operate a sequencer is subject to approval, but has been thought out. In some cases (S8: Level 1), it may be transparent.

There are enough well-known identities with an incentive to defend their reputation as operator. While collusion is still feasible, the likelihood is minimized for a permissioned setting.

 MEV concerns may or may not be mitigated. | -| | 🟠🟠 Poor | (**S8**: Level 3 or
Β **S9**: Level 2) and
**S12**: at most Level 2 | The process to operate a sequencer is subject to approval, and is not transparent.

This infrastructure of sequencers is, from a security perspective, indistinguishable from a single sequencer. This is because there are no additional guarantees that all sequencers are not run by the same entity or are likely to collude.

MEV concerns are partially mitigated. -| | πŸŸ πŸ”΄ Very Poor | (**S8**: Level 3 or
**S9**: Level 2) and
**S12**: Level 3 | The process to operate a sequencer is subject to approval, and is not transparent.

This infrastructure of sequencers is, from a security perspective, indistinguishable from a single sequencer. This is because there are no additional guarantees that all sequencers are not run by the same entity or are likely to collude.

MEV concerns are not mitigated. | -| **Escape Hatch Feasibility**
*Force inclusion feasibility* | 🟒🟒 Very Good | **S1**: Level 1 and
**S2**: at most Level 2 and
**S3**: Level 1 and
**S4**: Level 1 and
**S5**: at most Level 3 | Force inclusion does not require any technical knowledge in this case and does not require finding a counterparty. The user can thus activate force inclusion without any impediments.

S5 has no effect: the force append cannot be disabled. | +| | 🟠🟠 Poor | (**S8**: Level 3 or
Β **S9**: Level 2) and
**S12**: at most Level 2 | The process to operate a sequencer is subject to approval, and is not transparent.

This infrastructure of sequencers is, from a security perspective, indistinguishable from a single sequencer. This is because there are no additional guarantees that all sequencers are not run by the same entity or are likely to collude.

MEV concerns are partially mitigated. +| | πŸŸ πŸ”΄ Very Poor | (**S8**: Level 3 or
**S9**: Level 2) and
**S12**: Level 3 | The process to operate a sequencer is subject to approval, and is not transparent.

This infrastructure of sequencers is, from a security perspective, indistinguishable from a single sequencer. This is because there are no additional guarantees that all sequencers are not run by the same entity or are likely to collude.

MEV concerns are not mitigated. | +| **Escape Hatch Feasibility**
*Force inclusion feasibility* | 🟒🟒 Very Good | **S1**: Level 1 and
**S2**: at most Level 2 and
**S3**: Level 1 and
**S4**: Level 1 and
**S5**: at most Level 3 | Force inclusion does not require any technical knowledge in this case and does not require finding a counterparty. The user can thus activate force inclusion without any impediments.

**S5** has no effect: the force append cannot be disabled. | | | 🟑🟑 Fair | **S1**: Level 1 and
**S2**: at most Level 2 and
((**S3**: Level 2 and S4: Level 1) or
(**S3**: Level 1 and **S4**: Level 2)) and
Β **S5**: at most Level 3 | If force inclusion requires technical skill, then it may be inaccessible to most users. These users may not be able to circumvent the sequencer which censors them.

S5 has no effect: the force append cannot be disabled. | -| | 🟠🟠 Poor | **S1**: Level 1 and
Β **S2**: at most Level 2 and
(**S3**: Level 3 or
**S4**: Level 2) and
**S5**: at most Level 3 | If the user is not well-versed with Web3 and CS in general, the user will not be capable of using force inclusion. The user will be effectively censored by the sequencer.

S5 has no effect: the force append cannot be disabled. | -| | πŸŸ πŸ”΄ Very Poor | (**S1**: Level 2 or
**S2**: Level 3) and
**S3**: at most Level 3 and
**S4**: at most Level 2
or
**S5**: at most Level 3 | There is an escape hatch, but it is one that can be disabled (possibly by a single party), or an incomplete one. | +| | 🟠🟠 Poor | **S1**: Level 1 and
Β **S2**: at most Level 2 and
(**S3**: Level 3 or
**S4**: Level 2) and
**S5**: at most Level 3 | If the user is not well-versed with Web3 and CS in general, the user will not be capable of using force inclusion. The user will be effectively censored by the sequencer.

**S5** has no effect: the force append cannot be disabled. | +| | πŸŸ πŸ”΄ Very Poor | (**S1**: Level 2 or
**S2**: Level 3) and
**S3**: at most Level 3 and
**S4**: at most Level 2
or
**S5**: at most Level 3 | There is an escape hatch, but it is one that can be disabled (possibly by a single party), or an incomplete one. | | | πŸ”΄πŸ”΄ Does not apply | **S1**: Level 3 andΒ 
**S2**: at most Level 3 and
**S3**: at most Level 3 and
**S4**: at most Level 2
and
**S5**: at most Level 3 | There is no escape hatch. | | **Incentive Compatibility**

Incentive compatibility is a good measure for how likely sequencers will follow the best interest of users.

However, even if incentive compatibility is rated to be good, there might be external incentives not captured in this metric. If these incentives are big enough, sequencers may decide to collude or behave maliciously anyway, e.g., if there is a monetary outcome to delay or censor certain transactions. | 🟒🟒 Very Good | **S10**: Level 1 and
**S11**: Level 1 | There is an incentive for sequencers to submit transactions and a disincentive to censor transactions. | -| | 🟑🟑 Fair | Exactly one of
(**S10**: Level 1 or S11: Level 1) | While there is some incentive for sequencers to behave honestly, it could be designed with stronger incentive alignment. The sequencer may not be incentivized to progress state or include all transactions. | +| | 🟑🟑 Fair | Exactly one of
(**S10**: Level 1 or **S11**: Level 1) | While there is some incentive for sequencers to behave honestly, it could be designed with stronger incentive alignment. The sequencer may not be incentivized to progress state or include all transactions. | | | 🟠🟠 Poor | **S10**: Level 2 and
**S11**: at least Level 2 | There is no incentive for sequencers to behave honestly. This may incur heavier delays and increase the likelihood of censorship attacks. | #### Outcomes: Permissionless Sequencers @@ -1143,14 +1143,14 @@ Permissionless sequencers are necessary to truly decentralize a rollup. A well-d | | 🟩🟨 Low - Medium | **S1**: at most Level 2 and
**S2**: Level 3 and
**S10**: Level 1 and **S11**: at most Level 2 and
**S15**: Level 1 | A partial escape hatch exists but the sequencers can ignore the queued transactions. There are incentives to encourage honest sequencers to pick up the transactions. | | | 🟩🟨 Low - Medium | **S1**: Level 3 and
**S2**: at most Level 3 and
**S10**: Level 1 and **S11**: Level 2 and **S15**: Level 1 | Theoretically, if there is one honest sequencer, it would eventually include the transaction. Some appropriate incentives and disincentives are in place for censoring transactions, but some malicious sequencers may choose to censor transactions. There may be very few or no honest sequencers. This means it could take a very long time for transactions to be included if at all.

An escape hatch is not present. | | | 🟨🟨 Medium | (**S1**: Level 3 and at most
**S2**: Level 3) or
**S10**: Level 2 and **S11**: Level 3 and **S15**: Level 1 | Theoretically, if there is one honest sequencer, it would eventually include the transaction. However, Since the appropriate incentives and disincentives are not in place for censoring transactions, many sequencers may choose to censor transactions. There may be very few or no honest sequencers. This means it could take a very long time for transactions to be included if at all.
Since there is no escape hatch, there is no way to circumvent censorship from the sequencer. | -| | 🟧🟧 High | **S1**: at most Level 2 and
**S2**: Level 3 and
(**S10**: Level 2 or S11: Level 3) and
**S15**: Level 1 | There is an ability to force append (which may be disabled), but appended transactions may be ignored. There are no incentives to pick up this transaction, even by honest parties. | +| | 🟧🟧 High | **S1**: at most Level 2 and
**S2**: Level 3 and
(**S10**: Level 2 or **S11**: Level 3) and
**S15**: Level 1 | There is an ability to force append (which may be disabled), but appended transactions may be ignored. There are no incentives to pick up this transaction, even by honest parties. | | | 🟧🟧 High | (**S1**: Level 3 and
**S2**: at most Level 3 and
**S10**: Level 2 and **S11**: Level 3) or
**S15**: Level 2 | The sequencers could be bribed; since bribes are arbitrary, the influence could be much larger than incentives which don’t exist anyway.

There is no escape hatch. | | **Delay Attack** | 🟩🟩 Low | **S1**: at most Level 3 and
**S10**: Level 1 and **S11**: Level 1 and
**S15**: Level 1 | While a particular sequencer or subset of sequencers can delay your transaction, when another sequencer submits the batch of transactions, yours will be included.
 Since the incentives and disincentives for honest sequencers are properly aligned, there is a reasonable chance that the delay will not be too long. | | | 🟩🟨 Low - Medium | **S1**: at most Level 2 and (exactly one of
**S10**: Level 1 and **S11**: Level 1) and
**S15**: Level 1 | There is (a possibly delayed) escape hatch, and sequencers are either incentivized to act correctly, or disincentivized to act incorrectly. | | | 🟨🟨 Medium | **S1**: at most Level 2 and
**S10**: at most Level 2 and
**S11**: at most Level 2 and
**S15**: Level 1 | Since an escape hatch is present, the delay the sequencer will be responsible for will be bounded.

While a particular sequencer or subset of sequencers can delay your transaction, when another sequencer submits the batch of transactions, yours will be included.

Given that the incentives for sequencers are not aligned the delay may be longer or even indefinite if there are very few honest sequencers. | | | 🟨🟧 Medium - High | **S1**: Level 3 and (exactly one of
**S10**: Level 1 and **S11**: Level 1) and
**S15**: Level 1 | There is no escape hatch, but sequencers are either incentivized to act correctly, or disincentivized to act incorrectly. The incentives need to be tuned correctly to ensure no delays. | | | 🟨🟧 Medium - High | **S1**: at most Level 2 and
**S10**: Level 2 and **S11**: Level 3 and
**S15**: Level 1 | There is (a possibly delayed) escape hatch, and sequencers are not incentivized to act correctly or disincentivized to act incorrectly. | -| | 🟧🟧 High | **S1**: Level 3 and
**S10**: Level 2 and S11: Level 3 and
**S15**: Level 1 | There is no escape hatch and sequencers are not incentivized to act correctly or disincentivized to act incorrectly. | +| | 🟧🟧 High | **S1**: Level 3 and
**S10**: Level 2 and **S11**: Level 3 and
**S15**: Level 1 | There is no escape hatch and sequencers are not incentivized to act correctly or disincentivized to act incorrectly. | | | 🟧🟧 High | (**S1**: Level 3 and **S10**: Level 2 and **S11**: Level 2)
or
**S15**: Level 2 | While a particular sequencer or subset of sequencers can delay your transaction, when another sequencer submits the batch of transactions, yours will be included.

Since no escape hatch is present, you are reliant on at least one honest sequencer proposing a batch which includes your transaction.

However, since the sequencer consensus algorithm is vulnerable to bribery, it may take much longer for an honest sequencer to find which will include the transaction.

Also, given that the incentives for sequencers are not aligned the delay may be longer or even indefinite if there are very few honest sequencers. | | **Denial of Service Attack** | 🟩🟩 Low | **S13**: Level 1 | Scalability limit may be a maximum number of sequencers or another limit, but the limit is high enough to not be problematic most of the time. | | | 🟨🟨 Medium | **S13**: Level 2 | Some consensus algorithms will have scalability limits. These could lead to DoS. Scalability limit may be a maximum number of sequencers or another limit. | @@ -1161,10 +1161,10 @@ Permissionless sequencers are necessary to truly decentralize a rollup. A well-d | | 🟑🟑 Fair | **S12**: at most Level 3 and
**S14**: Level 2 | The DAO may decide not to slash a misbehaving sequencer if collusion occurs.

MEV may not be mitigated, but the DAO may have rules governing MEV issues. | | | 🟑🟠 Mediocre | **S12**: at most Level 3 and
**S14**: Level 3 | The member of the committee may collude with the rest not to slash a misbehaving sequencer.

MEV may not be mitigated, but the committee may have rules governing MEV issues. | | | 🟠🟠 Poor | **S12**: at most Level 3 and
**S14**: Level 4 | A single account can choose not to slash a dishonest sequencer. No collusion is required. The account may accept a bribe from the validator in exchange for not slashing it.

MEV issues may be mitigated, ignored, or punished. Note that the sequencer can be slashed even if they are following the MEV mitigation strategy, if the slasher is malicious. | -| **Escape Hatch Feasibility**
*Force inclusion feasibility* | 🟒🟒 Very Good | **S1**: Level 1 and
**S2**: at most Level 2 and
**S3**: Level 1 and
**S4**: Level 1 and
**S5**: at most Level 3 | Force inclusion does not require any technical knowledge in this case and does not require finding a counterparty. The user can thus activate force inclusion without any impediments.

S5 has no effect: the force append cannot be disabled. | -| | 🟑🟑 Fair | **S1**: Level 1 and
**S2**: at most Level 2 and
((**S3**: Level 2 and **S4**: Level 1) or
(**S3**: Level 1 and S4: Level 2)) and
**S5**: at most Level 3 | If force inclusion requires technical skill, then it may be inaccessible to most users. These users may not be able to circumvent the sequencer which censors them.

S5 has no effect: the force append cannot be disabled. | -| | 🟠🟠 Poor | **S1**: Level 1 and
**S2**: at most Level 2 and
(**S3**: Level 3 or
**S4**: Level 2) and
**S5**: at most Level 3 | If the user is not well-versed with Web3 and CS in general, the user will not be capable of using force inclusion. The user will be effectively censored by the sequencer.
S5 has no effect: the force append cannot be disabled. | -| | πŸŸ πŸ”΄ Very Poor | (**S1**: Level 2 or
**S2**: Level 3) and
**S3**: at most Level 3 and
**S4**: at most Level 2
or
**S5**: at most Level 3 | There is an escape hatch, but it is one that can be disabled (possibly by a single party), or an incomplete one. | +| **Escape Hatch Feasibility**
*Force inclusion feasibility* | 🟒🟒 Very Good | **S1**: Level 1 and
**S2**: at most Level 2 and
**S3**: Level 1 and
**S4**: Level 1 and
**S5**: at most Level 3 | Force inclusion does not require any technical knowledge in this case and does not require finding a counterparty. The user can thus activate force inclusion without any impediments.

**S5** has no effect: the force append cannot be disabled. | +| | 🟑🟑 Fair | **S1**: Level 1 and
**S2**: at most Level 2 and
((**S3**: Level 2 and **S4**: Level 1) or
(**S3**: Level 1 and S4: Level 2)) and
**S5**: at most Level 3 | If force inclusion requires technical skill, then it may be inaccessible to most users. These users may not be able to circumvent the sequencer which censors them.

**S5** has no effect: the force append cannot be disabled. | +| | 🟠🟠 Poor | **S1**: Level 1 and
**S2**: at most Level 2 and
(**S3**: Level 3 or
**S4**: Level 2) and
**S5**: at most Level 3 | If the user is not well-versed with Web3 and CS in general, the user will not be capable of using force inclusion. The user will be effectively censored by the sequencer.
**S5** has no effect: the force append cannot be disabled. | +| | πŸŸ πŸ”΄ Very Poor | (**S1**: Level 2 or
**S2**: Level 3) and
**S3**: at most Level 3 and
**S4**: at most Level 2
or
**S5**: at most Level 3 | There is an escape hatch, but it is one that can be disabled (possibly by a single party), or an incomplete one. | | | πŸ”΄πŸ”΄ Does not apply | **S1**: Level 3 and
**S2**: at most Level 3 and
**S3**: at most Level 3 and
**S4**: at most Level 2
and
**S5**: at most Level 3 | There is no escape hatch. | ## Smart Contract Concerns @@ -1218,7 +1218,7 @@ Many rollups allow the admins to call emergency functionality when the rollup is **SC5** Is there emergency functionality? | Level | Consequences | Example | | --- | --- | --- | -| 1 - No | The lack of emergency functions reduces the attack surface. However, it also reduces response options in the event of a security breach. | No example at this time.

All investigated rollups have some sort of emergency state functionality invocable by admins. As rollups gain maturity, some will gain the confidence to renounce the potentially exploitable emergency functionality. | +| 1 - No | The lack of emergency functions reduces the attack surface. However, it also reduces response options in the event of a security breach. | No example at this time.

All investigated rollups have some sort of emergency state functionality invocable by admins. As rollups gain maturity, some will gain the confidence to renounce the potentially exploitable emergency functionality. | | 2 - Yes | Emergency functions have a long history of [security issues in Web3](https://rekt.news/platypus-finance-rekt/). Vulnerabilities in these functions can lead to serious hacks. | The Arbitrum security council may execute an emergency function. For example, a challenge may be manually resolved when the rollup contract is paused through `forceResolveChallenge()`. | When emergency functionality does exist, it is crucial to consider who is capable of calling it. If a single centralized entity has total control over the emergency functionality, there is a higher risk of it being abused. Since emergency functionality often involves making critical changes to the state which determines how the rollup works, the consequence of abuse could be serious, including the theft of user funds. @@ -1235,7 +1235,7 @@ Well-documented smart contracts allow developers to build upon the rollup with a **SC7** How well-documented are the smart contracts? | Level | Consequences | Example | | --- | --- | --- | -| 1 - Full NatSpec and high-level docs | All functions within the rollup contracts are fully documented using the NatSpec standard. There is also high-level documentation present, including architecture diagrams and general descriptions of the contracts and functions. This is the ideal level of documentation for users and developers. | No example at this time.

Investigated rollups are missing some documentation on the function level of the smart contract. However, many existing rollups can move into this category with minor improvements. | +| 1 - Full NatSpec and high-level docs | All functions within the rollup contracts are fully documented using the NatSpec standard. There is also high-level documentation present, including architecture diagrams and general descriptions of the contracts and functions. This is the ideal level of documentation for users and developers. | No example at this time.

Investigated rollups are missing some documentation on the function level of the smart contract. However, many existing rollups can move into this category with minor improvements. | | 2 - Partial NatSpec and some high-level docs | Some functions within the rollup contracts are fully documented using the NatSpec standard. There is also some high-level documentation present. Developers and users may be confused as to the purpose of some functionality within the contracts. | Arbitrum has most contract functions documented with the NatSpec standard. However, several functions lack NatSpec comments. Arbitrum also has substantial high-level documentation of the smart contracts on its web page. | | 3 - Some function-level documentation | Only some function-level documentation in the form of code comments or otherwise. Developers and users may struggle to understand the majority of the functionality. | No example at this time.

All current rollups have at least some function-level documentation and some high-level documentation. However, a new rollup with insufficient documentation may fall into this category. | @@ -1245,13 +1245,13 @@ The smart contracts are critical to any rollup. Using the questions above, reade | --- | --- | --- | --- | | **Third-Party Risk**

Insufficient documentation of the rollup smart contracts could lead to developers incorrectly integrating these smart contracts into their applications. This could lead to unexpected which may disrupt user experience or even cause financial loss. | 🟩🟩 Low | **SC7**: at most Level 2 | At most, some functions within the rollup’s smart contracts are not well documented. This could lead to third-party developers incorrectly using these functions in their applications leading to unexpected effects such as the loss of users funds.

Even if documentation exists, there may be bugs in the contracts. | | | 🟨🟨 Medium | **SC7**: Level 3 | The rollup’s smart contracts are generally not well documented both on the function-level and on the architectural level. Third-party developers are much more likely to make mistakes when integrating with the rollups contracts. This could lead to unexpected effects such as the loss of user funds. | -| **Unauthorized Access Of Privileged Functionality Risk**
*General*

Privileged functionality on rollup smart contracts may include pausing, upgrading, the changing of parameters, as well the invocation of emergency functionality. The effect of any of these being used in a malicious manner could be devastating and, in the worse case, could lead to the theft of user assets and the disruption of the rollup. | 🟩🟩 Low | At least two of
**SC1** and
**SC2** and
**SC3** and
**SC5** are Level 1 | Critical administrative functionality is limited. What does exist is controlled by a DAO. There is a low risk that the administrative functionality will be misused to negatively impact users. | +| **Unauthorized Access Of Privileged Functionality Risk**
*General*

Privileged functionality on rollup smart contracts may include pausing, upgrading, the changing of parameters, as well the invocation of emergency functionality. The effect of any of these being used in a malicious manner could be devastating and, in the worse case, could lead to the theft of user assets and the disruption of the rollup. | 🟩🟩 Low | At least two of
**SC1** and
**SC2** and
**SC3** and
**SC5** are Level 1 | Critical administrative functionality is limited. What does exist is controlled by a DAO. There is a low risk that the administrative functionality will be misused to negatively impact users. | | | 🟩🟨 Low - Medium | **SC1** Level 2 or
**SC2**: Level 2 or
**SC3**: Level 2 or
(**SC5**: Level 2 and SC6: Level 1) | Critical administrative functionality within the rollup’s contracts is controlled by a DAO. There is a lower risk that the administrative functionality will be misused to negatively impact users. | | | 🟨🟨 Medium | (**SC1** Level 3 or
**SC2**: Level 3 or
**SC3**: Level 3 or
(**SC5**: Level 2 and **SC6**: Level 2)) | Critical administrative functionality within the rollup’s contracts is controlled by a committee. There is a moderate risk that the administrative functionality will be misused to negatively impact users. | | | 🟧🟧 High | (**SC1**: Level 4 or
**SC2**: Level 4 or
**SC3**: Level 4 or
(**SC5**: Level 2 and **SC6**: Level 3)) | Critical administrative functionality within the rollup’s contracts is controlled by a single account. This greatly increases the change that the administrative functionality will be misused to negatively impact users. | | **Unauthorized Access Of Privileged Functionality Risk**
*Upgrade*

Currently, most rollup contracts are upgradeable. Upgrades represent the most drastic change made to a smart contract and can completely alter its behavior. If control over contract upgradeability is compromised or abused, the effects could be devastating. One possible example would be an attacker upgrading the bridge contract to steal all funds locked within it. | 🟦🟩 None | **SC3**: Level 1 and **SC4**: at most Level 3 | No one can upgrade contracts. | -| | 🟩🟩 Low | **SC3**: Level 2 and **SC4**: Level 1 | A DAO controls upgrades for critical rollup contracts leading to a lower risk of malicious upgrades. Furthermore, there is a sufficient delay for upgrades such that users will have the opportunity to avoid their effects. | -| | 🟩🟨 Low - Medium | **SC3**: Level 2 and **SC4**: Level 2 | A DAO controls upgrades for critical rollup contracts leading to a lower risk of malicious upgrades. There is a small time window in which users can avoid the effects of a malicious upgrade. | +| | 🟩🟩 Low | **SC3**: Level 2 and **SC4**: Level 1 | A DAO controls upgrades for critical rollup contracts leading to a lower risk of malicious upgrades. Furthermore, there is a sufficient delay for upgrades such that users will have the opportunity to avoid their effects. | +| | 🟩🟨 Low - Medium | **SC3**: Level 2 and **SC4**: Level 2 | A DAO controls upgrades for critical rollup contracts leading to a lower risk of malicious upgrades. There is a small time window in which users can avoid the effects of a malicious upgrade. | | | 🟨🟨 Medium | (**SC3**: Level 3 and **SC4**: at most Level 2) or
(**SC3**: Level 2 and **SC4**: Level 3) | A combination of centralized control over the upgrades of critical rollup contracts and a low delay for upgrades results in a moderate risk for users, which could suffer from the effects of a malicious upgrade. | | | 🟧🟧 High | (**SC3**: Level 4 and **SC4**: at most Level 2) or
(**SC3**: Level 3 and **SC4**: Level 3) | A combination of centralized control over the upgrades of critical rollup contracts and a low delay for upgrades results in a high risk for users, which could suffer from the effects of a malicious upgrade. | | | 🟧πŸŸ₯ Very High | **SC3**: Level 4 and **SC4**: Level 3 | A single account controls upgrades for critical rollup contracts which greatly increases the risk of a malicious upgrade. Furthermore, upgrades have no delays, so users will have no opportunities to avoid the effects of a malicious upgrade. | @@ -1270,7 +1270,7 @@ The first question is whether all the transaction data is posted to L1. The high **DA1** Is all transaction data posted to L1? | Level | Consequences | Example | | --- | --- | --- | -| 1 - Yes, the (compressed) transactions are sufficient to reconstruct all L2 transactions | The rollup has maximum data availability due to the high availability of Ethereum. The L2 validators can always reconstruct the correct state of the L2. | Arbitrum One posts all transaction data to Ethereum. L2 nodes are able to construct the state due to high availability. | +| 1 - Yes, the (compressed) transactions are sufficient to reconstruct all L2 transactions | The rollup has maximum data availability due to the high availability of Ethereum. The L2 validators can always reconstruct the correct state of the L2. | Arbitrum One posts all transaction data to Ethereum. L2 nodes are able to construct the state due to high availability. | | 2 - Posts some data for each transaction but is not sufficient to reconstruct transactions | While the data posted to L1 is always available, additional information may be needed to reconstruct the state of L2. There is some risk of not being able to construct the state of L2 correctly. | No example at this time.

Any rollup which posts some transaction data or encoded transaction data which is difficult to decode could fit into this category. | | 3 - Conditionally posts transaction data to Ethereum | Some L2s do not post transaction data to L1 by default. However, they may post the data to L1 if the primary storage mechanism, such as a DAC, fails or under some other condition. The transaction data not posted to Ethereum may not be available. | Metis Andromeda posts transaction data to MEMO, a decentralized storage solution. However, the [transaction data can be posted to Ethereum during a challenge](https://metisdao.medium.com/the-tech-journey-lower-gas-costs-storage-layer-on-metis-867ddcf6d381).

Arbitrum Nova posts transaction data to a DAC and only falls back to Ethereum if the DAC is not functioning. | | 4 - No data is posted to L1 | Since no data is posted to L1, there is no guarantee for any of it to be available. There is a higher risk of not being able to construct the state of L2 correctly. | Immutable X [posts transaction data to a DAC](https://www.immutable.com/blog/a-guide-to-nft-platform-security) instead of posting it to Ethereum. | @@ -1280,7 +1280,7 @@ If the transaction data is not posted to L1, it is critical to consider who cont **DA2** Who controls data storage? | Level | Consequences | Example | | --- | --- | --- | -| 1 - Permission-less committee | Data availability depends on the strength of the incentive system. Reference **DA3** and **DA4** which assess the quality of the permissionless committee’s incentive system. | Metis Andromeda stores transaction data on MEMO, a decentralized storage network. [Anyone can create a node in the MEMO network](https://docs.memolabs.org/memo/start-nodes-in-docker/provider/run-megrez-provider-node). | +| 1 - Permission-less committee | Data availability depends on the strength of the incentive system. Reference **DA3** and **DA4** which assess the quality of the permissionless committee’s incentive system. | Metis Andromeda stores transaction data on MEMO, a decentralized storage network. [Anyone can create a node in the MEMO network](https://docs.memolabs.org/memo/start-nodes-in-docker/provider/run-megrez-provider-node). | | 2 - Whitelisted nodes | The whitelisted nodes may collude to withhold data from validators and users. There is some risk of not being able to construct the state of L2 correctly. | ImmutableX is a Validium rollup that posts transaction data to a DAC. The members of the DAC are restricted to trusted parties. | | 3 - Single centralized entity | A single party could withhold critical transaction data. This could effectively make the rollup unusable. It will likely not be possible for users to exit the L2, meaning that their funds may be stuck forever. There is a significant risk of data withholding attacks. | No example at this time.

However, it is possible that a new rollup with an underdeveloped data availability solution may fall under this category. | @@ -1325,7 +1325,7 @@ The sequencer is a critical component in any rollup, and bugs within it could ca **CD1** Are multiple client implementations in use for the sequencer? | Level | Consequences | Example | | --- | --- | --- | -| 1 - At least four clients are available, and the two most popular clients cumulatively account for less than 50% of the sequencers | This represents a fairly high level of client diversity as even the top two implementations do not form the majority of sequencers. Bugs in one client are likely to be compensated for by correct implementations in other clients. | No example at this time.

At the moment, not even Ethereum has reached this level of client diversity.

Currently, Geth forms a significant majority of the Ethereum execution clients, [around 63% at the time of writing](https://clientdiversity.org/#distribution). Prysm and Lighthouse together account for more than 70% of the consensus clients of Ethereum. | +| 1 - At least four clients are available, and the two most popular clients cumulatively account for less than 50% of the sequencers | This represents a fairly high level of client diversity as even the top two implementations do not form the majority of sequencers. Bugs in one client are likely to be compensated for by correct implementations in other clients. | No example at this time.

At the moment, not even Ethereum has reached this level of client diversity.

Currently, Geth forms a significant majority of the Ethereum execution clients, [around 63% at the time of writing](https://clientdiversity.org/#distribution). Prysm and Lighthouse together account for more than 70% of the consensus clients of Ethereum. | | 2 - At least three clients are available, and the most popular one accounts for less than 50% of the sequencers | There is still a significant risk as a similar bug in just the two most popular clients may result in significant disruption or unexpected behavior of the rollup. | No example at this time.

However, this category is justified by the Ethereum consensus client distribution. There are at least three implementations, including Prysm, Lighthouse, and Teku. None of the client implementations account for more than 50%. | | 3 - At least two clients are available, and the most popular accounts for less than 70% of the sequencers | A bug in the most popular client is likely to cause serious issues for the rollup. However, the presence of the second client may help avoid or mitigate some issues. This category also represents progress towards increasing client diversity from most rollups’ current state. | No example at this time.

Currently, the vast majority of rollups run on a single centralized sequencer, so there is not an opportunity at the moment to gain advantages from client diversity.

Again, this category is justified by Ethereum's execution client distribution. There are more than two execution clients, including Geth, Nethermind, and Erigon. However, Geth forms a significant majority which is less than 70%. | | 4 - Only one client is available | Since there is only one client implementation, one serious bug could impact the whole network. In the best case, this would lead to small delays. In worse cases, this could force users to transact on L2 by submitting L1 transactions, which would cause substantial delays and increase the burden on the L1 network. | All current rollups fall within this category, including Optimism and Arbitrum. To move out of this category, a rollup would need to implement multiple sequencers either through sequencer rotation, permissioned sequencers, or permissionless sequencers. | @@ -1345,11 +1345,11 @@ The data availability layer may introduce risk from DoS attacks and delay attack | Attack Type | Risk | Levels | Specific Comment | | --- | --- | --- | --- | | **Delay Attack**

If the sequencer malfunctions, it would require users to transact directly on L1 to create L2 transactions. Typically these transactions can only be force included after a significant delay, such as in the case of Arbitrum. | 🟩🟩 Low | **CD1**: Level 1 | A large number of clients are available without one or two forming a majority. If one or two clients have a bug, it is likely the other clients will compensate for this. | -| | 🟨🟨 Medium | **CD1**: Level 2 | Since two clients form the majority, a bug in these two clients could lead to sequencers for the L2 not functioning until the bug is fixed. Users are forced to use the escape hatch, resulting in a significant delay. | +| | 🟨🟨 Medium | **CD1**: Level 2 | Since two clients form the majority, a bug in these two clients could lead to sequencers for the L2 not functioning until the bug is fixed. Users are forced to use the escape hatch, resulting in a significant delay. | | | 🟨🟧 Medium - High | **CD1**: Level 3 | One client forms the majority, and so a bug in just this one client could significantly disrupt the sequencer network of the rollup. Users are forced to use the escape hatch, resulting in a significant delay. | | | 🟧🟧 High | **CD1**: Level 4 | There is only one client available for sequencers. If there is a bug in this client, the sequencers of the rollup may no longer be usable. Users are forced to use the escape hatch, resulting in a significant delay. | -| **Denial of Service Attack**

If the sequencer malfunctions, it would require users to transact directly on L1 to create L2 transactions. Users will likely run into scalability limits and may severely disrupt the L1 network.

If the state proposer malfunctions, then L2 states will not be updated on the L1 rollup contract. This means that users will not be able to withdraw their funds from L2 back to L1. | 🟩🟩 Low | **CD1**: Level 1 and **CD2**: Level 1 | A large number of clients are available without one or two forming a majority. If one or two clients have a bug, it is likely the other clients will compensate for this. | -| | 🟨🟨 Medium | **CD2**: Level 2 or (**CD1**: Level 2 or 3) | Since two clients form the majority, a bug in these two clients could lead to the state proposers for the L2 not functioning until the bug is fixed. As a result, users will not be able to withdraw their funds from L2.
One or two clients are used by the majority of sequencers. If there is a bug in these clients, then users may not be able to use the sequencer, and will be forced to resort to using the escape hatch. Since the escape hatch involves transacting directly on L1, many users accessing the escape hatch simultaneously could congest the L1 network and prevent other users from accessing the escape hatch. | +| **Denial of Service Attack**

If the sequencer malfunctions, it would require users to transact directly on L1 to create L2 transactions. Users will likely run into scalability limits and may severely disrupt the L1 network.

If the state proposer malfunctions, then L2 states will not be updated on the L1 rollup contract. This means that users will not be able to withdraw their funds from L2 back to L1. | 🟩🟩 Low | **CD1**: Level 1 and **CD2**: Level 1 | A large number of clients are available without one or two forming a majority. If one or two clients have a bug, it is likely the other clients will compensate for this. | +| | 🟨🟨 Medium | **CD2**: Level 2 or (**CD1**: Level 2 or 3) | Since two clients form the majority, a bug in these two clients could lead to the state proposers for the L2 not functioning until the bug is fixed. As a result, users will not be able to withdraw their funds from L2.
One or two clients are used by the majority of sequencers. If there is a bug in these clients, then users may not be able to use the sequencer, and will be forced to resort to using the escape hatch. Since the escape hatch involves transacting directly on L1, many users accessing the escape hatch simultaneously could congest the L1 network and prevent other users from accessing the escape hatch. | | | 🟨🟧 Medium - High | **CD2**: Level 3 or **CD1**: Level 4 | One client forms the majority, and so a bug in just this one client could entirely block state proposals until it is fixed. As a result, users will not be able to withdraw their funds from L2.

There is only one client available for sequencers. If there is a bug in this client, the sequencers of the rollup may no longer be usable. This will force users to access the escape hatch to transact on L2. Many users simultaneously accessing the escape hatch could cause L1 network congestion and prevent other users from accessing the escape hatch, thus removing their ability to transact on L2 entirely. | | | 🟧🟧 High | **CD2**: Level 4 | There is only one client available for state proposers. If this client has a critical bug, then the L2 states will not be proposed until the bug is fixed. As a result, users will not be able to withdraw their funds from L2. | | **Client Vulnerability Risk** | 🟩🟩 Low | **CD1**: Level 1 and **CD2**: Level 1 | A large number of clients (for both parts) are available without one or two forming a majority. If one or two clients have a bug, it is likely the other clients will compensate for this. | @@ -1391,7 +1391,7 @@ Escape hatch mechanisms usually involve an initial transaction on L1 specifying #### Improve Compatibility of Escape Hatches With Protocols Escape hatches for generalized rollups involve making a transaction on L1 specifying which operations should be performed on L2. However, rollups generally apply address aliasing for L1 to L2 calls including Arbitrum, Optimism, and zkSync. Address aliasing is an important security feature which prevents some types of cross-chain exploits. However, this means that for L1-L2 operations to successfully execute on L2, the L2 smart contract must accept the aliased version of the account as the caller. Most L2 rollups provide some way of checking whether the aliased version of the address matches the unaliased address. For example, Optimism provides the `xDomainMessageSender()` function, which allows smart contracts to check the L1 origin of the transaction. -However, many DeFi protocols deployed on L2s do not check for the aliased address of the account; they simply authorize against `msg.sender` as the L1 version of the protocol does. For example, the [AAVE V3 lending pool on Optimism](https://optimistic.etherscan.io/address/0x764594f8e9757ede877b75716f8077162b251460#code) does not make use of the `xDomainMessageSender()`, but rather checks `msg.sender` directly. Imagine a case whereby a user has deposited DAI on AAVE V3 on Optimism, and receives aDAI tokens. Then the Optimism sequencer starts to censor this user. The user cannot redeem their aDAI tokens for DAI by using the escape hatch on L1, because AAVE V3 will not recognize the aliased version of the user’s address. For current escape hatch implementations to be fully effective, all the relevant protocols on the L2 rollup must be implemented correctly and check for the aliased version of the user’s account. Thus either rollup teams must make protocols aware that their code is not compatible with escape hatches, and encourage them to increase the compatibility of this code, or they must implement an escape hatch mechanism which does not rely on the L2 protocol’s smart contract code. +However, many DeFi protocols deployed on L2s do not check for the aliased address of the account; they simply authorize against `msg.sender` as the L1 version of the protocol does. For example, the [AAVE V3 lending pool on Optimism](https://optimistic.etherscan.io/address/0x764594f8e9757ede877b75716f8077162b251460#code) does not make use of the `xDomainMessageSender()`, but rather checks `msg.sender` directly. Imagine a case whereby a user has deposited DAI on AAVE V3 on Optimism, and receives aDAI tokens. Then the Optimism sequencer starts to censor this user. The user cannot redeem their aDAI tokens for DAI by using the escape hatch on L1, because AAVE V3 will not recognize the aliased version of the user’s address. For current escape hatch implementations to be fully effective, all the relevant protocols on the L2 rollup must be implemented correctly and check for the aliased version of the user’s account. Thus either rollup teams must make protocols aware that their code is not compatible with escape hatches, and encourage them to increase the compatibility of this code, or they must implement an escape hatch mechanism which does not rely on the L2 protocol’s smart contract code. #### Faster Inclusion Commitment & MEV Mitigation When users submit transactions to the sequencer, they will receive a receipt indicating a soft commitment that it will be included at a certain position. However, the sequencer can deviate from this soft commitment and write a different order on-chain. While this might go unnoticed for many users, it can impact users that submit transactions algorithmically and dependent on each other.