SundaeSwapが、カルダノのDeFiエコシステムのバックボーンとしての、レイヤー１で最高のソリューションとなるScooper Model (AMM-Orderbook)を発表しています。
この記事ではSundaeSwapのプロトコルアーキテクチャとそこに至るまでの道のりを明らかにしています。また、新しいソリューションのそのストレステストも行なっており、驚くべき結果をもたらしています。
エポックな日々でもこの記事に触れていますので、ご参考ください。
以下はSundaeSwap Labsに掲載された記事「SundaeSwap Labs Presents: The Scooper Model」を翻訳したものです。
SundaeSwap Labs Presents: スクーパーモデル
By SundaeSwap Labs 2021年11月5日
ウォーリー教授プレゼンツ “スクーパーモデル”
ここ数週間、カルダノのスケーラビリティについて多くの情報が飛び交っています。私たちはIOGがスケーラビリティのために行ったトレードオフについて記事を書き、いくつかのプロジェクトはこれらのトレードオフを相殺するためのアーキテクチャソリューションについて投稿しました。SundaeSwapがパブリックテストネットとその後のローンチに近づいている今、私たちのプロトコルアーキテクチャとそこに至るまでの道のりを明らかにする良い機会だと考えました。
いくつかのソリューションを徹底的に評価しましたが、その中にはカルダノのエコシステムの中で議論されているものと似ているものもあります。それぞれのプロトコルには、優先すべき基準やトレードオフがありますが、多くのアプローチには少なくとも1つの重大な欠陥があり、最終的にはそれらを拒否することになりました。
この記事の最初のセクションでは、提案されたソリューションのひとつひとつを、私たちの内部評価と同じように深く掘り下げて紹介することは難しい（そして面白くない）ので、ソリューションとその評価に用いた基準を5万フィートの高さから見たものを紹介します。
その後のセクションでは、それぞれのプロトコルがどのように機能するのかを簡単に説明し、SundaeSwapプロトコルのソリューションとして失格となった致命的な欠陥は何かを考えます。
最後に、この記事の残りの部分で、私たちが採用したソリューションと、プロトコルを拡張するための今後の継続的な研究へのヒントについて説明します。
概要
SundaeSwapチームは、様々なソリューションを評価するために膨大な労力を費やしてきました。前述の通り、それぞれの検討内容を詳細に説明するには時間がかかりすぎますが、少なくとも評価の結果得られたハイレベルな機能マトリックスを提供したいと考えました。
網羅的ではありませんが、上位のソリューションに社内でつけた名前を挙げてみます。
- Uniswap Clone ：ホワイトペーパーに書かれているように、Uniswapのロジックをカルダノに直接移植する（主に比較のため）。
- Open Batching：誰でもプールに対してスワップのリクエストを集約できるようにする。
- Tokenized Escrows：市場の検閲を防ぐために、ステートチャネルトークンを発行する。
- Mixed Escrows：オーダーフローを保証するためのステートチャネルトークンと、スケーラビリティを確保するためのオープンオーダーのハイブリッド。
- プログラム可能なオーダーブック：プログラム可能な基準を持つフルオーダーブックモデル。
最終的には、Governed Scoopersと呼ぶソリューションに決定し、この記事の最後のセクションで説明しています。
私たちは、前述の各ソリューションの選択肢を、少なくとも以下の基準で評価しました。
- スケーラビリティー ：そのプロトコルはどれくらいの数のユーザーやトランザクションを持続的にサポートできるか？
- 競合 ：エンドユーザーがどのくらいの頻度でトランザクションを再提出しなければならないか？
- Miner Extractable Value (MEV) ： 市場操作に対してプロトコルがどの程度脆弱か？
- 非中央集権：単一の当事者によって停止されることに対するプロトコルの堅牢性は？
- Denial of Service（サービス拒否） ：サービス拒否攻撃に対するプロトコルの堅牢性はどの程度ですか？
- Volume Independence ：プロトコルが有用であるためにはどの程度のボリュームが必要ですか？
- 開発努力 ：実装するのにどれだけの努力が必要か？どのくらいの表面積を監査する必要があるか？
そして、私たちの意見では、各デザインがどのように評価されたかを紹介します。
視覚的にわかりやすいように、各デザインをランク付けしたチャートを用意しました。(注：これらのランキングはあくまでも意見であり、100％の事実ではありません。)
却下されたソリューション
このセクションでは、上記の各ソリューションがどのように機能することを意図していたのか、また、私たちが構築したいプロトコルに適していない致命的な欠陥であると考えられるものについて説明します。
これらのソリューションの中には、他のプロジェクトが提案したソリューションに似ているものもありますが、私たちの意図は彼らの仕事を軽視することではありません。それぞれがトレードオフの関係にあり、SundaeSwapに適したソリューションではないからといって、優先順位付けの基準や目的が異なるプロトコルに有効なニッチを埋められないということではありません。
Open Batching：オープンバッチング
私たちが評価した最初のソリューションは、最初のホワイトペーパーの初期ドラフトにも登場した、Open Batching（オープンバッチング）でした。このソリューションでは、ユーザーは注文内容を記載したスクリプトに自分の資金をロックします。
「Xトークンを少なくともYトークンと交換してください。このスクリプトによって、資金は流動性プールに対するスワップの一部として使われたり、キャンセルされたりします。次に、ある第三者がこれらの取引を「バッチ」して1つの取引に集約します。この1つの取引は、ロックされた各注文をプールの流動性を保持するUTXOとともに「消費」し、その結果得られた取引を元のユーザーに戻します。
これらのバッチボット間の争いは、エンドユーザには感じられないので許容され、注文を含むトランザクションが受理されるたびにプロトコル全体が進歩します。私たちは、プロトコルのテーマであるアイスクリームにちなんで、トランザクションのアグリゲータの役割を「Scooper」という言葉で表現するようになりました。
このソリューションは、Minswapが提案したLaminarと呼ばれるソリューションに最もよく似ていますが、コミュニティに参加されている方は、Laminarをご存知でしょうか？
Open Batchingには、私たちが維持しようとした多くの重要な特性があります。特に、エンドユーザーには競合がなく、スクーパにのみ競合があり、他のプロトコルとのコンポーザブル化も容易です。
悪意のあるスクーパーは、0個または1個の注文を含む取引を実行し、その間に他の注文の実行を遅らせるというサービス拒否攻撃を受けやすいという欠点があります。競合するアクターのエコシステムでは、これは問題ないかもしれません。しかし、このように1つの取引を送信すると、ネットワークに伝播する前に取引IDを取得し、次の取引を構築して送信する際に有利になります。洗練された攻撃者は、このようなトランザクションの長いチェーンをネットワークにスパムし、将来のブロックのためのメンプールに簡単に受け入れることができます。この攻撃は、私たちが「トリクル」攻撃と呼んでいるものですが、非常に安価に実行でき、深く取引されている市場を完全に停止させることができます。
もう1つの欠点は、マイナーによる価値の引き出しに対する脆弱性が非常に高いということだと思います。エコシステムが成長し、人々がカスタムスクーパーアプリケーションを構築すると、どの取引を含めるかを選択する側が利益を得られるような方法で、市場を非難したり並べ替えたりすることができます。例えば、大量の買い注文を処理して価格を上昇させた後、自分のウォレットから1つの売り注文を処理し、その後、大量の売り注文を処理して価格を下降させるという「サンドイッチ攻撃」という概念があります。この攻撃は逆に実行することも可能です。miner extractable value」については、こちらの記事が参考になります。
この攻撃を緩和するには、いくつかの方法があります。決定論的な順序を強制する、バッチ取引の順序に依存しないようにする、あるいは多くの競合するアグリゲータを用意するなどです。しかし、いずれの場合も、サンドウィッチ攻撃を実行するのはかなり簡単なことです。例えば、多くの競合するアグリゲーターがいる場合でも、サンドイッチ攻撃を実行することができます。なぜなら、誠実なアクターは、あなたが価格を押し上げてもすぐには価格が下がらないような買い注文と売り注文を混在させている可能性が高いからです。
SundaeSwapプロトコルは、カルダノ上のDeFiのバックボーンとなることを目指しているため、これらのリスクは、このソリューションの他の望ましい特性を圧倒するのに十分でした。
Escrow Tokens：エスクロー・トークン
私たちが評価した次のソリューションは、最初のソリューションを単純に拡張したもので、かなり長い間、高い信頼を得ていました。ユーザーが注文を待つために「使う」スクリプトにいくつかのトークンを発行することで、プールは立会人に必要なトークンの数を知ることができます。これにより、市場からの攻撃を防ぐことができました。スワップ計算を注文に依存しないようにする方法と組み合わせることで、MEVはすべて解消されました。ユーザーは「空」のエスクロー・トークンに資金を費やし、それが次のバッチに含まれることになります。間違ったエスクローを選択してしまったユーザーの間で争いが起こるかもしれませんが、十分な数のエスクローがあれば、このようなことは稀であり、オンラインでのクレジットカード取引を時々やり直さなければならないのと同じような経験ができるでしょう。
このソリューションは、Meld社が提案しているソリューションに最も似ており、彼らは「リザーブ・トークン」について言及しています。
興味のある方は、エスクロー・トークンはSundaeSwapプロトコルに含まれており、7月下旬に非公開でVCに見せ始めたデモにも含まれていましたし、CCV Danのチャンネルでの公開デモイベントでも紹介されました。
残念ながら、このソリューションはカルダノ・ブロックチェーンのサイズ制限に真っ向からぶつかります。上述の議論の確率的性質は、何百ものエスクロー・トークンに依存しており、実際のところ、我々の最初の実装では、ガバナンスなどの機能を追加する前に、5～6個のエスクロー・トークンでカルダノ・プロトコルの限界に達していました。
さらに、エスクロー・トークンを不正な注文で占拠することは非常に安価で容易であり、大部分の正当なトラフィックに対して事実上のサービス拒否を引き起こすことになります。
最後に、スクーパートークンとエスクロートークンの間で競合が発生し、優れたスケーラビリティ特性の多くが破壊されてしまいます。
前のセクションと同様に、同時実行性を高めてトリクル攻撃を防ぐために検討した拡張機能の1つが、フェイシングという概念です。エスクロー・トークンを長方形のグリッドに配置し、プールで列全体を一度に処理させるのです。ユーザーが扱うトークンの数が多くなるので、競合が発生する可能性が低くなり、トリクルアタックの機会も少なくなります。
最終的には、カルダノのトランザクション制限のためにこの方法で得られる利益はわずかなものであり、ソリューションの複雑さが増大していることから、この方法をやめて、より単純なトレードオフを探した方が良いと考えました。
Mixed Escrows：エスクロー
しかし、エスクロー・トークンを完全に排除する前に、私たちは最後の拡張機能を検討しました。それは、トークンを持つエスクローとトークンのないエスクローの混在です。トークンを使用する注文と使用しない注文を混在させることで、ユーザーが注文を受けるまで再試行することを厭わない場合、基本的な保証された注文フローを提供することができ、同時にカジュアルなユーザーには任意の同時実行を可能にしました。
残念ながら、これは「すべてのエスクロー・トークン」のソリューションと同じサービス拒否の脆弱性があります。カルダノ・トランザクションのリソース制限と、急速に近づいている開発スケジュールの下では、発売までにプロトコルに関する魅力的で公正かつ安全なインセンティブを提供することができないと感じたため、このアプローチを断念しました。
このアプローチは、将来的にカルダノのトランザクション制限が変更されたり、サービス拒否を防ぐための適切なインセンティブ構造を徹底的に検討するための時間ができたときに、再検討する可能性があります。
Mixed Escrows：プログラム可能なオーダーブック
私たちが検討したもう1つのアイデアは、完全かつ設定可能なオーダーブックという概念です。このモデルでは、ユーザーは自分の資金を、特定の価格での取引、ドルコストアベレージなどの注文基準をコード化したスクリプトに固定します。このアプローチの主な特徴は、マーケットメイカーが存在しないことです。市場参加者は互いに完全に独立して活動します。
これは、Maladex社のソリューションに最も似ていると思われます。
一見して、このアプローチには、私たちにとって魅力的な特性がいくつもありました。
- 注文を出すための競争がない
- プログラム可能
- コンポーザビリティ
これらの利点については、Maladexの論文によく書かれているので、ここでは蒸し返さないことにします。しかし、このモデルを検討していくうちに、いくつかの問題点が見えてきました。ほとんどすべての問題は、秩序ある執行を保証するマーケットメーカーが存在しないことに起因しています。大まかに言うと、それらの問題点は以下の通りです。
- 流動性を効率的に利用できない
- 大量の注文に対応できない
- ブロックチェーンの混雑
- 注文の侵食
- マーケットデプスの要求
- 手数料市場
Inefficient use of liquidity：流動性の非効率な利用
アリス、ボブ、キャロルが市場に様々な量の流動性を提供している次の例を考えてみましょう。JackとJillは共にその市場に対してスワップを実行したいと考えています。そしてこの例では、市場はJackとJillの両方の注文を満たすのに十分な流動性を持っています。しかし、両方の注文を確実に満たすことができるマーケットメーカーとは異なり、純粋なオーダーブックでは、注文が満たされるかどうかは、JackとJillがどのオファーにマッチしようとするかによります。
ジャックの注文は大きいので、自分の注文を満たすのに十分な流動性を得るためには、複数の注文と照合しなければなりません。ジルは小さい注文を持っているので、1つの注文に対してフィルすることができます。上記の例では、両当事者がボブの注文をマッチング取引に含めることを決定します。そして、残念ながら、どちらか一方の注文（この場合はジルの注文）だけが満たされます。しかし、ジャックはアリスとキャロルに対して自分のトランザクションを再提出することはできないのでしょうか？はい、でもこれは次の問題につながります。
Difficulty with larger orders：大口注文の難しさ
ジャックはもちろん、異なるUTXOのセットを使って取引を再送信します。しかし、次の取引でも同じ問題に直面します。この例では、ジャックは少数のUTXOと照合しようとしているため、彼の取引は次の回でも成立する可能性があります。しかし、これは純粋なオーダーブックの一般的な問題を示している。注文のサイズが大きくなると、その注文を照合できる可能性は指数関数的に減少します。
ジャックが非常に大きなスワップを持っていて、それを満たすために他の12件の注文が必要だったとします。その12個の注文のそれぞれに、他の人がその注文にマッチしようとしている可能性があります。ジャックのスワップが満たされるためには、ジャックは12のレースすべてに勝たなければなりません。どのレースでも、ジャックには均等な確率で勝てるはずです。しかし、12レースすべてに勝つのは、かなり難しいことです。
Blockchain congestion：ブロックチェーンの混雑
ジャックには2つの解決策があります。(a)自分の注文を多くの小さな注文に分割する、または(b)一致する注文を見つけて必要な注文数を減らすことを試みる。ジャックが注文を分割しようとすると、次の問題である「ブロックチェーンの混雑」が発生します。
つまり、ジャックは1つの注文を満たすために12のトランザクションを必要とする代わりに、それぞれが1つの注文に対してマッチする12の注文を作成することができます。その場合、次のような問題が発生します。
- 手数料：1つの取引に対して支払う代わりに、ジャックは12の取引に対して支払うことになります。そして、無料™であるRobinhoodのトレードとは異なり、ブロックチェーン上のスワップにはコストがかかります。
- ネットワークの混雑：これは設定可能ですが、現在、1つのトランザクションの最大サイズは16k、1ブロックの最大サイズは64kです。ブロックチェーン上で12倍の注文を満たそうとすると（各注文にはバリデータ・スクリプトのフルコピーが必要）、コミュニティ全体のエクスペリエンスを著しく悪化させることになります。また、ポストヒドラの世界であっても、この12倍の容量損失は大きな影響を与えるでしょう。
ですから、もし注文を分けることが問題になるのであれば、ジャックは逆に、より少ない数の大きな注文を相手にすることができるかもしれません。これが次の問題、「オーダー・エロージョン」につながります。
Order erosion：オーダー・エロージョン
注文を分割することは、現在では多くのデメリットがあるため（Hydraでは少ない）、ジャックは自分の大きな注文を他の大きな注文とマッチさせようとするかもしれません。ここでの問題は、他の多くの大口注文が同じことをしようとすることです。ジャックにとっては、自分が出している注文よりも大きい（あるいは見つけられれば同じ大きさの）注文を見つけることが利益になります。
この行動をコミュニティ全体に掛け合わせると、大きな流動性のオファーは、パーシャルフィルによって小さな流動性のオファーにすぐに侵食されることが予想されます。つまり、一部の参加者は自分の大口注文を他の大口注文と照合することができますが、ほとんどの参加者はできないということです。
Market Depth Requirement：市場の深さの要件
次の問題は、マーケットメーカーがそもそも存在した理由である、取引量の少ない市場に流動性を提供することです。十分な数の注文（流動性）がある市場では、ビッドとオファーを容易にマッチングさせることができるため、参加者にとって市場は流動的に見えます（例：NASDAQ）。
しかし、市場の流動性が低下すると、成立させることができる注文数が減少し、注文が成立しないレベルになります。この時点で、市場は本質的に流動性のない状態となり、ビッドとオファーの間に大幅なスプレッドが発生し、結果的にマッチングされる追加トレードの数が大幅に減少します。スプレッドが大きいと、取引を成立させるために一方の当事者が劣悪なオファーを受け入れざるを得なくなるため、取引が成立しなくなります。
マーケットメーカーは、常に取引を受けることを提案することでこの問題を解決しています。ビッドとアスクがある場合、オファーはその2つの間になる可能性が高いですが、さらに重要なことは、マーケットメーカーはビッドやアスクがない場合でも取引を行うことで、市場参加者が常に市場に出入りできるようにすることです。
分散型取引所のプールの多くは、取引量が少ない。例えば、Uniswapは8,000以上の取引ペアを持っています。取引量でプールをランキングして30位を調べると、1時間に数回しか取引されていません。そのため、AMMのサポートを受けない純粋なオーダーブックは適合性が低いと感じました。
Fee Market：手数料市場
最後の問題は、注文をどのように執行するかということです。執行には2つの基本的なモデルがあり、（a）注文の提出者が注文を執行する、（b）他の人に注文の執行を許可する、というものです。
発注者が注文を執行する場合、発注者は注文が満たされるまで実行されるオフチェーンの注文執行者を管理する必要があります。これはかなりハードルが高く、ほとんどの市場参加者がやりたがらないと思います。
そこで可能性が高いのが、2つ目のケースである「他の人が注文を執行できる」というものです。他者が注文を執行するわけですから、発注者は彼らに注文を執行するインセンティブを与え、彼らが公正に注文を執行することを信頼しなければなりません。一方、注文執行者は、受け取った価値を最大化することを第一に、異なる動機を持っていると思われます。受け取る価値を最大化する一つの方法は、最も高いインセンティブを提供する注文を優先することです。他の注文よりも早く約定させたいという注文は、より高いインセンティブを含んでおり、それゆえに手数料市場が誕生するのです。そして、手数料市場には、上記のようなマイナーによる価値の抽出やサンドイッチ攻撃があります。
この問題やその他の問題を解決するために、私たちはハイブリッドAMMオーダーブックという解決策を提案します。
この問題やその他の問題を解決することで、今回のソリューションであるハイブリッドAMM Orderbookを発売することになりました。
私たちのソリューション Scooper Model (AMM-Orderbook)
最後に、私たちが今回採用したソリューションをご紹介します。このソリューションは、上述のオーダーブックのポジティブな特性の多くを維持しつつ、カルダノブロックチェーン上で早期に主要なDEXを立ち上げるために重要と思われるいくつかの基準については妥協していないと考えています。
社内では、このソリューションを「Scooper Model/AMM Orderbook」と呼んでいます。
インセンティブを調整し、セルフガバナンスのシステムを構築することで、プロトコルの信頼性を高め、システムを拡張することができます。
純粋なオーダーブックのように、市場参加者は、キャンセルされるまで有効な注文をブロックチェーン上に出すことができます。この注文は既存のエンティティとのやり取りを必要としないため、他のプロトコル設計におけるUTXOのコンテンション問題に悩まされることはありません。プログラム可能なAPIを使用することで、これらの注文は市場参加者の要望に合わせて調整することができます。しかし、純粋なオーダーブックとは異なり、流動性プールは、自動化されたマーケットメーカーが実現するスワップの秩序ある効率的な実行に依存することができます。
前述のプロトコルと同様に、サードパーティのアグリゲータに依存しています。この記事はかなり長くなるので、これらのサードパーティアグリゲータの特性を少し思い出してみる価値があります。
社内では、テーマの好きな会社として、これらのアクターを「スクーパー」と呼んでいます。スクーパーは、自動化されたマーケットメーカーに対して多くのスワップを実行するトランザクションを構築して送信し、その見返りとして少額のADA手数料を徴収します。詳しくは上述の通りですが、自動売買マーケットメーカーのスクリプトのルールを守っていても、この役は桁違いの力を持っています。
しかし、アグリゲーターに限定的な信頼を何とか確立できれば、上記の各プロトコルにおける課題の多くが消えます。アグリゲーターがどの注文を含めるかを一貫して公正に選択することを信頼できれば、例えばエスクロー・トークンはもう必要ありません。競合のないオンランプと、プロトコルの互換性に集中することができます。
では、どのようにしてスクーパが誠実であることを保証するのでしょうか？
最初のステップは、コミュニティの信頼できるメンバーを選んで運営することです。カルダノは恵まれた環境にあり、そのための評判と実績を持つ多様な参加者がすでに存在しています。したがって、ISOのパートナーとなるステークプールを選択するのと同様に、（コミュニティの協力を得て）これらのスクーパを運営するステークプールも選択する予定です。
本日、ステークプール運営者向けに、ISOへの参加とSandaeSwapスクーパーの運営を申し込むためのサインアップフォームを送信する予定です。ソーシャルメディアでの存在感や経験などの簡単な基準に基づいてこのリストをフィルタリングした後、私たちはコミュニティの皆さんに物事を委ねます。最初のスクーパーを選ぶために、1週間の投票を行う予定です。
SundaeSwap DEXでは、上記のステークプール運営者に30日間のスクーパーライセンスを付与し、SundaeSwapコミュニティからのスワップを構築・集約するために使用します。これを行うたびに、ADAの取引手数料がスクリプトにロックされます。
一定期間後、これらのスクーパはライセンスを更新しなければならず、その際に取引手数料を請求します。
しかし、スクーパの1人が悪質な行為者であるとガバナンスが（投票によって）決定した場合、そのライセンスは取り消され、ADAトランザクション料金はプロトコルによって国庫に送られます。
例えば、誰かが「注文選択アルゴリズム」のリファレンス実装を実行し、その結果をIPFSで公開して誰でも見ることができるようにします。ネットワークの状態によっては、スクーパの間でこのアルゴリズムにわずかなズレが生じることもありますが、スクーパが一貫して大幅にズレている場合は、投票によってライセンスを取り消し、ADAの取引手数料と、そもそもの悪行の動機となった市場へのアクセスを拒否することができます。
このように、集めたADA報酬が重要なものであると仮定すると、スクーパーは、それらの報酬を請求するために正直であり続けるように強く動機づけられます。収集されたADA報酬が少なければ、市場は取引量が少なく、彼らが市場から引き出せる価値の量も少なすぎて、悪い行動に必要な労力を合理的に正当化できません。
時間が経てば、DAOはこのシステムをよりダイナミックな選挙構造でアップグレードし、スンデトークンがADAと同様の役割を果たし、アグリゲーターのセットを選択し、その後に報酬や罰を与えるようになると見ています。これは慎重に行われる必要がありますが、その成長はプロトコル全体の成長とよく一致しています。
ベンチマーク
この記事の公開を長らく延期していた理由の一つは、領収書を提出したかったからです。つまり、私たちのプロトコルの大規模な負荷テストを実施したかったのです。このようにして、スループットの理論的な上限を確立し、平均的なスループットを推測することができました。
参考までに、比較対象としてUniswap v3プロトコルを選びました。
11月の最初の数日間のUniswap v3ルーターコントラクトを含むトランザクションをEtherscanに照会すると、次のようになります。
- 11/01/21-24,477 トランザクション
- 11/02/21-27,961 トランザクション
- 11/03/21-28,203 トランザクション
これは、1日あたり平均26,880件、1分あたり約18.66件の取引があったことになります。2020年8月にUniswapが1日に10万件のトランザクションを広告していたことを考えると、これらのトップレベルのトランザクションの多くは複数の操作を表している可能性が高いので、そのスループットは1分あたり70トランザクションに近いかもしれません。DEXの構築に重点を置いていた私たちにとって、これは十分な近似値であり、正確な数字を得るために深く掘り下げることはしませんでした。
ある程度、これはりんごとオレンジの比較です。私たちは、理論上のピーク時のスループットと彼らの1日の平均値を比較しています。しかし、重要なのは、Uniswapが解決できなかった問題を我々が解決したということではありません。Uniswapの人気と我々の旅の比較的初期の段階を考慮すると、この比較は、次の10億人のユーザーと1秒間に10万回のトランザクションに向けて構築する間、妥当なトランザクションのスループットをサポートするチャンスがあるかどうかを判断するためのものです。そして、その結果は非常に有望であると感じています。
とはいえ、以下の結果はトラフィックの少ないテストネットでの理想的な条件であることに留意してください。他のプロトコルとネットワーク帯域を共有しているため、実際のスループットは低くなり、レイヤー2ソリューションへの移行がいかに重要であるかを示しています。私たちの願いは、このソリューションが現在の市場のニーズに応え、豊かで活発なエコシステムを構築し、レイヤー2にスケールアップしていく中で、SundaeSwapプロトコルがさらに中心的な役割を果たすための舞台を整えることです。
今日は、2つの主要なテストを行いました。どちらのテストも市場操作を可能な限り高速に実行し、1000回の操作を処理した後に停止しました。
1つ目のテストは、当社のプライベートな開発者向けテストネットで実施しました。IOGとの間で進められているトランザクションの制限やプロトコルのパラメータに関する議論の一環として、トランザクションのサイズがプロトコルに与える影響を調査しました。そこで、ブロックのCPUとメモリの制限値を大幅に引き上げ、制限要因がトランザクションサイズになるようにし、さらにトランザクションサイズの制限値を16kbから18kbに、トランザクションメモリの制限値を1,000万ユニットから3,000万ユニットに引き上げました。
これらのパラメータでは、1000回のスワップをすべて8分で実行することができ、1分あたりの平均スループットは120回となりました。これは、上記のUniswapの見積もりである70トランザクション/分の170%にあたります。このケースは楽観的ですが、カルダノ全体の上昇成長の可能性の一端を示しています。
次に、IOGがAlonzo Purpleのメモリ制限を1,000万個から3,000万個に増やした後、そこでも同じ負荷テストを行いました。このような悲観的な条件では、1000回の操作の平均スループットは43回/分となり、ユニスワップの高い見積もりの約60%を達成しました。
これはまた、カルダノプロトコルの実際のパフォーマンスと可能性について、興味深い洞察を与えてくれます。IOGは、当然のことながら、様々な取引の上限について保守的になっています。しかし、現在のブロックサイズと彼らの研究で引用された数字を比較すると、このブロックサイズは最大で32倍の大きさまで増加する可能性があります。実際にテストをしたわけではありませんが、ちょっとした計算では、この条件での最大スループットは1,300～3,800トランザクション/分となります。レイヤー1のソリューションとしては驚異的です。また、改善可能な点はそれだけではありません。これはカルダノのエキサイティングな未来を物語っています。
最後に、このプロトコルの優れた点は、エンドユーザーが『ゼロコンテンション（コンテンション：通信回線やネットワークにおける送信制御の方式の一つで、送信権を「早いもの勝ち」で獲得する方式）』に直面したことです。ネットワークが極端に混雑している場合を除いて、注文のキューイングが失敗することは極めて稀であるはずですが、これはユーザーにとっては最悪の体験です。このように、極端な負荷がかかった場合でも、注文の待ち時間が長くなることはあっても、すべてのユーザーが途切れることなくサービスを享受することができます。
他のプロトコルとネットワーク容量を共有しなければならない可能性が高いことから、混雑のピーク時の実際の数値はこれよりも低くなると思われますので、期待はしないようにしたいと思います。
レイヤー1のDEXは、決済流動性の重要な供給源として機能し、カルダノのエコシステムにおける非常に重要な需要を早い段階で満たすことになります。しかし、リテールトラフィックの大部分は、最終的には、より安価で高速、かつスケーラブルなレイヤー2のソリューションに引き寄せられるでしょう。
P.S. 詳細を知りたい方のために、Cardanoscanエクスプローラへのリンクを含むサマリーレポートと、負荷テストに関連するすべてのトランザクションのリストを公開しました。今後も、注目度の高い負荷テストや実験の結果をこのリポジトリで公開していきます。
おわりに
この記事では、私たちがどのようにプロトコルの設計を考えてきたか、また、いくつかのソリューションを公正かつ客観的に評価するために行ってきた慎重な取り組みについて、有益な洞察を得ていただければ幸いです。私たちは、SundaeSwap DEXの立ち上げに非常に興奮しており、初期のカルダノエコシステムの要求に応える私たちのプロトコルの能力に自信を持っています。
この先数週間は非常に厳しい状況が続くため、まだ具体的な日程を決めることはできませんが、ごく近い将来に予定していることは以下の通りです。
ステークプール運営者の選考を開始するために、Googleフォームを公開し、ステイクプール運営者が応募できるようにします。以前にメールでお問い合わせいただいた方は、正式なフォームが公開されてからご応募いただくことになりますが、念のため、フォームへのリンクをメールでお送りします。UPDATE: ISOのSPOへの応募はこちらから
公開テストネットを開始します。公開テストネットが開始されると、スケーリングソリューションの動作を確認できるだけでなく、プロトコルのストレステストに協力したり、気づかなかったバグを発見したり、SundaeSwapの最初のユーザーになることができます。
監査が終了すると、お客様からいただいたフィードバックに対応します。
そして、メインネットプロトコルとそれに伴うISOを発表します。DAOを起動している間、最初のコミュニティ投票が成功するまで、ベータラベルを維持します。
数週間後には、私たちが過去数ヶ月にわたって構築してきたものを披露する準備が整います。皆さんが私たちと同じように興奮してくれることを願っています。
~SundaeSwapラボチーム
