Carbon: Scaling Trusted Payments with Untrusted Machines

TL;DR

Carbon tackles scalable, trust-minimized payments in an asynchronous setting by replacing consensus with Byzantine reliable broadcast (Draft) and leveraging untrusted brokers to scale operations. It supports dynamic validator reconfiguration via asynchronous voting (Dibs) and uses lightweight client bootstrap/registration to bound storage while maintaining security against eclipse. The system demonstrates up to 1M tx/s with end-to-end latencies around 10–11 seconds, outperforming state-of-the-art consensus-based or privacy-preserving counterparts in throughput at similar latencies. Its design also enables flexible voting, low overhead for client authentication, and CBDC-compatible incentive models, making it a practical blueprint for global payment systems.

Abstract

This paper introduces Carbon, a high-throughput system enabling asynchronous (safe) and consensus-free (efficient) payments and votes within a dynamic set of clients. Carbon is operated by a dynamic set of validators that may be reconfigured asynchronously, offering its clients eclipse resistance as well as lightweight bootstrap. Carbon offers clients the ability to select validators by voting them in and out of the system thanks to its novel asynchronous and stake-less voting mechanism. Carbon relies on an asynchronous and deterministic implementation of Byzantine reliable broadcast that uniquely leverages a permissionless set of untrusted servers, brokers, to slash the cost of client authentication inherent to Byzantine fault tolerant systems. Carbon is able to sustain a throughput of one million payments per second in a geo-distributed environment, outperforming the state of the art by three orders of magnitude with equivalent latencies.

Figures (8)

• Figure 1: Overview of the Draft brb protocol oracular-brb-disc22 totaling 13 steps (#1--#13) between 2 clients (C1--C2), 1 broker (B1) and 4 validators (V1--V4). Clients broadcast a Carbon operation in #1 and receive confirmation of delivery in #10. Compared to the original algorithm, Carbon merges two steps in both #4 and #5 for efficiency. Arrows of optional steps are dashed.
• Figure 2: Carbon system and payment protocol overview. Carbon is composed of clients, validators, and brokers assisting validators, each with unique joining and resilience models.
• Figure 3: Example of operation safety during reconfiguration. Consider two views: (1) the genesis view $v_1$, with validators $V_1, V_2$, $V_3$ and $V_4$, and (2) a view $v_2$, with validators $V_5$, $V_6$, $V_7$ and $V_8$. All validators are correct, except for $V_2$ and $V_7$. Initially, a faulty client successfully commits its operation $o_1$ intended for $v_1$ (the left part of the figure). Then, the system reconfigures and view $v_2$ is "produced" (the right part of the figure). At this point, the client tries to commit two conflicting operations: $o_2$ intended for $v_1$, and $o_3$ intended for $v_2$. However, as a quorum of three validators of $v_1$ stopped processing operations intended for $v_1$, the client collects at most $2$ approvals for $o_2$: one from the faulty validator $V_2$, and one from the correct validator $V_4$ which did not approve the system's transition to $v_2$. As at least three approvals are needed, $o_2$ does not get committed, which preserves safety.
• Figure 4: Carbon's voting protocol. Clients issue Support operations to indicate a vote for a motion. A motion eventually passes when the summed balance of all supporting clients' accounts reaches more than 50% of the total supply.
• Figure 5: Load handling of Carbon and its baselines. Carbon sustains the delivery of 1M tx/s without contention. With an equivalent latency of 8--15 s, the throughput of Algorand and Quorum remains below 1,000 tx/s, while FastPay reaches up to 5,200 tx/s with a latency consistently below 3 s.

Theorems & Definitions (266)

• Theorem 1: Integrity
• proof
• Theorem 2: Decision Certification
• proof
• Theorem 3: Comparability
• proof
• Lemma 1
• proof
• Theorem 4: Validity
• proof