Dionysis Zindros, Common Prefix

Pod is a new blockchain-related primitive that takes transactions as input and produces a log (sequence of transactions) as output. It is a service that receives unordered transactions submitted into the mempool and orders them into a log. Contrary to blockchains and other consensus protocols, pod does not provide a persistent total order of transactions. While it does give some order, this order is subject to change with time — transactions “wiggle” around their positions in a somewhat predictable fashion. Accepting this wiggle room allows for making a very performant system. In particular, pod is latency-optimal and throughput-optimal. This optimality means that no other system can exceed the throughput and latency of the pod if provided with the same resources among validators and if all validators are required to record all transactions.

A log in which transactions are not fully set in stone in their positions is useful for many applications, although not every application. It can be used to run auctions with the help of a friendly but untrusted auctioneer in a way that enables accountable assurances of non-omission of honest bids. It can be used to conduct simple payments using pre-funded transactions. It can be used to transfer pre-committed NFTs. It can be used to notarize data and to provide a byzantine-resilience feed to data-driven apps such as decentralized social media. On the other hand, it cannot handle complex DeFi protocols such as Uniswap in which every transaction’s outcome, such as the swapping price, strictly depends on every previous transaction in an intimate manner. However, many systems (such as swaps) can be rewritten in a commutative fashion, which enables them to efficiently run on top of pod. Critically, while maintaining performance, pod provides short-term censorship resilience, meaning that an adversary cannot censor honest transactions even in the short term. This guarantee is similar to other leaderless protocols.

Figure 1: Transactions in full order and transactions with wiggle room

All EVM contracts (such as Solidity) can be readily deployed to the pod, but making full use of the pod’s efficiency requires the execution layer developer to be aware of the consensus semantics and to augment their smart contracts to use the right keywords, enabling fast execution. This lets pod execute the contract fast-track. Otherwise, confirmation will be fast, but smart contract execution will be slow. Our backwards-compatible extensions to Solidity — SolidityX — enable developers to express these nuances and optimize their contracts for fast-track.

Pod offers the following advantages:

• Optimal Latency. Transactions are confirmed in about 200ms, even though the system's validators are operated across the globe. This confirmation latency is optimal because it hits the speed of light limit. Formally, we achieve liveness u equal to the real network latency round-trip time 2δ in synchrony and eventual liveness in asynchrony. Fast latency is guaranteed in synchrony, while weak accountable safety is guaranteed even in asynchrony.
• Optimal Throughput. Transactions are treated as simple string messages. The pod construction allows transactions to be confirmed at a throughput that matches the Internet connection of the validators—in a home connection, this is 1 Gbps. This is optimal because a validator must at least see transactions before they get confirmed. Pod also borrows the well-understood consensus–execution separation principle to disentangle expensive compute from the consensus layer.
• Simplicity. Pod uses a very straightforward and simple design, making it easy to implement and audit. While it has many extensions enabling advanced behaviors, pod’s “consensus” core is just a few hundred lines of Rust code. The dependencies used in Pod’s core are just hash functions and signatures—no zero knowledge, multiparty computation, pairings, or other moon math. Pod’s extensions employ more advanced cryptographic techniques to enable more powerful features on top, but the heart of the construction is very simple.
• Scalability. Pod borrows its design from traditional relational DBMS systems from the 80s, 90s, 00s, and 10s, before the web3 era. These techniques are very mature, but have not been designed to be byzantine-resilient. Pod leverages these techniques to scale to Internet scale. Such structures include separating write from read replicas (the primary–secondary paradigm), efficient caching and indexing, load balancing, and hot swapping.
• Light clients. Pod has built-in light client support based on an elegant and simple, yet efficient, data structure called a Merkle Segment Mountain Range that uses bloom filters. The structure combines Merkle Trees with Segment Trees to allow for accountable light clients. Light clients can obtain information about only the smart contracts they’re interested in but can also verify, in an accountable fashion, that no information has been omitted. The construction does not require the light client to trust any server intermediaries. Our light client data structure borrows and extends older, well-understood protocols such as Google’s Certificate Transparency.
• Byzantine Resilience. Like many blockchain protocols, pod is byzantine resilient, meaning it can withstand arbitrary adversarial attacks and the corruption of a proportion of the validators. Our construction leverages well-understood, peer-reviewed research results from the distributed systems literature, such as the FastPay and ABC consensus papers. These constructions have provable security guarantees against any adversary.
• Accountability. Every validator claim in pod is accountable — from the confirmation of a single transaction, to the response to a light client query about a particular smart contract, to the full log report provided to full nodes. Faulty validators are slashable through an AVS (like EigenLayer) mechanism that can adjudicate in case of emergency. Resorting to AVS slashing is only needed when honest supermajority assumptions are violated, which is a rare occurrence. Otherwise, safety is guaranteed without the need to call an AVS.
• EVM compatibility. The vast majority of EVM smart contracts, such as contracts written in Solidity, are supported by pod out of the box. If a developer wishes to leverage the fast path of pod, they must modify their smart contract to annotate ownership semantics.

Construction

The pod construction is a very simple one and can be explained in just a couple of minutes. Its infrastructure consists of a handful of validators whose job is to record transactions. Validators do not talk to each other directly and do not process each others’ signatures. This is exactly what makes pod so quick. The validators are known to the users. Users of the protocols run clients that connect to these validators. They write transactions to them that eventually become confirmed, and they read a log out of them to discover the confirmed transactions’ order.

Each validator maintains a local, totally ordered temporal log. A temporal log is a sequence of transactions, each associated with a timestamp. The timestamps have millisecond precision and must be non-decreasing. Each validator’s temporal log is its own local data structure and is unaffected by what other validators are maintaining. A client that wishes to write a transaction connects to all validators and sends them the transaction of interest. Whenever a validator receives a new transaction from a client, it appends it to its local log, together with the current timestamp based on its local clock. It then signs the transaction with the timestamp and hands it back to the client. The client receives the signed transaction and timestamp, and validates the validator’s signature using its known public key. As soon as the client has collected a certain number of signatures from the validators (e.g., α = 2/3 of the validators), the client considers the transaction confirmed. The client associates the transaction with a timestamp, too: the median among the timestamps signed by the validators.

A client can request the full log of each validator. Upon such a request, the validator returns the full log containing timestamped transactions, together with the current timestamp, all signed by the validator key. A client who wishes to obtain a full picture of confirmed transactions reaches out to all the validators and requests their full log. The client then considers any transaction with more than α signatures confirmed and assigns the median timestamp to it. The client orders the transactions using these median timestamps, which are the client’s log. Because different clients may receive a response from a different subset of validators, they may not arrive at the exact same timestamp for a given transaction. That’s what gives rise to a transaction’s wiggle room. However, a client can find upper and lower bounds for that wiggle room, a parameter we call a transaction’s minimum and maximum temperature.