グラムステルダム

イーサリアムの次期アップグレードであるグラムステルダムは、次世代のスケーリングへの道を切り開くように設計されています。グラムステルダム（Glamsterdam）という名前は、「アムステルダム（Amsterdam）」（過去のDevconnect開催地にちなんで名付けられた実行レイヤーのアップグレード）と「グロアス（Gloas）」（星の名前にちなんで名付けられたコンセンサス・レイヤーのアップグレード）を組み合わせたものです。

フサカ・アップグレードでの進展に続き、グラムステルダムは、ネットワークがトランザクションを処理し、増大するデータベースを管理する方法を再編成することでレイヤー1 (L1) のスケーリングに焦点を当てており、イーサリアムがブロックを作成および検証する方法を根本的に更新します。

フサカが基礎的な改良に焦点を当てていたのに対し、グラムステルダムは、さまざまなネットワーク参加者間の役割の分離をプロトコルに組み込み、高スループットの並列化に向けてを準備するためのより効率的なデータ処理方法を導入することで、「L1のスケーリング」と「Blobのスケーリング」の目標を前進させます。

これらの改善により、イーサリアムはより多くのアクティビティを処理する際にも高速で手頃な価格であり、分散型であり続けることが保証されます。同時に、自宅でを運用する人々にとってハードウェア要件を管理可能なレベルに保ちます。

グラムステルダムで検討されている改善点

グラムステルダム・アップグレードは、主に3つの目標を中心としています。

• 処理の高速化（並列化）：ネットワークがデータ依存関係を記録する方法を再編成し、遅い順次処理ではなく、多くのトランザクションを同時に安全に処理できるようにします。
• 容量の拡大：ブロックの作成と検証という重い作業を分割し、速度を落とすことなく、より大量のデータを伝播するための時間をネットワークに与えます。
• データベースの肥大化防止（持続可能性）：新しいデータを保存するための長期的なハードウェア・コストを正確に反映するようにネットワーク手数料を調整し、ハードウェアのパフォーマンス低下を防ぎながら、将来のガス・リミットの引き上げを可能にします。

要するに、グラムステルダムは、ネットワークが容量を増やすにつれて、持続可能であり、パフォーマンスが高く保たれることを保証するための構造的な変更を導入します。

意味のあるレイヤー1 (L1) のスケーリングには、プロトコル外のトラスト前提と順次実行の制約から脱却する必要があります。グラムステルダムは、特定のブロック構築の役割の分離をプロトコルに組み込み、ネットワークが並列処理に備えることを可能にする新しいデータ構造を導入することで、この問題に対処します。

L1のスケーリングと並列処理

意味のあるレイヤー1 (L1) のスケーリングには、プロトコル外のトラスト前提や直列実行の制約から脱却する必要があります。グラムステルダムは、特定のブロック構築の役割の分離をプロトコルに組み込み、ネットワークが並列処理の準備を行えるようにする新しいデータ構造を導入することで、この問題に対処します。

目玉となる提案：プロポーザー・ビルダー分離のプロトコルへの組み込み (ePBS)

• プロトコル外のトラスト前提とサードパーティのリレイへの依存を排除します
• 伝播ウィンドウの拡張により、はるかに大きなペイロードを許可することでL1のスケーリングをサポートします
• トラストレスなビルダーへの支払いをプロトコルに直接導入します
• トラストレスな監視を可能にするためにステーキング・プールのアーキテクチャの更新が必要になりますが、洗練されたビルダー選択プロセスにより、全体的なステーキングのユーザー体験は向上します

現在、ブロックの提案と構築のプロセスには、ブロック・プロポーザーとブロック・ビルダー間の引き継ぎが含まれています。プロポーザーとビルダーの関係はイーサリアムのコア・プロトコルの一部ではないため、信頼できるサードパーティのミドルウェア、ソフトウェア（リレイ）、およびエンティティ間のプロトコル外の信頼に依存しています。

