はじめに
初めまして。
『DApps開発入門』という本や色々記事を書いているかるでねです。
以下でも情報発信しているので、興味ある記事があればぜひ読んでみてください！
今回は「Ethereumアップグレード名の付け方をまとめたEIP8133」についてまとめていきます。
Ethereumのアップグレードには、Frontier、London、Altair、Shapella、BPO1のように、時期や対象レイヤーによって異なる名前が付いています。
EIP8133は、これらの命名規則を1つの参照先として整理する提案です。
以下にまとめられているものを解説しながらまとめていきます。
概要
EIP8133は、Ethereumネットワークアップグレードの命名規則を整理する情報提供型のEIPです。
新しいプロトコル機能やクライアント実装の変更を定めるものではなく、アップグレード名の由来、対象レイヤー、統合名、Blob Parameter Only（BPO）アップグレードの番号規則をまとめています。
Ethereumのアップグレード名は、初期のマイルストーン名から始まり、歴史都市、氷河名、実行レイヤーの都市名、コンセンサスレイヤーの星名、Merge後の統合名、BPO番号へと広がってきました。
それぞれの名前は単なる愛称ではなく、どの時代の、どの種類のアップグレードなのかを示す手がかりになります。
命名カテゴリの全体像は以下です。
上図では、アップグレード名が6つの系統に分かれることを示しています。
初期アップグレードや氷河名は歴史的な文脈が強く、実行レイヤー名とコンセンサスレイヤー名はMerge後のレイヤー分離を反映しています。
動機
Ethereumでは、PoW（Proof of Work）からPoS（Proof of Stake）への移行、実行レイヤーとコンセンサスレイヤーの分離、Blob容量の段階的な拡張など、複数の軸でネットワークアップグレードが続いています。
その結果、アップグレード名を見ただけでは、実行レイヤーの変更なのか、コンセンサスレイヤーの変更なのか、両方をまとめた呼び名なのかが分かりにくくなります。
たとえば、ShanghaiとCapellaはそれぞれ独立したレイヤー名です。
一方で、Shapellaは外部コミュニケーションで使われる統合名です。
この違いが曖昧なままだと、仕様、クライアント実装、運用手順、コミュニティでの会話がずれやすくなります。
EIP8133は、既に使われてきた命名慣習をまとめ、アップグレード名の解釈をそろえるための参照先を提供します。
ただし、将来の命名を強制的に固定する提案ではありません。
今後のアップグレード名は、引き続きコミュニティ調整と個別のMeta EIPによって決まります。
仕様
EIP8133の仕様は、アップグレード名を以下のカテゴリごとに整理しています。
| カテゴリ | 命名の考え方 | 例 |
|---|---|---|
| 初期アップグレード | 開発段階や重要な節目を表す名前 | Frontier、Homestead |
| 歴史都市 | Metropolis期の歴史的につながる都市名 | Byzantium、Constantinople、Istanbul |
| 氷河名 |
Difficulty Bomb への対応を示す氷河名 |
Muir Glacier、Arrow Glacier、Gray Glacier |
| 実行レイヤー | DevconやDevconnectの開催都市名 | Berlin、London、Shanghai、Osaka |
| コンセンサスレイヤー | アルファベット順の星名 | Altair、Bellatrix、Capella、Deneb |
| 統合名 | 同時アップグレード時の合成名 | Shapella、Dencún、Pectra、Fusaka |
| BPO |
BPO<n> の連番 |
BPO1、BPO2、BPO3 |
初期アップグレード
初期のEthereumアップグレードでは、ネットワークの実験的な状態、重要なマイルストーン、実際に出荷された機能に紐づくテーマ名が使われました。
主な例は以下です。
| 名前 | 位置づけ |
|---|---|
| Frontier | Ethereumメインネットの初期段階 |
| Frontier Thawing | Frontier後の制限緩和 |
| Homestead | より安定したネットワーク段階への移行 |
| DAO Fork | The DAO事件への対応 |
| Tangerine Whistle | サービス妨害攻撃への緊急対応 |
| Spurious Dragon | 攻撃で作成された空アカウントへの対応 |
FrontierやHomesteadは、ネットワークが本番運用へ近づいていく節目を表す名前です。
Tangerine WhistleやSpurious Dragonは、当時の攻撃対応や状態整理といった機能面の文脈を反映しています。
歴史都市
Metropolis期には、歴史的につながる都市名が使われました。
Byzantium、Constantinople、St. Petersburg、Istanbulは、段階的に進むプロトコル成熟を表す名前として採用されています。
| 名前 | 補足 |
|---|---|
| Byzantium | Metropolis期の最初の主要アップグレード |
| Constantinople | Byzantium後の主要アップグレード |
| St. Petersburg | Constantinopleと同じブロック高で有効化された調整 |
| Istanbul | Metropolis期後半の主要アップグレード |
St. Petersburgは、Constantinopleで含まれる予定だった EIP1283 を取り除くために同じブロック高で有効化されました。
この時期の命名は、頻繁なアップグレードの中で一貫した名前を付けるために使われています。
EIP1283については以下の記事を参考にしてください。
氷河名
Difficulty Bomb への対応を主目的とするアップグレードでは、氷河に由来する名前が使われました。
Difficulty Bomb は、PoWからPoSへの移行を促すために、採掘難易度を段階的に上げる仕組みです。
氷河名は、採掘難易度が進行する「Ice Age」を遅らせる一時的な対応であることを表しています。
| 名前 | 役割 |
|---|---|
| Muir Glacier |
Difficulty Bomb を延期 |
| Arrow Glacier |
Difficulty Bomb を延期 |
| Gray Glacier |
Difficulty Bomb を延期 |
Gray Glacierという名前には、The Mergeが近づいていた文脈も含まれています。
Gray Glacierは別の氷河へ合流する氷河であり、EthereumがPoSへ合流していく状況と重ねられています。
実行レイヤー
実行レイヤーのアップグレード名には、DevconまたはDevconnectの開催都市名を使えます。
この慣習はDevcon開催都市から始まり、Devconnect開催都市にも広がりました。
主な例は以下です。
| 実行レイヤー名 | 由来 |
|---|---|
| Berlin | Devcon 0 |
| London | Devcon 1 |
| Paris | EthCC |
| Shanghai | Devcon 2 |
| Cancun | Devcon 3 |
| Prague | Devcon 4 |
| Osaka | Devcon 5 |
| Amsterdam | Devconnect 1 |
| Bogotá | Devcon 6 |
Parisは例外で、DevconやDevconnectではなくEthCCに由来します。
これはThe Mergeにおける実行レイヤー側のアップグレード名として、Ethereumコミュニティの大きなイベントを記念するために使われました。
今後の実行レイヤー名でも、DevconやDevconnectの開催都市を参照できます。
提案では、Istanbul、Bangkok、Buenos Aires、Mumbaiなども過去または発表済みの開催都市として挙げています。
コンセンサスレイヤー
コンセンサスレイヤーのアップグレード名は、アルファベット順の星名です。
各アップグレード名は、コミュニティの合意に基づいて認識された星名である必要があります。
この規則は、Beacon Chainの開始後に確立されました。
最初のコンセンサスレイヤーアップグレードであるAltairを起点として、Bellatrix、Capella、Deneb、Electra、Fulu、Gloas、Hezeのように頭文字が進んでいきます。
| 順序 | コンセンサスレイヤー名 |
|---|---|
| A | Altair |
| B | Bellatrix |
| C | Capella |
| D | Deneb |
| E | Electra |
| F | Fulu |
| G | Gloas |
| H | Heze |
星名を使うことで、政治的な偏りが少なく、国際的に認識しやすい名前を選べます。
さらに、アルファベット順に進めることで、将来のアップグレードにも対応しやすくなります。
The Merge
The Mergeは、Ethereumの命名規則の中でも特別な扱いです。
その後の同時アップグレードでは、実行レイヤー名とコンセンサスレイヤー名を組み合わせた統合名が使われることがあります。
しかし、The Mergeでは統合名を採用していません。
The Mergeでは、まずコンセンサスレイヤー側でBellatrixが有効化されました。
Bellatrixは、Beacon Chainが実行レイヤーの移行を認識し、調整できるようにするアップグレードです。
その後、実行レイヤー側のParisが有効化され、EthereumメインネットはPoWからPoSへ移行しました。
| 項目 | 内容 |
|---|---|
| コンセンサスレイヤー側 | Bellatrix |
| Bellatrix有効化 | 2022年9月6日、Epoch 144896 |
| 実行レイヤー側 | Paris |
| Paris有効化 | 2022年9月15日 06:42 UTC |
| 移行条件 |
Terminal Total Difficulty 到達 |
| 移行ブロック | 15,537,393 |
| 正規の呼び名 | The Merge |
Bellatrixによって運用上の移行が始まり、Parisによってプロトコル移行が完了しました。
この一連のイベント全体は、正規にはThe Mergeと呼ばれます。
統合名
Merge後のアップグレードでは、実行レイヤーとコンセンサスレイヤーのアップグレードが同時に有効化されることがあります。
その場合、それぞれのレイヤー名は独立した正規名として残ります。
ただし、外部コミュニケーションや調整をしやすくするために、2つの名前を組み合わせた統合名が使われることがあります。
Merge後の命名関係は以下です。
統合名は便利な呼び方ですが、仕様、クライアント実装、プロトコルドキュメントで使う正規名を置き換えるものではありません。
実装や仕様の文脈では、ShanghaiやCapellaのようなレイヤーごとの名前が正規名として扱われます。
主な統合名は以下です。
| 統合名 | 由来 |
|---|---|
| Shapella | ShanghaiとCapella |
| Dencún | DenebとCancún |
| Pectra | PragueとElectra |
| Fusaka | FuluとOsaka |
| Glamsterdam | GloasとAmsterdam |
| Hegotá | HekaとBogotá（提案上の例） |
これらの統合名は、エコシステム全体で会話しやすくするための情報上の呼び名です。
統合名だけで対象変更を判断せず、必要に応じて実行レイヤー名とコンセンサスレイヤー名に分けて確認することが重要です。
BPO
BPOアップグレードは、Blobに関するパラメータだけを変更するネットワークアップグレードです。
Blob targetやBlob maxなどの容量パラメータを調整し、追加のプロトコル変更は含みません。
この仕組みは、Ethereumのデータ可用性を段階的に拡張するために使われます。
EIP7892は、BPOアップグレードの仕組みと BPO<n> という番号規則を定めています。
BPO名では、n が1から始まる単調増加の正の整数です。
そのため、BPO1、BPO2、BPO3のように順番がそのまま名前になります。
EIP8134（BPO1）については以下の記事を参考にしてください。
EIP8135（BPO2）については以下の記事を参考にしてください。
BPO名が都市名や星名を使わないのは、変更範囲が限定されたテンプレート型のアップグレードだからです。
説明的な名前を付けるより、連番にした方が順序と対象を直接確認できます。
また、BPOアップグレードは単独でデプロイされる場合も、より大きなアップグレードと一緒にデプロイされる場合もあります。
その場合でも、数値識別子が正規の参照名として残ります。
補足
命名規則の位置づけ
EIP8133は、将来のアップグレード名を一方的に決める権限を作る提案ではありません。
既に観測されている慣習を整理し、仕様、実装、調整、コミュニティ会話で同じ名前を同じ意味で使えるようにするための参照先です。
この位置づけは重要です。
Ethereumのアップグレード名は、技術仕様だけでなく、コミュニティ調整、イベントの歴史、ロードマップ上の意味を含みます。
そのため、名前の決定は個別アップグレードのMeta EIPやコミュニティ合意に委ねられます。
統合名を正規名として扱わない理由
ShapellaやPectraのような統合名は、会話や告知では非常に便利です。
しかし、クライアント実装や仕様では、実行レイヤーとコンセンサスレイヤーで対象変更が異なります。
統合名だけを正規名として扱うと、どちらのレイヤーの仕様を指しているのかが曖昧になります。
そのため、統合名は外部コミュニケーション用の呼び名として扱い、仕様上の正規名はShanghaiやCapellaのようなレイヤーごとの名前として残します。
この分離によって、読みやすさと実装上の正確さを両立できます。
BPOを連番にする理由
BPOアップグレードは、Blob容量のパラメータを段階的に調整する仕組みです。
変更対象が限定されているため、都市名や星名のようなテーマ名を付けると、かえって意味の確認に余計な手間が増えます。
BPO<n> の書式であれば、順番、対象範囲、過去アップグレードとの対応関係を直接追えます。
BPO1、BPO2、BPO3のように並べるだけで、Blob容量調整の進行順が分かる設計です。
互換性
EIP8133は情報提供型の提案であり、プロトコル変更を導入しません。
そのため、既存のクライアント、スマートコントラクト、ネットワーク運用、アプリケーションに対する互換性の問題はありません。
セキュリティ
EIP8133は命名規則を整理する提案であり、新しい実行ルール、検証条件、オンチェーン処理を追加しません。
そのため、この提案自体によるセキュリティ上の変更はありません。
引用
最後に
今回は「Ethereumアップグレード名の付け方をまとめたEIP8133」についてまとめてきました。
Ethereumのアップグレード名は、初期のマイルストーン、歴史都市、氷河、実行レイヤーの都市名、コンセンサスレイヤーの星名、統合名、BPO番号という複数の規則で成り立っています。
EIP8133は、これらを1つの参照先にまとめることで、仕様、実装、運用、コミュニティ会話の間で名前の解釈がずれにくくなるようにしています。
他でも色々記事を書いているのでぜひよろしければ読んでいってください！