State machine smart contract for public accountability of zero knowledge payments in Ethereum

By definition, confidential and anonymous transactions are not publicly accountable. In most zero knowledge constructions (e.g. Zether, AZTEC), a payer can prove that a transaction has been made to an account within a set of accounts and there was no double spending. However, how can the payer prove that payments were sent to the correct account in the set and with the expected amount of funds, without disclosing critical information about the payments itself? We define a smart contract implementing a state machine that allows receivers of anonymous and confidential payments in Ethereum to prove the non-correctness of subjective, predefined payment statements. This mechanism allows a receiver to agree with the side effects of a confidential and anonymous payment without revealing any information about the payment itself. In addition, the receiver can challenge and keep the payer accountable, by proving that a payment was not done according to the predefined statement.

Goals

We want to design a smart contract that allows payers and receivers of anonymous and confidential payments to state publicly that they agree on the correctness of a payment, without revealing any other information about the payment itself. This is achieved by payers and receiver to commit to an encrypted statement that contains information about the payment. We want to define mechanism for receivers to challenge the commitment by showing proof that the payment was not correct. In terms of privacy, our goals are to not leak any information about the anonymous and confidential payments in so far as the receiver does not challenge the payer.

Overview

1) payment requests are generated, encrypted and published to a smart contract; 2) the payer fetches the payment requests, decrypts them and verifies their correctness; 3) the payer settles the valid payments; 4) the payer publishes in the smart contract a confirmation of the payments; 5) receivers have a mechanism to challenge the payment confirmation by unblinding the incorrect payment and providing proofs of incorrect payment.

Protocol

Entity R generates a payment request, Pr, containing a) amount of tokens to receive b) an account address where to receive the funds and c) a set of arbitrary metadata. The payment request is encrypted using the public key of the entity P, which is responsible for settling the anonymous and confidential payment. In addition, R generates a commitment to the decrypted payment request. The payment request tuple is the following:

Pr = [Enc(Pr.pubkey, [fund_amount, Addr, {metadata}]), commitment]

Pr is published by R in the public store of the smart contract. The smart contract keeps an object which stores all pending requests, keyed by commitment

payment_requests = {
  Commitment_1: Enc(P.pubkey, [fund_amount_1, Addr_1, {metadata_1}])
  Commitment_2: Enc(P.pubkey, [fund_amount_2, Addr_2, {metadata_2}])
  ...
  Commitment_n: Enc(P.pubkey, [fund_amount_n, Addr_n, {metadata_n}])
}

P now proceeds to get the published payment requests, verify them and settling the payments if they are correct. The protocol goes as follows:

P regularly fetches fresh pending requests from the smart contract, decrypts them and checks their validity and correctness. The definition of correctness of the payments is arbitrary and depends on the business logic that application layer wants. For example, the metadata may have authorization tokens or any other proofs that P can verify.

P settles the valid payment requests using an anonymous and confidential payment system (e.g AZTEC)

P adds a vector with all payments' commitments to the smart contract's public store. This signals that P has settled the pending payments with those commitments

At this point, P has settled all valid payment requests R and there is enough public information about a) the payments which were settled by P and b) the payment requests that are considered invalid/not correct by P ( A ⋃ B - A ∩ B ). All this information is metainformation respecting the privacy of the payments themselves, i.e., no other entity besides P has learned about the address and amount of funds of each payment.

Challenging the correctness of a payment

R can publicly challenge P if a confirmed payment is incorrect. There are two scenarios in which a payment is considered incorrect:

R received a payment amount different than stated in Pr or;
R did not receive the payment in the address Pr, even after P has confirmed it.

Under one of these conditions, R can publicly challenge P and prove that payment is incorrect with regards to the committed Pr. The procedure to challenge a payment and prove it is the following:

How can a receiver/sender prove that a payment of N was made to account A using with AZTEC, even if it discloses both N, A?

gpestana / notes