Sei 新ホワイトペーパーを解読する：Giga アップグレードはどのような技術革新をもたらすのか？

執筆者：パベル・パラモノフ、Hazeflow創設者

コンピレーション:PANews

Seiは新しいホワイトペーパーを発表し、最新のGigaアップグレードについて紹介しました。ほとんどの読者は17ページの深い技術内容が読みづらいと感じています。したがって、この記事では今回の更新の内容と、さまざまなレベルでブロックチェーンの性能を向上させる方法を説明します。

非同期実行に関するブロック生成

Gigaの主な思想と基礎は以下の通りです：

「もし私たちの取引リストが順序通りであり、ブロックチェーンの初期状態が一致し、すべての誠実なノードが同じ順序でこれらの取引を処理するなら、ノードは同じ最終状態に達するでしょう。」

この場合、結果は初期状態と取引の順序のみに依存します。これは、コンセンサスがブロック内の取引の順序について合意すればよく、各ノードが最終状態を独立して計算できることを意味します。

このモデルでは、コンセンサスと実行を分離し、ブロックを非同期に実行できるようにします。

ブロックが最終的に確定されると、ノードはそれを処理し、次のブロックでその状態を提出します。

その後、状態のコンセンサスを通じてそのブロックを検証し、すべてのノードが正しい最終状態を計算したことを確認します。

ここでの重要なポイントは、実行とコンセンサス（生成）が並行して行われることです。ノードはブロックの計算を実行している間に、他のブロックも受信します。

したがって、ブロックは実際には総順序（並行ではなく）で実行され、ブロック生成プロセス自体は確かにコンセンサスと並行して発生します。しかし、特定のブロックに対して、これらのプロセスは完全に非同期です。

明らかに、同じブロックに対してコンセンサスと実行を同時に行うことは不可能のようです。したがって、ブロック n を実行する際に、ノードは次のステップのためにブロック n+1 を受信します。

コンセンサスに偏りが生じた場合（例えば、ネットワーク内の3分の1のノードが悪意を持って行動する場合）、チェーンは停止します。これは標準的なBFTプロトコルに似ています。

ブロック内で実行に失敗したトランザクションは、そのブロックを無効にすることはなく、単に失敗状態を保持します。これは、ブロックの生成と実行が分離されており、現在のブロックの最終状態が後続のブロックで提出されるためです。

提案者モデルはどのように実現され、Autobahnとは何ですか？

このコンセンサスプロトコル自体は「Autobahn」と呼ばれています（無制限のドイツの高速道路のように）。Autobahnはデータの可用性と取引の順序を分離しており、その背後には興味深いモデルがあります。

ちょうどどの高速道路の車線のように、複数の車線が存在し、各ノードには独自の通路があります。ノードはこれらの通路を使用して、取引の順序に関する提案を行います。提案は単に取引の順序付けられた集合です。

アウトバーンは、取引の順序を確定するために複数の提案を集約する「チップカット」操作を実行することがあります。

以前言ったように、各バリデーターには取引バッチを提案するための独自のチャネルがあります。

ノードが有効な提案を受け取ると、その提案が受信されたことを確認するために投票が送信されます。

提案が投票に集まると、可用性証明（PoA）が形成され、データがネットワーク内の少なくとも1つの誠実なノードによって受信されたことが保証されます。

チップカットはミリ秒単位で発生し、最終的にはアウトバーンからの複数の提案が「カット」されます。

提案者はブロックを公開するのを待つ動機があり、可能であれば単一のブロックを公開しますが、各ブロックの実行時間制限（ガス制限に似ている）がこのダイナミクスをわずかに変更します。

通路上にある提案は通常1つのブロックに相当し、これはTipcutが発生すると複数のブロックが同時に切断されることを意味します。

その後、そのスロットのリーダーは、他のノードにTipcutを送信して順序を完成させます。ノードは実際に単一のTipcutに投票しながら、次のTipcutの準備をしています。

バッチを逃したノードは、PoAにリストされたバリデーターから非同期にデータを取得できます：これがデータの可用性が必要な本質的な理由です。

