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

フサカ 🦓

ページを編集 (opens in a new tab)

イーサリアムの待望のフサカ・アップグレードは、2025年12月3日に稼働しました

フサカ・ネットワーク・アップグレードはペクトラに続くものであり、より多くの新機能をもたらし、すべてのイーサリアムユーザーと開発者のエクスペリエンスを向上させます。この名前は、実行レイヤーのアップグレードであるOsaka（大阪）と、Fulu（附路）星にちなんで名付けられたコンセンサス・レイヤーのバージョンから構成されています。イーサリアムの両方の部分がアップグレードを受け、イーサリアムのスケーリング、セキュリティ、およびユーザーエクスペリエンスを未来へと押し上げます。

フサカ・アップグレードは、イーサリアムの長期的な開発目標における単なる一歩にすぎません。プロトコルのロードマップや過去のアップグレードについて詳しく学びましょう。

Ethereum's latest upgrade: Fusaka

A short overview of Ethereum's Fusaka upgrade featuring Ethereum Foundation contributors and ecosystem builders.

トランスクリプト付きで視聴 

フサカでの改善点

ブロブのスケーリング

PeerDAS

これはフサカ・フォークの_目玉_であり、このアップグレードで追加される主な機能です。レイヤー2 (L2) は現在、レイヤー2 (L2) 専用に作成された一時的なデータ型であるブロブでイーサリアムにデータを投稿しています。フサカ以前は、データが存在することを保証するために、すべてのフル・ノードがすべてのブロブを保存する必要がありました。ブロブのスループットが上昇するにつれて、このすべてのデータをダウンロードしなければならないことは、リソースを過度に消費し、維持できなくなります。

データ可用性サンプリング (opens in a new tab)により、すべてのブロブデータを保存する代わりに、各ノードはブロブデータのサブセットを担当するようになります。ブロブはネットワーク内のノード全体に一様にランダムに分散され、各フル・ノードはデータの1/8のみを保持するため、理論上最大8倍のスケーリングが可能になります。データの可用性を確保するために、データの任意の部分は、全体の既存の50%から再構築でき、誤ったデータや欠落したデータの確率を暗号学的に無視できるレベル（1020分の1から1024分の1程度）まで引き下げる手法が用いられます。

これにより、ノードのハードウェアと帯域幅の要件を維持可能な状態に保ちながら、ブロブのスケーリングを可能にし、結果としてレイヤー2 (L2) の手数料を抑えつつ、より大きなスケーリングを実現します。

PeerDASについてさらに学ぶ

リソース:

ブロブ・パラメータ・オンリー・フォーク

レイヤー2 (L2) はイーサリアムをスケーリングします。ネットワークが成長するにつれて、より多くのデータをイーサリアムに投稿する必要があります。これは、時間が経つにつれて、イーサリアムが利用可能なブロブの数を増やす必要があることを意味します。PeerDASはブロブデータのスケーリングを可能にしますが、それは段階的かつ安全に行われる必要があります。

イーサリアムは、同じルールに対する合意を必要とする何千もの独立したノード上で実行されるコードであるため、ウェブサイトの更新をデプロイするように、ブロブ数を増やすような変更を単に導入することはできません。ルールの変更は、すべてのノード、クライアント、およびバリデータソフトウェアが、あらかじめ決められた同じブロックの前にアップグレードする、調整されたアップグレードでなければなりません。

これらの調整されたアップグレードには通常、多くの変更が含まれ、多くのテストが必要であり、時間がかかります。変化するレイヤー2 (L2) のブロブのニーズにより早く適応するために、ブロブ・パラメータ・オンリー・フォーク（Blob Parameter Only forks）は、そのアップグレードのスケジュールを待つことなくブロブを増やすメカニズムを導入します。

