Introduction

Architecture of the Crosschain Protocol Stack

The architecture of the crosschain interoperability stack provides a standardized framework to enable secure and seamless communication across diverse blockchain and/or DLT networks. It consists of a modular, plug-and-play architecture spanning three layers - Crosschain Applications, Crosschain Function Calls, and Crosschain Messaging. The layered architecture allows for the integration of components from different vendors, serving as a robust infrastructure for an array of crosschain applications.

• The Crosschain Messaging layer facilitates secure exchange of data and events between networks, ensuring the integrity and validity of information passing between them. This is the communication backbone, ensuring that events generated on one network can be trusted on another. This layer is foundational to the trustless nature of DLTs, providing the mechanisms for verification and validation of events across different networks without the need for a centralized authority.
• The Crosschain Function Calls layer enables execution of operations across networks, allowing crosschain applications to trigger and coordinate activities on multiple networks. This is the operational core of the stack, enabling functions to be executed remotely on another network. This capability is crucial for allowing synchronous workflows across networks in scenarios where actions on one network depend on the state or outcomes on another. It is this layer that orchestrates the remote execution of smart contract functions, ensuring that transactions are not only executed but done so in a manner that aligns with the overarching business logic defined in the applications layer.
• The Crosschain Applications layer harbors business logic and use case-specific functionality. This is where the complex operations of enterprise applications are defined and managed.

Figure 1: Crosschain Protocol - Layered Architecture

Together, these three layers form a protocol stack that is robust, versatile, and capable of addressing the complex needs of modern enterprises. By adhering to the Distributed Ledger Technology Interoperability Specification defined by the Enterprise Ethereum Alliance (EEA), the protocol stack ensures that the components are not only interoperable but also scalable and secure. The EEA’s specification is a formal definition of the implementation requirements for Enterprise Ethereum clients to achieve secure and scalable crosschain communications.

The primary focus of the current specification is on Ethereum Virtual Machine (EVM) compatible blockchains, reflecting the widespread adoption and development within the Ethereum ecosystem. The specification is however implementable and compatible with other architectures, such as ZKP compatible networks and R3 Corda, where network state updates can be verified with an EEA-compliant proof. This broad-minded approach indicates a commitment to future-proofing interoperability standards and catering to an evolving digital ecosystem.

Crosschain Messaging Layer

The Crosschain Messaging layer establishes the critical information infrastructure to enable trusted interoperation between blockchain or DLT networks.

This section describes the required protocols, message formats, and mechanisms for one network to prove the integrity and authenticity of data to another. This includes specifics around event-based, state-based, and transaction-based messaging to cater to diverse crosschain information exchange requirements. Additionally, the section covers format standards for crosschain proofs and considerations for secure transmission of verified data between networks.

Crosschain message relays

This section describes various mechanisms through which messages are relayed from one blockchain to another, ensuring that the information can be trusted. This is fundamental to the operation of crosschain functions because the reliability and security of crosschain operations depend on the integrity of the message relay methods.

Understanding the strengths and weaknesses of various approaches is setting an important context for later understanding the technical requirements around event-based, state-based, and transaction-based messaging.

