gpestana
commented
4 years ago 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.
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)
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 of10*(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