Glamsterdamのアップグレード、イーサリアムのL1スケーリングソリューション

オリジナル | Odaily 星球日报 jk

イーサリアムが迎えるGlamsterdamアップグレードは、The Mergeに続く最も大きなプロトコルレベルの再構築です。この名前は二つの部分の組み合わせから来ています：実行層のアップグレード部分は"Amsterdam"を引き継ぎ、過去のDevconnectの開催地であるアムステルダムから取られています；コンセンサス層のアップグレード部分は"Gloas"と名付けられ、一つの恒星にちなんでいます。以前のFusakaアップグレードに続き、Glamsterdamはネットワークの取引処理とその増大するデータベースの管理方法を再構築することでL1のスケーリングを推進し、イーサリアムのブロック生成と検証の方法を根本的に更新しました。

このアップグレードは三つの核心目標を中心に展開されます：

• 処理の加速（並行化）：ネットワークがデータの依存関係を記録する方法を再構築し、大量の取引を安全に同時に処理できるようにします。従来のように遅い逐次処理ではありません。
• スケーリング：ブロックの生成と検証の重い作業を分割し、ネットワークがより多くのデータを減速せずに伝播するための時間を確保します。
• 持続可能性：ネットワークの手数料を調整し、新しいデータの保存にかかる長期的なハードウェアコストを正確に反映させ、将来のガス上限の引き上げをスムーズにし、ハードウェア性能の劣化を防ぎます。

アップグレードの二つの主要提案はそれぞれコンセンサス層と実行層にあります：

二つの主要提案があります。出典：イーサリアム

主要提案一：ePBS、「外部仲介者」を「内蔵ルール」に変える

まずはコンセンサス層の主要提案について、プロトコル内の提案者と構築者を分離することを提案しています。英語の略称はePBS（EIP-7732）です。

イーサリアムがブロックを生成する際、実際には二つのステップに分かれています：一人が「どのブロックを選ぶか」（提案者）を担当し、もう一人が「ブロック内の取引を実際に組み立てる」（構築者）を担当します。現在、この分業はイーサリアムプロトコル自体によって規定されているわけではなく、一群のオフチェーンの「仲介会社」（業界用語で中継）によって仲介されています。このオフチェーンの関係はブロック検証中にも一つの経路を生じさせ、検証者が緊張した2秒のウィンドウ内で急いで取引のブロードキャストと実行を完了することを強い、ネットワークが処理できるデータ量を制限しています。例えるなら、レストランの注文と料理の段階があり、本来は独立した外部の接続者に依存して料理を運ぶ必要があるため、その接続者が失敗すると、厨房とフロントが一致しなくなる可能性があります。

ePBSが行うことは、この「注文-料理」の分業ルールをレストラン自身の運営規範マニュアルに書き込み、外部接続者に依存しないようにすることです。こうすることで、信頼できるブロックの配信と支払いメカニズムがプロトコル自体に直接構築され、第三者のミドルウェアに依存する必要がなくなります。ただし、双方がプロトコルにまだ規定されていない複雑な機能を使用したい場合は、外部接続者を引き続き利用することも選択できます。また、「料理を運ぶ」段階が混乱しないように、ePBSは特別に「料理検査チーム」を設立し、「誰が注文したか」と「料理が時間通りに提供されたか」をそれぞれ確認します。その結果、元々2秒の料理運搬時間ウィンドウは約9秒に拡大され、レストランは一度により多くの注文を処理できるようになり、イーサリアムがLayer2向けのデータをより多く扱えるようになります。

主要提案二：BALs、出発前に「買い物リスト」を作成する

次に実行層の主要提案、ブロックレベルのアクセスリスト、英語の略称はBALs（EIP-7928）です。

現在のイーサリアムの取引処理の方法は、目隠しをした人がスーパーマーケットで買い物をするようなものです：まず商品に触れて何であるかを確認しなければ、次のステップを決定できないため、一つずつ並ぶしかありません。取引がどのデータを使用するかを事前に知らないため、例えばどのアカウントが関与するかなど、システムは厳密に順番に取引を処理しなければなりません。そうしないと、二つの取引が偶然に同じデータ（例えば同じアドレスの残高）を変更しようとし、競合が発生する可能性があります。

