メインコンテンツへスキップ

グラムステルダム

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

Fusakaのアップグレードで進展が見られたことを受け、Glamsterdamは、ネットワークがトランザクションを処理し、成長するデータベースを管理する方法を再編成することでL1をスケーリングに重点を置いています。これにより、イーサリアムがブロックを作成および検証する方法が根本的に更新されます。

Fusakaが基盤の改良に注力する一方で、Glamsterdamは、異なるネットワーク参加者間の職務分掌を確立し、高スループットの並列化に向けてを準備するためのより効率的なデータ処理方法を導入することで、「Scale L1」と「Scale Blobs」の目標を推進します。

これらの改善により、イーサリアムはより多くの活動を処理しながらも、高速、手頃な価格、分散型を維持し、自宅でを実行する人々のハードウェア要件を管理可能な状態に保ちます。

グラムステルダムの改善案

Glamsterdamのアップグレードは、主に3つの目標を中心に据えています。

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

要するに、Glamsterdamは、ネットワークの容量が増加しても、持続可能性とパフォーマンスを高く維持できるよう、構造的な変更を導入します。

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

意味のあるL1スケーリングを実現するには、プロトコル外の信頼仮定や逐次実行の制約から脱却する必要があります。Glamsterdamは、特定のブロック構築業務の分離を確立し、ネットワークが並列処理の準備を可能にする新しいデータ構造を導入することで、この問題に対処します。

ヘッドライナー提案：プロポーザーとビルダーの分離（ePBS）を確立

  • プロトコル外の信頼仮定やサードパーティのリレーへの依存を排除します
  • 拡張された伝搬ウィンドウを介して、より大きなペイロードを可能にすることで、L1スケーリングを実現します
  • トラストレスなビルダーへの支払いをプロトコルに直接導入します

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

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

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

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

「ホットパス」のボトルネックに対処するため、ePBSはペイロード適時性委員会（PTC）とデュアルデッドラインロジックも導入し、バリデータがコンセンサスブロックと実行ペイロードの適時性を個別に証明することで、スループットを最大化します。

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

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

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

ヘッドライナー提案：ブロックレベルアクセスリスト（BAL）

  • すべてのトランザクションの依存関係を事前にマッピングすることで、シーケンシャル処理のボトルネックを排除し、バリデータが1つずつではなく、多数のトランザクションを並行して処理できる環境を整えます。
  • ノードは、すべてのトランザクションをリプレイすることなく（実行なしの同期）、最終結果を読み取ることでレコードを更新できるようになり、ノードをネットワークに同期させる速度が大幅に向上します。
  • 推測の必要がなくなり、バリデータは必要なすべてのデータを一度にプリロードできるようになります。これにより、段階的にデータを発見する手間が省け、検証が大幅に高速化されます。

今日のイーサリアムは片側一車線の道路のようなものです。ネットワークは、トランザクションが実行されるまで、トランザクションに必要なデータや変更（トランザクションがどの口座に影響するかなど）を認識できないため、バリデータはトランザクションを厳密に順番に1つずつ処理する必要があります。これらの依存関係を認識せずにトランザクションを一度に処理しようとすると、2つのトランザクションが誤って同時にまったく同じデータを変更しようとしてエラーが発生する可能性があります。

ブロックレベルアクセスリスト（BAL、またはEIP-7928）は、すべてのブロックに含まれる地図のようなもので、作業を開始する前にデータベースのどの部分にアクセスするかをネットワークに伝えます。BALでは、すべてのブロックに、トランザクションが触れるすべてのアカウント変更のハッシュと、それらの変更の最終結果（すべての状態アクセスと実行後の値のハッシュレコード）を含める必要があります。

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

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

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

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

ブロックアクセスリスト交換（eth/71またはEIP-8159）は、ブロックレベルアクセスリストに直接関連するネットワーキング機能です。BALsが並列実行を可能にする一方で、eth/71はピアツーピアプロトコルをアップグレードし、ノードがこれらのリストをネットワーク上で実際に共有できるようにします。ブロックアクセスリスト交換を実装することで、同期が高速化され、ノードは実行を伴わない状態更新を実行できるようになります。

リソース:

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

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

