Delphi Digital：私たちがSei Networkに期待する理由は？

執筆：Delphi Digital

編纂：Babywhale，Foresight News

1月4日、暗号通貨取引所MEXCは、Sei Networkの重点プロジェクトの発展を支援するために2000万ドルの特別基金を立ち上げることを発表しました。そして、8月31日にはSei Labsが500万ドルのシードラウンドの資金調達を完了したことを発表し、Multicoin Capitalが主導し、Coinbase Ventures、GSR、Flow Traders、Hudson River Trading、Delphi Digital、Tangentなどが参加しました。公式に資金調達が完了した1か月後、Sei Networkは5000万ドルのエコシステムファンドを立ち上げ、同ネットワーク上で開発されるDeFiアプリケーションを支援しました。

Sei Networkの投資者の一つであるDelphi Digitalは、Sei Networkに期待する理由を説明するレポートを作成しました。筆者はここでそのレポートの重要な内容をまとめ、皆さんと共に議論するための参考にします。

DeFiのために設計されたネットワーク

ブロックチェーンを構築する際、通常はそれを2つの異なる種類に分類しようとします：汎用チェーンまたはアプリケーションチェーン。汎用チェーンは許可のない革新に使用され、アプリケーションチェーンは許可が必要な特定のユースケースに使用されます。しかし、「アプリケーションチェーン」は白黒はっきりしたものではなく、チェーン自体が決定します。Seiは、DeFiのために設計されたLayer 1ブロックチェーンを目指す、今後登場するCosmosエコシステムチェーンです。

「DeFiのために設計された」ということは、DeFiアプリケーションが繁栄できるように、基盤層に根本的な変更（およびトレードオフ）を加えることを意味します。Seiは、内蔵の注文マッチングエンジン、ミリ秒単位の決済速度、注文の並行処理、単一ブロックでの注文実行などを備えています。これらのカスタマイズされた機能はすべて基盤層で実現されています。SeiはDEXではなく、DeFiに最適化されたLayer 1ブロックチェーンです。同時に、Seiは単なるアプリケーションチェーンではなく、THORChainのようにクロスチェーン交換にのみ焦点を当てた「純粋な」アプリケーションチェーンではなく、DEX、契約、先物などの製品の特性に合わせて開発されたブロックチェーンです。

なぜ基盤ネットワークでこれらの変更を行いたいのかを理解するために、SerumとSolanaを見てみましょう。Solanaは汎用のLayer 1ブロックチェーンで、「オンチェーンのナスダック」として宣伝されており、400ミリ秒のブロック確認時間と非常に高いスループットを目指しています。Solanaの主な見解は、注文書取引プラットフォームが最終的にAMMを引き継ぐというものであり、Solana上の指標もこの見解を支持しています。SerumはSolana上に構築された注文書アプリケーションで、Solanaエコシステムで最も使用されているアプリケーションであり、Solana上の取引の約1/3を占めています。SerumはSolana上の「注文書層」であり、Mango Markets、Zeta、Atrix、Bonfida、Jupiterなどのプロジェクトが利用しています。人々がSolanaを思い浮かべるとき、通常はSerumを思い浮かべます。

しかし、このアーキテクチャにはいくつかの欠点もあり、最も注目すべきは、Solanaが汎用チェーンであるため、Serum（およびその上に構築されたアプリケーション）が他のアプリケーションとリソースを競争し続けることです。Serumとは関係のない活動、例えばゲームやNFTの鋳造は、チェーン上の混雑を引き起こし、以前に経験したSolanaのいくつかの「停止」のような事態を招きます。Seiは「足りないところを削る」ことを選択し、すべての非DeFi活動を彼らのチェーンから切り離しました。簡単に言えば、SeiはSerumが自分のLayer 1ブロックチェーンを立ち上げたようなものであり、具体的なトレードオフを行い、基盤層をDeFiに最適化し、その上に構築されたDeFiアプリケーションに非DeFiのアプリケーションに対して「不公平な優位性」を与えています。

ここでの主なトレードオフは、SeiはSolanaのように許可なしで運営されることはなく、アプリケーションを開発するためにはガバナンスを通じてホワイトリストを取得する必要があるということです。許可なしの革新から得られるいくつかの利点を失いますが、より最適化された環境を作り出すことができます。ネイティブの注文マッチングエンジン、価格オラクル、並行注文実行、単一ブロックでの注文実行は、Seiがインフラストラクチャレベルで構築したものの一部です。Seiはアプリケーションチェーンですが、Seiのチェーン上の注文書は、Sei上のCosmWasmアプリケーション間で同期的なコンポーザビリティを可能にし、ネイティブの注文マッチングエンジンを通じて流動性を共有するコンポーザブルなアーキテクチャを作り出しています。IBCをサポートするCosmosチェーンとして、元々非同期のコンポーザビリティを持っています。