ブロブ・パラメータ・オンリー・フォークは、ガス・リミットのような他の設定と同様に、クライアントによって設定できます。イーサリアムの主要なアップグレードの間に、クライアントは target と max のブロブを例えば9と12に増やすことに合意でき、その後ノードオペレーターはその小さなフォークに参加するためにアップデートします。これらのブロブ・パラメータ・オンリー・フォークはいつでも設定できます。

デンクン・アップグレードで初めてネットワークにブロブが追加されたとき、ターゲットは3でした。それはペクトラで6に増やされ、フサカ以降は、これらの主要なネットワーク・アップグレードとは独立して、持続可能なペースで増やすことができるようになります。

Chart showing average blob count per block and increasing targets with upgrades

グラフの出典: Ethereum Blobs - @hildobby, Dune Analytics (opens in a new tab)

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

実行コストによって制限されるブロブの基本料金

レイヤー2 (L2) はデータを投稿する際に2つの料金を支払います。ブロブ手数料と、それらのブロブを検証するために必要な実行ガスです。実行ガスが支配的になると、ブロブ手数料のオークションは1 Weiまで急落し、価格シグナルとしての機能を果たさなくなる可能性があります。

EIP-7918は、すべてのブロブの下に比例した最低価格（リザーブ価格）を固定します。最低価格が名目上のブロブの基本料金よりも高い場合、手数料調整アルゴリズムはブロックがターゲットを超過していると見なし、手数料の引き下げを停止して、正常に上昇できるようにします。その結果：

  • ブロブ手数料市場は常に混雑に反応するようになります
  • レイヤー2 (L2) は、ノードに強いる計算の少なくとも意味のある部分を支払うようになります
  • 実行レイヤー（EL）での基本料金の急騰によって、ブロブ手数料が1 Weiで立ち往生することはなくなります

リソース:

レイヤー1 (L1) のスケーリング

履歴の失効とよりシンプルなレシート

2025年7月、イーサリアムの実行クライアントは部分的な履歴の失効のサポートを開始しました (opens in a new tab)。これは、イーサリアムが成長し続ける中で、ノードオペレーターが必要とするディスク容量を削減するために、マージ (opens in a new tab)より古い履歴を破棄するものです。

このEIPは、フォークが実際に変更を実装するわけではないため、「コアEIP」とは別のセクションにあります。これは、クライアントチームがフサカ・アップグレードまでに履歴の失効をサポートしなければならないという通知です。実際には、クライアントはこれをいつでも実装できますが、アップグレードにこれを追加することで、具体的に彼らのTo-Doリストに載せ、この機能と組み合わせてフサカの変更をテストできるようにしました。

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

MODEXPの上限の設定

これまで、MODEXPプリコンパイルは事実上あらゆるサイズの数値を受け入れていました。そのため、テストが難しく、悪用されやすく、クライアントの安定性にとってリスクがありました。EIP-7823は明確な制限を設けます。各入力数値は最大8192ビット（1024バイト）の長さになります。それより大きいものは拒否され、トランザクションのガスは燃焼され、状態の変更は発生しません。ガス・リミットの計画やセキュリティレビューを複雑にしていた極端なケースを排除しつつ、現実世界のニーズを非常に快適にカバーします。この変更は、ユーザーや開発者のエクスペリエンスに影響を与えることなく、より高いセキュリティとDoS保護を提供します。

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

トランザクションのガス・リミットの上限

EIP-7825 (opens in a new tab)は、トランザクションあたり16,777,216 (2^24) ガスの制限を追加します。これは、ブロックのガス・リミットを引き上げる際に、単一のトランザクションの最悪のケースのコストを制限することによる、プロアクティブなDoS強化です。これにより、検証と伝播のモデル化が容易になり、ガス・リミットの引き上げによるスケーリングに取り組むことができるようになります。

なぜ正確に2^24ガスなのでしょうか？それは現在のガス・リミットよりも十分に小さく、実際のコントラクトのデプロイや重いプリコンパイルには十分な大きさであり、2の累乗であるためクライアント間での実装が容易だからです。この新しい最大トランザクションサイズは、ペクトラ以前の平均ブロックサイズに似ており、イーサリアム上のあらゆる操作にとって妥当な制限となります。

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

