Radio Script — Glamsterdam: ePBS and BALs

Today's theme is a coming Ethereum upgrade called Glamsterdam. And here's the strange part: it rebuilds two completely different things at the same time. How a block gets made, and how a block gets checked.

今日のテーマは、イーサリアムのこれから来るアップグレード、Glamsterdam(グラムステルダム)です。変わっているのは、まったく別のことを二つ同時に作り変える点なんです。ブロックの作り方と、ブロックの検証のしかた。

Right instinct. Normally you'd do one, then the other. But these two problems turned out to be connected, and fixing only one wouldn't have helped much.

いい勘です。普通なら片方をやってから、もう片方ですよね。でもこの二つの問題はつながっていて、片方だけ直してもあまり意味がなかったんです。

Those are the good ones. Let's start with the name — it's a little silly, and it tells you something real.

それがいい質問なんですよ。まず名前から始めましょう。ちょっとふざけた名前ですが、ちゃんと意味があります。

Ethereum runs as two chains locked together. There's a consensus layer and an execution layer. Each of them gets its own upgrade name, and this time the consensus name is Gloas — that's spelled G, L, O, A, S — and the execution name is Amsterdam.

イーサリアムは、二本のチェーンが噛み合って動いています。合意層と実行層です。それぞれにアップグレードの名前が付いていて、今回、合意層の名前は Gloas(グロアス)、綴りは G、L、O、A、S です。そして実行層の名前が Amsterdam(アムステルダム)。

Gloas plus Amsterdam gives you Glamsterdam. Consensus-layer names come from stars, in order. Execution-layer names come from cities that hosted Devconnect. They're technically separate forks, but they switch on together as one network upgrade.

Gloas と Amsterdam で Glamsterdam。合意層の名前は星の名前を順番に使い、実行層の名前は Devconnect(デブコネクト)が開かれた都市から取ります。技術的には別々のフォークですが、一つのネットワークアップグレードとして同時に有効になります。

That's the whole story in one word. And there's a mascot, by the way. It's a polar bear.

一語で全部言っているんです。ちなみにマスコットもいます。ホッキョクグマです。

There's an actual process for picking one.

選ぶための手順がちゃんとあるんですよ。

You've got the pattern exactly right. The Merge moved Ethereum to proof of stake. Shapella let people withdraw staked ether. Dencun brought in blobs, and layer two fees dropped hard — probably the one most ordinary people actually felt in their wallet. Then Pectra improved validator operations, and Fusaka, in December of 2025, widened data availability for layer two even further.

流れの捉え方はまさにその通りです。The Merge(ザ・マージ)でイーサリアムはプルーフ・オブ・ステークに移りました。Shapella(シャペラ)でステーキングしたイーサが引き出せるようになりました。Dencun(デンクン)でブロブが入って、レイヤーツーの手数料が大きく下がった。これはたぶん、普通の人が財布で実感した唯一の変化です。そのあと Pectra(ペクトラ)が検証者まわりと口座を改善して、2025年12月の Fusaka(フサカ)がレイヤーツー向けのデータ可用性をさらに広げました。

And Glamsterdam turns the camera around. This one is about how much layer one itself can handle. It's nineteen improvement proposals in total, but two of them carry the whole story.

そして Glamsterdam でカメラの向きが変わります。今回は、レイヤーワン自身がどれだけ処理できるかという話です。全部で十九件の改善提案が入っていますが、そのうち二つが物語のすべてを背負っています。

Let's do it in three pieces. First: time. Ethereum runs on a twelve-second heartbeat. Each twelve-second window is called a slot. In every slot, one validator is picked by lottery to publish the block. That role is called the proposer.

三つに分けましょう。まず時間です。イーサリアムは十二秒の心拍で動いています。この十二秒の区切りをスロットと呼びます。スロットごとに、検証者の中から抽選で一人が選ばれて、ブロックを出します。この役割を proposer(プロポーザー)と呼びます。