• Multisig relay: a mechanism that leverages multi-signature consensus for relaying messages across blockchains. In this approach, the message originating from a source chain is cryptographically signed by multiple independent relay nodes. These relay nodes or validators have public key signatures that are registered and verified against a whitelist of trusted nodes maintained on the target chain's smart contract. The relay nodes' signatures on the message are aggregated and attached to the communication payload sent from the source chain to the smart contract on the target chain. The target chain's smart contract first verifies that the aggregate signature comprises valid signatures from a threshold number of trusted relayers according to the whitelist. This blockchain-based consensus check establishes multiple attestations of the message's authenticity and integrity. If the multi-signature passes the policy set on the target chain, the message is deemed to have originated genuinely from the source system and can be processed and trusted accordingly by the target chain. By decentralizing the act of relaying through multiple participating validators and embedding multi-signature thresholds on target chains, multisig message relay aims to provide stronger security, availability and integrity assurances for crosschain messaging.
• MPC (Multi-Party Computing) relay: differs from multisig in that it involves only a single relay address affiliated with the relaying activity between networks. This relay address does not have access to the full private key - instead the private key is shared into segments and distributed in a cryptographically secure manner among a set of MPC nodes. These nodes engage in secure multi-party computation protocols to jointly sign messages sent from the relay address without any node revealing its share of the private key. By having at least a threshold of MPC nodes participate in approving the transmission of crosschain messages, the system can replicate the authentication assurances of a valid digital signature without a single privileged entity. The relay address is configured on the target chain and trusted to send messages from the source system. The target chain smart contract does not need to hold a whitelist of trusted relayers as in multisig – rather the relaying participants and business logic are abstracted behind the single relay address governed by decentralized MPC protocols. This approach balances both security as well as efficiency goals for crosschain messaging.
• ZKP (Zero Knowledge Proof) relay: a mechanism that utilizes modern cryptographic proof constructions to validate integrity of crosschain messages without revealing actual content. There are two main approaches - SNARKs (Succinct Non-Interactive Arguments of Knowledge) and STARKs (Scalable Transparent Arguments of Knowledge). In SNARK-based relay, parameters are precomputed among the underlying ZKP system partners to optimize proof generation efficiency. This however necessitates a trusted setup ceremony. In STARK-based relay, the proofs do not rely on any fixed reference string or parameters and hence don't need trusted setup. The ZKP prover computes a proof attesting to authenticity of the crosschain message and transmits this proof to a smart contract on the target chain. The target chain verifies the proof based on its policy to determine if the message originated genuinely from the source system. ZKP relay enhances privacy while enabling target chain participants to still definitively verify integrity of messages. By both eliminating message content exposure as well as third party relayers, it enhances security properties, albeit currently SNARKs pose setup challenges and STARKs have high computation overhead.
• Oracle relay: a mechanism that leverages external trusted nodes called oracles for bridging information between chains. Dedicated oracle smart contracts are first deployed on the target chain to handle incoming messages. Oracle nodes run independent off-chain server infrastructure that retrieves data and events from the source system through custom integrations. They collate this external information into standard formats understandable by the oracle contract on the target side. The oracle nodes transmit batched communications to the oracle contracts, which in turn expose APIs for other on-chain smart contracts to access the bridged data. This facilitates target side consumption of verified external data. The model operates through a trust-based federation of oracle nodes which follow expected security practices. By moving the message relaying to dedicated infrastructure operators who stitch source and target chains via custom software, a high degree of flexibility and efficiency is achieved. However lack of decentralization and use of trusted nodes implies some security assumptions for oracle relay versus other peer-to-peer messaging approaches between chains.
• Light Client relay: a method that involves configuring light clients on the source and target blockchains to enable direct crosschain message transmission leveraging simplified payment verification protocols. In this model, light clients containing current chain headers and consensus rules are instantiated on both sides. The target chain's light client can independently retrieve raw messages from the source system and verify integrity based on header proofs. This allows the target chain to confirm up-to-date state of transactions and events on the source without fully synchronizing the chain or relying on intermediaries. Light client architecture offers low storage requirements and sync times while still providing security inherited from the underlying blockchain.
• Hybrid relay: a method that method combines multiple crosschain messaging mechanisms to enhance security assurances for bridged communication between chains. It creates two separate relaying pathways for source messages to reach the target chain. For example, the hybrid approach may use an oracle cluster to relay the full message payload with bindings to off-chain anchors and a separate ZKP-based relay to prove cryptographic integrity without revealing contents. The target chain smart contract implements policies checking for payload validity via the oracle channel and proof validation via the ZKP channel. By relaying through multiple modes, adversarial compromisation of any single relay mechanism does not undermine the collective trust assurances. Attackers would need to break both pipelines simultaneously to disrupt message delivery guarantees. While more complex to operate, hybrid relay compensates via defense-in-depth against both infrastructure as well as cryptographic relay attacks. The security benefits exceed standalone relaying, albeit at the expense of more integration effort and technical overhead for bridging systems.

Crosschain message definition

A crosschain message can be categorized, based on the underlying network characteristic, as listed below:

• Event-based: Message payloads are identified with events emitted from the source network.
As an example, a trade finance blockchain application emits an event when an invoice is approved indicating accounts receivable. This event can relay the invoice details to an accounting system network to automatically update the company's revenue recognition ledger. The crosschain message is identified with a specific event emitted on the trade finance platform when the invoice was approved.
• State-based: Message payloads are identified with source network state updates.
As an example, an enterprise supply chain blockchain tracks inventory levels across warehouses and emit state updates when goods receipt/dispatch occurs. These inventory state updates can relay to a procurement blockchain where smart contracts manage automated supplier purchase order generation and payments. The crosschain message reflects updated warehouse inventory levels based on state changes in the supply chain platform to trigger procurement workflows.
• Transaction-based: Message payloads are identified with transactions executed on the source network.
As an example, an enterprise private blockchain network processes private transactions for tokenized asset transfers representing fund movements for quarter end reporting. Digests of completed transactions can relay to a public regulatory ledger to meet regulatory audit requirements while preserving transaction privacy.

Crosschain verifier interface

        

        
          pragma solidity >=0.8;
          interface ICrosschainVerifier {
            function decodeAndVerify(
              uint256 networkId,
              bytes calldata encodedInfo,
              bytes calldata encodedProof
            ) external view returns (
              bytes memory decodedInfo
            );
          }
        
        
      

The function decodeAndVerify is used to decode and verify message information originating from different networks.

Parameters:

• networkId (required): Identification of the source network where the message originated. This can be used to determine the applicable verification scheme.
• encodedInfo (required): ABI-encoded message containing event, state or transaction data that needs to be decoded and verified according to the message category.
• encodedProof (required): ABI-encoded proof information and/or signatures that an implementation can use to verify the information given in encodedInfo. The sections below detail the format of this value.

Returns:

• decodedInfo: The decoding scheme specific data as decoded from encodedInfo and attested to by encodedProof.

The function (optionally) returns decoded information for practical purposes. To improve efficiency and to avoid another smart contract call to a verifier contract implementation that performs scheme specific decoding of event data.

If the verification fails for any reason, the verification failure must prevent any state changes from occurring.

Some example failure cases requiring a transaction revert are:

• Encoded data cannot be properly decoded
• Decoded data fails defined validation rules
• Provided cryptographic proofs are not valid
• Any other invalid criteria according to the verification scheme

Event-based messaging mechanism

