A ZK-based multi-blockchain transaction layer for minimal trust base

Abstract

In the realm of blockchains, synchronization challenges are two-folded. First, smart contracts from different blockchains cannot communicate with each other, making it hard to establish a trustworthy communication channel to share and maintain a universal state between each other. Second, transactions on different blockchains can hardly be ordered. Hence interference is expected. We need a novel way to handle interference. Traditional solutions involving third parties have safety and liveness issues and thus compromise between safety, permissionless, and liveness. ZK Multi-Blockchain Aggregatoris a multi-blockchain execution layer that leverages the power of zero-knowledge proof to minimize the trust base of multi-blockchain communication, which does not compromise safety, liveness, permissionless, and atomicity. In contrast to traditional blockchain bridges performing transactions on different blockchains separately and using a relay system to enforce the order of transactions and prevent interference, our method uses an entirely new approach, such that for each multi-blockchain transaction, it simulates the multi-blockchain transaction in its aggregator chain. Our aggregator uses zero-knowledge proofs of the simulation to convince involved blockchains to update their local state accordingly. On top of this layer, rich applications over multi-blockchains can run safely and efficiently.

Full text

Translate

Turn on search term navigation

Introduction

As an emerging distributed computing paradigm, blockchain is rapidly evolving in areas such as digital finance, supply chain traceability (Hastig and Sodhi 2020), IOT systems (Minoli and Occhiogrosso 2018), secure data sharing (Feng et al. 2021). Existing blockchain projects adopt different blockchain architectures and protocols for domain-specific purposes. Consequently, it is generally tricky for different blockchain systems to share information and coordinate with each other. Hence, different blockchains are born isolated islands, limiting blockchain technology’s overall usability, functionality, and scalability of blockchain technology (Anati et al. 2013).

To build a cross-chain application, we have to solve two problems. One is the communication issue, as there is no proper way for a blockchain to query the state of another. This issue is rooted in blockchains’ decentralized computing system, containing many nodes connected over a peer-to-peer network. In such a system, a successful transaction must be audited on multiple nodes, meaning a transaction’s result depends only on the blockchain’s internal states. Otherwise, the transaction result will be inconsistent between different auditing nodes. The other issue is the interference problem, as different blockchains behave concurrently and can hardly coordinate with each other.

For example, in a cross-chain decentralized exchange (Zetzsche et al. 2020), a typical scenario of multi-chain communication, suppose that Alice would like to swap one token from Bob on blockchain $C_{A}$ by spending one pass on blockchain $C_{B}$ , then it follows that at least two transactions $t x_{A}$ (Alice gets a token from Bob on blockchain $C_{A}$ ) and $t x_{B}$ (Alice pays a token to Bob on blockchain $C_{B}$ ) are executed atomically.

Moreover, $t x_{A}$ and $t x_{B}$ must be executed in a safe manner that either both of them succeed, or both fail. If not, Alice loses a token on blockchain $C_{B}$ , or Bob loses a token on blockchain $C_{A}$ . However, since $t x_{A}$ cannot access any information from $t x_{B}$ and $t x_{A}$ cannot prevent Bob from performing other transactions after $t x_{A}$ , and before $t x_{B}$ , a protocol needs to be designed to achieve a safe swap.

To address the communication and synchronization problem, many protocols are developed in the literature, including time hash lock (Poon and Dryja 2016), interledger’s stream protocol (Zhang et al. 2021), relay system (Lys et al. 2021), SPV (Nakamoto 2008), sidechain (Singh et al. 2020; Deng et al. 2018), sidechain with ZKP (zero-knowledge proof) (Westerkamp and Eberhardt 2020). Most of them introduce relayers (Sun et al. 2020; Warren and Bandeali 2017) to establish an information channel from the source blockchain A to the target blockchain B as in Fig. 1.

[See PDF for image]

Fig. 1

Forwarding message using a relayer

The primary security challenge regarding the module in Fig. 1 is that we require the relayer to be honest and authorized. A centralized relayer is built such that chain B only accepts information reported from a trusted relayer. In such a solution, safety is enforced since the trusted relayer signs all their messages with their private key, and $t x_{B}$ in chain B checks the signature accordingly. However, with such a centralized setup, the relayer becomes one of the most essential trust bases for the protocol, leading to single point of failure (SPOF) if it is hacked or misbehaved.

To take a step further, we consider two bundled transactions, $T_{1}$ and $T_{2}$ . $T_{1}$ contains $t x_{A}^{1}$ on blockchain $C_{A}$ and $t x_{B}^{1}$ on blockchain $C_{B}$ . $T_{2}$ contains $t x_{C}^{2}$ on blockchain $C_{C}$ and $t x_{B}^{1}$ on blockchain $C_{B}$ . It follows that the safety property requires transactions in $T_{1}$ and $T_{2}$ to both succeed or none of them succeed. In such a scenario, the safety of the relayer does not enforce the safety of the bundled transactions as there might be interference between the execution of $T_{1}$ and $T_{2}$ (e.g., the execution sequence is $t x_{A}^{1}$ , $t x_{C}^{2}$ , $t x_{B}^{1}$ , $t x_{B}^{2}$ ).

Suppose a protocol is designed to help carry out such bundled transactions between blockchains. We define the safety, permissionless, liveness, and linearizability properties of the protocol as follows:

Permissionless. Any nodes of a certain blockchain are allowed to join the communication network.

Safety. All state updates for a single transaction are successful or fail on all blockchains.

Liveness. All valid transactions will eventually succeed on all blockchains.

Linearizability. All concurrent successful transactions are always linearizable so that the consequent state of a group of concurrent transactions is equivalent to performing the transactions sequentially in a special order that respects the happen-before relation of the original order.

Although various solutions try to tackle the above properties, they usually restrict the scope of use cases to transactions in two blockchains where the atomicity and liveness properties are more straightforward than in multi-chain scenarios.

The main idea of this work is to use a coordinate layer to simulate the execution of bundled transactions that spreads over different native chains before running them directly. Once the simulation proved to be successful, the coordinate layer will convince all the blockchain to accept the final state of the execution result. For such plan to work, the native block needs to verify the simulation result without rerun the simulation (which is, by nature, not possible since the native block chains can not access other chain’s state). The key to convince the native blockchain of the simulation result lies in the use of the increasingly mature SNARK technology which is build on top of Polynomial Commitment schemes (PCS) (Boneh et al. 2020a, b; Kate et al. 2010). PCS provide a new way to convince others that the polynomial has specific evaluation at a certain point without redoing the calculation. Based on this technique, Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (ZKSNARK) (Petkus 2019; Groth 2016; Chiesa et al. 2020; Gong et al. 2022; Setty 2020; Fiore and Nitulescu 2016) is often used to prove that a statement is true without revealing any information beyond the validity of the statement itself.

There are some existing exploration of ZKSNARK in cross-chain communication (Westerkamp and Eberhardt 2020; Cao and Wan 2020; Garoffolo et al. 2020) mainly focuses on communications between two blockchains by providing a secure (ZKP backed) relayer.

Contributions. This paper makes the following contributions:

We consider a general case of multi-chain bundled transactions and provide a novel way to preserve the linearizability of transactions across multiple blockchains. In particular, instead of executing multiple transactions on different blockchains and using relayers to synchronize them, we simulate the transactions on our aggregation layer and generate ZKP to convince involved blockchains to update their state accordingly.
Our approach not only enforces linearizability naturally but also allows transactions to be designed to have a view of multichain states. If a traditional two-chain transaction contains $t_{1}$ and $t_{2}$ , then $t_{1}$ only sees the state on blockchain $C_{1}$ , and $t_{2}$ only sees the state of blockchain $C_{2}$ . By using our approach, $t_{1}$ and $t_{2}$ can both see the global state of $C_{1} \times C_{2}$ .
We provide a permissionless solution by encoding the consensus algorithm of our aggregation layer into ZKP. By doing so, a user can trigger bundled transactions not only on the native blockchain but also on our aggregator chain. It is technically challenging as we must prevent dishonest nodes that systemically ignore transactions triggered on the aggregator chain.

While there are many existing protocols designed for specific scenarios, and they focus on preserving different properties with various trust bases, ZK Multi-Blockchain Aggregatortargets to achieve liveness, safety, permissionless, and linearizability properties by using zero-knowledge proof to provide a universal layer that synchronizes states between different smart contracts on different blockchains, and this layer together with its communication protocol can be used as a multi-blockchain communication framework.

Paper Organization. This paper is organized as follows: We define bundled multi-blockchain transactions and introduce a few standard techniques used in our protocol in Section 2. The details of each protocol component are explained in Section 3. In Section 4 we prove that permissionless, liveness, safety, and linearizability properties are preserved in our solution. In Section 5, we evaluate the implementation via the size of our ZKSNARK circuits and the transaction execution time. In the end, we review related works in the literature in Section 6 and draw a conclusion in Section 7.

Preliminaries

We briefly review several critical concepts, and refer to Robinson (2021) for a detailed description of these concepts.

Blockchain. A blockchain is a distributed database shared among a network of distributed nodes (Chen et al. 2018). As a database, transactions are first submitted and organized in blocks, while each block is a data structure that records the most recent transactions which have not yet been validated. Once a block is validated, the state of the whole distributed database is updated accordingly.

Bundled multi-blockchain Transaction. We use C (with possible subscripts) to denote a particular blockchain system with distributed nodes. For a blockchain $C_{k}$ indexed with k, We use $S_{k}$ to denote the whole state of a blockchain $C_{k}$ and $s_{k}$ to describe a partial state in $S_{k}$ .

Given a group of blockchains $C_{1}, C_{2}, \dots, C_{k}$ , we say a transaction tx is a bundled multi-blockchain transaction if it is composed of a sequence of transactions $t x_{k_{0}}^{0}$ , $t x_{k_{1}}^{1}$ , $\dots$ $t x_{k_{j}}^{j}$ such that the jth sub-transaction $t x_{k_{j}}^{j}$ is executed on $C_{k_{j}}$ locally. We use $s = ⟨ s_{1}, s_{2}, \dots, s_{k} ⟩$ to denote the underlying global state of tx where $s_{k}$ is the projection of s on the blockchain $C_{k}$ . Moreover, each local transaction $t x_{k}^{j}$ is executed on the partial state of $s_{k}$ in $C_{k}$ . The behavior of each $t x_{k_{j}}^{j}$ can depends on the global state s but only the local state $s_{k_{j}}$ is mutable in $t x_{k_{j}}^{j}$ .

Aggregator Chain. An extra blockchain named aggregator chain is introduced to store the global state s, which is distinguished from other blockchains $C_{k}$ involved in a bundled multi-blockchain transaction tx. Moreover, we call the other blockchains native chains.

Merkle Tree Encoding of a Global State. Merkle tree (Becker 2008) is a tree (see Fig. 2) in which each leaf node is labeled with the cryptographic hash ( $P = h a s h (l e a v e s)$ ) of a data block and every non-leaf node is labeled with the cryptographic hash of the labels of its child nodes. Each data block has a unique Merkle tree index (MTI), and each MTI encodes a unique path from top to leaf.

[See PDF for image]

Fig. 2

Merkle tree structure

State Pinning. State Pinning (Robinson and Brainard 2019) includes the state of one blockchain in another blockchain. In our scenario, instead of pining the native chain state in another blockchain, we represent our global state as a Merkle tree and use the Merkle root hash to pin the global state in native blockchains to ensure that the global state used in the simulation of transactions is consistent (see Fig. 3).

[See PDF for image]

Fig. 3

State Pinning

Side Effect. We denote the changes of $t x_{i}^{k}$ on chain-state $C_{k}$ other than the partial state $s_{k}$ to be the side effect $e_{k}$ of $t x_{i}^{k}$ . Side effects include emitting events on native chains or native chain contract calls.

ZKSNARK. ZKSNARK (Mayer 2016) combines SNARG (Succinct non-interactive arguments) and ZKP, providing a way for a prover to convince a verifier that he knows certain information by providing a ZKP. The succinct property here means the verifier can verify the proof with succinct time.

Polynomial Commitment Schemes. Polynomial commitment schemes (PCS) (Boneh et al. 2020a, b; Kate et al. 2010) provide the ability to commit to a polynomial over a finite field and prove its evaluation at points. A succinct PCS has commitment and evaluation proof size sublinear in the degree of the polynomial. An efficient PCS has sublinear proof verification and can be used to construct the ZKSNARK (Mayer 2016) with similar security and efficiency characteristics.

Proof of Program Execution. We use ZKSNARK as the crucial tool to prove a native blockchain with a pre-defined program is executed correctly. The succinct property is fundamental as it ensures the proof verifying effort is neglectable compared to running the pre-defined program on a native blockchain. Furthermore, the zero-knowledge property (Cramer and Damgård 1998; Kate et al. 2010; Damgård 1998) is essential for the prover to convince a verifier that a program is executed correctly without leaking any private information.

Protocol details

ZK Multi-Blockchain Aggregatorderives the basic ideas from a multi-way sidechain (multiple blockchains with a shared sidechain) and solves the trustworthy problem of the third parties by verifying the simulation from the sidechain via ZKSNARK proofs. In our protocol, the specific sidechain is represented as an aggregator chain and involved blockchains as native chains. More precisely, instead of executing transactions in a particular order in a bunch of native blockchains, we execute the following (see Fig. 4):

