Flow のパフォーマンス / スケーラビリティ / レジリエンス / アクセシビリティが向上します
本記事はこちらの記事を日本語に翻訳したものです。
Flow は、ブロックチェーン技術をメインストリームにするために必要な、スピード、スケーラビリティ、持続可能性、安全性を提供するオープンな分散型プラットフォームです。
Flow のビジョンは、Web3 に何十億もの消費者を乗せることです。 この目標を実現するには、ノード・ソフトウェア・レベル、インフラ・レベル、ガバナンス・レベルの強固な基盤が必要です。最新の Flow のアップデートは、この目標達成に向けた大きな一歩です。これは、ネットワークのスケーラビリティ、パフォーマンス、回復力、アクセシビリティを向上させるとともに、より安全にするための新機能を導入しています。これらは NCC、CoinbaseCloud、BlueSign など Flow コミュニティメンバーからの貢献によって、数ヶ月かけて実現されました。
これらの主要な変更について深堀りし、どのように Flow をビジョンの実現に近づけるのかみてみましょう。
トランザクションのファイナライズが 20% 高速化
ブロックチェーンなどの高度に分散されたシステムにおいて、共有されたステートを合意することは根本的な課題です。Flow の場合、この合意（コンセンサス）生成の責任はコンセンサス・ノードにあり、コンセンサス・ノードは現在 HotStuff として知られるコンセンサス・プロトコルを実行しています。現在の実装は Flow でよく動いてくれていますが、パフォーマンスや、ネットワーク上の一部のコンセンサス・ノードがダウンした場合の処理などの面で、いくつかの欠点があります。
今回のスポークで Flow は、HotStuff を大幅に改良した派生プロトコルである Jolteon に切り替わります（参考）。この新しいコンセンサス・プロトコルは、コンセンサス・ノードが合意に達するまでの時間、言い換えれば、ブロックをファイナライズ（確定）するまでの時間を 33％ 短縮します。Jolteon は、通常、2 つの子ブロックを持つブロックをファイナライズすること（通称：2-chain finalization rule）で、この高速化を実現します（元の HotStuff では、ファイナライズには 3 つの子ブロックが必要でした。通称：3-chain finalization rule）。
トランザクションがファイナライズされたブロックに入るには、トランザクションはまずアクセス・ノードからコレクション・ノードに送られて、コレクションに入れられ、最後にコンセンサス・プロトコルを経てコンセンサス・ノードによってブロックに入れられる必要があります。そのため、いくらかの待ち時間が発生します。今回の新しい実装では、トランザクションがファイナライズするまでの時間が約 20% 改善されます。トランザクションがファイナライズした後も、実行ノードによって実行され、検証ノードによって結果が検証され、コンセンサス・ノードによってそのトランザクションを含むブロックがシールされる必要があります。ファイナライズ処理の高速化は、トランザクションがパイプラインをより速く進むことを意味し、トランザクションのシールにかかる時間を改善することになります。（※訳注：Flow では「ファイナライズ」と「シール」は区別されています。「ファイナライズ」されるとトランザクションがブロックに取り込まれることが確定し、「シール」されるとノードから取得できるトランザクションの実行結果が保証されます。）
新しい実装は現在テストネットで稼働しています。下のグラフからわかるように、ファイナライゼーションにかかる時間は劇的に改善されました。
また、新しい実装では、オーファン・ブロック（※訳注：枝分かれして結果的に選ばれなかったブロック）が少なくなるため、トランザクションがブロックに含まれるまで異常に時間がかかるケースも減るはずです。さらに、Jolteon は Flow の検閲耐性も向上させます。悪意のあるノードはトランザクション内容が気に入らないブロックをオーファン・ブロックにしようとするからです（詳細は、3-chain finalization rule における「チェーン品質」の分析を参照。これは 2-chain finalization rule では改善されます）。
ブロック生成のレジリエンス改善
新しいコンセンサス実装では、分権化・分散化したシステムで避けられない、ネットワーク上のコンセンサス・ノードのダウン（オフラインになること）に対する耐性がはるかに向上する予定です。Hotstuff と Jolteon はラウンド・ベースのアルゴリズムであり、各ラウンドでリーダーとして指定された 1 つのコンセンサス・ノードがブロックを提案します。リーダーが有効なブロックを提案すると、他のコンセンサス・ノードがそれについて投票し、投票が通れば、そのブロックはチェーンの暫定的な次のブロックとして受け入れられ、新しいリーダーが選ばれてまた次のラウンドが行われます。しかし、あるラウンドのリーダーがオフラインの場合（または悪意がある場合）、他のノードはリーダーがブロックを提案するのを待ち続け、タイムアウトになるまで時間を浪費します。新しい実装では、アクティブ・ペースメーカーと呼ばれるものが導入され、ノードが活発的に相互調整し、長い時間待つことなくリーダーを放棄するかどうか決定できます。これにより、コンセンサス・ノードがダウンした場合のブロック生成のレジリエンス（耐障害性）が格段に向上します。
これは、スポーク（※訳注：Flow におけるメンテナンス）の高速化にも役立ちます。以前は、スポーク後にコンセンサス・ノードの大部分が起動しても、同時に起動していないと同期がとれず、なかなかコンセンサスに至りませんでした。すべてのノードが最終的に同期するまで、ブロック生成は行われません。そのため、スポークの完了が遅れるという問題がありました。アクティブ・ペースメーカーの実装により、ノードが順次オンラインになったとしても、ノード間の調整がうまくいき、より速く同期できます。
また、アクティブ・ペースメーカーは、将来的にコンセンサス・ノードのかなりの部分がオフラインになってもパフォーマンスを維持できるように、アグレッシブなチューニングを可能にします。さらに、完全にビザンチン耐性のあるエポックの切り替えを可能にします。
ネットワークをペタ・バイト級のオンチェーン・ストレージに超スケールするための基盤構築
Flow は 10 億人のユーザーのホームとなり、最終的には シャーディングなしで ペタ・バイト級のオンチェーン・データをサポートしてこれを達成します。これどのレイヤー 1 でも達成されていない偉業です。
今回のスポークには、ペタ・バイト級のオンチェーン・ストレージと、最適化された同時トランザクション実行、という目標に向けた実行ノードの複数のアップデートが含まれています。
これは、将来の 2 つの大きな目標のための準備となります：
- データをディスクにオフロードするストレージ層のリファクタリングによって、ペタ・バイト級のオンチェーン・ストレージを実現する一方で、実行ノードのメモリ要件を減らし、あらゆる規模のノード・オペレータがより手頃な価格で実行できるようにします。
- 実行ノードでのトランザクションの並列実行により、ネットワーク・スループットを数桁向上させます。
今回の一連の変更によって、実行ノードの性能はすでに 20% 向上しており、平均スループットは 400 TPS に達しています。
アカウントの早期検証によるスパム対策強化
このスポークは、手数料を支払えないトランザクションを送信する（悪意のある）アカウントに対するスパム対策をネットワークに追加します。以前は、手数料を支払うのに十分な資金がないトランザクションが送信された場合、それは実行されて、最後の手数料の支払い処理で失敗し、リソースを浪費していました。これをトランザクションの中身の実行前に支払い者の残高を確認するように変更することで、このようなスパム攻撃からチェーンの Liveness 性を守り、Flow が 99.99 % の SLA 目標に近づけるようにします。
パーミッションレスなアクセス・ノードのサポート
パーミッションレスなアクセス・ノードは間もなく有効化され、共有のものではない自分たちのアクセス・ノードを望む dApp 開発者が、プライベートなアクセス・ノードを実行できるようになります。今回のリリースは、パーミッションレスなアクセス・ノードの構築をサポートするためにノード・ソフトウェアのコア・コンポーネントを更新する過去数ヶ月の大規模な努力の集大成となっています。
最も重要な変更点は、ネットワーク層に Byzantine Fault Tolerant（BFT）を導入し、ネットワーク内に悪意のあるノードが存在すると、他のノードがそのノードからのトラフィックを拒否できるようにしたことです。また、ネットワーク層で使われているオープンソースのライブラリにいくつかの変更を加え、これらライブラリの導入による脆弱性がないようにしました。
また、更新されたノード・ソフトウェアは、Web3 セキュリティ監査機関の一つである NCC による監査を受け、監査で指摘された問題に対処しました。
これにより、ノード・ソフトウェアは、パーミッションレスなアクセス・ノードとして参加する可能性のあるビザンチン・アクターからのネットワーク層への攻撃に極めて強くなっています。
Cadence v0.30: コントラクトの動的なインポートと Account Inbox
このスポークは、メインネット上の Cadence バージョンを v0.30 に更新します。この新しい Cadence バージョンには、2 つの主要な機能と 12 のパフォーマンス向上の変更が導入されています。
コントラクトの動的なインポート
この機能により、アドレスから動的にコントラクトをインポートできるようになり、Solidity の開発者がよく使うパターンを Cadence でも使えるようになりました。これは静的にコントラクトをインポートする代わりに、インポートの失敗をより適切に（gracefully）処理できるため、耐障害性が改善されます。
⭐ これは Bluesign によるコミュニティ主導の機能であり、コミュニティによって実装された機能です。
- FLIP // Pull Request
Capability を扱いやすくする API（Account Inbox）
Capability を共有するトランザクションに送付者と受取者の両方が署名しなければならないこれまでのモデルに代わり、ひとりの署名者のトランザクションで、他のアカウントと Capabilty 共有を簡単にする新機能です。
- FLIP // Pull Request
- 詳細はこちら
ネットワークの可用性が向上し、今後のネットワークアップグレードを迅速かつ少ない回数で行うことが可能に
スポークでは、ネットワークのダウンタイムが発生します。ネットワークの可用性を高めるため、スポークの処理は可能な限り最適化されています。今回は 60 分で完了しましたが、今後、ステート移行を伴わないスポークは 30 分以内に完了するはずです。もし、ステート移行を伴うスポークであれば、移行の種類にもよりますが、約 45 分で完了します（ステート移行とは、既存のデータを新しいデータ・モデルに変換する処理のことです）。スポークの頻度も、これまでの隔月から、四半期に 1 回に変更されます。
しかし、イノベーションのペースが落ちないように、継続的なデプロイの方法として、ローリング・アップグレードと、ブロック番号で調整されたアップグレード（height coordinated upgrades）の 2 つの新しい方法が導入されます。
ローリング・アップグレードでは、ノード・オペレータはネットワークのダウンタイムなしにノード・ソフトウェアを更新できます。ブロック番号で調整されたアップグレードも、ノード・ソフトウェアを更新する必要がありますが、変更は特定のブロック番号で有効になりますが、ただし実行ノードの再起動が必要となり、その結果、トランザクションの実行が数分間停止する可能性があります。
私たちはできる限りダウンタイムを避けるようにしていますが、今回のネットワーク・アップグレードによって、Flow はパフォーマンス、安全性、信頼性がより高いものになるでしょう。今後も、Flow の可能性を最大限に発揮できるよう、皆さんと手をとりあって取り組んでいきたいと思います。
前向きに頑張っていきましょう！🚀