MODEXP のガスコストの増加

MODEXPは、RSA署名の検証や証明システムで使用される大数演算の一種であるモジュラべき乗を計算する、プリコンパイルされた組み込み関数です。これにより、コントラクトはこれらの計算を自分で実装することなく、直接実行できるようになります。

開発者とクライアントチームは、現在のガス価格設定では特定の入力がどれだけの計算能力を必要とするかを過小評価することが多いため、MODEXPがブロックのガス・リミットを増やす上での大きな障害であると特定しました。これは、MODEXPを使用する1つのトランザクションが、ブロック全体を処理するのに必要な時間の大部分を占め、ネットワークを遅延させる可能性があることを意味します。

このEIPは、実際の計算コストに合わせるために価格設定を次のように変更します。

  • 最小料金を200ガスから500ガスに引き上げ、一般的なコスト計算におけるEIP-2565の3分の1の割引を削除します
  • 指数の入力が非常に長い場合、コストをより急激に増加させます。指数（第2引数として渡す「累乗」の数値）が32バイト / 256ビットより長い場合、追加のバイトごとにガス料金がはるかに速く上昇します
  • 大きな底やモジュラスにも追加料金を課します。他の2つの数値（底とモジュラス）は少なくとも32バイトであると想定されており、どちらかがそれより大きい場合、コストはそのサイズに比例して上昇します

コストを実際の処理時間により適切に一致させることで、MODEXPがブロックの検証に時間がかかりすぎる原因になることはなくなります。この変更は、将来イーサリアムのブロックのガス・リミットを安全に増やすことを目的としたいくつかの変更のうちの1つです。

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

RLP実行ブロックサイズ制限

これは、ブロックの許容される大きさに上限を設けるものです。これはネットワーク上で_送信される_ものに対する制限であり、ブロック内の_作業_を制限するガス・リミットとは異なります。ブロックサイズの上限は10 MiBで、すべてが収まり、きれいに伝播するように、コンセンサスデータ用に小さなアローワンス（2 MiB）が予約されています。それより大きいブロックが現れた場合、クライアントはそれを拒否します。 非常に大きなブロックはネットワーク全体に広がり検証されるのに時間がかかり、コンセンサスの問題を引き起こしたり、DoSベクターとして悪用されたりする可能性があるため、これが必要です。また、コンセンサス・レイヤーのゴシップはすでに約10 MiBを超えるブロックを転送しないため、実行レイヤーをその制限に合わせることで、「一部のノードには見え、他のノードにはドロップされる」という奇妙な状況を回避できます。

詳細：これはRLPエンコードされた実行ブロックサイズの上限です。合計10 MiBで、ビーコン・ブロックのフレーミング用に2 MiBの安全マージンが予約されています。実際には、クライアントは次のように定義します。

MAX_BLOCK_SIZE = 10,485,760 バイト、および

SAFETY_MARGIN = 2,097,152 バイト、

そして、RLPペイロードが以下を超える実行ブロックを拒否します。

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

目標は、最悪のケースの伝播/検証時間を制限し、コンセンサス・レイヤーのゴシップの動作と一致させることで、ガスのアカウンティングを変更することなく、リオーグ/DoSのリスクを軽減することです。

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

デフォルトのガス・リミットを6000万に設定

2025年2月にガス・リミットを3000万から3600万に（そしてその後4500万に）引き上げる前は、この値はマージ（2022年9月）以来変更されていませんでした。このEIPは、一貫したスケーリングを優先することを目的としています。

EIP-7935は、フサカに向けてデフォルトのガス・リミットを現在の4500万より引き上げるよう、実行レイヤー（EL）クライアントチームを調整します。これは情報提供のEIPですが、デブネットでより高い制限をテストし、安全な値に収束させ、その数値をフサカのリリースに組み込むことをクライアントに明示的に求めています。