BALsは、出発前にこの人が「どの棚に行くか、どのアイテムを取るか」を明記した買い物リストを手に入れることを可能にします。このリストがあれば、システムは事前にどの取引が互いに「衝突しない」かを確認できるため、無関係な取引をいくつかのグループに分けて、同時に並行処理することができます。このリストには追加の利点もあります：新しいノードがネットワークに参加する際、このリストに記録された最終結果を直接コピーできるため、すべての複雑な過去の取引を再計算する必要がなく、新しいノードの同期が大幅に速くなります。このリストがネットワーク内で実際に流通するために、Glamsterdamはノード間でこれらのアクセスリストを実際に共有できるようにするための関連する伝送プロトコルのアップグレードもパッケージ化しました。この伝送プロトコルは現在、すべての実行層クライアントの強制要件となっています。

付随提案：「スペースを占有する」操作の再評価

この二つの主要提案に加えて、Glamsterdamはネットワークの「保管費用」と「クエリ費用」をそれぞれ再評価する二つの付随提案もパッケージ化しました。

• 第一の提案は、新しいアカウントの作成や契約の展開など、ネットワーク内で「永久にスペースを占有する」操作に関するもので、以前の料金は実際に占有するスペースとあまり比例していませんでした。現在は「スペースを占有するごとに対応する料金を徴収する」ように再計算され、全体のネットワークのデータ成長速度を年間120 GiBという安全で予測可能なレベルに制御することを目指しています。これにより、一般的なハードウェアでもこのネットワークを持続的に運用できるようになります。また、この保管費用は別のアカウントで計算され、取引処理自体の計算費用と混ざらないようにします。開発者が少し多くの保管費用を支払うことを望む限り、より大規模で複雑なアプリケーションを展開することができ、総ガス上限に一気に制約されることはありません。
• 第二の提案は、ネットワーク内の既存データをクエリしたり読み取ったりする操作に関するもので、以前の価格設定は低すぎて、現在のデータ量の増加に伴う実際のクエリコストに追いついていませんでした。今回、この種の操作コードの料金基準を引き上げ、価格を現代のハードウェアの実際の負荷状況により近づけることになります。これにより、誰かが安価な料金の隙間を利用して、大量のクエリリクエストでネットワークを詰まらせることを防ぐこともできます。

メインネットのローンチ日時：現在まだ決まっていません

スケジュールに関して、Glamsterdamは現在非常に微妙な段階にあります。公式の場では、最近確認できる全体の核心開発者実行層会議（ACDE）は第241回で、7月16日に行われ、主な議題はGlamsterdam Devnet段階の最新進捗報告と次回のアップグレードHegotaの投票で選ばれる主要提案です。以前、業界で広く引用されたスケジュールによれば、Devnet段階は0から7までの8回のイテレーションを行い、期間は2026年3月28日から7月8日までで、その後Sepoliaテストネットのフォークは2026年8月3日、Hoodiテストネットのフォークは2026年8月17日、メインネットのアクティベーションの目標日は2026年9月16日です。

元々のスケジュールは2026年上半期でした。出典：イーサリアム

しかし、最新の動向から見ると、このスケジュールは大幅に遅れる可能性が高いです。EthPandaOpsチームは最近、Glamsterdam専用の最初の短期公共テストネットであるPlatabergetを発表しました。正式なSepoliaとHoodiの展開は9月まで遅れる見込みです。メインネットのローンチ目標も2026年第4四半期に相応に後ろ倒しされます。これはGlamsterdamが以前の2026年上半期からの延期に続いて、二度目の日時のずれが発生したことを示しています。核心開発者は以前から、アップグレードの正確性が特定の日付に間に合わせることよりも優先されると強調しており、正式なACD会議で具体的なブロック高が確定する前に、私たちは第4四半期、さらには年末までこのアップグレードを見ることができないかもしれません。