Proposed design for Timeboost

1

The Offchain Labs research team has a specific proposed design in mind for adding Timeboost to the current centralized sequencer design. This would allow Arbitrum chains to prevent front-running, while capturing the value of benign MEV types like arbitrage.

The design has two parts: a change to the sequencer’s transaction ordering policy, and a new transaction type.

The sequencer’s ordering policy would go in rounds, with each round containing these steps:

  • the sequencer waits for a fixed period (tentatively: 0.5 seconds), collecting all transactions that arrive before the end of the period
  • the sequencer sorts the collected transactions into decreasing order by bid, breaking ties by a deterministic rule,
  • the sequencer builds a block from the sorted transaction list and emits that block into its output feed,
  • the round ends and the next round starts

The new transaction type is identical to a standard user-signed transaction, with the only differences being (1) a different transaction type label, and (2) how transaction fees are collected by the chain. For the new transaction type, the chain would collect the priority fee (“tip”) per gas unit as in Ethereum. (By contrast, standard transaction types don’t pay the priority fee on Arbitrum chains.) So the new transaction type would pay a gas price equal to the current Arbitrum-chain base fee plus the transaction’s priority fee.

A transaction’s bid, for sorting purposes, is (1) its priority fee, if it is the new transaction type, or (2) zero, for other transaction types. So a transaction can get earlier placement within its block by paying a higher priority fee. This implements a sealed-bid, all-pay, priority gas auction for position within the block.

In this design, the sequencer does not collect any “MEV fees”. Instead, transactions bid for position by offering to pay a priority fee for each gas unit they use. The resulting fees are collected by the chain, as part of its normal gas fee collection mechanism.

The priority fees would be collected by the chain and paid to an address specified by chain governance. In the case of DAO-governed chains, this address would be specified by the DAO.

For most chains, the fees would be paid to a smart contract which would split up the fee revenue as specified by chain governance. Most likely this would mean the largest share of priority fee revenue would go to the chain owner (e.g., the DAO) with perhaps a small slice going to the sequencer operator(s).

I gave a more detailed talk about this design and why I think it makes sense, at the Stanford MEV Workshop. Video is available here.

(One obvious design alternative is to not introduce a new transaction type, and just use the existing transaction type, which already has a priority fee field. The alternative would involve collecting the priority fee for existing transactions, which would be a change from the current policy of ignoring the priority fee field and treating all transactions as if they submitted a priority fee of zero.

The drawback of this alternative is many current transactions include a priority fee, typically a few gwei, because that is the default in some wallets–so that collecting the priority fee would cause many users to inadvertently pay much more for gas (adding, say, a 2 gwei tip on top of the 0.1 gwei base fee, a 21x increase in fee). By creating a new transaction type, and continuing to treat all legacy transaction types as having priority fee zero, we would protect users from this issue.)

7 Likes
2

Thanks Ed for the detailed write up, but I can’t help but wonder what will happen to fees. L2s are supposed to be cheap, how does this

  • Affect Gas price inflation: surely during peak times it will be very costly to do a simple transaction?
  • This causes an inequality as users who can’t afford to pay simply have to wait and continue trying, favouring users who have the gas to burn?
  • deterministic rule tie breaking - doesn’t this incentivise bad actors to try and manipulate this?
  • front running is still possible no, you just pay the highest fee and probabilistically determine how high you will be up (probabilistic ordering is being talked about now in the dark circles)

Have you looked into potentially adding in threshold security that encrypts transaction at submission, only to be decrypted by a decentralised committee after the consensus layer, should prevent people from exploiting pending txs. From [2205.08529] F3B: A Low-Overhead Blockchain Architecture with Per-Transaction Front-Running Protection

Thanks

3

Thanks for your questions and suggestion on threshold decryption.

Importantly, the bidders in timeboost are not contending for inclusions–every transaction that arrives by the deadline will be included in the block. They are only contending for ordering within the block. Unlike Ethereum, Arbitrum does not have an in-protocol limit on the number of txs that can run in some period of time. (The only real limit is the rate at which the sequencer can handle incoming RPCs, which is the same in the currrent system.)

Also, this design maintains the “secret mempool” feature of Arbitrum sequencing, so it will not be possible for external parties to see transactions and then outbid them. If a transaction arrives before some block’s deadline, it will be included in that block, and the block contents won’t be published until after the deadline–so by the time a transaction becomes visible to anyone (other than the sequencer itself), it will be too late to front-run it.

I would expect ordinary user txs to bid zero, because they will still be guaranteed mempool secrecy and prompt inclusion even with a zero bid. So I don’t think this will affect the gas fees paid by ordinary transactions.

With that background, here are answers to your questions:

  • I don’t expect this to affect gas fees for ordinary user transactions. I expect them to bid zero and get prompt inclusion just as they do now. It’s true that MEV extractors will pay more, but that’s part of the point of Timeboost, to internalize the value that MEV extractors are currently spending on technical “racing” outside of the protocol.
  • Users shouldn’t have to wait and re-try, because inclusion is guaranteed for all arriving transactions.
  • I’m not too worried about parties trying to game the deterministic tie-breaking, because any gaming can be defeated by a competitor who bids just one wei more.
  • The protocol is designed to prevent anyone (other than the sequencer itself) from being able to see a transaction and then insert another transaction in front of it. This is because of the secret mempool. (Your question suggests a kind of “blind front-running” where someone guesses that a particular transaction will be sent and submits a transaction before it, in the hope that the guess was correct. I don’t think any sequencing protocol can prevent that.)

My current proposal is a modification to the existing centralized, trusted sequencer. So this would still require parties to trust that the sequencer itself is not engaging in front-running tactics. Offchain Labs recently announced a partnership with Espresso Systems to develop a decentralized version of Timeboost. Threshold decryption is definitely part of that discussion.

In principle one could add threshold decryption to the centralized version, but it would include a decentralized committee (to do the decryption), and to me it makes sense to work on a more comprehensively decentralized approach.

Again, thanks for asking the hard questions. I hope my answers have added clarity to the proposal.

2 Likes
4

Pleased to observe that an L2 is taking MEV/ordering policy into account. I have a couple of questions:

Wasn’t PGA something that was aimed to be avoided from the pre-PBS days on Ethereum? Doesn’t it introduce wasted computations?

Have you considered a model where, over a year, sequencer operators are compensated with inflationary $ARB rewards for managing the sequencer? Concurrently, a substantial part of the sequencer’s revenues could be allocated for the burning of $ARB. This might result in the token experiencing net deflation by year-end. If we operate under the presumption of a steady market cap, it’s conceivable that the $ARB price would increase. This could be a possible strategy for the DAO, couldn’t it?

Do you have any insights regarding the latency of this decentralized version of Timeboost? I assume maintaining low latency is critical from a user perspective.

5

The problems with PGA on Ethereum happened because of the combination of PGA with a public mempool. Users would see other transactions in the mempool and change their behavior as a result. The Timeboost proposal would have a secret mempool, so these problems shouldn’t come up.

On your second question, of course the DAO can consider other models for paying the sequencer. There are some incentive alignment reasons to correlate sequencer payment with Timeboost revenue, but ultimately this is the DAO’s decision.

We’re still investigating the latency implications of decentralized Timeboost. That’s part of the research collaboration between Offchain Labs and Espresso Systems. I agree that latency is a very important consideration.