Table of Contents
Fetching ...

ZipperChain: Transmuting Trusted Third-Party Services Into Trustless Atomic Broadcast

Matteo Bjornsson, Taylor Hardin, Taylor Heinecke, Marcin Furtak, David L. Millman, Mike P. Wittie

TL;DR

ZipperChain reimagines blockchain correctness by transferring trust from distributed consensus to trusted third-party services (timestamp, sequencer, and replication). By structuring blocks, Merkle trees, and triads under attestations signed by these services, it achieves near line-speed throughput with rapid finality and eliminates the need for a native token. The approach relies on robust cloud-provider-backed services and TEEs to ensure immutability, agreement, and availability, while offering interoperability across app-chains and off-chain deterministic execution for smart-contract-like functionality. The work discusses practical considerations such as reliability, censorship resistance, and availability, and demonstrates promising performance, albeit with centralized operational assumptions and explicit trust in external services.

Abstract

Distributed ledger technologies (DLTs) rely on distributed consensus mechanisms to reach agreement over the order of transactions and to provide immutability and availability of transaction data. Distributed consensus suffers from performance limitations of network communication between participating nodes. BLOCKY ZipperChain guarantees immutability, agreement, and availability of transaction data, but without relying on distributed consensus. Instead, its construction process transfers trust from widely-used, third-party services onto ZipperChains's correctness guarantees. ZipperChain blocks are built by a pipeline of specialized services deployed on a small number of nodes connected by a fast data center network. As a result, ZipperChain transaction throughput approaches network line speeds and block finality is on the order of 500 ms. Finally, ZipperChain infrastructure creates blocks centrally and so does not need a native token to incentivize a community of verifiers.

ZipperChain: Transmuting Trusted Third-Party Services Into Trustless Atomic Broadcast

TL;DR

ZipperChain reimagines blockchain correctness by transferring trust from distributed consensus to trusted third-party services (timestamp, sequencer, and replication). By structuring blocks, Merkle trees, and triads under attestations signed by these services, it achieves near line-speed throughput with rapid finality and eliminates the need for a native token. The approach relies on robust cloud-provider-backed services and TEEs to ensure immutability, agreement, and availability, while offering interoperability across app-chains and off-chain deterministic execution for smart-contract-like functionality. The work discusses practical considerations such as reliability, censorship resistance, and availability, and demonstrates promising performance, albeit with centralized operational assumptions and explicit trust in external services.

Abstract

Distributed ledger technologies (DLTs) rely on distributed consensus mechanisms to reach agreement over the order of transactions and to provide immutability and availability of transaction data. Distributed consensus suffers from performance limitations of network communication between participating nodes. BLOCKY ZipperChain guarantees immutability, agreement, and availability of transaction data, but without relying on distributed consensus. Instead, its construction process transfers trust from widely-used, third-party services onto ZipperChains's correctness guarantees. ZipperChain blocks are built by a pipeline of specialized services deployed on a small number of nodes connected by a fast data center network. As a result, ZipperChain transaction throughput approaches network line speeds and block finality is on the order of 500 ms. Finally, ZipperChain infrastructure creates blocks centrally and so does not need a native token to incentivize a community of verifiers.

Paper Structure

This paper contains 24 sections, 7 equations, 5 figures, 1 table, 2 algorithms.

Figures (5)

  • Figure 1: AWS Nitro Enclave.
  • Figure 2: A ZipperChain blockchain formed through links between blocks ($b$), Merkle trees ($m$), timestamps attestations ($t$), and sequence attestations ($s$).
  • Figure 3: A fork in a ZipperChain blockchain.
  • Figure 4: ZipperChain block finality and throughput.
  • Figure : $\textit{makeCertificate}(d, M, Z)$

Theorems & Definitions (3)

  • Definition 3.3.1: Immutability
  • Definition 3.3.2: Agreement
  • Definition 3.3.3: Availability