プロポーザーとビルダー間のプロトコル外の関係は、ブロック検証中に「ホットパス」を作り出し、にわずか2秒という厳しい時間枠内でトランザクションのブロードキャストと実行を急がせるため、ネットワークが処理できるデータ量が制限されます。

プロポーザー・ビルダー分離のプロトコルへの組み込み（ePBS、またはEIP-7732）は、プロポーザー（コンセンサス・ブロックを選択する役割）とビルダー（実行ペイロードを組み立てる役割）の仕事を正式に分離し、この引き継ぎをプロトコルに直接組み込みます。

支払いと引き換えにブロック・ペイロードをトラストレスに交換する仕組みをプロトコルに直接組み込むことで、サードパーティのミドルウェア（MEV-Boostなど）の必要性がなくなります。ただし、ビルダーとプロポーザーは、コア・プロトコルにまだ含まれていない複雑な機能のために、引き続きプロトコル外のリレイやミドルウェアを使用することを選択する場合があります。

「ホットパス」のボトルネックに対処するため、ePBSはペイロード適時性コミッティ（PTC）と二重期限ロジックも導入し、バリデータがコンセンサス・ブロックと実行ペイロードの適時性を別々に証明できるようにして、スループットを最大化します。

プロトコル・レベルでプロポーザーとビルダーの役割を分離することで、伝播ウィンドウ（ネットワーク全体にデータを広めるために利用できる時間）が2秒から約9秒に拡大します。

プロトコル外のミドルウェアやリレイをプロトコル内のメカニズムに置き換えることで、ePBSは信頼への依存を減らし、イーサリアムがネットワークに負荷をかけることなく、はるかに大量のデータ（向けのより多くのBlobなど）を安全に処理できるようにします。

リソース：EIP-7732の技術仕様 (opens in a new tab)

目玉となる提案：ブロックレベル・アクセス・リスト (BAL)

• すべてのトランザクションの依存関係のマップを事前に提供することで順次処理のボトルネックを解消し、バリデータがトランザクションを1つずつではなく並列に処理するための舞台を整えます
• すべてのトランザクションを再実行することなく、最終結果を読み取ることでノードがレコードを更新できるようにし（実行なしの同期）、ノードをネットワークに同期する速度を大幅に向上させます
• 推測を排除し、バリデータが段階的に発見するのではなく、必要なすべてのデータを一度に事前ロードできるようにすることで、検証をはるかに高速化します

現在のイーサリアムは1車線の道路のようなものです。トランザクションが実行されるまで、そのトランザクションがどのデータを必要とするか、または変更するか（どのトランザクションがどのアカウントに触れるかなど）をネットワークが把握できないため、バリデータは厳密な順序でトランザクションを1つずつ処理する必要があります。これらの依存関係を知らずにトランザクションを一度に処理しようとすると、2つのトランザクションが誤って全く同じデータを同時に変更しようとして、エラーが発生する可能性があります。

ブロックレベル・アクセス・リスト（BAL、またはEIP-7928）は、ネットワークのマップのように機能し、作業が始まる前にデータベースのどの部分にアクセスするかを詳細に示します。実行レイヤーは、トランザクションが触れるすべてのアカウントの変更と、それらの変更の最終結果（すべての状態アクセスと実行後の値）を含む、完全なブロック・アクセス・リストを保存します。ブロックを軽量に保つため、ブロック・ヘッダーには、このリストの一意のデジタル指紋（ハッシュ・レコード）を含む新しいフィールドが含まれます。

BALは、どのトランザクションが重複していないかを即座に可視化するため、ノードは並列ディスク読み取りを実行し、多くのトランザクションの情報を同時に取得できます。ネットワークは、関連のないトランザクションを安全にグループ化し、並列に処理することができます。

BALにはトランザクションの最終結果（実行後の値）が含まれているため、ネットワークのノードがネットワークの現在の状態に同期する必要がある場合、それらの最終結果をコピーしてレコードを更新できます。バリデータは何が起こったかを知るために複雑なトランザクションをすべて最初から再実行する必要がなくなり、新しいノードがネットワークに参加するのがより速く、より簡単になります。