Exactly. It's a role, not a person. Everyone else validates and votes.

その通りです。人ではなく役割です。それ以外の全員は検証して投票します。

Piece two is who actually builds the block. And here's the surprise: the proposer usually doesn't build it. They outsource it to specialists called builders.

二つ目は、実際に誰がブロックを作るか。ここが意外なんですが、proposer は普通、自分では作らないんです。builder(ビルダー)と呼ばれる専門家に外注します。

Because a block is worth money. There are transaction fees, and there's profit that depends on the order you put transactions in. Builders are specialists at squeezing the most value out of that ordering. They can usually extract more than the proposer could alone.

ブロックにはお金の価値があるからです。取引手数料があり、そして取引をどんな順番に並べるかで生まれる利益があります。builder はその並べ方から価値を最大限に絞り出す専門家です。proposer が一人でやるより、たいてい多く引き出せます。

Right. But there's a catch. The builder won't reveal the contents before getting paid — someone could just steal their ordering. And the proposer won't sign something they can't see.

そうです。ただ、ここに引っかかりがあります。builder は代金を受け取る前に中身を明かしたくない。並べ方を盗まれてしまいますから。そして proposer は、見えないものに署名したくない。

So a third party wedges into the middle. It's called a relay. The relay holds the block, confirms it's real, and the proposer signs blind — without seeing inside. Today the large majority of blocks are built this way — the figure is often quoted as around nine in ten, though it moves day to day.

そこで第三者が間に割って入ります。relay(リレー)と呼ばれます。relay がブロックを預かり、本物だと確認し、proposer は中身を見ないまま署名する。今日、ブロックの大多数がこの経路で作られています。よく十のうち九という数字が挙げられますが、これは日々動く数字です。

And that's precisely the problem the first big proposal attacks. Hold that thought.

まさにそこを、一つ目の大きな提案が突きます。その感覚を覚えておいてください。

Piece three is validation — checking a block once it arrives. And here's a quiz for you. When a computer validates a block, what do you think eats the most time? Is it the Ethereum Virtual Machine — the E, V, M — actually computing the transactions? Or is it something else?

三つ目は検証です。届いたブロックを確かめる作業ですね。ここでクイズです。コンピュータがブロックを検証するとき、一番時間を食うのは何だと思いますか。Ethereum Virtual Machine(イーサリアム・バーチャル・マシン)、略して E、V、M が実際に取引を計算する時間でしょうか。それとも別の何かでしょうか。

Almost everyone guesses that. It's waiting on the disk.

ほとんどの人がそう答えます。実はディスク待ちなんです。

The computation finishes fast. But all the balances and storage live on disk, scattered everywhere, so the machine spends most of its time waiting on random reads. And the cruel part is you can't know what you'll need until you execute — so you can't fetch it early. Which means it's single file. Transaction two waits for one. Three waits for two. Even when they have absolutely nothing to do with each other.

計算自体はすぐ終わります。でも残高や保存領域はぜんぶディスクの上に、あちこち散らばって置かれている。だから機械は、そこへのランダムな読み出しを待つことに時間の大半を使います。しかも意地悪なことに、何を読むことになるかは実行してみるまで分からない。だから先に取ってくることもできないんです。つまり一列縦隊になります。取引の二番目は一番目を待ち、三番目は二番目を待つ。互いにまったく関係がなくてもです。

Remember that feeling. That's the second big proposal.

その違和感を覚えておいてください。それが二つ目の大きな提案です。

Worse than that. There's a deadline inside the slot. Votes — attestations — are due about four seconds in. So today, the block has to travel across the network and get all its checking done before that four-second mark.

もっと厳しいです。スロットの中に締め切りがあるんです。投票、つまり attestation(アテステーション)は、だいたい四秒の時点で締め切られます。だから今日は、ブロックがネットワークを渡りきって、検証も全部、その四秒の線より前に終わっていないといけない。

Mostly light work. The back two-thirds of the slot is comparatively idle. Everything is crammed against the front.