デブネットの計画では、約6000万のストレス（合成負荷をかけたフルブロック）と反復的な引き上げを目標としています。調査によると、最悪のケースのブロックサイズの病理は、約1億5000万未満では制限にならないはずです。ロールアウトは、制限が上がるにつれて単一のトランザクションが支配的にならないように、トランザクションのガス・リミットの上限（EIP-7825）と組み合わせる必要があります。

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

UXの向上

決定論的なプロポーザーの先読み

EIP-7917により、ビーコン・チェーンは次のエポックの今後のブロック・プロポーザーを認識するようになります。どのバリデータが将来のブロックを提案するかについて決定論的な見解を持つことで、事前確認（preconfirmations） (opens in a new tab)が可能になります。これは、実際のブロックを待つことなく、ユーザートランザクションがそのブロックに含まれることを保証する、今後のプロポーザーとのコミットメントです。

この機能は、バリデータがプロポーザーのスケジュールを操作できるエッジケースを防ぐため、クライアントの実装とネットワークのセキュリティに利益をもたらします。また、先読みにより、実装の複雑さを軽減することもできます。

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

先行ゼロカウント（CLZ）オペコード

この機能は、小さなEVM命令である**先行ゼロカウント（CLZ）**を追加します。EVM内のほとんどのものは256ビットの値として表されますが、この新しいオペコードは、先頭にいくつのゼロビットがあるかを返します。これは、より効率的な算術演算を可能にするため、多くの命令セットアーキテクチャで一般的な機能です。実際には、これにより今日の手動のビットスキャンが1つのステップに集約されるため、最初のセットビットの検索、バイトのスキャン、またはビットフィールドの解析がより簡単かつ安価になります。このオペコードは低コストで固定コストであり、基本的な加算と同等であることがベンチマークで示されており、同じ作業でバイトコードを削減し、ガスを節約します。

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

secp256r1曲線をサポートするためのプリコンパイル

固定アドレス 0x100 に、組み込みのパスキースタイルのsecp256r1 (P-256) 署名チェッカーを導入します。これは、多くのレイヤー2 (L2) で既に採用されているのと同じ呼び出し形式を使用し、エッジケースを修正しているため、それらの環境向けに書かれたコントラクトは変更なしでレイヤー1 (L1) で機能します。

UXのアップグレードです！ユーザーにとっては、これによりデバイスネイティブな署名とパスキーが解放されます。ウォレットは、Apple Secure Enclave、Androidのキーストア、ハードウェアセキュリティモジュール（HSM）、およびFIDO2/WebAuthnを直接利用できます。シード・フレーズは不要で、よりスムーズなオンボーディング、そして最新のアプリのように感じられる多要素フローが実現します。これにより、UXが向上し、リカバリが容易になり、何十億ものデバイスがすでに行っていることと一致するアカウント抽象化パターンがもたらされます。

開発者にとっては、160バイトの入力を受け取り、32バイトの出力を返すため、既存のライブラリやレイヤー2 (L2) のコントラクトを簡単に移植できます。内部的には、無限遠点やモジュラ比較のチェックが含まれており、有効な呼び出し元を壊すことなく、厄介なエッジケースを排除します。

リソース:

メタ

eth_config JSON-RPCメソッド

これは、実行しているフォークの設定をノードに尋ねることができるJSON-RPC呼び出しです。バリデータや監視ツールが、クライアントが今後のフォークに向けて準備できているかを確認できるように、current、next、および last の3つのスナップショットを返します。

現実的に言えば、これは2025年初頭にホルスキーのテストネットでペクトラ・フォークが稼働した際に、軽微な設定ミスによってファイナライズされない状態になったという欠点に対処するためのものです。これにより、テストチームや開発者は、デブネットからテストネットへ、そしてテストネットからメインネットへ移行する際に、主要なフォークが期待通りに動作することを確認できます。

