What is Time to Finality (TTF)?

Published on

What is Time to Finality (TTF)?

In the rapidly evolving landscape of blockchain technology, Time To Finality (TTF) has emerged as a crucial metric, influencing both the speed and security of transactions. At Chainspect, we recognize the significance of TTF in simplifying blockchain selection for developers and investors. In this blog post, we’ll delve into the key aspects of TTF, shedding light on what it is, the parameters influencing it, and its importance in the context of finality and block reorganization.

What is TTF?

Time to Finality represents the duration required for a transaction to achieve finality within a blockchain network. Finality, in this context, refers to the point at which a transaction becomes immutable in the blockchain’s ledger, making it irreversible.

Various parameters influence TTF, making it a dynamic metric. Consensus algorithms, block time, the presence of forks, and external factors all play a role in determining the finality of transactions.

Why is it important?

When someone sends a transaction on a blockchain, it goes through different stages. First, the transaction is sent across the blockchain’s network to a block proposer. Once the proposer gets the transaction and adds it to a block, the block is shared with the whole network.

However, some blockchains don’t clearly say who should be the next block proposer, and those that do need a way to recover if that node is offline. This creates situations where there are two or more valid paths for the blockchain to continue (a fork), and the network has to decide which path is the main one.

To deal with this, blockchains have rules to choose which path should be considered the main one. Sometimes, forks can last for several blocks, where different parts of the network see different chains as the main one. So eventually, the fork will be resolved, and one path becomes the main one. The other paths, along with their blocks and transactions, are removed from the blockchain’s history in a process called a re-org.

Re-orgs are a normal part of a blockchain’s life, and they can happen regularly due to factors like how fast blocks are produced, network delays, and overall network health. However, bad actors can take advantage of or even plan re-orgs to carry out double-spend attacks. In these attacks, someone submits a deposit transaction, waits for it to be included in a block, and then creates a re-org to erase their transaction from the main chain while still getting credit for their deposit in the off-chain application.

Types of Finality

Probabilistic finality

In blockchains with probabilistic finality, the blocks don’t get fully finalized. Instead, they become more likely to be considered final over time. As time passes, the chance of a previous block being removed from the chain (re-orged) approaches zero, making the block effectively final.

Examples: Bitcoin

Provable finality

Systems using provable finality take specific steps to make finality happen more quickly and with stronger economic assurances compared to most chains using probabilistic finality.

There are two types of provable finality: chains with instant provable finality and chains with delayed provable finality.

Chains with instant finality don’t need special considerations for finality by off-chain applications. All blocks released by the network are immediately and clearly final by definition.

However, chains with delayed finality use different methods for newly produced and finalized blocks. While these chains often work better in terms of responsiveness compared to instant finality chains, they come with more complexity, vulnerability to re-orgs, and require more careful integration for off-chain applications.

Examples: Ethereum, Polkadot, Solana, Algorand

L2 Finality

L2 networks stand out because they lack consensus mechanisms in the same way a regular blockchain does. In a typical blockchain, the validator set needs to agree on the result of a state transition function. However, in an L2 network, the responsibility for verifying the state transition function lies with the underlying L1 network. Essentially, this implies that the finality of an L2 network depends on the finality condition of the underlying L1.

Examples: Arbitrum, Optimism, StarkNet, Scroll

Conclusion & real TTF metrics

We hope that this blog post provides more clarity on the TTF topic and why is it important for evaluating blockchain projects.

Here are the Time to Finality metrics for the most popular blockchains. These metrics are relevant on Feb 12, 2024. For real-time TTF check out  our dashboard.

Discover dashboard