Effective translation of cross-link communication, Nomad’s general relativity

Today, we see a plethora of platforms, applications, and projects built on a common blockchain system. Application developers face enormous difficulties when they want to interact with multiple systems because each blockchain system speaks its own language and has its own protocol. Therefore, a solution is needed.

If you go back in 2020, you’ll remember the catchy headline: “Blockchain compatibility is no longer the future, it’s the reality.”. “Blockchain compatibility” is real, and true compatibility is not a set of cross-chains. We need global naming schemes, address discovery protocols, naming protocols, and scalable routing algorithms. There is a greater need for systems that support cross-chain solutions for these protocols and abide by fundamental principles such as trust, authentication, and message integrity. At the same time, creating a properly architected and scalable system is a challenging and rewarding task. But, of course, the true compatibility of blockchains will reveal the ecosystem’s greatest potential.

Cross-chain pain points

The Nomad team felt the pain of users wanting to share assets from different networks and developers wanting to use the liquidity from other networks in their applications. Once the problem is clearly defined, the team begins to develop solutions for this pain point.

Nomad is a universal cross-chain communication protocol that allows users to securely build applications and transfer digital assets between different blockchains. The core design centers on the traditional Optimism Rollup mechanism, but with a novel security model. Therefore, Nomad has open validation, low gas fees, and broad participation. However, unlike Oru, Nomad utilizes locally verifiable fraudulent certificates and operates on many different chains. The protocol leverages these capabilities to provide fast, cheap and secure communication across all smart contract chains and aggregates.

Nomad core features

Xapps are a key component of Nomad and can be built and safely deployed to almost any blockchain as a cross-chain application. XApp is essentially interoperable, allowing users to seamlessly bridge assets across different chains, such as the Protocol’s flagship XApp, Nomad Token Bridge. This bridge is just one of many Xapps built on top of Nomad messaging channels. Other Xapps, such as the NFT Bridge, cross-chain lending protocols, and cross-chain order books, can be built on top of Nomad channels.

XApp helps break through some of the limitations and limitations of traditional decentralized applications, which are essentially limited to their native chains and require significant solutions to communicate and send assets to other chains. To build these xapps efficiently, Nomad developed routers. In short, the router acts as a framework that enables developers to deploy XApps to any existing cross-chain channel without friction.

Another core function of Nomad is its novel security model. By design, Nomad does not include lightweight clients. Therefore, instead of validators or blockchains, the protocol acts as a smart contract deployment between two chains with components under the chain. This in turn means that the protocol also does not include formal security. This approach gives Nomad outstanding benefits in terms of simplicity and operating costs, but on balance it won’t prove safe.

To overcome this, Nomad is designed to be safe in practice. Nomad’s core channel relies on fraud certificates and release certificates to prevent channel failure. It also makes use of the network watcher system, through which users and applications are delegated to monitor fraud. This approach helps support Nomad’s system design to protect it from critical attack media and mitigate its lack of provable security.

Working Principle: Notarization framework

In the context of notaries, a quick overview of NOMAD’s working methods can be found:

The Home Chain sends documents (messages) that need to be authenticated and signed by a notary (Updater) .

These messages are then passed to the updater.

The updater acts like a notary and signs a contract to sign the message and verify its authenticity.

The updater can try to game the system by generating a fraudulent copy of the message. However, if they are captured, their bindings are cut and their updater privileges on the network are revoked.

When such a malicious game occurs, the network receives an alert and learns that the update is indeed malicious. Therefore, all customers of the updater can immediately block the updater and prevent any malicious access to their accounts.

More in-depth lightweight deployment

Nomad is designed around many of the core principles of existing OP systems. Without validators, Nomad is deployed as a smart contract between two chains, with lightweight sub-chain components. The agreement looks at the proof of the data and accepts it as valid after a given period of time. Honest participants had the opportunity to respond to the certificates and submit fraud certificates during the time-out period. Unlike most optimistic systems, however, Nomad spans multiple chains. While this provides more functionality and interoperability to the protocol, it adds an additional layer of complexity and risk.

