BTC
ETH
HTX
SOL
BNB
View Market
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

Talking about TTF: How long does it take for a rollup transaction to be finalized?

Foresight News
特邀专栏作者
This article is about 1901 words, reading the full article takes about 3 minutes
TTF (time to finality) refers to the time it takes for a trading signal to start broadcasting and reach its final state.
AI Summary
TTF (time to finality) refers to the time it takes for a trading signal to start broadcasting and reach its final state.

Original title: A tweet on rollup time-to-finality (TTF)

Original author: @larry 0x

Original compilation: Frank, Foresight News

First, what is TTF and why is it important?

Finality is the state in which a transaction can never be canceled, restored, or modified, that is, the corresponding transaction issue is deemed to have been resolved.

TTF (time to finality) is the time it takes for a trading signal to start broadcasting and reach its final state. The following are the TTFs of several selected chains:

TTF is an important parameter with multiple uses:

  • If I were a merchant accepting cryptocurrency payments, I would want to wait for a TTF before delivering goods or services so that I know the payment will not be cancelled.

  • If Im cross-chain bridging the protocol, and a packet is submitted on the sender chain, I want to wait for the TTF before relaying it to the receiver chain.

  • ……

Secondly, Rollups

The life cycle of a Rollup block has 2 stages:

(1) Its data is published to the data availability (DA) layer;

(2) Proved to be valid at the settlement layer;

It is worth noting that TTF is different for full nodes and light nodes of the Rollup chain:

  • For the former, they do not need to wait for (2) settlement, because as long as the block data is released in (1), they can immediately verify the validity themselves;

  • For the latter, they do need to wait for the settlement process;

During the settlement layer proof phase, there are two types of Rollups, depending on the mechanism they use:

  • Validity Rollups (aka zero-knowledge rollups, zkRUs). After the sequencer generates a block, the prover (usually the same person as the sequencer) submits a validity proof, proving through some cryptographic magic that the block is valid.

  • Optimistic Rollups (opRUs). The sequencer generates the block but does not prove that it is valid. If it is actually invalid, anyone (the prover) can challenge it by submitting a fraud proof, which will cause the block to be rejected. A block is considered valid if no one proves it to be invalid for a period of time, known as the dispute period.

Note: I dont like the term zkRU because many of these proof systems are not actually zero-knowledge technology, so Validity Rollup is a more accurate term. However, the use of zkRU is so common that I use it.

There are also some important things to know:

  • In fact, block data is usually not published to the DA layer immediately after the block is generated. The sequencer will usually wait a while and then publish a few blocks in batches (possibly to save gas fees);

  • Validity proofs are also often delayed, usually because generating them is computationally expensive and takes time;

  • Validity and fraud proofs are not only propagated on-chain. For example, if someone sends me an off-chain validity proof, I can be sure that the block is valid without having to wait for (2) the on-chain settlement process.

Finally, we are ready to discuss how long it takes for a Rollup transaction to reach its final outcome.

For full nodes, the process is simple: as soon as block (1) is published and completed on the DA layer, then it is finalized.

If we mean:

  • T 1 : How often blocks are published on the DA layer (for example, if the sequencer publishes a batch on the DA layer every 10 minutes, then T 1 = 10 minutes)

  • T2: TTF of DA layer

Then the TTF of Rollup = T 1 + T 2 .

For light nodes, they must wait for (1) and (2) to complete. For opRU, the time in (2) is the challenge period; for zkRU, the time is after the prover generates and releases the validity certificate.

If we mean:

  • T 3: For opRU, challenge period;

  • T 4: For zkRU, the time when the validity certificate is published at the settlement layer;

  • T 5: TTF of settlement layer;

Then there is the TTF of Rollup:

  • For opRU: max (T 1+T 2, T 3);

  • For zkRU: max (T 1+T 2, T 4+T 5);

The maximum in these equations means that we need to wait for the DA and settlement process to complete, whichever is longer (almost always settlement).

Now, here comes the problem! Remember, we said proofs can also be propagated off-chain. For zkRU, if we receive a proof of validity off-chain, then we can immediately say that the transaction is completed without waiting for the on-chain settlement process.

For opRU, its hard to say. The reason the challenge period (T 3) is often longer is due to concerns that the settlement layer may review evidence of fraud. So it really depends on your risk tolerance. If you are very confident that the settlement layer will not review the transaction, you may choose to wait for a shorter period of time. Otherwise youll wait longer, but you dont have to wait any longer than T3.

Let us summarize:

Here are two practical examples, Arbitrum and zkSync. They use Ethereum for DA and settlement, so T 2 = T 5 = 13 minutes.

  • Arbitrums sequencer publishes data approximately every T 1 = 6 minutes, and Arbitrums challenge period is T 3 = 1 week;

  • The sequencer of zkSync publishes data approximately every T 1 = 3 minutes, which proves that it is published irregularly, but on average once every T 4 = 1 hour;

We could also consider a hypothetical zkRU that uses Celestia for DA, which I think is closer to the end result:

  • T 1 = 0 (Celestia is cheap, so we assume blocks are published immediately after generation);

  • T 2 = 12 seconds;

  • T 4 = proof generation time, depends on the proof system;

Finally, a brief discussion of what it all means

As you know, Im a fan of Cosmos, and IBC uses light node clients to verify packets, so you need to wait for the TTF, as shown in the For light nodes column above.

For opRU, this could be up to 1 week (if youre not too confident about Ethereums censorship resistance), which is too long for practical purposes. This is why for opRU we have to use full node bridges such as Axelar and Wormhole, which consist of a bunch of operators running full nodes.

The disadvantage is that we need to trust this set of operators, which may not be as economically secure as the sender chain, which is why I am bearish on opRU.

With normal zkRU, we only need to wait for the DA to be finalized (16 minutes on Ethereum) + proof generation time, we dont need to wait for the proof to be released on Ethereum - this is the main advantage over opRU!

This is also one way I think Celestia can improve the Rollup cross-chain experience. On Ethereum, instead of waiting 16 minutes, we only wait 12 seconds + proof generation time. Light node clients can use QGB to check proofs from the Celestia validator (Im guessing its now renamed Blobstream), or possibly do DA sampling as well.


Celestia
DA
Welcome to Join Odaily Official Community