In the previous blog post, we discussed and compared two scalability approaches. The first strategy is to scale the blockchain vertically by building layer 2 solutions on top of the layer 1 base chain. For layer 2 solutions to be able to inherit the security of layer 1, they need to send some proofs and data back to the base chain.

Although the vertical scaling can help the blockchain scale massively, this additional data still limits layer 2 solutions by preventing them from reaching their true ability. When new schemes or techniques are used to develop new layer 2 solutions, developers also need to find a new way for their solution to be compatible with layer 1.

Horizontal scaling uses a slightly different approach. It offers a way to connect the existing blockchains to distribute and share the workload between chains. This structure solves the problems around scalability, fragmentation of users, and liquidity because one chain is not being relied on for all the resources.

Initially, it will be hard to make different blockchains that have different consensus mechanisms and languages that interact with one another seamlessly.  Solutions to these problems will be developed as blockchain technology continues to improve.

Connecting blockchains is easier said than done. There are tons of ideas on how to make them work together, but how can we be sure that the connection is made properly? How can we ensure that the connection is decentralized, secure, and keeps trust minimized?

The solutions used focus only on speed and simplicity rather than security. The ideology of the existing bridges attracts many users by claiming they are trustless and secure. Let’s look at the different trust models used by interoperability protocols and their approach to security.

Trust is the assumption that you believe in something or someone to behave as you expected. In the traditional centralized model, we trust only one actor to do what we expect them to do. Blockchains promise to provide a better model of trust.

Instead of trusting only one entity, we distribute this trust to multiple entities by assuming that m out of N actors will behave and reach a consensus on what we expected. Models should be designed carefully in a way that they must limit the motivations to prevent those people from deviating from the assumption that we want.

Because most blockchains are built as closed systems, a blockchain cannot interact and exchange data with another blockchain without help.  External platforms are required to put the data from the source chain into the destination chain to be processed. The new trust assumption (aside from the trusts of the base chains) is introduced since we have added a new set of entities into our system.

To preserve the decentralization of the whole scheme, these interactions, whether sending, receiving, or verifying, must be done in a decentralized manner. Typically, the degree of trust depends on how many m out of N actors were needed to be trusted to make the system work properly. If the cross-chain interactions get compromised (or m out of N entities were malicious), it can bring disaster to all the blockchains in the ecosystem, not just one blockchain.

A study on trust assumption is important because it helps one decide how secure cross-chain communications can be. Assume that the size of the participants in the cross-chain communication is N, and we need at least m actors (where m<N) to follow the protocol’s rule for the data to be correctly passed. Classifying the model using the size of m (or size of trusted actor in the system) seems to make sense. Let us look at this in more detail.

This model does not require an external entity to verify the data passed between chains. It allows the underlying chains to verify and process arbitrary data from the source chain directly. A  specific build and implementation are needed in this case. Thus, this type of connection is complicated and hard to extend to the new environment.

It is worth noting here that trustless means no one has to trust any external validators to pass the information. The validators on the destination chain have to verify the data by themselves. The trust in the underlying chains still exists. Ethereum-Zkrollup, IBC cosmos, XCMP Polkadot, and Near Rainbow Bridge are examples of this trust model.

In contrast with the previous case, this type of bridge is easy to extend to the new environment and is also the most popular type to build bridges. It is possible to pass any message or data between chains. An example is multi-signature bridges like Wormhole, Ronin, and Horizon, to name a few.

Generally, users need to entrust their data and assets to the external party to verify and process before the data can be used in a different environment. Usually, mint and burn models are used in this type of model. One has to sacrifice security to some extent in exchange for a user-friendly experience.

If a set of validators or nodes are compromised, they can write or send any malicious data between chains, bringing disaster to the whole ecosystem. In theory, the higher the ratio between m:N is, the harder the bridge can be compromised. Most of the existing bridges use a small size of N. Thus, exploiting or controlling the whole set of nodes is not possible.

Many solutions are implemented to tackle the pain point of having a small set of N. Axelar, for example, is trying to achieve this type of scheme by using permissionless proof of stake rather than using permissioned multi-signature bridges. When the size of N gets bigger, the security of the connection between chains might exceed those underlying chains (the chains that use this Axelar as a cross-chain communication) and can be thought of as a trustless scheme.

Bridges and systems built based on this trust model usually use fraud-proof schemes, which means the system is still working as long as at least one out of N participants behaves as we expected (trust-minimized model). In fraud proof, it works by introducing a challenge window (7-14 days for the optimistic rollup case). Within that time, someone can come and prove that data or proof is incorrect, opposite to the two previous cases that prove the data is valid.

Besides the optimistic rollup, Nomad is a cross-chain protocol that relies on a fraud proof scheme to pass arbitrary data between chains with a latency of 30-60 minutes. Although they have a trade-off with latency, they are economically more secure than the m out of N case given the same size of N. They also inherit the same advantages as the previous case, which are easy to extend, and passing arbitrary data between chains is allowed.

There are only two participants in this system so there only needs to be one between each of the parties according to the rule. This sounds like a centralized case, but the worst-case scenario is that the interaction between both parties is canceled. There are several kinds of approaches for this case. An atomic swap is an example. To prevent the participants from cheating, they are designed if at least one participant deviates from the rule, their interaction is halted and reverted.

In this case, both parties do not lose anything except the gas fee. Even though this scheme guarantees a very secure bridging, several drawbacks exist. For example, they cannot be used to transfer arbitrary data between chains; only assets are allowed.

Because they rely on the lock and send patterns to ensure no one is cheating, the counterparties’ asset is locked for a fixed time if one party is missing between the processes. Users cannot use their assets within that time, leading to a bad user experience. Examples of the cross-chain bridge based on 1 out of 1 trusted model are the Hop protocol and Connext.

In the previous article, we compared horizontal and vertical scaling. Although scaling blockchain horizontally provides an attractive way to achieve higher throughput, the design to preserve the decentralization and security of the blockchain is needed.

In this post, we have dove into the detail of each design based on the trust modes hoping that readers can distinguish which one is a good cross-chain platform to use. We started with the definition of trust and then classified the cross-chain model into four types: trustless (0 out of N), m out of N, 1 out of N, and 1 out of 1. The trustless case requires a custom build so that blockchains can connect and work together seamlessly, but they provide us with the best security.

The 1 out of N-based is another interesting trust model. They provide very high security and are easy to extend with the latency trade-off. Theoretically, the m out of N has lower security than the 1 out of N case, but they are fast and user-friendly. However, when N approaches a very big number in the asymptotic case, the model can be treated as a trustless case as it is more secure than the underlying chain. Lastly, the 1 out of 1 is a special case. They provide us with a secure cross-chain assets bridge, but general message passing is not possible.