Solana is already fast enough, and the transaction volume is large enough. But is it really "enough"?

When we examine those transactions, one question persists: Are these transactions really creating value?

The large number of transactions on Solana does not stem from genuine trading demand, but rather from high-frequency arbitrageurs exploiting millisecond information gaps to make profits. These "toxic traders" take advantage of their technical edge by increasing Gas fees just as market makers are about to cancel their orders, allowing their transactions to be packed first, completing the arbitrage and causing losses for the market makers. To compensate for these losses, market makers can only widen the bid-ask spread.

In the end, ordinary users bear the cost. Solana has always had a dream of implementing an order book on-chain to replace centralized exchanges (CEX). However, this makes "toxic traders" an obstacle to realizing that dream. This is the new challenge Solana faces: transaction volume ≠ liquidity. A truly healthy market does not require more transactions, but better transactions.

How can we eliminate toxic trades and better protect liquidity?

In the current system, takers enjoy actual priority due to Solana's periodic auction mechanism, which allows malicious MEV to affect market fairness.

How to understand this?

In Solana's current consensus, within each time slot, transactions are sorted by the Gas fees paid, with higher bids executed first. This auction is periodic, occurring every 400 milliseconds.

During this process, market makers need to frequently adjust their quotes, cancel orders, and re-list them. They must update immediately when market prices change.

Takers, especially high-frequency arbitrageurs, monitor price discrepancies and execute trades as soon as they spot an opportunity. Thus, arbitrageurs can pay higher fees to execute trades before orders are canceled, leading to market makers frequently being "sniped" and incurring losses.

For an order book DEX, the ideal order of execution should be to first execute all canceled orders, then execute new orders, and finally execute trades. This is something that Solana's consensus currently cannot achieve at a micro level.

The same applies to the oracle pricing layer; ideally, oracle prices should be updated first, followed by the execution of trades that depend on those prices. However, within the current 400-millisecond interval, market conditions may fluctuate dramatically, causing trades to still execute at the original price.

For lending protocols, it is best to first replenish collateral before proceeding with liquidation.

Therefore, it would be ideal to have a way for different protocols to sort transactions according to demand, which is what Solana has been emphasizing as ACE (Application-Controlled Execution).

BAM (Block Assembly Marketplace) is Solana's answer.

BAM builds a sorting layer, or preprocessing layer, between applications on the Solana chain and the mainnet.

Using Trusted Execution Environments (TEEs), it creates a privacy sandbox to sort transactions based on predetermined sorting rules, or FIFO (First In, First Out).

This better serves Central Limit Order Books (CLOBs), perpetual exchanges, and dark pool protocols.

Comparison of Solana's Normal Transaction Packaging and BAM Model

How to understand that BAM builds a sorting layer between Solana applications and the mainnet? Let's start with an intuitive comparison.

The normal transaction flow on Solana is as follows:

1) The user confirms the transaction in their wallet. 2) The transaction is sent to the RPC node. 3) The RPC sends it to the Leader node of the Solana mainnet for the current slot period. 4) The Leader collects transactions from the transaction pool, sorts them, packages them into a block, and broadcasts it. 5) The remaining nodes vote.

If an application connects to BAM, the transaction flow is as follows:

1) The user confirms the transaction in their wallet. 2) The transaction is sent to the RPC node. 3) The transaction is sent to the BAM network, where it is sorted in TEE privacy. During this process, nodes may add additional transactions through plugins, such as updating oracle prices, and then generate proofs. 4) The transaction data packet is submitted to the Solana mainnet Leader node. 5) When the Leader collects transactions, it collects the BAM data packet and packages it into a block for broadcasting. 6) The remaining nodes vote.

Thus, BAM does not conflict with the current Solana mainnet consensus process; rather, it serves as an "option." BAM does not run directly on the Solana mainnet but operates in a so-called "off-chain" manner, completing transaction sorting in advance, packaging transactions, and then submitting them to the Solana mainnet.

BAM Transaction Sorting Model

BAM supports three operational modes:

1) Solana default mode; 2) Block-Engine mode; currently Jito's MEV solution, which is centered around a bidding mechanism. 3) BAM mode, where validators strictly sort transactions according to FIFO.

The core of the BAM mode includes the following points:

1) Trusted Execution Environments (TEEs): Privacy and Fairness. Utilizing TEEs to create a privacy environment for transaction sorting. The other side of privacy is fairness. 2) Plugin System: Complex Sorting. Through the plugin system, BAM allows applications to build custom transaction sorting logic. This custom sorting is not arbitrary; it is based on pre-established rules.

The plugin plan aims to implement complex transaction sorting while maintaining the security guarantees of the TEE environment. It is currently in the early stages of development.

As mentioned earlier, for an order book DEX, the ideal sorting should be to execute all canceled orders first, then execute new orders, and finally execute trades as prices fluctuate. This is something that Solana's consensus currently cannot achieve at a micro level.

The same applies to the oracle pricing layer; ideally, oracle prices should be updated first, followed by the execution of trades that depend on those prices. However, within the current 400-millisecond interval, market conditions may fluctuate dramatically, causing trades to still execute at the original price.

For lending protocols, it is best to first replenish collateral before proceeding with liquidation. This effectively realizes the ACE application-controlled execution function.

So, what exactly has BAM achieved?

For example:

1) Lending Liquidation Protection. For lending protocols, upon detecting liquidation risk, prioritize executing collateral replenishment operations before proceeding with liquidation checks. 2) Atomic-Level Transaction Combinations. For DEX, first update oracle prices, then execute trades that depend on those prices. If it is a contract DEX, related derivatives can also be settled. All of the above operations are completed within the same time window. 3) Price Fluctuation Protection. For DEX, detect abnormally large orders, split them into smaller chunks, and execute them in batches, allowing the market time to react and avoiding a death spiral caused by cascading liquidations or arbitrage. 4) Market Maker Protection. In the event of sudden occurrences, cancel orders within milliseconds, update oracle prices, and re-list orders for market makers. This avoids malicious arbitrage and reduces the bid-ask spread.

BAM was originally set to launch at the end of July.

With the deployment of BAM, the trading experience on Solana will be significantly improved. BAM will make the experience of Solana mainnet applications closer to that of CEX.

In summary, BAM brings verifiability, privacy protection, and programmability to Solana's transaction processing flow, enabling developers to build Central Limit Order Books (CLOBs), perpetual exchanges, dark pools, and other financial infrastructures that require sorting control, deterministic execution, and privacy protection, thus promoting the innovative development of the Solana ecosystem.

That's all.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。