スナップショットには、chainId、forkId、計画されているフォークの有効化時間、どのアクティブなプリコンパイルがあるか、プリコンパイルのアドレス、システムコントラクトの依存関係、およびフォークのブロブスケジュールが含まれます。

このEIPは、フォークが実際に変更を実装するわけではないため、「コアEIP」とは別のセクションにあります。これは、クライアントチームがフサカ・アップグレードまでにこのJSON-RPCメソッドを実装しなければならないという通知です。

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

よくある質問 (FAQ)

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

はい、フサカ・アップグレードでは、実行クライアントとコンセンサス・クライアントの両方のアップデートが必要です。すべての主要なイーサリアムクライアントは、優先度高とマークされたハード・フォークをサポートするバージョンをリリースします。これらのリリースがいつ利用可能になるかは、クライアントのGitHubリポジトリ、彼らのディスコードチャンネル (opens in a new tab)、EthStakerのディスコード (opens in a new tab)で確認するか、プロトコルのアップデートについてイーサリアムのブログを購読することで把握できます。アップグレード後にイーサリアム・ネットワークとの同期を維持するために、ノードオペレーターはサポートされているクライアントバージョンを実行していることを確認する必要があります。クライアントのリリースに関する情報は時間に敏感であるため、ユーザーは最新の詳細について最新のアップデートを参照する必要があることに注意してください。

ハード・フォーク後、ETHはどのように変換できますか？

  • あなたのETHに必要なアクションはありません: イーサリアムのフサカ・アップグレード後、ETHを変換したりアップグレードしたりする必要はありません。アカウントの残高は同じままであり、現在保持しているETHは、ハード・フォーク後も既存の形式でアクセス可能なままです。
  • 詐欺に注意してください！ ETHを「アップグレード」するように指示する人は、あなたを騙そうとしています。 このアップグレードに関連してあなたがしなければならないことは何もありません。あなたの資産は完全に影響を受けません。情報を得ておくことが詐欺に対する最善の防御であることを忘れないでください。

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

シマウマとは何ですか？

シマウマは、フサカの開発者が選んだ「マスコット」です。その縞模様が、PeerDASの列ベースのデータ可用性サンプリングを反映しているためです。このサンプリングでは、ノードが特定の列のサブネットを保管し、各ピアのスロットから他のいくつかの列をサンプリングして、ブロブデータが利用可能であることを確認します。

2022年のマージでは、実行レイヤーとコンセンサス・レイヤーの結合を示すために、パンダをマスコットとして使用しました (opens in a new tab)。それ以来、各フォークで非公式にマスコットが選ばれ、アップグレード時のクライアントログにアスキーアートとして表示されています。これは単に祝うための楽しい方法です。

L2スケーリングにはどのような改善が含まれていますか？

PeerDASは、このフォークの主な機能です。これはデータ可用性サンプリング（DAS）を実装し、ロールアップのさらなるスケーラビリティを解放し、理論的にはブロブスペースを現在のサイズの最大8倍にスケーリングします。ブロブ手数料市場も改善され、混雑に効率的に反応し、ブロブがノードに課す計算とスペースに対して、レイヤー2 (L2) が意味のある手数料を支払うことを保証します。

BPOフォークはどのように異なりますか？

ブロブ・オンリー・パラメータ（BPO）フォークは、PeerDASが有効化された後、完全に調整されたアップグレードを待つことなく、ブロブ数（ターゲットと最大値の両方）を継続的に増やすメカニズムを提供します。各増加は、フサカをサポートするクライアントリリースで事前に設定されるようにハードコードされています。

ユーザーまたはバリデータとして、各BPOのためにクライアントをアップデートする必要はなく、フサカのような主要なハード・フォークに従うことだけを確認してください。これは以前と同じ慣行であり、特別なアクションは必要ありません。ハード・フォークの後に修正や最適化が行われる可能性があるため、アップグレードやBPOの前後でクライアントを監視し、メジャーリリースの間でもアップデートを維持することが引き続き推奨されます。