BALによって可能になる並列ディスク読み取りは、イーサリアムが一度に多くのトランザクションを処理できるようになる未来に向けた重要な一歩となり、ネットワークの速度を大幅に向上させます。

eth/71 ブロック・アクセス・リストの交換

ブロック・アクセス・リストの交換（eth/71またはEIP-8159）は、ブロックレベル・アクセス・リストの直接的なネットワーキングのコンパニオンです。BALが並列実行を可能にする一方で、eth/71はピア・ツー・ピア・プロトコルをアップグレードし、ノードがネットワーク上でこれらのリストを実際に共有できるようにします。現在、すべての実行レイヤー・クライアントに必須となっているブロック・アクセス・リストの交換により、同期が高速化され、ノードが実行なしの状態更新を実行できるようになります。

リソース：

• EIP-7928の技術仕様 (opens in a new tab)
• EIP-8159の技術仕様 (opens in a new tab)

ネットワークの持続可能性

イーサリアム・ネットワークがより高速に成長するにつれて、その利用コストがイーサリアムを実行するハードウェアの消耗に見合っていることを確認することが重要です。ネットワークは、安全にスケーリングし、より多くのトランザクションを処理するために、全体的な容量制限を引き上げる必要があります。

状態作成のガス・コストの引き上げ

• 新しいアカウントやスマート・コントラクトを作成するための手数料が、イーサリアムのデータベースにかかる長期的な負担を正確に反映するようにします
• 年間120 GiBという安全で予測可能な成長率を目標とする固定の**状態バイトあたりのコスト（CPSB）**を設定し、標準的な物理ハードウェアがネットワークの実行を継続できるようにします
• これらの特定の手数料の会計を新しいリザーバー（貯水池）に分離し、古いトランザクション制限を撤廃して、開発者がより大規模で複雑なアプリケーションをデプロイできるようにします

新しいアカウント、トークン、およびを追加すると、ネットワークを実行しているすべてのコンピュータが無期限に保存しなければならない永続的なデータ（「状態」として知られています）が作成されます。このデータを追加または読み取るための現在の手数料は一貫性がなく、ネットワークのハードウェアにかかる実際の長期的なストレージ負担を必ずしも反映していません。

新しいアカウントの作成や大規模なスマート・コントラクトのデプロイなど、イーサリアム上で状態を作成する一部のアクションは、ネットワークのノード上で占有する永続的なストレージ・スペースに比べて比較的低コストでした。たとえば、コントラクトのデプロイは、ストレージ・スロットを作成するよりもバイトあたりのコストが大幅に安くなっています。

調整を行わなければ、ネットワークがグラムステルダムによって可能になる2億ガス・リミットの下限に向けてスケーリングするにつれて、イーサリアムの状態の成長は持続不可能になります（開発者は現在、正確な状態の価格設定を導き出すために、1億5000万の参照ブロック・ガス・リミットでテストを行っています）。

状態作成のガス・コストの引き上げ（またはEIP-8037）は、コストを作成されるデータの実際のサイズに結び付けることでコストを調和させ、操作が作成またはアクセスする永続的なデータの量に比例するように手数料を更新します。

EIP-8037はまた、これらのコストをより予測可能に管理するためのリザーバー・モデルを導入します。状態のガス料金は最初にstate_gas_reservoirから引き出され、GASオペコードはgas_leftのみを返すため、実行フレームが利用可能なガスを誤って計算するのを防ぎます。これをサポートするために、不可欠なバックグラウンド・タスクには、この専用の予備に直接入る追加の燃料アローワンスが与えられ、永続的なデータの保存により多くのリソースが必要になるという理由だけで、重要なネットワーク操作が失敗しないようにします。

