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

ページの最終更新日時: 2026年2月23日

Fusaka

イーサリアム待望のFusakaアップグレードが2025年12月3日に公開されました

Fusakaネットワークアップグレードは Pectra に続くもので、さらなる新機能をもたらし、すべてのイーサリアムユーザーと開発者のエクスペリエンスを向上させます。 その名称は、実行レイヤーのアップグレード Osaka と、Fulu star にちなんで名付けられたコンセンサスレイヤーのバージョンで構成されています。 イーサリアムの両方のパートがアップグレードを受け、イーサリアムのスケーリング、セキュリティ、ユーザーエクスペリエンスを未来へと押し進めます。

Fusakaにおける改善点

ブロブのスケーリング

PeerDAS

これはFusakaフォークの_目玉_であり、このアップグレードで追加されるメインの機能です。 レイヤー2は現在、レイヤー2専用に作成された一時的なデータタイプであるblobを使用して、データをイーサリアムに投稿しています。 Fusaka以前は、すべてのフルノードがデータの存在を保証するためにすべてのblobを保存する必要がありました。 Blobのスループットが増加するにつれて、これらすべてのデータをダウンロードすることは、リソースの負荷が高くなりすぎて維持できなくなります。

データ可用性サンプリング (opens in a new tab)では、すべてのblobデータを保存する必要がなくなり、各ノードがblobデータのサブセットを担当するようになります。 Blobはネットワーク内のノード全体に均一にランダムに分散され、各フルノードはデータの8分の1のみを保持するため、理論上8倍までのスケールアップが可能になります。 データの可用性を確保するために、データ全体のうち既存の50%の部分から任意のデータ部分を再構築できるようになっており、誤りや欠損データが発生する確率を暗号学的に無視できるレベル(約1020分の1から1024分の1)まで低減する手法が用いられています。

これにより、ノードのハードウェアとバンド幅の要件を維持可能なレベルに保ちながら、blobのスケーリングを可能にし、レイヤー2のより大きなスケールとより低い手数料を実現します。

PeerDASについてもっと知る

参考リソース:

ブロブパラメータのみのフォーク

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

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

これらの協調的なアップグレードには、通常多くの変更が含まれ、膨大なテストを必要とし、そのために時間がかかります。 変化するレイヤー2のブロブ需要により迅速に対応するために、「blobパラメータのみのフォーク（blob parameter–only forks）」は、従来のアップグレードスケジュールを待たずにブロブ数を増やすための仕組みを導入します。

ブロブパラメータのみのフォークは、ガスリミットなどの他の設定と同様に、クライアントによって設定することができます。 主要なイーサリアムアップグレードの合間に、クライアント同士が合意して「target」および「max」ブロブ数をたとえば9と12に増やすことができ、その後、ノードオペレーターはその小規模なフォークに参加するためにソフトウェアを更新します。 これらのblobパラメータのみのフォークは、いつでも設定することができます。

Dencunアップグレードでブロブが初めてネットワークに追加されたとき、ターゲットは3でした。 Pectraでは6に増加し、Fusaka以降は、これらの主要なネットワークアップグレードとは無関係に、持続可能なレートで増加させることができるようになります。

ブロックごとの平均ブロブ数とアップグレードによるターゲットの増加を示すグラフ

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

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

実行コストによって制約されるblobのベース料金

レイヤー2はデータを投稿する際に2つの費用を支払います。blob手数料と、それらのblobを検証するために必要な実行ガスです。 実行ガスが支配的な場合、blob手数料のオークションが1 weiまで下落し、価格シグナルとしての機能を失う可能性があります。

EIP-7918は、すべてのblobに比例したリザーブ価格を設定します。 リザーブが名目上のブロブベースフィーより高い場合、手数料調整アルゴリズムはブロックをターゲット超過として扱い、手数料の引き下げを停止し、通常通りに上昇できるようにします。 その結果：

  • blob手数料マーケットは常に混雑に反応します
  • レイヤー2は、自身がノードに課す計算負荷に対して、少なくとも意味のある一部のコストを支払う必要があります
  • 実行レイヤーのベース手数料の急騰がblob手数料を1 weiに放置することができなくなります

