Note also that an aggregator does not need to know the previously processed transactions in order to add a new transaction to the rollup. This means aggregating is fully permissionless, so that new transactions can be added concurrently by anyone.

If a user wants to withdraw funds to a blockchain address, he can initiate the corresponding transactions as described above. Subsequently, any aggregator can pick a history root hash M which has been stored after or in the process of the addition of the block containing the last transaction to be taken into account. The aggregator who picked the history root hash M can then for a set of blockchain addresses generate a recursive ZK-proof that a given total amount received by one of the blockchain address at history root hash M is correct himself, and/or gathers such proofs from other users. The recursive ZK-proof can be a cryptographic proof that the blockchain address has received at least the purported total amount at the point when history root hash M was computed, which contains information on every relevant transaction. The aggregator can then send the recursive ZK-proofs together with the purported total amounts received, the history root hash M and the corresponding blockchain addresses in an aggregator withdrawal transaction to the ZK-rollup smart contract. The ZK-rollup smart contract upon reception of the aggregator withdrawal transaction verifies that the latter is formally valid, i.e., has the intended format, that the history root hash M is stored in the ZK-rollup contract state, and each recursive ZK-proof. If all verifications by the ZK-rollup smart contract are successful, the ZK-rollup smart contract transfers funds according to the purported total amounts received by the blockchain addresses and according to total amounts already withdrawn to each of the concerned blockchain addresses, where the latter are stored in the ZK-rollup contract state, updated with every withdrawal, and set to some predefined initial value, e.g. 0, if no withdrawal to the corresponding blockchain address has been processed yet. The transferring can be done by transferring the assets to the blockchain address which belong to it according to the aggregator withdrawal transaction and have not been withdrawn and therefore transferred before according to the total amount withdrawn to the blockchain address stored in the ZK-rollup contract state. Eventually the ZK-rollup smart contract replaces the total amount withdrawn to the blockchain address stored in the ZK-rollup contract state before the present withdrawal with the updated total amount withdrawn to the blockchain address after the present withdrawal. More concretely, the ZK-rollup smart contract can comprise a withdraw function, which can be called by any aggregator, takes the content of the aggregator withdrawal transaction as an input, performs the verifications, and if the verifications are successful, performs the transferring of funds and updates the total amount withdrawn.

Here the M in history root hash M can be just some label or a count of every history root hash computed.

Note that naturally an aggregator withdrawal transaction comprising a history root hash M has to be generated by the aggregator ZK-rollup node B after the history root hash M has been computed and stored in the ZK-rollup contract state.

The purported total amount received by a blockchain address can for example be a list of the amounts of assets of each kind received by this address.

The total amount withdrawn to a blockchain address can be a list of total amounts of each kind of asset withdrawn to the blockchain address. The total amount withdrawn to a blockchain address before any withdrawal to that blockchain address can be set to a default value or index, e.g. the value 0.

The total amount withdrawn to each blockchain address is stored and updated in the ZK-rollup contract state. Transferring funds according to an aggregator withdrawal transaction and according to the total amounts already withdrawn to one of the involved blockchain addresses means that the data of the transaction as well as of the total amounts withdrawn is considered and the actual transfer amount is possibly calculated from amounts indicated by this data.

The recursive ZK-proofs can be kept as a set of recursive ZK-proofs for each purported total amount received, or they can be summarized to a combined recursive ZK-proof for all purported total amounts received. In the former case, each recursive ZK-proof can be generated at one of the several user ZK-rollup nodes and then be transferred to the aggregator ZK-rollup node B, or it can be generated at a separate software and then be provided to one of the several user ZK-rollup nodes from which it is then transferred to the aggregator ZK-rollup node B. In the latter case, the combined recursive ZK-proof for all purported total amounts received can be generated at the aggregator ZK-rollup node B, for example by generating an aggregated ZK-proof from recursive ZK-proofs for each purported total amount received, where the latter proofs can be provided in the same way as in the former case.

The present ZK-rollup design differs from other designs in the way that states are handled. Instead of having a global state of user balances, each user maintains and updates a recursive ZK-proof of the balance of the ZK-rollup addresses and blockchain addresses that are owned by this user. For each new ZK-rollup block, respectively each transaction processed by the smart contract, each user can update its balance and compute a new recursive ZK-proof of the balance of its addresses.