In an EVM-based environment, event attestation is a process that utilizes the block header's receipt root to prove that events occurred within that particular block. This receipt root is a cryptographic commitment to the list of transaction receipts, which in turn contain the smart contract event logs. The event data would typically contain information to trigger an action on the destination network.

Event-based Verification

Whenever a smart contract emits an event on the source network, the associated log data is written and recorded in a transaction receipt. Receipts are hashed and represented as leaves in a Merkle tree of which root is called the receipt root. This receipt root is included in each block header and used when verifying Merkle tree membership of a specific receipt containing a specific event log. This serves as a reliable way to prove that an event has indeed been emitted on the source network.

A verifying smart contract, designed to handle crosschain messages, deployed on the destination network can use this event data to execute a corresponding operation after verifying the authenticity of the event. The verifying contract will perform a validation check, by means of a Merkle inclusion proof, to verify that the event data is part of a transaction receipt that corresponds to a receipt root in a block header that the destination network recognizes as valid. This process ensures that only verified events from the source network can trigger actions on the destination network.

Event-based Interface

Parameters:

• networkId (required): Identification of the source network that emitted the event. This can be used to determine the verification scheme or to enforce the EIP 3220 format for EVMs.
• encodedInfo (required): Packed ABI-encoding of the local network identifier (networkId), the local contract address (contractAddress) and the remote event data (eventData) to be verified.
• encodedProof (required): ABI-encoded proof information and/or signatures that an implementation can use to verify the information given in eventData. The sections below detail the format of this value.

Returns:

• decodedInfo: The decoding scheme specific data as decoded from encodedInfo. This can contain the verified local network identifier, contract address and function call data as decoded and interpreted from the given verifiable eventData, if the next action to be taken is a remote function call.

Event Attestation

The process for using event attestation in the Crosschain Messaging Protocol can be summarised as follows.

1. The Crosschain Function Call contract on the source network emits an event. The circumstances in which an event is emitted and the meaning of the event are Crosschain Function Call protocol dependant. This event can then be verified on one or more target networks.
2. Relayer nodes observe the network, for events being emitted by the Crosschain Function Call contract. Once an event is observed, they can either sign the event and store it locally, or wrap the event with a block header Merkle proof before sending it to the target network for verification.
3. The Crosschain Function Call SDK can be used to observe the network for events being emitted by the Crosschain Function Call contract. When an event is observed, it needs to be wrapped up with a proof so that it can be verified on another network. It can call the Crosschain Messaging Layer SDK to fetch signed events from relayers and combine them as a single, signed object. The number of signatures that need to be combined will depend on the threshold signature scheme for the source network. It can alternatively call the Crosschain Messaging Layer SDK to construct a block header proof around the event making use of validator signatures on the source network.
4. The Crosschain Function Call SDK can be used to submit a transaction to the target network, calling the Crosschain Function Call contract, supplying the event and proof that it occurred. The Crosschain Function Call contract calls the Crosschain Messaging contract, for the given source network, invoking decodeAndVerify. This call verifies that the event information did come from the source network and that the event data can be trusted. Actions taken after decoding and verifying the message are Crosschain Function Call protocol dependant.

State-based messaging mechanism

For EVM-based networks, state-based messaging relies on the state root in block headers to prove the current state of the source network. By conveying state roots for particular blocks alongside expected state data encodings, the destination network can verify specific account balances, contract variables, or other on-chain data stored in the source network's state tree.

For networks using ZKPs, state updates can be attested through computationally verifiable proofs validating changes to the network state. The ZKP prover can succinctly demonstrate a particular account balance or contract storage value transitioned to an expected amount from a previously verified state, while keeping state data opaque.

State-based Verification

Block header proofs for state-based messaging can be used in exactly the same manner as in event-based messaging but unlike events in transaction receipts, the current header includes states in the past. ZKP circuit specific contracts can be used for verification of state changes for ZKP capable source networks.

State-based Interface

Parameters:

• networkId (required): Identification of the source network where state was updated. This can be used to determine the applicable verification scheme.
• encodedInfo (required): Packed ABI-encoding of the local network identifier (networkId), the local contract address (contractAddress) and the remote storage root as key-value state data (stateData) to be verified.
• encodedProof (required): ABI-encoded proof information and/or signatures that an implementation can use to verify the information given in stateData.

Returns:

• decodedInfo: The decoding scheme specific data as decoded from encodedInfo. This can contain the verified local network identifier, contract address and function call data as decoded and interpreted from the given verifiable stateData, if the next action to be taken is a remote function call.

Transaction-based messaging mechanism

Transaction-based crosschain messaging relies on conveying transaction information that can be used to prove that a transaction was executed on the source network. For EVM-based networks, the transaction root in block headers provides a cryptographic hash structure encapsulating all transactions included within the block. By transmitting block headers containing a desired transaction hash alongside a Merkle proof tying the transaction hash to the overall transaction root, the destination network can reliably verify the occurrence of the specific transaction on the source network.

More broadly, any network that utilizes Merkle trees or similar structures to efficiently store and verify transactions, can be used in the crosschain messaging protocol to attest that transactions having been executed in the network.

Transaction-based Verification

Block header proofs for transaction-based messaging can be used in exactly the same manner as in event-based messaging by making use of the transaction root. Moreover, a transaction executed in a source network, that is not EVM-based, can be wrapped in the same way with a Merkle inclusion proof or a ZKP depending on the capabilities of the source network.

Transaction-based Interface

Parameters:

• networkId (required): Identification of the source network where the transaction occurred. This can be used to determine the verification scheme.
• encodedInfo (required): Packed ABI-encoding of the local network identifier (networkId), the local contract address (contractAddress) the remote transaction data (txData) to be verified.
• encodedProof (required): ABI-encoded proof information and/or signatures that an implementation can use to verify the information given in txData. The sections below detail the format of this value.

Returns:

• decodedInfo: The decoding scheme specific data as decoded from encodedInfo. This can contain the verified local network identifier, contract address and function call data as decoded and interpreted from the given verifiable txData, if the next action to be taken is a remote function call.

Transaction and State Attestation

The process for using transaction or state attestation in the Crosschain Messaging Protocol can be applied in a similar way as event attestation for EVM compatible networks. It is also possible to construct proofs to be used for transaction or state attestation from non-EVM networks. It can be summarised as follows.

1. A transaction was executed or global state was updated on the source network. This transaction or state change can then be verified on one or more target networks.
2. Relayer nodes observe the network, for transactions being executed or storage roots being updated. Once a transaction or state change is observed, they can either sign it and store it locally, or wrap it with a Merkle proof or ZKP before sending it to the target network for verification.
3. The Crosschain Function Call SDK can be used to observe the network for transactions or state changes. Once observed, it needs to be wrapped up with a proof so that it can be verified on another network. It can call the Crosschain Messaging Layer SDK to fetch signed transactions or state changes from relayers and combine them as a single, signed object. The number of signatures that need to be combined will depend on the threshold signature scheme for the source network. It can alternatively also call the Crosschain Messaging Layer SDK to construct a block header proof around the transaction or state roots, making use of validator signatures on the source network, or more generally, construct a Merkle inclusion proof making use of the consensus participants of the source network. For ZKP capable networks, the Crosschain Messaging Layer SDK can also be called to produce a ZKP to computationally verify that the transaction or state change is valid.
4. The Crosschain Function Call SDK can be used to submit a transaction to the target network, calling the Crosschain Function Call contract, supplying the transaction or state update along with a proof that it occurred. The Crosschain Function Call contract calls the Crosschain Messaging contract, for the given source network, invoking decodeAndVerify. This call verifies that the information did come from the source network and its contents can be trusted. Actions taken after decoding and verifying the message are Crosschain Function Call protocol dependant.

Formats of Proofs

The sections below detail the requirements for formats of proofs.

