トランザクション専用に設計された並列処理ブロックチェーンであるSei Networkは、今年8月にトークンとメインネットを立ち上げました。 市場を熱狂させた後、Sei Labsの創設者であるJayendra Jog氏は最近、Sei v2のリリースを発表しました。 このアップデートにより、EVMが統合され、並列処理メカニズムが最適化され、台帳ストレージ構造が強化されます。
目次
Sei Networkとは?
Sei:トランザクションのために生まれました
Sei 並列処理機構
Sei v2 の更新方向
仮想マシン:EVM サポート
オリジナルデザイン: Sei v1 は CosmWasm 仮想マシンを使用
アップデートの焦点:Sei v2がEVMサポートを統合
Sei並列処理機構の最適化
元の設計: Sei v1 では、コントラクトに定義されたリソース スコープが必要です
アップデートの焦点:Sei v2がコントラクトの並列実行メカニズムを簡素化
台帳のストレージ構造の最適化:SeiDB
元の設計: Sei v1 は大量の状態データを格納します
アップデートの焦点:Sei v2が台帳構造を分離
コンセンサスメカニズム
Sei はトレードオフを通じて最前線で競争します
Sei Networkとは?
Sei:トランザクションのために生まれました
Sei Networkは明確な市場ポジショニングを持っており、仮想資産の取引に効率的な環境を提供しています。 仮想資産には、一般的なトークンに加えて、NFT、ソーシャルグラフ、ゲームアイテムが含まれ、トランザクション専用の基盤環境を提供することで、最高のユーザーエクスペリエンスを生み出すことを目的としています。
仮想資産取引には多くの種類があります(ソース)
取引は暗号通貨に限定されないため、仮想資産の取引はオンラインの世界で最も広く普及している需要です。 チームは、最も成功するWeb3アプリケーションには取引属性が関係していると考えています。
したがって、トランザクションの需要がなくなることはなく、Web3の将来における重要なリンクです。 最適なトランザクションネットワークのポジショニングを完了するためには、高効率な環境を提供する必要があり、Seiはこの目標を達成するためにパラチェーン処理設計とコンセンサスメカニズムを使用しています。
Sei Networkのメインネットは3ヶ月以上前からオンラインになっています。 公式データによると、ネットワークは現在平均20,000TPSで、最終確認時間は390ミリ秒です。 チームは、革新的な並列処理メカニズムのおかげで、業界で最も効率的なネットワークであると主張しています。
Seiブロックチェーン上のトランザクションが同じリソース(アドレス)を伴わない場合、トランザクションシーケンスを注文することなく、すべてのトランザクションを同時に処理できます。 これにより、ネットワーク運用効率が大幅に向上します。
ブロックチェーンプロジェクトを見るとき、台帳構造、コンセンサスメカニズム、仮想マシンの3つの主要な評価ポイントがあります。 Sei独自の並列処理メカニズムと相まって、今回のSei v2のアップデートの違いがよくわかります。
Sei Network v2の主なアップデート (出典)
創設者のJayendra氏は、Sei v2は新機能を追加するだけで、既存の機能には影響しないと述べています。 ユーザーと開発者は、この更新プログラムのために追加の操作を実行する必要はありません。
Sei v2 の提案には、主に 3 つの更新が含まれています。
この更新は、2024 年第 1 四半期に完了する予定です。
Sei は Cosmos SDK を使用してビルドされ、後者が提供するコンポーネントである CosmWasm 仮想マシンを使用します。 CosmWasm は、Cosmos エコシステム用に特別に構築された仮想マシン コンポーネントです。 基盤となるレイヤーは WebAssembly (Wasm) で、それにちなんで名付けられています。 Cosmos SDK を使用して構築されたブロックチェーンは、既存のロジックを調整することなく、CosmWasm をチェーンに追加できます。
WebAssemblyは、Rust、C、C++など、さまざまな一般的なプログラミング言語をサポートできるため、Rust開発者であれば、CosmWasmでスマートコントラクトを簡単に作成できるため、Seiはサークル外の開発者を引き付けます。
しかし、Sei Labsチームは、開発者のエンゲージメントが高いにもかかわらず、イーサリアム仮想マシン(EVM)のエコシステムを失っていることに気づきました。 EVM は、既存のほとんどの産業用アプリケーションや製品で使用されている仮想マシンです。 このエコシステムを失うと、既存のイーサリアムプロジェクトがSeiエコシステムに分岐できないなど、現段階でのSeiの急速な発展を妨げる可能性があります。
これに対処するために、チームは専用のコードリポジトリであるCore Sei Binaryを更新し、EVM RPCおよびGethノード用の専用インターフェイスを導入しました。 これにより、EVMトランザクションをシームレスに展開し、Seiネットワークと対話することができます。
ゲスを選んだのは、その相対的な安定性に基づいていました。 Jayendra Jog氏は、現在、イーサリアムノードの80%がGethを使用しており、EVMバイトコードの完全な互換性をサポートしていると述べました。 つまり、開発者は他のEVMからコントラクトを複製し、Seiネットワーク上でシームレスに実行することができます。
Sei Network v2の主なアップデート内容 (出典)
Sei v2はEVM RPCも使用するため、ユーザーはMetamaskなどのウォレット操作を簡単に使用でき、開発者はFoundry、Remix、Hardhatなどのツールを引き続き使用できます。
したがって、Sei v2 は EVM トランザクションと Cosmwasm トランザクション間のコンポーザビリティを可能にします。 Sei の Geth には Cosmwasm コントラクトを呼び出すことができるプリコンパイラがあり、Sei の wasmd モジュールは EVM コントラクトを逆に呼び出すこともできるため、Sei のエコシステム内の資産の価値が高まります。
オリジナルのSei Networkでは、トランザクションを並行して処理するために、開発者は「コントラクトのリソース使用量をマークする」方法を学ぶ必要がありました。 開発者が Sei でコントラクトを作成する場合、コントラクトがアクセスする必要がある可能性のあるリソースとその独立性を定義する必要があります。 これは、Seiが契約を実行する際にリソースの独立性を迅速に区別し、トランザクションを並行して処理するか、特定の順序で処理するかを決定するために重要です。
コントラクトの並列実行を可能にするには、開発者は、実行中に必要なリソース (コントラクトのクエリを含む) を特定する必要があります。 次に、リソーススコープをJSON形式でチェーンに書き込む必要があります。 これにより、開発者に不注意な課題が発生し、エントリのしきい値とセキュリティ上の懸念が高まります。
Sei v2 では、並列処理メカニズムが最適化され、開発者が依存関係を手動で定義する必要がなくなります。 代わりに、並列化メカニズムを単独で処理できるため、開発者の負担が軽減されます。
新しい並列処理メカニズムは、すべてのトランザクションを統一された方法で実行します。 リソースの競合が見つかった場合、ネットワークはシーケンスを再検査して再実行します。
Sei v2 はリソースの重複の問題を自動的に処理します (ソース)
トランザクションに異なるアカウントが含まれる場合 (たとえば、Alice が Bob に送金し、Carol が Dave に送金する場合)、依存関係が重複しないため、トランザクションは並行して処理されます。トランザクションに同じアカウントが含まれる場合 (たとえば、Alice と Bob の両方が Carol に送金する場合)、順番に再実行する必要があります。
ただし、この設計には懸念がある場合があります。 最悪のシナリオが発生した場合は、すべてのトランザクションに相関関係が伴い、順番に再実行する必要があります。 これらのトランザクションを再実行すると、最初に順番に実行した場合と比較して、実行時間が30%長くなります。
幸いなことに、イーサリアムの過去のデータによると、実際にリソースが重複し、順番に再処理する必要があるトランザクションは約15%しかないため、チームはSeiの全体的なパフォーマンスが大幅に向上すると評価しました。
しかし、SeiはIAVLツリー全体を分散型台帳に永続的に保存するという別の問題に直面しています。 迅速なファイナリティと並列処理設計により、グローバルな状態変化を頻繁に記録する必要があり、ネットワーク台帳全体のサイズが大幅に増加します。
並列処理のコストは、多くの無効な中間状態データを記録することです。 例えば、Seiチームが提案した RFC によると、atlantic-2テストネットノードでは、保存されている25GBのデータのうち、意味のあるトランザクション情報が含まれているのは10GBだけです。 これにより、ノードのディスク領域の使用が非効率的になります。
データのインフレにより、Sei ノードのディスク使用量が急速に増加します。 atlantic-2 のアーカイブ ノードのハード ディスク使用量は、1 日あたり 150 GB 以上増加し、1 週間あたり 1 TB を超えています。 チェーンの状態が成長し続けると、ストレージスペースの成長率も増加します(速くなります)。
それは多くの問題を引き起こします:
将来の v2 ラウンドトリップ処理と再検証の並列処理設計と相まって、ネットワーク全体のステータスがより頻繁に変更され、ステータス データの量が大幅に増加します。
また、Sei v2は、上記の問題を解決するために最適化されたストレージメカニズムを備えており、状態データの拡張を防ぎ、すべてのノードによるデータ読み取りの速度を向上させます。
Sei v2 は、状態ストレージ台帳を SeiDB と呼ばれる 2 つのタイプに分割します。
SeiDBの改良により、検証ノードはSC台帳情報を記録するだけでよく、完全な状態情報はSS層によって記録され、リアルタイム送信を必要とせずに先に先書きログに送信が入れられるため、ブロック生成に影響を与えないため、状態を非同期で保存してパフォーマンスを向上させることができます。
Sei v2 は、検証ノードでのデータ増加の負担を軽減します (ソース)
SeiDBの改良により、Seiはパフォーマンスのさまざまな側面で強化されています。 これには、ブロック送信時間の 100 倍の増加、毎日のデータ生成の 100 GB から 5 GB への圧縮、同期情報を必要とするすべてのノードまたはノードのキャッチアップ時間の 10 倍の改善が含まれます。
Sei Network v2は、当初のコンセンサスメカニズムを変更せず、ツインターボの設計を維持し続けています。 CosmosコンセンサスインターフェースTendermint ABCIの拡張により、ブロック確認時間を大幅に短縮しました。
Sei v2では、EVM仮想マシンが導入され、並列処理と分散型台帳ストレージメカニズムが改善されています。 目標は、開発者、ノード、およびユーザーのユーザーエクスペリエンスを向上させ、それによって生態学的影響を高めることです。
しかし、3ヶ月間の運用では、Seiの並列トランザクションはTPSを向上させ、ファイナリティを高速化する一方で、そのトレードオフとして状態データ量が増加し、ノードのハードウェア要件が高くなることが観察されました。 チームは、台帳構造を分離し、効率のために分散化をいくらか犠牲にすることで妥協しました。
全体として、他のイーサリアムキラーと比較して、前述のアップデートを効果的に実装することができれば、Seiはトップティアの競争に参加する機会があります。 来年のチームアップデートの結果を見るのを楽しみにしています。
(注:この記事は投資アドバイスではありません。
トランザクション専用に設計された並列処理ブロックチェーンであるSei Networkは、今年8月にトークンとメインネットを立ち上げました。 市場を熱狂させた後、Sei Labsの創設者であるJayendra Jog氏は最近、Sei v2のリリースを発表しました。 このアップデートにより、EVMが統合され、並列処理メカニズムが最適化され、台帳ストレージ構造が強化されます。
目次
Sei Networkとは?
Sei:トランザクションのために生まれました
Sei 並列処理機構
Sei v2 の更新方向
仮想マシン:EVM サポート
オリジナルデザイン: Sei v1 は CosmWasm 仮想マシンを使用
アップデートの焦点:Sei v2がEVMサポートを統合
Sei並列処理機構の最適化
元の設計: Sei v1 では、コントラクトに定義されたリソース スコープが必要です
アップデートの焦点:Sei v2がコントラクトの並列実行メカニズムを簡素化
台帳のストレージ構造の最適化:SeiDB
元の設計: Sei v1 は大量の状態データを格納します
アップデートの焦点:Sei v2が台帳構造を分離
コンセンサスメカニズム
Sei はトレードオフを通じて最前線で競争します
Sei Networkとは?
Sei:トランザクションのために生まれました
Sei Networkは明確な市場ポジショニングを持っており、仮想資産の取引に効率的な環境を提供しています。 仮想資産には、一般的なトークンに加えて、NFT、ソーシャルグラフ、ゲームアイテムが含まれ、トランザクション専用の基盤環境を提供することで、最高のユーザーエクスペリエンスを生み出すことを目的としています。
仮想資産取引には多くの種類があります(ソース)
取引は暗号通貨に限定されないため、仮想資産の取引はオンラインの世界で最も広く普及している需要です。 チームは、最も成功するWeb3アプリケーションには取引属性が関係していると考えています。
したがって、トランザクションの需要がなくなることはなく、Web3の将来における重要なリンクです。 最適なトランザクションネットワークのポジショニングを完了するためには、高効率な環境を提供する必要があり、Seiはこの目標を達成するためにパラチェーン処理設計とコンセンサスメカニズムを使用しています。
Sei Networkのメインネットは3ヶ月以上前からオンラインになっています。 公式データによると、ネットワークは現在平均20,000TPSで、最終確認時間は390ミリ秒です。 チームは、革新的な並列処理メカニズムのおかげで、業界で最も効率的なネットワークであると主張しています。
Seiブロックチェーン上のトランザクションが同じリソース(アドレス)を伴わない場合、トランザクションシーケンスを注文することなく、すべてのトランザクションを同時に処理できます。 これにより、ネットワーク運用効率が大幅に向上します。
ブロックチェーンプロジェクトを見るとき、台帳構造、コンセンサスメカニズム、仮想マシンの3つの主要な評価ポイントがあります。 Sei独自の並列処理メカニズムと相まって、今回のSei v2のアップデートの違いがよくわかります。
Sei Network v2の主なアップデート (出典)
創設者のJayendra氏は、Sei v2は新機能を追加するだけで、既存の機能には影響しないと述べています。 ユーザーと開発者は、この更新プログラムのために追加の操作を実行する必要はありません。
Sei v2 の提案には、主に 3 つの更新が含まれています。
この更新は、2024 年第 1 四半期に完了する予定です。
Sei は Cosmos SDK を使用してビルドされ、後者が提供するコンポーネントである CosmWasm 仮想マシンを使用します。 CosmWasm は、Cosmos エコシステム用に特別に構築された仮想マシン コンポーネントです。 基盤となるレイヤーは WebAssembly (Wasm) で、それにちなんで名付けられています。 Cosmos SDK を使用して構築されたブロックチェーンは、既存のロジックを調整することなく、CosmWasm をチェーンに追加できます。
WebAssemblyは、Rust、C、C++など、さまざまな一般的なプログラミング言語をサポートできるため、Rust開発者であれば、CosmWasmでスマートコントラクトを簡単に作成できるため、Seiはサークル外の開発者を引き付けます。
しかし、Sei Labsチームは、開発者のエンゲージメントが高いにもかかわらず、イーサリアム仮想マシン(EVM)のエコシステムを失っていることに気づきました。 EVM は、既存のほとんどの産業用アプリケーションや製品で使用されている仮想マシンです。 このエコシステムを失うと、既存のイーサリアムプロジェクトがSeiエコシステムに分岐できないなど、現段階でのSeiの急速な発展を妨げる可能性があります。
これに対処するために、チームは専用のコードリポジトリであるCore Sei Binaryを更新し、EVM RPCおよびGethノード用の専用インターフェイスを導入しました。 これにより、EVMトランザクションをシームレスに展開し、Seiネットワークと対話することができます。
ゲスを選んだのは、その相対的な安定性に基づいていました。 Jayendra Jog氏は、現在、イーサリアムノードの80%がGethを使用しており、EVMバイトコードの完全な互換性をサポートしていると述べました。 つまり、開発者は他のEVMからコントラクトを複製し、Seiネットワーク上でシームレスに実行することができます。
Sei Network v2の主なアップデート内容 (出典)
Sei v2はEVM RPCも使用するため、ユーザーはMetamaskなどのウォレット操作を簡単に使用でき、開発者はFoundry、Remix、Hardhatなどのツールを引き続き使用できます。
したがって、Sei v2 は EVM トランザクションと Cosmwasm トランザクション間のコンポーザビリティを可能にします。 Sei の Geth には Cosmwasm コントラクトを呼び出すことができるプリコンパイラがあり、Sei の wasmd モジュールは EVM コントラクトを逆に呼び出すこともできるため、Sei のエコシステム内の資産の価値が高まります。
オリジナルのSei Networkでは、トランザクションを並行して処理するために、開発者は「コントラクトのリソース使用量をマークする」方法を学ぶ必要がありました。 開発者が Sei でコントラクトを作成する場合、コントラクトがアクセスする必要がある可能性のあるリソースとその独立性を定義する必要があります。 これは、Seiが契約を実行する際にリソースの独立性を迅速に区別し、トランザクションを並行して処理するか、特定の順序で処理するかを決定するために重要です。
コントラクトの並列実行を可能にするには、開発者は、実行中に必要なリソース (コントラクトのクエリを含む) を特定する必要があります。 次に、リソーススコープをJSON形式でチェーンに書き込む必要があります。 これにより、開発者に不注意な課題が発生し、エントリのしきい値とセキュリティ上の懸念が高まります。
Sei v2 では、並列処理メカニズムが最適化され、開発者が依存関係を手動で定義する必要がなくなります。 代わりに、並列化メカニズムを単独で処理できるため、開発者の負担が軽減されます。
新しい並列処理メカニズムは、すべてのトランザクションを統一された方法で実行します。 リソースの競合が見つかった場合、ネットワークはシーケンスを再検査して再実行します。
Sei v2 はリソースの重複の問題を自動的に処理します (ソース)
トランザクションに異なるアカウントが含まれる場合 (たとえば、Alice が Bob に送金し、Carol が Dave に送金する場合)、依存関係が重複しないため、トランザクションは並行して処理されます。トランザクションに同じアカウントが含まれる場合 (たとえば、Alice と Bob の両方が Carol に送金する場合)、順番に再実行する必要があります。
ただし、この設計には懸念がある場合があります。 最悪のシナリオが発生した場合は、すべてのトランザクションに相関関係が伴い、順番に再実行する必要があります。 これらのトランザクションを再実行すると、最初に順番に実行した場合と比較して、実行時間が30%長くなります。
幸いなことに、イーサリアムの過去のデータによると、実際にリソースが重複し、順番に再処理する必要があるトランザクションは約15%しかないため、チームはSeiの全体的なパフォーマンスが大幅に向上すると評価しました。
しかし、SeiはIAVLツリー全体を分散型台帳に永続的に保存するという別の問題に直面しています。 迅速なファイナリティと並列処理設計により、グローバルな状態変化を頻繁に記録する必要があり、ネットワーク台帳全体のサイズが大幅に増加します。
並列処理のコストは、多くの無効な中間状態データを記録することです。 例えば、Seiチームが提案した RFC によると、atlantic-2テストネットノードでは、保存されている25GBのデータのうち、意味のあるトランザクション情報が含まれているのは10GBだけです。 これにより、ノードのディスク領域の使用が非効率的になります。
データのインフレにより、Sei ノードのディスク使用量が急速に増加します。 atlantic-2 のアーカイブ ノードのハード ディスク使用量は、1 日あたり 150 GB 以上増加し、1 週間あたり 1 TB を超えています。 チェーンの状態が成長し続けると、ストレージスペースの成長率も増加します(速くなります)。
それは多くの問題を引き起こします:
将来の v2 ラウンドトリップ処理と再検証の並列処理設計と相まって、ネットワーク全体のステータスがより頻繁に変更され、ステータス データの量が大幅に増加します。
また、Sei v2は、上記の問題を解決するために最適化されたストレージメカニズムを備えており、状態データの拡張を防ぎ、すべてのノードによるデータ読み取りの速度を向上させます。
Sei v2 は、状態ストレージ台帳を SeiDB と呼ばれる 2 つのタイプに分割します。
SeiDBの改良により、検証ノードはSC台帳情報を記録するだけでよく、完全な状態情報はSS層によって記録され、リアルタイム送信を必要とせずに先に先書きログに送信が入れられるため、ブロック生成に影響を与えないため、状態を非同期で保存してパフォーマンスを向上させることができます。
Sei v2 は、検証ノードでのデータ増加の負担を軽減します (ソース)
SeiDBの改良により、Seiはパフォーマンスのさまざまな側面で強化されています。 これには、ブロック送信時間の 100 倍の増加、毎日のデータ生成の 100 GB から 5 GB への圧縮、同期情報を必要とするすべてのノードまたはノードのキャッチアップ時間の 10 倍の改善が含まれます。
Sei Network v2は、当初のコンセンサスメカニズムを変更せず、ツインターボの設計を維持し続けています。 CosmosコンセンサスインターフェースTendermint ABCIの拡張により、ブロック確認時間を大幅に短縮しました。
Sei v2では、EVM仮想マシンが導入され、並列処理と分散型台帳ストレージメカニズムが改善されています。 目標は、開発者、ノード、およびユーザーのユーザーエクスペリエンスを向上させ、それによって生態学的影響を高めることです。
しかし、3ヶ月間の運用では、Seiの並列トランザクションはTPSを向上させ、ファイナリティを高速化する一方で、そのトレードオフとして状態データ量が増加し、ノードのハードウェア要件が高くなることが観察されました。 チームは、台帳構造を分離し、効率のために分散化をいくらか犠牲にすることで妥協しました。
全体として、他のイーサリアムキラーと比較して、前述のアップデートを効果的に実装することができれば、Seiはトップティアの競争に参加する機会があります。 来年のチームアップデートの結果を見るのを楽しみにしています。
(注:この記事は投資アドバイスではありません。