Solanaはどのように改善してオンチェーンのナスダックのビジョンを実現できるか？

原題：《The Path to Decentralized Nasdaq》

著者 ：Max Resnick（Anza）\& Anatoly Yakovenko（Solana Labs）

編訳 ：GaryMa 吴说区块链

Solanaは、ナスダックよりも効率的な分散型取引ネットワークを構築することを目指していますが、既存のブロックチェーン設計は期待に達しておらず、現在のSolanaのマーケットメーカーは注文キャンセル競争において勝率が低い（中央集権型取引所の13%を大きく下回る）、Jitoオークションは単一のリーダーによる状態アクセスの制御を強化し、スプレッドを拡大させています。これに対し、彼らはコンセンサスメカニズムを再構築し、注文の並び替えを最適化するために複数の並行リーダー（Concurrent Leaders）を導入し、マーケットメーカーの逆選択コストを低減し、価格効率を向上させることを提案しています。

Solanaの最初の創設目標は、十分に速く、十分に安価なブロックチェーンを構築し、その上で利用可能な中央限度価格注文簿を運営できるようにすることでした。Solanaメインネットのテスト版は2020年3月に立ち上がりました --- --- 現在、5年が経過しましたが、多くの成果を上げたにもかかわらず、この目標はまだ達成されていないことがますます明らかになっています。

既存のブロックチェーンインフラは取引のために設計されていません。Solanaの最初の使命を実現するためには、原点に戻り、最も基本的な原則から出発して、コンセンサスメカニズムを徹底的に再設計し、最終的にはニューヨーク証券取引所と競争できる分散型ネットワークを構築する必要があります。

私たちが言う「ニューヨーク証券取引所と競争する」とは、Solana上の取引所が中央集権型取引所よりも良い価格を提供できる必要があるということです。市場の世界では、価格は「スプレッド」によって定義されます：つまり、ある人が資産を買うために支払う最高価格と、別の人が資産を売るために受け取る最低価格との間の差です。

スプレッドが小さいほど、トレーダーが得られる価格は良くなり、市場の効率も高くなります。

スプレッドの公式は非常にシンプルです。スプレッドは次のように設定されます：マーケットメーカーが情報を持たないトレーダーとの取引から得られる期待収益は、情報を持つトレーダーとの取引から生じる期待損失に等しいです。マーケットメーカーが相手方よりも情報を多く持っている場合、彼らは利益を得ます；相手方よりも情報が少ない場合、彼らは損失を被ります。マーケットメーカーは通常、個々の小口トレーダーとの取引で少しずつ利益を得ますが、価格が激しく変動する（頻繁でないことを願っています）場合、逆方向に捕まると大きな損失を被ります。これが「マーケットメーカーはゴマを拾ってスイカを失う」という言葉の由来です。

逆選択コストは何によって決まるのか？

逆選択をよりよく理解するためには、マーケットメーカーがどのようなゲームをしているのかを理解する必要があります。マーケットメーカーは、時間とともにランダムに変化する「公正価格」（fair）に基づいて判断します。公正価格が売買スプレッドの範囲内にある場合、マーケットメーカーの提示価格は安全です。なぜなら、相手方がその提示価格を受け入れても利益を得られないからです。しかし、公正価格が売買スプレッドを超えると、競争が始まります：マーケットメーカーはできるだけ早く注文をキャンセルしようとし、相手方（テイカー）はマーケットメーカーがキャンセルする前にその過去の注文を奪おうとします。成功したテイカーが期待するのは、公正価格と過去の提示価格との間の差です。逆選択の摩擦を減少させる鍵は、できるだけマーケットメーカーがこの競争に勝つようにすることです。

ある中央集権型取引所のデータによると、価格が変動した後、マーケットメーカーが先に注文をキャンセルできる確率はわずか13%です。

中央集権型取引所のマーケットメーカーがキャンセル競争に勝つ確率は高くありませんが、Solanaではさらに低くなります。Jitoオークションメカニズム --- --- これは、単一の提案者が長期間にわたって状態アクセス権を制御することによって引き起こされる副作用 --- --- により、マーケットメーカーはキャンセル競争に勝つことがほぼ不可能になります。たとえマーケットメーカーがより早くても、実際に勝敗を決定するのは、Jitoオークションで誰がより高く入札するかです。これにより、マーケットメーカーは進退窮まる状況に置かれます：高額で注文をキャンセルするか、他の人に高値で狙われるかのどちらかです。どちらの方法でも、彼らは損失を被るため、スプレッドを拡大せざるを得ません。

実際の運用において、現在のオンチェーン市場のミクロ構造は、逆選択の面でテイカーに先手を与えています。この問題を解決するためには、アプリケーションにより大きな取引並び替えの柔軟性を与える必要があります。スプレッドを減少させたいのであれば、アプリケーションはキャンセル注文の競争においてマーケットメーカーに先手を与える必要があります。一つの方法は、「先にキャンセルしてから取引する」という並び替え戦略を導入することです。私たちはブロックを確認し、すべての取引（テイク）を処理する前にすべてのキャンセル取引（キャンセル）を処理します。

この戦略はSolana上で即座に実施可能で、現在のリプレイ並び替えをリーダーによって決定されるモデルから、キャンセルを優先的に処理する戦略に変更するだけです。しかし、これだけでは問題を根本的に解決することはできません。もし単一のリーダーが制御を続けるなら、彼はキャンセル取引を無視することを選択できるため、私たちは再び出発点に戻ります --- --- マーケットメーカーは依然としてキャンセル競争において不利な立場にあります。

この問題を解決する唯一の方法は、複数の並行リーダー（Concurrent Leaders）を導入することです。こうすれば、あるリーダーがキャンセル取引を遮断しても、別のリーダーに提出することができます。

実現 --- 取引並び替え

複数の並行リーダーに関して、皆さんが最も疑問に思うのは、衝突が発生した場合、どのように各自の取引ブロックを統合するのかということです。答えは実際には非常にシンプルです：手数料を2つのカテゴリに分けます：包含手数料（inclusion fee）と並び替え手数料（ordering fee）。包含手数料はその取引を含む検証者に支払われ、並び替え手数料はプロトコルに支払われ（破棄されます）。各リーダーのブロックを統合する際には、特定のスロット内のすべてのブロックのすべての取引の和集合を取り、その並び替え手数料に基づいて並び替えて実行します。

この措置だけでは不十分です。私たちが本当に実現したいのは、アプリケーションが取引並び替えをより柔軟に制御できるようにすることです。もう一つの要素は、`gettransactionmetadata` システムコールで、これによりプログラムは相互作用する取引の並び替え手数料を読み取ることができ、アプリケーションに強力な並び替え制御ツールを提供します。

実現 --- コンセンサスメカニズム

私たちのコンセンサスメカニズムの設計目標には以下が含まれます：

1. バインディングとブラインディング（Binding \& Blinding）：並行リーダーは、自分のブロックに他のリーダーのブロックの情報（例えば、プライベート取引を挟むこと）を含めることはできず、他のリーダーのブロックの内容に基づいて自分のブロックをキャンセルすることもできません（例えば、他の入札を見た後に自分の入札をキャンセルすること）。

2. 時計の公平性（Wallclock Fairness）：並行リーダーは、大体同じ実際の時間内にブロックを提出しなければなりません。

以下は、私たちがa16z ResearchのPranav GarimidiとJoachim Neuと協力して開発した最も効果的な方案の概要です：

1. 各リーダーはそのブロックをエラー訂正コードの断片（shreds）に変換します。十分な数（符号率を超える）の断片が復元されると、ブロックを復元できます。部分的な復元は不可能です。

2. リーダーは断片をTurbineツリーの第一層の中継ノードに送信します。各リーダーはその最初の断片を中継1に、2番目の断片を中継2に、というように送信します。すべてが順調に進めば、各中継はすべてのリーダーからの断片を受け取ります。

3. タイムアウト後、中継は単一のコンセンサスリーダーに署名済みのIHAVEメッセージを送信し、受け取った断片を通知します。

4. コンセンサスリーダーは、そのIHAVEメッセージを含むブロックを構築します；十分な割合のIHAVEメッセージが含まれていない場合、そのブロックは無効になります。

5. コンセンサスリーダーはそのブロックを検証者にブロードキャストし、検証者はそのブロックについて合意を形成し始めます。

この方案は、高い確率でバインディングとブラインディングの特性を満たし、良好な時計の公平性を持っていますが、将来的にはさらに優れた方案が現れる可能性があります。

結論

Solanaの創設目標はナスダックを超えることです。これを実現するためには、ナスダックよりも良い価格を提供しなければなりません。これを実現するためには、アプリケーションに取引前にキャンセル操作を優先的に並び替える能力を与えなければなりません。この能力をアプリケーションに与えるためには、リーダーが一方的に注文を審査することを防がなければなりません。そしてこれを実現するためには、複数の並行リーダーを導入する必要があります。