Ethereum, Finality and Bridges
Understanding Finality Risks in Bridges
Understanding What Happened With Ethereum Last Week
On Thursday, May 11th, and Friday, May 12th, Ethereum encountered an unexpected problem that disrupted block finality for roughly two hours in total. During the two network stoppages (we’re reticent to call it an outage here at LI.FI), new blocks were still produced, but, because of a technical issue, blocks were not finalizing.
The lack of finality was traced back to a bug in Ethereum’s Prysm client, which is used by 37% of nodes, and was resolved rather quickly in both cases, with finality being restored within minutes on Thursday and in about an hour on Friday.
In both cases, Ethereum resumed functioning with finalized transactions thanks to the network’s client diversity. Ethereum developer Danny Ryan explained the outage and subsequent restoration of finality like this: “many CL clients on ethereum experienced high load due to an exceptional scenario. Lighthouse did not due to a different design approach. This kept the network live throughout the incident (at 40 to 50% of blocks) until the other clients caught up and the network finalized.”
While worrisome in the moment, last week’s finality test was most likely healthy for the Ethereum ecosystem at large, as maintaining and emphasizing client diversity is very important in keeping with central crypto characteristics like decentralization censorship resistance. That being said, it is probably a good time to go over the idea of “finality” – as it is a key aspect of how blockchains work in general and absolutely critical in the bridging space.
Understanding the Term Finality
Finality is the concept that helps dApps and users trust that transactions are secure and irreversible (aka immutable). Finality impacts all types of protocols, but for cross-chain bridge, in particular, finality issues are a fundamental concern and the worst-case results can be catastrophic.
While no major issues related to bridges were reported during Ethereum’s hiccup last week, it’s important for us to understand how finality in blockchains impacts bridges.
To reiterate, the term "finality" refers to the moment when a transaction (or block of data) has been added to a blockchain and can be considered irrevocably confirmed (editor’s note: or confirmed with some negligible probability of being reversed or altered).
Most blockchains, including Bitcoin and Ethereum, are constructed upon the idea of probabilistic finality, where the probability of a transaction being reversed decreases as more blocks are added to a chain. Different chains take different approaches to ensure that a block won’t be reverted after some point in time. In Bitcoin’s case, a transaction is considered 99.99% likely to be irreversible after 6 confirmations (which takes roughly 60 minutes at 10 min/block).
It’s important to understand here that a block with 6 confirmations isn’t any different from blocks with lesser confirmations. It simply represents a point where the wait time is considered sufficient enough for most practical use cases to safely determine that the probability of a transaction being reversed is unlikely. In essence, after waiting for a block with 6 confirmations, users can be certain that their transaction will not be reverted because of a chain-reorg or a 51% attack.
However, even after a transaction has achieved "probabilistic finality," there are rare cases where a blockchain community may collectively decide to reverse transactions. For example, after the Ethereum DAO hack, Ethereum was hard forked to revert the attacker's transactions by rolling back the chain to a block before the hack occurred.
In addition to same-chain finality worries like a bug in Ethereum consensus clients or the rare case of a blockchain experiencing a reorganization based on social consensus, the varying finality times across different blockchains also create worrying limitations for cross-chain transactions.
These limitations have led many individuals, including Vitalik, to have a pessimistic outlook on cross-chain applications.
Let’s understand these concerns in more detail.
Finality & How it Applies to Bridges
Finality in bridging transactions is inherently more complicated and risky compared to finality in simple transactions like swaps as each transaction involves multiple blockchains, each with different consensus mechanisms and time to achieve finality.
Bridges coordinate state changes between different blockchains. This coordination involves transmitting state information from one blockchain (known as the source chain) to one or more other blockchains (known as destination chains) and implementing the required state modifications (aka txs) on destination chains.
For this process to work effectively, two fundamental assumptions are made.
1) the source chain’s state is considered valid and final
2) the chain can perform the required state changes in a timely manner (without significant delays)
Everything would work fine if bridges could just wait long enough for source chains to 100% confirm finality before executing transactions on destination chains.
However, we live in a world where everything needs to be ‘instant’ – or else the user experience is deemed bad. As a result, bridges have tried to create near-instant bridging experience by adding trust assumptions related to finality, which creates the risky edge case: what happens if a chain fails to achieve finality after a bridging transaction has been executed?
In such cases, for bridges that move assets and data instantly, or even just too quickly, the destination chain and other connected chains will have inconsistent information with the source chain… which could lead to worst case scenarios like double spending, where the attack could spend the same assets more than once on different blockchains. This can result in significant losses for users.
In order to fix this, the bridged transaction would need to be rolled back as well. This would mean reverting the source chain and the destination chain (along with the other connected networks) in order to invalidate the transaction. However, this is very unlikely to be possible given how such a problem would scale across chains.
For instance, let’s say a user is hunting for airdrops, and within 10 minutes, they bridge funds from Ethereum to Polygon to Optimism to Arbitrum and uses four different dApps and three different bridges to do so. In a scenario where Ethereum is 51% attacked and the chain needs to be rolled back to a time period where the users’ initial bridging transaction from Ethereum to Polygon is invalidated, there will now be an inconsistent state across all the chains they have bridged to and interacted with afterward.
Now extrapolate this to a real-world setting where there are thousands of transactions on Ethereum every minute and funds are bridged to tens of blockchains. There will be inconsistencies in state across all these chains and in case of rollbacks, it would be almost impossible to rectify the state on all chains.
As a result, even with Ethereum’s recent technical issue and period of no finality, attackers could’ve possibly bet against the chain resuming operations without a reorg and bridged large amounts of funds to wreak havoc.
Moreover, during Ethereum’s finality hiccup last week, bridges continued to operate as they would under normal circumstances — executing transactions after x number of confirmations (varies for different bridges) and releasing funds on destination chains. While nothing happened this time around because Ethereum did not reorg, that does not mean a reorg will not happen in the future, which would result in:
LPs losing their locked funds in bridges whereas,
burn and mint bridges having inconsistent balances on source-destination chains, meaning there would be less funds backing the bridged funds resulting in cascading inconsistencies across DeFi ecosystems of several chains.
How Can Bridges Address Finality Issues?
If we believe the space will continue evolving with multiple chains and bridges that connect them, how do we design bridges that can address some of these fundamental attack vectors? Here are some of the ways and considerations:
Communicating only the states that have been finalized in the source chain by trading off speed for security. Most bridges take measures to address finality in the context of transactional state and have some heuristics in place for determining finality based on the properties of the underlying blockchain.
Bridging mechanisms where LPs promptly provide funds to the end users and accept funds from the messaging bridge when they become available. This removes the risks away from the users as the finality risk is borne by LPs or other participants in the bridge’s design (like Relayer in Across), whereas the users receive their assets instantly.
Using only secure chains. The likelihood of chain reorgs, aka hard forks, is higher in chains with less decentralization, lower economic security, and few validators. For instance, in the past we’ve seen chains with weaker economic securities like Ethereum Classic been susceptible to reorgs due to 51% attacks (happened twice in a week in August 2020) and thus it’s fair to say that it has a higher chance of facing a similar attack in the future. On the contrary, as seen in Ethereum’s case, the network was able to resume operations because of the decentralization owing to client diversity. Thus, by connecting blockchains with sufficient security and decentralization, bridges can reduce the impact of finality failures in one chain by limiting its contagion to other chains.
Using rate limits and caps on transaction size to mitigate the potential impact of such failures.
For blockchains with deterministic finality (100% guarantee that transactions cannot be reversed) like Algorand and Solana, one can consider building and using bridges that support deterministic finality.
Conclusion
The recent finality issues in Ethereum's blockchain did not result in significant problems because the network eventually achieved delayed finality, thereby preventing the exploitation of security concerns associated with bridges. Nonetheless, it serves as a crucial reminder for bridges to remain vigilant and implement strategies that effectively mitigate such risks.
If you’re interested in learning more about bridges, finality, and bridge security, you must check out:
FAQ: Ethereum, Finality and Bridges
Get Started With LI.FI Today
Enjoyed reading our research? To learn more about us:
- Head to our link portal at link3.to
- Read our SDK ‘quick start’ at docs.li.fi
- Subscribe to our newsletter on Substack
- Follow our Telegram Newsletter
- Follow us on X & LinkedIn
Disclaimer: This article is only meant for informational purposes. The projects mentioned in the article are our partners, but we encourage you to do your due diligence before using or buying tokens of any protocol mentioned. This is not financial advice.