Distributed Ledger Interoperability Security (PART 1/3)

This small series of articles documents my 5-year PhD journey in the world of blockchain interoperability.

Blockchain technology has become a powerful tool for creating decentralized, transparent, and secure systems. However, as the blockchain ecosystem has grown, it has become fragmented into many separate networks that need help to communicate or exchange assets easily. This lack of interoperability limits blockchain's potential to create a true “Internet of Value” where digital assets can flow freely.

Interoperability has been studied extensively, and its popularity is still rising:

I hypothesize a few reasons for the rise in the importance of the area:

1. Research in scalability feeds back on research in interoperability, so multi-chain interoperability research can influence and be influenced by cross-chain interoperability.
2. The emergence of bridge aggregators and services with better UI/UX exposes more users to interoperability solutions.
3. New use cases, particularly hybrid-blockchain dApps, are being studied as viable solutions for the tokenization of digital assets.

This doctoral thesis, “Distributed Ledger Interoperability Security,” tackles the critical challenge of enabling secure and reliable communication between blockchain networks. The core hypothesis is

interoperability mechanisms (IMs) can be developed to provide interoperability across technical, semantic, and organizational layers while meeting the security and privacy requirements of both centralized and decentralized organizations.

This high-level paper provides a quick overview of the several different interoperability layers. I like to use the blockchain infrastructure stack as an analogy to explain the layers. Imagine an EVM-based blockchain or even Hyperledger Fabric (key-value store). There are no ERC-20 tokens natively, nor ERC-721 or any others. There are no “wallets” — just transactions recorded on the ledger that respect some consensus rules (in Bitcoin, the wallet concept is even further from the underlying transaction model).

Implementing standards programmatically (e.g., ERC-20 token smart contract implementations) defines a semantic layer — a protocol or set of agreements that determine what people can do with the instantiations of those contracts — tokens. Those contracts are implemented on top of the syntactical and technical layers, namely the blockchain transaction execution and consensus engines; the contracts expose well-defined interfaces that realize the semantic layer.

On top of it, we have the organizational layer. Here, we take a step further in the abstraction from the bits and bytes that guide HTTP requests between machines: wallets read the state of the blockchain and create the concept of balances, help sign transactions that interact with the corresponding token contracts, and, therefore, send tokens to several addresses. It checks the validity of addresses and does not allow a transaction to happen if the minimum balance is missing. Consequently, a certain set of rules is enforced at this layer. Wallets can, on their hand, to define their interfaces for other wallets to collaborate with (more semantic interoperability), or interfaces for institutions (such as banks and custodians) to interact with (organizational interoperability). This layer of abstraction is concerned with the business processes, agreements, collaborations, and expectations that parties have between themselves concerning the underlying layers.

This is how the internet works and, more philosophically, people. Abstractions upon abstractions upon abstractions that allow us to be more efficient, communicate better, and settle disputes. In this thesis, we study almost the full stack of blockchain interoperability, studying and dissecting its relationships, vicissitudes, challenges, solutions, and future opportunities.

I say all because we still have the legal layer (we can even have two more according to some frameworks), but I’m no lawyer and will abstain for now.

What does an IM (interoperability mechanism) look like? Probably something like this:

It has an interface that allows other IMs and application clients to integrate with it; it has functionality that may persist in some sort of state in storage. It has a set of business rules that should be enforced (invariants, in our jargon, cross-chain rules). It supports different DLT protocols, networks, and subnetworks via connectors (technical interoperability). Some solutions are simpler and have no state (HTLCs) or little state (SATP)

Our research explores three key questions:

1. How can we assess the capabilities of blockchain interoperability mechanisms?
2. How can IMs provide technical and semantic interoperability while laying the groundwork for organizational interoperability?
3. How can we improve the security and robustness of blockchain interoperability mechanisms?

Through a series of novel contributions, the thesis aims to advance the state-of-the-art in blockchain interoperability and pave the way for a more connected and valuable blockchain ecosystem.