The requirements for the recursive ZK-proof to be formally valid depend on the corresponding ZK proof system.

The balance recursive ZK-proofs can be based on Plonky2 and/or Nova and/or SuperNova.

Note that the point in time when the ZK-rollup blocks corresponding to the transactions referred to by the balance recursive ZK-proof were added is only relevant in the sense that this has to be before or during history root hash M was stored. Since every history root hash is computed from the previous one, transactions can be verified even if the corresponding blocks were added long before.

The security assumptions on the protocol presented here are the same as the assumptions for the underlying blockchain, together with the assumption that the employed ZK proof system is secure.

In some embodiments the transaction method may comprise the following additional step: by means of the ZK-rollup smart contract:

- processing a registration of a user ZK-rollup account by
- a) receiving a user registration transaction from one of the several user ZK-rollup nodes, with the user registration transaction comprising a user identifier of the user ZK-rollup account and a user signature of the user identifier,
- b) verifying the user signature of the user identifier, and
- c) if the verification in the previous step was successful, (i) computing a history root hash (31) from content of the user registration transaction and the immediately preceding history root hash (31′), and storing the computed history root hash (31) in the ZK-rollup contract state (32) until the predefined condition is met, and (ii) assigning a ZK-rollup address to the user ZK-rollup account.

Note that there can be user ZK-rollup nodes by means of which several user ZK-rollup accounts are registered, or a single one, or none. A user can register a user ZK-rollup account with one user ZK-rollup node and afterwards participate in the ZK-rollup also or exclusively with other user ZK-rollup nodes.

Blockchain addresses to which funds can be withdrawn can correspond to smart contract accounts or externally owned accounts (EOAs).

In some embodiments user signatures and/or aggregated signatures may be BLS signatures.

A Boneh-Lynn-Shacham (BLS) signature is a cryptographic signature scheme which allows a user to verify that a signer is authentic. The scheme involves a private key and a corresponding public key. Under the scheme, a user can generate a user signature of a bitstring by computing a given function from the bitstring and the private key. A verifier subsequently can verify the signature given the signature and the public key. Multiple BLS signatures, corresponding to multiple private keys and/or multiple bitstrings, can be aggregated into a single BLS signature.

When using BLS signatures, the user identifier and the user signature of the user identifier contained in the user registration transaction can be a public BLS key and a signature computed from the public BLS key together with the corresponding private BLS key.

In some embodiments the transaction method may comprise the following additional step: by means of the ZK-rollup smart contract:

processing a user token deposit by

- a) receiving a set of tokens together with a user token deposit transaction from one of the several user ZK-rollup nodes, with the user token deposit transaction being generated at this user ZK-rollup node and comprising
  - i. at least one token ID,
  - ii. an amount of tokens for each of the at least one token IDs, and
  - iii. a ZK-rollup address to receive the amounts of tokens;
- b) verifying that
  - i. the user token deposit transaction is formally valid, and
  - ii. for each of the at least one token IDs, the set of tokens received comprises as many tokens corresponding to this token ID as indicated by the amount of tokens for this token ID;
- c) if the verifications in the previous step were successful, computing a history root hash from content of the user token deposit transaction and the immediately preceding history root hash, and storing the computed history root hash in the ZK-rollup contract state until the predefined condition is met.

A user token deposit transaction is formally valid if it is in the intended format.

Computing a history root hash from X means here that one computes the output of some hash function with the input X. Note that here either all or only part of the content of the user deposit transaction can be contained in the input of the hash function.

Note that the user registration transactions, the user token deposit transactions, and the aggregator transfer transactions can each come in the form of a ZK-rollup block which is added by the corresponding node to the ZK-rollup chain by making a blockchain transaction with the content of the respective transaction as calldata, or blob-data, to the ZK-rollup smart contract.

A token ID is understood here as an identifier of a specific class of tokens, i.e., of the kind of token, like for example a kind of cryptocurrency, like ETH, DAI, or USDC, or a specific NFT. The token IDs can for example be natural numbers.