Nomad attempts to mitigate these risks directly through its system design. More specifically, the chain that sends the message is considered to be the source of the facts. This chain contains the“Master” protocol for message queuing. The message is submitted to the Merkle tree, and the root of the tree is authenticated by the updater. The updater then relays the message to the receive chain in update. These updates are signed by the updater and committed to the previous and new roots.

Basically, any chain can maintain a“Copy” contract. This copy contains knowledge of the updater and the current root. Therefore, it can be considered as a source of truth at a particular time. The signed update is sent to and held by the replica contract and is accepted as true after a timeout. The copy effectively replays a series of updates to reach the same root directory as the main chain. Because the root commits to the message tree, once the root is transferred in this manner, the message can be proven and processed.

This leads to one of Nomad’s most important features. The replica protocol relies heavily on the updater to constantly verify new messages and ensure that they are indeed true. The assumption here is that the update itself is acting as it should. However, the updater may choose to act dishonestly and sign a fraudulent update. Nomad actually allows fraud. Therefore, Nomad’s security model is fundamentally different from the optimistic aggregate security model, which does not allow for fraud. Under Nomad’s design, update program fraud can always be traced back to the family contract in the sending chain and verified as fraud. Therefore, the update program must always submit a bonded interest in the send chain. Eventually, the fraud can be traced back to the household chain, and once confirmed, the bonds of the updater are cut. As a result, there is a powerful mechanism that enables agents to objectively identify fraud and punish bad actors.

Nomad’s security model makes it almost impossible to hide fraud. It is true that there are certain types of fraud that can not be objectively proven on the receiving chain, because the replica chain can not know what messages the Home chain is going to send, so the Merkle tree can not be checked in all cases. However, if the updater sends a fraudulent message to the replica chain, the update is public, which allows anyone in the ecosystem to challenge it as fraudulent, and by referring to the family contract to objectively prove that it is fraudulent. As a result, the Updater’s binding to the home chain will be cut.

Messages are sent as raw bytes between chains, so an application using Nomad must define rules for sending and receiving messages. Each cross-chain application must implement its own messaging protocol, and each messaging protocol is implemented by a router protocol. In short, these router protocols function like routers in a local network and ensure that all incoming and outgoing messages are indeed in the protocol-defined format. The router contract is also used to manage a set of license contracts on the remote chain from which to receive messages from Nomad that must be encoded in a standardized format on the main chain, so that they can be decoded by the router contract on the target chain, and they process and schedule messages from the remote router contract.

These capabilities, embedded in each router contract, allow them to deploy freely across multiple chains and still communicate with each other because they all share a common language and a common set of rules. In addition, these router contracts support cross-chain applications that use Nomad to act as wizards to send and receive messages to each other.

What does a universal cross-link communication protocol need to achieve?

Over the past year, a number of new layer 1(L1) protocols have emerged with great success. Projects like Solana, Avalanche, Near, and Polygon have gained significant traction, providing an active ecosystem of decentralized applications (Dapps) , developers, and retail users.

Although there has been a considerable increase in L1 activity, most ecosystems lack native interoperability. Instead, they rely on third-party development of the bridge to achieve cross-chain interaction. A key risk is that these bridges are often built in haste and could contain serious security breaches, as evidenced by the more than $1 billion lost in bridge hacking over the past year. Without these bridges, however, users of a given ecosystem are essentially relegated to that particular space and can not easily interact with another ecosystem, for example, sending local funds across chains or interacting with non-native applications.

This lack of interoperability has become a common problem across the field and a bottleneck for user and developer activity. Nomad has developed a base layer for cross-chain communication networks, attempting to address these issues by providing fast, scalable, and inexpensive messages for all intelligent contract chains and aggregations. Basically, any L1 or L2 that supports user-defined computing can take advantage of Nomad to achieve optimized output. This creates considerable interoperability between different blockchains and improves existing ORU solutions, examples include reducing the latency to 30 minutes (one week compared to most ORU latency) and reducing the gas overhead of the sender of the message.

Thus, Nomad enables applications to be deployed effortlessly on many different chains and constitute liquidity and state, no matter where it comes from, while the end user benefits from low latency and cheap transactions. Nomad also uses familiar tools to make it more composable and to reduce the barriers to entry for developers, including Solidity of up-chain contracts and Rust of down-chain agents. Both are widely used.