Troubleshoot Timeboost
This is a short guide on how response times work and how express lane transactions are sequenced, alongside common errors and best practices for using Timeboost. This guide assumes you have reviewed our guide on How to use Timeboost.
How express lane transactions are ordered into blocks
The express lane time advantage is currently set to 200ms, while the current block creation time is 250ms. Both express lane transactions and regular transactions are processed together in a single queue after taking into account the timeboost time advantage and artificial delay. This means that if an express lane transaction and a normal transaction both arrive at the sequencer at the same time, but before 50ms have passed since the last block was produced, then both transactions may appear in the same block, though the express lane transaction would be sequenced ahead of the normal transaction (assuming that the block's gas limit has not yet been reached).
Express lane transactions are processed in the order of their sequenceNumber, which is a field in every express lane transaction. The sequenceNumber field is important because transactions with sequenceNumber = n can only be sequenced after all the transactions from sequenceNumber = 0 to sequenceNumber = n-1 have been sequenced. The first expected sequence number for a new round is zero and increments for each accepted transaction.
There is a special "dontcare" sequence number (2^64 - 1) that can be used to indicate that you don't care about ordering of this express lane submission relative to others. Transactions with the "dontcare" sequence number will be sequenced right away without waiting for any other transactions. Note that normal nonce ordering within transactions for an account is still respected, so transactions from the same account will still be ordered by their nonce regardless of sequence number. The express lane controller can send ExpressLaneSubmissions with both "dontcare" and normal sequence numbers within the same round.
How response times work
The response for a transaction submission to the express lane is returned immediately once received by the sequencer. For example, if an express lane transaction is sent to the sequencer at t=0ms and it took 50ms to arrive at the sequencer (defined as time_to_arrive), then the expected response time is at t=50ms. Note that an accepted transaction is defined as an express lane transaction submission where the sequencer returns an empty result with an HTTP status of 200 and will always have their sequenceNumber consumed. You can read more about how to submit express lane transactions in: How to submit transactions to the express lane.
Errors relating to the sequenceNumber
When it comes to submitting express lane transactions, there are a few scenarios to consider. Note that if your use case doesn't require an ordering between ExpressLaneSubmissions beyond the usual per account nonce ordering, then you can use the "dontcare" sequence number described above.
Scenario 1: You get an error response immediately
In this scenario, an error response is immediately returned after you send an express lane transaction. In most cases the transaction's sequenceNumber will not be consumed if the error is Timeboost-related or if the transaction was invalid (e.g., nonce too low, malformed transaction). If the error contains "Error queuing expressLane transaction" you need to re-submit your transaction with the same sequence number after rectifying any errors, or submit a different transaction with that sequence number. See Common Timeboost error responses below for a full list of Timeboost-related error responses and how to interpret them.
Scenario 2: Your transaction got an empty response with an HTTP status of 200
In this scenario, a null response is immediately returned after you send an express lane transaction. This means that your transaction's sequenceNumber was consumed and your transaction was accepted. However, this does not mean that your transaction was sequenced into a block due to a block-based timeout explained below. We recommend checking transaction receipts for confirmation on whether your transactions were sequenced into a block or not.
The block-based timeout for express lane transactions
If the express lane controller decides to send a burst of transactions to the express lane with ascending values for the sequenceNumber, then the sequencer will attempt to process them in the order defined by the sequenceNumber (as explained above). However, if the transactions arrive out-of-order at the sequencer, then the transactions that do not have the expected sequenceNumber will be buffered (up to a limit) to be processed until the sequencer receives the transaction with the expected sequenceNumber. Once the sequencer receives the transaction with the expected sequenceNumber, then the sequencer will begin processing the buffered transaction with the next sequenceNumber. In other words, a transaction will only be sequenced into a block once transactions with the other, missing sequence numbers arrive to fill in the “gap” between the expected sequencerNumber and a given transaction’s sequenceNumber.
A block-based timeout is applied to all express lane transactions, even those in the buffer, such that any transactions accepted (meaning sequenceNumber is consumed) by the sequencer will be dropped if they are not sequenced into a block within 5 blocks. This timeout can occur if the cummulative gas usage of transactions (express lane or otherwise) fill up 5 blocks worth of transactions before all of the buffered express lane transactions are sequenced. No timeout error will be returned in this case and we recommend checking transaction receipts for confirmation on whether your transactions were sequenced into a block or not. Note that each Arbitrum block has a gas limit of 32 million gas and 1 Arbitrum block is produced every 250ms. This block-based timeout is likely to be reached before the limit on buffered transactions is hit in almost all cases.
Common error responses
The below two tables can also be found on our guide on How to use Timeboost.
Table 1: Errors relating to bid submission
| Error | Description |
|---|---|
MALFORMED_DATA | wrong input data, failed to deserialize, missing certain fields, etc. |
NOT_DEPOSITOR | the address is not an active depositor in the auction contract |
WRONG_CHAIN_ID | wrong chain id for the target chain |
WRONG_SIGNATURE | signature failed to verify |
BAD_ROUND_NUMBER | incorrect round, such as one from the past |
RESERVE_PRICE_NOT_MET | bid amount does not meet the minimum required reserve price on-chain |
INSUFFICIENT_BALANCE | the bid amount specified in the request is higher than the deposit balance of the depositor in the contract |
Table 2: Errors relating to express lane transaction submission
Note that if you get any of the errors below or errors related to invalidity of the transaction (e.g., nonce too low, malformed transaction), then the sequence number used in your express lane transaction was not consumed.
| Error | Description |
|---|---|
MALFORMED_DATA | wrong input data, failed to deserialize, missing certain fields, etc. |
WRONG_CHAIN_ID | wrong chain id for the target chain |
WRONG_SIGNATURE | signature failed to verify |
BAD_ROUND_NUMBER | incorrect round, such as one from the past |
NOT_EXPRESS_LANE_CONTROLLER | the sender is not the express lane controller |
NO_ONCHAIN_CONTROLLER | there is no defined, on-chain express lane controller for the round |
SEQUENCE_NUMBER_ALREADY_SEEN | the sequence number used for the given transaction was already consumed, try resubmitting with a new sequence number |
SEQUENCE_NUMBER_TOO_LOW | the sequencer number used for the given transaction is numerically lower than the expeected sequence number, try resubmitting with the expected sequence number |
sequence number has reached max allowed limit | the limit on the number of buffered express lane transactions was reached |
Notes on Timeboost's implementation for Arbitrum One & Arbitrum Nova
Although the auctioneer will function autonomously, please note that the ArbitrumDAO (formal owners of Arbitrum One and Arbitrum Nova) has granted the sequencer operator with:
- The right to pause the acceptance and verification of bids. This is to allow the current sequencer operator to provide reliable, consistent UX and maximize infrastructure stability, and
- The right to disable Timeboost entirely in the event of a security risk or otherwise malicious attempt to harm Arbitrum One and Arbitrum Nova node operators, existing deployed applications, and/or end users. The Arbitrum Foundation and Offchain Labs commits to sharing publicly post-mortems and analyses should this scenario arise.
These rights, among a few others as described in the original AIP, are expected to only be exercised in circumstances where doing so would enhance Timeboost’s long-term stability, preserve or improve the user experience for those using Timeboost-enabled Arbitrum chains, increase the security posture, resiliency, or stability of the chain, and/or otherwise help increase revenue for the ArbitrumDAO.
It is important to emphasize that for Arbitrum One and Arbitrum Nova, the DAO-elected Arbitrum Security Council can, at any time, perform either Emergency Actions or Non-Emergency Actions to execute software upgrades, perform routine maintenance, and other parameter adjustments to Timeboost, in each case in accordance with its existing powers. These actions can include, but are not limited solely to, exercising the rights proposed above for the current sequencer operator. More information about the Arbitrum Security Council and their scope of powers can be found in the ArbitrumDAO Constitution.