We map the local state $s_{i}$ of each block chain $C_{i}$ into the aggregator chain to form a global state $s = ⟨ s_{0}, s_{1}, \dots ⟩$ .
We perform a simulating run of the bundled transactions over s on the aggregator chain to get a resultant state $s^{'} = ⟨ s_{0}^{'}, s_{1}^{'}, \dots ⟩$ and create ZKPs to convince each native chain $C_{i}$ that after the bundled transaction executed, its local state is changed to $s_{i}^{'}$ .
We ask every native chain $C_{i}$ to change their local state by providing them the resultant state $s_{i}^{'}$ and the ZKP.

[See PDF for image]

Fig. 4

Overview of ZK Multi-Blockchain Aggregator

State abstraction of asset transfer

We use the standard asset transfer process from Alice on chain $C_{A}$ to Bob on chain $C_{B}$ through a liquid provider in $C_{A}$ and $C_{B}$ (Jensen et al. 2021) as an example.

First, we abstract our local state $s_{A}$ of $C_{A}$ and $s_{B}$ of $C_{B}$ separately as follows.

As described in Section 2, the underlying global state s of transfer is a tuple of $C_{A}$ and $C_{B}$ :

Second, the bundled transfer transaction tx is defined as a function on global state s as follows (see in Fig. 5),

[See PDF for image]

Fig. 5

Transfer Transaction

Line 2 can be treated as the invoke transaction on $C_{A}$ , lines 4–12 are bundled transactions that will be simulated on the aggregator layer, and line 11 is the side effect on $C_{B}$ .

Unlike other bridge-like solutions performing lines 2–5 on $C_{A}$ , lines 7–11 on $C_{B}$ , and using relayers to synchronize two parts, we simulate the transaction in the aggregator chain on global state s and then use ZKP of the simulation to convince native blockchains to update their local states.

ZK multi-blockchain aggregator node

In a blockchain setting, we combine the finalizer, storage component, transaction handler and native chain monitor (everything except proxy contracts on native blockchains) together, and equip it with an extra consensus component into a ZK Multi-Blockchain Aggregatornode. These distributed ZK Multi-Blockchain Aggregatornodes form a blockchain that works together to synchronize and alter states among native blockchains. Each component in the node performs the following task:

Chain Storage Component:
- store the global state.
- store the Merkle root hash of the whole state.
- store the valid voter list and the Merkle root hash of all voters.
Transaction Handler and Simulator.
- order aggregator chain transactions under consensus.
- process transactions and update the whole state.
- emits transaction events (with execution order).
Native Chain Monitors:
- handle event emitted by invoke transaction of a bundled transaction.
- handle event emitted by revoke.
Transaction Finalizer:
- calculate transaction execution proofs.
- calculate proofs of consensus.
- submit proofs to a guest chain for validation and finalization.
Consensus Component:
- performs consensus algorithm (voting block generator).
- calculate the ZKP of the consensus algorithm.
- generate and prepare block.

Finally, the proxy contract on the native chain is also an essential component of ZK Multi-Blockchain Aggregatoras it is used to maintain the partial state of a particular native chain by performing proof verification, state updating, and processing the side effects of each transaction during the finalizing stage.

For example, suppose we have two blockchains $C_{A}$ and $C_{B}$ . Then our single ZK Multi-Blockchain Aggregatorinvolves the entities in Fig. 6.

[See PDF for image]

Fig. 6

Protocol components

Transaction llife cycle

In ZK Multi-Blockchain Aggregator, the global state is compressed as a Merkle hash tree and pinned in all the guest chain proxy contracts. A bundled transaction tx is a set of operations $t x_{i}^{k} : s_{k} \mapsto s_{k}^{'}$ . By defining how the local state $s_{k}$ of the application can be changed through $t x_{i}^{k}$ , tx can be treated as a function on the global state s. For a transaction to be successfully executed in ZK Multi-Blockchain Aggregator, it undergoes the following four stages: (see Fig. 7)

[See PDF for image]

Fig. 7

Transaction life cycle

Consensus Stage: As a decentralized protocol, a transaction will only be handled once collected in a block. Each block is produced by an elected node under a pre-defined consensus algorithm. A node winning the consensus game must provide a ZKP later be used as evidence to finalize all transactions within the block on the guest proxy contract.

Simulating Stage: At the simulating stage, an operation is simulated on ZK Multi-Blockchain Aggregator, changes the global state, and thus changes the Merkle root. During the simulation, all the information to create a ZKP for the simulation is prepared and stored. Since all transactions are handled sequentially regarding their order in a particular block, their proofs are stored in the same order to be batched in the proving stage.

Proving Stage: After the simulating stage, the finalizer generates proofs for every transaction and compresses proofs into a single ZKP. This proof is appended after the transaction information in the block with an updated Merkle tree hash.

Finalizing Stage: Once the finalizer generates the proof of batched operation sequence, it will broadcast to various underlying blockchains. Each blockchain verifies the proof, performs side effects, and emits an acknowledgment event to finalize the transaction.

Protocols in each stage

Consensus Stage. A consensus algorithm is a common process in blockchain to achieve agreement on value or state among distributed nodes, which is critical in systems that contain permissionless unreliable nodes. In ZK Multi-Blockchain Aggregatorwe need a consensus algorithm for the following purposes:

Decide the order of the bundled cross-chain transactions.
Enroll and identify a valid node.
Vote a node to produce the next block and finalize its transactions.

We use a modified PBFT (Castro et al. 1999) consensus algorithm between chain nodes to vote for a block generator. Recall that PBFT consensus consists of three phases: pre-preparation, preparation, and commitment. At the Pre-preparation stage, the primary node is responsible for verifying the requests and generating corresponding pre-preparation messages. In the preparation stage, the primary node broadcasts pre-preparation messages to all Replica nodes. After receiving the messages, Replica nodes will verify those pre-preparation messages and broadcast a corresponding prepared message in the commitment stage.

The final step is carried out on native chains. The results are not broadcast back to Replica nodes but to native chain nodes and verified there. Moreover, in addition to verifying that the results are correctly calculated, we must convince the guest chain that our generated blocks are produced under the consensus protocol. Since the native chain does not attend the consensus algorithm in the aggregator chain, it has the problem of checking whether the transaction results are reported from a fairly picked node. We must encode the consensus algorithm and its result into a ZKP so that we can confirm the guest proxy contract, in which the block contains all transactions generated legally. The consensus result and its ZKP are stored in a newly generated block.

To satisfy all the above requirements, our modified PBFT approach consists of three phases, as described below.

First, at the pre-preparation stage, a node is registered as a valid block-generating candidate and broadcasts the ZKP of the validation to other nodes. During the voting (preparation stage), each aggregator chain node in the consensus stage places a vote and sends a signature of the vote to their voting target. If two-thirds of the nodes in the system are honest, only one potential node will win the voting game, and this particular node is authorized to produce a block.

Second, after the particular node gathers enough voting messages, instead of broadcasting the result, the winner node calculates the ZKP of the consensus algorithm and put it into its generated block. This ZKP is later used to convince the native blockchains that a batched transaction proof is sent from a legally voted node. Once the proof is attached to a newly generated block, the winner node will start producing transactions (see Fig. 8).

[See PDF for image]

Fig. 8

Voting process during consensus in aggregator layer

Third, the winner node will broadcast the generated block to the native blockchains. ZK Multi-Blockchain Aggregatorproxy contract on the native blockchain will verify and finalize this block and update its local state accordingly.

ZK Multi-Blockchain Aggregatortargets to build a permissionless chain that everyone can join the aggregator chain to help to synchronize bundled cross-chain transactions. This means we need to provide a protocol to register and remove a valid voter. To achieve that, ZK Multi-Blockchain Aggregatorkeeps a Merkle tree of all valid nodes by tracking their public keys as Merkle tree data nodes, and anyone can register to be a valid node by registering itself as a new Merkle tree leaf. Also, for an aggregator node to vote for the next block producer, it has to prove the target it votes for is a valid Merkle tree node (a registered valid node) first and then sign and send his voting ticket to the voted node. More precisely, anyone can do the following:

Register a node for voting: Node registration is an aggregator chain transaction that updates the Merkle tree of all valid voters on the aggregator chain and has the side effect of updating the Merkle tree root hash of nodes in the guest proxy contract. It is responsible of every aggregator node to keep the registration tree updated so that the root hash is consistent with the pinned hash in the proxy contract.
Validate a voter: When a node receives voting from another node, it validates that the sender is a valid voter. If the sender is an invalid node (e.g. a malformed node without registration), the proof of sufficient voter will fail at the stage of finalizing, thus wasting the computing source of the node who voted.
Recall that all the valid voters are arranged in a Merkle tree whose root hash is pinned in the guest proxy contract. The voter provides identity proof through ZKP to show that his public key or voting address is one of the Merkle tree leaf nodes.
Once a node receives voting from a voter, it needs to verify the identity proof before pushing to the list of its supporters for the next block generation round.
Send a valid vote ticket: A voting ticket contains two parts, a signature, and a validation proof. The signature is signed from the current block height together with the Merkle root hash of all valid voters. The validation proof is a ZKP that the voter is one of the valid voters.

Remark

Although PBFT assumes an honest majority, the failure of such assumption will only introduce dishonest on picking and ordering transactions. Since the execution correcetness is enforced by SNARK proofs, onchain verifier can still reject uncorrect execution results.

Simulation Stage. After a node is voted a block generator, it collects transactions from various sources. In ZK Multi-Blockchain Aggregator, transactions are submitted to the aggregator node via three sources (see Fig. 9).

[See PDF for image]

Fig. 9

Simulation stage

1. The pure bundled transaction that does not contain an invoking transaction: A pure bundled transaction should be sent directly to ZK Multi-Blockchain Aggregatornodes, and all its internal sub-transaction should either succeed or fail. Notice whether each sub-transaction will succeed (or all fail) can be determined via simulation in the aggregator node. The finalizer only finalizes successful transactions.

2. The bundled transaction that starts with an invoking transaction: This kind of bundled transaction is similar to the pure bundled transaction except that its first sub-transaction (and only the first sub-transaction) cannot be simulated by the aggregator node. When handling this kind of transaction, the first transaction is executed on the native-block chain first, and the aggregator node monitors the result of the first transaction. If the first transaction is succeeded, the monitor submits the following transaction to the aggregator node. If not, the monitor submits a revoke transaction to the aggregator, which will trigger a revoke of the invoking transaction just performed on the native chain.

3. System transactions: These kinds of transactions are submitted by aggregator nodes, containing voting transactions, voter registration transactions, voter quit transactions, etc.

Proving Stage. As we discussed before, we simulate bundled transactions of the global state on the aggregator chain node, and each bundled transaction is equivalent to a function $f : s \mapsto s^{'}$ . Since the global state is pinned on the native chain by the Merkle hash root h(s) of the state, a zero-knowledge proof of bundled transactions tx is proof that ensures the Merkle hash root of the result state $s^{'} = f (s)$ is valid.

[See PDF for image]

Fig. 10

State refinement of transaction circuit

For example (see Fig. 10), suppose that, before the transaction, state s is encoded into the Merkle hash tree mht, which has root hash r. After simulating the transaction, the state changes to $s^{'} = f (s)$ . Also, suppose that this new state is stored in the aggregator chain storage in a format of updated Merkle tree $m h t^{'}$ whose new root hash is $r^{'}$ . Then we need to create a zero-knowledge proof to show that the following constraints hold. $\begin{matrix} c o n s t r a i n t s = \{\begin{matrix} r = r o o t (m h t (s)) \\ r^{'} = r o o t (m h t (s^{'})) \\ m h t (s^{'}) = m h t (f (s)) \end{matrix}) \end{matrix}$ where the first two constraints are constraints about the state before and after the transaction, and the last constraint is about the simulation of the function f, which is a combination of the following:

simple Merkle tree leaf update.
predefined functions that have predefined ZKP circuits.
cryptographic functions including signature functions and hash functions.

Finalizing Stage. We know that a bundled transaction tx is a state transformer over global state s and is composed of a sequence of sub-transactions

t x_{k_{j}}^{j}

C_{k_{j}}

. During the finalizing stage, ZK Multi-Blockchain Aggregatormainly performs three things. First, it checks the ZKP of the consensus algorithm to make sure the block is generated by a valid block producer. Second, it checks the ZKP of the simulation of tx so that the proxy contract can safely update the local state on

C_{k_{j}}

. Third, the proxy contract performs the side effects of

t x_{k_{j}}^{j}

C_{k_{j}}

(e.g., if a user would like to withdraw some asset from the aggregator chain to the guest chain, then during the finalizing procedure a transfer from the guest chain proxy contract to the target account of the withdrawal is executed).

Guest proxy contract

Guest Proxy Contract contains two parts: guest chain interface and verification interface (see Fig. 11). Both of them manipulate the local state of guest chain. The guest chain interface includes invoke and revoke which allows guest chain users to invoke or revoke a transaction. The verification interface is called by ZK Multi-Blockchain Aggregatornode to finalize transactions.

[See PDF for image]

Fig. 11

Local state of guest proxy contract

Guest chain interface

When a user invokes a guest chain interface, the transaction info with the current block height (h) is recorded in the pending queue of the guest local state. The user who performed invoke transaction can revoke his invocation any time when the transaction remains in the pending queue after a fixed amount ( $δ_{h}$ ) of the block. This means ZK Multi-Blockchain Aggregatornodes have to notice and handle this event and finalize this event within $δ_{h}$ blocks.

Verification interface

The verification interface verifies the ZK-SNARK proof generated by the aggregator chain node (see Section 2.5).

[See PDF for image]

Fig. 12

Verification API in Native Blockchain

Recall that only the winner of the voting consensus of the current finalizing round (rid) is authorized to invoke the verification interface at round rid. It follows that the verification function (see Fig. 12) first checks the voting proof to ensure that the sender is the winner of round rid and then checks every transaction encoded in tx_data is executed honestly via verifying the ZK proof encoded in verify_data. If both check pass, the guest contract will perform all the side-effects of transactions on the guest chain accordingly (see Fig. 13).

[See PDF for image]

Fig. 13

Perform side effects of a bundled transaction

Types of transaction side-effects during finalization:

Invoke: An invocation tx on the aggregator chain must be related to an invocation call on a guest contract, since every time a guest chain invocation will cause a record of pending invocation to be added to the pending list in the local state of the guest contract. Once an invocation tx is verified, the side effect of that tx is removing the invocation record in the pending invocation list. Once an invocation is removed from the pending invocation list, its sender loses the capability to withdraw it.
Callback: The callback is a special transaction that is invoked through ZK Multi-Blockchain AggregatorNode which tries to trigger a certain callback function from ZK Multi-Blockchain Aggregatorchain to guest chain. Once a callback tx is verified, its side effect is to call a related guest contract API according to the tx information. Withdraw is a special case of callback that calls the transfer API.
Generic Transaction: All bundled transactions are simulated in aggregator nodes and the global state is pinned to the guest contract. So there is no other side-effect during the process of finalization for generic transactions.

Guest chain monitor

Guest chain monitor is responsible for monitoring guest chain events and notifying aggregator chain tx handlers by forwarding them. To make sure the guest chain monitor is honest, it needs to sign the blockhead of the guest chain and provide a ZKP proof of the event by encoding the attestation algorithm (for more details about using ZKP to secure the guest chain monitor please refer to Westerkamp and Eberhardt 2020).

Remark

It is worth mention that, our attestation test only requires the check of the root of the merkle root of the result state of the execution. If a voted ZK Multi-Blockchain Aggregatornode fails to finalize its transactions in the guest chain proxy contract, then it either fails to calculate a correct ZKP proof of transactions and voting result or it does not pass the checks in the side-effect of invoking transactions in the guest contract. In the later case, the failed node could be a malicious node that provides invoking transactions that do not exist on the guest chain.

Properties that the protocol guarantees

This section shows that our aggregator chain has permissionless and liveness properties. Moreover, the protocol between the aggregator and guest chains ensures the safety and linearizability for all bundled multi-blockchain transactions.

Permissionless poperty

ZK Multi-Blockchain Aggregatoris a decentralized layer that anyone can join the network to help synchronize cross-chain bundled transactions. To prove permissionless, we need to show that although any running node performs multi-blockchain transactions, the data stored in the chain is consistent, and all local data in distributed nodes converge.

Given a group of bundled transactions $T = \{t, x_{i}\}$ submitted simultaneously, a valid trace from a start point of global state s is a sequence of global state $s_{0} = s, s_{1}, \dots s_{n} = s^{'}$ . Different orders of $t x_{k}$ from the same $T$ lead to different valid traces. Thus we need a consensus algorithm to vote for a unique block producer to generate a globally valid trace.

We use a Merkle tree to record all the valid voting nodes and pin the root hash of the Merkle tree in native blockchains. If a new node registers itself as a valid node, it must fire a register transaction on the aggregator chain and synchronize the root hash before the vote.

To vote for a node, a voter signs a voting message and sends the message to the target it votes. The message contains the Merkle root hash of all valid voters’ and targets’ public addresses. Once a node receives a sufficient number of voting tickets, it will produce a zero-knowledge proof showing that the total number of tickets reaches two-thirds of the total number of voters and that all have the correct Merkle root hash.

After the winner node calculated the ZKP proof of all the received signatures, it starts producing a block that represents a valid sequence of bundled transactions $T$ (see Fig. 14). This process is executed locally, and the block producer can pick any order of $t x_{i}$ in the final sequence as long as it can generate a ZKP proof of the simulation. Once the block is generated, it must be sent to the native blockchains $C_{i}$ to finalize before it is recorded in the ZK Multi-Blockchain Aggregatorchain ledger.

[See PDF for image]

Fig. 14

Produce a block after voting

As the consensus algorithm solves the ordering problem, it remains to ensure the winner node cannot produce a partially finalized block (finalize the block to a subset of the native blockchains). Thus we need a strategy to continue finalizing the block even if the winner node quits after generating the block. To achieve this, we record the proof data on the native chain $C_{i}$ during finalization so that if a block is partially synchronized, all ZK Multi-Blockchain Aggregatornodes will notice the recorded proof and can continue broadcasting it until it is fully synchronized. Moreover, if the winner does not finalize its block to any of the native chains, we rely on the liveness property to ensure another block generator can be voted.

Liveness property

We abstract the state transition diagram as follows (see Fig. 15) and would like to show that all intermediate states lead to either a full finalizing state or a skip state.

[See PDF for image]

Fig. 15

State transition

Notice that in the protocol, the interesting state is $s_{4}$ in which the block is generated, and some nodes may suspect that the finalizing stage is halted and vote to skip the current round. If any of the nodes notices that the block is partially finalized on a subset of native blockchains, then it leads to $s_{5}$ , and there is no need to skip. Otherwise, the current round is skipped. Thus the final state of all native-block chains converges to the same state.

Safety property

Recall that for a bundled transaction $t x = t x_{i}$ , the safety property of a protocol to carry out tx is that either all $t x_{i}$ succeeds or none of them succeeds. We discuss the safety property of ZK Multi-Blockchain Aggregatorin three scenarios.

First, we show that the safety property holds if a transaction tx does not have an invoke transaction or any side effects. Second, we further prove that if all side effects are safe then the safety property still holds. Finally, we show that if the first transaction of a bundled transaction tx is an invoke transaction, then we can rely on our liveness property to ensure that if the invoke transaction succeeds then all sub transactions in tx will eventually be finalized.

1. Bundled transaction with no invoke transaction and side-effects If a bundled transaction does not start with an invoke transaction, then it means the bundled transaction is invoked directly on the aggregator chain. Because all components $t x_{i}$ of tx are simulated and performed on the aggregator chain and a proof of the execution of tx cannot be generated if any $t x_{i}$ fails during the simulation, a transaction can only be executed as a whole.

If the proof is valid and is submitted to native chains then it will pass the validation check and then we expect that the local state of the native chain will change accordingly with no exception.

Since the liveness property promises that all native chains will eventually receive valid proof, it remains to show that the state updating protocol in our proxy contract is safe. A smart contract is a code that cannot be changed once deployed, its behavior is fixed and predictable. Thus we assume that our proxy contract always performs correctly according to its pre-defined functionality. Suppose that s is the start global state with hash MTH(S), tx is the transaction, $s^{'}$ is the final state with hash MTH(S) and $p (M T H (s), M T H (s^{'}), t x)$ is a zero-knowledge proof which proves that $t x (s) = s^{'}$ . Then our proxy contract will perform the following:

Proxy contract checks that pined local global hash equals MTH(s). This ensures that the current local state $s_{i}$ is consistent with the global state s.
Proxy contract verifies the proof $p (s, s^{'}, t x)$ . Once the verification succeeds, it can guarantee that $s^{'}$ is a valid final state after simulating tx over s thus, the state update protocol is predictable and safe.
Compute the changes of $s_{i}$ and change the local state from $s_{i}$ to ${(s_{i})}^{'}$ .

2. Bundled transaction with side-effects. Notice that side effects are the only place where a finalizing call will fail even if the proof is correct. To address this problem, we break down side effects into two categories. The first category contains side effects like emitting events, logging, or pure history recording, which are naturally safe since they will never fail by design. The second category includes unsafe function calls like assets transfer. This kind of unsafe function can still be safe if we perform sanity checks in tx.

3. Bundled Transaction with an Invoke Transaction. If a bundled transaction tx starts with an invoked transaction $t x_{0}$ on $C_{i}$ , then this invoke transaction on chain $C_{i}$ triggers the execution of the bundled transaction tx by emitting an invoking event. This event is reported to the aggregator chain through a native chain monitor.

The aggregator chain bundled transaction simulator relies on the honesty of the reporter and if the relayer is hacked it can exploit the protocol by reporting malformed results of the invoke transaction. For example, in the transfer scenario, if a report reports the wrong amount of assets that have been transferred from Alice to Bob in Chain A then a successfully finalized tx will trigger a wrong transfer from Bob to Alice on Chain B. To resolve this problem, we uses the technique presented in Garoffolo et al. (2020), Westerkamp and Eberhardt (2020) which is supplying the ZKP of the attestation check of the event to the aggregator chain.

In this scenario, we split the process of the changes of global state s into two stages. At the first stage s is changed to $s^{'}$ after invoke transaction and in the second stage $s^{'}$ is changed to $s^{''}$ after the whole simulation of tx. During the first stage, $s^{'}$ is pinned in native chain $C_{i}$ once the invoke transaction is executed, and the second stage is encoded by a zero-knowledge proof generated from ZK Multi-Blockchain Aggregatornode. During the finalization, the proof of tx now encodes the proof from $s^{'}$ to $s^{''}$ .

Linearizability property

In concurrent programming, an operation (or set of operations) is linearizable (Herlihy and Wing 1990) if it provides the illusion that each operation takes effect instantaneously at some point between its invocation and its response. Since in each block generation round only one node wins the right to produce a block, the linearizability hold if and only if the final state simulated in the block can be represented as a sequence of bundled cross transactions ${t x_{i}}$ . Since each block producer needs to create a zero-knowledge proof to show that $s^{'} = t x_{k} \circ t x_{k - 1} \circ \dots t x_{0} (s)$ (where $\circ$ is function composition), a valid proof already shows the linearizability property. Thus in ZK Multi-Blockchain Aggregatorprotocol, the linearizability property holds trivially.

Implementation and evaluation

Code Base for ZK Multi-Blockchain Aggregator We implemented the Aggregator chain based on Substrate (Substrate 2014). The substrate is a blockchain development kit that allows users to customize by combining rich blockchain building blocks. We start with a standard Substrate setting and build our ZK Multi-Blockchain Aggregatorby providing our own consensus, simulation, and finalizing components. As described in Section 3.4, the verifying process is done on native blockchains. Thus the main performance cost is spent on the ZKP part during the consensus, simulation, and proving stage. Since the ZKP performance is highly related to the CS (constraints size) of ZKP circuits, below, we will mainly use the number of constraints to measure performance. The reason we use substrate is because it support customized pallets which simplifies the protocol implementation. In theory, any blockchain that supports SNARK verifier contracts can be used as our aggregation layer.

Consensus Component. Recall that the consensus component needs to provide a ZKP circuit for registering a valid node, validating a registered node, and voting the node to generate a new block. We use the ECDSA signature on BabyJubJub (WhiteHat et al. 2020) curve to reduce the circuit size. Also, the voting process can be split into two parts: a voter needs to generate and send the ticket to the target, and the winner needs to prove that he has received sufficient votes. Thus the following four different circuits written in Circom (Muñoz-Tapia et al. 2022) are required by the consensus component (see Table 1).

Table 1. Consensus Circuit Constraint Size

Total Nodes	Circuit Name	Language	CS	Proofs
128	register	Circom	$2^{18}$	1
256	register	Circom	$2^{18}$	1
$2^{18}$	register	Circom	$2^{21}$	1
128	node validation	Circom	$2^{17}$	1
256	node validation	Circom	$2^{17}$	1
$2^{12}$	node validation	Circom	$2^{21}$	1
128	source voting	Circom	$2^{17}$	1
256	source voting	Circom	$2^{17}$	1
$2^{12}$	source voting	Circom	$2^{17}$	1
128	winner proving	Circom	$2^{24}$	1
256	winner proving	Circom	$2^{24}$	2
$2^{12}$	winner proving	Circom	$2^{24}$	16

Remark

When the winner proves that he has collected enough votes, he might need to provide more than one proof, and each proves that a certain amount of voters has voted for him by sending him the voting proof.

Simulation circuit

Since the size of the simulation circuit usually depends on the transaction logic a user would like to execute, we provide an example to show the circuits size of building a multi-chain DEFI (decentralized finance Zetzsche et al. 2020; Chen and Bellavitis 2020) system over ZK Multi-Blockchain Aggregator (see Table 2) using Circom. In Table 2, the AMM circuits denote the multi-blockchain transactions of automated market maker (Mohan 2022), and the state circuit means the circuit of Merkle tree manipulating interfaces.

Table 2. DEFI Transaction Circuits

Number of $t_{x}$	Circuit Name	Language	CS
8	AMM circuit	Circom	$2^{14}$
256	AMM circuit	Circom	$2^{19}$
8	State circuit	Circom	$2^{16}$
256	State circuit	Circom	$2^{21}$

Proof batching circuit

The standard way to batch multiple proofs into one proof is to encode the PLONK verify algorithm into ZKP circuits. Since the verify algorithm contains a lot of calculation of EC (elliptic curve) scalar multiplication, it is infeasible to implement such a complex algorithm in Circom. Thus we encode the algorithm using Halo2 (Halo2 2020) proving system (see Table 3 for constraint size in Halo2).

Table 3. Circuits for Batching Proofs

Circuit Name	Proof System	CS
EC scalar multiplication circuit	Halo2	$7 \times 10^{4}$
Transcript circuit	Halo2	$2^{18}$
Batch circuit	Halo2	$2^{24}$

Evaluation results on real-world testnet

The overall block-generating time is the sum (some of the calculations can be executed concurrently) of the consensus, simulating, and proving stages. The time consumption of simulating stage is negligible. Thus it is sufficient to calculate the consensus and proving stage time. The average time consuming of $2^{20}$ constraints is about 6 sec on a 2 (Intel(R) Core(TM) i7) CPU computer with 128 G memory. When batch proofs using the Halo2 system, it takes 34 s more to batch the consensus proof with around 32 simulation proofs in a block on a 2 (Intel(R) Core(TM) i7) CPU computer with one NVIDIA GeForce RTX 3070 card.

When running the whole DEFI application on ZK Multi-Blockchain Aggregatortestnet over four native blockchains (goerli, bsctestnet, cronostestnet, rolluxtestnet), the overall performance of transaction handling is about 1 TPS (transaction per second) per machine (2 Intel i7 CPU + GeForce RTX 3070 graphic card). It can be scaled linearly if more hardware is provided. The evaluation shows that our protocol is practical in realistic applications.

Since we are focus on the protocol implementation instead of the performance tuning on ZKP prover, the ZKP tool we used is a bit behind the recent most advanced tools (Ernstberger et al. 2024) which should provide significant speed improvement compare to circom (e.g. deVirgo Xie et al. 2022, stark Ben-Sasson et al. 2018). Thus the TPS could potentially improved if modern ZKP protocols are applied.

Related works

Notary Schemes. The main idea of notary schemes is to elect one or more trusted nodes as a notary public and report transactions in different blockchain networks through notaries (Qin and Gervais 2018). Therefore, all information transferred between other blockchains is entirely managed by notaries. The centralized notary scheme has efficiency in procession events and simplicity in implementation. However, it suffers from the SPOF problem. Therefore, a multi-signature notary scheme may be proposed to reduce the trust in a specific centralized node. However, this multi-signature notary is non-permissionless and needs extra protocols to ensure liveness.

SPV: Simplified Payment Verification. SPV (Lin and Liao 2017; Ray et al. 2020) is a particular case of one-directional state pining (Robinson 2020). In such protocols, the block header of $C_{A}$ and a Merkle proof of a specific transaction is monitored and sent to the target blockchain $C_{B}$ . $C_{B}$ accepts the transaction by calculating the partial Merkle tree hash and compares it with the block header of $C_{A}$ . The liveness property of this approach depends on the liveness of relayers of $C_{A}$ , and the safety property relies on the block headers being reported to $C_{B}$ honestly.

Sidechains. The goal of sidechains (Singh et al. 2020) is to extend the scalability and functionality of the blockchain system. Sidechains enforce the security of transactions by implementing a protocol validated by consensus. Since sidechains need to update state changes back to the underlying blockchains, they trust or verify the transactions sent out by sidechains. The safety property relies on whether observation of the source chain can be honestly reported to the side chain and whether the verifier on the target chain can reject all fraud transactions. The liveness relies on how robust the sidechain itself is and whether all the transactions that happen on the sidechain will get reported to the target chain eventually. Some improving ideas are given in Plasma (Poon and Buterin 2017).

Cross Chain Gateway and Relayers. Cross Chain Gateway with relays is another extension of the idea of state pinning. While it enables blockchain interoperability applications, including cross-chain token transfer, the safety property is attained at the cost of storing every single block header of the source blockchain (Belchior et al. 2021). In general, the cost of storing such a state is prohibitive. Moreover, such storage does not imply certain transaction has been executed as it is hard to check another chain’s state via blockhead only. Thus attestation proof is still needed and is usually designed case by case.

ZKBridge. The ZKBridge (Xie et al. 2022), proposes an efficient cross-chain bridge that guarantees strong security using ZKP to provide trustless relayers. The trust base of the ZKBridge requires that the light-client protocols of checking the blockhead of the source blockchain are secure. Compared to ZKBridge, mainly focusing on the security of relayers, our protocol tackles the interference problem much better. ZKBridge still follows the traditional way of executing transactions on different blockchains and using relayers to synchronize them. Hence it does not scale well in constructing multi-blockchain transactions that involve many blockchains since it needs to handle the interference between the blockchains in a case-by-case manner. Instead, we simulate the transaction on our aggregator chain and convince native blockchains to update their local state by providing the ZKP of the simulation result, and hence offer a general solution to handle the interference. Moreover, our protocol naturally has the linearizability property with no scalability problem when applied to scenarios with many native blockchains. Regarding the cost of ZKP proof generation, our solution only requires attestation proofs of the merkle root on native chains thus reduce the cost of the attestation proof. However this simplification introduce more proof generation cost of the execution simulation on the aggregation layer.

Conclusion and future work

In this work, we presented a protocol that utilizes an aggregation layer and ZKP to perform multi-blockchain transactions in a simulating-synchronizing manner. The main novelty of our protocol is that it solves the communication and interference problem in a general sense while still ensuring important properties such as safety, permissionless, linearizability, and liveness. Our future work will target two directions. One is reducing the overall cost of gas fees by batching attestation proofs with executing proofs, and reducing the time of proof generation by applying more up-to-date ZKP technology to improve the overall TPS. The other is formalizing the protocol in an interactive prover (e.g. Coq, Lean, TLA+) so that we can have move rigorous and formal specification of the protocol.

Author contributions

The first author’s main contributions include coding, conducting experiments, and preparing data. The second author’s contributions are mainly supervision, design ideas and methodology.

Funding

No funding provided.

Data availibility

Data will be made available on reasonable request.

Declaration

Competing interests

The authors declare that they have no Conflict of interest.

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

References

Anati I, Gueron S, Johnson S, Scarlata V (2013) Innovative technology for cpu based attestation and sealing. In: Proceedings of the 2nd International Workshop on Hardware and Architectural Support for Security and Privacy, 13. ACM New York, NY, USA

Becker G (2008) Merkle signature schemes, merkle trees and their cryptanalysis. Ruhr-University Bochum, Tech. Rep 12, 19

Belchior, R; Vasconcelos, A; Guerreiro, S; Correia, M. A survey on blockchain interoperability: past, present, and future trends. ACM Comput Surv (CSUR); 2021; 54, 8 pp. 1-41. [DOI: https://dx.doi.org/10.1145/3471140]

Ben-Sasson E, Bentov I, Horesh Y, Riabzev M (2018) Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive

Boneh D, Drake J, Fisch B, Gabizon A (2020) Halo infinite: Recursive zk-snarks from any additive polynomial commitment scheme. Cryptology ePrint Archive

Boneh D, Drake J, Fisch B, Gabizon A (2020) Efficient polynomial commitment schemes for multiple points and polynomials. Cryptology ePrint Archive

Cao L, Wan Z (2020) Anonymous scheme for blockchain atomic swap based on zero-knowledge proof. In: 2020 IEEE International Conference on Artificial Intelligence and Computer Applications (ICAICA), pp. 371–374. IEEE

Castro, M; Liskov, B et al. Practical byzantine fault tolerance. In: OSDI; 1999; 99, pp. 173-186.

Chen, Y; Bellavitis, C. Blockchain disruption and decentralized finance: the rise of decentralized business models. J Bus Ventur Insights; 2020; 13, 00151. [DOI: https://dx.doi.org/10.1016/j.jbvi.2019.e00151]

Chen W, Xu Z, Shi S, Zhao Y, Zhao J (2018) A survey of blockchain applications in different domains. In: Proceedings of the 2018 International Conference on Blockchain Technology and Application, pp. 17–21

Chiesa A, Hu Y, Maller M, Mishra P, Vesely N, Ward N (2020) Marlin: preprocessing zksnarks with universal and updatable srs. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 738–768. Springer

Cramer R, Damgård I (1998) Zero-knowledge proofs for finite field arithmetic, or: Can zero-knowledge be for free? In: Annual International Cryptology Conference, pp. 424–441. Springer

Damgård I (1998) Commitment schemes and zero-knowledge protocols. In: School Organized by the European Educational Forum, pp. 63–86. Springer

Deng L, Chen H, Zeng J, Zhang L-J (2018) Research on cross-chain technology based on sidechain and hash-locking. In: International Conference on Edge Computing, pp. 144–151. Springer

Ernstberger J, Chaliasos S, Kadianakis G, Steinhorst S, Jovanovic P, Gervais A, Livshits B, Orrù M (2024) zk-bench: A toolset for comparative evaluation and performance benchmarking of snarks. In: International Conference on Security and Cryptography for Networks, pp. 46–72. Springer

Feng, C; Yu, K; Bashir, AK; Al-Otaibi, YD; Lu, Y; Chen, S; Zhang, D. Efficient and secure data sharing for 5g flying drones: a blockchain-enabled approach. IEEE Netw; 2021; 35, 1 pp. 130-137. [DOI: https://dx.doi.org/10.1109/MNET.011.2000223]

Fiore D, Nitulescu A (2016) On the (in) security of snarks in the presence of oracles. In: Theory of Cryptography Conference, pp. 108–138. Springer

Garoffolo A, Kaidalov D, Oliynykov R (2020) Zendoo: A zk-snark verifiable cross-chain transfer protocol enabling decoupled and decentralized sidechains. In: 2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS), pp. 1257–1262. IEEE

Gong Y, Jin Y, Li Y, Liu Z, Zhu Z (2022) Analysis and comparison of the main zero-knowledge proof scheme. In: 2022 International Conference on Big Data, Information and Computer Network (BDICN), pp. 366–372. IEEE

Groth J (2016) On the size of pairing-based non-interactive arguments. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 305–326. Springer

Halo2: The Halo2 Book. Accessed on 2022-9-3 (2020). https://zcash.github.io/halo2/

Hastig, GM; Sodhi, MS. Blockchain for supply chain traceability: Business requirements and critical success factors. Prod Oper Manag; 2020; 29, 4 pp. 935-954. [DOI: https://dx.doi.org/10.1111/poms.13147]

Herlihy, M; Wing, JM. Linearizability: a correctness condition for concurrent objects. ACM Trans Program Lang Syst; 1990; 12, 3 pp. 463-492. [DOI: https://dx.doi.org/10.1145/78969.78972]

Jensen, JR; Wachter, V; Ross, O. An introduction to decentralized finance (defi). Complex Syst Inform Model Quart; 2021; 26, pp. 46-54. [DOI: https://dx.doi.org/10.7250/csimq.2021-26.03]

Kate, A; Zaverucha, GM; Goldberg, I. Polynomial commitments; 2010; Rep, Tech:

Kate A, Zaverucha GM, Goldberg I (2010) Constant-size commitments to polynomials and their applications. In: International Conference on the Theory and Application of Cryptology and Information Security, pp. 177–194. Springer

Lin, I-C; Liao, T-C. A survey of blockchain security issues and challenges. Int. J. Netw. Secur.; 2017; 19, 5 pp. 653-659.

Lys L, Micoulet A, Potop-Butucaru M (2021) R-swap: Relay based atomic cross-chain swap protocol. In: International Symposium on Algorithmic Aspects of Cloud Computing, pp. 18–37. Springer

Mayer H (2016) zk-snark explained: Basic principles. URL https://blog.coinfabrik.com/wp-content/uploads/2017/03/zkSNARK-explained_basic_principles. pdf

Minoli, D; Occhiogrosso, B. Blockchain mechanisms for iot security. Int Things; 2018; 1, pp. 1-13.

Mohan, V. Automated market makers and decentralized exchanges: a defi primer. Finan. Innovat.; 2022; 8, 1 pp. 1-48.

Muñoz-Tapia JL, Belles M, Isabel M, Rubio A, Baylina J (2022) CIRCOM: A Robust and Scalable Language for Building Complex Zero-Knowledge Circuits. TechRxiv

Nakamoto S (2008) Bitcoin whitepaper. URL: https://bitcoin. org/bitcoin. pdf-(: 17.07. 2019)

Petkus M (2019) Why and how zk-snark works. arXiv preprint arXiv:1906.07221

Poon J, Buterin V (2017) Plasma: Scalable autonomous smart contracts. White paper, 1–47

Poon J, Dryja T (2016) The bitcoin lightning network: Scalable off-chain instant payments

Qin K, Gervais A (2018) An overview of blockchain scalability, interoperability and sustainability. Hochschule Luzern Imperial College London Liquidity Network

Ray, PP; Kumar, N; Dash, D. Blwn: blockchain-based lightweight simplified payment verification in iot-assisted e-healthcare. IEEE Syst J; 2020; 15, 1 pp. 134-145. [DOI: https://dx.doi.org/10.1109/JSYST.2020.2968614]

Robinson, P. The merits of using ethereum mainnet as a coordination blockchain for ethereum private sidechains. Knowledge Eng. Rev.; 2020; 35, e30. [DOI: https://dx.doi.org/10.1017/S0269888920000296]

Robinson, P. Survey of crosschain communications protocols. Comput Netw; 2021; 200, 108488. [DOI: https://dx.doi.org/10.1016/j.comnet.2021.108488]

Robinson P, Brainard J (2019) Anonymous state pinning for private blockchains. In: 2019 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), pp. 827–834. IEEE

Setty S (2020) Spartan: Efficient and general-purpose zksnarks without trusted setup. In: Annual International Cryptology Conference, pp. 704–737. Springer

Singh, A; Click, K; Parizi, RM; Zhang, Q; Dehghantanha, A; Choo, K-KR. Sidechain technologies in blockchain networks: an examination and state-of-the-art review. J Netw Comput Appl; 2020; 149, 102471. [DOI: https://dx.doi.org/10.1016/j.jnca.2019.102471]

Substrate: Substrate Documentation. Accessed on 2022-9-3 (2014). https://docs.substrate.io/

Sun, W; Wang, L; Wang, P; Zhang, Y. Collaborative blockchain for space-air-ground integrated networks. IEEE Wirel Commun; 2020; 27, 6 pp. 82-89. [DOI: https://dx.doi.org/10.1109/MWC.001.2000134]

Warren W, Bandeali A (2017) 0x: An open protocol for decentralized exchange on the ethereum blockchain. URl: https://github.com/0xProject/whitepaper, 04–18

Westerkamp M, Eberhardt J (2020) zkrelay: Facilitating sidechains using zksnark-based chain-relays. In: 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS and PW), pp. 378–386. https://doi.org/10.1109/EuroSPW51379.2020.00058

WhiteHat B, Baylina J, Bellés M (2020) Baby jubjub elliptic curve. Ethereum Improvement Proposal, EIP-2494 29

Xie T, Zhang J, Cheng Z, Zhang F, Zhang Y, Jia Y, Boneh D, Song D (2022) zkbridge: Trustless cross-chain bridges made practical. In: Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pp. 3003–3017

Zetzsche, DA; Arner, DW; Buckley, RP. Decentralized finance. J Finan Regulat; 2020; 6, 2 pp. 172-203. [DOI: https://dx.doi.org/10.1093/jfr/fjaa010]

Zhang Q, Cao S, Zhang X (2021) Enabling auction-based cross-blockchain protocol for online anonymous payment. In: 2021 IEEE 27th International Conference on Parallel and Distributed Systems (ICPADS), pp. 715–722. IEEE

Word count: 9058

Show less

© The Author(s) 2025. This work is published under http://creativecommons.org/licenses/by/4.0/ (the “License”). Notwithstanding the ProQuest Terms and Conditions, you may use this content in accordance with the terms of the License.

A ZK-based multi-blockchain transaction layer for minimal trust base

Content area

Abstract

Full text