以太坊Glamsterdam升级：最大规模底层重构，主网日期仍悬而未决

原文：Odaily 星球日报（@OdailyChina）

作者｜jk

イーサリアムは今後、The Merge に次ぐ、コア開発者から見て最も大規模な変更となるプロトコルレベルの再構築である Glamsterdam アップグレードを迎えようとしている。この名称は、実行レイヤー部分が過去の Devconnect 開催地アムステルダムに由来する「Amsterdam」、コンセンサスレイヤー部分は恒星の名前にちなんだ「Gloas」という、二つの部分の組み合わせに由来する。以前の Fusaka アップグレードに続き、Glamsterdam はネットワークがトランザクションを処理し、成長し続けるデータベースを管理する方法を再編成することで L1 のスケーリングを推進し、イーサリアムがブロックを作成・検証する方法を根本的に更新する。

今回のアップグレードは、以下の3つの中核的な目標を中心に展開される：

• 処理の加速（並列化）：ネットワークがデータの依存関係を記録する方法を再編成し、ゆっくりとした1件ずつの順次処理ではなく、大量のトランザクションを安全に同時処理できるようにする。
• スケーリング：ブロック作成と検証の負荷の大きい作業を分割し、ネットワークが速度を落とさずにより大量のデータを伝播するための時間を確保する。
• 持続可能性：新規データの保存にかかる長期的なハードウェアコストを正確に反映するようネットワーク手数料を調整し、将来のガス上限引き上げへの道を開くとともに、ハードウェア性能の低下を防ぐ。

アップグレードの2つの主要提案は、コンセンサスレイヤーと実行レイヤーにそれぞれ存在する：

2つのヘッドライナー提案がある。出典：イーサリアム

主要提案その1：ePBS、「外部の仲介業者」を「組み込みのルール」に変える

まずコンセンサスレイヤーの主要提案、プロトコル内提案者・構築者分離、英語略称 ePBS（EIP-7732）について。

イーサリアムがブロックを生成するたびに、実際には2つのステップがある：一人が「どのブロックを選ぶか」を担当し（提案者）、もう一人が「ブロック内のトランザクションを実際に組み立てる」ことを担当する（構築者）。現在、この分業はイーサリアムのプロトコル自体によって規定されているわけではなく、チェーン外の「仲介会社」のグループ（業界用語でリレー）によって仲介されている。このチェーン外の関係はまた、ブロック検証中に、検証者をタイトな2秒のウィンドウ内で慌ただしくトランザクションのブロードキャストと実行を完了させることを強いる経路を生み出し、ネットワークが処理できるデータ量を制限している。例えるなら、レストランで注文と調理のプロセスを、独立した外部の仲介者が調整して料理を運んでいたところ、この仲介者が機能しなくなると、キッチンとフロントで情報が食い違う可能性がある、というようなものだ。

ePBS が行うことは、この「注文-調理」の分業ルールを、レストラン自身の運営マニュアルに書き込むことであり、外部の仲介者に依存しないようにすることだ。これにより、チェーン上で信頼できるブロックの受け渡しと支払いのメカニズムがプロトコル自体に直接組み込まれ、サードパーティ製のミドルウェアに依存する必要がなくなる。ただし、双方がプロトコルでまだ規定されていない複雑な機能を使いたい場合は、引き続き外部の仲介者を使う選択肢も残されている。同時に、「料理を運ぶ」プロセスで慌ただしくならないように、ePBS は「誰が注文したか」と「料理が時間通りに完成してテーブルに運ばれたか」をそれぞれチェックする専用の「料理チェックチーム」も設置した。これにより、従来の2秒だった料理を運ぶ時間ウィンドウは約9秒に拡大され、レストランは一度により多くの注文を処理できるようになる。つまり、イーサリアムがより多くの Layer2 向けデータを処理できるようになるということだ。

主要提案その2：BALs、出発前に「買い物リスト」を整理しておく