ほとんど軽い仕事です。スロットの後ろ三分の二は、相対的に暇なんです。全部が前に押し込まれている。

It's hard because you can't just move the deadline. You have to change what needs to finish by it.

難しいんです。締め切りを動かすわけにはいかないので。締め切りまでに終わらせるべきものの方を、変えないといけない。

So. Headliner number one. It's called ePBS. That's spelled with a small e, then capital P, B, S. It stands for enshrined Proposer-Builder Separation, and it's improvement proposal seventy-seven thirty-two.

では、主役の一つ目。ePBS(イーピービーエス)と呼ばれます。綴りは小文字の e に、大文字の P、B、S。enshrined Proposer-Builder Separation、日本語にすると「プロトコルに組み込まれた、提案者とビルダーの分離」。改善提案の番号は七七三二番です。

Written into the protocol itself. Today, that builder-proposer trade happens outside the rules, with the relay holding everything together. Enshrining it means the rules handle the trade directly.

プロトコルそのものに書き込まれる、ということです。今日は builder と proposer の取引がルールの外側で起きていて、relay が全体をつなぎ止めている。組み込むというのは、ルールが直接この取引を扱うようになる、という意味です。

It becomes optional. Here's the trick, and it's a genuinely clever one. Builders register in the protocol and put up a stake — as little as one ether. When a builder bids, that bid is signed and binding.

任意になります。ここが仕掛けで、本当によくできているんです。builder はプロトコルに登録して、ステークを預けます。最低で一イーサから。そして builder が入札すると、その入札には署名が付いていて、拘束力を持ちます。

This is my favorite part. When the proposer publishes the block containing the winning bid, the builder's balance goes down. Automatically.

ここが私の一番好きなところです。proposer が、落札した入札を含むブロックを公開すると、builder の残高が減ります。自動的に。

Nobody.

誰でもありません。

There's no collector. Every node processing that block runs the same rule, and inside that rule the builder's balance simply decreases. The builder doesn't get to agree. The builder doesn't get to refuse. It just happens, everywhere, at once.

取り立て役がいないんです。そのブロックを処理するすべてのノードが同じルールを走らせて、そのルールの中で builder の残高がただ減る。builder が同意する余地もない。拒否する余地もない。ただ、あらゆる場所で、一斉に起きるんです。

Good way to put it. And that changes everything — because now consider what happens if the builder breaks their promise and never reveals the contents.

いい言い方です。そしてこれがすべてを変えます。というのも、builder が約束を破って中身を一度も明かさなかったら、何が起きるかを考えてみてください。

The proposer got paid anyway. That's called unconditional proposer payment. And once that's true, you don't need a relay standing there guaranteeing anyone's behavior.

それでも支払われています。これを「proposer への無条件支払い」と呼びます。そしてこれが成り立つと、誰かの振る舞いを保証するために relay が立っている必要がなくなるんです。

That's the elegant part. Now — a slot can end three ways. Full means the builder revealed the contents as promised, the normal case. Empty means the builder went quiet: only the consensus part lands on chain, but the proposer still gets paid. Skipped means no block appeared at all, so the bid never processed and nobody pays anything.

そこが美しいところです。さて、スロットの終わり方は三通りあります。Full(フル)は、builder が約束通り中身を明かした場合。これが普通のケースです。Empty(エンプティ)は builder が黙り込んだ場合で、合意の部分だけがチェーンに載りますが、proposer にはそれでも支払われます。Skipped(スキップド)はそもそもブロックが出なかった場合で、入札が処理されていないので、誰も何も払いません。

You just independently derived a known open problem. It's called the free option problem, and it's written down as an unresolved issue in the proposal's own security considerations.

今あなたは、既に知られている未解決問題を独力で導き出しました。free option problem(フリー・オプション・プロブレム)、無料オプション問題と呼ばれます。提案自身のセキュリティ考慮事項の中に、未解決の課題として書かれています。

