Distributed Ledger Interoperability Security (PART 2/3)
This small series of articles documents my 5-year PhD journey in the world of blockchain interoperability.
Read Part 1 if you missed it here.
Let’s start with what we do not want to do here. Part 2 does not aim to provide a comprehensive explanation of the papers or technical contributions of the thesis; rather, it will step back a bit and summarize them, explain why those contributions are needed, and how they connect with others. This process allows us to compress the technical contributions of a 121k-word thesis into a 6-minute read. Let’s start by asking:
Do You Need a Distributed Ledger Technology Interoperability Solution?
This contribution addresses the first research question by developing frameworks to assess and classify blockchain interoperability mechanisms. It provides a unified conceptual model (terms such as DLT protocol, network, and subnetwork), a classification framework (how to classify the IM), and decision models (functionality and infrastructure decision models) to help researchers and practitioners evaluate interoperability solutions. This is the functionality decision model:
This model tells you which IM to pick based on a set of requirements. We also have a model for the infrastructure. You sum the green picks, and then we have a table for you to cross the ticks with the requirements:
For example, if you need a solution with potentiality P4, compatibility C1, data transfer support, and asset transfer support, you must pick something from G2 (last line), G3, or G4 (see paper for details).
We have chosen the solution we need. How can IM instantiations (and even different types of IMs) send data to each other and thus interoperate? With Blockchain Views.
BUNGEE is a protocol that provides a common data format for accountable and privacy-preserving interoperability between blockchains. The concept of “blockchain views” allows for the capturing and merging states across different networks.
This allows privacy views to be encoded in the transaction generation receipt processes, granting privacy to the cross-chain process. Another interesting property of blockchain views is that they refer to the state a user has access at a given time — and we can even merge it to obtain a unified view that represents the concerns of a set of users:
In this example, we merge views one and two into integrated view 3. These views can transport proofs used in the bridging process for blockchain interoperability mechanisms. BUNGEE and blockchain views are important to SATP gateways (Hermes paper).
Hermes: Fault-Tolerant Middleware for Blockchain Interoperability
Hermes is fault-tolerant middleware that enables reliable asset transfers between blockchain networks. It introduces the concept of blockchain gateways and provides protocols for ensuring atomicity and consistency of cross-chain transactions. This is the foundation of our Secure Asset Transfer Protocol at the IETF. At the IETF, we create an open-source spec (anyone can participate).
Key contributions:
- Blockchain gateway paradigm for enterprise interoperability
- Protocols for atomic cross-chain asset transfers
- Crash recovery mechanisms for gateways
There are quite a lot of detailed workshops/tutorials/videos explaining this technology:
Our colleagues from Cheesecake Labs created a Stellar connector and implemented a use case using SATP:
Having a robust, standardized, open-source, enterprise-grade protocol for interoperability, we now focus on the Web3-native people and more decentralized protocols with:
Harmonia: Securing Cross-Chain Applications Using Zero-Knowledge Proofs
Harmonia is a framework for building secure cross-chain applications using zero-knowledge proofs (SNARKs). It provides a decentralized and trust-minimized approach to blockchain interoperability.
We introduced:
- A SNARK-based interoperability mechanism, architecture, and protocol
- Improved Ethereum light client protocol, namely by fixing critical security vulnerabilities
- Comprehensive security and performance analysis, the most detailed IM assessment to date.
The general idea is to implement Altair’s Light Client Sync protocol as an arithmetic circuit to generate proofs that it was correctly respected. Graphically, the algorithm works as follows:
See page 138 of the thesis for an explanation. This protocol authenticates the next valid block in Ethereum for light clients to consume. This is the first step of our idea.
This means we now have a validated block, namely a valid block root (a few more things, see details in the paper) that we can use as the foundation for part 2.
Part 2 simply creates proof that a transaction occurred in a source chain (Ethereum, e.g., locking an asset). That proof is relayed to the target chain and verified against the valid block root (part 1). This allows us to verify the state of a third-party blockchain in a decentralized, succinct, and transparent way. With this infrastructure in place, we can implement part 3 (bridge functionality on top of this).
The video explaining the paper in detail is available here:
https://web.ist.utl.pt/~ist180970/presentations/2023/dpss-harmonia-december2023.mp4 (long version).
Hephaestus: Modelling, Analysis, and Performance Evaluation of Cross-Chain Transactions
The final technical chapter presents Hephaestus, a system for modeling and monitoring cross-chain applications. It uses process mining techniques to infer bridge processes and detect deviations automatically. The motivation is straightforward: no protocol is immune to hacking, and of course, our own too. So investing in a “safer” protocol for IMs is not enough: they will eventually get attacked. So, the solution is to reinforce the security of these protocols as much as possible (solving bugs, formal verification, testing, cryptoeconomics, bug bounties, etc.) and do proactive monitoring and effective incident response. In fact, according to our comprehensive study of the security and privacy of IMs, we found very concerning facts:
- Since 2021, at least 3.1 Billion USD has been stolen from blockchain bridges (3 million USD per day).
- The attack vector is enormous, focusing on the operational layer (key management, incident response, etc).
- The academia has not studied the operational layer security of IMs in detail.
Therefore, the security problem in IMs is not solved. Hephaestus is a technology that aims to mitigate this problem. The key idea is simple: we model (either manually or semi-automatically) the expected behavior of a bridge (the so-called cross-chain rules), and with these rules, we instantiate a cross-chain model. The cross-chain model creation pipeline is depicted here:
The model monitors transactions in real-time and emits an alert if there are suspicious transactions (either rare transactions or not respecting the model). The bridge can be frozen once a warning is emitted, mitigating losses. An example of a simple bridge (blue numbers are steps on the source chain and orange on the target chain):
This is the representation of a cross-chain model. Imagine two scenarios, the one on the left and the one on the right, down below:
On the left one, we had a mint before a lock (the lock was not done), which indicates a problem; the image on the right represents the equivalent scenario in the other direction.
The key contributions of the paper are:
- First usage of process mining algorithms for cross-chain model generation
- Framework for monitoring cross-chain applications based on cross-chain rules and cross-chain models
- Setting the infrastructure, methods, and algorithms for incident response mechanisms for bridges
The talk for Hephaestus is available here. This talk also presents the Harmonia paper in a high-level fashion:
Thank you for reading. In the next and final part, we conclude this series. We will explore future work directions, trends, and predictions for the following years.
Read the other parts of this series: Distributed Ledger Interoperability Security (PART 1/3)
Source/Thesis: Distributed Ledger Interoperability Security