同期条件下で、リーダーが正しい場合、Autobahnは2回の通信で提案の確認を完了します。リーダーが故障した場合、そのメカニズムはプロセスを維持するために新しいリーダーを選出します。

次の tip-cut 提案は、実際に現在の tip-cut の提出段階で開始できるため、遅延を減少させることができます。なぜなら、実行は生成と並行して行われるからです。

実際、全体のモデルはマルチプロポーザルモデルであり、多くのノードが同時に自分のブロックを提案することができます。各検証者は自分のブロックを提案し、ネットワークがこれらのブロックの証明（PoA）を受け取ります。これにより、ネットワークのスループットと全体的な効率が向上します。

並列実行とその応用

以前に述べたように、ブロックの実行プロセスと合意は並行して発生していますが、ブロック自体は実際には順番に実行されます。これが本当の並行実行を構成するかどうか疑問に思うかもしれません。

答えは肯定的でもあり、否定的でもあります。

ブロックは順番に実行されますが、ブロック内のトランザクションは実際には並行して実行できます。トランザクションが同じ状態を変更（書き込み）せず、あるトランザクションの結果が別のトランザクションに影響を与えない場合、それらは並行して実行可能です。

簡単に言うと、それらの実行パスは互いに依存すべきではありません。Gigaにはメモリプールがなく、取引はノードによって即座に含まれます。

Gigaは、ほとんどの取引間に競合がないと仮定し、複数のプロセッサコアで同時にこれらの取引を処理します。

各取引の変更は、一時的にプライベートバッファに保存され、すぐにはブロックチェーンに適用されません。

処理が完了した後、システムはその取引が以前の取引と衝突しているかどうかを確認します。

衝突がある場合、その取引は再処理されます。衝突がない場合は、その変更がブロックチェーンに適用され、最終的に確定されます。

高頻の衝突が発生する可能性もあり、その場合、システムは一度に1つのトランザクションを処理するモードに切り替えて、トランザクションの進行を保証します。

簡単に言えば、並行実行はトランザクションを複数のコアに割り当てることで、競合しないトランザクションが同時に実行できるようにします。

ストレージの問題と最適化

取引量が多いため、データは安全で簡単にアクセスできる必要があるため、従来のブロックチェーンストレージとは少し異なる方法で保存する必要があります。 Giga は単純なキーと値の形式でデータを保存するため、比較的フラットな構造であるため、データが変更されたときに何度も更新やチェックを行う必要性を減らすことができます。

さらに、Gigaは階層ストレージ方式を採用しています：最近のデータはSSD（高速）に保持され、あまり使用されないデータは速度が遅く、コスト効率の良いストレージシステムに移行されます。

ノードがクラッシュした場合、それはログを再生して正しい状態を復元し、データを整理するためにRocksDB（専用データベース）に更新を適用できます。

このストレージシステムは、重い計算を行うことなくデータの正確性を証明できる暗号累積器（Cryptographic Accumulator）を採用しています。累積器はバッチ処理の方法で更新され、検証者と軽量ノードがブロックチェーンの現在の状態に迅速に合意できるようにします。

マルチプロポーザル EVM L1 ブロックチェーンになるとはどういう意味ですか？

L1インフラストラクチャは様々な改善が可能であり、異なるL1はMEVなどの経済的問題から状態管理などの技術的問題に至るまで、様々な技術的課題に直面しています。

マルチプロポーザーをサポートする最初のL1チェーンであることは、特にEVM L1にとっては、EVMがマルチプロポーザーシステムをサポートするように設計されていないため、困難な場合があります。

しかし、Sei は EVM と多くの開発者が使い慣れているツールを保持するために異なるアプローチを試みています。

並行トランザクションの実行、実行中の合意形成、複数の提案者の並行操作は、パフォーマンスの向上に寄与し、実行スループットは約50倍向上する可能性があります。ただし、これらの改善は、前述のリスクに直面する可能性もあります。

これは Sei の二回目の大規模アップデートであり、以前 Sei は Cosmos チェーンから EVM チェーンに移行しましたが、現在 Sei は速度最適化に特化した実行クライアントを発表しました。

今後の発展とこれらの最適化措置のその後の効果は注目に値します。