In addition to the ZK-rollup chain on the blockchain, there can be a corresponding validated ZK-rollup chain computed off-chain. Here we call a ZK-rollup block corresponding to an aggregator transfer transaction valid if the latter is formally valid and its aggregated signature is correct with respect to its list of user ZK-rollup accounts. Otherwise, the ZK-rollup block corresponding to an aggregator transfer transaction is called invalid. Furthermore, we call a ZK-rollup block corresponding to a user registration transaction valid if the latter is formally valid and the user signature of the user identifier is correct with respect to the user identifier. User token deposit transactions are always considered valid, as their content is verified by the ZK-rollup smart contract when they are added. The validated ZK-rollup chain is then computed by only including validated ZK-rollup blocks and skipping invalid ones. More precisely, whereas the original history root hashes of the original ZK-rollup chain are computed from the previous original history root hash and the content of the current ZK-rollup block, no matter whether the current ZK-rollup block is valid, the same is done for the validated ZK-rollup chain but only if the current ZK-rollup block is valid. Hence, in order to update the validated ZK-rollup chain, the validity of the newly added ZK-rollup blocks to the original ZK-rollup chain have to be verified beforehand. This verification, which involves the verification of signatures corresponding to user ZK-rollup accounts respectively user identifiers, can be done by keeping track of user ZK-rollup accounts and their corresponding ZK-rollup addresses in an off-chain user ZK-rollup state. When a ZK-rollup block is verified, a proof of the validity of this ZK-rollup block can be generated and posted on-chain. Note that the computations and proofs for the validated ZK-rollup chain can be performed by any user participating in the ZK-rollup, i.e., having registered at least one user ZK-rollup account. Moreover, users participating in the ZK-rollup can store their own version of the validated chain without making computations by trusting in the validity proofs of the ZK-rollup blocks being posted on-chain. In order to incentivize e.g., aggregators to take care of the task of verifying ZK-rollup blocks and generating proofs and posting the proofs on-chain, there can be suitable rules incorporated in the ZK-rollup smart contract. Similarly, suitable rules can help to motivate trusting in posted validity proofs of ZK-rollup blocks without them having to be verified on-chain in most cases.

If a validated ZK-rollup chain is available (in the sense of validity proofs of ZK-rollup blocks being posted on-chain), a balance recursive ZK-proof of a user withdrawal instruction can take as public input the original history root hash M, the one or more blockchain addresses, and their claimed balance at original history root hash M, and prove 1) that there exists a validated history root hash M′ and a recursive ZK-proof that this is the correct validated history root hash corresponding to the original history root hash M, and 2) that for each of the one or more blockchain addresses, there exists a recursive ZK-proof that this blockchain address has the specified balance at validated history root hash M′.

More generally, the proof system can be any proof system capable of making recursive ZK-proofs.

In some embodiments the predefined condition may be either that a fixed number x of succeeding history root hashes is stored, or the predefined condition is that another history root hash corresponding to the same blockchain block and/or a fixed number x of succeeding history root hashes is stored.

Here the fixed number x is a natural number bigger than or equal to 1.

For both options, at most x+1 history root hashes are kept in the storage. As there can be several ZK-rollup blocks contained in one blockchain block, i.e., in one blockchain transaction, the two options may however differ. The second option can be realised by storing the blockchain block number in which the last ZK-rollup block was added in the ZK-rollup contract state.

Note that here it is possible that the history root hash to be erased from the storage is done so by overwriting it with the xth succeeding history root hash or with the other history root hash corresponding to the same blockchain block respectively. In that case, deleting the old history root hash and storing the xth succeeding history root hash or the other history root hash corresponding to the same blockchain block respectively are happening simultaneously. This also means that in this case, there are at most x history root hashes in the storage at the same time.

In some embodiments the fixed number x may be a natural number between 1 and 2{circumflex over ( )}16, and preferably 2{circumflex over ( )}7<=x<=2{circumflex over ( )}9, and most preferably x=2{circumflex over ( )}8.

Note that in principle, x could be any natural number>0. There is however a trade-off: on the one hand, if the number is too small, there might not be enough time to generate the balance recursive ZK-proofs needed for withdrawing before the history root hash is deleted from the ZK-rollup contract state. On the other hand, if the number is too big, there is more data that needs to be stored by the ZK-rollup smart contract.

