backshare via telegramshare via whatsappshare via facebook

The Importance of Security Architecture in Blockchain Bridges

The Importance of Security Architecture in Blockchain Bridges

The cryptocurrency industry is constantly evolving as a response to growing public adoption. Public adoption and usage have caused congestion on leading blockchains in the past. Congestion leads to much higher average transaction fees and typically slower average transaction time. 

Developers designed different solutions to resolve congestion on the blockchain and increase scalability. Some of these solutions are new blockchain ecosystems built to rival well-known and established blockchains. Others are called “L2”, also known as layer 2 solutions or “sidechains.” L2 solutions are essentially additional blockchains built on top of an established chain.  

Prominent L2s for Ethereum include Arbitrum and Optimism. Arbitrum settles Tx fees on ETH, while Optimism requires using OP tokens for transactions. Notable L1s include BNB, Cardano, and Solana, each with its unique token for its ecosystem.

These solutions solved the scalability issues many blockchains experienced, lowered fees, and assisted with transaction speed. The plethora of blockchains has complicated the space and created new problems to solve. 

New blockchains have added a lot of value to the crypto space and answered consumer demand. However, each of these blockchains acting alone would not maximize their full potential. There is a need to interconnect different blockchains to develop collaboration between ecosystems. By connecting diverse blockchain ecosystems, Dapps become interoperable and more accessible. Interoperability is becoming more and more significant in the current blockchain landscape.  

Blockchain bridges or cross chain bridges are a protocol that helps different blockchains communicate with each other. Bridges facilitate the transfer of information and assets across blockchain networks in the form of tokens. Some cross chain bridges permit the transfer of information across several blockchain ecosystems.

Most blockchain bridges work by “wrapping” tokens via smart contracts and issuing new assets on a different chain. Bridges that function in this manner are called “lock and mint” bridges. Some other bridges operate differently, but we will discuss this topic later.

Blockchain Bridges & Security

Cross chain bridges are becoming essential in the current crypto landscape but are still far from perfection. Because blockchain bridges are relatively new & still in the infancy stage of development, there are some unresolved issues. 

The most prominent issue for most cross chain bridges is security. 

There have been many instances where cross chain bridges had vulnerabilities that were later exploited. Exploits have become so common in the cryptocurrency industry that a significant hack occurs monthly on average. According to Bloomberg, the USD equivalent lost in bridge hacks in 2022 exceeds $1 billion. The large number of hacks led the tech publication Wired to declare that “bridge hacks are the new exchange hacks,” although it is possibly worse.

In many of these hacks, the main vulnerability is storing funds on the bridge in a “hot” contract.

Vulnerabilities of Crypto Bridges

Common risks of blockchain bridges include smart contract risks, technology risks, censorship risks, and custodial risks. We’ll elaborate more on the topic in our next blog post.

Smart contract risk refers to a flaw within the smart contract code that hackers may exploit. Technology risks are flaws within the bridge’s code unrelated to the smart contract. Censorship risks are when a bridge restricts users from taking specific actions. Custodial risk is when the operator of a custodial risk absconds with user funds.
The two primary types of crypto bridges handle these risks differently. 

There are two types of blockchain bridges. They are typically called trusted bridges or custodial bridges and trustless bridges or non custodial bridges.

Non custodial bridges operate via algorithms and are usually open-source code. As such, they face a much higher degree of risk from technology and smart contract risks. The majority of bridge hacks that occurred have taken full advantage of exploits from those risks. 

Custodial bridges require a trusted third party who safeguards funds stored in the bridge. The risk is that the third party needs to be well reputed and trusted not to abscond with users' funds. This risk is called custodial risk. At the moment, the custodial risk with crypto bridges is theoretical only. 
A few crypto exchange operators have disappeared mysteriously in the past and possibly stole funds. To date, no similar accusations have been made against any known crypto bridges. 