Not yet. There are proposed mitigations — variable penalties for builders who do it. But to be straight with you: it's open. The proposer is protected; the slot still gets wasted. One more piece, though. All this creates a new job, called the P, T, C — the Payload Timeliness Committee.

まだです。緩和策の案はあります。これをやった builder に対する可変のペナルティなどですね。でも正直に言うと、未解決です。proposer は守られます。それでもスロットは無駄になる。もう一つだけ。この仕組みから新しい仕事が生まれます。P、T、C と呼ばれるもので、Payload Timeliness Committee、ペイロード適時性委員会です。

Each slot, five hundred and twelve validators get pulled from that slot's committee, and they answer exactly one question: did the promised contents show up on time? Yes or no.

スロットごとに、そのスロットの委員会から五百十二人の検証者が抜き出されて、たった一つの質問に答えます。約束された中身は、時間内に現れたか。はい、か、いいえ。

They don't check correctness at all. Just the clock. Which means it takes milliseconds and comfortably beats the deadline. The heavy correctness checking gets pushed later, into the roomy part of the slot.

正しさは一切見ません。時計だけです。だからミリ秒で終わって、締め切りに余裕で間に合う。重い正しさの検証は、あとに回されます。スロットの、広々とした側へ。

That's exactly it. And I should say one honest thing here. The total propagation time doesn't get shorter. The same bytes still have to travel, and splitting them into two deliveries actually makes the end-to-end total slightly longer.

まさにそれです。そしてここで一つ、正直なことを言っておきます。伝播にかかる合計時間は短くなりません。同じバイト数は結局運ばれるわけですし、二回の配達に分けることで、端から端までの合計はむしろ少し長くなります。

The window gets wider, not the work smaller. Only a small slice now has to finish before the deadline. That headroom is what makes everything else possible.

窓が広くなるのであって、仕事が小さくなるのではありません。今は、ごく一部だけが締め切り前に終わればいい。その余裕こそが、他のすべてを可能にしているんです。

This is the single-file problem. The proposal is called B, A, Ls — people say "bals" — short for Block-Level Access Lists. Improvement proposal seventy-nine twenty-eight.

これが一列縦隊の問題です。提案は B、A、L に複数形の s を付けて、みんな「バルズ」と呼びます。Block-Level Access Lists、ブロック単位のアクセスリストの略です。改善提案の番号は七九二八番。

Parcel delivery. Imagine you're a courier, but you don't get the address list — you only learn the next address after finishing the current delivery.

宅配便です。あなたが配達員だと想像してください。ただし住所の一覧はもらえない。今の配達を終えて初めて、次の住所が分かるんです。

That's Ethereum validation today. Now imagine someone hands you the complete address list before you leave the depot.

それが今日のイーサリアムの検証です。では、営業所を出る前に、住所の全一覧を手渡されたとしましょう。

Same parcels. Same total work. Only the planning changed. A Block-Level Access List is that address list — every transaction in the block declares upfront which accounts and which storage it's going to touch.

同じ荷物、同じ総量の仕事。変わったのは段取りだけです。ブロック単位のアクセスリストとは、その住所一覧のこと。ブロックの中のすべての取引が、どの口座とどの保存領域に触れるかを、あらかじめ申告するんです。

All the reads fire together. And then the computation runs in parallel for transactions that don't overlap. According to the proposal, somewhere between sixty and eighty percent of transactions touch completely separate things.

読み出しが一斉に走ります。そしてそのあとの計算も、重ならない取引同士なら並列で進みます。提案によれば、取引のおよそ六十から八十パーセントは、まったく別々の場所に触れています。

They still have to take turns. If two transactions touch the same storage, order matters and you can't cheat that. I want to be clear about this because it's easy to oversell — it is not a magic multiplier.

そちらは順番を守るしかありません。二つの取引が同じ保存領域に触れるなら、順序に意味があるので、そこはごまかせない。ここははっきりさせておきたいんです。誇大に語られやすいところなので。魔法の倍率ではありません。

