Summary
Nomad is a generalized cross-chain communication protocol that allows users to securely build applications and transfer digital assets across different blockchains. Its core design is centered around traditional optimistic rollup (ORU) mechanisms, but with a novel security model. Therefore, Nomad has public verification, low gas fees, and broad participation. Unlike ORUs, however, Nomad leverages a locally verifiable fraud-proof and operates across many different chains. The protocol utilizes these features to provide fast, inexpensive, and secure communication for all smart contract chains and rollups.
Overview
Many new Layer 1 (L1) protocols have emerged to achieve massive success over the last year. Projects such as Solana, Avalanche, Near, and Polygon have all gained significant traction, offering active ecosystems full of decentralized applications (dapps), developers, and retail users. While L1 activity has grown considerably, most ecosystems lack native interoperability. Instead they rely on bridges developed by third-parties to enable cross-chain interactions. A key risk is that these bridges are often built in haste and can contain serious security vulnerabilities, as evidenced by the over $1B lost in the past year in bridge hacks. Without these bridges, however, users of a given ecosystem are essentially relegated to that particular space and cannot easily engage with another ecosystem, such as sending native funds across chains or interacting with non-native applications. This lack of interoperability has become a common problem throughout the space and is a bottleneck for user and developer activity.
Nomad has developed a base layer for a cross-chain communication network that attempts to resolve these issues by providing fast, scalable, inexpensive messaging for all smart contract chains and rollups. Essentially any L1 or L2 that supports user-defined computations can utilize Nomad to achieve optimized output. This creates considerable interoperability between different blockchains and improves upon existing ORU solutions, such as shortening latency to thirty minutes (compared with a latency of one week in most ORUs) and lower gas overhead on message senders. So Nomad enables applications to be deployed effortlessly across many different chains, and compose liquidity and state regardless of where it originated, while end users benefit from low latency and cheap transactions. Nomad also leverages familiar tooling to make it more composable and with less barriers of entry to developers, including Solidity for on-chain contracts and Rust for off-chain system agents. Both of which are widely used.
Core Features
xApps are a key component of Nomad and function as cross-chain applications that can be built and securely deployed to virtually any blockchain. xApps are natively interoperable and allow users to seamlessly bridge assets between different chains, such as the protocol's flagship xApp, the Nomad token bridge. The bridge is just one of many xApps built on top of Nomad's messaging channels. Other xApps such as NFT bridges, cross-chain lending protocols, and cross-chain order books can be built on top of Nomad channels.
xApps help break through some of the limitations and confinements of traditional decentralized applications, which by nature, are limited to their native chain and require significant workarounds to communicate and send assets to other chains. In order to effectively build these xApps, Nomad has developed Routers. In short, Routers serve as the framework that enables developers to deploy xApps to any existing cross-chain channel without friction.
Another core feature of Nomad is its novel security model. Nomad, by design, does not include light clients. So no validators or blockchain, but instead the protocol functions as a deployment of smart contracts between two chains with an off-chain component. This in turn means that the protocol also does not include formal security. This approach allows Nomad to achieve significant benefits in terms of simplicity and operating costs, but with the tradeoff that it will not be provably secure. In order to overcome this, Nomad is instead designed to be secure in practice. Nomad’s core channel relies on fraud proofs and proof of publication to prevent channel failure. It also utilizes a system of network watchers by which users and applications delegate to in order to monitor fraud. This approach helps shore up Nomad’s system design in a way to protect it from critical attack vectors and mitigates its lack of provable security.
How it Works: Notary Framework
A quick overview of how Nomad works can be thought of in the context of a notary:
The Home Chain sends documents (messages), and these need to be validated and signed by a notary (Updater).
These Messages are then passed to an Updater.
The Updater acts similarly to a notary and is contracted to sign the messages and confirm their authenticity.
The Updater can attempt to game the system by producing a fraudulent copy of the message. However, if they are caught then their bond is slashed and their Updater privilege on the network is revoked.
In the event of such malicious gaming, the network is alerted and learns that the Updater is indeed malicious. As a result, all of the Updater’s customers can immediately block the Updater and prevent any malicious access to their accounts.
Deeper Dive
Nomad is designed around many of the core tenets of existing optimistic systems. There are no validators and Nomad is deployed as smart contracts between two chains with a lightweight off-chain component. The protocol sees an attestation of data and accepts it as valid after a given amount of time elapses. Honest participants have a chance to respond to the attestation and submit fraud proofs during a timeout period. Unlike most optimistic systems, however, Nomad spans multiple chains. While this gives the protocol more functionality and interoperability, it also adds additional layers of complexity and risk.
Nomad attempts to mitigate these risks directly through its system design. More specifically, the chain sending the message is considered the source of truth. This chain contains the “Home” contract where messages are enqueued. Messages are committed to a merkle tree, and the root of this tree is authenticated by the Updater. The Updater then relays the message to the receiving chain in an “update”. These updates are all signed by the Updater, and they commit to the previous root and a new root.
Essentially any chain can maintain a “Replica” contract. This Replica holds knowledge of the Updater and the current root. So it can be considered a source of truth at a given time. Signed updates are sent to and held by the Replica contract, and accepted as true after a timeout. The Replica effectively replays a series of updates to reach the same root as the Home chain. Because the root commits to the message tree, once the root has been transmitted this way, the message can be proven and processed.
This leads us to one of the most important features of Nomad. Replica contracts critically rely on Updaters to continuously validate new messages and vouch that they are indeed truthful. The assumption here is that the Updaters themselves are acting truthfully. However, Updaters may choose to act dishonestly instead, and sign fraudulent updates. Nomad actually permits fraud. So the security model of Nomad is fundamentally different from an optimistic rollup security model which does not permit fraud. Under Nomad’s design, Updater fraud can always be traced back to the Home contract on the sending chain and verified to be fraudulent. As a result, Updaters must always submit a bonded stake on the sending chain. Ultimately, fraud is traced back to the Home chain at which point once it is confirmed, the Updater’s bond is slashed. So there is a strong mechanism in place which enables agents to objectively determine fraud and punish bad actors.
Nomad’s security model makes it virtually impossible to hide fraud. There are indeed certain types of fraud that cannot be objectively proven as such on the receiving chain, since the Replica chain cannot know which messages the Home chain intended to send and therefore cannot check the merkle tree in all cases. However, if an Updater sends a fraudulent message to the Replica chain, that update is public, and this allows anyone in the ecosystem to challenge it as fraudulent and objectively prove it as such by referencing the Home contract. As a result, the Updater’s bond on the Home chain will be slashed.
The other component of Nomad’s security model is that there is an intentional latency in Replica chains processing messages. This allows honest agents to detect and prevent fraud. This helps guarantee that honest dApps can always prevent processing fraudulent messages. Again, fraud is always public knowledge on Nomad before the fraudulent message is processed. And Nomad requires that honest users stay online (while the updates are being vetted).
All off-chain observers can check the Home chain and be immediately convinced of fraud. So the validity of a message sent by Nomad is not 100% guaranteed. Instead, Nomad has designed a system in which fraud is costly; all users can detect a fraud (by referencing the Home chain); all users can block a fraudulent message before it is accepted. In this manner, Nomad doesn’t use a globally verifiable fraud-proof and instead has designed a system in which fraud detection relies on local verification by participants. Fraud is extremely costly, all users can learn about fraud, and all users can block a fraudulent message before they are accepted. This tradeoff between globally verifiable fraud-proof and local verification allows Nomad to save 90% on gas fees compared to pessimistic relays, while still maintaining a high degree of security.
Passing Messages Between Chains
Nomad initiates this process by building an authenticated merkle tree data structure on a given home chain. Any updates to that tree are then relayed to replica chains. This creates a system in which the home chain and any number of existing replicas share and agree upon the true state of the data structure. So they are all in continuous agreement. The home chain enforces all of the rules on the creation of the merkle tree.
This tree commits all of the previous messages and the home chain enforces the messages and calculates the tree root. Ultimately, the root will be sent and installed to the replica chains, and the home chain maintains a queue of roots.
The home chain elects an "updater" that validates the state of the message tree. The updater stakes a bond on the home chain and periodically validates and updates data. In the event of conflicting data, the home chain can slash the updater’s bond for fraud.
Before being accepted as true, however, each update must undergo a challenge period. So a replica places each update into a queue and each update must wait for some time parameter before being accepted. The waiting system guarantees that fraud is publicly visible on the home chain before being accepted by the replica. In other words, the security guarantee of the system is that all frauds may be published by any participant, all published frauds may be slashed, and all participants have a window to react to any fraud. Therefore updates that are not blacklisted by participants are sufficiently trustworthy for the replica to accept.
Cross-Chain Communication Channels
Messages are sent between chains in the form of raw bytes so applications that use Nomad must define the rules for sending and receiving messages as such. Each cross-chain application must implement its own messaging protocol, and each messaging protocol is implemented by Router contracts. In short, these Router contracts function similarly to routers in local networks and ensure that all incoming and outgoing messages are indeed in the protocol-defined format. Router contracts also function to manage a permissioned set of the contracts on remote chains from which it will accept messages via Nomad, they must encode messages in a standardized format on the home chain, so they can be decoded by the Router contract on the destination chain, and they handle and dispatch messages from remote Router contracts
These functionalities embedded within each Router contract allow them to be freely deployed across multiple chain and still be able to communicate with each other since they all share a common language and common set of rules. Moreover, the cross-chain applications that these router contracts support can leverage Nomad to act as the courier for sending and receiving messages to each other.
Mechanism Design and Tokenomics
Currently there is no token for Nomad, however there are a few key objective functions for which a token may be a good fit:
Rewarding Updaters for correctly sending messages
Method of staking bond and enforcing slashing
Method of incentivizing network watcher volume and activity
These mechanisms could help reinforce some of the protocol's potential vulnerabilities, such as sufficiently preventing instances in which an Updater attempts to pass forged messages and voluntarily forfeits bond.
Macro View
One concern with Nomad’s approach is their security model. While shifting from a globally verifiable fraud-proof system to a local verification system does improve network efficiency significantly and results in considerable cost savings for end users, it also comes with inherent risk. Relying on local users to detect fraud can be powerful in theory, but not in practice. On a very fundamental level the incentive structure for such a system to work must be strong enough to attract not only a sufficient number of network watchers to actively monitor millions of transactions across many different chains, but they must also have the skill and wherewithal to properly monitor the network. One possibility is that while the reward for fraud proof is quite attractive (e.g. 100% of the operator’s bond is given to the watcher), the end result is that only a handful of good watchers actually participate in the network. So Nomad must rely on the wherewithal of a select few.
Another related concern is around the frequency of fraud surveillance. This begs the question of whether watcher agents are constantly monitoring the system and checking every transaction and not just a select subset. Finally, Nomad must ensure that liveness persists in the event of Updater failure. This goes back to mechanism design and creating the proper incentive (and disincentive) structures for keeping Updaters active and online.
Further Reading and Sources
https://blog.nomad.xyz/the-nomad-design-philosophy-6fc0eacf3263
https://blog.nomad.xyz/nomad-raises-22m-seed-round-for-security-first-interoperability-5d6b15c96007
https://www.wired.com/story/blockchain-network-bridge-hacks/
Cryptofunds, market makers, and trading desks can interact with these DeFi protocols with MetaMask Institutional
MetaMask Institutional offers unrivalled access to the DeFi ecosystem without compromising on institution-required security, operational efficiency, or compliance. We enable funds to trade, stake, borrow, lend, invest, and interact with over 17,000 DeFi protocols and applications.
Learn more about MetaMask Institutional
Found this research useful? Connect with the Consensys Cryptoeconomic Research team at [email protected]
Return to the Cryptoeconomic Research Library
Consensys Software Inc. is not a registered or licensed advisor or broker. This report is for general informational purposes only. It does not constitute or contain any individual investment advice and is made without any regard to the recipient's objectives, financial situation, or means. It is not an offer to buy or sell, or a solicitation of any offer to buy, any token or other investment, nor is it intended to be used for marketing purposes to anyone in any jurisdiction. Consensys does not intend for any person or entity to rely on any facts, opinions, or ideas, and any financial or economic commentary expressed in this report may not be relied upon. Consensys makes no representations as to the accuracy, completeness, or timeliness of the information or opinions in this report and, along with its employees, does not assume any responsibility for any loss to any person or entity that may result from any act or omission based upon this report. This report is subject to correction, completion, and amendment without notice; however, Consensys has no obligation to do so.