Special thanks to Jon Charbonneau and Conor McMenamin for reviewing this article.

At this point we all should know that confirmation rules have security, not rollups themselves. When we say that rollups inherit “Ethereum security” or that they are “trust-minimized”, what we actually mean is that on rollups it is possible to use confirmation rules that have around the same security as Ethereum confirmation rules. Block explorers though, mostly care about showing a green badge without going into the details on which confirmation rule they are referring to or what security properties they provide.

At L2BEAT we want to tackle this problem and make it accessible for everyone. In particular, we want to focus on finality, the strongest confirmation rule against double spend attacks.

Confirmation rules: consistency vs availability

Confirmation rules are algorithms that, under specific assumptions, indicate when a block is confirmed and unlikely to be reorged. Once a block is confirmed, actions related to its transactions can be taken. For instance, this could involve handing over a coffee to a customer or delivering a car to its buyer.

Different confirmation rules give users different security guarantees. The security of a confirmation rule comprises consistency and availability, and heavily depends on the underlying consensus algorithms:

• Consistency (safety): any two nodes’ view are consistent under network partitions.
• Availability (liveness): transactions continue to get included into ledger within some time bound even after a substantial fraction of the nodes cease to participate in the protocol.

The CAP Theorem tells us that it’s not possible to design a consensus algorithm that remains both consistent under network partitions and available under dynamic participation: if a serious network partition happens, nodes can either decide to continue to produce blocks and lose consistency, or stop and lose availability. There is no way for nodes to distinguish between others being simply offline (dynamic participation) or being active but unreachable (network partitions) and therefore it’s not possible to act differently.

Eve can’t know whether Bob is simply offline or on a different network partition.

Blockchains like Bitcoin, utilizing a Nakamoto-like consensus, are liveness-favoring, meaning that during a network split both sides will continue to produce blocks and will eventually reorg if the partition is resolved, while others like Cosmos chains, using a PBFT-like consensus, halt under network partitions to preserve consistency.

Confirmation rules on Ethereum

Ethereum prioritizes availability under network partitions using the LMD GHOST algorithm. This approach means that honest nodes might have different views on the tip of the chain and could confirm different blocks for the same height, potentially leading to reorgs.

Under favorable network conditions, Ethereum also aims to provide consistency guarantees through finality, using the Casper FFG protocol. Finality is the strongest confirmation rule possible, with nodes having a hard-coded rule to never reorg finalized blocks.

The finalized ledger (green) is always a prefix of the live ledger (blue).

Finality guarantees are compromised if two conflicting blocks get finalized, an event that can occur if more than 1/3 of the validators act maliciously. However, on Ethereum, such actions come with the significant penalty of losing their stake.

Users can choose whether to use the Casper FFG as the safest confirmation rule or be more live by relying on LMD GHOST. Confirmation rules for LMD GHOST, similarly to the k-confirmation rule in Bitcoin, can be more sophisticated than just looking whether the transaction is included in the ledger, as specified in the Safe Block confirmation rule.

Confirmation rules on rollups

Rollups can, in principle, use the same confirmation rules available on Ethereum. If you send a transaction on a rollup, and later see the same transaction posted on L1 in a finalized block, you might also want to consider the L2 transaction as final. Turns out the story is much more complex than this.

Transaction data rollups

On Ethereum, blocks include both the list of transactions and the proposed state root in the block header. If the execution of the transactions does not lead to the state that the root represents, the whole block is discarded, including the transactions that can be later added to other blocks in a different order.

On rollups, since the actions of publishing data and roots are decoupled, transactions don’t need to be discarded depending on the validity of the corresponding state roots. Given this separation, it is sufficient to check whether transactions are finalized without waiting for state root finalization, bypassing additional delays such as the 7-day challenge period in optimistic rollups.

State diffs rollup

State diffs are outputs of a state transition function, and to validate that they are indeed valid, one needs to wait for a ZK proof. ZK proof generation takes time, and additionally, there is an incentive to delay further to include more transactions in a single proof to better amortize the costs of proof generation and verification.

Proof aggregation techniques offer a solution to this trade-off between confirmation times and cost amortization: even if a rollup experiences minimal activity, it can still benefit from amortization by including transactions from more active rollups in the same proof. An example of this approach is SHARP by Starkware, currently aggregating proofs from Starknet, Paradex and StarkEx rollups like dYdX and even Validiums.

Where things get complicated

Rollup derivation spec

If a rollup is not based, the derivation ordering of batches can be defined by the rollup sequencer, which might publish them in a different order on L1.

To provide an example, OP Stack chains publish batches on L1 that are linked using the hashes of the previous batch. These batches don’t need to be published in chronological order, leading to a 12-hour sequencing window during which nodes wait for potentially missing transactions. Transactions should not be considered included merely because they are published on L1: if a batch is not yet connected to the canonical chain of batches, there’s a risk that an alternative fork with a different ordering or set of transactions will be built.