EIP-8037以前は、計算作業（アクティブな処理）と永続的なデータ・ストレージ（スマート・コントラクトをネットワークのデータベースに保存すること）の両方が同じガス・リミットを共有していました。リザーバー・モデルは会計を分割します。トランザクションの実際の計算作業（処理）のためのガス・リミットと、長期的なデータ・ストレージ（状態ガス）のためのガス・リミットです。この2つを分離することで、アプリケーションのデータの膨大なサイズがガス・リミットの上限に達するのを防ぐことができます。開発者がデータ・ストレージ用のリザーバーを満たすのに十分な資金を提供する限り、はるかに大規模で複雑なスマート・コントラクトをデプロイできます。

データ・ストレージの価格をより正確かつ予測可能に設定することで、イーサリアムはデータベースを肥大化させることなく、速度と容量を安全に向上させることができます。この持続可能性により、ノード・オペレーターは今後何年にもわたって（比較的）手頃な価格のハードウェアを使用し続けることができ、ネットワークの分散化を維持するためにホーム・ステーキングへのアクセスを維持できます。

リソース：EIP-8037の技術仕様 (opens in a new tab)

状態アクセスのガス・コストの更新

• アプリケーションがイーサリアムに永続的に保存されている情報を読み取ったり更新したりする際（状態アクセス・オペコード）のガス・コストを引き上げ、これらのコマンドが必要とする計算作業に正確に一致させます
• 人為的に安価なデータ読み取り操作を悪用するサービス拒否（DoS）攻撃を防ぐことで、ネットワークの回復力を強化します

イーサリアムの状態が成長するにつれて、古いデータを検索して読み取る行為（「状態アクセス」）は、ノードが処理するのにより重く、遅くなっています。情報を検索するためのコスト（計算能力の観点から）がわずかに高くなっているにもかかわらず、これらのアクションの手数料は同じままです。

その結果、一部の特定のコマンドは現在、ノードに強いる作業に対して過小評価されています。たとえば、EXTCODESIZEとEXTCODECOPYは、アカウント・オブジェクト用と、実際のコード・サイズまたはバイトコード用の2つの別々のデータベース読み取りを必要とするため、過小評価されています。

状態アクセスのガス・コストの更新（またはEIP-8038）は、アカウントやコントラクト・データの検索など、状態アクセス・オペコードのガス定数を引き上げ、最新のハードウェアのパフォーマンスと状態のサイズに合わせます。

状態アクセスのコストを調整することは、イーサリアムの回復力を高めることにも役立ちます。これらの重いデータ読み取りアクションは人為的に安価であるため、悪意のある攻撃者がネットワークの手数料制限に達する前に、単一のブロック内で何千もの複雑なデータ・リクエストをネットワークにスパム送信し、ネットワークを停止またはクラッシュさせる可能性があります（サービス拒否攻撃）。悪意がなくても、ネットワーク・データの読み取りが安すぎると、開発者は効率的なアプリケーションを構築する経済的な動機を持ちません。

状態アクセス・アクションの価格をより正確に設定することで、イーサリアムは偶発的または意図的な速度低下に対してより高い回復力を持つことができます。同時に、ネットワーク・コストをハードウェアの負荷に合わせることは、将来のガス・リミット引き上げのためのより持続可能な基盤となります。

リソース：EIP-8038の技術仕様 (opens in a new tab)

ネットワークの回復力

バリデータの義務とエグジット・プロセスの改良により、大規模なスラッシング・イベント中のネットワークの安定性が確保され、流動性が民主化されます。これらの改善により、ネットワークはより安定し、大小を問わずすべての参加者が公平に扱われるようになります。

スラッシングされたバリデータを提案から除外する

• ペナルティを受けた（スラッシングされた）バリデータが将来のブロックを提案するために選択されるのを防ぎ、確実なスロットのミスを排除します
• イーサリアムをスムーズかつ確実に稼働させ続け、大規模なスラッシング・イベントが発生した場合の深刻な停止を防ぎます

現在、バリデータがスラッシングされた（ルールを破ったり、期待通りに動作しなかったりしてペナルティを受けた）場合でも、システムが将来のプロポーザーの先読みを生成する際に、近い将来にブロックを主導するように選択される可能性があります。

スラッシングされたプロポーザーからのブロックは無効として自動的に拒否されるため、これによりネットワークはスロットを逃し、大規模なスラッシング・イベント中のネットワークの回復が遅れます。

