Decentralized Timeboost Specification

[jill-espresso]

Decentralized Timeboost Specification - Feedback Welcome

We’re excited to share that Espresso Systems and Offchain Labs have jointly published the full specifications for Decentralized Timeboost.

The design builds off of Offchain Labs’ original Timeboost proposal with the goal of making it compatible with decentralized sequencers. There is currently a proposal before the Arbitrum DAO for the adoption of this original Timeboost proposal on Arbitrum One and Nova.

Decentralized Timeboost can be thought of as a follow-on and expansion of this prior work. Espresso Systems plans to develop and test Decentralized Timeboost and ultimately bring a proposal to the Arbitrum DAO for adoption.

Quick Timeboost Refresher

If you’re not familiar with Timeboost, it offers a new take on transaction ordering by introducing a fair-auction mechanism designed to enable good forms of MEV (i.e., arbitrage) while mitigating predatory MEV tactics like front-running and sandwich attacks.

Timeboost enables auctions for the rights to an express lane, through which users can bid for a time advantage (i.e., a time boost ) for their transactions and potentially capture arbitrage and backrunning opportunities. In existing FCFS systems, arbitrageurs and predatory MEV extractors compete to get their transactions submitted first with souped-up hardware and by trying to locate servers as geographically close to the sequencer as possible, creating an unlevel playing field where sophisticated actors have the upper hand. Timeboost levels that playing field by introducing a permissionless auction for the express lane in which anyone can bid and win.

Decentralized Timeboost

Decentralized Timeboost builds on the original design through the introduction of a sequencer committee, as well as optional use of an encrypted mempool.

The sequencer committee is composed of multiple nodes and is responsible for ordering a block’s transactions, including those with a time boost submitted by the auction winner. The committee can tolerate up to one-third Byzantine or malicious nodes.

Users of a chain using Decentralized Timeboost also have the option to encrypt their transactions before they’re sent to the committee. This protects them from front-running, sandwich attacks, and censorship as the committee doesn’t decrypt the transactions until after they’re ordered.

While not yet part of the specification, Espresso Systems is also exploring how existing auction designs, like that of the Espresso Marketplace, might be leveraged for selection of the “priority controller” in the Decentralized Timeboost implementation.

Call for Feedback

We’d love to hear your thoughts and feedback on the design for Decentralized Timeboost. Please review the spec and share your input on how we can improve Decentralized Timeboost and make it a robust option for rollup ecosystems with decentralized sequencers.

Looking Ahead

Now that we’ve published the spec for Decentralized Timeboost, we’re looking ahead to what’s next. Our plan includes:

• Refining the design: We’ll continue to tweak the design as needed to ensure the protocol meets the needs of different rollup architectures. We’d love feedback from the Arbitrum community to inform this process!
• Further testing: Espresso Systems will lead ongoing development of Decentralized Timeboost with continued collaboration from Offchain Labs.
• Implementation: We will implement and deploy Decentralized Timeboost as a transaction-ordering option for rollups that integrate with Espresso (mainnet coming soon!)
• Adoption: We hope to see organic adoption of Decentralized Timeboost among Orbit chains and rollups building on other stacks and in other ecosystems. Our goal is to ultimately make a proposal to the Arbitrum DAO that Decentralized Timeboost be adopted for Orbit chains opting to decentralize their sequencer.

Final Thoughts

Our collaboration with Offchain Labs and the release of Decentralized Timeboost marks a significant milestone in our ongoing mission to empower rollups with new and innovative infrastructure options, especially those that enable decentralization and cross-chain composability without the need for rollups to sacrifice scalability or their sovereignty.

We look forward to engaging with the Arbitrum community on Decentralized Timeboost!

[sam.ng]

Is it correct to say that there is no separation between the block builder and the block proposer in decentralized timeboost for Arbitrum? Or can we imagine the entities in the Espresso marketplace acting as block builders and the sequencer committee of Arbitrum acting as block proposers?

Regarding decryption, is it fair to say that the decryption key is essentially attached to the sequencer’s consensus vote (so decryption happens simultaneously)? I assume there is always added latency due to bandwidth, sending more data around and doing calculations etc…

As for the block building engine, if we think about the Arbitrum sequencer as both the front end and back end, are you suggesting that the back end remains the same, whether it’s a centralized Timeboost or decentralized Timeboost, since the state transition functions are deterministic? In a sense, only the front end changes because now there is a consensus that needs to be reached between operators.

Looking forward to seeing how the UX will turn out, as Arbitrum’s preconf is such a key feature/differentiator. If it can remain close to how it is today, that’s great. If not, I’m curious to see whether the DAO will prefer keeping a centralized Timeboost with trust assumptions or if more latency in a decentralized setup will be preferred. Great stuff anyway!

[edfelten]

Several good questions there!

You’re correct that in the specification there is no distinction between block proposer and block builder. The protocol causes all honest parties to build the same sequence of blocks, so there is no need for a separate block proposer role.

Regarding decryption, the specification does not try to piggyback the decryption shares onto the final messages of the decryption protocol. The most obvious way of doing that kind of piggybacking has the drawback that if some honest members vote for some inclusion list, but that inclusion list doesn’t get enough votes to reach consensus, then some decryption shares have been leaked to adversaries. To prevent this, the current spec has honest members publish their decryption shares only after they know that the inclusion list has reached consensus.

There is ongoing research suggesting that it may be possible to make the decryption shares “single-use” in the sense that shares generated in one protocol round aren’t useful for decryption in later protocol rounds. That would enable the kind of piggybacking you suggest to be done safely.

I tend to think of sequencing and execution as separate parts of the broader Arbitrum protocol, where sequencing only decided on an ordered set of transactions that are deemed to have arrived at the chain, and execution determines the result of executing those transactions in order. The new spec only applies to the sequencing part of the protocol.

You’re right to identify latency as one of the key metrics for the implementation of this protocol.