On Interoperability and Trustlessness: What’s at stake?

Interoperability solutions (also called “non-canonical bridges”) play a significant role in the blockchain space, enabling the transfer of authenticated information between different networks. One of the challenges of these solutions is the inability to be fully trustless.

Even though in some specific cases, trust assumptions can be minimized (e.g. by leveraging state/storage/succinct proofs developed by teams such as Lagrange, Herodotus, and Succinct Labs), in most cases, there is no way to build an interoperability layer that can connect any<->any chain relying solely on consensus of the chains themselves. That’s why having an owned validation layer is an inevitable aspect of generic interoperability solutions as the implementation of the validation layer is one of the main areas where these solutions should be compared. The main properties of the validation layer to look at should be:

• Decentralization
• Throughput
• Gas-efficiency

Forging and collusion
Today, we’re going to talk about decentralization, as the collusion of participants (validators) can lead to the forging of messages or their censorship.

To avoid and minimize the chance of this happening, it’s important to understand the following aspects of cross-chain infrastructures:

1. Who governs the validation layer and how its participants are elected
2. How many and what validators would need to collude in order to:
   - forge the message
   - censor the message
3. What financial guarantees validators are providing (minimal ensured amount)

Understanding these risks
As for the first point: It’s important for cross-chain infrastructures to have a validation mechanism that’s independent of governance. Validators should work for the protocol, but not govern it. Governance should be managed by token holders, and validators should never have a significant stake to influence any decision-making. Thus, if some of the validators show poor performance, they’ll be replaced by others through governance voting.

In order to minimize any economic incentive to collude, validators should pose financial guarantees (collateral) in the form of staking. That collateral should be in liquid assets (ETH, USDC) and not in the governance token since collateral value should not be highly correlated with the governance token price. As with the classical POS approach, malicious validators would be able to open a short position before colluding, in order to hedge the cost of attack and value of the posed collateral.

Staked liquid assets act as financial insurance for everyone using the cross-chain infrastructure. If application builders know that, for example, the total collateral of a minimal number of validators needed to forge a message is ~20M, they will be able to limit the risks and value of cross-chain message transfer to make it fully insured. If validators collude, they get automatically slashed by the protocol, and confiscated collateral is used to cover the loss of users suffered from collusion. At this point, there is no single cross-chain infrastructure that has a validation layer that can provide financial guarantees with a liquid stake. At deBridge, we’ve laid in a delegated staking and slashing module into the protocol design, which when enabled, will mean validators start providing financial guarantees (insurance) for all validated messages.

Who should take responsibility for decentralization?
It’s also important to gradually expand the set of validators, expanding the default security guarantees of the validation network. Some cross-chain infrastructures allow applications to pick their own validators, shifting the responsibility for security and decentralization from the protocol to its users, which doesn’t make much sense. On top of the default validation layer, apps can always incorporate additional 3rd-party oracles in their smart contracts that process cross-chain messages. Integrating apps should be able to leverage the best security and decentralization of the provided validation layer without the need to think about how to customize settings to make messaging secure.

As mentioned earlier, to expand default security guarantees even further, state or storage proofs can be combined into validation so that a cross-chain message is accepted only if both — the majority of validators and trustless state proof — confirm its validity simultaneously. In this case, even if validators collude, or in the unlikely event of vulnerability in the validation client, the malicious message will never be validated.

To minimize the risks of vulnerability in the validation client, there is a need for client diversity, so that validation participants use different types of clients. E.g. if 8 out of 12 signatures are needed for consensus, and half of the validators are the second validation node, even if there is a vulnerability in one of the clients, it won’t allow the consensus to have a malicious message passed.

Our commitment and goals
The deBridge team is actively working on Client diversity, and will be launching a second C# client in addition to the current TypeScript client our validators are currently running, so that our network is maintained 50/50 by two different validation clients (nodes).

At deBridge, we know that 100% decentralization cannot be enabled from day one, but it’s important to move toward this goal by taking small steps. To sum up, here are the steps that we’re taking.

• Enable decentralized governance for the infrastructure and let governance expand (not replace) the number of validators enabling better decentralization
• Enable delegated staking and slashing to let validators provide financial guarantees posing liquid USDC/ETH collateral
• Explore combining validation with State/Storage proofs from Lagrange and Herodotus to expand default security guarantees of the infrastructure even further
• Increase client diversity and migrate 50% of the validators’ network to the second C# client

deBridge has been committed since day one to moving step by step towards decentralization, and we will not divert or become distracted from this mission. We will publish more updates in the future as we reach these milestones.