Blockchain Interoperability is defined according to the National Institute of Standards and Technology (NIST) as: “a composition of distinguishable blockchain systems, each representing a unique distributed data ledger, where atomic transaction execution may span multiple heterogeneous blockchain systems, and where data recorded in one blockchain are reachable, verifiable, and referable by another possibly foreign transaction in a semantically compatible manner”.

The validating bridge contract is tasked with protecting the integrity of the widely replicated database and liveness such that a proposed state update will eventually be applied to the database.

– Off-chain system A system with its own appointment protocol, smart contract environment, and a widely replicated database that anyone can independently recompute.

– Chain of commitments (commitchain) Periodic commitments about the off-chain system’s database state and the bridge must be convinced that all state updates to the database are valid before it can accept a new commitment.

Agents We assume there is an honest user who wants to transact on the off-chain system and they lack the computational resources to verify it in real-time. Figure 1 identifies three agents when assessing the security of a validating bridge:

– Sequencer One or more agents who propose an ordered list of transactions to the bridge contract. They are privy to the pending transactions that will soon be confirmed and are in a position to offer information about the pending state of the off-chain system’s database (including account balances, smart contract state, etc).

– Executor One or more agents who propose the final execution result for a batch of transactions by posting state commitments to the bridge contract.

– Challenger One or more agents with the computational resources to validate commitments proposed by the executors. This requires the agent to process every state update to the widely replicated database and this role is only required if the validating bridge requires assistance.

Nomad contains several on-chain and off-chain components. For convenience, we’ll be referring to the Home and Replica as contracts, when in fact they are several contracts working together.

The home contract is responsible for managing production of the message tree and holding custody of the updater bond.

It performs the following functions:

• Expose a "send message" API to other contracts on the home chain

• Enforce the message format

• Commit messages to the message tree

• Maintain a queue of tree roots

• Slash the updater's bond

  • Double-update proofs

  • Improper update proofs

The replica contract is responsible for managing optimistic replication and dispatching messages to end recipients.

It performs the following functions:

• Maintain a queue of pending updates

• Finalize updates as their timeouts elapse

• Accept double-update proofs

• Validate message inclusion proofs

• Enforce the message format

• Ensure messages are processed in order

• Dispatch messages to their destination

The updater is responsible for signing attestations of new roots.

It is an off-chain actor that does the following:

• Observe the home chain contract

• Sign attestations to new roots

• Publish the signed attestation to the home chain

The watcher observes the Updater's interactions with the Home contract (by watching the Home contract) and reacts to malicious or faulty attestations. It also observes any number of replicas to ensure the Updater does not bypass the Home and go straight to a replica.

It is an off-chain actor that does the following:

• Observe the home

• Observe 1 or more replicas

• Maintain a DB of seen updates

• Submit double-update proofs

• Submit invalid update proofs

• If configured, issue an emergency halt transaction

The relayer forwards updates from the home to one or more replicas.

It is an off-chain actor that does the following:

• Observe the home

• Observe 1 or more replicas

