Sequencer
Last updated
Last updated
A sequencer has four main responsibilities, namely to:
Order transactions.
Execute transactions.
Filter transactions (i.e. prevent spam making its way to the L1).
Group transactions into larger batches, and write them to the DA layer.
The Bullet runtime executes transactions as native Rust code (i.e. without any sort of virtual machine) which frees it from the strict CU budgets, block sizes and stack limits one might experience in EVM and SVM programming environments. This allows Bullet to achieve best in class performance and make no compromises. Whilst this does come at the cost of some out-of-the-box compatibility with existing Solana smart contracts and tooling, we aim to address this by deploying an SVM module later in our roadmap to enable Solana builders to deploy their existing programs on Bullet.
Bullet's transaction processing model has been engineered from the ground up to process transactions in real-time as "streams". In comparison to traditional blockchains, which process transactions in discrete "blocks" (i.e. every 400ms on Solana), Bullet can execute transactions continuously as soon as they are received. This is fundamentally important in creating web2 like product interactions, where actions feel snappy and instantaneous. Likewise it is important for trading experiences as markets are highly event driven and change in real time.
In addition to processing transactions as they arrive, Bullet issues extremely fast 2ms 'soft confirmations' (also called pre-confirmations, as popularized by Justin Drake). These are the secret sauce behind what makes trading on Bullet feel as fast (or in fact faster) than a centralized exchange like Binance.
These soft confirmations are issued immediately after the sequencer executes an incoming user transaction, informing them of the transaction's success and, optionally, any resulting state changes (e.g., the new state of the orderbook post-trade).
Although these soft confirmations are not the finalized state, the chances of invalidation are extremely rare in practice, barring a liveness failure of K slots in the DA layer (where K represents the maximum allowed slot 'lag' between the actual slot number and the slot number observed by the preferred sequencer when building its current bundle). Thankfully, Solana has not experienced a serious liveness failure in over a year (in Toly and Anza we trust).
To improve the overall market microstructure and reduce toxic MEV on DeFi platforms built on Bullet, we adopt the concept of application specific sequencing. In essence, this means Bullet's sequencer can contain pre-determined ordering rules for incoming transactions, something that is difficult to achieve on general purpose rollups.
To frame this as a concrete example, Bullet's sequencer makes liquidity provisioning on orderbooks much more sustainable and accessible. By prioritising maker orders and order-types such as PostOnly (which cannot take by definition), we can encourage deep liquidity without the risk of severe adverse selection. This moves us away from a typical HFT front-running race and typical CEX-DEX arbitrage, to one where two-sided markets can be made sustainably.
Bullet uses the underlying Solana network for consensus, however it should be noted that Solana nodes don't inherently understand the transaction validity rules of the rollup. As the base layer for the rollup, Solana can be thought of as a "lazy ledger" of sorts (to quote @musalbas). Not knowing the rules of the rollup, it can't enforce them, and hence we have be prepared for the situation in which this ledger is dirty.
This is where the sequencer comes into play, which executes transactions and performs the validity checks before sending to the Solana leader. Each sequencer locks up a certain amount of stake to register itself, hence if it's found to have posted invalid batches to the DA layer, it is slashed and de-registered.
These are the first checks we perform, and are mostly concerned with checking the validity of each transaction's signatures (like Solana's sigverify stage).
These are more complicated and check for things like whether the transaction is a duplicate, whether the account has enough gas to cover the transaction.
Transactions that have been executed and passed validation checks can then be grouped into batches, and send to the L1 proposer (the current Solana leader). It is worth noting that the sequencer processes and issues soft confirmations in a streaming manner, but later batches the transactions in the background to be written to DA. This allows the end user experience to be lightning quick, whilst still ensuring that blocks are packed efficiently and write costs to DA are amortized (i.e. a single 1kB Solana transaction can hold 5 Bullet transactions).
Since the design goal of Bullet is to inherit the security of the underlying blockchain (Solana), it is paramount that even though users should primarily interact with the rollup, they should always able to fall back on the censorship resistance of the L1. Hence if a user detects that the sequencer is censoring them, they can submit a "forced transaction" directly to the L1 inbox, which we ensure is always processed within a reasonable number of slots K.
Furthermore, sequencers undoubtedly wield a lot of power, and with great power comes great responsibility. Therefore to ameliorate the concerns of sequencer centralization, we allow anyone to register a sequencer by depositing a bond into the sequencer - a radical departure from existing rollups that rely on a single trusted sequencer. Secondly, similar to the above, we allow new sequencers to register directly via transactions sent to the L1. Lastly, we will also have sequencer slashing as outlined above.