If the predefined condition is that another history root hash corresponding to the same blockchain block and/or a fixed number x of succeeding history root hashes is stored, then at most one history root hash is stored for every blockchain block. Thus if for example a blockchain block is added every 12 seconds, then setting x=2{circumflex over ( )}8=256 guarantees that each history root hash is stored for at least 256*12 seconds=51 minutes. Furthermore, note that 256 is the highest number that fits in one byte, which can be an advantage in implementations. This number can however be adjusted, e.g., according to the time needed for the proving.

In some embodiments each user transfer instruction may contain instructions for at least one transfer of funds between two different ZK-rollup addresses or from a ZK-rollup address to a blockchain address.

Note that a single transfer of funds is always between two distinct addresses, and that in the case of the receiving address being a blockchain address, the latter is represented in an appropriate way within the rollup structure. A user transfer instruction can however contain several transfers from a ZK-rollup address to other ZK-rollup addresses and/or to blockchain addresses. It typically contains transfers from only one ZK-rollup address. A user can however have more than one user ZK-rollup accounts registered.

In some embodiments the blockchain may be an Ethereum blockchain.

In some embodiments the funds may be assets of the type of cryptocurrency and/or of digital tokens.

The invention also refers to a computer program product which executes the transaction method described above when it runs on a computer device network.

BRIEF EXPLANATION OF THE FIGURES

The invention is further described below with reference to figures. The figures show:

FIG. 1—a schematic representation of a ZK-rollup chain;

FIG. 2—a schematic representation of adding a batch to a ZK-rollup;

FIG. 3—example of a registration batch;

FIG. 4—example of a deposit batch;

FIGS. 5A-5D—a schematic representation of a transfer transaction method for a ZK-rollup network;

FIG. 6—a schematic representation of a validated chain;

FIG. 7—a schematic representation of adding a valid registration batch;

FIG. 8—a schematic representation of adding a valid deposit or transfer batch;

FIG. 9—a schematic representation of adding an invalid batch;

FIG. 10—a schematic representation of updating a user state/balance;

FIG. 11—a schematic representation of a withdrawal.

IMPLEMENTATIONS OF THE INVENTION

In the present section, as well as in the figures, for the sake of ease of reading a ZK-rollup block is called a batch and a blockchain block is called a block.

A ZK-rollup chain consists here of a chain of batches together with their batch hashes 31 (history root hashes), as seen in FIG. 1. There are three kinds of batches, registration batches 6 (user registration transactions), deposit batches 7 (user token deposit transactions) and transfer batches 51 (aggregator transfer transactions). These will be explained later. Each batch hash 31 is a hash of the batch content together with the previous batch hash 31′ (immediately preceding history root hash).

The ZK-rollup smart contract is here a blockchain (also referred to as layer one or L1, whereas a ZK-rollup is also referred to as layer two or L2) smart contract which stores a list of the last 256 batch hashes 31, which is needed for withdrawals as explained later. The process of adding a batch to the ZK-rollup is shown in FIG. 2.

Anyone participating in the ZK-rollup can add a new batch 6, 7, 51 to the ZK-rollup by making a blockchain transaction to the ZK-rollup smart contract 3 with the content of the new block 6, 7, 51 included as calldata, or blob-data. The ZK-rollup smart contract 3 will then compute the batch hash 31 of the new batch by hashing its content together with the previous batch hash 31′, which is already stored in the contract storage 32 (ZK-rollup contract state). The ZK-rollup smart contract 3 then adds the new batch hash 31 (N) to the list of recent batch hashes 31′ (N−1, . . . , N−255) and removes the oldest batch hash from the list.

An aggregator 5 does not need to know the previous batch in order to add a new batch to the ZK-rollup. This means that aggregating can be fully permissionless, so that new batches can be added concurrently by anyone.

Before a user can make a transaction on the ZK-rollup network, he may register a user ZK-rollup account by registering a public Boneh-Lynn-Shacham (BLS) key. This can be done by adding a registration batch 6 to the ZK-rollup. A registration batch 6 comprises at least the public BLS key and a signature of the BLS key by the corresponding private key (FIG. 3). The signature proves that each user knows the private key corresponding to their public BLS key, preventing a rogue key attack. When a user registers a new account, the account is given an account ID (e.g., L2 address), which may be an integer that increments for each new account.

In order to deposit tokens to the ZK-rollup, a user must create a deposit batch