How can Solana improve to achieve the vision of an on-chain Nasdaq?

Original Title: “The Path to Decentralized Nasdaq”

Authors: Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)

Compiled by: GaryMa Wu Says Blockchain

Solana aims to create a decentralized trading network that is more efficient than Nasdaq, but the existing blockchain design has not met expectations. Currently, Solana's market makers have a low win rate in the order cancellation race (far below the 13% of centralized exchanges). The Jito auction exacerbates the control of a single leader over state access, leading to wider spreads. In response, it proposes a reconstruction of the consensus mechanism, introducing 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 blockchain that is fast enough and cheap enough to run a usable central limit order book. The Solana mainnet beta launched in March 2020 — five years have passed, and although we have achieved a lot, it has become increasingly clear that we have not yet realized this goal.

The existing blockchain infrastructure is not designed for trading. If we want to achieve Solana's original mission, we must return to the basics and completely redesign the consensus mechanism to ultimately build a decentralized network capable of competing with the New York Stock Exchange.

When we say competing with the New York Stock Exchange, we mean that exchanges on Solana need to provide better prices than centralized exchanges. In the market world, price is defined by the "spread": the difference between the highest price someone is willing to pay for an asset and the lowest price someone is willing to sell it for.

The smaller the spread, the better the price traders receive, and the higher the market 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 incurred from trading with informed traders. When market makers have more information than their counterparts, they make money; when they have less information, they lose money. Market makers typically make a little money on each trade with retail investors, but during sharp price movements (which we hope are infrequent), they can lose a lot if caught on the wrong side. This is where the saying "market makers pick up sesame seeds and lose watermelons" comes from.

What Determines Adverse Selection Costs?

To better understand adverse selection, we need to understand what game 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 because the counterpart cannot profit by taking that quote. However, once the fair price exceeds the bid-ask spread, a race begins: market makers will try to cancel their orders as quickly as possible, while the counterpart (taker) tries to grab the outdated order before the market maker cancels it. A successful taker expects to earn the difference between the fair price and the outdated 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 movements, market makers only have a 13% chance of canceling their orders first.

Centralized exchange market makers have a low probability of winning the cancellation race, but it is even lower on Solana. The Jito auction mechanism — a side effect caused by 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, the real determinant of victory is who bids higher in the Jito auction. This puts market makers in a dilemma: either spend a lot to cancel orders or let others outbid them. In either case, they are losing 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 give applications greater flexibility in order sorting. If we want to reduce the spread, applications must be able to give market makers a head start in the cancellation race. One way to do this is to introduce a "cancel first, then fill" sorting strategy. We look at the blocks and process all cancel transactions before processing all fill transactions (takes).

We can implement this strategy on Solana immediately by changing the current replay sorting from a leader-determined model to a strategy that prioritizes cancels. However, this does not completely solve the problem. If a single leader still controls the process, they can choose to ignore cancel transactions, and we are back to square one — market makers remain 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 cancel transactions, you can submit to another leader.

Implementation — Order Sorting

Regarding multiple Concurrent Leaders, the biggest question is: how do we merge each leader's 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, while the ordering fee is paid to the protocol (burned). When we need to merge the blocks from each leader, we simply take the union of all transactions from all blocks in a slot and execute them in order of 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 sorting. Adding another element: the get_transaction_metadata system call, which allows programs to read the ordering fees of transactions they interact with, thus providing applications with a powerful sorting control tool.

Implementation — Consensus Mechanism

Our design goals for the consensus mechanism include:

1. Binding & Blinding: Concurrent leaders cannot include information from other leaders' blocks in their own blocks (e.g., front-running private transactions), nor can they cancel their own blocks based on the contents of other leaders' blocks (e.g., canceling their bids after seeing other bids).

2. Wallclock Fairness: Concurrent leaders must submit blocks in roughly the same real-time.

Here is a summary of the most effective solution developed in collaboration with Pranav Garimidi and Joachim Neu from a16z Research:

1. Each leader converts their block into erasure-coded shards. Once enough shards (above the coding rate) are recovered, the block can be restored. Partial recovery is not possible.

2. Leaders send shards to the first layer of relay nodes in the Turbine tree. Each leader sends their first shard to relay 1, the second shard to relay 2, and so on. If all goes well, each relay will receive shards from all leaders.

3. After a timeout, the relay sends a signed IHAVE message to a single consensus leader, informing them of the shards 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 then begin to reach consensus on this block.

This solution satisfies the binding and blinding properties with high probability and has good wallclock fairness, although better solutions may emerge in the future.

Conclusion

The goal of Solana's creation is to surpass Nasdaq. To achieve this, we must provide better prices than Nasdaq. To do this, we must empower applications with the ability to prioritize cancellation operations before fills. To empower applications with this ability, we must prevent leaders from unilaterally censoring orders. And to do this, we must introduce multiple parallel leaders.