ステート作成時のガス代増加

  • 新規アカウントやスマートコントラクトの作成にかかる手数料が、それらがイーサリアムのデータベースに与える長期的な負担を正確に反映していることを保証する
  • ネットワーク全体の容量に基づいてこれらのデータ作成手数料を自動的に調整し、安全で予測可能な成長率を目標とすることで、標準的な物理ハードウェアでネットワークを継続的に実行できるようにします。
  • これらの特定の料金の会計処理を新しいリザーバーに分離することで、古いトランザクション制限をなくし、開発者がより大規模で複雑なアプリケーションをデプロイできるようにします。

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

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

調整を行わない場合、ネットワークが1億ガスリミットにスケールすると、イーサリアムの状態は年間200GiB近く増加し、最終的には一般的なハードウェアを上回る可能性があります。

ステート作成ガス代の増加（またはEIP-8037）は、作成されるデータの実際のサイズにガス代を関連付けることでコストを調整し、操作が作成またはアクセスする永続データの量に比例するように料金を更新します。

EIP-8037は、これらのコストをより予測可能な方法で管理するためのリザーバーモデルも導入しています。状態ガスチャージはまずstate_gas_reservoirから引き出され、GASオペコードはgas_leftのみを返します。これにより、実行フレームが利用可能なガスを誤って計算するのを防ぎます。

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

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

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

ステートアクセスガスのコスト更新

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

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

その結果、一部の特定のコマンドは、ノードに強制的に実行させる作業と比較して、現在価格が低すぎます。たとえば、EXTCODESIZEとEXTCODECOPYは、2つの別々のデータベース読み取り（1つはアカウントオブジェクト用、もう1つは実際のコードサイズまたはバイトコード用）が必要なため、価格が低すぎます。

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

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

ステートアクセスアクションの価格設定をより正確にすることで、イーサリアムは偶発的または意図的なスローダウンに対してより強靭になり、ネットワークコストをハードウェア負荷に合わせることで、将来のガスリミットの引き上げのためのより持続可能な基盤を証明します。

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

ネットワークの回復力

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

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

  • ペナルティを受けた（スラッシュされた）バリデータが将来のブロックを提案するバリデーターとして選択されないようにすることで、保証されたスロットの欠落をなくします。
  • イーサリアムをスムーズかつ確実に稼働させ、大量スラッシングイベントが発生した場合でも深刻な停滞を防ぎます。

現在、バリデータがスラッシュされた場合（ルール違反や期待どおりに動作しなかったことに対するペナルティ）、システムは将来のプロポーザーの先行予測を生成する際に、近い将来にそのバリデーターをブロックのリーダーとして選択する可能性があります。

スラッシュされたプロポーザーからのブロックは、無効として自動的に拒否されるため、ネットワークはスロットをスキップし、大量スラッシングイベント中のネットワーク復旧が遅延します。

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

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

終了時に統合キューを使用する

  • コンソリデーションキューを介して、残高の多いバリデータが残高の少ないバリデータよりも迅速にネットワークから退出できる抜け穴を塞ぎます。
  • 余剰容量がある場合、通常の出金がこの第2のキューに流れ込むことを可能にし、高負荷時のステーキング出金時間を短縮します。
  • イーサリアムのコアな安全性に関する制限を変更したり、ネットワークを弱体化させたりしないよう、厳格なセキュリティを維持します。

Pectraのアップグレードにより、イーサリアムバリデータの最大有効残高が32ETHから2,048ETHに増加したため、技術的な抜け穴が生じ、残高の多いバリデータは、コンソリデーションキューを介して、残高の少ないバリデータよりも速くネットワークから退出できるようになりました。

出金にコンソリデーションキュー（またはEIP-8080）を使用することで、すべてのステーキング出金に対してコンソリデーションキューが民主化され、全員にとって単一で公平な列が作成されます。

今日の仕組みを分解すると、以下のようになります。

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

より公平なエグジットキューにより、標準エグジットは、エグジット需要が高い期間中に、未使用のコンソリデーションキューのスペースを借りることが可能になり、「3対2」の交換レートが適用されます（未使用のコンソリデーションスポット2つにつき、ネットワークは安全に3つの標準エグジットを処理できます）。この3/2のチャーンファクターは、コンソリデーションキューとエグジットキューの需要のバランスを取ります。

コンソリデーションキューへのアクセスを民主化することで、ネットワークのセキュリティを損なうことなく、需要の高い時期にユーザーがステークを解除できる速度を最大2.5倍に引き上げることができます。

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