BPOのスケジュールはどうなっていますか？

BPOアップデートの正確なスケジュールは、フサカのリリースとともに決定される予定です。プロトコルの発表 (opens in a new tab)とクライアントのリリースノートに従ってください。

どのようになるかの例：

  • フサカ以前：ターゲット6、最大9
  • フサカ有効化時：ターゲット6、最大9
  • BPO1（フサカ有効化の数週間後）：ターゲット10、最大15（3分の2増加）
  • BPO2（BPO1の数週間後）：ターゲット14、最大21

これによりイーサリアム（レイヤー1）の手数料は下がりますか？

このアップグレードは、少なくとも直接的には、レイヤー1 (L1) のガス手数料を下げません。主な焦点はロールアップデータのためのより多くのブロブスペースであり、それによってレイヤー2 (L2) の手数料を下げます。これはレイヤー1 (L1) の手数料市場にいくつかの副作用をもたらすかもしれませんが、大きな変更は予想されていません。

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

すべてのネットワーク・アップグレードと同様に、フサカのサポートがマークされた最新バージョンにクライアントをアップデートしてください。リリースに関する情報を得るには、メーリングリストとEFブログのプロトコルの発表 (opens in a new tab)のアップデートに従ってください。 メインネットでフサカが有効化される前にセットアップを検証するために、テストネットでバリデータを実行できます。フサカはテストネットでより早く有効化される (opens in a new tab)ため、すべてが機能することを確認し、バグを報告するためのより多くの時間が与えられます。テストネットのフォークもメーリングリストとブログで発表されます。

「決定論的なプロポーザーの先読み」（EIP-7917）はバリデータに影響しますか？

この変更はバリデータクライアントの機能方法を変更しませんが、バリデータの義務の将来についてより多くの洞察を提供します。新機能に対応するために、監視ツールを必ずアップデートしてください。

フサカはノードとバリデータの帯域幅要件にどのように影響しますか？

PeerDASは、ノードがブロブデータを送信する方法に大きな変更をもたらします。すべてのデータは128のサブネットにわたって列と呼ばれる断片に分割され、ノードはその一部のみをサブスクライブします。ノードが保管しなければならないサブネットの列の量は、その設定と接続されているバリデータの数によって異なります。実際の帯域幅要件は、ネットワークで許可されているブロブの量とノードのタイプによって異なります。フサカの有効化の時点では、ブロブのターゲットは以前と同じままですが、PeerDASにより、ノードオペレーターはブロブのディスク使用量とネットワークトラフィックの減少を確認できます。BPOがネットワーク内でより多くのブロブを設定するにつれて、必要な帯域幅は各BPOとともに増加します。

フサカのBPO後でも、ノードの要件は依然として推奨されるマージン (opens in a new tab)内にあります。

フル・ノード

バリデータを持たない通常のノードは4つのサブネットのみをサブスクライブし、元のデータの1/8を保管します。これは、同じ量のブロブデータでも、それらをダウンロードするノードの帯域幅が8分の1になることを意味します。通常のフル・ノードのブロブのディスク使用量とダウンロード帯域幅は、約80%減少してわずか数Mbになる可能性があります。

ソロステーカー

ノードがバリデータクライアントに使用される場合、より多くの列を保管し、したがってより多くのデータを処理する必要があります。バリデータが追加されると、ノードは少なくとも8つの列サブネットをサブスクライブするため、通常のノードの2倍のデータを処理しますが、それでもフサカ以前よりは少なくなります。バリデータの残高が287 ETHを超える場合、さらに多くのサブネットがサブスクライブされます。

