Demystifying pod-core

pod is a novel layer-1 network, achieving fast finality, censorship resistance, and accountable safety all at once.

In the How it Works article, we show how pod achieves optimal latency and optimal throughput by finalizing transactions within a round-trip time. To achieve this, pod validators do not talk to each other. Instead, pod clients write and read from pod by sending a single message to each validator. In this post, we will take a deeper dive into the core algorithm of pod.

We will present the three core primitives — broadcast, chaining, and timestamps — that allow pod to confirm transactions at network speed. Then, we will introduce the rest of the properties achieved by pod — most notably, the notion of past perfection, ensuring that clients see all transactions up to a specific point in time.

The Setting

• Pod validators: n = 5f + 1 validators maintain the network, tolerating up to f Byzantine ones.
• An unknown number of untrusted clients send transactions (acting as writers) to validators and read (acting as readers) confirmed transactions.
• The network is asynchronous. We will denote by δ the time it takes a message from the slowest honest validator to reach a client.

First Ingredient: Best-effort Broadcast

A client writes a transaction by sending it to all validators. Each validator responds with a vote, which contains a signature on the transaction. Once the writer collects n - f votes, the transaction is considered confirmed.

In order to read the pod, clients subscribe to validators to receive votes. Validators provide both past votes (for confirmed transactions) and new votes as they are generated. Readers confirm transactions independently by verifying that at least n - f votes have been received.

‍

Various optimizations can be applied to this architecture without affecting the core protocol, such as employing secondaries and gateways. We refer to the How it Works article for further details.

Second Ingredient: Adding Chaining

Validator votes are chained using sequence numbers. Each validator maintains a sequence number and, whenever it receives a transaction, it increments the sequence number and appends it to the message that it signs. pod readers process votes from validators sequentially, that is, they only process a vote if it contains the next sequence number expected from the validator that sent the vote, or otherwise they backlog the vote.

This ingredient gives pod an interesting flavor. Imagine a pod reader serving as an auctioneer, using the bids confirmed on pod as input to an auction protocol. The auctioneer publishes the auction result and the latest sequence number it received from each validator. Because votes from each validator are chained, the auctioneer cannot censor bids without getting detected (except for bids whose votes appear in the end of a chain — this will be resolved with our next ingredient). Any party that reads the pod and observes the result of the auction can provably blame a censoring auctioneer.

We remark here that chaining is, in fact, achieved using more advanced data structures, such as Merkle and Segment trees. This allows for chaining even when clients selectively subscribe to transactions. Stay tuned for all the details!

Third Ingredient: Adding Timestamps

The next addition to the pod protocol is a timestamp, which validators include in each vote they create. The timestamp of a transaction is the local wall time of the validator when it received the transaction.

Altogether, a vote now contains the elements (tx, sn, ts), where sn is the sequence number and ts is the timestamp assigned to tx, and a signature on (tx, sn, ts). For a vote containing (tx, sn, ts) to be accepted by a client, the following rules must be fulfilled:

• no previous vote from the same validator can be on the transaction tx
• sn must be the next sequence number the client expects from that validator
• ts must be greater than or equal to the last vote (that is, the vote with sequence number sn - 1) sent by that validator

This simple addition allows for two crucial upgrades to the recipe of pod. First, readers can derive additional attributes on pod transactions. Specifically, they assign a confirmation timestamp to each confirmed transaction, computed as the median of the (at least n - f) votes received on the transaction. They can also compute a minimum timestamp and a maximum timestamp for each transaction. Two different clients may compute different confirmation timestamps to a transaction, but the confirmation timestamp will always lie between the minimum and the maximum timestamps any other honest client has computed.

If the transaction gets confirmed, then its confirmation timestamp will be between these two values. A reader derives these values from the votes it receives from the validators. A reader also derives a past-perfect timestamp T_PERF. In the example of the figure, the reader knows that no transaction other than TX₁ and TX₂ will ever obtain a confirmation timestamp smaller than T_PERF.

Second, and most importantly, this offers readers a completeness guarantee about the past, which we formalize as past perfection. Each reader can locally compute a past-perfect timestamp T_PERF using the votes it has already received from the validators. The reader is guaranteed that no new transaction may ever obtain a confirmation timestamp smaller than T_PERF. Our constructions achieves the following liveness property: a client that reads pod at time t will see the time t - 𝛅 as past perfect.

Benefits of Past Perfection

But why is this useful? Let us go back to the auction example. Remember that we had the auctioneer publish the auction result and the latest sequence number received from each pod validator. We will can now tell the auctioneer when to do this.

To this end, the application (built on top of pod) defines a timestamp t₁. The auctioneer must wait until it computes a past-perfect timestamp larger than t₁ (this will happen at t₁ + 𝛅, where 𝛅 is the actual network delay) and then run the auction. Now, together with the auction result, the auctioneer publishes the latest vote received from n-f validators, such that the vote contains a  timestamp larger than t₁. In essence what happens here is that the auctioneer commits to these votes, and at the same time, due to chaining, to all votes it has received in the past. The auctioneer can be held accountable if any client presents enough votes (compacted into a transaction certificate) for a transaction with confirmation timestamp smaller than t₁, but which has not been included in the auction input.

In other words, past-perfection allows pod to achieve accountable censorship resistance. Pod readers will see all transactions up to the past-perfect timestamp, and they cannot deny having done so. Note that this argument holds in asynchronous networks as well, and that it can be used as a black-box by any application built on top of pod.

Why Is This Not Consensus

One might wonder why past-perfection does not reduce to consensus. We saw that a pod reader that computes T_PERF as the past-perfect timestamp will have received all transactions that may ever obtain a confirmation timestamp up to T_PERF. Can the reader then not deterministically order these transactions, and achieve total order?

This comes down to the fact that two honest readers may see a different set of transactions, and they do not know which transactions will actually get confirmed. Transactions written by honest clients will get confirmed, and indeed with a confirmation timestamp at most T_PERF, but transactions written by misbehaving writers (e.g., not sent to all pod validators) may never become confirmed, hence may not appear in the output of all readers.

Conclusion

In this post we presented the technical details behind the core protocol of pod. We saw that pod confirms transactions within a single round-trip time. We also introduced the past-perfection property, ensuring clients who read the pod at time t that they have received all transactions that may obtain a confirmation timestamp up to t - 𝛅.

Acknowledgements

Thank you to  Zeta Avarikioti and Odysseas Sofikitis for providing resources, fruitful discussions, and feedback.

References

1. Pod Research Paper — https://arxiv.org/pdf/2501.14931