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 TTF 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
There are 3 types of finality:
Probabilistic finality
Provable finality
L2 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
True blockchain TTF
At Chainspect, we track TTF for all our blockchains in real time and show it on the dashboard
and on individual chain pages. For example, here is the Ethereum chain page.