ソロステーカーにとって、これはディスク使用量とダウンロード帯域幅が約50%減少することを意味します。ただし、ローカルでブロックを構築し、すべてのブロブをネットワークにアップロードするには、より多くのアップロード帯域幅が必要です。ローカルビルダーは、フサカの時点では以前の2〜3倍のアップロード帯域幅を必要とし、15/21ブロブのBPO2ターゲットでは、最終的に必要なアップロード帯域幅は約5倍の100Mbpsになる必要があります。

大規模なバリデータ

サブスクライブされるサブネットの数は、ノードに追加される残高とバリデータが増えるにつれて増加します。たとえば、約800 ETHの残高の場合、ノードは25の列を保管し、以前よりも約30%多くのダウンロード帯域幅を必要とします。必要なアップロードは通常のノードと同様に上昇し、少なくとも100Mbpsが必要です。

4096 ETH、つまり最大残高のバリデータが2つの場合、ノードはすべての列を保管する「スーパーノード」になり、したがってすべてをダウンロードして保存します。これらのノードは、欠落しているデータを還元することでネットワークを積極的に修復しますが、はるかに多くの帯域幅とストレージも必要とします。最終的なブロブのターゲットが以前の6倍になるため、スーパーノードは約600GBの追加のブロブデータを保存し、約20Mbpsのより高速な持続的ダウンロード帯域幅を持つ必要があります。

予想される要件の詳細を読む。 (opens in a new tab)

どのようなEVMの変更が実装されていますか？

フサカは、新しいマイナーな変更と機能でEVMを強化します。

新しい1600万のガス・リミットはコントラクト開発者にどのように影響しますか？

フサカは、単一のトランザクションの最大サイズを1670万 (opens in a new tab) (2^24) ガス単位に制限します。これは、以前の平均的なブロックのサイズとほぼ同じであり、ブロック全体を消費するような複雑なトランザクションを収容するのに十分な大きさです。この制限はクライアントの保護を生み出し、将来のより高いブロックのガス・リミットでの潜在的なDoS攻撃を防ぎます。スケーリングの目標は、単一のトランザクションがブロック全体を消費することなく、より多くのトランザクションがブロックチェーンに入ることを可能にすることです。

通常のユーザートランザクションは、この制限に達するにはほど遠いです。大規模で複雑な分散型金融 (DeFi) 操作、大規模なスマート・コントラクトのデプロイ、または複数のコントラクトを対象とするバッチトランザクションなどの特定のエッジケースは、この変更の影響を受ける可能性があります。これらのトランザクションは、より小さなものに分割するか、別の方法で最適化する必要があります。制限に達する可能性のあるトランザクションを送信する前に、シミュレーションを使用してください。

RPCメソッド eth_call は制限されておらず、実際のブロックチェーンの制限よりも大きなトランザクションのシミュレーションを可能にします。RPCメソッドの実際の制限は、悪用を防ぐためにクライアントオペレーターが設定できます。

CLZは開発者にとって何を意味しますか？

SolidityのようなEVMコンパイラは、内部的にゼロをカウントするための新機能を実装して利用します。新しいコントラクトは、この種の操作に依存している場合、ガスの節約の恩恵を受ける可能性があります。潜在的な節約に関するドキュメントについては、スマート・コントラクト言語のリリースと機能の発表に従ってください。

既存のスマート・コントラクトに変更はありますか？

フサカには、既存のコントラクトを壊したり、その動作を変更したりするような直接的な影響はありません。実行レイヤーに導入された変更は下位互換性を持って行われますが、エッジケースと潜在的な影響には常に注意を払ってください。

ModExp プリコンパイルのコストが増加したため (opens in a new tab)、それに依存するコントラクトは実行により多くのガスを消費します。コントラクトがこれに大きく依存しており、ユーザーにとってより高価になる場合は、その利用方法を再考してください。

コントラクトを実行するトランザクションが同様のサイズに達する可能性がある場合は、新しい1670万の制限 (opens in a new tab)を考慮してください。

参考文献

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

UaittU (opens in a new tab)
architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
+6