ソラナは十分に速く、出来高も十分に大きい。それでは、本当に「十分」なのでしょうか？取引を検討する際、常に存在する疑問があります：これらの取引は本当に価値を生み出しているのでしょうか？ソラナ 大量の出来高は実際の取引需要から来ているわけではなく、高頻度のアービトラージャーがミリ秒単位の情報差を利用して利益を得ています。 これらの"有毒取引者"（Toxic-takers）は技術的な優位性を利用して、マーケットメイカー（Maker）が注文を撤回しようとする際にGasを増加させ、自分の取引を先にパッケージし、アービトラージを完了させることでマーケットメイカーに損失を与えます。 損失を補うために、マーケットメイカーは買値と売値のスプレッドを拡大せざるを得ません。最終的には、普通のユーザーがその代償を払うことになります。ソラナは常にCEXを置き換えるオンチェーンオーダーブックの実現を夢見ています。しかしそうなると、「有毒なトレーダー」がその夢を実現する障害となります。これがソラナが直面している新たな挑戦です：出来高≠流動性。本当に健全な市場に必要なのは、より多くの取引ではなく、より良い取引です。### 有毒な取引をどのように排除し、流動性をより良く保護することができますか？現在のシステムでは、テイカーはソラナのコンセンサス周期的オークションメカニズムにより、実際の優先権を享受し、悪意のあるMEVが市場の公平性に影響を与えています。**どう理解する？**ソラナの現在のコンセンサスでは、各時間帯のSlot内で、取引は支払った優先Gas料金の順に並べられ、入札が高いほどその取引が先に実行されます。このオークションは周期的で、400ミリ秒ごとに1つのSlotがあります。このプロセスでは、マーケットメイカーは頻繁に価格を調整し、注文をキャンセルし、再度注文を出す必要があります。市場価格が変動する際には、即座に更新する必要があります。そして、食べる側（テイカー）、特に高頻度アービトラージャーは、価格差を監視し、機会を見つけるとすぐに取引を行います。 そのため、アービトラージャーは、高い手数料を支払うことで、キャンセルされる前に取引を成立させることができます。これにより、マーケットメイカーはしばしば「狙撃」され、損失を被ることになります。注文簿 DEX にとって、理想的な順序は、価格の変動に応じて、まずすべてのキャンセルを実行し、次に新しい注文を実行し、最後に取引を実行することです。これは現在のソラナのコンセンサスがミクロレベルで実現できていないことです。また、オラクルの価格提示レイヤーにおいても同様で、理想的な状況は、まずオラクルの価格を更新し、その価格に依存する取引を実行することです。しかし、現在の400ミリ秒の間隔内では、市場が激しく変動する可能性があり、取引が実行される際に依然として元の価格で成立することがあります。貸出契約においては、まず保証金を追加し、その後清算を行うのが最良です。したがって、異なるプロトコルがニーズに応じて取引をソートできる方法があると最良です。これは、ソラナが常に強調しているACEアプリケーション制御実行（Application-Controlled Execution）です。BAM（Block Assembly Marketplace、ブロックアセンブリマーケットプレイス）は、ソラナの答えです。BAMはソラナチェーン上で、メインネットとの間にソートレイヤー、またはプレプロセッシングレイヤーを構築しました。信頼できる実行環境 (Trusted Execution Environments, TEEs) を利用してプライバシーサンドボックスを構築し、サンドボックス内で事前に決定された順位付けルール、または FIFO（先入れ先出し）に基づいて取引を並べ替えます。CLOB、パーペチュアルエクスチェンジ、ダークプールプロトコルのサービスが向上しました。### ソラナ 通常取引パッケージと BAM モードの比較BAMがソラナのアプリケーションとメインネットの間にどのようにソーティングレイヤーを構築したのかを理解する方法？まずは直感的な比較から。ソラナ 正常取引フロー、1）ユーザーはウォレット内で取引を確認します。2）RPCノードにトランザクションを送信する、3）RPC が現在のスロットの期間内に、ソラナメインネットのリーダーノードに送信します。4）リーダーは取引プールの取引を収集し、ソートし、ブロックにパッケージ化してブロードキャストします。5）残りのノードの投票。もしあるアプリケーションがBAMを接続した場合、取引の流れは以下の通りです。1）ユーザーはウォレット内で取引を確認します。2）RPCノードにトランザクションを送信します。3）BAMネットワークに取引を移し、TEEプライバシー内でソートします。この過程で、ノードはプラグインを介して追加の取引を追加する可能性があり、例えばオラクルの価格を更新し、その後証明を生成します。4）取引データパケットがソラナのメインネットのリーダーノードに提出されます。5）Leaderが取引を収集する際、BAMデータパケットを収集し、それをブロックにパッケージ化してブロードキャストします。6）残りのノードが投票します。ですので、実際にはBAMは現在のソラナメインネットの合意プロセスとは矛盾せず、むしろ「オプショナリティ」として機能します。BAMはソラナメインネット上で直接稼働するのではなく、いわゆる「オフチェーン」の方法で、事前に取引の順序を決定し、取引をパッケージ化してからソラナメインネットに提出します。! [Solana BAMブロックアセンブリ市場の解釈:速度がもはや唯一の追求ではなくなったとき](https://img-cdn.gateio.im/social/moments-80b3584e69b2d2874adfe16a0331ad66)### BAM トランザクション ソート モードBAMは三つの運用モードをサポートしています。1）ソラナ デフォルトモード；2）Block-Engine モード；現在の Jito の MEV ソリューション、核心は入札メカニズムです。3）BAMモードでは、バリデーターはFIFO（先入れ先出し）順序に厳密に従います。BAM モードのコアには、以下の点があります。1）信頼できる実行環境 TEE：プライバシーと公正 信頼できる実行環境 TEEを利用して、プライバシー環境を構築し、取引を並べ替えます。プライバシーのもう一つの側面は公正です。2）プラグインシステム Plugin：複雑なソート プラグインシステムを通じて、BAMはアプリケーションにカスタム取引ソートロジックの構築を許可します。このカスタムソートは、ノードが好きなようにソートできるという意味ではなく、あらかじめ設定されたルールに基づいてソートされます。プラグインは複雑な取引のソートを実現し、同時にTEE環境のセキュリティ保証を維持します。現在、初期開発段階にあります。前述の通り、注文板 DEX にとって、理想的なソートは、価格の変動に応じて、まずすべてのキャンセルを実行し、その後新しい注文を実行し、最後に約定を実行することです。これは現在ソラナのコンセンサスがミクロレベルでできないことです。また、オラクルの価格提供の面でも同じことが言えます。理想的な状況は、オラクルの価格を先に更新し、その価格に依存する取引を実行することです。しかし、現在の400ミリ秒の間隔内では、市場が激しく変動する可能性があるため、取引時に依然として元の価格で成立することがあります。借入契約に関しては、まず保証金を補充してから清算を行うのが最善です。これは実際にACEアプリの制御実行機能を実現しています。### それで、BAMは一体何を実現したのですか？例えば、1)ローン清算保護借入契約において、清算リスクが検出された場合、まずは追加担保の操作を優先的に実行し、その後に清算チェックを行います。2）原子レベルの取引の組み合わせDEXについて、まずオラクルの価格を更新し、その価格に依存する取引を実行します。もし契約DEXの場合、関連するデリバティブも決済できます。以上の操作は、すべて同じ時間ウィンドウ内で完了します。3)価格変動防止DEXに対して、異常な大口注文を検出し、大口注文を小さな塊に分割して分割実行し、市場に反応時間を与え、連鎖清算やアービトラージによるデススパイラルを避ける。4）マーケットメイカー保護突発的な出来事が発生し、ミリ秒内に注文を取り消し、オラクルが価格を更新し、市場メーカーが再び注文を出します。悪意のあるアービトラージを避け、価格差を縮小します。BAM は本来 7 月末に発売される予定でした。さらに、BAMの展開に伴い、ソラナの取引体験が大幅に改善されます。BAMはソラナのメインネットアプリケーションの体験をCEXに近づけるでしょう。以上より、BAMは、ソラナの取引処理プロセスに検証可能性、プライバシー保護、プログラム可能性をもたらし、開発者が中央限界注文書（CLOB）、永続的契約取引所（Perpetual Exchanges）、ダークプール（Dark Pools）、および他のソート制御、決定的実行、プライバシー保護を必要とする金融インフラを構築できるようにし、ソラナエコシステムの革新的な発展を促進します。以上です。
ソラナ BAMブロック組立市場の解釈：速度が唯一の追求でなくなったとき
ソラナは十分に速く、出来高も十分に大きい。それでは、本当に「十分」なのでしょうか？
取引を検討する際、常に存在する疑問があります：これらの取引は本当に価値を生み出しているのでしょうか？
ソラナ 大量の出来高は実際の取引需要から来ているわけではなく、高頻度のアービトラージャーがミリ秒単位の情報差を利用して利益を得ています。 これらの"有毒取引者"（Toxic-takers）は技術的な優位性を利用して、マーケットメイカー（Maker）が注文を撤回しようとする際にGasを増加させ、自分の取引を先にパッケージし、アービトラージを完了させることでマーケットメイカーに損失を与えます。 損失を補うために、マーケットメイカーは買値と売値のスプレッドを拡大せざるを得ません。
最終的には、普通のユーザーがその代償を払うことになります。ソラナは常にCEXを置き換えるオンチェーンオーダーブックの実現を夢見ています。しかしそうなると、「有毒なトレーダー」がその夢を実現する障害となります。これがソラナが直面している新たな挑戦です：出来高≠流動性。本当に健全な市場に必要なのは、より多くの取引ではなく、より良い取引です。
有毒な取引をどのように排除し、流動性をより良く保護することができますか？
現在のシステムでは、テイカーはソラナのコンセンサス周期的オークションメカニズムにより、実際の優先権を享受し、悪意のあるMEVが市場の公平性に影響を与えています。
どう理解する？
ソラナの現在のコンセンサスでは、各時間帯のSlot内で、取引は支払った優先Gas料金の順に並べられ、入札が高いほどその取引が先に実行されます。このオークションは周期的で、400ミリ秒ごとに1つのSlotがあります。
このプロセスでは、マーケットメイカーは頻繁に価格を調整し、注文をキャンセルし、再度注文を出す必要があります。市場価格が変動する際には、即座に更新する必要があります。
そして、食べる側（テイカー）、特に高頻度アービトラージャーは、価格差を監視し、機会を見つけるとすぐに取引を行います。 そのため、アービトラージャーは、高い手数料を支払うことで、キャンセルされる前に取引を成立させることができます。これにより、マーケットメイカーはしばしば「狙撃」され、損失を被ることになります。
注文簿 DEX にとって、理想的な順序は、価格の変動に応じて、まずすべてのキャンセルを実行し、次に新しい注文を実行し、最後に取引を実行することです。これは現在のソラナのコンセンサスがミクロレベルで実現できていないことです。
また、オラクルの価格提示レイヤーにおいても同様で、理想的な状況は、まずオラクルの価格を更新し、その価格に依存する取引を実行することです。しかし、現在の400ミリ秒の間隔内では、市場が激しく変動する可能性があり、取引が実行される際に依然として元の価格で成立することがあります。
貸出契約においては、まず保証金を追加し、その後清算を行うのが最良です。
したがって、異なるプロトコルがニーズに応じて取引をソートできる方法があると最良です。これは、ソラナが常に強調しているACEアプリケーション制御実行（Application-Controlled Execution）です。
BAM（Block Assembly Marketplace、ブロックアセンブリマーケットプレイス）は、ソラナの答えです。
BAMはソラナチェーン上で、メインネットとの間にソートレイヤー、またはプレプロセッシングレイヤーを構築しました。
信頼できる実行環境 (Trusted Execution Environments, TEEs) を利用してプライバシーサンドボックスを構築し、サンドボックス内で事前に決定された順位付けルール、または FIFO（先入れ先出し）に基づいて取引を並べ替えます。
CLOB、パーペチュアルエクスチェンジ、ダークプールプロトコルのサービスが向上しました。
ソラナ 通常取引パッケージと BAM モードの比較
BAMがソラナのアプリケーションとメインネットの間にどのようにソーティングレイヤーを構築したのかを理解する方法？まずは直感的な比較から。
ソラナ 正常取引フロー、
1）ユーザーはウォレット内で取引を確認します。
2）RPCノードにトランザクションを送信する、
3）RPC が現在のスロットの期間内に、ソラナメインネットのリーダーノードに送信します。
4）リーダーは取引プールの取引を収集し、ソートし、ブロックにパッケージ化してブロードキャストします。
5）残りのノードの投票。
もしあるアプリケーションがBAMを接続した場合、取引の流れは以下の通りです。
1）ユーザーはウォレット内で取引を確認します。
2）RPCノードにトランザクションを送信します。
3）BAMネットワークに取引を移し、TEEプライバシー内でソートします。この過程で、ノードはプラグインを介して追加の取引を追加する可能性があり、例えばオラクルの価格を更新し、その後証明を生成します。
4）取引データパケットがソラナのメインネットのリーダーノードに提出されます。
5）Leaderが取引を収集する際、BAMデータパケットを収集し、それをブロックにパッケージ化してブロードキャストします。
6）残りのノードが投票します。
ですので、実際にはBAMは現在のソラナメインネットの合意プロセスとは矛盾せず、むしろ「オプショナリティ」として機能します。BAMはソラナメインネット上で直接稼働するのではなく、いわゆる「オフチェーン」の方法で、事前に取引の順序を決定し、取引をパッケージ化してからソラナメインネットに提出します。
! Solana BAMブロックアセンブリ市場の解釈:速度がもはや唯一の追求ではなくなったとき
BAM トランザクション ソート モード
BAMは三つの運用モードをサポートしています。
1）ソラナ デフォルトモード；
2）Block-Engine モード；現在の Jito の MEV ソリューション、核心は入札メカニズムです。
3）BAMモードでは、バリデーターはFIFO（先入れ先出し）順序に厳密に従います。
BAM モードのコアには、以下の点があります。
1）信頼できる実行環境 TEE：プライバシーと公正 信頼できる実行環境 TEEを利用して、プライバシー環境を構築し、取引を並べ替えます。プライバシーのもう一つの側面は公正です。
2）プラグインシステム Plugin：複雑なソート プラグインシステムを通じて、BAMはアプリケーションにカスタム取引ソートロジックの構築を許可します。このカスタムソートは、ノードが好きなようにソートできるという意味ではなく、あらかじめ設定されたルールに基づいてソートされます。
プラグインは複雑な取引のソートを実現し、同時にTEE環境のセキュリティ保証を維持します。現在、初期開発段階にあります。
前述の通り、
注文板 DEX にとって、理想的なソートは、価格の変動に応じて、まずすべてのキャンセルを実行し、その後新しい注文を実行し、最後に約定を実行することです。これは現在ソラナのコンセンサスがミクロレベルでできないことです。
また、オラクルの価格提供の面でも同じことが言えます。理想的な状況は、オラクルの価格を先に更新し、その価格に依存する取引を実行することです。しかし、現在の400ミリ秒の間隔内では、市場が激しく変動する可能性があるため、取引時に依然として元の価格で成立することがあります。
借入契約に関しては、まず保証金を補充してから清算を行うのが最善です。これは実際にACEアプリの制御実行機能を実現しています。
それで、BAMは一体何を実現したのですか？
例えば、
1)ローン清算保護
借入契約において、清算リスクが検出された場合、まずは追加担保の操作を優先的に実行し、その後に清算チェックを行います。
2）原子レベルの取引の組み合わせ
DEXについて、まずオラクルの価格を更新し、その価格に依存する取引を実行します。もし契約DEXの場合、関連するデリバティブも決済できます。以上の操作は、すべて同じ時間ウィンドウ内で完了します。
3)価格変動防止
DEXに対して、異常な大口注文を検出し、大口注文を小さな塊に分割して分割実行し、市場に反応時間を与え、連鎖清算やアービトラージによるデススパイラルを避ける。
4）マーケットメイカー保護
突発的な出来事が発生し、ミリ秒内に注文を取り消し、オラクルが価格を更新し、市場メーカーが再び注文を出します。悪意のあるアービトラージを避け、価格差を縮小します。
BAM は本来 7 月末に発売される予定でした。
さらに、BAMの展開に伴い、ソラナの取引体験が大幅に改善されます。BAMはソラナのメインネットアプリケーションの体験をCEXに近づけるでしょう。
以上より、
BAMは、ソラナの取引処理プロセスに検証可能性、プライバシー保護、プログラム可能性をもたらし、開発者が中央限界注文書（CLOB）、永続的契約取引所（Perpetual Exchanges）、ダークプール（Dark Pools）、および他のソート制御、決定的実行、プライバシー保護を必要とする金融インフラを構築できるようにし、ソラナエコシステムの革新的な発展を促進します。
以上です。