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

To achieve this, we must offer better prices than Nasdaq and empower the application with the ability to prioritize cancellation operations before execution.

**Written by:**Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)

Compiled by: GaryMa Wu says blockchain

Summary

Solana aims to create a decentralized trading network that is more efficient than Nasdaq, but the current blockchain design has not met expectations. Currently, Solana market makers have a low win rate in the order cancellation race (far below the 13% of centralized exchanges). Jito auctions exacerbate the control of a single leader over state access, leading to wider spreads. In response, it proposes to restructure the consensus mechanism by introducing Concurrent Leaders to optimize order sorting, reduce the adverse selection costs for market makers, and enhance price efficiency.

The initial goal of Solana was to build a blockchain that is fast enough and cheap enough to run a usable centralized limit order book on it. The Solana mainnet beta launched in March 2020 — it has been five years now, 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 go back to the basics, starting from the fundamental principles, and completely redesign the consensus mechanism to ultimately build a decentralized network capable of competing with the New York Stock Exchange.

What we mean by competing with the New York Stock Exchange is that exchanges on Solana need to be able to offer better prices than centralized exchanges. In the world of markets, 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 an asset for.

The smaller the price difference, the better the price obtained by traders, and the higher the efficiency of the market.

The formula for the spread is simple. Spreads are set in such a way that the expected profit that a market maker will receive from trading with a non-information trader is equal to the expected loss they would incur from trading with an information trader. When market makers have more information than their counterparties, they make money; When there is less information than the counterparty, they lose money. Market makers usually make a little money on each trade with retail investors, but lose a lot if they are hedged in the opposite direction when the price jumps violently (hopefully infrequently). This is the origin of the phrase “the market maker picks up the gate and loses the watermelon”.

What determines the cost of adverse selection?

To better understand adverse selection, we need to understand what game market makers are playing. Market makers make decisions 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 counterparty cannot make a profit by eating the quote. But as soon as the fair price exceeds the bid-ask spread, a race begins: the market maker tries to cancel the order as quickly as possible, and the taker tries to grab the outdated order before the market maker cancels. The expectation of a successful taker is the difference between the fair price and the outdated offer. The key to reducing the friction of adverse selection is to allow market makers to win the race as much as possible.

Data from a certain centralized exchange indicates that after price fluctuations, market makers only have a 13% probability of being able to cancel orders ahead of others.

Market makers on centralized exchanges are less likely to win in the cancellation race, but even lower on Solana. The Jito auction mechanism – which is a side effect of a single proposer controlling state access over an extended period of time – makes it nearly impossible for market makers to win the cancellation race. Even if the market maker is faster, the real decision is who bids higher in the Jito auction. This puts market makers in a dilemma: they can either pay a lot of money to cancel their orders, or let someone else pay a high price to snipe them. Either way, they were losing money and had to widen the spread as a result.

In practice, the current on-chain market microstructure gives takers a first-mover advantage in terms of adverse selection. To address this issue, we need to provide applications with greater flexibility in trade ordering. If we want to reduce the spread, the application must be able to give market makers the upper hand in the race to cancel orders. One way to do this is to introduce a “cancel first, then execute” ordering strategy. We examine the blocks and process all cancel transactions before processing all executed transactions (takes).

We can implement this strategy on Solana immediately, simply by changing the current replay ordering from a leader-determined model to one that prioritizes canceled transactions. However, this does not completely solve the problem. If a single leader still controls the process, they can choose to ignore canceled transactions, and we would be back to square one — market makers would still be at a disadvantage in the race to cancel.

The only way to solve this problem is to introduce Concurrent Leaders. This way, if one leader blocks a cancellation transaction, you can turn to submit it to another leader.

Implementation - Transaction Ordering

The biggest question about the multiple parallel leaders is: How do we merge their respective transaction blocks when there is a conflict? The answer is simple: we divide fees into two categories: inclusion fees and ordering fees. The inclusion fee is paid to the validator who contains the transaction, and the sorting fee is paid to the protocol (burn). When we want to merge the blocks of each leader, we simply take the union of all transactions for all blocks in a slot and order them according to their sorting 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. Another element is the get\_transaction\_metadata system call, which allows programs to read the sorting fees of the transactions they interact with, thus providing applications with a powerful tool for sorting control.

Implementation - Consensus Mechanism

Our consensus mechanism design goals include:

1. Binding & Blinding: Parallel leaders cannot include information from other leaders’ blocks (such as colluding private transactions) in their own blocks, nor can they cancel their own blocks based on the content of other leaders’ blocks (for example, canceling their own bid after seeing other bids).

2. Wallclock Fairness: Parallel leaders must submit blocks within approximately the same real time.

The following is an overview of the most effective solutions developed in collaboration with Pranav Garimidi and Joachim Neu from a16z Research:

1. Each leader will convert their block into erasure coded shards (shreds). Once a sufficient number of shards (above the coding rate) is recovered, the block can be restored. Partial recovery is not possible.

2. The leaders send the shards to the relay nodes at the first layer of the Turbine tree. Each leader sends its 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 the timeout, the relay sends a signed IHAVE message to a single consensus leader, informing them of the fragments received.

4. The consensus leader then constructs a block containing these IHAVE messages; if a sufficient proportion of IHAVE messages are not included, the block will be invalid.

5. The consensus leader broadcasts the block to the validators, who begin to reach consensus on this block.

This scheme satisfies the binding and blinding properties with high probability, and has good clock fairness, although better schemes may emerge in the future.

Conclusion

The goal of creating Solana is to surpass Nasdaq. To achieve this, we must provide better prices than Nasdaq. To do this, we need to empower applications with the ability to prioritize cancellation operations before a transaction. To give applications this ability, we must prevent leaders from unilaterally reviewing orders. And to achieve this, we must introduce multiple parallel leaders.