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

オリジナル | Odaily Planet Daily jk

イーサリアムの次期アップグレードであるGlamsterdamは、コア開発者の間ではThe Merge以来最大のプロトコルレベルの再構築とみなされています。この名前は2つの要素の組み合わせから来ています。実行レイヤーのアップグレードは、以前のDevconnectイベントの開催地にちなんで「Amsterdam」という名前が残され、コンセンサスレイヤーのアップグレードは星にちなんで「Gloas」と名付けられています。前回のFusakaアップグレードに続き、Glamsterdamはネットワークがトランザクションを処理し、増大するデータベースを管理する方法を再編成することでL1のスケーラビリティを向上させ、イーサリアムがブロックを作成および検証する方法を根本的に更新します。

今回のアップグレードは、以下の3つの主要な目標を中心に展開されます。

• 高速処理（並列化）：ネットワークがデータ依存関係を記録する方法を再編成することで、トランザクションを一つずつゆっくりと処理するのではなく、多数のトランザクションを同時に安全に処理できるようにする。
• スケーラビリティ：ブロック生成と検証という重いワークロードを分割することで、ネットワークが速度を落とすことなく、より多くのデータを伝播するための時間を確保できる。
• 持続可能性：ネットワーク料金を調整して、新しいデータを保存するための長期的なハードウェアコストを正確に反映させ、ハードウェア性能の低下を回避しながら、将来のガス制限の引き上げに対する障害を取り除く。

今回のアップグレードにおける2つの主要な提案は、コンセンサス層と実行層に焦点を当てたものである。

主要なヘッドライナー提案は2つあります。出典：イーサリアム

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

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

イーサリアムがブロックを生成するたびに、実際には2つのステップが行われます。1つは「どのブロックを選択するか」を担当する人（提案者）、もう1つは「実際にブロック内のトランザクションを組み立てる」人（構築者）です。現在、この分業はイーサリアムプロトコル自体では規定されておらず、プロセスを円滑に進めるためにオフチェーンの「仲介企業」（一般的にリレーと呼ばれる）グループに依存しています。このオフチェーンの関係は、ブロック検証中にも経路を作り出し、バリデーターはわずか2秒という短い時間内にトランザクションのブロードキャストと実行を急いで完了させなければならず、ネットワークが処理できるデータ量が制限されます。これは、注文と調理のプロセスが、料理の提供を調整する独立した外部の仲介業者に依存しているレストランに似ています。この仲介業者が失敗すると、厨房とフロントデスクの連携が取れなくなる可能性があります。

ePBSは、この「注文と調理」の分業をレストランの業務マニュアルに組み込み、外部の仲介業者に頼る必要がなくなりました。その結果、信頼できるオンチェーンのブロック配信と支払いメカニズムがプロトコル自体に直接組み込まれ、サードパーティのミドルウェアが不要になりました。ただし、両当事者がプロトコルでまだ規定されていない複雑な機能を使用したい場合は、外部の仲介業者を利用することもできます。さらに、「配達」フェーズでの混乱を防ぐため、ePBSは「料理検証チーム」を設立し、「誰が注文したか」「料理が時間通りに準備されたか」をチェックすることで、元の2秒の配達時間枠を約9秒に拡大し、レストランが一度に処理できる注文数を増やし、イーサリアムがレイヤー2向けのより多くのデータを処理できるようにしました。

注目の提案その2：BALs（ビジネス・アカウント・リーダーズ）向け、出発前に「買い物リスト」を準備する

次に、実行層に関する主要な提案であるブロックレベルアクセスリスト（BALsと略される）（EIP-7928）について説明しましょう。

現在、イーサリアムのトランザクション処理方法は、スーパーマーケットで目を閉じて買い物をする人のようなものです。まず商品を触って確認し、それが何であるかを判断してから、どう進めるかを決めなければなりません。そのため、一度に1つの商品しか処理できません。システムは、トランザクションがどのデータを使用するか（例えば、どの口座が関係しているかなど）を事前に把握できないため、トランザクションは厳密に順番通りに処理する必要があります。そうしないと、2つのトランザクションが意図せず同じデータ（例えば、同じアドレスの残高）を変更しようとして、競合が発生する可能性があります。

