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

Original title:"The Path to Decentralized Nasdaq"

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

Compiled by : GaryMa Wu said blockchain

Solana aims to build a decentralized trading network that is more efficient than Nasdaq, but the existing blockchain design is not up to expectations, and the current Solana market makers have a low winning rate in the cancellation contest (well below 13% of centralized exchanges), and Jito auctions intensify single leaders ' control over state access, resulting in widening spreads. In this regard, it proposed to reconstruct the consensus mechanism and introduce multiple parallel leaders to optimize order sorting, reduce the reverse selection cost of market makers, and improve price efficiency.

Solana’s initial goal was to build a blockchain that was fast enough and cheap enough to run an available central limit order book on it. The Solana mainnet beta was launched in March 2020 — five years have passed now, and despite our achievements, it is becoming increasingly obvious that we have not achieved this goal.

The existing blockchain infrastructure is not designed for transactions. If we want to achieve Solana's initial mission, we must return to the starting point, start from the most basic principles, completely redesign the consensus mechanism, and ultimately build a decentralized network with the ability to compete with the New York Stock Exchange.

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

The smaller the spread, the better the price the trader gets and the higher the efficiency of the market.

The formula for price spread is simple. The spread is set like this: the expected gains market makers receive from trading with non-information traders equal to the expected losses they generate when they exchange with information traders. When market makers have more information than their opponents, they make money; when there is less information than their opponents, they lose money. Market makers usually make a little money every time they trade with retail investors, but when the price jumps violently (hopefully infrequently), if they are trapped in the opposite direction, they will lose a lot. This is the origin of the saying "market makers pick up sesame seeds and lose watermelons."

What determines the cost of reverse selection?

In order to better understand the reverse selection, we need to understand what game market makers are playing. The market maker makes judgments based on a "fair price" that changes randomly over time. When a 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 once the fair price exceeds the bid-ask spread, a race begins: the market maker tries to cancel the order as soon as possible, while the counterparty tries to grab the outdated order before the market maker cancels it. What you earn in a successful taker expects is the difference between a fair price and an outdated quote. The key to reducing reverse selection friction is to allow market makers to win in this race as much as possible.

Data from a centralized exchange shows that after the price fluctuates, market makers have only a 13% chance of canceling orders first.

Market makers on centralized exchanges have low probability of winning in cancelling races, but are even lower on Solana. Jito Auction Mechanism — It is a side effect caused by a single proposer controlling state access for a longer period of time — making it almost impossible for market makers to win cancelled races. Even if market makers are faster, it is who really decides the outcome that bids higher in Jito auctions. This puts market makers in a dilemma: either spend a lot of money to cancel orders or allow others to pay high prices to snipe them. Either way, they are losing money and therefore have to expand the spread.

In actual operation, the current on-chain market microstructure is equivalent to giving taker a first-mover advantage in reverse selection. To solve this problem, we need to give the application greater flexibility in ordering transactions. If we want to lower the spread, the application must be able to give market makers the first move in cancelling order racing. One way is to introduce a sorting strategy of "cancel first and then trade". We look at the blocks and process all cancels before processing all take transactions.

We can implement this strategy immediately on Solana, simply changing the current replay order from a leader-determined pattern to a policy that prioritizes cancellation. But this doesn't completely solve the problem. If it is still controlled by a single leader who still has the option to ignore cancellation, then we are back to the starting point - market makers are still at a disadvantage to cancelling the race.

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

Implementation — Transaction sorting

Regarding multiple parallel leaders, the biggest question is: How do we merge their respective transaction blocks when there is a conflict? The answer is actually very simple: we divide the fees into two categories: inclusion fees and ordering fees. The inclusion fee is paid to the verifier containing the transaction, and the sort fee is paid to the agreement (destroy). When we want to merge the blocks of each leader, we just need to unify all transactions of all blocks in a slot and sort them according to their ordering fees and execute them.

This measure alone is not enough. What we really want to achieve is to allow applications to control transaction sorting more flexibly. Add another element: get_transaction_metadata system call, which allows the program to read the sort fees for transactions with it, thus providing an application with a powerful sorting control tool.

Implementation — Consensus mechanism

Our consensus mechanism design objectives include:

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

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

Here is a summary of the most effective solutions we have developed in partnership with Pranav Garimidi and Joachim Neu of a16z Research:

1. Each leader converts its block into erasure code fragments (shreds). Once a sufficient number of fragments (above the encoding rate) are recovered, the blocks can be restored. Partial recovery is impossible.

2. The leader sends the fragments to the relay node in the first layer of the Turbine tree. Each leader sends its first piece to Relay 1, the second piece to Relay 2, and so on. If everything goes well, each relay receives fragments from all leaders.

3. After the timeout, the relay sends a signed IHAVE message to the single consensus leader, informing them of the fragments received.

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

5. The consensus leader broadcasts the block to the verifier, and the verifier begins to reach a consensus on the block.

This solution satisfies the binding and blinding attributes at high probability and has good clock fairness, although better solutions may appear in the future.

Conclusion

Solana’s goal is to go beyond the Nasdaq. To do this, we have to offer better prices than the Nasdaq. To do this, we must give the application the ability to prioritize cancellation operations before closing. To empower this capability, we must prevent leaders from unilaterally reviewing orders. And to do this, we have to introduce multiple parallel leaders.