On the Security of Cross-Chain Protocols
This article belongs to a series of articles analyzing the state of security and privacy in cross-chain protocols.
Access the paper below👇👇👇
What does a secure Interoperability Mechanism look like?
If you’re wondering why a cross-chain protocol powered by an interoperability mechanism is relevant to web3, check out our previous post here.
We propose a foundational framework delineating the essential properties that make up a secure Interoperability Mechanism (IM). At the heart of these security properties lies the underlying cross-chain logic, represented by predefined rules that state the expected behavior of the protocol.
- Integrity: A rule of thumb for integrity in asset transfers and asset exchanges is that double spend should not occur. Integrity is guaranteed if every generated cross-chain transaction respects the set of cross-chain rules defined (e.g., a transaction minting tokens in the target chain is only valid if there is an equivalent amount burnt or locked in the source chain).
- Accountability: An IM is accountable if these conditions hold: 1) the metadata of any event is public, or at least verifiable (for example, private data verifiable through proving systems, for example leveraging Zero-Knowledge Technology); 2) for every integrity violation attempt of the cross-chain rules, there is a mechanism to prove it; and 3) there is a third party that can enforce punishments for proved integrity breach attempts (e.g., third-party, blockchain smart contract). This property encompasses two facets: identification and punishment of actors through slashing mechanisms.
- Availability: Finally, we require the availability property for IMs to be considered secure and guarantee the availability of resources and services for users and operators. Protocols must be resilient to failures and handle unexpected behavior quickly. An IM guarantees availability if it can process valid cross-chain transactions (validate, issue, or relay).
Security Approaches
The table below summarizes the architectures of interoperability mechanisms in the industry and academia. The classification is divided into two tiers; for each, we provide the component that takes the Interoperability Mechanism (IM) role.
Trusted Third Parties
Trusted third parties play a crucial role in facilitating interoperability among blockchain networks, offering solutions that rely on centralized models or trusted computation mechanisms. In centralized approaches, trusted parties manage users’ funds and execute transactions, either directly holding funds or serving as relay services. This method offers enhanced performance and accountability but raises concerns about centralization, censorship, and security vulnerabilities. On the other hand, trusted computation solutions leverage technologies like trusted execution environments (TEEs) to ensure the integrity and authenticity of computations within secure enclaves at the hardware level. While TEE-based systems offer heightened security, they still face challenges such as reliance on hardware manufacturers for attestation keys and the potential for collusion among administrators. To mitigate these risks, strategies such as employing multiple TEE hosts controlled by different entities can be implemented to enhance security and decentralization.
Examples: Centralized Exchanges
Distributed Trust
Centralized solutions offer simplicity, speed, and cost-effectiveness but come with security risks. To address these risks, intermediary-distributed networks distribute power among multiple entities. These networks employ various consensus mechanisms to validate transactions and maintain the integrity of cross-chain protocols. The architecture of intermediary networks must consider factors such as latency, cost of execution, and the level of decentralization to ensure efficient and secure cross-chain operations (ranging from permissionless to permissioned). Technologies like Threshold Signature Schemes (TSS), Multi-Signatures (MS), and Multi-Party Computation (MPC) are utilized to build trust among mutually untrusted entities, offering enhanced security and reliability in cross-chain transactions. Despite these advancements, challenges remain in ensuring liveness, scalability, and resilience to malicious actors, underscoring the ongoing efforts to develop robust and efficient cross-chain interoperability solutions.
Example: Wormhole, Axelar, etc
Native State Verification
In the pursuit of native state validation for cross-chain interoperability, approaches focusing on proof validation within the participating networks offer promising avenues. These methods enhance security by validating events or states directly on-chain, minimizing reliance on external entities.
Inclusion Proofs leverage block headers from the source chain to verify transactions on the target chain. This approach ensures transaction validity through proofs like Merkle paths or note commitments. While effective, the security of Inclusion Proofs hinges on the light client implementation in the target chain, raising concerns about potential risks if relayers go offline or become compromised.
Example: any light client-based protocol
Validity Proofs, on the other hand, employ proving systems (such as Zero-Knowledge Proofs) to validate consensus states across chains. These usually rely on light clients as well. Although efficient, these systems often require trusted setups or face scalability challenges due to the creation of proofs. Nonetheless, advancements like verifiable off-chain computation and batch processing offer avenues for mitigating these limitations.
Example: zkBridge
Fraud Proofs adopt a reactive approach to security, assuming the validity of relayed information until proven otherwise. External watchers challenge invalid data, ensuring relayer accountability, and are incentivized by rewards. Choosing the appropriate time windows and guaranteeing continuous watcher availability is essential to maintain protocol safety.
Example: Optimism
Local Verification
Secret-based and time-based locks, exemplified by Hash Time-Locked Contracts (HTLCs), offer a decentralized avenue for asset exchange, utilizing hashlocks and timelocks. However, the synchronous nature of HTLCs presents challenges for atomicity during extended crashes, prompting the introduction of intermediary networks or premium-based approaches to modify communication assumptions and enhance completion likelihood. Despite game-theoretical analyses demonstrating increased completion probability under collateralized models, concerns persist regarding vulnerability to attacks during premium exchange. Explicit time intervals face obstacles due to varying time management mechanisms across permissionless blockchains, with solutions like Verifiable Timed Commitments (VTC) and Verifiable Timed Signatures (VTS) aiming to ensure protocol security and privacy. Nonetheless, questions regarding protocol liveness in scenarios of participant disengagement underscore the need for ongoing refinement and exploration of cryptographic locks in cross-chain asset exchange protocols.
Example: Hash Time Locked Contracts (HTLCs)
Conclusions
- Integrity in cross-chain protocols relies heavily on cryptographic mechanisms, with the number of embedded assumptions playing a crucial role in determining the protocol’s integrity level.
- While academic literature predominantly focuses on asset exchanges and transfers between blockchains, there’s a noticeable gap in studies addressing general data transfers, contrasting with industry trends favoring arbitrary message-passing bridges.
- Accountability in cross-chain protocols is typically emphasized through stake-slashing mechanisms. Still, a smaller subset of research also advocates for incorporating legal identification of parties, especially in centralized or permissioned network configurations where nodes possess identifiable attributes.
- The trade-off between privacy and accountability of parties is still unexplored. It still needs to be clarified the level of privacy that a protocol can yield to its users while still guaranteeing accountability in case of protocol deviation. In the next blog post, we will zoom in on privacy in cross-chain.
A special thanks to Rafael Belchior for reviewing and making suggestions that improved this post.
Additional relevant resources:
