Abstract
We propose to formally restrict the scope of the Stages assessment to the messaging bridge and provide escrow-specific assessments that do not affect the overall Stage designation of the project, unlike today. We also propose a new, messaging-centric definition of “canonical” escrow, and as a consequence a recategorization of some of the existing ones. Finally, we motivate the need to establish exceptions for gas token escrows and related attacks that can affect all users.
Background
Today, the Stages Framework assessment is designed to loosely define as “canonical” those token escrows that are part of the suite of contracts that the rollup team develops, and that ideally have the same guarantees as the core messaging system, i.e. the same Stage (0, 1 or 2) guarantees. While rare, some tokens make use of third party escrows that either use a validation mechanism independent from the rollup’s own proof system (e.g. committee-based), or use the canonical messaging layer but with custom governance (e.g. non-Stage 1 instant upgrades). To preserve what it means to be canonical, we currently classify both types of escrows as “external” and exclude them from affecting the Stages assessment. On the other hand, general-purpose ERC20 escrows that are deployed by the rollup team itself are generally considered in scope and can therefore affect the Stages designation, even though they often do not affect the security of the other escrows (e.g. ETH) or that of the general messaging system. Examples of “standalone” canonical escrows include Arbitrum’s ERC20 gateway and Base’s L1 Standard Bridge, and examples of external escrows include Sky-controlled escrows for DAI, USDS and sUSDS that make use of canonical messaging system, or Facet’s externally validated escrow.
Edge-cases
Given that what it means to be canonical and what escrows should be included as part of the Stage assessment scope have never been precisely defined, cases have appeared that have challenged the existing soft rules and showed the need to formalize them better. In the following sections we analyze Linea, Facet Bluebird and Aztec as recent examples.
Linea
Linea has recently announced their plans to upgrade their canonical ETH escrow to enable accrual of “native yield” through ethereum validator staking using Lido’s v3 design. At the same time, Linea is also planning to become a Stage 2 rollup through multi-proving.
After extensive analysis of the native yield design, we don’t believe there is any way to make such an escrow Stage 2 compatible. When users bridge ETH, funds are redirected to node operators that can fundamentally put those funds at risk through slashable offenses, meaning that withdrawals are not guaranteed in the same way that we would expect from a simple “Stage 2 escrow”. We believe that the state validation and the censorship resistance guarantees of the messaging layer can be made Stage 2 compatible, but due to the fact that the ETH escrow is currently considered part of the Stage assessment, the project as a whole wouldn’t be considered as such. Ideally, what we want to say is that the project allows for Stage 2-compatible escrows and applications, but that this specific escrow, even though it is not a third party escrow, is not.
Specifically for this case, the situation is a bit more complicated given that the native yield bridge also corresponds to the bridge used to obtain the gas token on L2. If such bridge is compromised, it can potentially affect everyone and prevent all user withdrawals. These nuances are later discussed in the “Gas-token escrows” section of this article.
Facet Bluebird
Facet Bluebird implements a quite unique design where the gas token is obtained by burning ETH on L1 rather than locking it in an escrow. This allows the rollup to not need any privileged escrow, and leaves the task to implement them in any suitable way to third parties.
Remarkably, all core contracts are immutable, including the proof system. There currently exist two quite distinct token escrows: one immutable, and one validated by an EOA, both deployed by the Facet team. Since it would be unfair to classify the whole system as Stage 0 because of the EOA escrow, given that an alternative exists and doesn’t affect all other applications, we decided to consider it “external” and outside of the contracts covered by the Stage 2 designation. This approach goes against the initial principle that all escrows provided by the team are considered part of the core contracts and should be in scope of the Stage assessment.
Aztec
Aztec is also planning to deploy fully immutable contracts, including the proof system, but without any team-developed escrow at all. In this case, we would also like to say that the system is Stage 2 regardless of any third-party deployed escrows, if the messaging system will turn out to be in fact Stage 2. In this case, each escrow should ideally be assessed independently, and if properly implemented, considered as canonical, even if not deployed by the Aztec team itself.
The proposal
We propose to restrict the scope of the Stage assessment to the general purpose messaging bridge and assess the token escrows separately, with the exception of the gas token escrow, where its security might compromise all users (see next section).
The existing loose “canonical” definition is refined to include only those escrows that make use of the canonical messaging system, regardless of the entity behind it and its existing governance. As a consequence, externally governed escrows such as the Sky-controlled ones, will be reclassified from external to canonical, with the addition of a dedicated assessment to establish whether they introduce any additional trust assumptions or not. The “external” escrow classification will be restricted to only those that use an external validating mechanism.
Gas-token escrows
Gas-token escrows, if present, must be treated differently as the impossibility of obtaining the gas token on L2 can prevent withdrawals. As a consequence, even if Linea’s state validation guarantees are Stage 2 compatible, if the native yield bridge can be upgraded by Lido’s governance without an exit window, users can be blocked from depositing ETH and therefore obtaining the gas token. If users cannot be blocked from obtaining the gas token, but the locked tokens can be stolen, withdrawals are still technically possible, with the exception that the system falls back to a burn-to-mint gas token mechanism similar to Facet’s, which we consider viable. An open question remains on how to properly communicate this risk to users.
Another attack vector concerns unlimited minting of the gas token, as this allows for a DoS attack where the malicious operator can arbitrarily increase the L2 block base fee to prevent all users from withdrawing. A similar attack is possible on chains (e.g. Ethereal) using “omnichain” (i.e. using burn-and-mint) tokens like OFTs. In this case, it might be worth to distinguish risks introduced by the token itself and risks introduced by the rollup independently from the token, with the rationale that users will only handle tokens whose risks are already accepted. Assessing the risks of the gas token itself is out of scope for this proposal.
Free-stuffing attacks
To be consistent, it’s important to compare block-stuffing attacks through gas token minting with block-stuffing attacks that are already possible without any minting capabilities.
Today, rollup operators that collect all L2 fees are already able to stuff blocks “for free” to artificially increase the base fee by utilizing their existing token reserves. Let’s say an L2 produces blocks with a gas target of 50M gas: if the rollup operator has 1000 ETH (~3M), it can spend it all in txs until the base fee reaches a point where 50M gas equals exactly 1000 ETH, i.e. when the cost per gas is 20’000 gwei, or in other words, when the cost of a transfer becomes 0.42 ETH. If the budget becomes 10’000 ETH, then the cost of a transfer becomes 4.2 ETH. Note that this attack doesn’t hold for all projects, as some implement forced transactions whose cost is independent from the L2 base fee.
It remains an open question to what extent this type of attack should be considered in the Stages assessment and how it influences the assessment of projects that use OFT-like gas tokens.
Future work
While all tokens that are bridged using externally validated escrows can be classified as “external”, not all tokens that are bridged through trust-minimized canonical escrows can automatically be classified as “canonical”, as certain L2 tokens allow themselves to be minted both by the canonical bridge and by external entities (e.g. LayerZero). We’re expanding our infrastructure to be able to monitor all L2 tokens’ implementations to better present a full picture behind the trust assumptions of bridged tokens on each L2.
