Proof of Sequence

Proof of Sequence embeds transactions in a proof of elapsed time. It achieves verifiable fair ordering layer subject to VDF limits.

POSq

POSq is designed to produce a canonical order of transactions at the protocol level. Unlike other blockchains that leave sub-block ordering to the discretion of the validator, on Continuum disordering transactions causes an invalid state transition function. (protocol enshrined ordering). The core mechanism of the Proof of Sequence is built on a recursive RSA-Group VDF, producing an ongoing proof of elapsed time, and anchoring transactions in that timechain. Transaction hashes are embedded in each sequential "tick" of VDF computation, making it prohibitively difficult to rewrite the past chain rapidly.

Sequenced transactions are continously streamed by the leader to all other validators (turbine like propagation planned if validator set is to be expanded beyond ~80). There is no delay for execution, and the leader signs all included ticks, committing to the order of transactions. Unlike just inclusion receipts, this prevents rewriting of history structurally, especially after a significant delay. Even if the users are not constantly comparing receipts to detect misordering, this makes reordering structurally hard, and detectable by other validators.

Proof of Inclusion - Reciepts

Immediately on tx. reciept, the leader produces an instant proof of inclusion - a signed reciept, including the: i) Transaction hash, and ii) VDF hash at the inclusion tick number. For colocated clients (i.e. in same AZ as the leader), confirmations are to be expected in <1ms. This enshrines the position of the transaction in the timechain, and serves as a simple fraud proof if the sequencer produces another signed timechain with a different transaction at that tick. Targeted, selective delay of transactions is prevented by Encryption (described below): Wide, significant delay in inclusion of transactions should be detectable by by the social layer (leading to forced rotation), and is unlikely to yield much benefit to the sequencer. In regular operations, all users can essentially treat proof of inclusion as a binding proof of order. More details on #finality.

Timelock Encryption

To make reordering structurally infeasible even by the leader, users can opt for timelock encryption (details in white paper). This leads to blind ordering, with the transaction not decrypting till the proof of inclusion has been formed. The combined effect of the three componensts is Verifiable Ordering To illustrate, assume the sequencer wants to frontrun a transaction, and wishes to take the following steps: At tick t (let's say 0 ms) the transaction arrives. It is included in the timechain. Then at tick t+10ms, the transaction is decrypted. by then, the vdf computation has advanced, and as long as the difficulty retargeting is accurate, it becomes nearly infeasible for the sequencer to redo the chain rapidly. This is especially true at scale. This is essentially reduces to, for eg. the following unfeasible requirement to disguise the reordering where the transaction stream being broadcast is observed in real time by other validators. The key distinction is that in the naive case (no VDF), say a 10 ms delay could at worst be attributed to jitter - allowing the sequencer to decrypt the transaction and frontrun it. In the POSq scheme, to plant a transaction 10ms in the past, the sequencer would have to catch up to 10ms of computation. This is hard to do in short order (would require a 20%-30%+ faster VDF machine, unlikely if tuned correctly). The problem then reduces to something like: in the next 40ms, produce a VDF of 50ms Now, to complete the deception, the sequencer would have to justify a >100ms streaming delay, to create a forged timechain. 100ms is in any case considered a liveness fault, leading to sequencer rotation. Note on VDF Difficulty

VDFs are hard in a somewhat analgous way to Proof Of Work, in that they require a target time to compute on best case hardware - execept unlike POW, VDF calculations are not parallizable. Nevertheless, to account for VDF improvements, difficulty retargetting to maintain tick cadence is built in. The current design targets 27 iterations per 100 Microseconds, optimize

This is subject to hardware limits of single threaded computation by design. V1 relies on an optimized CPU execution, while V2 will require FGPAs (and eventually potentially ASICs at the limit) - to provide security of elapsed time at the physical limit of available machines at a given time.

User Flow

Users submit (optionally timelock encrypted) transactions to the Sequencer. The sequencer maintains a cryptographic, VDF-based "clock" as a trustless proof of elapsed time / timekeeping device which is not tamperable. Upon submitting the transaction, it is instantly assigned a canonical queue position (a VDF "tick"), and it is instantly broadcast to full nodes - in a continuous manner, for execution. In this way, transaction inclusion and execution is final the moment the transaction is accepted by the sequencer - there is no batching or waiting for blocks to learn the fate of the transaction. For all intents and purposes, transaction inclusion and execution is Continous.

Blocks produces distinct boundaries around which reordering is profitable in classical blockchains. In continuum, transaction processing is continuous. Batches are put into "blocks" at a later stage in deterministic fashion, purely for voting and economic finality - however from a user or full node perspective, execution remains real time with no natural boundaries. POSq is a natural successor to previous onchain timekeeping protocols like Proof Of History (POH). While the tech stack is explained in more detail in our whitepaper , we examine the core sequencing primitive briefly here.