SeiはABCI++を通じていくつかの最適化を実現しました。ABCI++は、CosmosのABCIに対するアップグレードであり、合意の各ステップがプログラム可能になります。SeiはABCI++を使用して、ブロック生成の最適化、スマートブロックブロードキャスト、注文の並行実行の3つの改善を試みています。

ABCI++を使用してSeiを最適化

注文書取引に特化する場合、ブロック生成時間、取引決済、遅延はマーケットメーカーにとって最も重要です。マーケットメーカーは各ブロックで価格を更新する必要があるため、短いブロック時間はブロック間の価格差を小さくし、スプレッドを小さくし、マーケットメーカーが負担するリスクを小さくします。数百ミリ秒を超える時間は受け入れがたい（長期的には数百ミリ秒でも高すぎる可能性があります）。標準的なCosmosチェーンは約6秒のブロック確認時間を持っており、これにより注文書は最適解ではありません。しかし、Cosmosの魅力はそのカスタマイズ性にあり、Seiは合意を最適化し、できるだけ速くするための変更に焦点を当てています（目標は約300-600ms）。Seiの3つの主要な重点分野は：

ブロック生成の最適化、スマートブロックブロードキャスト、注文の並行実行です。

SeiはABCI++を活用してこれを実現しています。ABCIはアプリケーションと合意の間のインターフェースであり、その主な役割は合意によって決定されたブロックを実行することです。ABCIを使用すると、アプリケーションは意思決定時に合意と対話するだけで済み、mempoolからどの取引を選択するかについてはほとんど制御権を持ちません。ABCI++は合意の各ステップにプログラム可能性を追加し、アプリケーションが取引を再配置、変更、放棄、遅延、または追加することを可能にし、最適化を導入することでブロック生成時間を短縮する能力を提供します。

合意の提案ステップの後、アプリケーションはブロック処理の最適化を開始でき、事前投票（pre-vote）および事前委託（pre-commit）段階と並行して行われます。次に、Seiは「最適化を通じて」状態変更を一時的な候補状態に移行し、合意に受け入れられるまで待ちます。受け入れられない場合（非常に稀）、ブロックは放棄されます。このステップでは、大量のデータを処理する必要があり、かなり遅くなる可能性があります。しかし、最適化された状態変化処理を通じて、出力時間を短縮し、遅延を大幅に減少させることができます（約300msの削減）。

ブロック生成の最適化に加えて、Seiはブロック情報のブロードキャストの改善にも取り組んでいます。Tendermintでは、バリデーターがブロックを提案すると、そのブロックにはすべての取引の詳細が含まれ、データ量が非常に大きくなりますが、バリデーターはすでにローカルのmempoolからこれらの取引の約99.9%を取得しているため、再度ブロック提案者からこれらのデータを受け取る必要はありません。すべての詳細を送信する代わりに、提案者は現在、ブロック内の各取引のハッシュ値を送信するだけで済み、バリデーターは自分のローカルmempoolを使用してブロックを迅速に再構築できます。

Seiはこれらの2つの最適化を「Twin-Turbo Consensus」と名付け、これらの最適化（ブロック生成の最適化とスマートブロックブロードキャスト）を実施することでスループットが83%向上したと述べています。

ブロック生成プロセスの3つ目の最適化は、取引実行に関するものです。ABCIを使用するCosmosチェーンの取引処理は順番に実行され、このプロセスでは、どの市場で取引が行われても個別に処理され、スループットを大幅に妨げます。また、負荷が増加するにつれて、遅延も倍増します。並行処理を使用することで、重複しない独立した市場を同時に処理できます。市場Aの取引の後に市場Bの最初の取引を処理するのではなく、同時に処理する方が良いです。特定の市場内の取引は、確実性を避けるために順番に処理する必要があります。異なるバリデーターが同じ状態に対して異なる結果を得ると、確実性が失われます（例えば、あるバリデーターがユーザーBの前にユーザーAの注文を処理しますが、別のバリデーターはAの前にBの注文を処理し、ユーザーの決済価格に矛盾が生じます）。