For every address the block touches: which storage slots got written, which got only read, and the changes to balance, nonce, and code. And here's the clever bit — for anything written, it records the value after execution.

ブロックが触れたすべてのアドレスについて、どの保存領域に書き込んだか、どこを読んだだけか、そして残高と nonce(ナンス)とコードの変化です。そして巧いのがここで、書き込んだものについては、実行した後の値そのものを記録します。

Because a node can update its state just by reading the list. It doesn't have to re-execute anything. That makes syncing lighter, and it also helps zero-knowledge proving, because you know the dependencies in advance and can split the work up.

ノードがリストを読むだけで、自分の状態を更新できるからです。もう一度実行し直す必要がない。おかげで同期が軽くなりますし、ゼロ知識証明にも効きます。依存関係が先に分かるので、作業を分割できるんです。

There is, and I don't want to skip it. It's roughly seventy kibibytes on average — call it seventy kilobytes — and in bad cases it can reach around one mebibyte, about one megabyte. That's real extra traffic on the network.

あります。そこは飛ばしたくありません。平均でおよそ七十キビバイト、七十キロバイトほどと思ってください。そして悪い場合には一メビバイト、およそ一メガバイト近くまで届きます。これはネットワークにかかる、実際の追加の通信量です。

There's an anticipated attack where someone declares reads for storage they never actually touch, just to make validators do pointless disk work. The specification includes a gas-based early rejection to blunt that. And how much the parallelism actually helps varies a lot depending on what's in the block.

想定されている攻撃があります。実際には触れもしない保存領域を「読む」と申告して、検証者に無駄なディスク作業をさせるというものです。仕様には、これを鈍らせるためにガスに基づく早期の拒否が入っています。それから、並列化がどれだけ効くかは、ブロックの中身によって大きく変わります。

Nothing. Your address, your balance, how you send — all identical. No wallet setting to touch. The choreography backstage changes; the stage looks the same.

何も変わりません。アドレスも、残高も、送り方も、まったく同じです。触るべき財布の設定もありません。舞台裏の段取りが変わるだけで、舞台の見た目は同じです。

Real work. Update both clients, consensus and execution — one alone won't run. And that new Payload Timeliness Committee duty comes around on a rota, so you need software ready for it.

実務があります。クライアントを両方、合意層と実行層の両方を更新してください。片方だけでは動きません。それから、あの新しいペイロード適時性委員会の当番が定期的に回ってくるので、対応したソフトウェアを用意しておく必要があります。

Mostly no code changes; it's backward compatible. But prices shift — creating state, reading state, call data, and access lists get more expensive, while the base cost of a transaction comes down. If you've hardcoded a gas number anywhere, re-measure it on a test network.

コードの書き換えはほぼ不要です。後方互換なので。ただ値段が動きます。状態を新しく作ること、状態を読むこと、call data(コールデータ)、それにアクセスリストが高くなり、一方で取引の基本料は下がります。どこかにガスの数値を直接書き込んでいるなら、テストネットワークで測り直してください。

Here the easy answer is wrong. The access lists are invisible to layer two sequencers, so no changes there. But a separate proposal in this upgrade raises the floor cost of call data. If your rollup posts batches as call data, you pay more. If you post to blobs, you're mostly fine.

ここは簡単な答えの方が間違っています。アクセスリスト自体はレイヤーツーのシーケンサーからは見えないので、そちら側の変更は要りません。でも、このアップグレードには別の提案が入っていて、call data の下限コストを引き上げます。もしあなたのロールアップがバッチを call data として載せているなら、負担が増えます。ブロブに載せているなら、影響はほぼありません。

I'm going to disappoint you carefully. You will see claims online that Glamsterdam brings two hundred million gas, or ten thousand transactions per second, or a seventy percent cut in M, E, V — that's maximal extractable value.

慎重にがっかりさせますね。ネット上ではこんな主張を見かけます。Glamsterdam で二億ガスになる、毎秒一万取引になる、M、E、V が七十パーセント減る。M、E、V というのは maximal extractable value、最大抽出可能価値のことです。