In a nutshell, this is the thesis:

In the time we are living, writing is one of the most powerful tools. This is because a clear mind writing is a mind interfacing with the physical world, perhaps even unfiltered thoughts, such as right now. Transmitting the key ideas of a PhD of hard work, clearly and objectively, is a challenging job. Interoperability is a tricky topic since it deals with variability, lack of communication, and unpredictability — all characteristics humans have passed to digital systems. These characteristics are, in a certain view, challenges. Challenges that, if left unsolved, hinder our field of research. Thus, we organized this thesis to deal with a series of non-trivial, related challenges in the field of interoperability. The conceptual map is as follows:

First of all, we need to solve the systematization problem—with dozens of different frameworks and fragmented vocabulary, nobody understands each other.

What is our solution? It is yet another better framework than all others, of course! Not only one or two, but three? Joking aside, it is difficult to come up with one integrated ontology that can guide the mental model of developers and researchers, and several complementary or even conflicting frameworks do co-exist. Our contribution here was (in the order of the question above) 1) a survey on what exists out there, 2) a simpler model that covers most concepts of the field, so we can have abstractions to reason about specific implementations, and 3) a framework closer to the industry and the specific protocol instantiations. These arethe foundations for BI and IMs:

BUNGEE is a data format that can be used to relay information between IMs. It refers to certain cross-chain operations that, on their turn, point to different infrastructure (centralized or decentralized). BUNGEE is technical interoperability (data format) and semantic interoperability (interchangeable blockchain views using this data format).

We then address the first part of the hypothesis: “[…] provide interoperability across technical, semantic, and organizational layers while meeting the security and privacy requirements of both centralized […]”.

This first part is addressed by our contribution Hermes: BI Middleware, which propelled the creation of the Secure Asset Transfer Protocol (SATP). A production-ready version of SATP is currently being developed under the Linux umbrella (see code). This is an engineering project backed by scientific research, focusing on testability, reliability, reproducibility, and security. It is open-source and standard-first, where a set of contributors, typically with technical background, discuss and construct the protocol together under the purview of the Internet Engineering Task Force (IETF).

After a few years of work, we realized that we needed to secure SATP with non-conventional cybersecurity techniques, more adapted to the Web3 world (lest we end up like the ~20 bridges that were hacked). For this, we created Hephaestus, a cross-chain model generator and monitor that enforces the bridge's safety. It’s this part:

Finally, to address the second part of the hypothesis, we created Harmonia, a decentralized, transparent, zero-knowledge proof-based IM for conducting interoperability processes between EVM chains (namely, asset transfers). Probably the most challenging part of my work, Harmonia touches the forefront of cryptography research and decentralized interoperability applied to real-world engineering problems: provably notarizing facts in a source blockchain such that an action can be taken in a target blockchain (note: this has to do with current bridging models: a user 1 has x units of asset A locked in the source chain; the user or someone else confirm that operation to a target chain; the target chain mints y units of asset b to user 2; user 2 could be the same as user 1; x units of a should have a corresponding value to y units of b, given by the cross-chain market rates).

Of course, an attentive reader could have already detected some (solved and/or unsolved) challenges associated with the ideas above. How do you define a cross-chain market rate? It could be easy — it’s market forces helped by arbitrageurs that take advantage of price variances and end up helping set a more stable price (this is related to the area of MEV, specifically cross-chain MEV).

Who can load such rates for smart contracts to consume then? Indeed, it cannot be a centralized party. Perhaps we can pick another challenge: ensuring that unit 1 effectively locked x units of Ain the source chain? What if forks happen? What about the privacy of such transfers? What happens if a bridge is hacked? And in the process of a transfer? By the way, what is a suitable model to know the state of a cross-chain transfer at every point in time? By the end of this series, it will be apparent which questions have been solved and which have not.

Thank you for reading! The next part of this series analyzes the solution space and delves deeper into this thesis's deliverables.