Decentralized Approximate Timekeeping Oracle
Many problems in blockchains right now can be helped by having a lightweight protocol that can agree on which messages were seen, and when they were seen. Note that this does not require total ordering, meaning there is no need for full BFT SMR protocols like Tendermint or Hotstuff, which often implies having a single leader, limited throughput, and added latency.
Instead, reaching rough consensus on time can be achieved by sending a message
DATO exhibits the following properties:
- Linear communication complexity:
$n \times (m + r)$ ($m$ = message size,$r$ = response size) - Minimal, constant latency
- Maximal throughput
We'll look at 3 use cases:
- Fair exchange accountability
- Censorship-resistant message feeds
- Simultaneous release in BRAID
Suppose Alice wants to trade an item with Bob over the internet in an atomic manner, meaning that both parties receive the item, or none do. This is known as the fair exchange problem, and it is generally unsolvable without a trusted third party (TTP).
PBS is an example of this, where the relay (TTP) mediates the fair exchange by only delivering the payload to the proposer if the proposer has committed to the associated header. Decentralizing PBS could involve replacing the relay with a committee that, among other things, votes on the timeliness of the payload reveal (the PTC design).
Other duties like checking block validity and the block value could be done inside of a TEE like in TEE-Boost, but making sure the builder reveals the payload when a proposer has committed to it needs to be solved in another way (host machine can always censor incoming and outgoing TEE traffic).
With DATO, we can optimistically replace the relay by acting as a "record of communication" between the builder and the proposer. In case of a fault, anyone can replay the certified log of records to use as evidence.
Flow
- Happy case
- (Staked) builders make bids to a proposer (direct communication)
- Proposer selects a winning bid and broadcasts the commitment on DATO and directly to the builder
- DATO timestamps the commitment (
$T_{commit}$ ) - Builder reveals the payload by broadcasting it on DATO (and on the Ethereum P2P network)
- Signed block is proposed
- Faulty case
- (Staked) builders make bids to a proposer (direct communication)
- Proposer selects a winning bid and broadcasts the commitment on DATO and directly to the builder
- DATO timestamps the commitment (
$T_{commit}$ ) - Builder does NOT reveal the payload
- Proposer misses the block, but can request a certificate of UNAVAILABILITY for the timestamp at
$T_{commit} + \Delta$ - Proposer uses the certficiate of UNAVAILABILITY to slash the builder
Fair exchange problems also show up in various proposer commitment & preconf protocols like Bolt, which is where we initially got the idea.
In the case of single-sequencer protocols like current rollups, or TEE-run auctions, it is currently not possible to attribute censorship faults. Having a verifiable record of messages fixes that issue, and can reliably detect even very short-term censorship.
Sequencers could commit to reading their inputs from DATO (as an additional channel next to direct RPC). Any message sent on DATO would need to be included within some delta set by the protocol. If these messages are not included within that delta, users can use the certificate to attribute a censorship fault. For mempool privacy, transactions on this layer can be encrypted with the sequencer public key.
TEEs could also commit to reading their bids from DATO, which (in the case of verifiable auction rules) could allow anyone to verify the outcome of an auction. This could detect the censorship of bids.
BRAID (an implementation of MCP), has an incentive problem when various proposers for a round are supposed to release their partial block. This is because other proposers could benefit from looking the contents of other proposers' blocks in the case they contain profitable transactions. They can then steal these transactions and put them in their own partial blocks.
A potential solution could look like this:
- Proposers threshold encrypt their partial blocks and broadcast it on DATO along with a "delay" request
- DATO validators timestamp the request, but only reveal it after the delay (timelock)
- Clients can collect the quorum certificate after the delay and decrypt the payload
The only way for proposers to steal the payloads from other proposers is for them to wait until the timelock is completed and collect the quorum certificate. Only then will they be able to broadcast their partial blocks, which would be too late and detectable.
NOTE: this would require some added functionality to DATO for the time locking functionality.
Requirements:
You can run DATO yourself with the launch.sh script.
- Build the client and validator images:
./launch.sh -b- Run the test setup with a registry file, for example with 200 validators:
./launch.sh -r registry-20.txtThis will run 20 validators, and 1 client. The client will connect to all validators. Simulated latency will be added
to the links between the clients and the validators (between 0 and 400 by default, tune this limit with the -l flag)
You can then run the demo example with:
cargo run --example cr_feedThe demo is setup like this:
- Analyzing the security properties (tolerated threshold adversary, network models)
- Performance analysis & testing
- DATO for threshold encryption
- Handling of fees for validators