これを行うには、NASDAQよりも優れた価格を提供する必要があり、アプリに約定する前にキャンセルを優先する機能を提供する必要があります。
**脚本: Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)
翻訳：GaryMa ウーはブロックチェーンについて語る
SolanaはNASDAQよりも効率的な分散型取引ネットワークの構築を目指していますが、既存のブロックチェーン設計は期待を下回っており、現在のSolanaマーケットメーカーは注文キャンセルレースでの勝率が低く(中央集権的な取引所の13%よりもはるかに低い)、Jito Auctionsは単一のリーダーによる国家アクセスの制御を悪化させ、スプレッドを拡大しています。 この点で、コンセンサスメカニズムを再構築し、複数の同時リーダーを導入して、注文順序を最適化し、マーケットメーカーの逆選択コストを削減し、価格効率を向上させることが提案されています。
Solanaの最初の作成目標は、十分に速く、十分に安価なブロックチェーンを構築することで、そこに利用可能な中央限界注文簿を運営できるようにすることでした。Solanaメインネットのテスト版は2020年3月にオンラインになりました——今では5年が経過しましたが、多くの成果を上げたにもかかわらず、この目標を達成できていないことがますます明らかになっています。
現在のブロックチェーン基盤は取引のために設計されているわけではありません。もし私たちがSolanaの本来の使命を実現したいのであれば、原点に戻り、最も基本的な原則から出発して、コンセンサスメカニズムを徹底的に再設計し、最終的にはニューヨーク証券取引所と競争できる能力を持つ分散型ネットワークを構築する必要があります。
私たちがニューヨーク証券取引所と競争すると言っているのは、Solana上の取引所が中央集権的取引所よりも良い価格を提供できる必要があるということです。市場の世界では、価格は「スプレッド」によって定義されます：すなわち、資産を購入したい人の最高価格と、資産を売却したい人の最低価格との間の差額です。
!
価格差が小さいほど、トレーダーが得られる価格は良くなり、市場の効率も高まります。
スプレッドの計算式は単純です。 スプレッドは、マーケットメーカーが非情報トレーダーとの取引から受け取る期待利益が、情報トレーダーとの取引から被る予想損失と等しくなるように設定されます。 マーケットメイカーが取引相手よりも多くの情報を持っているとき、彼らはお金を稼ぎます。 取引相手よりも情報が少ない場合、彼らはお金を失います。 マーケットメーカーは通常、個人投資家との取引ごとに少額のお金を稼ぎますが、価格が激しく跳ね上がったときに反対方向にヘッジされると、多くの損失を被ります(できればまれに)。 これが「マーケットメーカーが門を拾い、スイカを失う」という言葉の由来です。
逆選択をよりよく理解するためには、ゲームマーケットメーカーが何をしているのかを理解する必要があります。 マーケットメイカーは、時間の経過とともにランダムに変化する「公正価格」に基づいて意思決定を行います。 公正価格がビッド・アスク・スプレッド内にある場合、カウンターパーティはクォートを食べて利益を得ることができないため、マーケットメーカーのクォートは安全です。 しかし、公正な価格がビッド・アスク・スプレッドを超えるとすぐに、競争が始まります:マーケットメーカーはできるだけ早く注文をキャンセルしようとし、テイカーはマーケットメーカーがキャンセルする前に古い注文をつかもうとします。 成功したテイカーの期待は、公正な価格と古いオファーの違いです。 逆選択の摩擦を減らすための鍵は、マーケットメーカーができるだけレースに勝てるようにすることです。
ある中央集権型取引所のデータによると、価格変動後にマーケットメイカーが先に注文をキャンセルできる確率はわずか13%です。
中央集権的な取引所のマーケットメイカーは、キャンセルレースで勝つ可能性は低くなりますが、Solanaではさらに低くなります。 Jitoのオークションメカニズムは、単一の提案者が長期間にわたって国家のアクセスを制御する副作用であり、マーケットメーカーがキャンセルレースに勝つことをほぼ不可能にしています。 マーケットメーカーが速かったとしても、本当の決定はJitoオークションで誰が高く入札するかです。 これにより、マーケットメイカーはジレンマに陥ります:彼らは注文をキャンセルするために多額のお金を払うか、他の誰かに高い価格を払わせて彼らを狙撃することができます。 いずれにせよ、彼らはお金を失っており、その結果、スプレッドを広げなければなりませんでした。
実際には、現在のオンチェーン市場の微細構造は、逆選択の点でテイカーに先行者利益をもたらします。 この問題を解決するには、アプリケーションでトランザクションを順序付ける際の柔軟性を高める必要があります。 スプレッドを下げたい場合、アプリケーションはマーケットメーカーに注文キャンセルレースで有利なスタートを切らせることができなければなりません。 これを行う 1 つの方法は、「最初にキャンセルし、後で埋める」並べ替え戦略を導入することです。 ブロックを見て、すべてのキャンセルを処理してから、すべてのテイクを処理します。
この戦略は、現在のリプレイの順序をリーダーが決定するモデルからキャンセルを優先するポリシーに変更するだけで、Solanaですぐに実装できます。 しかし、それで問題が完全に解決するわけではありません。 もしそれがまだ一人のリーダーによって支配されていて、そのリーダーが取引のキャンセルを無視することを選択できるなら、私たちは振り出しに戻ってしまいます - マーケットメーカーはレースをキャンセルするのにまだ不利な立場にあります。
この問題を解決する唯一の方法は、複数の並行リーダー（Concurrent Leaders）を導入することです。これにより、もしあるリーダーが取引をキャンセルした場合、別のリーダーに提出することができます。
複数の並列リーダーに関する最大の問題は、競合が発生したときに、それぞれのトランザクションブロックをどのようにマージするかということです。 答えは簡単で、手数料をインクルージョン手数料と注文手数料の2つのカテゴリに分けています。 インクルージョン手数料はトランザクションを含むバリデーターに支払われ、ソーティング手数料はプロトコル(バーン)に支払われます。 各リーダーのブロックをマージする場合は、スロット内のすべてのブロックのすべてのトランザクションの結合を取り、ソーティング手数料に従って並べ替えるだけです。
この対策だけでは不十分です。 私たちが本当に達成しようとしているのは、トランザクションの順序を制御するための柔軟性をアプリケーションに与えることです。 もう 1 つの要素である 'get_transaction_metadata' システムコールを使用すると、プログラムは対話するトランザクションのソート手数料を読み取ることができ、アプリケーションに強力な順序制御ツールが提供されます。
私たちのコンセンサス機構の設計目標には、
バインディング&ブラインド:パラレルリーダーは、他のリーダーのブロックからの情報を自分のブロックに含めることはできません(例:プライベートトランザクションをつまむ)か、他のリーダーのブロックの内容に基づいて自分のブロックをキャンセルすることもできません(例:他の入札を見て自分の入札をキャンセルする)。
時計の公平性（Wallclock Fairness）：並行するリーダーは、ほぼ同じ実時間内にブロックを提出しなければなりません。
ここでは、a16z Research の Pranav Garimidi 氏と Joachim Neu 氏と共同で開発した最も効果的なシナリオの概要をご紹介します。
各リーダーは、自分のブロックをエラーレジスタのフラグメント（shreds）に変換します。十分な数（エンコード率を超える）のフラグメントを復元すれば、ブロックを復元できます。部分的な復元は不可能です。
リーダーは、シャードを Turbine ツリーの最初のレイヤーのリレーノードに送信します。 各リーダーは、最初のスライスをリレー 1 に、2 番目のスライスをリレー 2 に送信します。 すべてがうまくいけば、各リレーはすべてのリーダーからシャードを受け取ります。
タイムアウト後、中継は単一のコンセンサスリーダーに署名された IHAVE メッセージを送信し、受信したフラグメントを通知します。
コンセンサスリーダーは、その後、これらの IHAVE メッセージを含むブロックを構築します。IHAVE メッセージの十分な割合が含まれていない場合、そのブロックは無効となります。
コンセンサスリーダーはそのブロックをバリデーターにブロードキャストし、バリデーターはそのブロックについてコンセンサスを形成し始めます。
このソリューションは、高い確率でバインディングとブラインド属性を満たし、良好なクロック公正性を備えていますが、将来的にはより優れたソリューションが現れる可能性があります。
Solanaは、NASDAQを超えることを目標に作成されました。 これを行うには、NASDAQよりも優れた価格を提供する必要があります。 これを行うには、クロージング前にキャンセルを優先する機能をアプリに付与する必要があります。 この能力を活かすためには、リーダーが一方的に注文を見直すことを防ぐ必要があります。 そのためには、複数のリーダーを並行して招聘する必要があります。
302k 投稿
269k 投稿
177k 投稿
83k 投稿
70k 投稿
69k 投稿
63k 投稿
62k 投稿
53k 投稿
51k 投稿
ソラナはどのように改善してオンチェーンのナスダックのビジョンを実現できるか？
**脚本: Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)
翻訳：GaryMa ウーはブロックチェーンについて語る
まとめ
SolanaはNASDAQよりも効率的な分散型取引ネットワークの構築を目指していますが、既存のブロックチェーン設計は期待を下回っており、現在のSolanaマーケットメーカーは注文キャンセルレースでの勝率が低く(中央集権的な取引所の13%よりもはるかに低い)、Jito Auctionsは単一のリーダーによる国家アクセスの制御を悪化させ、スプレッドを拡大しています。 この点で、コンセンサスメカニズムを再構築し、複数の同時リーダーを導入して、注文順序を最適化し、マーケットメーカーの逆選択コストを削減し、価格効率を向上させることが提案されています。
Solanaの最初の作成目標は、十分に速く、十分に安価なブロックチェーンを構築することで、そこに利用可能な中央限界注文簿を運営できるようにすることでした。Solanaメインネットのテスト版は2020年3月にオンラインになりました——今では5年が経過しましたが、多くの成果を上げたにもかかわらず、この目標を達成できていないことがますます明らかになっています。
現在のブロックチェーン基盤は取引のために設計されているわけではありません。もし私たちがSolanaの本来の使命を実現したいのであれば、原点に戻り、最も基本的な原則から出発して、コンセンサスメカニズムを徹底的に再設計し、最終的にはニューヨーク証券取引所と競争できる能力を持つ分散型ネットワークを構築する必要があります。
私たちがニューヨーク証券取引所と競争すると言っているのは、Solana上の取引所が中央集権的取引所よりも良い価格を提供できる必要があるということです。市場の世界では、価格は「スプレッド」によって定義されます：すなわち、資産を購入したい人の最高価格と、資産を売却したい人の最低価格との間の差額です。
!
価格差が小さいほど、トレーダーが得られる価格は良くなり、市場の効率も高まります。
スプレッドの計算式は単純です。 スプレッドは、マーケットメーカーが非情報トレーダーとの取引から受け取る期待利益が、情報トレーダーとの取引から被る予想損失と等しくなるように設定されます。 マーケットメイカーが取引相手よりも多くの情報を持っているとき、彼らはお金を稼ぎます。 取引相手よりも情報が少ない場合、彼らはお金を失います。 マーケットメーカーは通常、個人投資家との取引ごとに少額のお金を稼ぎますが、価格が激しく跳ね上がったときに反対方向にヘッジされると、多くの損失を被ります(できればまれに)。 これが「マーケットメーカーが門を拾い、スイカを失う」という言葉の由来です。
逆選択のコストは何を決定しますか?
!
逆選択をよりよく理解するためには、ゲームマーケットメーカーが何をしているのかを理解する必要があります。 マーケットメイカーは、時間の経過とともにランダムに変化する「公正価格」に基づいて意思決定を行います。 公正価格がビッド・アスク・スプレッド内にある場合、カウンターパーティはクォートを食べて利益を得ることができないため、マーケットメーカーのクォートは安全です。 しかし、公正な価格がビッド・アスク・スプレッドを超えるとすぐに、競争が始まります:マーケットメーカーはできるだけ早く注文をキャンセルしようとし、テイカーはマーケットメーカーがキャンセルする前に古い注文をつかもうとします。 成功したテイカーの期待は、公正な価格と古いオファーの違いです。 逆選択の摩擦を減らすための鍵は、マーケットメーカーができるだけレースに勝てるようにすることです。
!
ある中央集権型取引所のデータによると、価格変動後にマーケットメイカーが先に注文をキャンセルできる確率はわずか13%です。
!
中央集権的な取引所のマーケットメイカーは、キャンセルレースで勝つ可能性は低くなりますが、Solanaではさらに低くなります。 Jitoのオークションメカニズムは、単一の提案者が長期間にわたって国家のアクセスを制御する副作用であり、マーケットメーカーがキャンセルレースに勝つことをほぼ不可能にしています。 マーケットメーカーが速かったとしても、本当の決定はJitoオークションで誰が高く入札するかです。 これにより、マーケットメイカーはジレンマに陥ります:彼らは注文をキャンセルするために多額のお金を払うか、他の誰かに高い価格を払わせて彼らを狙撃することができます。 いずれにせよ、彼らはお金を失っており、その結果、スプレッドを広げなければなりませんでした。
!
実際には、現在のオンチェーン市場の微細構造は、逆選択の点でテイカーに先行者利益をもたらします。 この問題を解決するには、アプリケーションでトランザクションを順序付ける際の柔軟性を高める必要があります。 スプレッドを下げたい場合、アプリケーションはマーケットメーカーに注文キャンセルレースで有利なスタートを切らせることができなければなりません。 これを行う 1 つの方法は、「最初にキャンセルし、後で埋める」並べ替え戦略を導入することです。 ブロックを見て、すべてのキャンセルを処理してから、すべてのテイクを処理します。
!
この戦略は、現在のリプレイの順序をリーダーが決定するモデルからキャンセルを優先するポリシーに変更するだけで、Solanaですぐに実装できます。 しかし、それで問題が完全に解決するわけではありません。 もしそれがまだ一人のリーダーによって支配されていて、そのリーダーが取引のキャンセルを無視することを選択できるなら、私たちは振り出しに戻ってしまいます - マーケットメーカーはレースをキャンセルするのにまだ不利な立場にあります。
!
この問題を解決する唯一の方法は、複数の並行リーダー（Concurrent Leaders）を導入することです。これにより、もしあるリーダーが取引をキャンセルした場合、別のリーダーに提出することができます。
!
実現 — 取引のソート
複数の並列リーダーに関する最大の問題は、競合が発生したときに、それぞれのトランザクションブロックをどのようにマージするかということです。 答えは簡単で、手数料をインクルージョン手数料と注文手数料の2つのカテゴリに分けています。 インクルージョン手数料はトランザクションを含むバリデーターに支払われ、ソーティング手数料はプロトコル(バーン)に支払われます。 各リーダーのブロックをマージする場合は、スロット内のすべてのブロックのすべてのトランザクションの結合を取り、ソーティング手数料に従って並べ替えるだけです。
!
この対策だけでは不十分です。 私たちが本当に達成しようとしているのは、トランザクションの順序を制御するための柔軟性をアプリケーションに与えることです。 もう 1 つの要素である 'get_transaction_metadata' システムコールを使用すると、プログラムは対話するトランザクションのソート手数料を読み取ることができ、アプリケーションに強力な順序制御ツールが提供されます。
!
実現 — コンセンサス機構
私たちのコンセンサス機構の設計目標には、
バインディング&ブラインド:パラレルリーダーは、他のリーダーのブロックからの情報を自分のブロックに含めることはできません(例:プライベートトランザクションをつまむ)か、他のリーダーのブロックの内容に基づいて自分のブロックをキャンセルすることもできません(例:他の入札を見て自分の入札をキャンセルする)。
時計の公平性（Wallclock Fairness）：並行するリーダーは、ほぼ同じ実時間内にブロックを提出しなければなりません。
ここでは、a16z Research の Pranav Garimidi 氏と Joachim Neu 氏と共同で開発した最も効果的なシナリオの概要をご紹介します。
各リーダーは、自分のブロックをエラーレジスタのフラグメント（shreds）に変換します。十分な数（エンコード率を超える）のフラグメントを復元すれば、ブロックを復元できます。部分的な復元は不可能です。
リーダーは、シャードを Turbine ツリーの最初のレイヤーのリレーノードに送信します。 各リーダーは、最初のスライスをリレー 1 に、2 番目のスライスをリレー 2 に送信します。 すべてがうまくいけば、各リレーはすべてのリーダーからシャードを受け取ります。
タイムアウト後、中継は単一のコンセンサスリーダーに署名された IHAVE メッセージを送信し、受信したフラグメントを通知します。
コンセンサスリーダーは、その後、これらの IHAVE メッセージを含むブロックを構築します。IHAVE メッセージの十分な割合が含まれていない場合、そのブロックは無効となります。
コンセンサスリーダーはそのブロックをバリデーターにブロードキャストし、バリデーターはそのブロックについてコンセンサスを形成し始めます。
このソリューションは、高い確率でバインディングとブラインド属性を満たし、良好なクロック公正性を備えていますが、将来的にはより優れたソリューションが現れる可能性があります。
!
まとめ
Solanaは、NASDAQを超えることを目標に作成されました。 これを行うには、NASDAQよりも優れた価格を提供する必要があります。 これを行うには、クロージング前にキャンセルを優先する機能をアプリに付与する必要があります。 この能力を活かすためには、リーダーが一方的に注文を見直すことを防ぐ必要があります。 そのためには、複数のリーダーを並行して招聘する必要があります。