On OP Stack chains, the block time is 2 seconds, resulting in 6 blocks within each Ethereum block. This grouping of 6 blocks between Ethereum blocks is termed an “epoch.” L1-to-L2 messages submitted via L1 are included in the first part of the first block of the corresponding epoch for the given L1 block. While these transactions can be considered confirmed without waiting for the sequencing window to pass, as their ordering within the L2 ledger upon derivation is known, it is important to note that nodes will not start computing blocks containing these messages if a preceding batch is missing. This is because the state cannot be computed without the complete sequence, and therefore, state roots will also not be published on L1.

The consequence of this is that merely examining on-chain data is insufficient to track L1 confirmation times. It’s also necessary to understand how L2 blocks are derived from L1 data by examining the rollup node software itself.

Permissioned functions

Scroll is a ZK rollup posting transaction data, meaning that, in principle, one doesn’t need to wait for a ZK proof to consider their transaction final. This would have been true if they didn’t implement a function to delete batches that have not been proven yet.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

The same can apply to rollups posting state diffs: zkSync Era and zkSync Lite have a three step process to post state diffs: first, they commit the data without any proof, then they provide a proof for them, and then, after a 24h delay, the root becomes available to be execute to process withdrawals. In theory, when a proof is provided the ordering of the transactions is fixed, so one doesn’t need to wait for the execution delay to pass. Except, zkSync can revert those blocks:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

While for zkSync Era no blocks have ever been reverted, on zkSync Lite it happened 8 times.

Finality observability

Since rollup posting state diffs are not posting transaction data, how can we track that a transaction has indeed been included? Yes, we could track effects, like account nonces, but the general case gets tricky. A month back I asked the following question:

Let’s take a look at some of the replies:

This is a solution that works if the sequencer is willing to respond to you and if you trust it. What if it doesn’t? Or, what if it does but you don’t trust it? How do you verify that the claim is correct?

My favorite reply.

A solution that actually works was suggested here:

while this works, it means that the technical decision of using state diffs leaks into the application logic, meaning that even if a rollup is EVM equivalent, projects must adapt their contract to this consideration.

A partial solution is to post a transactions root and verify their validity inside the ZK proof. Even in this case though, one must rely on the sequencer to obtain the necessary Merkle path, which might be reasonable with reputable centralized sequencers, but gets trickier in a permissionless setting.

Liveness metrics

As a first step towards tracking times to finality of rollup transactions, on L2BEAT we started tracking liveness metrics, in particular intervals between transaction batches (if applicable) and state roots. The rationale is that if a rollup is, for example, interacting with L1 just once per month, users cannot expect time to finality to be in the order of minutes. Liveness metrics can be thought as a lower bound indicator for time to finality: if a transaction data rollup is posting batches once every two minutes, and assuming that the distribution of L2 transactions is uniform, the expected time to finality is not lower than one minute.

Here’s some examples of data that we are tracking for zkSync Era (state updates) and OP Mainnet (tx batches):

zkSync Era liveness metrics for the month of September.

OP Mainnet liveness metrics for the month of September.

As predicted, since ZK proofs take time to be generated and there’s the incentive to include more transactions in a single proof, zkSync Era has worse liveness metrics than OP Mainnet. It’s important to keep in mind that, as we discussed in previous sections, liveness metrics don’t translate directly into finality considerations: in the worst case, OP Mainnet has actually a higher time to finality because of its sequencing window.

You can now explore liveness metrics for most rollups on L2BEAT:

Limitations of tracking liveness

While liveness can be seen as a lower bound indicator for finality, it can sometimes be a very bad one. Imagine a rollup with a block time of 4 seconds, meaning that for each Ethereum block there are 3 rollup blocks. If the rollup operator is posting only two L2 blocks per L1 block, even if from Ethereum’s perspective the rollup is very live, it will increasingly fall behind L2 soft confirmations and time to finality would get increasingly worse. While this is an extreme scenario, it’s something that rollups need to account for.

A practical example is Starknet: although we observe an average of 32 seconds between state updates, the time to finality is actually close to 6 hours:

Source: starkscan.co

This is because Starknet publishes a state root update for each L2 block on L1. However, to do this, they must reference a SHARP proof, which is typically posted approximately once every 30 minutes. Additionally, these proofs are around 6 hours behind the tip of the L2 soft-confirmed chain.

Soft confirmations

Soft confirmations are confirmation rules used to achieve shorter confirmation times on L2 at the expense of safety guarantees. Currently, in all cases, soft confirmations imply trusting the centralized operator not to post different txs on L1. Incorrect soft confirmations are attributable faults, therefore mechanisms to track sequencers reputation offchain or onchain slashing can be implemented. In collaboration with Nethermind, we plan to estimate those security properties and track the amount of value at risk at any given moment in time.

Left: economic guarantees on Starknet if they had soft confirmations secured by a slashing mechanism. Right: total value at risk of being reorged over time.

Going forward

Tracking the time to finality is a complex task. Our first step is to monitor the intervals of proof submissions for ZK rollups, which impose a higher lower bound on the time to finality compared to intervals between state root submissions. Following this, we plan to introduce charts displaying historical data for each project. Subsequently, our research will focus on all additional mechanisms that need to be considered to ultimately achieve real-time metrics for time to finality. Stay tuned!

Disclaimer：

1. This article is reprinted from [medium]. All copyrights belong to the original author [Luca Donno]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.