次に実行レイヤーの主要提案、ブロックレベルアクセスリスト、英語略称 BALs（EIP-7928）について。

現在のイーサリアムのトランザクション処理方法は、目隠しをしてスーパーで買い物をする人のようなものだ：商品に触れて、それが何かを確認して初めて、次の行動を決められるため、1件ずつ順番に処理するしかない。どのトランザクションがどのデータ（どのアカウントに関わるかなど）を使うかが事前に分からないため、システムはトランザクションを厳密に順番通りに処理しなければならない。そうしないと、2つのトランザクションが偶然にも同じデータ（例えば同じアドレスの残高）を同時に変更しようとし、衝突やエラーを引き起こす可能性があるからだ。

BALs は、この人物が事前に「どの棚に行き、どの商品を取るか」が明確に書かれた買い物リストを手に入れることに相当する。このリストがあれば、システムは事前にどのトランザクションが互いに全く競合しないかを把握でき、関連性のないトランザクションをいくつかのグループに分けて同時に並列処理できるため、1件ずつ並んで待つ必要がなくなる。このリストにはもう一つの追加の利点がある：ネットワークに新しく参加するノードは、リストに記録された最終結果を直接コピーできるため、複雑な過去のトランザクションを全て再計算する必要がなく、新規ノードの同期が大幅に高速化される。このリストが実際にネットワーク内で流通するように、Glamsterdam にはノード間でこれらのアクセスリストを実際に共有できるようにするための、補助的な伝送プロトコルのアップグレードも同梱されている。この伝送プロトコルは現在、すべての実行レイヤークライアントにとって必須の要件となっている。

付随する提案：「場所を取る」操作への再課金

これら2つの主要提案に加えて、Glamsterdam には再価格設定を行う2つの付随提案も含まれている。これは、ネットワークの「保管料」と「照会料」の料金表をそれぞれ調整するものと理解できる。

• 1つ目は、新しいアカウントの作成やコントラクトのデプロイなど、ネットワーク内で「恒久的に場所を取る」操作に関するものだ。従来の料金は実際に占有するスペースとあまり比例していなかったが、今後は「スペースを1つ占有するごとに対応する料金を支払う」という形で再計算され、ネットワーク全体のデータ増加速度を年間120 GiBという安全で予測可能な水準に抑えることを目標とする。これにより、一般的なハードウェアでもネットワークを継続して実行できることを確保する。同時に、この保管料は専用のアカウントで管理され、トランザクション処理自体の計算コストとは分離される。開発者が保管料を追加で支払う意思があれば、総ガス上限に一気に制限されることなく、より大規模で複雑なアプリケーションを引き続きデプロイできる。
• 2つ目は、ネットワーク内の既存データの照会や読み取りといった操作に関するものだ。従来の価格設定は低すぎ、データ量が増えた現在の実際の照会コストに追いついていなかった。今回、これらのオペコードの料金基準を引き上げ、価格を現代のハードウェアの実際の負荷に近づける。同時に、手数料が安すぎることを利用して、大量の照会リクエストで意図的にネットワークを詰まらせる行為を防ぐことも目的としている。

メインネットの稼働時期：現時点では未定

スケジュールに関しては、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 チームは最近、Plataberget という新しいテストネットを立ち上げた。これは Glamsterdam 専用に設計された最初の短期パブリックテストネットであり、正式な Sepolia と Hoodi へのデプロイは9月まで延期される見込みだ。メインネットの稼働目標もそれに伴い2026年第4四半期に後ろ倒しされる。これにより、Glamsterdam は当初の2026年上半期から延期された後、2回目の日程ずれとなる。コア開発者はこれまでも、アップグレードの正確性は特定の日付に間に合わせることよりも優先されると繰り返し強調しており、正式な ACD 会議で特定のブロック高が確定するまでは、このアップグレードが見られるのは第4四半期、あるいは年末になるかもしれない。