BAL（ビジネスアクセスリスト）を使用すると、買い物に出かける前に「どの棚に行ってどの商品を取るか」が明確に示された買い物リストを入手できます。このリストにより、システムはどのトランザクションが互いに「衝突」しないかを事前に把握できるため、関連性のないトランザクションを1つずつキューに入れるのではなく、グループ化して並列処理できます。このリストにはさらに利点があります。新しいノードがネットワークに参加する際に、複雑な過去のトランザクションをすべて再計算することなく、このリストに記録された最終結果を直接コピーできるため、新しいノードの同期プロセスが大幅に高速化されます。ネットワーク内でこのリストの流通を容易にするため、Glamsterdamは、ノードがこれらのアクセスリストを実際に共有できるようにする対応する伝送プロトコルのアップグレードもパッケージ化しており、これは現在、すべての実行レイヤークライアントにとって必須要件となっています。

支持提案：「占有型」作戦の再評価

これら2つの主要な提案に加えて、Glamsterdamは価格改定に関する2つの補足的な提案も提示しており、これはネットワークの「保管料」と「照会料」の価格表を調整するものと理解できる。

• 最初の提案は、新規アカウントの作成やネットワーク上で「永続的にスペースを占有する」契約の展開といった操作に関するものです。従来、課金される料金は実際に占有されたスペースに比例していませんでしたが、今後は「占有スペース単位ごとに課金」する方式に再計算され、ネットワーク全体のデータ増加率を年間120 GiBという安全かつ予測可能なレベルに抑え、ネットワークが通常のハードウェアで動作し続けることを保証します。さらに、このストレージ料金はトランザクション処理の計算料金とは別に計上され、混同されることはなくなります。開発者はストレージ料金を少し多く支払う意思があれば、全体のガス制限にすぐに制約されることなく、より大規模で複雑なアプリケーションを展開することができます。
• 2つ目の提案は、ネットワーク内の既存データの照会や読み取りといった操作に関するものです。これらの操作はこれまで料金が低すぎ、データ量の増加に伴う実際の照会コストに追いついていませんでした。今回は、これらの操作コードの料金基準を引き上げ、最新のハードウェアの実際の負荷状況をより適切に反映させるとともに、低料金を悪用して意図的に過剰な照会要求でネットワークを混雑させる行為を防止することを目的としています。

メインネットローンチ日：未定

タイムラインに関して言えば、Glamsterdamは現在かなりデリケートな段階にあります。公式には、実行レイヤーのすべてのコア開発者（ACDE）による最新の検証可能な会議は、7月16日に開催された第241回会議で、主な議題にはGlamsterdam Devnetフェーズのアップデートと、次のアップグレードであるHegotaの主要提案の選択が含まれていました。業界で広く参照されているスケジュールによると、Devnetフェーズは2026年3月28日から7月8日までの0から7までの8回の反復を経て、当初2026年8月3日に予定されていたSepoliaテストネットフォーク、そして当初2026年8月17日に予定されていたHoodiテストネットフォークが続き、メインネットのアクティベーションの目標日は2026年9月16日に設定されています。

当初の予定では2026年前半だった。出典：イーサリアム

しかし、最新の動向に基づくと、このスケジュールは延期された可能性が高い。EthPandaOps チームは最近、Plataberget と呼ばれる新しいテストネットをローンチした。これは、Glamsterdam 用に特別に設計された最初の短期公開テストネットである。Sepolia と Hoodi の公式展開は 9 月まで延期される見込みで、メインネットのローンチ目標もそれに合わせて 2026 年の第 4 四半期にずれ込んだ。これは、当初計画されていた 2026 年前半からの延期に続き、Glamsterdam のタイムラインが遅れる 2 回目となる。コア開発者は、アップグレードの正確さが特定の日付を満たすことよりも優先されることを繰り返し強調しており、正式な ACD 会議で特定のブロック高が確定するまで、このアップグレードは第 4 四半期、あるいは年末まで見られない可能性がある。