Thoughts on Token Bridge Safety

Introduction

If the past two decades working in the security industry has taught me anything, it is that software is imperfect. Despite our aspirations of writing perfect code, there will be days when our assumptions will be shattered and we will hope that we had the foresight to install a safety net.

What is becoming increasingly more obvious as token bridges are affected by high-profile hacks is that there is a need to invest more in defense-in-depth strategies to reduce the potential for a vulnerability to result in a total loss on our worst day.

In this short blog post, I’ll share some safety feature concepts that I feel token bridges should consider adopting to better reduce the impact of otherwise existential threat scenarios.

Existential Threat Scenarios

There are a number of risks that need to be considered for token bridges, for this post, we’ll focus on three key threat scenarios:

• Smart Contract Compromise: When there is a bug in a smart contract that allows an attacker to extract or mint arbitrary amounts of funds.
• Chain Compromise: When a connected chain is compromised (eg. 51% attack) and an attacker can make arbitrary transactions on that chain.
• Validator Compromise: What happens when parts of the validator set is compromised?

The above three cases are some of the worst possible threat scenarios a token bridge can face, and despite having a team of the best developers in the world, audits from the most reputable firms, and an industry-leading bug bounty program, there are still actions that a token bridge must additionally take.

Let’s now move on to the safety features I believe would be helpful to a token bridge in trying to hedge against these threat scenarios. The thing we’ll want to keep in mind as we go through these is that we shouldn’t let perfect be the enemy of the good. Each of these features has its limits, but when layered together they could provide significantly more safety for the token bridges of the future.

Safety Feature #1: Rate Limiting / Governor

One of the really exciting capabilities of many token bridges is that you can move as much value as you want as fast as you want. This is a compelling property, to be completely unbounded by limits, but this can quickly become a double-edged sword during a smart contract compromise or chain compromise scenario, as the token bridge can quickly be drained to zero in record speed.

I’ll fully recognize that the concept of adding value movement limits to token bridges can truly feel like a wet blanket. However, I believe having an upper bound of value movement per chain is an essential safety feature for any token bridge for those moments when things go wrong.

Let’s say for example we have chain A (governed at $1M) and chain B. In either a smart contract compromise or a chain compromise scenario on chain A, fraudulent token transfers would be constrained to a $1M loss per day from chain A to chain B. Notwithstanding, this still presents a $1M per day liability, but such an outcome has much less of a chance of becoming a project ending event (assuming the limits are set using a risk-based approach).

Advantages:

• Allows token bridges to set a configurable amount of value movement that is allowed to cross the bridge in a given time period.
• Guards against both smart contract compromises and chain compromise scenarios when the attack involves crossing the bridge.
• Provides real-time protection with no direct human interaction for the control to operate.

Limitations:

• Does not address direct value extraction from a smart contract vulnerability on the origin chain.
• Does not address the validator compromise scenario.

Safety Feature #2: Reconciliation / Global Accounting

Accounting is one of those things within a given blockchain that we often take for granted, but when you move cross-chain, the accounting between the various chains becomes the responsibility of a given token bridge.

In very simple terms, this feature would attempt to ensure that when moving assets across a token bridge that the origin chain contract minimally has the funds (verified independently of the smart contract logic) before that transfer can be finalized on the destination chain. This is an additional check on top of the existing smart contract logic, such that if the smart contract logic were to have a bug, an additional process conducted by validators can check the balance of the original contract to reveal that the transaction is fraudulent.

Advantages:

• Reconciles the value that is existent on the origin chain contract with the value minted  while largely distrusting the smart contract logic.
• Provides a sliding scale by which mint risk is properly calibrated up/down with the value present on the origin contract, in the case that the origin contract is compromised and the attack involves crossing the bridge.
• Provides real-time protection with no direct human interaction for the control to operate.

Limitations:

• Does not address direct value extraction from a smart contract on its origin chain.
• Does not address the chain compromise scenario.
• Does not address the validator compromise scenario.

Safety Feature #3: Emergency Shutdown

In software development, there will always be scenarios that we cannot anticipate. It’s hard to imagine where the next bug will come from. However, one of the things we can anticipate is the type of response actions we likely will need to have when those scenarios happen.

On token bridges, one of the most common response actions we expect to take during a smart contract vulnerability scenario is to patch the vulnerability by doing a smart contract upgrade.  However, in some cases, the time in which a token bridge (especially a decentralized token bridge) can design new smart contracts, perform the necessary governance actions, and deploy them on the chain is valuable time in which assets could remain in jeopardy.

The way this feature could work is by allowing a quorum of validators to vote on whether value movement is enabled or not. This would allow a set of validators, who have determined that there is an existential threat to the token bridge to disable value movement for a temporary period of time by which an upgrade can be completed safely.

Advantages:

• Provides preemptive upgrade safety while developing and deploying a smart contract bug fix on the chain.
• Avoids needing to develop a custom neutered contract upgrade on the fly to get to containment while a more complete solution can be designed and deployed.
• Provides preemptive protection for attacks that cross the bridge, but also some scenarios by which the attack is direct on the origin chain.

Limitations:

• Does not address chain compromise.
• Does not address validator compromise scenarios.
• Requires the control to be enabled before the attack occurs and requires some form of user intervention or built-in logic to know when to shutdown.
• Control may be slow to activate in decentralized validator scenarios.

Safety Feature #4: Validator (De)centralization

It feels a bit weird to reference validators in this context, but quite clearly the level of decentralization in validators for a given token bridge is high on the list of important properties needed for token bridge safety.

Here are just a few attributes to consider when thinking about validator decentralization:

• How many validators are there?
• What is the validator threshold to achieve consensus?
• Is there sufficient geographic diversity between validators?
• Is there sufficient technology, operational, and process diversity between validators?
• Who are the actual validators and what stake do they have in protecting the token bridge?

The importance of all these attributes is that you want to understand how difficult it would be for an external party to censor or effectively rug the token bridge either maliciously or via a validator compromise scenario.

Advantages

• Validator networks that have a larger number of validators at a higher threshold will largely be harder to corrupt, compromise, or collude to impact the token bridge.
• Allowing validators to take on additional shared responsibilities, such as Governing and Accounting functions, can additionally hedge smart contract and chain compromise risks.
• Geographically dispersed validator sets are much more tolerant to physical intervention.
• Maintaining a diverse set of technology, operations, and process makes wholesale compromise significantly harder.
• Possible rewards/slashing for observed good/bad behavior.

Limitations

• The more centralized the validator set, the more likely it could fall victim if the threshold to achieve consensus is low (eg. 3 of 5).
• The more decentralized the validator set, the slower it may be to conduct governance activities and perform contract upgrades in the case of existential threat, putting more pressure on real-time controls to largely be the protection layer.

Parting Thoughts

As I alluded to in the intro, I believe strongly that token bridges must adapt to the increasing threat landscape by adopting defense-in-depth strategies if they intend to guard against existential threats imposed by a smart contract, chain, or validator compromises.