SoK: Auditability and Accountability in Distributed Payment Systems

Abstract

Enforcement of policy regulations and availability of auditing mechanisms are crucial building blocks for the adoption of distributed payment systems. In this work we review a number of existing proposals for distributed payment systems that offer some form of auditability for regulators. We identify two major distinct lines of work: payment systems that are not privacy-preserving such as Bitcoin, where regulation functionalities are typically tailored for organizations controlling many accounts, and privacy-preserving payment systems where regulation functionalities are typically targeted to user level. We provide a systematization methodology over several axes of characteristics and performance, while highlighting insights and research gaps that we have identified, such as lack of dispute-resolution solutions between the regulator and the entity under audit, and the incompatibility of ledger pruning or off-chain protocols with regulatory requirements. Based on our findings, we propose a number of exciting future research directions.

P. Chatzigiannis—did part of this work during an internship at Novi Financial/Facebook Research. Foteini Baldimtsi and Panagiotis Chatzigiannis were supported by NSF #1717067, NSA #204761 and a Facebook research Award.

A Cryptographic Background

1.1 A.1 Consensus

A consensus protocol allows a number of nodes to output a common agreement on input of a sequence of messages. In our setting, the commonly agreed value is typically recorded on a public ledger. The basic properties of a consensus protocol are [36] a) Consistency: On some input, all honest nodes make the same output. b) Liveness: An input proposed by some honest node will be eventually processed by all honest nodes after a finite number of rounds. A common distinction among consensus protocols is according to their failure model, where crash tolerant protocols assume failed nodes may become offline or otherwise stop interacting with the system, while Byzantine tolerant [47] protocols assume such nodes might also engage into malicious activity in order to defeat the above properties. These models typically assume different levels of adversarial power needed for the system to fail. Another distinction is based on the participation model, where permissioned consensus participation is open only to a closed set of parties, while permissionless is open to anyone, which however needs a mechanism to prevent attacks through “sybil” identities such as Bitcoin’s Proof of Work [51] or Proof of Stake protocols [45].

1.2 A.2 Distributed Payment Systems

A distributed payment system DPS (also known as ledger-based payment system) can be simply defined by the following algorithms and protocols when already assuming the existence of a consensus layer.

• $\mathsf {pp},L \leftarrow \mathsf {Setup}(\lambda )$: on input of security parameter $\lambda$, outputs public parameters pp and initializes a public ledger L to be maintained by the consensus layer. This algorithm is executed once in the setup phase of the system, and is run by either a single party or a quorum of parties in a multi-party computation (MPC) protocol. In the following algorithms and protocols, $\mathsf {pp}$ and L are default inputs and are omitted for simplicity.

• $(\mathsf {pk_{{}_{}}},\mathsf {sk_{{}_{}}}) \leftarrow \mathsf {CreateAcc}()$: Run by any party wishing to transact in the system⁵, outputs a public key pair.

• $\mathsf {tx}_{} \leftarrow \mathsf {CreateTx}(\mathsf {sk_{{S}_{}}},\mathsf {pk_{{R}_{}}},v)$: Run by a sender wishing to send value v to receiver, and outputs a transaction $\mathsf {tx}_{}$. Although here for simplicity we assume a single sender and receiver, a transaction can generally accommodate multiple senders and receivers. $\mathsf {tx}_{}$ is sent to the consensus layer in order to be included in L after verification.

• $\mathsf {VerifyTx}(\mathsf {tx}_{}):= \{0,1\}$ Verifies the validity of a transaction $\mathsf {tx}_{}$, given the state of the ledger L. Verification is typically performed in a distributed fashion in the consensus layer among all verifiers (often called “miners”), where agreement results in the update of the ledger’s state to $L'$ which contains $\mathsf {tx}_{}$.

1.3 A.3 Commitment Schemes

Commitment schemes are very commonly used in private DPSs, to hide transaction information. A non-interactive commitment scheme $\mathsf {Com}(\mathsf {pp}, m, r)$ takes as input public parameters $\mathsf {pp}$, a message m and randomness r and outputs a commitment value $\mathsf {cm}$. This value reveals no information about the message (hiding property) while it is hard to find $(m', r')$ such that $\mathsf {Com}(\mathsf {pp}, m, r) = \mathsf {Com}(\mathsf {pp}, m', r')$, when $m' \ne m$ (binding property). Certain commitment schemes, i.e. Pedersen commitments [53] allow for homomorphic operations over committed values, a useful property in private DPSs.

1.4 A.4 Zero Knowledge Proofs

A Zero Knowledge proof is an interactive protocol between a prover P and a verifier V where P based on a common input statement proves knowledge of a witness w without revealing to V any additional information other than this fact alone. In DPSs, zero-knowledge proofs are used extensively to provide privacy-preserving attributes, with transacting parties proving validity of a transactions based on a public ledger without revealing the full transaction details, while in recent works they are also used to prove compliance with regulatory requirements.

Range Proofs are Zero Knowledge protocols proving that a committed value v lies within some interval (a, b), with v as the witness. In a payment system setting, such proofs are typically used to show that v is positive or does not overflow a maximum presentable value. Most well-known construction families for range proofs include square decomposition [40], multi-base decomposition [55] and Bulletproofs [21], with the latter being the most efficient in terms of proof size. Obviously, one can generate constant size range proofs from trusted-setup based SNARKs like Groth16 [41]. In privacy-preserving DPSs they are often used to ensure their basic core properties discussed in Sect. A.2, but they are also used for regulation purposes (e.g. distinguish between transactions that exceed a value limit).

1.5 A.5 Interactive Zero Knowledge Proofs

An interactive zero-knowledge proof (ZKP) for statement $\{w: f(w,x)\}$ where x is publicly known and witness w is known only to prover P, is a protocol between P and verifier V that proves P’s knowledge of w such that f(w, x) holds. This protocol needs to satisfy the following:

• Completeness: Honest V is always convinced by an honest P who knows a valid witness w.

• Soundness: A malicious prover $P^*$ cannot convince a verifier for a false statement.

• Zero Knowledge: After executing the protocol, a verifier does not learn any additional information other than the validity of the statement.

An interactive ZKP can be converted to a non-interactive zero knowledge proof (NIZK) using the Fiat-Shamir heuristic [33]. In turn, a ZK - Succinct Non-interactive ARgument of Knowledge (zk-SNARK) is a non-interactive zero-knowledge proof that is succinct, namely its proofs are very short $O(\lambda )$ with efficient verification $O(\lambda |x|)$ [18].