参考リソース:

L1のスケーリング

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

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

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

参考リソース: 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) は、1トランザクションあたり 16,777,216（2²⁴）ガスの上限を追加します。 これは、ブロックガスリミットを引き上げる際に、単一トランザクションの最悪ケースのコストを制限することで、DoS攻撃に対する防御を事前に強化するものです。 これにより、検証および伝播のモデル化が容易になり、ガスリミットの引き上げによるスケーリングへの取り組みが可能になります。

なぜ正確に 2²⁴ ガスなのか？ これは現在のガスリミットより十分に小さく、実際のコントラクトのデプロイや重いプリコンパイルにも対応できる大きさであり、2のべき乗であるためクライアント間での実装が容易です。 この新しい最大トランザクションサイズは、Pectra以前の平均ブロックサイズに近く、イーサリアム上でのあらゆる処理に対して妥当な上限となっています。

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

MODEXPのガスコスト引き上げ

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

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

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

  • 最小料金を 200 ガスから 500 ガスに引き上げ、EIP-2565 によって一般的なコスト計算に適用されていた 3分の1の割引 を廃止します
  • 指数の入力が非常に長い場合、そのコストをより急激に増加させます。 もし指数（つまり第2引数として渡される「べき乗」の数）が32バイト／256ビットを超える場合、追加される1バイトごとにガス料金がはるかに速いペースで上昇します
  • 大きな基数（base）や法（modulus）に対しても追加料金を課します。 他の2つの数値（基数と法）は、少なくとも32バイトであると想定されています。どちらか一方がそれより大きい場合、そのサイズに比例してコストが上昇します

コストを実際の処理時間により正確に対応させることで、MODEXP がブロックの検証に過剰な時間を要する原因となることはなくなります。 この変更は、将来的にイーサリアムのブロックガスリミットを安全に引き上げられるようにすることを目的とした複数の取り組みのうちの1つです。

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

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

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

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

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月にガスリミットが 30M から 36M に（その後 45M に）引き上げられるまで、この値は Merge（2022年9月）以降、変更されていませんでした。 この EIP は、一貫したスケーリングを最優先事項とすることを目的としています。

EIP-7935 は、実行層（EL）クライアントチーム間で調整を行い、Fusaka に向けて現在の 45M を超えるデフォルトのガスリミットを引き上げることを目的としています。 これは情報提供用のEIPですが、クライアントに対してdevnetでより高いリミットをテストし、安全な値に収束させ、Fusakaリリースでその数値を実装することを明示的に求めています。

開発ネットワーク（devnet）の計画では、約 60M の負荷テスト（合成負荷によるフルブロック）と段階的な引き上げを目標としています。研究によれば、最悪ケースのブロックサイズによる異常な性能低下や問題の発生は、おおよそ 150M 未満では起きないとされています。 展開は、トランザクションガスリミットキャップ(EIP-7825)と組み合わせて行われるべきで、リミットが上昇しても単一のトランザクションが支配的にならないようにします。

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

UXの向上

決定論的プロポーザールックアヘッド

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

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

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

先頭ゼロカウント(CLZ)オペコード

この機能は、**先頭ゼロカウント(CLZ)**という小さなEVM命令を追加します。 EVM内のほとんどすべては256ビット値として表現されており、この新しいオペコードは先頭にいくつのゼロビットがあるかを返します。 これは多くの命令セットアーキテクチャで一般的な機能であり、より効率的な算術演算を可能にします。 実際には、これにより現在の手動でのビットスキャンが1ステップに圧縮されるため、最初のセットビットを見つけたり、バイトをスキャンしたり、ビットフィールドを解析することがよりシンプルかつ安価になります。 このオペコードは低コストで固定料金となっており、基本的な加算（add）命令と同程度の性能であることがベンチマークによって確認されています。これにより、同じ処理をより短いバイトコードで実行でき、ガスの節約にもつながります。

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

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

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

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

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

参考リソース:

メタ

eth_config JSON-RPCメソッド

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

