Anonymous Zether performance and throughput on PoA chains

[gpestana]

I ran some experiments to understand the performance of anonymous zether running on a (local) quorum ledger. After doing so, I found it very hard to replicate the performance results shown in the section 3 of Anonymous Zether [1] paper. This issue describes and compares the measurements performed locally (A) and the measurements in the paper (B).

Note: "performance" in this context means time to transaction, ie, the time for the smart contract to verify the proof and settle the transaction so that a new transaction can be processed. Ultimately, I am trying to understand how many anonymous Zether transactions can a PoA blockchain process per day.

A. Performance study

Setup

Blockchain: Smart contracts running on Quorum PoA blockchain, with a validation pool of 7 Quorum nodes running on Docker, as in jpmorgan's examples repository
Epoch size: variable

1: Proof generation (using local JS library)

Anonymity set size	Avg. time (ms)	Epoch time	Outliers
2	2023	1	3523, 3570, 2665

In this experiment, assuming that the epoch size is 1 in both experiments (no enough information about the experiments ran in the paper), the performance is similar to the measurements in the paper (see Fig.3 below)

2. E2E prover and verification times

This measurement refers to the E2E time from the proof generation in the client until the transaction is settled. As expected, the bottleneck is the epoch time, rather than the computational resources of the validator nodes or the proof/verification times.

B. Anonymous Zether paper performance study

Blockchain: not specified
Epoch time: not specified

Fig.3 : Performance measurements in [1]

Questions

• It seems to me that epoch times are the hard bottleneck in the protocol, since no matter how fast on-chain verifications are, the verification smart contract has to wait for the end of the epoch to verify 1 transaction. This means that 10 verifications cost at minimum 10*epoch_time, instead of 10*(proof_time + verification_time + communication_time ). Is this assumption correct?

• At this point, we can achieve 10 Anonymous Zether Tx per minute (600/h, 14,000/day). These values are based on a PoA blockchain with 7 Quorum validator nodes running locally on docker with a single thread and IBFT1.0 consensus protocol, with Anonymous Zether using PoC implementation and anonymity set size of 2. Is there any way to improve the throughput?

---

[1] Anonymous Zether paper

[gpestana]

Front running problem and epoch times in Zether

From [2]:

Front-running.

The very rst problem with the simplistic version of Zether is that the
ZK-proofs are generated w.r.t. a certain state of the contract. For example, the ZK-proof
in a transfer transaction needs to show that the remaining balance is positive. A user Alice
generates this proof w.r.t. to her current account balance, stored in an encrypted form on the
contract. However, if another user Bob transfers some ZTH to Alice, and Bob's transaction
gets processed rst, then Alice's transaction will be rejected because the proof will not be
valid anymore. Note that Bob may be a totally benign user yet Alice loses the fees she paid
to process her transaction. We refer to this situation as the front-running problem. Burn
transactions have a similar problem too: a proof that a ciphertext encrypts a certain value
becomes invalid if the ciphertext changes.
To solve this problem, one could introduce a new type of transaction that just locks an
account to keep away incoming transfers. Alice could wait until this transaction gets into the
blockchain before initiating an outgoing transfer (or doing a burn). While this seems to x
the problem (at the cost of making transfer, the primary transaction, a two-step process), it
creates new problems for users like Bob who want to send ZTH to Alice. Alice's account may
not be locked when Bob publishes a transfer transaction tx, but it could get locked before tx
gets in, resulting in tx being rejected.
Any kind of locking approach becomes more untenable when we bring in anonymity. (We
will discuss anonymity in more detail at the end of this section.) If Alice wants to hide herself
among other users and make sure that her transaction gets through, she will have to lock all
the accounts in the anonymity set. Clearly, this cannot be allowed: Alice must not be able
to lock accounts of other users. Alternatively, Alice could only put locked accounts in her
anonymity set. However, if someone unlocks their account before Alice's transaction gets in,
Alice's degree of anonymity is reduced.

Pending transfers.

To address the front-running problem, we keep all the incoming transfers
in a pending state. These transfers are rolled over into the accounts from time to time so that
the incoming funds could be spent. This rollover cannot happen at arbitrary times, otherwise
the proofs would get invalidated again.
To handle this, we divide time into epochs where an epoch consists of k consecutive blocks.
The choice of k depends on two factors: a) the gap between the latest state of blockchain
and any user's view, and b) the time it takes to get a transaction into the blockchain. At
the end of every epoch, pending transfers are rolled over into the corresponding accounts.
Users are expected to publish their transfer or burn transaction at the beginning of an epoch
so that even if they do not see the latest state of the blockchain and it takes some time for
their transaction to be included, they do not step into the next epoch. As long as k is chosen
wisely, transactions will be processed before the account changes state.