# ソラナの新しい挑戦：取引の質を向上させること、数量ではなくソラナはその高速と大容量の取引で知られていますが、それだけで十分なのでしょうか？これらの取引を深く分析すると、思わず尋ねたくなります：それらは本当に実際の価値を生み出しているのでしょうか？実際、ソラナ上の大量の取引は真の需要からではなく、ミリ秒単位の情報差を利用してアービトラージを行う高頻度取引者から来ている。このいわゆる「有毒な取引者」は技術的な優位性を利用し、マーケットメーカーがオーダーを撤回しようとする際にGas料金を引き上げ、自らの取引が優先的に実行されるようにしてアービトラージを行い、マーケットメーカーに損失を強いている。これらの損失を補填するために、マーケットメーカーは買値と売値のスプレッドを拡大せざるを得ず、最終的には一般ユーザーがそのコストを負担することになる。ソラナは、ブロックチェーン上で中央集権型取引所に代わる注文板を実現することを夢見てきましたが、"有毒な取引者"の存在がこの目標の障害となっています。これがソラナが現在直面している新たな課題です：取引量は流動性と同じではありません。真に健全な市場に必要なのは、より多くの取引ではなく、より質の高い取引です。! [Solana BAMブロックアセンブリ市場の解釈:速度がもはや唯一の追求ではなくなったとき](https://img-cdn.gateio.im/social/moments-80b3584e69b2d2874adfe16a0331ad66)## 毒性のある取引を除外し、流動性をより良く保護するには？現在のシステムでは、ソラナのコンセンサス機構が周期的オークションを採用しているため、注文を食べる者が実際に優先権を享受しており、これが悪意のあるMEV（最大抽出価値）行動によって市場の公平性に影響を与えています。ソラナの既存のコンセンサスメカニズムの下では、400ミリ秒ごとの時間スロット内で、取引は支払った優先ガス料金に基づいてソートされ、入札が最も高い取引が優先的に実行されます。このプロセスでは、マーケットメイカーは頻繁に価格を調整し、市場価格の変動に適応するために注文をキャンセルしたり再度出したりする必要があります。一方、アービトラージャーは価格差を監視し、機会を見つけ次第すぐに取引を行い、しばしばマーケットメイカーが注文をキャンセルする前により高い料金を支払うことで取引を完了させるため、マーケットメイカーは頻繁に損失を被ります。理想的には、オーダーブック型の分散型取引所（DEX）の取引の順序は、価格の変動に応じて、まずすべてのキャンセルが実行され、その後新しい注文があり、最後に取引が成立するべきです。しかし、ソラナの現在のコンセンサス機構は、ミクロレベルではこれを実現できません。同様に、オラクルの価格提供において理想的な状況は、まずオラクルの価格を更新し、その後にその価格に依存する取引を実行することです。しかし、現在の400ミリ秒の間隔内では、市場が激しい変動により、取引が依然として以前の価格で実行される可能性があります。借入契約に関しては、最適な解決策はまず保証金を追加し、その後清算を行うことです。したがって、ソラナは異なるプロトコルが需要に応じて取引を順序付けることを許可するメカニズムを必要としています。これがソラナが常に強調しているアプリケーション制御実行（ACE）です。## BAM：ソラナの解決策BAM（ブロック組み立て市場）は、ソラナがこれらの問題を解決するために提案した答えです。それは、ソラナチェーン上でメインネットとアプリケーションの間にソート層または前処理層を構築します。BAMは、信頼できる実行環境（TEEs）を利用してプライバシーサンドボックスを構築し、そこで事前に設定されたルールや先入れ先出し（FIFO）原則に基づいて取引をソートし、オーダーブック、永続的契約取引所、ダークプールなどのプロトコルにより良くサービスを提供します。## BAM のしくみ従来のソラナの取引プロセスでは、ユーザーが取引を確認した後、取引はRPCノードを通じて現在の時間スロットのリーダーノードに送信され、リーダーは取引を収集して整理し、ブロックにパッケージ化してブロードキャストし、他のノードが投票を行います。BAMに接続されたアプリケーションでは、取引プロセスが若干異なります：ユーザーが確認した取引はまずBAMネットワークに送信され、TEE環境で順序付けされます。この過程で、ノードはプラグインを通じて追加の取引を加えることがあり、例えばオラクルの価格を更新することがあります。順序付けされた取引パッケージはソラナのメインネットのリーダーノードに提出され、その後ブロックにパッケージされてブロードキャストされます。BAMは実際にはオプションの前処理層として機能し、ソラナのメインネット上で直接実行されるのではなく、"オフチェーン"でトランザクションの順序を決定し、その後、順序付けされたトランザクションパッケージをメインネットに提出します。## BAMの三つの運用モード1. ソラナデフォルトモード2. Block-Engineモード：現在のJitoのMEVソリューション、核心は入札メカニズム3. BAMモード：バリデーターはFIFO原則に従って厳密に順序付けますBAMモードの核心的な特徴は次のとおりです：1. TEEを利用してプライバシー環境を構築し、取引の順序を決定して公平性を確保する2. プラグインシステムを通じて複雑な取引ソートロジックを実現し、アプリケーションがカスタムソートルールを定義できるようにします。## BAMの実用化1. 借入清算保護：優先的に追加担保品操作を実行し、その後清算チェックを行います。2. 原子レベルの取引の組み合わせ：まずオラクルの価格を更新し、その価格に依存する取引を実行します。契約DEXの場合、関連するデリバティブの決済も同時に行うことができます。3. 価格変動保護：異常な大口注文を検出し、分割実行して市場に反応時間を与え、連鎖清算やアービトラージによる悪影響を回避します。4. マーケットメイカーの保護：突発的な事件が発生した場合に、迅速に注文をキャンセルし、価格を更新し、再度注文を出すことができ、悪意のあるアービトラージのリスクを減少させます。BAMの展開に伴い、ソラナの取引体験が大幅に改善され、そのメインネットアプリケーションの体験が中央集権型取引所により近づきます。総じて、BAMはソラナの取引処理プロセスに検証性、プライバシー保護、プログラム可能性をもたらしました。これにより、開発者は中央限界注文書、永続契約取引所、ダークプールおよびその他のソート制御、決定論的実行、プライバシー保護を必要とする金融インフラを構築でき、ソラナエコシステムの革新と発展を促進します。
ソラナはBAMソリューションを導入し、取引の質と公平性を向上させます。
ソラナの新しい挑戦：取引の質を向上させること、数量ではなく
ソラナはその高速と大容量の取引で知られていますが、それだけで十分なのでしょうか？これらの取引を深く分析すると、思わず尋ねたくなります：それらは本当に実際の価値を生み出しているのでしょうか？
実際、ソラナ上の大量の取引は真の需要からではなく、ミリ秒単位の情報差を利用してアービトラージを行う高頻度取引者から来ている。このいわゆる「有毒な取引者」は技術的な優位性を利用し、マーケットメーカーがオーダーを撤回しようとする際にGas料金を引き上げ、自らの取引が優先的に実行されるようにしてアービトラージを行い、マーケットメーカーに損失を強いている。これらの損失を補填するために、マーケットメーカーは買値と売値のスプレッドを拡大せざるを得ず、最終的には一般ユーザーがそのコストを負担することになる。
ソラナは、ブロックチェーン上で中央集権型取引所に代わる注文板を実現することを夢見てきましたが、"有毒な取引者"の存在がこの目標の障害となっています。これがソラナが現在直面している新たな課題です：取引量は流動性と同じではありません。真に健全な市場に必要なのは、より多くの取引ではなく、より質の高い取引です。
! Solana BAMブロックアセンブリ市場の解釈:速度がもはや唯一の追求ではなくなったとき
毒性のある取引を除外し、流動性をより良く保護するには？
現在のシステムでは、ソラナのコンセンサス機構が周期的オークションを採用しているため、注文を食べる者が実際に優先権を享受しており、これが悪意のあるMEV（最大抽出価値）行動によって市場の公平性に影響を与えています。
ソラナの既存のコンセンサスメカニズムの下では、400ミリ秒ごとの時間スロット内で、取引は支払った優先ガス料金に基づいてソートされ、入札が最も高い取引が優先的に実行されます。このプロセスでは、マーケットメイカーは頻繁に価格を調整し、市場価格の変動に適応するために注文をキャンセルしたり再度出したりする必要があります。一方、アービトラージャーは価格差を監視し、機会を見つけ次第すぐに取引を行い、しばしばマーケットメイカーが注文をキャンセルする前により高い料金を支払うことで取引を完了させるため、マーケットメイカーは頻繁に損失を被ります。
理想的には、オーダーブック型の分散型取引所（DEX）の取引の順序は、価格の変動に応じて、まずすべてのキャンセルが実行され、その後新しい注文があり、最後に取引が成立するべきです。しかし、ソラナの現在のコンセンサス機構は、ミクロレベルではこれを実現できません。
同様に、オラクルの価格提供において理想的な状況は、まずオラクルの価格を更新し、その後にその価格に依存する取引を実行することです。しかし、現在の400ミリ秒の間隔内では、市場が激しい変動により、取引が依然として以前の価格で実行される可能性があります。
借入契約に関しては、最適な解決策はまず保証金を追加し、その後清算を行うことです。
したがって、ソラナは異なるプロトコルが需要に応じて取引を順序付けることを許可するメカニズムを必要としています。これがソラナが常に強調しているアプリケーション制御実行（ACE）です。
BAM：ソラナの解決策
BAM（ブロック組み立て市場）は、ソラナがこれらの問題を解決するために提案した答えです。それは、ソラナチェーン上でメインネットとアプリケーションの間にソート層または前処理層を構築します。BAMは、信頼できる実行環境（TEEs）を利用してプライバシーサンドボックスを構築し、そこで事前に設定されたルールや先入れ先出し（FIFO）原則に基づいて取引をソートし、オーダーブック、永続的契約取引所、ダークプールなどのプロトコルにより良くサービスを提供します。
BAM のしくみ
従来のソラナの取引プロセスでは、ユーザーが取引を確認した後、取引はRPCノードを通じて現在の時間スロットのリーダーノードに送信され、リーダーは取引を収集して整理し、ブロックにパッケージ化してブロードキャストし、他のノードが投票を行います。
BAMに接続されたアプリケーションでは、取引プロセスが若干異なります：ユーザーが確認した取引はまずBAMネットワークに送信され、TEE環境で順序付けされます。この過程で、ノードはプラグインを通じて追加の取引を加えることがあり、例えばオラクルの価格を更新することがあります。順序付けされた取引パッケージはソラナのメインネットのリーダーノードに提出され、その後ブロックにパッケージされてブロードキャストされます。
BAMは実際にはオプションの前処理層として機能し、ソラナのメインネット上で直接実行されるのではなく、"オフチェーン"でトランザクションの順序を決定し、その後、順序付けされたトランザクションパッケージをメインネットに提出します。
BAMの三つの運用モード
BAMモードの核心的な特徴は次のとおりです：
BAMの実用化
BAMの展開に伴い、ソラナの取引体験が大幅に改善され、そのメインネットアプリケーションの体験が中央集権型取引所により近づきます。
総じて、BAMはソラナの取引処理プロセスに検証性、プライバシー保護、プログラム可能性をもたらしました。これにより、開発者は中央限界注文書、永続契約取引所、ダークプールおよびその他のソート制御、決定論的実行、プライバシー保護を必要とする金融インフラを構築でき、ソラナエコシステムの革新と発展を促進します。