Multiple ECDSA Signatures

        

        
      pragma solidity >=0.8;
      struct Signature {
        uint256 by;
        uint256 sigR;
        uint256 sigS;
        uint256 sigV;
        bytes32 meta;
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• by: The 160-bit Ethereum address derived from the 257-bit ECDSA public key of the signer.
• sigR: The ECDSA signature's R value.
• sigS: The ECDSA signature's S value.
• sigV: The ECDSA signature's V value.
• meta: The ECDSA signature's metadata containing optional information on the platform, curve and hash function that was used to create the signature.
• typ: The type of proof indicating that the proof contains multiple ECDSA signatures.
• proofData: Not applicable for this scheme.
• signatures: An array of signatures.

Note:

• The signatures array should only contain signatures for unique by values.

Multiple EDDSA Signatures

      

      
      pragma solidity >=0.8;
      struct Signature {
        uint256 by;
        uint256 sigR;
        uint256 sigS;
        uint256 sigV;
        bytes meta;
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• by: The 256-bit EDDSA public key of the signer.
• sigR: The EDDSA signature's R value.
• sigS: The EDDSA signature's S value.
• sigV: Not applicable for EDDSA signatures.
• meta: The EDDSA signature's metadata containing optional information on the platform, curve and hash function that was used to create the signature.
• typ: The type of proof indicating that the proof contains multiple EDDSA signatures.
• proofData: Not applicable for this scheme.
• signatures: An array of signatures.

Note:

• The signatures array should only contain signatures for unique by values.

Multiple Schnorr Signatures

      

      
      pragma solidity >=0.8;
      struct Signature {
        uint256 by;
        uint256 sigR;
        uint256 sigS;
        uint256 sigV;
        bytes32 meta;
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• by: The 256-bit Schnorr public key of the signer.
• sigR: The EDDSA signature's R value.
• sigS: The EDDSA signature's S value.
• sigV: Not applicable for Schnorr signatures.
• meta: The Schnorr signature's metadata containing optional information on the platform, curve and hash function that was used to create the signature.
• typ: The type of proof indicating that the proof contains multiple Schnorr signatures.
• proofData: Not applicable for this scheme.
• signatures: An array of signatures.

Note:

• The signatures array should only contain signatures for unique by values.

Multiple BLS Signatures

      

      
      pragma solidity >=0.8;
      struct Signature {
        uint512 by;
        uint256 sigR;
        uint256 sigS;
        uint256 sigV;
        bytes32 meta;
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• by: The 384-bit BLS public key of the signer.
• sigR: The BLS signature's alpha value.
• sigS: Not applicable for BLS signature.
• sigV: Not applicable for BLS signatures.
• meta: The BLS signature's metadata containing optional information on the platform, curve and hash function that was used to create the signature.
• typ: The type of proof indicating that the proof contains multiple EDDSA signatures.
• proofData: Not applicable for this scheme.
• signatures: An array of signatures.

Note:

• The signatures array should only contain signatures for unique by values.

Ethereum Block Header Proofs

        

        
      pragma solidity >=0.8;
      struct ProofData {
        bytes witnesses;
        bytes32 root;
        bytes32 blockHash;
        bytes blockHeaderMeta;
      }
      struct Signature {
        uint256 by;
        uint256 sigR;
        uint256 sigS;
        uint256 sigV;
        bytes32 meta;
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• witnesses: The rlp-encoded sibling nodes as witnesses.
• root: The block receipt, transaction or state root.
• blockHash: The block hash.
• blockHeaderMeta: The rlp-encoded block header metadata.
• by: The 160-bit Ethereum address of the signer.
• sigR: The ECDSA signature's R value.
• sigS: The ECDSA signature's S value.
• sigV: The ECDSA signature's V value.
• meta: The ECDSA signature's metadata containing optional information on the platform, curve and hashing function that was used to create the signature.
• typ: The type of proof indicating that the proof contains Ethereum block header data.
• proofData: ABI encoded data. The data contained in the proof, e.g. sibling nodes, receipt root, block hash and block headers.
• signatures: The array of Ethereum validator signatures.

Multivalued Merkle Inclusion Proofs

        

        
      pragma solidity >=0.8;
      struct ProofData {
        bytes32 root;
        bytes32[] witnesses;
        uint8[] flags;
        bytes32[] values;
      }
      struct Signature {
        uint256 by;
        uint256 sigR;
        uint256 sigS;
        uint256 sigV;
        bytes32 meta;
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• root: The Merkle tree root.
• witnesses: The Merkle multivalued proof's witnesses.
• flags: The Merkle multivalued proof's flags.
• values: The multivalued Merkle proof's leaves.
• by: The 256-bit ECDSA public key coordinate or the 256-bit ED25519 public key of the signer.
• sigR: The ECDSA/EDDSA signature's R value.
• sigS: The ECDSA/EDDSA signature's S value.
• sigV: The ECDSA signature's V value.
• meta: The ECDSA/EDDSA signature's metadata, containing optional information on the platform, curve and hashing function that was used to create the signature.
• typ: The type of proof indicating that the proof contains multivalued Merkle proof data.
• proofData: The data contained in the proof, e.g. witnesses, flags, values and a root.
• signatures: The array of consensus participant signatures.

Zero-knowledge Proofs

        

        
      pragma solidity >=0.8;
      struct G1 {
        uint x;
        uint y;
      }
      struct G2 {
        uint[2] x;
        uint[2] y;
      }
      struct ProofData {
        G1 a;
        G2 b;
        G1 c;
        bytes32 meta
      }
      struct Proof {
        uint256 typ;
        bytes proofData;
        Signature[] signatures;
      }
    
    
    

Where:

• a: First elliptic curve pairing point for zero-knowledge circuit implementation.
• b: Second elliptic curve pairing point for zero-knowledge circuit implementation.
• c: Third elliptic curve pairing point for zero-knowledge circuit implementation.
• meta: the public parameters, such as protocol name, base points and so on.
• typ: The type of proof indicating that the proof contains zero-knowledge proof data.
• proofData: The data contained in the proof, e.g. elliptic curve pairing points for a zero-knowledge circuit.
• signatures: Not applicable for this scheme.

Crosschain transaction fees

When messages are relayed across networks, certain crosschain messaging models entail associated fees. In event-based transfers validated by third-party relayers, the relayers may charge a service fee plus cover gas costs for submitting proofs on destination chains. To enable transparency, a EstimateFee function can be exposed to return expected messaging fees based on payload details. It can accept parameters like the target network ID and estimated gas limit for proof verification. Using these inputs, it can calculate total fees comprising:

• Relayer service fees based on aspects like message size, relay paradox time, privacy techniques.
• Gas fees charged on target network for executing transaction verifying the proof submission. Estimated using expected gas costs given payload complexity and configured gas limit.

The estimated fees returned can inform source network applications on complete crosschain messaging costs denominated in the payload asset. Upon successful relaying, fees are paid to the relaying contract and distributed to participating relayers minus gas expenses. For non-relayed state-based transfers where users directly submit proofs, the function can return just the target network gas estimation required for proof verification. Enabling fee transparency and estimation guides rational messaging behavior across networks.

  

  
    pragma solidity >=0.8;
    interface IEstimateGas {
      function estimateGas(
        uint256 networkId,
        uint256 gasLimit,
        bytes data
      ) external returns (uint256 gas);
    }
  
  
  

Where:

• networkId: The destination network identification.
• gasLimit: The gasLimit set in the transaction.
• data: The rlp encoded function and parameters.
• return: The estimated gas fee.

Crosschain messaging considerations

Levels of Finality

Settlement Finality: Settlement finality refers to the point at which a transaction is considered complete and irreversible by the system. Once a transaction achieves finality, it cannot be altered, undone, or disputed. This is a critical requirement for many financial and legal applications where certainty about the status of a transaction is necessary.

Probabilistic Finality: Probabilistic finality means that transactions become increasingly irreversible as more blocks are added to the chain after the block containing the transaction. The security of a transaction is based on the probability that it would be too computationally expensive for an attacker to change the transaction, as they would need to redo the work of the block containing the transaction and all subsequent blocks. Probabilistic finality usually occurs in DLTs that use consensus mechanisms with potential forks, like proof-of-work blockchains.

In industries heavily regulated and requiring clear audit trails (like finance and law), settlement finality is often a legal requirement. Systems operating in these domains must ensure their technology can meet these regulatory standards, making probabilistic finality unsuitable.

In addition, for DLT systems that interact with traditional banking systems or other blockchains, having clear settlement finality can simplify the process of reconciling transactions across different systems, which might have different rules regarding transaction finality.

Level of finality for public permissionless networks.

Implementations must carefully navigate the unique characteristics of the DLT networks on which they operate, ensuring that messages and transactions maintain their integrity and legal standing as they traverse across different ledger systems, and must account for the potential variations in the time to finality and the economic implications of the consensus mechanisms. For instance, in the context of public permissionless networks utilizing Proof of Stake (PoS) for consensus, such as Ethereum post-Merge, the network offers a form of deterministic finality through mechanisms like the Casper Finality Gadget, where transactions are considered final and irreversible after a certain number of confirmations, backed by economic stakes of validators. This ensures that transactions cannot be reversed without significant financial penalties, providing a stronger assurance of finality compared to probabilistic finality seen in proof-of-work systems.

Level of finality for permissioned networks.

In permissioned networks with consensus mechanisms like proof of authority, immediate deterministic finality can be assumed for chain transactions with sufficient validator signatures. Byzantine fault tolerance provides strong cryptographic guarantees against block reversions. Thus, messaging finality can directly track on-chain settlement without probabilistic relaxations on permissioned environments using consensus algorithms with instant finality. Deferred effects should only be needed in cases of detected validation failures, not due to probabilistic uncertainties.

Public Key / Address Validation

Some crosschain messaging techniques rely on cryptographic signatures to attest to the validity of data sourced from external networks. Destination networks will typically maintain a list of authorized public keys alongside verification rules in their verifier contracts. These contracts will also govern permissions to add or remove trusted keys from the whitelist based on the sender's address.

For ECDSA signatures, verifier contracts may opt to rather store Ethereum addresses, serving as proxies for actual public keys, to be used later in verifying signed payloads. Before registering their signing address, participants must validate possession of the associated private key for signing messages, usually via an eth_sign or EIP-191 personal_sign operation. Failing to properly validate the signing identity can bind an invalid address incapable of producing signatures to manage the registrant’s listing. This prevents erroneously registered entities from later participating in their own removal or updating their registered signing keys. Careful key management ensures signature-based messaging can flexibly propagate while preventing spam and manipulation.

Consideration of ZKP as a messaging mechanism

ZK-SNARKs are succinct non-interactive arguments of knowledge that enable privacy-preserving proofs of computation and integrity. They are well-suited for crosschain messaging due to their short, efficiently verifiable proofs. ZKP relayers are operators that generate proofs to attest to the validity of messages without revealing the content. They undergo upfront ceremonies to securely generate proving and verification keys to facilitating subsequent proof generation workflows. The verification keys are published or configured in smart contracts on the destination network in order to verify computational proofs attesting to the authenticity of ZKP-encoded messages coming from the source network.

For crosschain messaging, ZKP relayers follow bi-directional multi-party computation protocols to jointly compute proofs of events, transactions or state transitions on source networks without leaking raw data. Source network integrity assertions are encoded into the generated proofs and transmitted to ZK verifier contracts on destination networks for verification against the published verification keys.

Destination networks can host ZK verifier contracts supporting different proof circuits for multiple types of ZKP-attested crosschain messages such as asset transfers, trade settlements, identity credentials, etc. By configuring circuit-specific verifier contracts and relayers with aligned circuits, advanced ZKP-based messaging flows between networks can be supported without compromising privacy.

Crosschain Function Call Layer

The Crosschain Function Calls layer enables execution of operations across networks, allowing crosschain applications to trigger and coordinate activities on multiple networks. This is the operational core of the stack, enabling functions to be executed remotely on another network. This capability is crucial for allowing synchronous workflows across networks in scenarios where actions on one network depend on the state or outcomes on another. It is this layer that orchestrates the remote execution of smart contract functions, ensuring that transactions are not only executed but done so in a manner that aligns with the overarching business logic defined in the applications layer.

Crosschain function call protocols can be atomic or non-atomic. Non-atomic protocols do not ensure consistency across networks. That is, a segment of the overall crosschain flow may occur on a source network, with associated updates, but the segment on the destination network may fail, and hence the updates would not be applied on the destination network. A crosschain flow segment could fail for any of the reasons described below. Non-atomic protocols must provide a mechanism to resolve failures such that consistency is restored.

Interfaces and Helper Functions

This section defines Solidity interfaces for the Crosschain Function Call layer as used by the Crosschain Application layer.

Remote Function Call Interface

The Remote Function Call interface allows applications to call functions remotely on other networks.

      

      
        pragma solidity >=0.8;
        interface IRemoteFunctionCall {
          function outboundCall(
            uint256 networkId,
            address contractAddress,
            bytes calldata functionCallData
          ) external payable;
          function inboundCall(
            uint256 networkId,
            bytes calldata encodedInfo,
            bytes calldata encodedProof,
          ) external payable;
          event RemoteFunctionCall(
            uint256 indexed networkId,
            address indexed contractAddress,
            bytes functionCallData
          );
        }
      
    
    

Where IRemoteFunctionCall functions are defined as:

• outboundCall: Function that emits a RemoteFunctionCall event, to trigger a remote function call on another network, which will only succeed if a valid EVM-based attestation proof of this event can be provided.
• inboundCall: Function that executes a remote function call on the local network after a valid event, state or transaction attestation proof from another network was verified.

Where outboundCall parameters are defined as:

• networkId: Identifier of remote destination network where the function call is to be made.
• contractAddress: Address of the contract on the remote destination network to which the function call is to be made.
• functionCallData: The function call data that consists of the ABI-encoded function selector and input parameter data with which the remote function should be called.

And inboundCall parameters are defined as:

• networkId: Identifier of the source network that initiated the remote function call.
• encodedInfo: The ABI-encoded remote source network information containing the local destination network identifier, contract address and function call data encoded in remote event, transaction or state change data that needs to be verified before executing the function call locally.
• encodedProof: The ABI-encoded remote source network proof data and/or signatures that an implementation can use to verify the information given in encodedInfo.

Proofs should always be generated for a specific source and destination network as a remote function call is always intended for a particular target network. It is recommended to include the networkId in the source network encodedInfo that will be attested to on another network so that it cannot be tampered with and that the remote function call is executed in the intended network.

Task Manager Interface

When a task is dispatched from the source network, by calling outboundCall, a remote function call is triggered on the target network. This process should be made idempotent in the sense that if identical remote function call requests are made, with the same source network information and attestation proof, then it should only be executed once. There are various approaches to implementing this. One solution would be to store hashes of the given encodedInfo on the target network, to ensure it is used only once to facilitate a successful remote function call execution. Another solution would be to make use of a task identifier, generated to be unique to the source network information, and to persist the identifiers of successfully executed tasks on the target network.

    

      
        pragma solidity >=0.8;
        interface ITaskManager {
          event OutboundTaskExecuted(
            bytes32 indexed taskId,
            uint256 indexed networkId,
            address indexed contractAddress,
            bytes functionCallData
          );
          event InboundTaskExecuted(
            bytes32 indexed taskId,
            uint256 indexed networkId,
            address indexed contractAddress,
            bytes functionCallData
          );
          function genTaskId(bytes calldata data) external pure returns (bytes32 taskId);
        }
      
    
    

Where ITaskManager events are defined as:

• OutboundTaskExecuted: Event to indicate that the outbound task was successfully executed.
• InboundTaskExecuted: Event to indicate that the inbound task was successfully executed.

Where OutboundTaskExecuted parameters are defined as:

• taskId: Uniquely generated task identifier.
• networkId: Identifier of remote destination network where the function call is to be made.
• contractAddress: Address of the contract on the remote destination network to which the function call is to be made.
• functionCallData: The function call data with which the remote function should be called.

And InboundTaskExecuted parameters are defined as:

• taskId: Uniquely generated task identifier.
• networkId: Identifier of the source network that initiated the remote function call.
• contractAddress: Address of the local contract to which the function call was made.
• functionCallData: The function call data with which the local function was called.

Application Authentication Parameters

Remote function call components need to determine the source network and contract address that initiated the remote function call. Functions in contracts on destination networks use this information to determine if the caller is authorised to execute the function remotely. The authentication parameters are provided as hidden parameters, that exist outside the scope of the declared function parameters. The parameters are appended to the call data of a function by the function call component and extracted by the application layer.

The helper function encodeNonAtomicAuthParams appends authentication parameters to the function selector and parameter data, and the function decodeNonAtomicAuthParams can be used to extract the authentication parameters from the call data again.

      

      
      pragma solidity >=0.8;
      abstract contract NonAtomicHiddenAuthParams {
        function encodeNonAtomicAuthParams(
          uint256 networkId,
          address contractAddress,
          bytes memory functionCallData
        ) internal pure returns (bytes memory) {
          return bytes.concat(functionCallData, abi.encodePacked(networkId, contractAddress));
        }
        function decodeNonAtomicAuthParams() internal pure returns (
          uint256 networkId,
          address contractAddress
        ) {
          bytes calldata allParams = msg.data;
          uint256 len = allParams.length;
          assembly {
            calldatacopy(0x0, sub(len, 52), 32)
            networkId := mload(0)
            calldatacopy(12, sub(len, 20), 20)
            contractAddress := mload(0)
          }
        }
      }
    
  
  

Application Authentication

Similar to existing single network applications, the type of application authentication is application specific. Applications that checked msg.sender in a single network context should use the decodeNonAtomicAuthParams and decodeAtomicAuthParams to check that the source network and source contract are authorised to call the function. In the case of atomic crosschain function calls, the application should also check that the root network of the call execution tree is authorised. Applications should limit which networks can be root networks to those networks that they have access to.

Crosschain Application Layer

The Crosschain Application Layer orchestrates complex interactions across multiple blockchain networks, enabling business processes to seamlessly operate over distinct ledgers. This layer empowers applications to access and manipulate data across different chains, unlocking new possibilities for crosschain interoperability and collaboration. It utilizes either atomic or non-atomic crosschain function calls to facilitate remote function executions and state updates across networks.

• User Interface Tools: A Graphical User Interface (GUI) or Command Line Interface (CLI) for user interaction.
• Network Interface Tools: A suite of tools or libraries, using DLT specific protocol drivers, to facilitate network connectivity to the underlying ledger.
• Smart Contracts: Contracts need to be deployed on both the source and target networks to handle business logic and state transitions.
• Crosschain Executors: These entities, also known as Remote Function Call agents (RFC agents), execute remote crosschain calls. They can be users, application operators or any third party.
• Data Storage: While optional, off-chain storage can be utilized for data that doesn't require ledger immutability or only require a hash of the data to be stored on the ledger. This can include large files, frequently updated data, or information that needs to be deleted or modified.

The Crosschain Application Layer enables a wide range of use cases, such as crosschain asset transfers, multi-chain decentralized applications (dApps), and interoperable decentralized finance (DeFi) protocols. By facilitating seamless interaction between different DLT networks, this layer plays a crucial role in driving the adoption and scalability of this technology.

Leveraging Crosschain Messaging only

For the Crosschain Application layer to leverage the Crosschain Messaging layer defined in this specification, a Crosschain Messaging framework or SDK should be deployed alongside the source and target networks and the protocols defined in this specification should be implemented.

• Initiation: Users interact with the source network through a GUI or CLI, initiating transactions, via DLT specific protocols, to the source network's smart contracts.
• Processing: Processing involves capturing a transaction, or event emitted from a smart contract, or state change on the source network, as is done by the Crosschain Function Call layer.
• Verification: This layer verifies the event, transaction or state change, and either signs it, or generates a proof from it, containing consensus participant signatures or verifiable zero-knowledge computations, that can be stored either on a third, intermediary network or off-chain for enhanced flexibility and efficiency.
• Invocation: RFC (Remote Function Call) agents, acting on behalf of users, application operators, or third parties, utilize the generated proofs to invoke corresponding flows on the target network. These agents are responsible for relaying the verified events, transactions or state changes, and triggering the execution of the appropriate flows on the target network.
• Verification and Remote Execution:The target network's smart contracts, equipped with a predefined interface as specified in this specification, verify the source network events, transactions or state changes. Successful verification triggers the execution of designated remote functions, while failure leads to transaction abortion.

By leveraging the Crosschain Messaging layer, the Crosschain Application layer enables secure and reliable communication between different DLT networks. This communication is essential for executing complex, multi-chain business processes and facilitating interoperability across diverse DLT ecosystems.

Leveraging Crosschain Function Call

For the Crosschain Application layer to leverage the Crosschain Functional Call layer defined in this specification, a Crosschain Function Call Framework or SDK should be deployed, alongside the source and target networks, and the protocols defined in this specification should be implemented.

• Custom Function Implementation: Applications can implement custom functions that utilize the crosschain function interface specified herein, enabling seamless source and target network interactions.
• Verification and Invocation: The crosschain SDK agent undertakes the verification of events, transactions or state updates on the source network, generates the requisite proofs, and triggers the target network's smart contracts to conduct crosschain transactions. This functionally enriches the Messaging Layer SDK by incorporating RFC agents, thereby facilitating broader crosschain interactions.

By leveraging the Crosschain Function Call layer, the Crosschain Application layer can support a wide range of complex, multi-chain use cases. This includes scenarios such as crosschain asset swaps, multi-chain lending and borrowing, and interoperable decentralized exchanges.

Figure 2: Crosschain Protocol - Flow Overview

Considerations:

Key considerations for the Crosschain Application layer include:

• Handling source network and target network setup: Strategies to manage and maintain interoperability configuration stored on the source or target networks.
• Handling source network and target network errors: Strategies to manage and recover from errors originating from either the source or target networks.
• Handling gas and service fees: Approaches to handle transaction costs, including gas and service fees, efficiently across networks.

Adaptability for Non-EVM Ecosystems

This requirement allows developers to implement the crosschain interoperability protocols consistently across diverse DLT ecosystems, promoting seamless integration and interaction between different networks. By providing clear mappings and adaptations of the interfaces to their respective environments, non-EVM platforms can ensure that the crosschain communication mechanisms operate predictably and reliably, regardless of the underlying technology stack.

Considerations

Smart Contract Upgradability

Smart contract upgradability a critical aspect to consider in the development of a DLT interoperability implementation, particularly for long-term viability and compliance with evolving regulatory standards. Smart contracts, once deployed, are immutable on the ledger. However, financial regulations and business logic may evolve, necessitating updates to the contracts. Implementing upgradable smart contracts through proxy patterns or versioning systems allows for the modification of contract logic without changing the contract's address or deployed bytecode. This approach must be carefully designed to maintain the integrity and security of the contracts, especially in a regulated financial context. Upgradability mechanisms should include strong governance processes to control updates and prevent unauthorized changes. Additionally, considering the crosschain interoperability, the upgradability strategy should ensure consistency and compatibility across different DLT platforms, enabling seamless interaction and compliance with regulatory changes over time.

Data Type Convertibility and Compatibility

In the context of this specification, certain data types such as uint256 and bytes32 are used to define interfaces and data structures. It is important to note that these data types, while distinct, are convertible and can be transformed from one to another through simple data format conversions. Smart contracts and off-chain relays are recommended to accommodate both data types to enhance interoperability and flexibility in data handling across different DLT platforms. This approach facilitates seamless crosschain communication and operations, ensuring broader compatibility and ease of implementation within diverse DTL ecosystems. Developers should ensure that their implementations incorporate mechanisms for the straightforward conversion between these data types, where necessary, to maintain the integrity and fidelity of data as it moves across network boundaries.