スラッシングされたバリデータを提案から除外する（またはEIP-8045）は、スラッシングされたバリデータが将来の義務に選択されないように単にフィルタリングします。これにより、健全なバリデータのみがブロックを提案するように選択されることが保証され、ネットワークの混乱時にもサービスの品質が維持されるため、チェーンの回復力が向上します。

リソース：EIP-8045の技術仕様 (opens in a new tab)

エグジットに統合キューを使用させる

• 残高の多いバリデータが、統合キューを介して小規模なバリデータよりも早くネットワークからエグジットできる抜け穴を塞ぎます
• この2番目のキューに空き容量がある場合、通常のエグジットがオーバーフローできるようにし、大量処理期間中のステーキングの引き出し時間を短縮します
• イーサリアムのコアな安全限界を変更したり、ネットワークを弱体化させたりすることを避けるため、厳格なセキュリティを維持します

ペクトラ・アップグレードにより、イーサリアム・バリデータの最大有効残高が32 ETHから2,048 ETHに引き上げられて以来、技術的な抜け穴により、残高の多いバリデータは統合キューを介して小規模なバリデータよりも早くネットワークからエグジットできるようになっています。

エグジットに統合キューを使用させる（またはEIP-8080）は、すべてのステーキング・エグジットに対して統合キューを民主化し、全員にとって単一の公平な列を作成します。

現在の仕組みを分解すると次のようになります。

• イーサリアムのチャーン・リミットは、ネットワークのセキュリティが不安定にならないようにするための、バリデータがステークしたETHを参加、エグジット、またはマージ（統合）できる速度に関する安全限界です
• バリデータの統合は、標準的なバリデータのエグジットよりも多くの可動部分を伴う重いアクションであるため、この安全予算（チャーン・リミット）のより大きな部分を消費します
• 具体的には、プロトコルは、1つの標準的なエグジットの正確なセキュリティ・コストが、1つの統合のコストの3分の2（2/3）であると規定しています

より公平なエグジット・キューにより、エグジットの需要が高い期間中、標準的なエグジットは統合キューの未使用スペースを借りることができ、「3対2」の交換レートが適用されます（未使用の統合スポット2つにつき、ネットワークは3つの標準的なエグジットを安全に処理できます）。この3/2のチャーン係数は、統合キューとエグジット・キュー全体で需要のバランスを取ります。

統合キューへのアクセスを民主化することで、ネットワークのセキュリティを損なうことなく、需要の高い期間中にユーザーがステークをエグジットできる速度が最大2.5倍に向上します。

リソース：EIP-8080の技術仕様 (opens in a new tab)

ユーザーと開発者の体験の向上

イーサリアムのグラムステルダム・アップグレードは、ユーザー体験を向上させ、データの発見可能性を高め、増加するメッセージ・サイズを処理して同期の失敗を防ぐことを目的としています。これにより、ネットワークがスケーリングする際の技術的な問題を防止しながら、オンチェーンで何が起こっているかを追跡しやすくなります。

組み込みのトランザクション・ガス・コストの削減

• トランザクションの基本料金を下げ、シンプルなネイティブETH支払いの全体的なコストを削減します
• 少額の送金をより手頃な価格にし、日常的な交換手段としてのイーサリアムの実行可能性を高めます

現在、すべてのイーサリアム・トランザクションには、処理がどれほど単純であれ複雑であれ、一律の基本ガス代が設定されています。組み込みのトランザクション・ガスの削減（またはEIP-2780）は、その基本料金を削減し、既存のアカウント間の標準的なETH送金を最大71%安くすることを提案しています。

組み込みのトランザクション・ガスの削減は、トランザクション手数料を分解し、デジタル署名の検証や残高の更新など、ネットワークを実行しているコンピュータが実際に実行する基本的で不可欠な作業のみを反映させることで機能します。基本的なETH支払いは複雑なコードを実行したり、余分なデータを運んだりしないため、この提案はその軽量なフットプリントに合わせて手数料を削減します。

