On The Road to Trustless Interoperability
People often casually use the word trustless. It lines up with the principles of decentralization and sounds good on crypto Twitter, but it rarely gets defined or quantified. And it’s important to note that the difference between “trusted” and “trustless” interoperability solutions is not binary.
Instead, many cross-chain protocols exist on a continuum between relying heavily on humans at one end and trusting code on the other. So in this sense, the (current) goal isn’t absolute trustlessness but rather the maximum level of trust minimization.
Achieving this requires careful consideration of various technical aspects, such as the design of relay nodes, the validity or fraud proofs backend, permissionless participation, etc. Below, we’ll outline some plans we have in this regard for the original Polkadot bridge, Sygma. Let’s dive in!
Introduction
As the implications of trustlessness are quite broad, let’s start by defining a few important things.
Goal: build a cross-protocol, general-purpose message-passing bridge that utilizes only a trustless off-chain agent setup.
For clarity, a trustless off-chain agent setup is an auxiliary setup of computation or persistence nodes that have no associated trust assumptions.
Below, we’ll describe our aims to achieve this goal within the framework of the famous Interoperability Trilemma. Critical to this process is the separation of the application and chain state transition and the utilization of validity proofs for both domains.
Extensibility.
Instead of facing general interoperability problems like type system inconsistency or finality rules between different protocols, the validity proofs of the application state transition will be transferred.
Generalization.
Allow developers to build verifiable computation infrastructure tailored to their application needs and not rely on the generalization of the bridge itself. Instead, tap into the rich customization provided by the tools and libraries of the Sygma SDK.
Trustlessness.
Developers will rely on the open infrastructure consisting of ZK provers, fraud challenger nodes, and onchain smart contracts instead of bridge-related off-chain agents. This ensures that applications can keep transferring proofs of their state transition and remain live even in the event of bridge malfunction or attack.
Let’s stay on the subject of trust and establish a clear definition for it. So, purely from an architectural perspective, there are two layers of trust composed like a “sandwich”:
- The first layer is the consensus layer — where we need to get confirmation that the source chain has finalized a certain block. For ultimate end-to-end trustlessness, this must be done by explicitly verifying the finality mechanism of the source chain.
- The second one is the application layer — where we need to check the semantic correctness of the executed operations on the destination chain from the application business logic perspective. In the already established jargon, verify the validity proof of the application state transition.
These two layers share similarities but are not the same thing exactly, especially in the case of a heterogeneous network setup like the one in question. It’s true that verified consensus and the immutability of smart contracts can generally cover the application layer needs. However, we argue that when thinking about these layers independently, we can approach trust minimization modularly and, instead of facing the tradeoff between shared and individual application security for the entire system, provide developers the freedom to decide for themselves and their applications.
Our approach [tool-oriented, open-source]
Now that trust is properly defined, let’s return to that triangle of interoperability trilemma. Despite the definition of “trilemma,” we argue that with the current rate of technological advances hitting all three corners is no longer impossible.
Nonetheless, some compromises must be made on the way to this interconnected multichain future. Let’s discuss available options and trade-offs.
Offchain agents
The ideal solution would eliminate third parties altogether and rely on smart contracts and destination chain validators to verify source chain consensus and application logic. However, the high network fees and limited block capacity make it infeasible in practice. As a compromise, the offchain agents could cover only one (consensus) layer of trust while relying on math (ZK) or game theory (fraud proofs) for trust minimization.
For the second (application) layer, our goal is to preserve the current functionality of Sygma SDK while handing more control over the trust to developers. This raises the question of whether the unified developer experience is worth possible sacrifices in trust. To resolve this, we are going to open the development strategy to the community to allow for an open conversation and idea validation.
Cross-protocol general message passing
The challenges here are due to the differences in type systems, encoding systems, elliptic curves, and execution environments across different protocol ecosystems. Our take on this involves open-source software that enables developers to bootstrap application-specific cross-chain communication in a no-code/low-code manner.
Under this approach, we are committed to equipping developers with scaffolding utilities, libraries, and templates while maintaining the supplementary infrastructure for even greater convenience.
Development roadmap
Sygma’s architecture has two big pieces horizontally: Sygma SDK and a relay network. And two layers vertically: app state transition proofs and chain state transition proofs. Our roadmap would unfold in two major phases.
Phase 1 — is going to extend the existing relay network with trust-minimized nodes based on the block header oracle technology and secured with Proofs of Consensus. The endgame is the infrastructure where block headers, along with cryptographic proofs of the full consensus, are posted regularly on the target chain so that the verification of the state transition can be checked via onchain execution. More specifically, two types of nodes are being developed with widely different designs that are comparable to that of rollups: optimistic and validity (ZK).
Phase 2 — will focus on application layer trust minimization. This phase aims to bring new developer experience where it would be possible to generate proofs of the application and chain state transitions and then bring these proofs to the target chain itself for end-to-end trustless verification.
Let’s briefly look at the design approaches that we’re taking.
Optimistic design
The optimistic nodes will be based on the Zipline project, started at the DevCon Bogota hackathon and inspired by the Optimism project Cannon. The first implementation aimed at onchain light client implementation, but later developments changed this direction towards full consensus proof.
In short, Zipline follows the finalized checkpoints (epoch boundary blocks) of the source chain. Only the checkpoint header data from the source chain is transmitted to the destination chain. Because Zipline uses the optimistic approach, no other data is needed during normal operation, making it extremely cheap.
In the event of a dispute where the validity of the Checkpoint is questioned, the prover must start a challenge game to show that the submitted Checkpoint cannot be justified and finalized, providing the necessary data to the Zipline verification module.
More details about Zipline can be found in the Zipline repository.
ZK design
By moving expensive computation offchain with zero-knowledge proof (ZKP) technology, we can let any target chain verify the consensus of a particular source chain cheaply. Compared with the current MPC-based model that operates under an honest minority assumption, the ZK-based model makes no assumptions for validity and requires only a single prover node online for liveness.
Another advantage is that by using ZKPs, we also abstract cryptography involved in the source chain consensus away from the destination chain execution layer. This means we are no longer concerned about the target chain's ability to verify signatures from some source chain, only that it can efficiently verify resulting ZKPs. This will likely play a vital role in our plans to support multiple heterogeneous protocols.
One caveat is that the current generation of blockchains have certain limitations that complicate the deployment of ZK solutions. Among them are non-deterministic/non-single-slot finality, expensive storage data, and limited elliptic-curve precompiles. It is also true that for each consensus protocol, separate circuits must be developed.
More details about the ZK design will be shared soon.
There is no one-size-fits-all
While trust-minimization is the general goal, we have to acknowledge that a 10 USDC transaction between two addresses owned by an individual has likely different security requirements than the execution of a cross-chain governance transaction of a multi-billion dollar TVL DeFi protocol.
Therefore, our goal must not be to offer a new trade-off on the cost, speed, and security triangle but rather focus on providing the flexibility to dynamically select the right security configuration and design that is optimal given the risk profile of the current use case at hand. The Sygma SDK will enable developers to have this freedom of choice while maintaining a single integration interface.
A recommended security configuration should ideally be provided automatically based on transaction parameters and act as a strong default to take the burden from developers to dive into the specifics of the different security mechanisms.
Looking ahead
Trustless solutions are critical for the long-term vitality of cross-chain infrastructure and blockchain ecosystems. The main issue with low-security bridges is that they compromise the benefits of using a transparent, decentralized system, which is what makes blockchain so open, efficient, transparent, and special in the first place.
While full end-to-end trustlessness is within reach, it must be approached incrementally, and compromises may have to be made. The unevenness of such a setup may raise some hard (but fair) questions about whether to sacrifice some level of trustlessness to unify the user experience or consider functionality encapsulation.
In summary, we expect that higher degrees of trustlessness will bring immense benefits. ChainSafe’s R&D team is working in close cooperation with Sygma’s core team to ensure innovation while preserving the unique value proposition of the current version. We value our community and are always open to suggestions and feedback.
Community👥
Sygma connects you with the chains you want, making it possible to compose applications that work across EVM, Substrate, and Cosmos.
The strength of our project lies in our builder community. We're always looking for contributors, and Sygma’s modular architecture is designed to foster contributions and extensions.
Check out our documentation or GitHub to get started.
Have a question? Hop into our Discord 👋
