Solana aims to create a decentralized trading network that is more efficient than Nasdaq, but existing blockchain designs have not met expectations. Current Solana market makers have a low win rate in the order cancellation race (far below the centralized exchange's 13%), and the Jito auction exacerbates the single leader's control over state access, leading to wider spreads. In response, it proposes a reconstruction of the consensus mechanism, introducing multiple concurrent leaders to optimize order sorting, reduce market makers' adverse selection costs, and improve price efficiency.
The original goal of Solana was to build a sufficiently fast and cheap blockchain to run a usable central limit order book. The Solana mainnet beta launched in March 2020 — it has been five years since, and while we have achieved quite a bit, it is increasingly clear that we have not yet realized this goal.
The existing blockchain infrastructure is not designed for transactions. If we want to achieve Solana's original mission, we must return to the starting point, fundamentally redesign the consensus mechanism based on the most basic principles, and ultimately build a decentralized network capable of competing with the New York Stock Exchange.
When we say we compete with the New York Stock Exchange, we mean that exchanges on Solana need to provide better prices than centralized exchanges. In the market world, prices are defined by the 'spread': the difference between the highest price someone is willing to buy an asset and the lowest price someone is willing to sell it.
The smaller the spread, the better the price traders receive, and the higher the market's efficiency.
The formula for the spread is simple. The spread is set such that the expected profit a market maker gains from trading with non-informed traders equals the expected loss they incur from trading with informed traders. When market makers have more information than their counterparties, they earn money; when they have less information, they lose money. Market makers usually make a little money on each trade with retail investors, but during price swings (which we hope are infrequent), if caught on the wrong side, they can lose a lot. This is the origin of the saying 'market makers pick sesame seeds and lose watermelons.'
To better understand adverse selection, we need to understand what game the market makers are playing. Market makers make judgments based on a 'fair price' that changes randomly over time. When the fair price is within the bid-ask spread, the market maker's quote is safe, as the counterparty cannot profit by taking that quote. However, once the fair price exceeds the bid-ask spread, a race begins: the market maker will try to cancel the order as quickly as possible, while the counterparty (taker) will try to seize that stale order before the market maker cancels it. A successful taker expects to earn the difference between the fair price and the stale quote. The key to reducing adverse selection friction is to allow market makers to win this race as much as possible.
Data from a centralized exchange indicates that after price swings, market makers have only a 13% chance of canceling orders ahead of time.
Market makers on centralized exchanges have a low probability of winning the cancellation race, but it is even lower on Solana. The Jito auction mechanism — a side effect of a single proposer controlling state access over a long period — makes it nearly impossible for market makers to win the cancellation race. Even if market makers are faster, what truly determines the outcome is who bids higher in the Jito auction. This puts market makers in a dilemma: either spend a lot of money to cancel orders or let others bid higher to snipe them. Either way, they lose money and thus have to widen the spread.
In practice, the current on-chain market microstructure gives takers an advantage in adverse selection. To solve this problem, we need to provide applications with greater flexibility in transaction ordering. If we want to reduce the spread, applications must be able to give market makers the upper hand in the cancellation race. One approach is to introduce a 'cancel before fill' ordering strategy. We look at the blocks and process all cancellation transactions before processing all fill transactions.
We can immediately implement this strategy on Solana by changing the current replay ordering from a leader-determined model to a strategy that prioritizes cancellations. However, this does not fundamentally solve the problem. If a single leader still controls the process, they can still choose to ignore cancellation transactions, and we are back to square one — market makers still find themselves at a disadvantage in the cancellation race.
The only way to solve this problem is to introduce multiple concurrent leaders. This way, if one leader blocks cancellation transactions, you can turn to submit to another leader.
Regarding multiple parallel leaders, the biggest question everyone has is: how do we merge our transaction blocks when conflicts arise? The answer is quite simple: we divide fees into two categories: inclusion fee and ordering fee. The inclusion fee is paid to the validator that includes the transaction, and the ordering fee is paid to the protocol (destroyed). When we want to merge the blocks of each leader, we simply take the union of all transactions from all blocks in a given slot and execute them sorted by their ordering fees.
This measure alone is not enough. What we really want to achieve is to allow applications to have more flexible control over transaction ordering. Adding one more element: the `get_transaction_metadata` system call, which allows programs to read the ordering fees of the transactions they interact with, thus providing applications with a powerful tool for ordering control.
Our consensus mechanism design goals include:
1. Binding & Blinding: Parallel leaders cannot include information from other leaders' blocks in their own blocks (such as private transaction sandwiching), nor can they cancel their own blocks based on the contents of other leaders' blocks (for example, cancel their own bids after seeing others' bids).
2. Clock fairness: parallel leaders must submit blocks within roughly the same real time.
Below is a summary of the most effective scheme we developed in collaboration with Pranav Garimidi and Joachim Neu from a16z Research:
1. Each leader converts their block into erasure code shreds. Once a sufficient number of shreds (above the coding rate) are recovered, the block can be restored. Partial recovery is not possible.
2. The leader sends shreds to the first layer relay nodes of the Turbine tree. Each leader sends their first shred to Relay 1, the second shred to Relay 2, and so on. If everything goes smoothly, each relay will receive shreds from all leaders.
3. After timeout, the relay sends a signed IHAVE message to a single consensus leader, informing them of the shreds received.
4. The consensus leader then constructs a block containing these IHAVE messages; if it does not include a sufficient proportion of IHAVE messages, the block will be invalid.
5. The consensus leader broadcasts the block to validators, who begin to reach consensus on this block.
This scheme satisfies binding and blinding properties with high probability and has good clock fairness, although better schemes may emerge in the future.
The goal of creating Solana is to surpass Nasdaq. To do this, we must provide better prices than Nasdaq. To achieve this, we must empower applications with the ability to prioritize cancellation operations before transactions are completed. To empower applications with this ability, we must prevent leaders from unilaterally censoring orders. To do this, we must introduce multiple parallel leaders.