• Polls home for new signed updates (since replica's current root) and submits them to replica

• Polls replica for confirmable updates (that have passed their optimistic time window) and confirms if available (updating replica's current root)

The processor proves the validity of pending messages and sends them to end recipients.

It is an off-chain actor that does the following:

• Observe the home

• Maintain local merkle tree with all leaves

• Observe 1 or more replicas

• Maintain list of messages corresponding to each leaf

• Generate and submit merkle proofs for pending (unproven) messages

• Dispatch proven messages to end recipients

Nomad sends messages from one chain to another in the form of raw bytes. A cross-chain application that wishes to use Nomad will need to define the rules for sending and receiving messages for its use case.

Each cross-chain application must implement its own messaging protocol. By convention, we call the contracts that implement this protocol the application's Router contracts. Their function is broadly similar to routers in local networks. They ensure that incoming and outgoing messages are in the protocol-defined format, and facilitate handling and dispatch.

These Router contracts must:

• maintain a permissioned set of the contract(s) on remote chains from which it will accept messages via Nomad — this could be a single owner of the application on one chain; it could be a registry of other applications implementing the same rules on various chains

• encode messages in a standardized format, so they can be decoded by the Router contract on the destination chain

• handle messages from remote Router contracts

• dispatch messages to remote Router contracts

  By implementing these pieces of functionality within a Router contract and deploying it across multiple chains, we create a working cross-chain application using a common language and set of rules. Applications of this kind may use Nomad as the cross-chain courier for sending and receiving messages to each other.

This is not an article which is conducted by me or anyone else. You can see most of the information from the document page of Nomad project.

https://docs.nomad.xyz/

Blockchain Interoperability is defined according to the National Institute of Standards and Technology (NIST) as: “a composition of distinguishable blockchain systems, each representing a unique distributed data ledger, where atomic transaction execution may span multiple heterogeneous blockchain systems, and where data recorded in one blockchain are reachable, verifiable, and referable by another possibly foreign transaction in a semantically compatible manner”.

The validating bridge contract is tasked with protecting the integrity of the widely replicated database and liveness such that a proposed state update will eventually be applied to the database.

– Off-chain system A system with its own appointment protocol, smart contract environment, and a widely replicated database that anyone can independently recompute.

– Chain of commitments (commitchain) Periodic commitments about the off-chain system’s database state and the bridge must be convinced that all state updates to the database are valid before it can accept a new commitment.

Agents We assume there is an honest user who wants to transact on the off-chain system and they lack the computational resources to verify it in real-time. Figure 1 identifies three agents when assessing the security of a validating bridge:

– Sequencer One or more agents who propose an ordered list of transactions to the bridge contract. They are privy to the pending transactions that will soon be confirmed and are in a position to offer information about the pending state of the off-chain system’s database (including account balances, smart contract state, etc).

– Executor One or more agents who propose the final execution result for a batch of transactions by posting state commitments to the bridge contract.

– Challenger One or more agents with the computational resources to validate commitments proposed by the executors. This requires the agent to process every state update to the widely replicated database and this role is only required if the validating bridge requires assistance.

Nomad contains several on-chain and off-chain components. For convenience, we’ll be referring to the Home and Replica as contracts, when in fact they are several contracts working together.

The home contract is responsible for managing production of the message tree and holding custody of the updater bond.

It performs the following functions:

• Expose a "send message" API to other contracts on the home chain

• Enforce the message format

• Commit messages to the message tree

• Maintain a queue of tree roots

• Slash the updater's bond

  • Double-update proofs

  • Improper update proofs

The replica contract is responsible for managing optimistic replication and dispatching messages to end recipients.

It performs the following functions:

• Maintain a queue of pending updates

• Finalize updates as their timeouts elapse

• Accept double-update proofs

• Validate message inclusion proofs

• Enforce the message format

• Ensure messages are processed in order

• Dispatch messages to their destination

The updater is responsible for signing attestations of new roots.

It is an off-chain actor that does the following:

• Observe the home chain contract

• Sign attestations to new roots

• Publish the signed attestation to the home chain

The watcher observes the Updater's interactions with the Home contract (by watching the Home contract) and reacts to malicious or faulty attestations. It also observes any number of replicas to ensure the Updater does not bypass the Home and go straight to a replica.

It is an off-chain actor that does the following:

• Observe the home

• Observe 1 or more replicas

• Maintain a DB of seen updates

• Submit double-update proofs

• Submit invalid update proofs

• If configured, issue an emergency halt transaction

The relayer forwards updates from the home to one or more replicas.

It is an off-chain actor that does the following:

• Observe the home

• Observe 1 or more replicas

• Polls home for new signed updates (since replica's current root) and submits them to replica

• Polls replica for confirmable updates (that have passed their optimistic time window) and confirms if available (updating replica's current root)

The processor proves the validity of pending messages and sends them to end recipients.

It is an off-chain actor that does the following:

• Observe the home

• Maintain local merkle tree with all leaves

• Observe 1 or more replicas

• Maintain list of messages corresponding to each leaf

• Generate and submit merkle proofs for pending (unproven) messages

• Dispatch proven messages to end recipients

Nomad sends messages from one chain to another in the form of raw bytes. A cross-chain application that wishes to use Nomad will need to define the rules for sending and receiving messages for its use case.

Each cross-chain application must implement its own messaging protocol. By convention, we call the contracts that implement this protocol the application's Router contracts. Their function is broadly similar to routers in local networks. They ensure that incoming and outgoing messages are in the protocol-defined format, and facilitate handling and dispatch.

These Router contracts must:

• maintain a permissioned set of the contract(s) on remote chains from which it will accept messages via Nomad — this could be a single owner of the application on one chain; it could be a registry of other applications implementing the same rules on various chains

• encode messages in a standardized format, so they can be decoded by the Router contract on the destination chain

• handle messages from remote Router contracts

• dispatch messages to remote Router contracts

  By implementing these pieces of functionality within a Router contract and deploying it across multiple chains, we create a working cross-chain application using a common language and set of rules. Applications of this kind may use Nomad as the cross-chain courier for sending and receiving messages to each other.

This is not an article which is conducted by me or anyone else. You can see most of the information from the document page of Nomad project.

https://docs.nomad.xyz/