ユーザーと開発者のエクスペリエンスを向上させる

イーサリアムのGlamsterdamアップグレードは、ユーザーエクスペリエンスの向上、データ検索性の強化、メッセージサイズの増加への対応による同期エラーの防止を目指しています。これにより、ネットワークが拡大するにつれて発生する技術的な問題を防ぎながら、オンチェーンで何が起こっているかをより簡単に追跡できるようになります。

本質的なトランザクションガス代を削減する

  • トランザクションのベースフィーを下げ、シンプルなネイティブ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 partial ブロック receipt lists（またはEIP-7975）は、ノードが互いに通信するための新しい方法（eth/70）を導入し、これらの大きなリストをより小さく、より管理しやすい部分に分割できるようにします。eth/70は、ネットワークの通信プロトコルにページネーションシステムを導入し、ノードがブロックレシートリストを分割し、より小さく、より管理しやすいチャンクでデータを安全に要求できるようにします。

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

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

参考文献

よくある質問

Glamsterdamのハードフォーク後、ETHはどのように変換されますか？

  • ETHに関するアクションは不要です：Glamsterdamのアップグレード後、ETHを変換またはアップグレードする必要はありません。アカウント残高は同じままで、現在お持ちのETHはハードフォーク後も既存の形式で引き続きご利用いただけます。
  • 詐欺にご注意ください！ ETHを「アップグレード」するよう指示する者は、詐欺を企てています。このアップグレードに関して、あなたが行うべきことは何もありません。あなたの資産は全く影響を受けません。詐欺に対する最善の防御策は、常に情報を得ておくことであることを忘れないでください。

詐欺を見抜いて避ける方法について

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

はい、Glamsterdamのアップグレードには、実行クライアントとコンセンサスクライアントの両方の更新が必要です。このアップグレードでは、エンシュラインド・プロポーザー・ビルダー・セパレーション（ePBS）が導入されるため、ノードオペレーターは、ブロックがネットワークによって構築、検証、認証される新しい方法に対応するために、クライアントが更新されていることを確認する必要があります。

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

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

ステーカーとして、Glamsterdamのアップグレードのために何をする必要がありますか？

すべてのネットワークアップグレードと同様に、クライアントをGlamsterdamサポート対象の最新バージョンにアップデートしてください。リリースに関する情報は、メーリングリストとEFブログのプロトコル発表 (opens in a new tab)でご確認ください。

Glamsterdamがメインネットで有効化される前にセットアップを検証するには、テストネットでバリデータを実行できます。テストネットのフォークは、メーリングリストやブログでも発表されます。

GlamsterdamはL1スケーリングのためにどのような改善を予定していますか？

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

Glamsterdamはイーサリアム（レイヤー1）の手数料を下げますか？

はい、Glamsterdamは一般ユーザーの料金を削減する可能性が高いです！トランザクションガス（またはEIP-2780）を削減することで、ETHの送金にかかるベースフィーが下がり、日常的な支払いにETHを使用するコストが大幅に安くなります。

さらに、長期的な持続可能性のために、Glamsterdamはブロックレベルアクセスリスト（BAL）を導入します。これにより並列処理が可能になり、L1が将来的に全体的なガス制限の上昇を安全に処理できるよう準備が整います。これにより、キャパシティが増加するにつれて、トランザクションあたりのガス代が削減される可能性が高まります。

Glamsterdam開催後、既存のスマートコントラクトに変更はありますか？

既存の契約はGlamsterdam後も通常通り機能します。開発者はいくつかの新しいツールを入手する可能性があり、ガス使用量を確認する必要があります。

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

Glamsterdamはノードのストレージやハードウェアの要件にどのような影響を与えますか？

Glamsterdamで検討されている複数のEIPは、状態の成長に伴うパフォーマンスの急落に対処します。

  • ステート作成ガス代の増加（またはEIP-8037）は、状態データベースの成長率を年間100 GiBに目標設定する動的価格設定モデルを導入し、標準的な物理ハードウェアがネットワークを効率的に実行し続けられるようにします。
  • eth/70 partial ブロック receipt lists（またはEIP-7975）により、ノードはページ分割されたブロックレシートを要求できるようになります。これにより、データ量の多いブロックレシートリストをより小さなチャンクに分割し、Ethereumがスケーリングする際のクラッシュや同期の問題を防ぎます。

この記事は役に立ちましたか?