None of them have a basis in the proposals or in Ethereum Foundation material.

どれ一つとして、提案にもイーサリアム財団の資料にも根拠がありません。

One at a time. The gas limit today sits around sixty million, and this upgrade mandates no number at all. Validators set it by voting, as they always have. What Glamsterdam does is make raising it defensible — because the heavy work moved out from under the deadline, and then got parallelized.

一つずつ行きましょう。ガスの上限は今、六千万あたりです。そしてこのアップグレードは、いかなる数値も強制しません。検証者が投票で決めます。これまでずっとそうだったように。Glamsterdam がやるのは、上限を上げることを筋の通った話にすることです。重い仕事が締め切りの下から出て、そのうえで並列になったからこそ、そう言えるわけです。

Precisely. Second: ePBS is not a mechanism for reducing extractable value. What it removes is trust in the relay. The value extraction itself is untouched.

その通りです。二つ目。ePBS は抽出可能価値を減らすための仕組みではありません。取り除くのは relay への信頼です。価値の抽出そのものには手を触れていません。

Completely different. And third, on fees — fees follow demand in the end. More capacity doesn't mean cheaper if usage grows faster than the capacity does.

完全に別物です。そして三つ目、手数料について。手数料は結局のところ需要に従います。容量が増えても、それ以上の速さで使われれば、安くなるとは限りません。

Two worth knowing. There was a proposal to halve slots from twelve seconds to six. It was declined — it would have delayed real-time zero-knowledge proving, implementations weren't mature enough, and if slots get restructured later you'd be re-tuning everything twice.

知っておく価値のあるものが二つ。スロットを十二秒から六秒へ半分にする提案がありました。見送られています。リアルタイムのゼロ知識証明を遅らせてしまうこと、実装が十分に成熟していなかったこと、そして後でスロットの構成を組み直すなら、全部を二度調整し直すことになるからです。

Censorship resistance — a proposal called FOCIL. Shipping it alongside ePBS left too little time to verify how the two interact. So it headlines the next upgrade, which is called Hegotá.

検閲への耐性です。FOCIL(フォシル)と呼ばれる提案ですね。ePBS と同時に出すと、二つがどう影響し合うかを検証する時間が足りませんでした。それで次のアップグレードの主役になります。Hegotá(ヘゴタ)という名前です。

There's always a next. That's sort of the point.

常に次があります。まあ、それが要点でもあるんですが。

That these two changes are the same idea approached from opposite ends. ePBS says: the heavy part of a block shouldn't have to arrive before the deadline. Access lists say: the heavy part shouldn't have to be done one item at a time. Neither one alone would have been enough.

この二つの変更が、同じ発想を逆の端から攻めたものだ、ということです。ePBS はこう言っています。ブロックの重い部分が、締め切りより前に届く必要はない。アクセスリストはこう言っています。重い部分を、一件ずつ順にやる必要はない。どちらか片方だけでは足りなかったんです。

Rebuilding how blocks are made, and how they get checked, both at once.

ブロックの作り方と、その検証のしかたを、同時に作り変える。

Good instinct, and I'll be honest to the end. As of August 2026, the meta proposal that bundles this whole upgrade is still in draft status. The list of included proposals can change. Dates have slipped by months on past upgrades, and proposals have been dropped at the last minute.

いい勘です。最後まで正直に言いますね。2026年8月の時点で、このアップグレード全体をまとめているメタ提案は、まだドラフト状態です。含まれる提案の一覧は変わりえます。過去のアップグレードでは日程が数か月ずれたこともありますし、提案が土壇場で外されたこともあります。

Understand the shape. The shape is solid; the specifics are still moving. That's the honest version.

形を掴んでください。形は固いです。細かいところはまだ動いています。それが正直な言い方です。

Thanks for asking the dumb questions. They were the right ones.

バカな質問をありがとうございました。あれが正しい質問でしたよ。