The Cross-Chain Bridge That Never Gets Hacked: Technical Deep Dive

Blockchains are islands. Assets cannot move freely between them unless cross-chain bridges connect and help port assets between blockchains.

But bridges are also the weakest points in any blockchain architecture. Hackers can drain millions in a single cross-chain bridge hack. The 2022 Ronin Bridge exploit had users losing $600 million in a single attack.

Over the past few years, over $2 billion has been stolen in these hacks. Speeding transfers, decentralising trust, and maintaining rock-solid security–these three form a trilemma of cross-chain bridge security vulnerabilities.

Bridges vary in design and complexity, and understanding why they fail is the first step towards building a bridge that can never be hacked.

Which Attack Surfaces Are Unique to Cross-Chain Bridges?

Are cross-chain bridges easy targets for hackers? What do you think?

Poorly designed bridges are an easy target for hackers. History has been full of instances in which critical flaws in bridges made them attractive targets for hackers. Most have a single central pool of funds backing the bridged tokens. Hackers can exploit this vulnerability by compromising private keys or falsifying cross-chain messages.

Let’s talk about some unique attack vectors beyond smart contract vulnerabilities that impact cross-chain bridges:

Validator Compromise

Bridges use a set of operators or a committee to sign off on cross-chain transfers. An attacker can attain enough private keys and fake approvals to drain funds. Ronin Bridge lost five of nine keys in March 2022, while Harmony lost two of five keys in June 2022.

Message Forgery and Relay Manipulation

In many bridges, an oracle network or relayer listens for ‘lock’ events on Chain A, and then triggers minting on Chain B. Hackers can fake or replay these messages to orchestrate exploits.

The Wormhole exploit in February 2022 happened when the hacker created fake deposit events to mint unbacked tokens. Qubit and Meter.io hacks in Jan and Feb 2022 had similar attack vectors.

State Desynchronisation and finality issues

Some bridges use optimistic fraud proofs or weaker consensus guarantees. A hacker might attempt to force a fork or replay an old state if the blockchains have different finality models. The August 2022 Nomad hack happened when a hacker abused a default root-of-trust to accept fraudulent transactions.

Solvency and economic assumptions

Custodial or mint-burn bridges need to keep sufficient collateral. Anytime a bridge mints synthetic tokens without proof of reserves, there is a chance that the tokens created are unbacked.

The teams have to be constantly on their toes so that the 1:1 peg remains despite any sudden oracle failures or market movements. The Wormhole hacker was able to create 120,000 wETH on Solana. These tokens were not properly collateralised.

Analysis of Existing Bridge Architectures

Bridges aren’t built on a template design. They come in various architectural models

• Multi-sig validator committees: In this design, a group of custodians jointly approves transfers. If a hacker is able to secure enough or collude enough keys, they can get access to funds and steal them. Ronin, Harmony, and Multichain bridges have this design.
• Oracle-based attestations: These bridges use external Oracle networks to sign or attest deposits. The Oracle network is outside the control of a bridge. If ever the Oracle network gets compromised or delays occur, the entire bridge can get stalled or hacked. For example, the early versions of Wormhole used guardians. These external guardians were tricked into signing a fake VAA.
• Optimistic proof models: This model assumes the submissions are honest until a challenger proves the submission to be false. Optimistic bridges are similar to optimistic rollups. They shift the onus of challenging the transaction onto others. If the challenge period is very short or if no one monitors the submissions, there is a chance a fraudulent transaction can slip through. For instance, Nomad Bridge allowed bogus roots that no one challenged.
• Wrapped-asset custodial systems: When a single custodian holds assets on Chain A and mints wrapped tokens on Chain B, centralisation risks increase. These bridges are more susceptible to cold-wallet hacks, deceitful reserves, and regulatory seizures.

The Cryptographic Way: Zero-Knowledge Proofs as a Foundation

Zero-knowledge proofs (ZKPs) offer a promising approach for on-chain cryptographic verification of cross-chain state transactions. Let’s learn how the entire cross-chain transfer happens in case ZKPs are deployed within a cross-chain bridge:

• ZK-SNARKs: There are no multi-sig or external oracle attestations happening for verification here. Instead, the smart contract on Chain B requires a cryptographic proof from Chain A’s state. The proof size is tiny. This cryptographic proof or ZkSNARK can be checked on Chain B with no additional data load.
• Recursive proofs: ZK proofs are succinct. Still, too many ZKPs combined for many blocks can be heavy. The solution is recursive proofs and distributed proving.
• Data-parallel proving: DeVirgo is a distributed proof system that parallelises work and then compresses the result with a classic Groth16 SNARK. The parallel tasks are more capable of achieving linear scalability and reducing on-chain costs dramatically from ~80 million gas to ~230 thousand gas fees per header proof.
• Decentralisation by Design: ZK-based bridge removes trust in committees. Smart contracts enforce validity. Since there’s no privilege attached, any node or relayer can run the Zk prover. Proofs bind Chain A’s state to actions on Chain B cryptographically. The structure becomes trust-minimized.

