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.
6.1 Compatibility with Corda network
Using the crosschain messaging protocol described in this specification to facilitate interoperability between a Corda network and an Ethereum network is outlined in this section.
6.1.1 Crosschain Messaging Layer
Corda does not have events in the same sense as Ethereum but a transaction attestation proof can be constructed instead and used in the transaction-based messaging mechanism outlined in section 3.6.3 (Transaction-based Attestation). Corda transactions are split up into component groups and their SHA-256 hashes are used as Merkle tree leaves in storage. The most important of these, for a Corda transaction attestation proof, are listed below:
- The outputs component group, containing the output data of the transaction.
- The commands component group, containing the commands that was executed during the execution of the transaction.
- The signers component group, containing the public keys of all participants that needs to sign the transaction.
- The notary component group, containing the public key of the notary that needs to sign the transaction.
The contents of the outputs and commands component groups is interpreted as an instruction and translated into an EVM function and corresponding function call parameters to facilitate a remote function call from a Corda network to an EVM-based network. Translation is done by registered parameter handlers for each function that is callable via the interop protocol.
Similar to the interop between two Ethereum networks, participant on-boarding will be required to provide sufficient security in a production environment. Even for EVM-based event attestation proofs, it might be necessary to maintain a list of active validators of the source network on the target network. For example, some QBFT network implementations using contract validator selection, no longer include the list of validator addresses in their block headers.
More generally, the network verifying a proof might need to maintain a list of authorized signatories in the verifying contract. Consensus on Corda transactions are reached among participants of the transaction and a notary, instead of a global network-wide validator pool. For this reason, it is necessary to verify that the signatures provided in the proof are from authorized signatories and match up with the required signers of the transaction as provided in the signers and notary component groups.
Corda signatures can use ECDSA with the SECP256K1 or SECP256R1 curve and SHA256 hashing, or EDDSA with the ED25519 curve and SHA512 hashing. Signatures are performed over a hash of the Merkle transaction tree root and metadata containing the signature scheme that was used. Proof and signature structures must use those defined in section 3.7.6 (Multivalued Merkle Inclusion Proofs).
The interface for encoding transaction data, for use in the transaction-based messaging mechanism, is given in section 3.6.2 (Transaction-based Interface). The structure of the transaction data (txData) is DLT specific and an example of a compliant Corda transaction attestation proof can make use of the following structures:
struct ComponentData {
uint8 groupIndex;
uint8 internalIndex;
bytes encodedBytes;
}
struct TxData {
bytes inputParameters;
string hashAlgorithm;
bytes32 privacySalt;
ComponentData[] componentData;
}
Where the ComponentData structure contains Corda transaction component group data that needs to be decoded, hashed and checked for Merkle tree inclusion.
Properties:
groupIndex: Global transaction component group index.internalIndex: Internal component group index.encodedBytes: Contains a hex-encoded component group of the Corda transaction.
Where the TxData structure contains the Ethereum function input parameters, Corda component group data and algorithmic details to verify the component group hash's inclusion in the transaction tree.
Properties:
inputParameters: Input parameters to be verified as being included in the component data.hashAlgorithm: Hash algorithm used in the Merkle tree. Only SHA-256 is currently supported.privacySalt: Salt needed to compute a Merkle tree leaf.componentData: Hashes of these components become the values we want to proof Merkle tree membership of in our multivalued proof.
The ABI-encoded TxData struct is then included in the encodedInfo field as txData.
This multivalued Merkle inclusion proof can alternatively be turned in a zero-knowledge proof yielding a much lower EVM verification cost, with added privacy, but resource intensive proof generation.
The interface for the crosschain verifier contract on the EVM-based network, that is verifying the Corda proof, is outlined in section 3.3 (Crosschain verifier interface). To be able to fully integrate with an EVM network, a compliant Corda app would need to provide an equivalent implementation of decodeAndVerify to verify an EVM-based proof as listed in section 3.7 (Formats of Proofs). This evidently results in having to maintain an active list of EVM network validators, or authorised signatories, in the messaging layer of the Corda app.
6.1.2 Crosschain Function Call Layer
For every type of Corda transaction that gets added to the interop flows, and EVM function call instruction that can be created from it, a translator needs to be registered in the messaging layer. The translator consists of a mapping between Corda output component group data and EVM input function call parameters. The inputParameters in the TxData structure contains the call parameters of the function we want to call remotely through the function call layer.
Both the Corda app and the EVM contract MUST implement the interface in section 4.1.1 (Remote Function Call Interface), or an equivalent thereof, to allow functions to be called remotely on other networks.
It is worth noting that the Corda network, or the generator of the Corda proof, needs to know the destination EVM network identification and target contract address before invoking inboundCall on an EVM network. This information is not signed over as in the case of EVM event attestation, and care should be taken that the correct contract addresses are given to this layer.
The required authentication parameters in section 4.1.3 (Application Authentication Parameters) contain an additional network identification number and contract address from where the event, transaction or state change originated. This, for EVM-based networks, provide the ability to verify the source network identification and contract address against the event, transaction or state data that was signed over in an attestation proof. The most obvious way to generalize this for Corda transaction attestation proofs, at the moment, is to use the Corda network parameters. For each contract class there is a list of SHA-256 hashes, of the approved Corda app jar versions containing the contract, that is included in the Corda network parameters as whitelisted contract implementations. A Corda transaction contains a SHA-256 hash of the source network parameters from where the transaction was sent which can be used in authorisation if we onboard and maintain the Corda network parameters on the EVM-based network.
6.1.3 Crosschain Application Layer
The application layer integration mainly consists of implementing Corda app and EVM smart contract flows involving specific functions that can be called remotely, via the crosschain function call layer. The underlying messaging protocol, which depends on the registered verification scheme in the crosschain messaging layer, translates a verifiable step (event, transaction or state change) in the flow, performed on a remote network, into a verified instruction that can be used to securely perform the next step in the flow on the local network. The application layer contains the business logic that gets invoked through the crosschain messaging protocol.
Any application layer implementation needs to also cater for unhappy paths in the flows to ensure assets don't get stuck without recovery. This is a requirement in any regulated financial environment. This involves cancellation of a flow, under special circumstances, to release assets by means of a remote function call and a cryptographic proof of a prerequisite step that occurred on a different network.
The existing use case using Corda and Ethereum focussed in on DvP (Delivery vs Payment) where securities reside on a Corda network and tokenized cash reside on an Ethereum network in deposit token contracts. The crosschain messaging protocol is used to facilitate remote crosschain function calls between the two ledgers, and an execution plan, involving fixed flows, was build on top of the protocol to do intraday repo trades. The approach followed a standard hold to execute approach where assets and cash are placed on hold and holds are executed after verification of proof that either the hold was placed on the other network or the hold was executed on the other network.
6.2 Compatibility with Algorand network
Using the crosschain messaging protocol described in this specification to facilitate interoperability between an Algorand network and an EVM-based network is outlined in this section.
6.2.1 Crosschain Messaging Layer
For Algorand to be compatible with the crosschain messaging protocol discussed in this document, it must support an event, transaction or state attestation proof as specified in section 3.7.
An Algorand block contains a transaction root, which authenticates the set of transactions appearing in the block, as the root of a Merkle tree with transaction ids as leaves, in lexicographic order. This can naturally be turned into a transaction attestation proof
An Algorand state proof is a cryptographic proof of state changes that occur in a given set of blocks. State proofs are created and signed by the Algorand network itself, so they can be used to verify that a state change happened on the Algorand network. State proofs use quantum-safe Falcon keys. An EVM pre-compile for verification of this signature scheme was proposed in EIP 7592 but these signature are not currently supported.
Algorand make use of events as part of log functions, which can be used in the crosschain message protocol described in this document.
Algorand uses ED25519 signature scheme for authorization and uses SHA-512/256 hash function for creating contract account addresses from TEAL bytecode.
It is recommended to support ECDSA using the SECP256K1 curve and KECCAK-256 hashing algorithm for better verification times in the EVM.
As a source ledger, it would need to emit events. Since Algorand implements events in Log function, it is recommended that a module function is defined in Algorand that has a similar format as Solidity. The function should log the event data such as destination chain, destination smart contract address, and function data.
Messaging components MUST support an equivalent interface as described in section 3.3 (Crosschain verifier interface).
This function could be:
@app.external
def decodeAndVerify(networkId:abi.uint256, encodedInfo: abi.byte[], encodedProof:abi.byte[], output:abi.byte[] )-> Expr:
# getDecodedInfo
return output.set(decodedInfo)
The definition of networkId, encodedInfo and encodedProof are similar to the EVM definition.
To perform encoding for message info, the encoded rules of Algorand specification (https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0004.md) should be used.
6.2.2 Crosschain Function Call Layer
Algorand should support compatible remote function call libraries to initiate a remote function call to another network and execute a remote function call locally after verifying a proof from another network as described in section 4.1.1 (Remote Function Call Interface).
On the Algorand chain, this remote function call can be defined as
@app.external
def outboundCall(networkId:abi.uint256, contractAddress: abi.address, functionCallData:abi.byte[] )-> Expr
def inboundCall(networkId:abi.uint256, encodedInfo: abi.byte[], encodedProof:abi.byte[] )-> Expr
def CrosschainCallEvent(networkId:abi.uint256, contractAddress: abi.address, functionCallData:abi.byte[] )-> Expr
6.3 Compatibility with Stellar (Soroban) network
Using the crosschain messaging protocol described in this specification to facilitate interoperability between a Stellar (Soroban) network and an EVM-based network is outlined in this section.
6.3.1 Crosschain Messaging Layer
For Stellar(Soroban) to be compatible with the crosschain messaging protocol discussed in this document, it must support an event, transaction or state attestation proof as specified in section 3.7.
Stellar(Soroban) make use of events as part of env struct, which can be used in the crosschain message protocol described in this document.
Messaging components MUST support an equivalent interface as described in section 3.3 (Crosschain verifier interface).
This function could be:
pub struct Signature {
by : U256,
sig_r: U256,
sig_s: U256,
sig_v: U256,
meta: BytesN<32>
}
pub struct Proof {
typ: U256,
proof_data: Bytes,
signatures: Vec,
}
trait ICrosschainVerifier {
fn decode_and_verify(network_id: U256, encoded_info: Bytes, encoded_proof: Bytes) -> Bytes;
}
The definition of networkId, encoded_info and encoded_proof are similar to the EVM definition.
6.3.2 Crosschain Function Call Layer
Stellar(Soroban) should support compatible remote function call libraries to initiate a remote function call to another network and execute a remote function call locally after verifying a proof from another network as described in section 4.1.1 (Remote Function Call Interface).
On the Stellar(Soroban) chain, this remote function call can be defined as
pub fn inbound_call(env: Env,
network_id: U256, //stellar chainid
encoded_info: Bytes,
encoded_proof: Bytes,
)
fn outbound_call(env: Env, network_id: U256,target_contract_address: Bytes, function_calldata: Bytes,source_contract_address: Address );
6.5 Compatibility with the FinP2P network
Using the crosschain messaging protocol described in this specification to facilitate interoperability between an arbitrary DLT network, connected to the FinP2P network, and an Ethereum network is outlined in this section.
The FinP2P system uses routers, which serve as a connection point between different participants involved in the DLT ecosystem of tokenized assets. These routers utilize the open FinP2P protocol to unify user identities, wallets, data structures, messaging and orchestration of DLT transactions. They can be used as a network of trusted peers, signing receipts, to attest to finalized transactions on the underlying DLT networks they are connected to.
FinP2P receipts, when part of an execution plan, can be used to enable interoperability between two of the underlying DLT networks, by trusting router signatures over FinP2P receipts. This allows for a mode of interoperability where the heterogeneous DLT networks are less coupled. That is, the verifying DLT network doesn't need to understand the workings of the DLT network where the transaction originated. This means that EVM verifiers can be standardised around processing generic FinP2P receipts and verifying the signatures over them. This comes at the cost of an additional layer of trusted peers instead of relying on the consensus participants of the underlying DLT network.
The FinP2P network can also facilitate interoperability between two DLT networks by routing around ledger specific proofs, as part of the receipt, as is described in section 3.7 of this document. Verifier contracts handling such proofs will do so independently of whether the proofs were routed via FinP2P or not.
The FinP2P open source specifications are available here.
6.5.1 Crosschain Messaging Layer
A signed FinP2P receipt is encoded, hashed and signed using EIP712. Using a known Receipt structure allows the EVM verifier to extract data from the encoded structure and translate it into a command and EVM smart contract function call parameters. FinP2P receipts are defined below:
{
"types": {
"EIP712Domain": [
{"name": "name", "type": "string"},
{"name": "version", "type": "string"},
{"name": "chainId", "type": "uint256"},
{"name": "verifyingContract", "type": "string"}
],
"Account": [
{"name": "accountType", "type": "string"},
{"name": "finId", "type": "string"}
],
"TransactionDetails": [
{"name": "operationId", "type": "string"},
{"name": "operationType", "type": "string"},
{"name": "transactionId", "type": "string"}
],
"Asset": [
{"name": "assetId", "type": "string"},
{"name": "assetType", "type": "string"}
],
"TradeDetails": [
{"name": "executionPlanId", "type": "string"},
{"name": "instructionSequenceNumber", "type": "string"}
],
"Receipt": [
{"name": "id", "type": "string"},
{"name": "source", "type": "Account"},
{"name": "destination", "type": "Account"},
{"name": "asset", "type": "Asset"},
{"name": "tradeDetails", "type": "TradeDetails"},
{"name": "transactionDetails", "type": "TransactionDetails"}
]
}
}
Supported FinP2P signatures use ECDSA with the SECP256K1 curve and KECCAK hashing for optimized verification in the EVM. Signatures are encoded according to the EEA specification as defined in section 3.7.1 (Multiple ECDSA Signatures) to hold FinP2P receipt signatures.
The interface for encoding transaction data, for use in the transaction-based messaging mechanism, is given in section 3.6.2 (Transaction-based Interface). The structure of the transaction data (txData) is DLT specific and an example of a compliant FinP2P transaction attestation proof can make use of the following structures containing a FinP2P receipt:
struct EIP712Domain {
string name;
string version;
uint256 chainId;
address verifyingContract;
}
struct Asset {
string assetId;
string assetType;
}
struct TransactionDetails {
string operationId;
string operationType;
string transactionId;
}
struct TradeDetails {
string executionPlanId;
uint256 instructionSequenceNumber;
}
struct Account {
string accountType;
string finId;
}
struct Receipt {
string id;
Account source;
Account destination;
Asset asset;
TradeDetails tradeDetails;
TransactionDetails transactionDetails;
}
struct TxData {
bytes inputParameters;
string command;
EIP712.EIP712Domain domainParameters;
Receipt receipt;
}
Where the EIP712Domain structure contains FinP2P domain parameters.
Properties:
name: The user readable name of the signing domain.version: Current major version of the signing domain.chainId: The EIP-155 chain id.verifyingContract: Destination verifying contract address.
Where the Receipt structure contains FinP2P receipt data.
Properties:
assetId: Asset identification, e.g. ownera, USD, BTC.assetType: Asset type, e.g. finp2p, fiat, cryptocurrency.operationId: Operation identification on the FinP2P network.operationType: Type of operation performed by the transaction.transactionId: Transaction identification on the underlying DLT network.executionPlanId: Execution plan identification corresponding to a unique trade identifier.instructionSequenceNumber: Unique instruction number for the step of the execution plan that was performed.accountType: Type of FinP2P account, e.g. finp2pfinId: FinP2P account identification in the form of a compressed public key.id: Unique receipt identification.source: Source FinP2P account.destination: Destination FinP2P account.asset: Asset used in the trade.tradeDetails: Trade details.transactionDetails: Transaction details.
Where the TxData structure contains the Ethereum function input parameters, FinP2P receipt data and domain parameters required to recreate the hash that was signed.
Properties:
inputParameters: Input parameters to be verified as being included in the receipt data.command: The unique command constructed from the receipt contents that is used to make the remote function call.domainParameters: EIP712 domain parameters needed to encode typed data.receipt: The FinP2P receipt.
The ABI-encoded TxData struct is then included in the encodedInfo field as txData.
The interface for the crosschain verifier contract on the EVM-based network, that is verifying the FinP2P receipt proof, is outlined in section 3.3 (Crosschain verifier interface).
6.5.2 Crosschain Function Call Layer
For every FinP2P receipt, pertaining to a specific execution plan instruction, that gets added to the interop flows, and EVM function call that can be created from it, a translator needs to be registered in the messaging layer. The translator consists of a mapping between receipt fields and EVM input function call parameters. The inputParameters in the TxData structure contains the call parameters of the function we want to call remotely through the function call layer.
EVM and non-EVM based DLT networks MUST implement the interface in section 4.1.1 (Remote Function Call Interface), or an equivalent thereof, to allow functions to be called remotely with a proof that a previous step in the execution plan was executed successfully.
The FinP2P adapter that generates the proof from the receipt needs to know the target network information, where the receipt will be verified, as well as the target contract address where the remote function call must be executed. This information is included in encodedInfo when invoking inboundCall on an EVM network. It is not signed over as in the case of EVM event attestation, and care should be taken that the correct contract addresses are given to this layer.
6.5.3 Crosschain Application Layer
The application layer integration consists of implementing specific functions that can be called remotely, via the crosschain function call layer. The existing use case using FinP2P with Ethereum focussed in on DvP (Delivery vs Payment) where securities reside on the FinP2P network as tokenized assets and tokenized cash resides on an Ethereum network in deposit token contracts. The crosschain messaging protocol is used to facilitate remote crosschain function calls to transfer the asset in the FinP2P network and provide payment for it on Ethereum. The approach makes use of FinP2P escrow services to hold and transfer assets. Holds are executed after verification of proof that either the hold was placed on the other network or the hold was executed on the other network.