Seiは並行化に関するいくつかの負荷テストを行い（バリデーターのホスティングも行いました）、出力時間、遅延、スループットの改善を観察しました。一般的に、並行処理を通じて、ブロック時間を順番処理に比べて75-90%短縮でき、並行の遅延は40-120ms、順番の遅延は200-1370msです。1万件の注文/ブロックと20の異なる契約（市場）がある場合、並行処理は出力時間を1.33秒から0.81秒に、遅延を371msから48msに、スループットを7500件/秒から12200件/秒に短縮できます。すべての負荷レベル（注文/ブロック）で明らかな改善が見られ、負荷量が増加するにつれて、限界の最適化程度が大きくなります。

上記の3つの主要な改善に加えて、Seiは基盤層に他の機能も追加しています。例えば：

ネイティブの価格オラクル。基盤層にオラクルを構築し、バリデーターはブロックを生成する際に価格に合意する必要があります。バリデーターが価格に合意するまで、ブロックは生成されません。他のモジュールがチェーン上の市場から信頼できる価格情報を取得できるようにします。

単一ブロックでの注文実行。単一のブロック内での注文と実行を可能にします（Serumでは複数のブロックが必要です）。

注文バンドル。マーケットメーカーは、1回の取引で複数の市場の価格を更新できます。

頻繁なバッチオークション。ブロック終了時に市場の注文を集約し、単一の価格で清算します；目的は、先行取引を最小限に抑えることです。

ソフトウェア面での改善に加えて、Seiはより小さなバリデーター構造とより高いハードウェア要件をテストしています。分散化の面で妥協があるものの、これらは顕著な性能向上を伴い、再びCosmosの独自性、すなわちカスタマイズ性を強調しています。

高性能ハードウェア構成のバリデーターを使用

Seiプロジェクト文書の最初のバージョンでは、推奨される仕様は標準的なCosmosチェーンに似ていました。その後、ハードウェアの要件が引き上げられ、特定の負荷テストではさらに引き上げられました。注文書モデルはハードウェアに対する要求が高く、低性能のマシンはネットワーク全体の性能を低下させます。Solanaレベルの要求ではありませんが、Seiはバリデーターが一般的なブロックチェーンを超えることを望んでいることを明確に示しています。また、バリデーターの地理的位置の集中化を推進し、遅延をさらに減少させることを目指しています。

なぜホスティングを行うのか？バリデーターが地理的に分散している場合、情報の伝達に時間がかかり、合意に達しブロックを生成する際に遅延が増加します。注文書取引プラットフォームは、遅延をできるだけ減らす必要があります。Seiは再び、ホスティングに関するいくつかのテスト結果を発表しました：

1. 地理的に分散した場合と比較して、ホスティングは約46%の遅延を削減できます。

2. 50のバリデーターは許容できる遅延の限界です。

すべてのバリデーターが同じ地理的地域にいることには明らかな利点と欠点がありますが、性能の向上は無視できません。Seiがメインネットを立ち上げる際、彼らはこのような集中した小規模なバリデーターのセットに向かう可能性が高いです。以下のグラフでは、p50/p75/p95は、x%のリクエストが特定の値よりも早くなる確率を示しています。例えば、p50は50%のリクエストがこのテストのp50値よりも早くなることを意味します。したがって、p95は95%のリクエストがp95値よりも早くなることを意味します。

まとめ

Delphi Digitalのレポートにはエコシステム、トークンなどの内容も含まれていますが、この記事ではそれを省略し、Sei Networkの技術的およびメカニズムの革新のみを示しました。Seiは並行処理やブロックブロードキャストなどの面で革新を行い、ネットワークの取引確認速度を向上させました。しかし一方で、Seiは高性能ハードウェア構成のバリデーターを必要とし、これらのバリデーターが地理的に相対的に集中している必要があります。これにより、注文書モデル取引プラットフォームのサポートレベルをさらに満たすことができます。Delphiはレポートの中でこのアプローチの集中化問題を認めていますが、性能向上は無視できないと述べています。

筆者は、文中で述べられているように、Cosmosエコシステムのアプリケーションチェーンのカスタマイズ性は非常に高く、Web3がブロックチェーンをどのようなイデオロギーで提示すべきかは十分に包容的であるべきだと考えています。私たちは高い分散化を持つプロジェクトを支持することも、効率のために一部の分散化を犠牲にしたプロジェクトを受け入れることもできます。しかし、Sei Networkが本当に「速い」とされるかどうかは、メインネットの立ち上げ後に実際のデータで答えを出す必要があります。