If, during a hack, the perpetrator is able to collude many keys or nodes, they still need to produce valid ZKPs against A’s state, which isn’t possible unless the underlying consensus is shattered.

Security Model for a Never-Hacked Bridge

What exactly does a 'never hacked' bridge mean? Such an architecture guarantees unforgeability by using on-chain cryptographic state verification. It doesn’t use vulnerable oracles or keys.

As long as one honest prover exists and the base chain remains live, the Zk bridge can achieve complete consistency and liveliness. ZKPs close most of the attack vectors. However, attention is needed during finality. The consensus of the entire chain needs to be compromised for the platform to be hacked.

• Consensus verification via light-client proofs: An on-chain light client or a ZK proof that functions on the light client logic can be used to verify source blocks on the destination chain. Any update that isn’t a part of the main chain gets rejected. When honest nodes on different chains agree on the exact sequence of events, the network state becomes consistent.
• Deterministic state commitments: Any secure design must require a proof that ties the transfer to a specific block hash or state root on Chain A before any mint or token release takes place on Chain B. Merkle proofs of a user balance can provide the exact state data that the platform can peruse to avoid message forging.
• No external trust assumptions: ZKP systems assume zero trust on off-chain processes. Since no ‘trusted’ updater or time lock external witness is needed, the validity is checked on-chain.
• Finality and Safety buffers: Proof-of-Work chains require 12 or more confirmations to avoid deep reorganisations, while BFT chains rely on final guarantees. A cross-chain bridge that’s secure parameterises these finality lags and enforces them in the verification step.
• Sound Cryptographic assumptions: These include some standard assumptions, including that the SNARK proof is sound and that at least one honest node follows the protocol to produce proofs.

The bridge security is reduced to the security of the source chain itself, plus the proof protocol to eliminate all extra assumptions. A ‘never-hacked’ chain would make fraudulent transactions mathematically impossible as there’s no shortcut than to bust the entire chain’s consensus.

Verification of solvency and economic security

Besides being secure, bridges need to be economically sound, too. An economically viable bridge would have every minted token on Chain B backed by real collateral on Chain A. Key practices include:

• Collateral solvency: The smart contract can help anyone verify that the total value locked on Chain A matches the total supply of wrapped tokens on Chain B. Merkle proofs of contract balances or on-chain oracles can report proof-of-reserves to avoid any unwarranted minting of unbacked tokens.
• Mint-burn verification: A standard lock/mint model enforces a 1:1 relation between tokens and their wrapped counterparts on different chains. Tokens are only minted on B after tokens are locked on A. A failure in achieving this ratio can create arbitrage. Zk proofs guarding lock events automatically tie minting to actual locks.
• Preventing unbacked synthetic assets: Flash loan attacks or draining fees are economic risks that bridges need to consider while designing the architecture. A resilient design requires higher initial collateral or inflationary staking by validators to reduce the risks of black swan volatility.

An ideal bridge considers economic security as no magic money. They should publish their proof of reserves and undergo regular audits of their collateral.

Risk Assessment Framework

A risk assessment framework is needed to evaluate the risk profile methodically. A simple framework involves the following parameters:

• Architectural risk: During architectural risk evaluation, you must ask whether the design has any single points of failure, and more than one independent network or layer of validation. Bridges with monolithic networks and single validator sets score high risk.
• Cryptographic risk: Here, you must ask what kind of primitives are used and if they are well-studied SNARKs or novel schemes. You must evaluate if the bridge relies on trusted setups. Complex circuits or unproven ZK algorithms invite high risks.
• Operational risk: Operational risk evaluation includes bridge operators’ security, hardware security modules, procedures for upgrades or emergencies. Poor key management leads to losses, and non-production signers or inexperienced teams elevate risk.
• Economic risk: This evaluation involves assessing whether there is sufficient collateral, and if it is possible that market shocks could leave the bridge under-collateralised. Also, check how the bridge handles token volatility, and whether it has liquidity networks or insurance funds.
• Governance risk: Governance parameters that need evaluating include the upgrade mechanisms, who can pause or change the bridge logic, and whether a small group can enact changes secretly.

Each category can be rated low, medium, or high, and an overall score can be given. A good bridge scores low risk in all categories.

Bridge Due-Diligence Checklist

Here’s a practical checklist teams must complete before integrating a bridge:

