From 57fe28cb13202550ed29512f913de2508877dc0b Mon Sep 17 00:00:00 2001 From: Paolo Cappelletti Date: Wed, 18 Jan 2023 09:42:45 +0100 Subject: [PATCH 1/3] Draft of ZenIP 42205 for a cross-sidechain communication protocol --- zenip-42205.md | 144 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 zenip-42205.md diff --git a/zenip-42205.md b/zenip-42205.md new file mode 100644 index 0000000..aded5b3 --- /dev/null +++ b/zenip-42205.md @@ -0,0 +1,144 @@ + +# ZenIP-42205 + + ZenIP: 42205 + Title: Cross-sidechain communication protocol + Owner: Paolo Cappelletti, + Discussions-To: Paolo Cappelletti, + Comments-URI: https://horizen.global/invite/discord + Status: Draft + Type: Consensus + Created: 2023-01-18 + License: MIT + +## Table of Contents + +- [Abstract](#abstract) +- [Motivation](#motivation) +- [Requirements](#requirements) +- [Specification](#specification) +- [References](#references) + + +## Abstract + +This ZenIP proposes the implementation of a cross-sidechain communication protocol, to exchange in a secure way arbitrary messages between two sidechains of the Horizen Ecosystem, as described in [[1]](#references). + + +## Motivation + +There is a need for secure communications between blockchains such that data, including digital assets, can be transferred between them. + +The definition of a communication protocol between sidechains will be the base layer on top of which we will be able to implement specific higher level applications, to enable the transfer of data between them. +For example, it will be possible to define a protocol allowing an application to transfer assets from one sidechain to another by transferring a message identifying the asset to be burnt in the sending sidechain and recreated with its properties in the receiving sidechain. + +Inside the Horizen ecosystem, every sidechain is connected to the mainchain: the mainchain collects certificates from all the sidechains, and they contribute to the creation of a data structure (the sidechain commitment tree) representing all the state-changes happening in the sidechains that are relevant for the Mainchain [[2]](#references). +The Merkle root of this tree is shared among all the chains. +By leveraging this feature, and by defining a zero-knowledge proof of authenticity of each message with an “anchor” to this tree root, we will use the mainchain as a *trusted intermediary* between the two sidechains. + +## Requirements + +The messaging protocol is designed to be generic, not bound to a specific message format. + +The messaging protocol is designed to not require any hard-fork on the mainchain: no changes on certificate data format. + + +## Specification + +**Application flow** + +The high-level flow will be implemented as described in [[1]](#references), and summarized here: +- one or more messages will be published in the sender sidechain. +- All the messages published inside each epoch will be collected in a Merkle tree, and the tree root will be included in a specific custom field inside every certificate of the epoch. +Furthermore, we require to insert in another specific custom field the reference to the previous epoch’s top quality certificate. This is used to identify the top-quality certificate of each epoch, that is the only relevant certificate for proof calculation and verification. +- A redeem message will be generated on the sender sidechain, containing a zkProof of authenticity of the message. It will be posted and verified on the receiving sidechain. + +We will assume the sender sidechain is of non-ceasable type (this proposal does not cover any methods for exchanging messages from a ceased sidechain). + +**Entity definition** + +We define the following entities: + +A *cross chain message* is a generic message to be exchanged between two sidechains. +It will be composed by the following attributes: +- `sendingScId`: identifier of the sending sidechain +- `receivingScId`: identifier of the receiving sidechain +- `msgType: Int`: Identifier of the type of message. +Note this has not to be unique, and will be meaningful only for the upper protocol established by the two sidechains +- `sender`: Address of the creator of the message in the sending sidechain +- `receiver`: Address of the receiver in the receiving sidechain +- `payload`: This is the body of the message exchanged. +Can be any kind of message, meaningful only for the upper protocol established by the two sidechains + +We also define `msg_hash` as the Poseidon Hash of all the previous fields. + +A *redeem message* “wraps” the previous cross chain message by adding also the zk-proof of its authenticity, and all the public inputs needed to verify it. +It will be composed by the following attributes: +- `message` +Cross chain message to be redeemed (see previous entity) +- `curr_cert_hash: ByteArray` +Certificate data hash of the certificate containing the message tree root where the message is committed in the sender sidechain +- `curr_sc_tx_commitment_root: ByteArray` +Sidechain commitment Merkle tree root where the above certificate was committed. +- `next_cert_hash: ByteArray` +Certificate data hash of a next epoch certificate in the sender sidechain. +- `next_sc_tx_commitment_root: ByteArray` +Sidechain commitment Merkle tree root where the above certificate was committed. +- `proof: ByteArray` + +**Certificate format** + +Every sidechain that wants to act as “sender” must emit certificates with the following structure: +`N + M = 32 ` + +Where: +`M` = number of bit vector elements +`N` = number of certificate custom fields, all of them of fixed 32 bytes size. + +A minimum amount of 3 custom fields will be required: fields at position 1 and 2 (0 based) will be reserved for this protocol. +- The custom field at position 1 must contain the root of a Merkle tree built with all the cross chain messages published in the epoch. +Each leaf of the Merkle tree is composed by `msg_hash`. Leaves will be valorized in order of message publication inside the sidechain. +We will refer to this root with `SC2SC_message_tree_root` +- The custom field at position 2 will contain the certificate data hash of the previous epoch’s top-quality certificate. + +**Cryptographic components** + +Every sidechain that wants to enable this protocol must use a cryptographic circuit , to allow the creation and verification of the proof of authenticity of the message. The proof will be included inside the redeem message. + +Sender sidechain will be responsible for its creation, receiver sidechain for its verification. + +Each proof must be generated for one and only one message. +The proof specification, for a message msg published in a epoch N, is as follow: + +Public inputs: +- Sidechain commitment tree root of epoch N+1 (`next_sc_tx_commitment_root`) +- Sidechain commitment tree root of epoch N (`curr_sc_tx_commitment_root`) +- Poseidon Hash of the message to be redeemed (`msg_hash`) + +Witnesses: + +- A certificate for epoch N+1 (`next_cert`) +(can be any certificate, not mandatory to be the top-quality one) +- Merkle path of next_cert data hash inside its sidechain commitment tree (`next_cert_path`) +- Top quality certificate for epoch N (`curr_cert`) +- Merkle path of curr_cert hash inside its sidechain commitment tree (`curr_cert_path`) +- Merkle path of the message to be redeemed inside SC2SC_message_tree_root present in the custom field of curr_cert (`msg_path`) + +Statements: +- `VrfyMembership(H(next_cert), next_cert_path, next_sc_tx_commitment_root) == TRUE` +- `VrfyMembership(H(curr_cert), curr_cert_path, curr_sc_tx_commitment_root) == TRUE` +- `next_cert.previous_top_quality_hash == H(curr_cert)` +- `curr_cert.epoch == next_cert.epoch - 1` +- `VrfyMembership(msg_hash, msg_path, curr_cert.SC2SC_message_tree_root) == TRUE` + +The circuit will assume the format previously described for the certificate custom fields (total size of custom fields + bit vector elements and fixed position of the relevant custom fields). + +## References + +[1] [Trustless Cross-chain Communication for Zendoo Sidechains (paper) +](https://arxiv.org/pdf/2209.03907.pdf) + +[2] [Zendoo: a zk-SNARK Verifiable Cross-Chain Transfer Protocol Enabling Decoupled and Decentralized Sidechains](https://www.horizen.io/assets/files/Horizen-Sidechain-Zendoo-A_zk-SNARK-Verifiable-Cross-Chain-Transfer-Protocol.pdf) + + + From 60a492fe59e46c7d5c6a511691e9dc8c460b989e Mon Sep 17 00:00:00 2001 From: Paolo Cappelletti Date: Thu, 26 Jan 2023 16:07:33 +0100 Subject: [PATCH 2/3] updated circuit specifications --- zenip-42205.md | 48 +++++++++++++++++++++++++++++++----------------- 1 file changed, 31 insertions(+), 17 deletions(-) diff --git a/zenip-42205.md b/zenip-42205.md index aded5b3..5077a7b 100644 --- a/zenip-42205.md +++ b/zenip-42205.md @@ -13,11 +13,13 @@ ## Table of Contents -- [Abstract](#abstract) -- [Motivation](#motivation) -- [Requirements](#requirements) -- [Specification](#specification) -- [References](#references) +- [ZenIP-42205](#zenip-42205) + - [Table of Contents](#table-of-contents) + - [Abstract](#abstract) + - [Motivation](#motivation) + - [Requirements](#requirements) + - [Specification](#specification) + - [References](#references) ## Abstract @@ -103,39 +105,51 @@ We will refer to this root with `SC2SC_message_tree_root` **Cryptographic components** -Every sidechain that wants to enable this protocol must use a cryptographic circuit , to allow the creation and verification of the proof of authenticity of the message. The proof will be included inside the redeem message. +Every sidechain that wants to enable this protocol must use a cryptographic circuit, to allow the creation and verification of a SNARK proof of authenticity of the message. The proof will be included inside the redeem message. Sender sidechain will be responsible for its creation, receiver sidechain for its verification. Each proof must be generated for one and only one message. -The proof specification, for a message msg published in a epoch N, is as follow: +The proof specification, for a message msg published in an epoch N, is as follows: Public inputs: - Sidechain commitment tree root of epoch N+1 (`next_sc_tx_commitment_root`) - Sidechain commitment tree root of epoch N (`curr_sc_tx_commitment_root`) -- Poseidon Hash of the message to be redeemed (`msg_hash`) +- Hash of the message to be redeemed (`msg_hash`) Witnesses: +- The ID of the SC (`sc_id`) - A certificate for epoch N+1 (`next_cert`) (can be any certificate, not mandatory to be the top-quality one) -- Merkle path of next_cert data hash inside its sidechain commitment tree (`next_cert_path`) +- Merkle path of `next_cert` data hash inside the subtree of certificates for the SC at epoch N+1 (`next_cert_path`) +- Merkle root of the subtree of forward transfers for the SC at epoch N+1 (`next_fwt_root`) +- Merkle root of the subtree of backward transfers for the SC at epoch N+1 (`next_bt_root`) +- Merkle path of the SC commitment inside the SC commitment tree at epoch N+1 (`next_sc_comm_tree_path`) - Top quality certificate for epoch N (`curr_cert`) -- Merkle path of curr_cert hash inside its sidechain commitment tree (`curr_cert_path`) -- Merkle path of the message to be redeemed inside SC2SC_message_tree_root present in the custom field of curr_cert (`msg_path`) - +- Merkle path of `curr_cert` data hash inside the subtree of certificates for the SC at epoch N (`curr_cert_path`) +- Merkle root of the subtree of forward transfers for the SC at epoch N (`curr_fwt_root`) +- Merkle root of the subtree of backward transfers for the SC at epoch N (`curr_bt_root`) +- Sidechain creation transaction of the SC (`scc_tx`) +- Merkle path of the SC commitment inside the SC commitment tree at epoch N+1 (`curr_sc_comm_tree_path`) +- Merkle path of the message to be redeemed inside SC2SC_message_tree_root present in the custom field of `curr_cert` (`msg_path`) + Statements: -- `VrfyMembership(H(next_cert), next_cert_path, next_sc_tx_commitment_root) == TRUE` -- `VrfyMembership(H(curr_cert), curr_cert_path, curr_sc_tx_commitment_root) == TRUE` +- `next_cert_root = ApplyMerklePath(H(next_cert), next_cert_path)` +- `curr_cert_root = ApplyMerklePath(H(curr_cert), curr_cert_path)` +- `next_sc_root = H(next_fwt_root, next_bt_root, next_cert_root, scc_tx, sc_id)` +- `curr_sc_root = H(curr_fwt_root, curr_bt_root, curr_cert_root, scc_tx, sc_id)` +- `VrfyMembership(next_sc_root , next_sc_comm_tree_path, next_sc_tx_commitment_root) == TRUE` +- `VrfyMembership(curr_sc_root , curr_sc_comm_tree_path, curr_sc_tx_commitment_root) == TRUE` - `next_cert.previous_top_quality_hash == H(curr_cert)` - `curr_cert.epoch == next_cert.epoch - 1` -- `VrfyMembership(msg_hash, msg_path, curr_cert.SC2SC_message_tree_root) == TRUE` +- `VrfyMembership(msg_hash, msg_path, curr_cert.SC2SC_message_tree_root) == TRUE` -The circuit will assume the format previously described for the certificate custom fields (total size of custom fields + bit vector elements and fixed position of the relevant custom fields). +The circuit will assume the format previously described for the certificate custom fields (total size of custom fields + bit vector elements and fixed position of the relevant custom fields). ## References -[1] [Trustless Cross-chain Communication for Zendoo Sidechains (paper) +[1] [Trustless Cross-chain Communication for Zendoo Sidechains (paper) ](https://arxiv.org/pdf/2209.03907.pdf) [2] [Zendoo: a zk-SNARK Verifiable Cross-Chain Transfer Protocol Enabling Decoupled and Decentralized Sidechains](https://www.horizen.io/assets/files/Horizen-Sidechain-Zendoo-A_zk-SNARK-Verifiable-Cross-Chain-Transfer-Protocol.pdf) From c961d91c68b50a4aed16b3057724f5a4065fd0c4 Mon Sep 17 00:00:00 2001 From: Paolo Cappelletti Date: Tue, 30 May 2023 17:38:46 +0200 Subject: [PATCH 3/3] added changes from Victor review --- zenip-42205.md | 41 ++++++++++++++++++++++++----------------- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/zenip-42205.md b/zenip-42205.md index 5077a7b..bdd7e37 100644 --- a/zenip-42205.md +++ b/zenip-42205.md @@ -14,7 +14,7 @@ ## Table of Contents - [ZenIP-42205](#zenip-42205) - - [Table of Contents](#table-of-contents) + - [Terminology](#terminology) - [Abstract](#abstract) - [Motivation](#motivation) - [Requirements](#requirements) @@ -22,6 +22,12 @@ - [References](#references) +## Terminology + +The key words "MUST", "SHOULD", "SHOULD NOT", "MAY", "RECOMMENDED", +"OPTIONAL", and "REQUIRED" in this document are to be interpreted as +described in [RFC 2119](https://tools.ietf.org/html/rfc2119). + ## Abstract This ZenIP proposes the implementation of a cross-sidechain communication protocol, to exchange in a secure way arbitrary messages between two sidechains of the Horizen Ecosystem, as described in [[1]](#references). @@ -63,53 +69,54 @@ We define the following entities: A *cross chain message* is a generic message to be exchanged between two sidechains. It will be composed by the following attributes: -- `sendingScId`: identifier of the sending sidechain -- `receivingScId`: identifier of the receiving sidechain +- `sendingScId: ByteArray`: identifier of the sending sidechain +- `receivingScId: ByteArray`: identifier of the receiving sidechain - `msgType: Int`: Identifier of the type of message. Note this has not to be unique, and will be meaningful only for the upper protocol established by the two sidechains -- `sender`: Address of the creator of the message in the sending sidechain -- `receiver`: Address of the receiver in the receiving sidechain -- `payload`: This is the body of the message exchanged. +- `sender: ByteArray`: Address of the creator of the message in the sending sidechain +- `receiver: ByteArray`: Address of the receiver in the receiving sidechain +- `payload: ByteArray`: This is the body of the message exchanged. Can be any kind of message, meaningful only for the upper protocol established by the two sidechains We also define `msg_hash` as the Poseidon Hash of all the previous fields. A *redeem message* “wraps” the previous cross chain message by adding also the zk-proof of its authenticity, and all the public inputs needed to verify it. It will be composed by the following attributes: -- `message` +- `message: CrossChainMessage` Cross chain message to be redeemed (see previous entity) -- `curr_cert_hash: ByteArray` +- `certificateDataHash: ByteArray` Certificate data hash of the certificate containing the message tree root where the message is committed in the sender sidechain -- `curr_sc_tx_commitment_root: ByteArray` +- `scCommitmentTreeRoot: ByteArray` Sidechain commitment Merkle tree root where the above certificate was committed. -- `next_cert_hash: ByteArray` +- `nextCertificateDataHash: ByteArray` Certificate data hash of a next epoch certificate in the sender sidechain. -- `next_sc_tx_commitment_root: ByteArray` +- `nextScCommitmentTreeRoot: ByteArray` Sidechain commitment Merkle tree root where the above certificate was committed. - `proof: ByteArray` +zk-proof of message authenticity. **Certificate format** -Every sidechain that wants to act as “sender” must emit certificates with the following structure: +Every sidechain that wants to act as “sender” MUST emit certificates with the following structure: `N + M = 32 ` Where: -`M` = number of bit vector elements +`M` = number of bit vector elements (not used by this specific application), where each bit represents the change of a particular leaf in the Merkle state tree. `N` = number of certificate custom fields, all of them of fixed 32 bytes size. A minimum amount of 3 custom fields will be required: fields at position 1 and 2 (0 based) will be reserved for this protocol. -- The custom field at position 1 must contain the root of a Merkle tree built with all the cross chain messages published in the epoch. +- The custom field at position 1 MUST contain the root of a Merkle tree built with all the cross chain messages published in the epoch. Each leaf of the Merkle tree is composed by `msg_hash`. Leaves will be valorized in order of message publication inside the sidechain. We will refer to this root with `SC2SC_message_tree_root` -- The custom field at position 2 will contain the certificate data hash of the previous epoch’s top-quality certificate. +- The custom field at position 2 MUST contain the certificate data hash of the previous epoch’s top-quality certificate. **Cryptographic components** -Every sidechain that wants to enable this protocol must use a cryptographic circuit, to allow the creation and verification of a SNARK proof of authenticity of the message. The proof will be included inside the redeem message. +Every sidechain that wants to enable this protocol MUST use a cryptographic circuit, to allow the creation and verification of a SNARK proof of authenticity of the message. The proof will be included inside the redeem message. Sender sidechain will be responsible for its creation, receiver sidechain for its verification. -Each proof must be generated for one and only one message. +Each proof MUST be generated for one and only one message. The proof specification, for a message msg published in an epoch N, is as follows: Public inputs: