有害な取引を排除し、流動性をより適切に保護するにはどうすればよいでしょうか？

現在のシステムでは、Solanaコンセンサスの定期的なオークションメカニズムにより、テイカーが事実上の優先権を享受しており、悪意のあるMEVが市場の公平性を損なう可能性があります。

理解するには？

Solanaの現在のコンセンサスでは、各タイムスロットにおいて、取引は支払われた優先ガス料金によってランク付けされます。最高入札者の取引が最初に実行されます。このオークションは定期的に行われ、400ミリ秒ごとに1スロットが実行されます。

このプロセスの間、マーケットメーカーは頻繁に見積り価格を調整し、注文をキャンセルして再入力する必要があります。市場価格の変動は、即時の更新を必要とします。

テイカー、特に高頻度アービトラージを行うトレーダーは、価格の差異を監視し、機会があれば即座に取引を実行します。そのため、裁定取引を行う業者は、注文がキャンセルされる前に取引を執行するために、より高い手数料を支払うことができます。その結果、マーケットメーカーは頻繁に標的となり、損失を被ることになります。

オーダーブック型DEXの場合、理想的な順序は、まずキャンセルされた注文をすべて執行し、次に新規保留注文を執行し、最後に価格変動に合わせて取引を行うことです。しかし、これは現在、Solanaのマイクロレベルのコンセンサスでは不可能です。

オラクル価格レベルでも同様です。理想的には、まずオラクル価格を更新し、次にその価格に依存する取引を行うべきです。しかし、現在の400ミリ秒間隔では、市場の変動により、元の価格で取引が執行される可能性があります。

レンディングプロトコルの場合、まず証拠金を補充し、次に清算を行うのが最適です。

したがって、異なるプロトコルがそれぞれのニーズに基づいて取引の優先順位を決定できる手段が理想的です。これはSolanaが重視しているACE（アプリケーション制御実行）です。

BAM（ブロックアセンブリマーケットプレイス）こそがSolanaの答えです。

BAMは、Solanaオンチェーンアプリケーションとメインネットの間にソートレイヤー、つまり前処理レイヤーを構築します。

Trusted Execution Environments（TEE）を活用し、事前に定義されたソートルール、つまりFIFO（先入先出）に従ってトランザクションをソートするプライバシーサンドボックスを構築します。

これにより、オーダーブック（CLOB）、パーペチュアルスワップ、ダークプールのパフォーマンスが向上します。

Solanaの典型的なトランザクションバンドルとBAMのモデルの比較

BAMがSolanaアプリケーションとメインネットの間にソートレイヤーを作成する仕組みをどのように理解すればよいでしょうか？まずは視覚的な比較から始めましょう。

通常のSolanaトランザクションプロセス：

1) ユーザーはウォレットでトランザクションを確認します。

2) トランザクションはRPCノードに送信されます。

3) 現在のスロット中に、Solanaメインネット上のリーダーノードにRPCが送信されます。

4) リーダーはトランザクションプールからトランザクションを収集し、ソートしてブロックにパッケージ化し、ブロードキャストします。

5) 他のノードが投票します。

アプリケーションがBAMと統合されている場合、トランザクションプロセスは次のようになります。

1) ユーザーはウォレットでトランザクションを確認します。

2) トランザクションはRPCノードに送信されます。

3) トランザクションはBAMネットワークに転送され、TEE内でプライベートにソートされます。このプロセス中、ノードはプラグインを介してオラクル価格の更新などのトランザクションを追加し、プルーフを生成する場合があります。

4) トランザクションデータパケットは、Solanaメインネットのリーダーノードに送信されます。

5) リーダーはトランザクションを収集する際に、BAMデータパケットを収集し、ブロックにパッケージ化してブロードキャストします。

6) 残りのノードが投票します。

したがって、BAMは現在のSolanaメインネットのコンセンサスプロセスと実際には競合しません。むしろ、「オプション」機能として存在します。BAMはSolanaメインネット上で直接実行されるのではなく、「オフチェーン」で動作し、トランザクションを事前に順序付け、パッケージ化してからSolanaメインネットに送信します。

BAMトランザクション順序モード

BAMは3つの動作モードをサポートしています。

1) Solanaデフォルトモード。

2) ブロックエンジンモード。Jitoの現在のMEVソリューションは入札メカニズムを中心に構築されています。

3) BAMモデルでは、バリデータはFIFO順序に厳密に従います。

BAMモデルの核となる部分は次のとおりです。

1) Trusted Execution Environments (TEE): プライバシーと公平性。Trusted Execution Environments (TEE) を使用することで、トランザクションをソートするためのプライベート環境を構築します。プライバシーの裏返しは公平性です。

2) プラグインシステム: 複雑なソート。BAMはプラグインシステムを通じて、アプリケーションがカスタムのトランザクションソートロジックを構築できるようにします。このカスタムソートとは、ノードがトランザクションを任意の方法でソートできるという意味ではなく、事前に定義されたルールに従ってトランザクションがソートされるという意味です。

プラグインは、TEE環境のセキュリティを維持しながら、複雑なトランザクションソートを実装するように設計されています。現在、開発初期段階です。

前述の通り、

オーダーブック型DEXの場合、理想的な順序は、まずキャンセルされた注文をすべて執行し、次に新規保留注文を執行し、最後に価格変動に応じて取引を行うことです。これは現在、Solanaのマイクロレベルのコンセンサスでは不可能です。

オラクル価格レベルでも同様です。理想的には、まずオラクル価格を更新し、次にそれに依存する取引を行うべきです。しかし、現在の400ミリ秒間隔では、市場の変動により、取引が元の価格で執行される可能性があります。

レンディングプロトコルの場合、まず証拠金を補充し、次に清算を行うのが最適です。これは、ACEのアプリケーション制御実行機能を効果的に実装します。

では、BAM は具体的に何を実現するのでしょうか？

例えば、

1) レンディングと清算保護

レンディングプロトコルでは、清算リスクが検出されると、清算チェックよりも担保の補充が優先されます。

2) アトミックトレードコンビネーション

DEX では、まずオラクル価格が更新され、その後、その価格に依存する取引が実行されます。契約ベースの DEX では、関連するデリバティブの決済も可能です。これらの操作はすべて、同じ時間枠内で完了します。

3) 価格変動保護

DEX では、異常に大きな注文を検知し、それを小さな単位に分割して一括執行することで、市場に反応する時間を与え、連鎖清算や裁定取引によるデススパイラルを防止します。

4) マーケットメーカー保護

緊急事態が発生した場合、注文は数ミリ秒以内にキャンセルされ、オラクルが価格を更新し、マーケットメーカーが注文を再入力します。これにより、悪質な裁定取引が防止され、価格差が縮小されます。

BAMは当初、7月末のリリースが予定されていました。

さらに、BAMの導入により、Solanaの取引エクスペリエンスは大幅に向上します。BAMは、SolanaメインネットのアプリケーションエクスペリエンスをCEXに近づけます。

まとめると、

BAMは、Solanaのトランザクション処理に検証可能性、プライバシー、プログラマビリティをもたらし、開発者が中央指値注文帳（CLOB）、永久スワップ、ダークプール、そして注文制御、確定的実行、プライバシーを必要とするその他の金融インフラを構築できるようにすることで、Solanaエコシステムにおけるイノベーションを推進します。

以上です。