この提案では、低い手数料がネットワークの状態を圧迫するのを防ぐため、まったく新しいアカウントの作成に対する例外を導入しています。送金によって空の存在しないアドレスにETHが送信された場合、ネットワークはそのための永続的な新しいレコードを作成する必要があります。そのアカウント作成には、長期的なストレージ負担をカバーするためにガスの追加料金が加算されます。

これらを合わせて、EIP-2780は、真の状態の成長を正確に価格設定することでネットワークがデータベースの肥大化から引き続き保護されることを保証しつつ、既存のアカウント間の日常的な送金をより手頃な価格にすることを目指しています。

リソース：EIP-2780の技術仕様 (opens in a new tab)

決定論的ファクトリーの事前デプロイ

• 開発者に、複数のチェーンにわたって全く同じアドレスにアプリケーションやスマート・コントラクト・ウォレットをデプロイするネイティブな方法を提供します
• ユーザーが複数のレイヤー2 (L2) ネットワークで同じスマート・ウォレット・アドレスを持てるようにし、認知的負荷を減らし、混乱を減らし、資金を誤って失うリスクを減らします
• 開発者が現在この同等性を達成するために使用している回避策を置き換え、マルチチェーンのウォレットやアプリをより簡単かつ安全に構築できるようにします

現在、ユーザーが複数のイーサリアム仮想マシン（EVM）互換チェーンにまたがるアカウントを持つスマート・コントラクト・ウォレットを持っている場合、異なるネットワークでまったく異なるアドレスになってしまうことがよくあります。これは混乱を招くだけでなく、資金を誤って失う原因にもなります。

決定論的ファクトリーの事前デプロイ（またはEIP-7997）は、開発者に、イーサリアム・メインネット、レイヤー2 (L2) ネットワークなどを含む複数のEVMチェーンにわたって、分散型アプリケーションやスマート・コントラクト・ウォレットを全く同じアドレスにデプロイするためのネイティブな組み込みの方法を提供します。採用されれば、ユーザーは参加しているすべてのチェーンで全く同じアドレスを持つことができ、認知的負荷とユーザー・エラーの可能性を大幅に減らすことができます。

決定論的ファクトリーの事前デプロイは、参加しているすべてのEVM互換チェーンの同一の場所（具体的にはアドレス0x12）に、最小限の特化したファクトリー・プログラムを永続的に配置することで機能します。その目標は、あらゆるEVM互換ネットワークで採用できる普遍的で標準的なファクトリー・コントラクトを提供することです。EVMチェーンが参加してこの標準を採用する限り、開発者はそれを使用して、そのネットワーク上の全く同じアドレスにスマート・コントラクトをデプロイできるようになります。

この標準化により、開発者やより広範なエコシステムにとって、クロスチェーン・アプリケーションの構築と管理が簡素化されます。開発者は、異なるネットワーク間でソフトウェアをリンクするためにカスタムのチェーン固有のコードを構築する必要がなくなり、代わりにこの普遍的なファクトリーを使用して、どこでもアプリケーションの全く同じアドレスを生成できます。さらに、ブロック・エクスプローラー、追跡サービス、およびウォレットは、さまざまなチェーンにわたってこれらのアプリケーションとアカウントをより簡単に識別してリンクできるようになり、すべてのイーサリアム・ベースの参加者にとって、より統一されたシームレスなマルチチェーン環境が構築されます。

リソース：EIP-7997の技術仕様 (opens in a new tab)

ETHの送金とバーンによるログの発行

• ETHが送金またはバーンされるたびに、永続的な記録（ログ）を自動的に生成します
• アプリ、取引所、ブリッジがアドホックな追跡ツールなしでユーザーの預金を確実に検出できるようにする、歴史的な死角を修正します

トークン（ERC-20）とは異なり、スマート・コントラクト間の通常のETH送金は明確なレシート（標準ログ）を発行しないため、取引所やアプリが追跡するのは困難です。