Censorship risk is yet another theoretical risk associated with custodial bridges. Bridge censorship is when the operator limits a user's actions or bridging abilities. Bridge censorship is exceedingly rare and typically only used against bad actors. Bridge censorship may be taken against users handling funds identified as stolen from hacks or phishing attacks. While some define bridge censorship as a “censorship risk,” it may benefit the crypto industry.

Practices to Boost Blockchain Bridge’s Security

From a security perspective, custodial bridges are preferable to non custodial bridges. Security does depend on the operator, however. If the bridge is custodial, ensure it secures funds in cold storage wallets to guarantee funds are safe. 

Security audits are of utmost importance regardless of whether the bridge is custodial or non custodial. Audits should be conducted regularly by different and well-regarded blockchain security firms. These security audits minimize the threat of both smart contract and technology risks. 

ChainPort’s Security Philosophy for Bridges

At ChainPort, security and interoperability are the highest priority. We recommend that other bridges consider making security their utmost consideration. 
ChainPort’s CTO outlined his security philosophy on Twitter following the hack of Wormhole bridge earlier this year. He elaborated on minimizing the risk to users' funds while striving for greater security and useability. Here are his recommendations:

Closed Source Code

Never reveal your code to the public. Hackers may still expose closed source code, but it has a smaller attack surface. The first time an attacker can start building an attack is after the code is deployed. Any fixes that expose previous flaws won't get exposed before actual patching on production.

While some in the crypto industry may dislike closed source code, it can significantly assist with security. Hackers must ensure the code is fully deployed, then reverse engineer it. Closed source code ensures that hackers will have a more challenging time when attempting to exploit a vulnerability. 

Decentralization

Decentralize a bridge only in instances where it reinforces security. 

In blockchain technology, decentralization usually increases security, but that's not always correct. Decentralized architectures are more difficult to build correctly. Typically decentralized architecture only becomes more secure than centralized architecture after extreme testing.

Blockchain bridges are even more prone to this decentralization vulnerability. They take on the security attack surface of all the blockchains they connect to combined. 

Distribute All Possible Computation 

Cross chain bridges like ChainPort support multiple chains and bridging directions. As such, these bridges have many layers of computation running. Each computation phase must be as distributed as possible to keep architecture secure.

Distributing computation phrases means any layer of logic run should have parallel independent processes running in tandem. Parallel independent processes work as a failsafe. Computation phrase distribution also means distributing the workload. The workload can be distributed to clouds, accounts, and dedicated compute layers to secure the architecture further.

Exhaustive Cross Validation

Backend computations that make a logical checksum or condition that may alter the bridge's state should have multiple other computations running in separation. These computations will checksum the calculation itself.

You can't always know if your logic is broken. If given enough layers of checksums, you can get a real-time signal if something appears wrong in the high level and freeze the bridge.

Avoid Third-Party Code

Don't trust 3rd party code, and be skeptical of your code. To mitigate risk, conduct independent cross validations inside the code. Avoid calling any function in a contract you didn't write yourselves.

At times using third-party code can't be avoided. If so, proceed when there's absolutely no other possibility. Then, only interface with highly audited, trusted, and reputable code from verified sources.

Abolish Implicit Checksums

In many recent bridge exploits, the core of the failure was "implicit checksums." This means the code relies on an implicit assumption that functions will be called or parameters will be used a certain way.
These low-level implicit checksums are standard. Many developers struggle to write a flow of logic if they have to checksum the fundamental pillars of the code's reality at an atomic level.

There are places hidden in every piece of code which implicitly assume that multiple conditions apply. The ability of the code to operate per spec is highly dependent (often in an unmapped way) on these conditions existing at runtime.

ChainPort roots these out by "not trusting our code." Additionally, we have multiple passes over time trying to find these places. Multiple passes are done to make more checksums and explicit ones in every step of the logic flow.

Join the ChainPort community for updates:

ChainPort | Twitter | Telegram | ChainPort News | Documentation | Medium

back
share via telegramshare via whatsappshare via facebook