• Cryptographic guarantees: The bridge must use on-chain verification, such as light client proofs or SNARKs. Solutions solely relying on federated signers should be avoided.
• Codebase auditing & formal methods: Third-party attestations are a must for smart contracts. Look for reports by reputable firms detailing the issues found and the suggested fixes.
• Validator set assumptions: Study the processes that determine how validators are selected and replaced, staking and slashing schemes for misbehaviour, and how the bridge documents its minimum honest-majority assumptions.
• Upgrade mechanisms: Check whether the bridge’s upgrade mechanism uses a multi-sig or DAOs. Also, note if the bridge’s code changes are time-locked for public review. The process should be transparent and involve multiple independent stakeholders.
• Emergency and Monitoring controls: Check for built-in safes. If something goes wrong, is there a provision to pause the bridge on-chain, or is there a cross-chain ‘circuit breaker’ to halt new transactions if an anomaly is detected? Any independent watchers or oracles validating transfer logic can also add to security layers in a cross-chain bridge.
• Incident History: Review any past security incidents in detail. Assess each incident and the cause behind it. The cause can be an inherent design flaw or an execution error.

Bridges that are transparent about their issues or past downfalls and have learnt from their mistakes are better than those that don’t disclose at all.

Incident Response Plan for Cross-Chain Bridges

Even the best of the bridges need to plan for contingent situations. An incident response plan for a secure cross-chain bridge must include:

• Pre-attack preparation: Have a provision for an on-chain circuit breaker for all ‘just in case’ emergencies. For instance, a ‘paused’ flag in contracts that governors can activate. The control of the flag should be distributed among multiple parties or a DAO. Regular drills should be conducted, and a rulebook should detail different situations and how to respond to them if the keys are suspected to be compromised.
• On-chain circuit breakers: On-chain mechanisms should be in place to freeze operations. It is up to the team to decide whether the freeze function will be a simple pause of the mint function or a more complex ‘transfer buffer’ function that queues large withdrawals for manual review. However, it is necessary to make the mechanism as trust minimised as possible by making it require the consensus of multiple off-chain signers or multisig.
• Cross-chain withdrawal freezes: What happens if an exploit is in flight? How do you deal with such a situation? Some protocols consider coordinated rollbacks. The team can halt the bridge and revert suspicious transactions on the destination chain, if possible, and then reclaim tokens on the source chain. This process can get complex and dirty, but it can be planned carefully.
• Communication protocols: Put protocols in place to notify users, validators, and partners. Determine which channels will be used to announce the issue. Prepare template messages for quick and transparent communication, and avoid panic among the community members.
• Law enforcement and blockchain training: Stay in touch with blockchain analytics or a law enforcement firm, like a Chainalysis incident hotline, to trace stolen funds.

Bridges operate with a large amount of funds. Working with authorities can help with marking and freezing illicit funds.

Blueprint of the Cross-Chain Bridge That Never Gets Hacked

A future-proof, secure cross-chain bridge must include the following components:

• Trustless State Validation: The bridge verifies messages directly against the source chain’s consensus. It removes reliance on validators, multisigs, or oracles.
• ZK Light Client on Destination Chain: On-chain verifier contract checks ZK-SNARK proofs of source chain state. An efficient and tamper-proof bridge replaces full light clients with succinct proofs.
• Recursive Proofs for Scalability: A ZKP bridge compresses multiple state transitions into one proof. It scales bridge performance without increasing gas costs.
• Proof Aggregation: A ZKP mint and burn model batches multiple transfers into a single proof. It reduces overhead, improves latency, and lowers on-chain footprint.
• Permissionless Relayer Network: anyone can submit valid proofs. There’s no need for trusted relayer networks. These committee-based bridges are secured by incentives like fees and bound by cryptographic verification.
• Deterministic Fraud Detection: Invalid messages are rejected automatically via on-chain logic and distributed proving on ZKP bridges. These bridges optionally integrate circuit breakers or fraud alerts for added safety.
• On-Chain Verifiers with Bounded Cost: Proof checks remain within predictable gas limits on ZKP bridges. These bridges are compatible with both L1s and L2S, enabling broader deployment and interoperability.

Secure Cross-chain Bridges Are The Next Step Towards a Multichain Future

$6 billion in monthly volume flows through bridges. For the interoperable and multichain future, bridges need to become the ‘hack-proof’ infrastructure central to the crypto ecosystem. The article talks about various vectors and standards that bridges should implement, including robust economic safeguards, rigorous auditing of funds, decentralised validation relayers and governance, and a zero-trust design.

Crypto’s history has been full of exploits. This can be changed if cross-chain bridges balance cryptographic rigour with decentralisation. The bridges of tomorrow need to be built with math, and not blind trust.