ETHの送金とバーンによるログの発行（またはEIP-7708）は、ゼロではない量のETHが移動またはバーンされるたびに、ネットワークが標準のログ・イベントを発行することを義務付けます。

これにより、ウォレット、取引所、およびブリッジのオペレーターは、カスタム・ツールなしで預金や移動を正確に追跡することがはるかに簡単かつ確実になります。

リソース：EIP-7708の技術仕様 (opens in a new tab)

eth/70 部分的なブロック・レシート・リスト

イーサリアムが実行できる作業量を増やすにつれて、それらのアクションのレシートのリスト（これらのトランザクションのデータ・レコード）は非常に大きくなっており、ネットワークのノードが互いにデータを同期しようとする際に失敗を引き起こす可能性があります。

現在、すべての実行レイヤー・クライアントに必須となっているeth/70 部分的なブロック・レシート・リスト（またはEIP-7975）は、ノードが互いに通信するための新しい方法（eth/70）を導入し、これらの大きなリストをより小さく管理しやすい断片に分割できるようにします。eth/70は、ネットワークの通信プロトコルにページネーション・システムを導入し、ノードがブロック・レシート・リストを分割して、より小さく管理しやすいチャンクでデータを安全に要求できるようにします。

この変更により、アクティビティが集中する期間中のネットワーク同期の失敗を防ぐことができます。最終的には、チェーンを同期する物理ハードウェアを圧迫することなく、将来的にイーサリアムがブロック容量を増やし、ブロックあたりのトランザクション処理数を増やすための道を開きます。

リソース：EIP-7975の技術仕様 (opens in a new tab)

参考文献

• イーサリアムのロードマップ
• Forkcast：グラムステルダム (opens in a new tab)
• グラムステルダムのメタEIP (opens in a new tab)
• 2026年に向けたプロトコルの優先事項の更新に関するブログ発表 (opens in a new tab)
• The Daily Gwei Refuel ポッドキャスト - ポスト量子イーサリアム、グラムステルダムの到来 (opens in a new tab)

よくある質問 (FAQ)

グラムステルダムのハード・フォーク後、ETHはどのように変換できますか？

• ETHに対するアクションは不要です：グラムステルダム・アップグレードに伴い、ETHを変換またはアップグレードする必要はありません。アカウントの残高は変わらず、現在保有しているETHは、ハード・フォーク後も既存の形式で引き続きアクセス可能です。
• 詐欺にご注意ください！ ETHを「アップグレード」するように指示する人は、あなたを騙そうとしています。 このアップグレードに関連して、あなたがしなければならないことは何もありません。あなたの資産は完全に影響を受けません。情報を常に把握しておくことが、詐欺に対する最大の防御であることを覚えておいてください。

詐欺の認識と回避についての詳細

グラムステルダム・アップグレードは、すべてのイーサリアム・ノードとバリデータに影響しますか？

はい、グラムステルダム・アップグレードでは、実行クライアントとコンセンサス・クライアントの両方の更新が必要です。このアップグレードではプロポーザー・ビルダー分離のプロトコルへの組み込み (ePBS) が導入されるため、ノード・オペレーターは、ネットワークによってブロックが構築、検証、および証明される新しい方法を処理できるように、クライアントが更新されていることを確認する必要があります。

すべての主要なイーサリアム・クライアントは、優先度高とマークされたハード・フォークをサポートするバージョンをリリースします。これらのリリースがいつ利用可能になるかについては、クライアントのGitHubリポジトリ、それぞれのディスコード・チャンネル (opens in a new tab)、EthStakerのディスコード (opens in a new tab)で確認するか、イーサリアム・ブログを購読してプロトコルの更新情報を入手することができます。

アップグレード後にイーサリアム・ネットワークとの同期を維持するために、ノード・オペレーターはサポートされているクライアント・バージョンを実行していることを確認する必要があります。クライアントのリリースに関する情報は時間に敏感であるため、ユーザーは最新の詳細について最新の更新情報を参照する必要があることに注意してください。

ステーキング参加者として、グラムステルダム・アップグレードのために何をする必要がありますか？

