オリジナル編集: Babywhale、Foresight News
オリジナル編集: Babywhale、Foresight News
1月4日、仮想通貨取引所MEXCは、聖ネットワークの主要プロジェクトの開発を支援するために2,000万米ドルの特別基金の立ち上げを発表した。そして8月31日には、セイ研究所はそれが完了したと発表した。500万ドルのシードラウンド, Multicoin Capitalが投資を主導し、参加投資家にはCoinbase Ventures、GSR、Flow Traders、Hudson River Trading、Delphi Digital、Tangentなどが名を連ねた。資金調達完了の正式発表から1ヵ月後、聖ネットワークは発足5000万ドルのエコファンド、その上で開発されたDeFiアプリケーションをサポートします。
Delphi Digital は Sei Network の投資家の 1 人として、sei Network について楽観的である理由を説明するレポートを作成し、全員で議論できるようにレポートの主要な内容を要約しています。
DeFi向けに設計されたネットワーク
ブロックチェーンを構築するとき、私たちは通常、ブロックチェーンをユニバーサル チェーンとアプリケーション チェーンという 2 つの異なるカテゴリに分類しようとします。ユニバーサル チェーンは許可のないイノベーション用であり、アプリケーション チェーンは許可が必要な特定のユースケース用です。ただし、「アプリケーション チェーン」は白か黒かではなく、チェーン自体によって決まります。 Sei は、「DeFi 用に設計された」レイヤー 1 ブロックチェーンを目指す、今後の Cosmos エコロジカル チェーンです。
「DeFi向けに設計」とは、DeFiアプリケーションの成功を可能にする基本的な変更（およびトレードオフ）をベースレイヤーに行うことを意味します。 Sei には、注文マッチング エンジン、1 秒未満の決済速度、注文の並列処理、単一ブロック注文の実行などが組み込まれています。これらのカスタマイズされた機能はすべて基本層で実行されます。知っておく必要があるのは、sei は DEX ではなく、DeFi に最適化されたレイヤー 1 ブロックチェーンであるということです。同時に、seiはTHORChainのようなクロスチェーン交換のみに焦点を当てた「純粋な」アプリケーションチェーンとは異なり、純粋なアプリケーションチェーンではなく、DEX、契約、先物などの商品の特性に合わせて開発されたブロックチェーンです。
基盤となるネットワークにこれらの変更を加える必要がある理由を理解するには、Serum と Solana を見てみましょう。 Solana は、400 ミリ秒のブロック確認時間と非常に高いスループットを目標とする「オンチェーン ナスダック」として宣伝されている汎用レイヤー 1 ブロックチェーンです。 Solana の主なポイントは、オーダーブック取引プラットフォームが最終的には AMM に取って代わるということであり、Solana の指標はこの点を裏付けています。 Serum は、Solana 上に構築された注文帳アプリケーションであり、Solana エコシステムで最も使用されているアプリケーションであり、Solana 上のトランザクションの約 1/3 を占めています。 Serum は Solana の上にある「オーダーブック レイヤー」で、Mango Markets、Zeta、Atrix、Bonfida、Jupiter などのプロジェクトで使用されています。ソラナについて考えるとき、人々は通常セラムを思い浮かべます。
ただし、このアーキテクチャにはいくつかの欠点があります。最も顕著なのは、Solana が汎用チェーンであるため、Serum (およびその上に構築されたアプリケーション) が他のアプリケーションとリソースを求めて常に競合していることです。以前に Solana のいくつかの「停止」で経験したように、ゲームや NFT の鋳造など、Serum に関係のないアクティビティはチェーンの輻輳を引き起こす可能性があります。 Sei は「足を切って靴を合わせる」ことを選択し、DeFi 以外のアクティビティをすべてチェーンから切り離しました。簡単に説明すると、seiはSerumが独自のレイヤー1ブロックチェーンを立ち上げることに相当し、特定のトレードオフを行い、ベースレイヤーをDeFi向けに最適化し、その上に構築されたDeFiアプリケーションに非DeFiアプリケーションの「不当な優位性」を与えるというものだ。
ここでの主なトレードオフは、sei でアプリケーションを開発するにはガバナンスによるホワイトリストが必要なため、sei は Solana のようにパーミッションレスではないことです。パーミッションレスなイノベーションに伴う利点の一部は失われますが、より最適な環境を構築することはできます。ネイティブ注文マッチング エンジン、価格オラクル、並列注文実行、および単一ブロック注文実行は、sei がインフラストラクチャ レベルで構築するものの一部です。 Sei はアプリケーション チェーンですが、sei のオンチェーン オーダー ブックは、sei 上の CosmWasm アプリケーション間の同期コンポーザビリティを可能にし、ネイティブ注文マッチング エンジンを通じて流動性を共有するコンポーザブル アーキテクチャを作成します。 IBC 対応の Cosmos チェーンとして、本質的に非同期に構成可能です。
Sei は、コンセンサスのあらゆるステップをプログラム可能にする Cosmos の ABCI の今後のアップグレードである ABCI++ を通じて最適化の一部を実装しました。 Sei は、ABCI++ で 3 つの改善を試みてきました。最適化されたブロック生成、スマート ブロック ブロードキャスト、および注文の並列実行です。
ABCI++ による Sei の最適化
最適化されたブロック生産、スマートブロックブロードキャスト、注文の並行実行。
最適化されたブロック生産、スマートブロックブロードキャスト、注文の並行実行。
Sei は ABCI++ を利用してこれを実現します。 ABCI はアプリケーションとコンセンサスの間のインターフェイスであり、その主な役割はコンセンサスによって決定されたブロックを実行することです。 ABCI を使用すると、アプリケーションは意思決定時にのみコンセンサスと対話し、メモリプールからどのトランザクションを選択するかをほとんど制御できません。 ABCI++ は、コンセンサスのすべてのステップにプログラマビリティを追加し、アプリケーションでトランザクションの並べ替え、変更、破棄、遅延、または追加を可能にするだけでなく、ブロック生成を最適化する機能を導入することでブロック生成時間を短縮します。
コンセンサスの提案ステップの後、アプリケーションは事前投票および事前コミットフェーズと並行して、処理ブロックの最適化を開始できます。次に、セイは、コンセンサスで受け入れられるまで、州を一時的な候補州に変更するための「最適化」を開始します。受け入れられない場合 (非常にまれですが)、ブロックは破棄されます。このステップでは、処理するデータが大量にあるため、処理が非常に遅くなる可能性があります。しかし、状態変更の処理を最適化することで、ブロックの生成時間を短縮し、レイテンシーを大幅に短縮することができます (約 300 ミリ秒の短縮)。
Sei はブロック生成の最適化に加えて、ブロック情報のブロードキャストも改善しています。 Tendermint では、検証者がブロックを提案すると、このブロックにはすべてのトランザクションの詳細が含まれ、データ量は非常に多くなりますが、検証者はローカル メモリプールを通じてこれらのトランザクションの約 99.9% を取得しているため、ブロック提案者からこのデータを再度受信するまで待つ必要があります。すべての詳細を送信する代わりに、提案者はブロック内の各トランザクションのハッシュを送信するだけで済み、バリデーターは独自のローカル メモリプールを使用してブロックを迅速に再構築できるようになります。
Sei 氏は 2 つの最適化を「ツイン ターボ コンセンサス」と名付け、それら (最適化されたブロック生成とスマート ブロック ブロードキャスト) を実装することでスループットが 83% 向上したと述べました。
ブロック生成プロセスの 3 番目の最適化は、トランザクションの実行を中心に展開されます。 ABCIを用いたCosmosチェーンのトランザクション処理はシーケンシャルに実行されるため、マーケットに関係なくトランザクションが1件ずつ処理されるため、スループットに大きな支障をきたします。負荷が増加すると、レイテンシーも指数関数的に増加します。並列処理を使用すると、重複しない独立した市場を同時に処理できます。マーケット A での取引の後にマーケット B で最初の取引を処理するのではなく、これらを同時に処理する方がよいでしょう。特定の市場内のトランザクションは、非決定性を回避するために依然として処理する必要があります。非決定性は、2 つの異なるバリデーターが同じ状態に対して異なる結果を取得する場合に発生します (例: 1 つのバリデーターがユーザー B ユーザー A の注文の前に処理されるが、別のバリデーターがユーザー B の注文を処理する) A の前に、ユーザーの決済価格が競合する原因となります）。
Sei は並列化に関するいくつかの作業を行いました負荷テスト(バリデーターも共同ホストします) ブロック時間、レイテンシー、スループットの点でどのような改善が得られるかを確認します。一般に、並列実行によるブロック時間は、逐次処理と比較して 75 ～ 90% 削減でき、並列レイテンシは 40 ～ 120 ミリ秒、逐次レイテンシは 200 ～ 1370 ミリ秒になります。 10,000 注文/ブロックおよび 20 の異なるコントラクト (市場) では、並列処理によりブロック時間を 1.33 秒から 0.81 秒に、レイテンシーを 371 ミリ秒から 48 ミリ秒に、スループットを 7,500 注文/秒から 12,200 注文/秒に短縮できました。すべての負荷レベル (順序/ブロック) にわたって大幅な改善が見られ、負荷が増加するにつれて限界最適化が大きくなります。
上記の 3 つの主要な改善に加えて、sei はベース レイヤーに次のような他の機能も追加します。
ネイティブ価格のオラクル。基本層でオラクルを構築します。バリデーターは、ブロックを生成するときに価格に同意する必要があります。ブロックはバリデーターが価格に同意するまで作成されません。他のモジュールがオンチェーン市場から信頼できる価格情報を取得できるようにします。
単一ブロック注文の実行。単一のブロックで注文と実行が可能になります (Serum に複数のブロックが必要です)。
バンドルを注文します。マーケットメーカーは、1 回の取引で複数の市場の価格を更新できます。
頻繁に行われるロットオークション。成行注文は、単一価格で清算するためにブロックの最後に集約できます。目的は、フロントランニングを最小限に抑えることです。
ソフトウェアの改善に加えて、sei はより小さなバリデータ構造とより高いハードウェア要件もテストしてきました。分散化に関してはトレードオフがありますが、パフォーマンスの大幅な向上がもたらされ、Cosmos のユニークな点であるカスタマイズ性が改めて強調されます。
高性能のハードウェア構成検証ツールを使用する
Sei プロジェクト ドキュメントの最初のバージョンでは、推奨仕様は標準の Cosmos チェーンと同様です。その後、ハードウェア要件が引き上げられ、特定の負荷テストでは要件がさらに引き上げられました。オーダーブック モデルにはハードウェア要件が高く、マシンのパフォーマンスが低いとネットワーク全体のパフォーマンスが低下します。 Solana レベルの要件ではありませんが、sei はバリデーターが一般的なブロックチェーンよりも優れたパフォーマンスを発揮することを望んでいることを明確にしています。さらに、待ち時間をさらに短縮するために、バリデーターの地理的な集中化を推進しています。
なぜホスティングをするのか?バリデーターが地理的に分散している場合、情報の伝達に時間がかかり、合意に達してブロックを生成するまでの待ち時間が長くなります。オーダーブック取引プラットフォームは、遅延を可能な限り最小限に抑える必要があります。 Sei は、ホスティングに関するテスト結果の一部を再度投稿しました。
1. コロケーションにより、地理的分散と比較して遅延が約 46% 削減されます。
2. 50 個のバリデータが、許容可能なレイテンシの制限です。
要約する
要約する
Delphi Digital のレポートには生態やトークンなども含まれていますが、この記事では一時的に省略され、sei Network の技術とメカニズムの革新のみが示されています。 Sei は並列処理とブロックブロードキャストの革新を行い、ネットワークトランザクション確認の速度を向上させたことがわかりますが、その一方で、sei は高性能なハードウェア構成を備えたバリデーターと、それらのバリデーターの地理的な位置を必要としています。オーダーブックモデル取引プラットフォームのサポートをさらに満足させるために一元化されたDelphiは、レポートの中でソリューションの一元化の問題も認めているが、それでもパフォーマンスの向上は無視できないと述べた。
著者は、記事で述べたように、Cosmos のエコロジカル アプリケーション チェーンは非常にカスタマイズ可能であり、Web3 はブロックチェーンのイデオロギーに対して十分寛容であるべきであり、高度な分散化を実現したプロジェクトをサポートできると考えています。効率化のための分散化も容認されます。ただし、sei Network が言うほど「高速」であるかどうかは、メインネットの稼働後に実際のデータを使用して答えを出す必要があります。
