MiniLedger: Compact-Sized Anonymous and Auditable Distributed Payments

Abstract

In this work we present MiniLedger, a distributed payment system which not only guarantees the privacy of transactions, but also offers built-in functionalities for various types of audits by any external authority. MiniLedger is the first private and auditable payment system with storage costs independent of the number of transactions. To achieve such a storage improvement, we introduce pruning functionalities for the transaction history while maintaining integrity and auditing. We provide formal security definitions and a number of extensions for various auditing levels. Our evaluation results show that MiniLedger is practical in terms of storage requiring as low as 70 KB per participant for 128 bits of security, and depending on the implementation choices, can prune 1 million transactions in less than a second.

F. Baldimtsi—The authors have been supported by the National Science Foundation (NSF) under Grant 1717067, the National Security Agency (NSA) under Grant 204761, an IBM Faculty Award and Facebook Research Award.

A MiniLedger Security and Extensions

1.1 A.1 MiniLedger security

We achieve the security of MiniLedger construction as follows: Theft prevention and balance: relies on NIZK soundness of $\pi$ (e.g. prevent a cheating prover to make false claims such as knowledge of $\mathsf {sk_{{}_{}}}$ or v in range) and consensus consistency. Secure pruning: relies on accumulator soundness (e.g. prevent accepting a digest not representing the exact set of pruned transactions) and consensus consistency. Ledger correctness: relies on consensus consistency. Correct and Sound auditability: relies on NIZK soundness (e.g. preventing convincing an auditor for a false claim), accumulator soundness and consensus consistency. Privacy: relies on IND-CPA security of ElGamal variant, Pedersen commitment hiding and NIZK zero-knowledgeness (e.g. prevent distinguishing information on the ledger or leaking private information during transaction creation).

1.2 A.2 Adding Clients for Fine-grained Auditing (MiniLedger+)

At a high level, each Bank $\mathsf {B}_{j}$ maintains a private ledger of clients $L_{\mathsf {B}_{j}}$ (denoted as “UsrDB” in Fig. 1), independent of the public ledger L. For each client m, $\mathsf {B}_{j}$ stores its transactions in encrypted format. For a $\mathsf {B}_{s}$ client to transfer value v to a $\mathsf {B}_{r}$ client, she creates a transaction that includes encryptions of the recipient client’s $\mathsf {pk_{{}_{}}}$, the receiver’s Bank $\mathsf {B}_{r}$ and v, as well as appropriate NIZKs to prove consistency with the protocol, which is recorded on the private ledger $L_{\mathsf {B}_{s}}$. Then $\mathsf {B}_{s}$ constructs a transaction on L that transfers v to $\mathsf {B}_{r}$, which in turn decrypts the information and allocates v to its recipient client. MiniLedger+ preserves anonymity while enabling fine-grained auditing at a client level, including checks that Banks allocated the funds correctly. It also has minimal overhead compared to MiniLedger while still maintaining a ledger of constant size. We provide a detailed description and analysis in the full version [15].

1.3 A.3 Additional Types of Audits

As shown in Sect. 4.1, MiniLedger basic audit functionality $\mathsf {Audit}\{\}$ is on the value $v_{ij}$ of specific transaction $\mathsf {tx}_{ij}$. Several more audit types can be constructed which reduce to that basic audit. We discuss some of those below, and provide more details for audit extensions in the full version [15]. Note these audits can still be executed for pruned data.

Full Transaction Audit: For an auditor to learn the full details of a transaction (sender, receiver and values), they would have to audit the entire row (i.e. perform n audits on $v_{ij}~\forall j$).

Statistical Audits: Audits such as average or standard deviation are supported by utilizing “bit flags” to disregard zero-value transactions, proved for correctness in zero knowledge.

Value or Transactions Exceeding Limit: Utilizing appropriate range proofs, an auditor can learn if a sent or received value exceeds some limit t. Multiple range proofs can show a Bank has not exceeded the limit over a time period.

Transaction Recipient: The goal of this audit type is for a sending Bank to prove the recipients for one of its transactions. While a Bank doesn’t know (and therefore cannot prove) where a received value came from (unless learning it out-of-band as in zkLedger), for outbound transactions the Bank can keep an additional record of its transaction recipients in its local memory. As an example, for proving in $\mathsf {tx}_{i}$ that the Bank really sent $v_{ij}$ to $\mathsf {B}_j$, it could send this claim to the auditor who in turn would simply then audit $\mathsf {B}_j$ to verify this claim.

Client Audits: Audits in a client level (e.g. statistical audits or transaction limits) can be performed similar to the respective audits in a Bank level, however the auditor needs first to learn and verify the Bank’s private ledger $L_B$ as discussed above. From that point, the auditor can perform all audits in a client level in a similar fashion to the respective audits in a Bank level. For instance, to learn if some MiniLedger+ client exceeded a value transaction threshold within a time period or over a number of transactions, this audit can be executed by selecting the client’s transactions from the Bank’s private table that happened within this period by their id’s. The audit would then be on the sum of the values represented by the product of the respective ciphertexts, and the client would produce a range proof for that ciphertext product as above. and select those with the appropriate timestamp. A special useful audit would be to learn if a MiniLedger+ client has sent assets to some specific client $\mathsf {pk_{{}_{}}}$ or not. The transactions would need to be augmented with an additive universal accumulator, with each sender adding the end client recipient’s $\mathsf {pk_{{}_{}}}$ to the accumulator, while also providing its Bank a ZK proof of adding the correct public key. During an audit, the client would have to prove membership (or non membership) to the auditor. An important note is that the receiving client does not directly learn the original sender of a specific transaction in-band, which implies the above approach cannot work for a client to prove if he has received (or not) assets from another client.

Non-interactive Audits: The audit proof $\pi ^{\mathsf {Aud}}$ described in Sect. 4 is interactive and require the Bank’s consent. While can treat a Bank’s refusal to cooperate as a failed audit, we could still enable non-interactive audits by including an encryption of $\pi ^{\mathsf {Aud}}$ and its statement for each transaction cell under a pre-determined trusted auditor’s public key (which preserves privacy). Our full version [15] provides more details.