すべてのネットワーク・アップグレードと同様に、クライアントをグラムステルダム・サポートとマークされた最新バージョンに必ず更新してください。メーリング・リストやEFブログのプロトコル・アナウンス (opens in a new tab)の更新情報をフォローして、リリースに関する情報を入手してください。

メインネットでグラムステルダムがアクティブ化される前にセットアップを検証するために、テストネットでバリデータを実行できます。テストネットのフォークもメーリング・リストとブログで発表されます。

グラムステルダムには、L1のスケーリングのためにどのような改善が含まれますか？

目玉となる機能はePBS (EIP-7732) であり、ネットワーク・トランザクションを検証するという重いタスクを、コンセンサスに達するというタスクから分離します。これにより、データ伝播ウィンドウが2秒から約9秒に拡大し、イーサリアムがはるかに高いトランザクション・スループットを安全に処理し、レイヤー2 (L2) ネットワーク向けのより多くのデータBlobを収容できるようになります。

グラムステルダムはイーサリアム（レイヤー1）の手数料を下げますか？

はい、グラムステルダムは日常的なユーザーの手数料を削減する可能性が非常に高いです！組み込みのトランザクション・ガスの削減（またはEIP-2780）は、ETHを送金するための基本料金を削減し、日常的な支払いにETHを使用するコストを大幅に安くします。

さらに、長期的な持続可能性のために、グラムステルダムはブロックレベル・アクセス・リスト (BAL) を導入します。これにより並列処理が可能になり、将来的にL1がより高い全体的なガス・リミットを安全に処理できるよう準備が整います。これにより、容量の増加に伴い、トランザクションあたりのガス・コストが削減される可能性があります。

グラムステルダム後、既存のスマート・コントラクトに変更はありますか？

既存のコントラクトは、グラムステルダム後も引き続き正常に機能します。開発者はいくつかの新しいツールを入手する可能性が高く、ガスの使用量を見直す必要があります。

• 最大コントラクト・サイズの引き上げ（またはEIP-7954）により、開発者はより大規模なアプリケーションをデプロイできるようになり、最大コントラクト・サイズの制限が約24KiBから32KiBに引き上げられます。
• 決定論的ファクトリーの事前デプロイ（またはEIP-7997）は、普遍的な組み込みのファクトリー・コントラクトを導入します。これにより、開発者は参加しているすべてのEVMチェーンにわたって、アプリケーションやスマート・コントラクト・ウォレットを全く同じアドレスにデプロイできるようになります。
• アプリがETHの送金を見つけるために複雑な追跡に依存している場合、ETHの送金とバーンによるログの発行（またはEIP-7708）により、よりシンプルで信頼性の高い会計のためにログの使用に切り替えることができます。
• 状態作成のガス・コストの引き上げ（またはEIP-8037）および状態アクセスのガス・コストの更新（またはEIP-8038）は、新しい持続可能性モデルを導入します。これにより、新しいアカウントや永続的なストレージの作成には、作成されたデータのサイズに基づいた新しい標準化された固定手数料が適用されるため、特定のコントラクトのデプロイ・コストが変更されます。

グラムステルダムはノードのストレージとハードウェア要件にどのような影響を与えますか？

グラムステルダムで検討されている複数のEIPは、状態の成長によるパフォーマンスの崖（クリフ）に対処しています。

• 状態作成のガス・コストの引き上げ（またはEIP-8037）は、状態データベースの成長率を年間120 GiBに目標設定する固定コスト・フレームワーク (CPSB) を導入し、標準的な物理ハードウェアがネットワークを効率的に実行し続けられるようにします。
• eth/70 部分的なブロック・レシート・リスト（またはEIP-7975）により、ノードはページネーションされたブロック・レシートを要求できるようになります。これにより、データ量の多いブロック・レシート・リストがより小さなチャンクに分割され、イーサリアムのスケーリングに伴うクラッシュや同期の失敗を防ぎます。

ページの最終更新: 2026年6月6日

w (opens in a new tab)

m (opens in a new tab)

コントリビューターを見る