実際には、これは2025年初頭にPectraフォークがHoleskyテストネットで公開された際に発見された、軽微な設定ミスが原因でファイナライズされない状態に陥ったという欠点に対処するためのものです。 これにより、テストチームや開発者は、devnetからテストネットへ、そしてテストネットからメインネットへ移行する際に、主要なフォークが期待どおりに動作することを確認できます。

スナップショットには、chainId、forkId、計画されたフォークのアクティベーション時間、アクティブなプリコンパイル、プリコンパイルのアドレス、システムコントラクトの依存関係、フォークのブロブスケジュールが含まれます。

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

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

よくある質問

このアップグレードは、イーサリアムノード全体やバリデータに影響しますか？

はい、Fusaka アップグレードでは、実行クライアントとコンセンサスクライアント の両方を更新する必要があります。 主要なイーサリアムクライアントのはすべて、高い優先度でハードフォーク対応バージョンをリリースします。 これらのリリース時期については、各クライアントの GitHub リポジトリや、Discord チャンネル (opens in a new tab)、EthStaker Discord (opens in a new tab) で最新情報を確認できます。 また、Ethereum のブログを購読することで、プロトコルの更新情報を受け取ることもできます。 アップグレード後もイーサリアムネットワークと同期を維持するために、ノードオペレーターはサポートされているクライアントバージョンを実行していることを確認する必要があります。 なお、クライアントリリースに関する情報は時間とともに変化するため、ユーザーは現時点の詳細情報を知るために、最新のアップデートを参照すべきです。

ハードフォーク後にETHはどのように変換されるのでしょうか?

  • ETHに対して特別な操作は不要です：Ethereum の Fusaka アップグレード後も、ETH を変換したりアップグレードしたりする必要はありません。 あなたのアカウント残高は同じままで、現在保有しているETHはハードフォーク後も既存の形式でアクセス可能です。
  • 詐欺に注意してください！ ETHを「アップグレード」するよう指示する人は、詐欺を試みています。このアップグレードに関して、あなたがする必要のあることは何もありません。 あなたの資産は完全に影響を受けません。 詐欺から身を守る最善の方法は、情報を得ておくことです。

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

なぜシマウマなのですか？

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

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

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

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

BPOフォークはどのように違うのですか？

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

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

BPOのスケジュールは何ですか？

BPOアップデートの正確なスケジュールは、Fusakaのリリースと共に決定されます。 プロトコル発表 (opens in a new tab)とクライアントのリリースノートをフォローしてください。

以下に例を示します:

  • Fusaka前: ターゲット6、最大9
  • Fusakaアクティベーション時: ターゲット6、最大9
  • BPO1、Fusakaアクティベーションの数週間後: ターゲット10、最大15、3分の2増加
  • BPO2、BPO1の数週間後: ターゲット14、最大21

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

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

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

すべてのネットワークアップグレードと同様に、Fusakaサポートとマークされた最新バージョンのクライアントに必ずアップデートしてください。 メーリングリストの更新情報やEFブログのプロトコル発表 (opens in a new tab)をフォローして、リリースに関する情報を入手してください。 Fusakaがメインネットでアクティベートされる前に設定を検証するために、テストネットでバリデータを実行できます。 Fusakaはテストネットでより早くアクティベートされる (opens in a new tab)ため、すべてが機能することを確認し、バグを報告するための時間が増えます。 テストネットのフォークもメーリングリストやブログで発表されます。

「決定的プロポーザールックアヘッド」(EIP-7917)はバリデータに影響しますか？

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

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

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

Fusaka BPOの後でも、ノードの要件は推奨マージン (opens in a new tab)の範囲内です。

フルノード

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

ソロステーカー

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

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

大規模バリデータ

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

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

予想される要件に関する詳細はこちら。 (opens in a new tab)

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

Fusakaは、新しい軽微な変更と機能でEVMを強化します。

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

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

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

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

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

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

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

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

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

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

参考リンク

最終更新： 2026年2月23日

mnelsonBTm (opens in a new tab)
konopkjak (opens in a new tab)
architr4a (opens in a new tab)
+5

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