ETHEREUM NETWORK UPGRADE
ブロックの作り方と、
その検証のしかたを、
同時に作り変える。
Glamsterdam(グラムスターダム)は、The Merge以来もっとも構造的なEthereumのアップグレードと呼ばれています。主役は2つ。読むより、動かして掴んでください。
Ethereumはどこまで来たか
直近のアップグレードはL2を安くすることに集中してきました。Glamsterdamは、L1そのものの実行能力に踏み込む回です。
-
2022.09The MergePoWからPoSへ。マイナーによるブロック生産が終わりました。
-
2023.04ShapellaステークしたETHの引き出しが可能に。
-
2024.03DencunBlobを導入し、L2の手数料が劇的に下がった回。多くの人が体感した唯一の変化かもしれません。
-
2025.05Pectraバリデータ運用とアカウントまわりの改善。
-
2025.12FusakaPeerDASでL2のデータ可用性をさらに広げました。
-
開発中Glamsterdamここで矛先が変わります。L2ではなく、L1自身がどれだけ処理できるか。ブロックの作り方と検証のしかたを、同時に組み替えます。
なぜ「Glamsterdam」という名前なのか
2つのフォーク名をつなげた合成語です。名前そのものが「2層を同時に変える」ことを表しています。
主役は2つ。役割はきれいに分かれています
このサイトはずっとこの対比で進みます。色も最後まで揃えてあります。紫が「作る側」、緑が「検証する側」です。
ブロックが生まれてから確定するまでの一本道。ePBSは入口を、BALsは出口の手前を作り変えます。
解く問題:ブロックを誰がどう作るか
いまは外部のリレーという仲介役に信頼を預けています。ePBSはこの取引をプロトコルの中に取り込み、仲介なしで成立させます。実行層の変更もEngine APIの変更も必要ありません。
解く問題:届いたブロックをどう速く検証するか
いまは実行してみるまで、どのデータに触るのか分かりません。BALsはそれを事前に宣言させます。先に分かっていれば、並列に処理できます。
ちなみにGlamsterdamの公式マスコットはホッキョクグマです。Ethereumのアップグレードにはマスコットを決める仕組み(EIP-8066)があります。
Glamsterdamはまだ開発中です。どのEIPが入るか、各パラメータがいくつになるか、いつ有効化されるか — いずれも確定していません。全体をまとめるメタEIPであるEIP-7773は、本稿の時点でDraftステータスのままです。このサイトでは、確定していない数字は意図的に書いていません。
まず、いまのEthereumを見ておく
02と03の話は、どちらもここが土台になります。急がば回れです。3つだけ掴んでください。
12秒ごとに、世界中が同じ手順を繰り返しています。その12秒の中で「誰がブロックを作るか」と「みんなでどう確かめるか」が起きています。Glamsterdamが触るのは、この12秒の中身です。
1. Ethereumは2階建て
Ethereumは2本のチェーンが上下に組み合わさって動いています。「ビーコンブロック」といえば上の階のブロック、「実行ペイロード」といえば下の階の中身のことです。02のePBSは上の階の、03のBALsは下の階の話です。
2. 12秒でひと区切り —— スロット
スロット長12秒はGlamsterdamでも変わりません。6秒に半減する提案(EIP-7782)は、今回は見送られました。
3. いまのブロックの作り方 —— 仲介役がいる
ブロックを提案する権利を得たバリデータは、たいてい自分では作りません。専門のビルダーに外注します。ただし、その受け渡しには仲介役が必要です。
ビルダーは中身を見せずに入札します。プロポーザーは一番高い入札を、中身を見ないまま選んで署名します。両者は直接やり取りできないため、間にリレーという第三者が立ちます。現在、ブロックの大半(およそ9割)がこの経路で作られています。
「およそ9割」という比率は日々変動します。このデモの入札額もイメージであり、実際の値ではありません。
4. いまのブロックの検証 —— 一列に並んで待つ
🤔 まず予想してみよう
ブロックの検証で、いちばん時間を食っているのはどっち?
答え:B。EVMの計算そのものは十分に速く終わります。ボトルネックは、状態(アカウントやストレージ)がディスク上にあり、そこへのランダムな読み出しを待たされることです。しかも、どこを読むことになるのかは実行してみるまで分かりません。だから先回りして準備しておくこともできません。
探しているのはトランザクションではなく、それが触りにいくステート(残高・nonce・コード・ストレージ)の置き場所です。触る先は木のあちこちに散らばっています。
1行が1トランザクションです。オレンジは「どこを読むのか探して、ディスクから取ってくる」時間、青は「EVMが実際に計算する」時間。1本のレーンしかないので、2本目は1本目が終わるまで、3本目は2本目が終わるまで、ただ待つしかありません。行が右にずれていく分がまるごと待ち時間です。この待ちを潰すのが03のBALsです。
このデモの時間の比率は、構造を体感するための例です。実測値ではありません。実際には、トランザクションの内容によって読み出しの量も計算の量も大きく変わります。
そして、これを全部ひとつの締切までにやる
いまのバリデータは、証明の期限までに3つの仕事を終わらせる必要があります。ここが詰まっているせいで、ブロックを大きくできません。
重いペイロードの伝播も、3つの検証も、ぜんぶ赤い線の左。後半はガラ空きなのに使えていません。
順番は上と同じ「伝播 → 検証」。細くなったのは、期限までに済ませる伝播だけ(上の帯と見比べてください)。重い伝播と検証は線の右へ移り、青い枠が次のスロットまで広がります。
横方向は時間。赤い線(証明の期限)はいまは4秒で、これは確定した値です。ePBS後の各締切の秒数はまだ策定中なので、位置は仮です。
この図には秒数を書いていません。スロット内の各締切をどう設定するかは、現在まさに仕様策定中だからです。コンセンサス仕様では時間設定の方式そのものを見直す作業が進んでおり、PTCの締切も「ペイロードが届いたか」「データが届いたか」の2つに分かれる方向です。ここでは順序と、おおよその重さの比率だけを示しています。
ブロックを「作る側」を、プロトコルの中に入れる
01で見た、リレーという仲介役への信頼。それを仕組みそのもので要らなくします。
鍵は「先に払わせる」こと。ビルダーが約束を破っても、プロポーザーの取り分は守られる。だから仲介役に見張ってもらう必要がなくなります。
1. リレーが消える
2. ブロックから中身が抜ける
01の最後で「期限までに済ませる伝播が細くなる」と言ったのは、これが理由です。
実行ペイロードが抜けて、代わりにビルダーの署名つきの約束が1行だけ入ります。約束にはブロックのハッシュと、プロポーザーに払う金額が書かれています。
3. スロットは3つの結末を取る
ここがePBSの核心です。3つ押し比べて、いちばん下の行を見てください。
ビーコンブロックさえ出れば、プロポーザーは必ず払われる。ビルダーがペイロードを出さなくても(Empty)、取り分は守られます。これを「プロポーザーの無条件支払い」と呼びます。リレーに見張ってもらう理由が、ここで消えます。
4. お金はどう動くのか
払うのはビルダー、もらうのはプロポーザー。ブロックを作らせてもらう代金です。
なぜ作る側が払うのか
プロポーザーが自分で作らないのはなぜか。専門のビルダーのほうが多く引き出せるので、代金を受け取ったほうが手取りが増えることが多いからです。これが「提案者とビルダーを分ける(PBS)」という発想の出発点で、ePBSはその取引をプロトコルの中に取り込んだものです。
支払いは3段階で動く
5. 「間に合ったか」だけを見る係 —— PTC
PTC = Payload Timeliness Committee(ペイロード適時性委員会)。ePBSで新しく生まれる役目です。
スロットごとに、そのスロットのビーコン委員会の中から512人が選ばれ、この係を務めます。仕事は「ビルダーが約束したペイロードが時間内に届いたか」を見るだけ。中身は検証しません。だからミリ秒で終わり、締切に間に合います。重い検証は、01で見たとおり後ろへ回されます。
PTCが何人賛成すればFullと判定されるか、その閾値の数値は本サイトでは書いていません。EIP本文の定数表に載っておらず、緩和策として「2/3にすれば」という将来案が書かれている段階だからです。人数(512人)は仕様に明記されています。
まだ解けていない問題
Free option problem と呼ばれます。EIP本文のSecurity Considerationsにも明記されている、既知の未解決課題です。ビルダーに可変のペナルティを課す緩和策が提案されています。
ここまでが「作る側」。次は、届いたブロックをどう速く検証するか。01で見た1本のレーンを、03で並列にします。
「どこを触るか」を、先に申告させる
01で見た1本のレーン。あの順番待ちを、まるごと畳みます。BALs = Block-Level Access Lists(ブロック単位のアクセスリスト)。
速くする方法は「働き者を増やす」ではありません。同じ仕事を、同時に手をつけられるようにするだけ。そのために必要なのは、始める前に行き先が分かっていることです。
1. 配達に例えると
BALはこの「住所一覧」です。ブロックの中の全トランザクションが、どのアカウントとどのストレージに触るのかを、あらかじめ全部書き出しておきます。
2. 同じブロックで競争させる
上が01で見た逐次のレーン。下がBALがある場合。同じ時間軸で並べています。
下のレーンでは、ステートの読み出しが最初にまとめて走ります。行き先が全部分かっているので待つ必要がないからです。そのあとの計算も、互いに関係のないトランザクション同士なら同時に進みます。ただし全部が並列になるわけではありません。同じ場所を触るもの同士は、やはり順番を守る必要があります。
仕事の量はまったく同じです。トランザクションの数も、読むデータも、計算の中身も変わりません。変わったのは段取りだけ。EIPによれば、トランザクションの60〜80%は互いに関係のない場所を触るので、多くが同時に進められます。
このデモの差は、構造を体感するために大きめに描いてあります。実際にこの倍率で速くなるわけではありません。検証にはBALがあっても並列にできない部分(状態のルート計算、署名の検証、BAL自体の照合など)が残りますし、どれだけ効くかはブロックの中身しだいで大きく変わります。ここで見てほしいのは倍率ではなく、「待ちが消える」という形のほうです。
3. BALには何が書いてあるか
ブロックの中で触れられた全アドレスについて、この5種類が並びます。ポイントは、書き換えた場所については実行後の値そのものが入っていること。だから実行せずに状態を更新できます。
4. BALはどこに置かれるのか
よく誤解されるところです。ブロックの本体には入りません。
ヘッダに入るのは block_access_list_hash という短いハッシュだけ。BAL本体はブロックボディではなく ExecutionPayload のフィールドとして運ばれ、実行層クライアントが別途保存します。ヘッダのハッシュと突き合わせることで、中身がすり替えられていないと確かめられます。
5. おまけでついてくるもの
タダではありません。BALのぶんだけブロックは大きくなり、ネットワークを流れる量が増えます(平均で約70 KiB、最大では1 MiB程度)。伝播の負荷を下げるため、BALを別便で運ぶ案(EIP-8146)も別途検討されています。また、実際には触らない場所を「読む」と嘘の申告をして、検証側に無駄なディスク読み出しをさせる攻撃が想定されています。これにはガス残量で早い段階に弾く仕組みが仕様に入っています。並列化の効きめも、ブロックの中身しだいで大きく変わります。
これで2つの主役が揃いました。作る側(ePBS)と検証する側(BALs)。最後に、これが誰にどう影響するのかを見ます。
で、結局あなたに何が起きるのか
立場によって、必要なことはまったく違います。自分のところだけ開いてください。
🙂 ETHを持っている・使っている やることなし
アドレスも、残高も、送金の手順も変わりません。ウォレットの設定を触る必要もありません。裏側の段取りが変わるだけで、見えるところは今までどおりです。
🖥️ ステーカー・ノードを動かしている 準備が要る
- 両方のクライアントを更新する合意層と実行層、どちらも上げる必要があります。片方だけでは動きません
- PTCという新しい仕事が増える02で見た「間に合ったか」を見る係。定期的に当番が回ってくるので、対応したソフトとノードの用意が要ります
- 検証の負荷のかかり方が変わる重い実行の検証が締切の外に移り、スロットをまたぐようになります
🧑💻 アプリやコントラクトを作っている 前提の更新
- コードの書き換えは基本的に不要後方互換です。既存のコントラクトがそのまま壊れることはありません
- ただし値段の感覚が変わる状態を新しく作る操作、状態を読む操作、calldata、アクセスリストのコストが上がり、逆にトランザクションの基本料は下がる方向です
- 見積もりを取り直すガス代を決め打ちしている箇所があれば、テストネットで測り直しておくのが安全です
🌐 L2を使っている・運営している コスト構造の確認
- BAL対応は不要BALはL2のシーケンサーからは見えない仕組みで、シーケンサー側の変更は要りません
- calldata型は値上がりの影響を受けるcalldataの下限コストが上がるため(EIP-7976)、データをcalldataで載せているロールアップは負担が増えます。Blobを使っていれば影響は限定的です
- 長い目では追い風L1の余裕が増えれば、L2が使えるデータ枠も広がっていきます
いま、どのあたり?
この節の「いま」は 2026年8月 時点です。ここから先は動きます
- 入れるEIPを決めるおおむね固まりました
- 開発者用のネットワークで試す2026年8月時点はここ。クライアント同士の噛み合わせを詰めています
- 公開テストネット誰でも参加できる環境で本番同様に動かします
- メインネット本番で有効化
このサイトには日付を書いていません。予定は動くからです。最新の状況は下の2つで確認してください。
EIP-7773は本稿の時点でまだDraftステータスです。つまり「これで確定」と宣言された状態ではありません。過去のアップグレードでも、直前にEIPが外れたり、日程が数か月ずれたりしています。
入っているEIPは19本
このサイトで扱ったのは、そのうち2本です。
残り17本を見る
- EIP-7708ETHの送金がログを出すようになる。ウォレットや履歴の追跡が楽に
- EIP-7778返金なしのブロックガス会計。ガスの抜け道をふさぐ
- EIP-7843スロット番号を取得する命令を追加
- EIP-7954コントラクトの最大サイズを引き上げ
- EIP-7976calldataの下限コストを引き上げ
- EIP-7981アクセスリストのコストを引き上げ
- EIP-8037状態を新しく作るコストを引き上げ
- EIP-8038状態にアクセスするコストを引き上げ
- EIP-2780トランザクションの基本料を引き下げ
- EIP-7610ストレージが空でない場合のコントラクト生成を失敗させる
- EIP-7688将来のフォークで壊れにくい合意層のデータ構造に
- EIP-8045スラッシュされたバリデータをブロック提案から外す
- EIP-8061出金・統合の処理枠を広げる
- EIP-8282ビルダー向けの実行リクエスト。ePBSと関係します
- EIP-8024スタック操作の命令を追加(後方互換)
- EIP-7997どのチェーンでも同じアドレスになるファクトリを標準搭載
- EIP-8246SELFDESTRUCT時のETH焼却をやめる
値付けを変えるEIPが多いのは、01で見た「詰まっている締切」を緩めるために、重い操作の値段を実態に近づけているからです。
で、速くなるの? 安くなるの?
01で見たとおり、いまは締切の前がぎゅうぎゅうです。ePBSで重い仕事を後ろへ回し、BALsでその重い仕事自体を並列化する。この2つで初めて「上限を上げても大丈夫」と言える下地ができます。
「Glamsterdamで200M gasになる」「1万TPSになる」「MEVが70%減る」といった数字をネット上でよく見かけますが、いずれもEIPやEthereum Foundationの資料には根拠がありません。ガスリミットは今回のフォークが強制する値ではなく、バリデータが従来どおり投票で決めるものです。ePBSはMEVの量を減らす仕組みでもありません。減らすのは「リレーへの信頼」であって、MEVそのものではありません。そして手数料は最終的に需要しだいです。容量が増えても、それ以上に使われれば下がるとは限りません。
今回入らなかったもの、次に来るもの
ブロックの作り方と、その検証のしかたを、同時に作り変える。
最初の1行に戻ってきました。2つのEIPが何をしているかが、いまは具体的に見えているはずです。