著者: Pavel Paramonov 、Hazeflowの創設者
編集：フェリックス、PANews
Sei は、最新の Giga アップグレードについて説明する新しいホワイト ペーパーをリリースしました。ほとんどの読者にとって、17 ページにわたる高度な技術的コンテンツを読むのは困難です。したがって、この記事では、このアップデートの内容と、さまざまなレベルでブロックチェーンのパフォーマンスがどのように向上するかについて説明します。
1. 非同期ブロック生成について
Giga の主なアイデアと基盤は次のとおりです。
「トランザクションのリストが順序通りで、ブロックチェーンの初期状態が一貫しており、すべての正直なノードがこれらのトランザクションを同じ順序で処理する場合、それらは同じ最終状態に到達します。」
この場合、結果は初期状態とトランザクションの順序のみによって決まります。つまり、コンセンサスはブロック内のトランザクションの順序についてのみ合意すればよく、各ノードは最終状態を独立して計算できます。
- このモデルでは、コンセンサスと実行が分離されており、ブロックを非同期で実行できます。
- ブロックが完成すると、ノードはそれを処理し、その状態を後続のブロックにコミットします。
- 次に、ブロックは状態のコンセンサスを通じて検証され、すべてのノードが正しい最終状態を計算したことが確認されます。
ここで重要な点は、実行とコンセンサス生成が並行して行われるという点です。ノードがブロック上で計算を実行すると、他のブロックも受信されます。
したがって、ブロックは実際には全順序で（並列ではなく）実行され、ブロック生成プロセス自体はコンセンサスと並列に行われます。ただし、特定のブロックに対して、これらのプロセスは完全に非同期です。
明らかに、同じブロックで同時に合意に達して実行することは不可能と思われます。したがって、ブロック n を実行すると、ノードは次のステップのためにブロック n+1 を受け取ります。
コンセンサスが歪んだ場合（たとえば、ネットワーク内のノードの 3 分の 1 が悪意を持って行動した場合）、標準の BFT プロトコルと同様に、チェーンは停止します。
ブロック内で実行に失敗したトランザクションはブロックを無効にせず、単に失敗した状態のままになります。これは、ブロックの生成と実行が分離されており、現在のブロックの最終状態が後続のブロックにコミットされるためです。
2.マルチプロポーザーモデルはどのように実装されますか? また、アウトバーンとは何ですか?
コンセンサス プロトコル自体は「アウトバーン」（速度制限のないドイツの高速道路）と呼ばれます。 Autobahn には、データの可用性とトランザクションの順序付けを分離する興味深いモデルがあります。
高速道路の車線と同様に、複数の車線があり、各ノードには独自の車線があります。ノードはこれらのチャネルを使用して、トランザクションの順序に関する提案を行います。提案は、順序付けられたトランザクションの集合にすぎません。
Autobahn は、複数の提案を集約してトランザクションの順序を確定する「tipcut」操作を実行することがあります。
- 前述のように、各バリデーターにはトランザクションのバッチを提案するための独自のチャネルがあります。
- ノードは有効な提案を受信すると、提案が受信されたことを確認するために投票を送信します。
- 提案が投票を集めた後、データがネットワーク内の少なくとも 1 つの正直なノードによって受信されたことを確認するために、可用性の証明 (PoA) が形成されます。
- チップカットは数ミリ秒単位で発生し、最終的にはアウトバーンからの複数の提案が「カット」されることになります。
提案者には、ブロックの公開を待って、可能な場合は単一のブロックを公開するインセンティブがありますが、各ブロックの実行時間制限（ガス制限と同様）により、このダイナミクスはわずかに変化します。
チャネル上の提案は通常 1 つのブロックに相当します。つまり、ティップカットが発生すると、複数のブロックが同時に切断されることになります。
その後、スロットのリーダーは Tipcut を他のノードに送信してソートを完了します。実際、ノードが単一の Tipcut に投票すると、そのノードはすでに次の Tipcut の準備を始めます。
バッチを逃したノードは、PoA にリストされているバリデーターから非同期的にバッチを取得できます。これが、データの可用性が必要な理由の本質です。
同期条件下では、リーダーが正しい場合、Autobahn は 2 回の通信で提案の確認を完了します。リーダーが失敗した場合、メカニズムは進行を維持するために新しいリーダーを選出します。
次のチップカット提案は、実際には現在のチップカットのコミットフェーズ中に開始できるため、実行が生成と並行して行われるため、レイテンシが短縮されます。
実際、モデル全体はマルチプロポーザーモデルであり、多くのノードが同時にブロックの順序付けを提案することができます。各バリデーターは独自のブロックを提案し、ネットワークがそれらのブロックを所有しているという証明 (PoA) を受け取ります。これにより、ネットワークのスループットと全体的な効率が向上します。
3.並列実行とその適用性
前述のように、ブロック自体は実際には順番に実行されますが、ブロック実行プロセスはコンセンサスと並行して行われます。これが真の並列実行を構成するかどうか疑問に思うかもしれません。
答えはイエスであり、ノーでもあります。
ブロックは順番に実行されますが、ブロック内のトランザクションは実際には並列に実行できます。トランザクションは同じ状態を変更（書き込み）せず、1 つのトランザクションの結果が別のトランザクションに影響を与えない場合、並列で実行できます。
つまり、実行パスは互いに依存してはなりません。 Giga にはメモリ プールがなく、トランザクションはノードによってすぐに組み込まれます。
- Giga は、ほとんどのトランザクション間に競合がないことを前提とし、複数のプロセッサ コアで同時に処理します。
- 各トランザクションへの変更は一時的にプライベート バッファーに保存され、ブロックチェーンにすぐには適用されません。
- 処理が完了すると、システムはトランザクションが以前のトランザクションと競合するかどうかを確認します。
- 競合が発生した場合、トランザクションは再処理されます。競合がない場合、変更はブロックチェーンに適用され、確定されます。
また、高頻度の競合が発生する状況も考えられます。その場合、システムはトランザクションを確実に進めることができるように、一度に 1 つずつトランザクションを処理するように切り替えます。
簡単に言えば、並列実行はトランザクションを複数のコアに分散し、競合しないトランザクションを同時に実行できるようにします。
4.ストレージの問題と最適化
取引量が多いため、データは安全で簡単にアクセスできる必要があり、その保存方法は従来のブロックチェーン ストレージとは少し異なる必要があります。 Giga は、データを単純なキー値形式で保存します。これは比較的フラットな構造であり、データの変更時に必要な更新やチェックの回数を削減するのに役立ちます。
さらに、Giga は階層型ストレージ アプローチを採用しています。最近のデータは SSD (高速) に保存され、あまり使用されないデータはより低速でコスト効率の高いストレージ システムに移動されます。
ノードがクラッシュした場合、ログを再生して正しい状態を復元し、専用データベースである RocksDB に更新を適用してデータを整理することができます。
ストレージ システムは、負荷の高い計算を実行せずにデータの正確性を証明できる暗号化アキュムレータを使用します。アキュムレータはバッチで更新されるため、バリデータとライトノードはブロックチェーンの現在の状態について迅速に合意に達することができます。
5.マルチプロポーザーEVM L1ブロックチェーンとはどういう意味ですか?
L1 インフラストラクチャには改善できる点が数多くあり、L1 ごとに、MEV などの経済的な問題から状態管理などの技術的な問題に至るまで、さまざまな技術的課題に直面しています。
複数の提案者をサポートする最初の L1 チェーンになることは、特に EVM L1 にとっては困難です。これは、EVM がもともと複数の提案者システムをサポートするように設計されていなかったためです。
しかし、Sei は、多くの開発者が使い慣れている EVM とツールを保持するために、別のアプローチを試みています。
並列トランザクション実行、実行中のコンセンサス、および並列に動作する複数のプロポーザはすべてパフォーマンスの向上に役立ち、実行スループットは約 50 倍増加します。ただし、これらの改善は、前述のリスクのいくつかに直面する可能性もあります。
これは Sei の 2 回目のメジャー アップデートです。以前、セイはコスモスチェーンからEVMチェーンに変換されました。現在、Sei は速度に最適化された実行クライアントをリリースしました。
次に何が起こるか、そしてこれらの最適化対策がどのように機能するかを見るのは興味深いでしょう。
