暗号資産（仮想通貨）専業10年目の墨汁うまい（@bokujyuumai）です。イーサリアムは5月に実装したペクトラ（Pectra）アップデートに続き、年内2回目となるフサカ（Fusaka）アップデートを12月3日に実施します。
本稿ではこのイーサリアムを大きく変えるフサカアップデートの内容とイーサリアムやアービトラム（Arbitrum : ARB）やジーケーシンク（zkSync : ZK）といったレイヤー2ネットワークなどを含むイーサリアムエコシステムへの影響について仮想通貨（暗号資産）投資家向けにわかりやすく解説を行います。
フサカアップデートのEIP
フサカアップデートでは9つのEIP、すなわちイーサリアム改善提案が導入されることになり、内容は下記となっています。
・EIP-7594：PeerDASの実装
・EIP-7642：保持するブロックデータの期間を設定
・EIP-7823：NODEXPの上限設定
・EIP-7825：トランザクションのガスリミット設定
・EIP-7883：ModExpガスコストの引き上げ
・EIP-7892：Blobsのパラメータ変更
・EIP-7918：Blobsの手数料市場調整
・EIP-7934：RLPのブロックサイズを10MBへ
・EIP-7935：ELのデフォルトガスを6000万へ
これは主にイーサリアム自体の変更と、イーサリアム上に展開するロールアップのようなレイヤー2ネットワークに影響を与えるものに分類することができ、この中でも最も大きな変更となるのがEIP-7594の「ピアダス（PeerDAS）」です。
ピアダス（PeerDAS）とは？
ピアダスとはイーサリアムが2023年4月に行った大型アップデート、デンクン（Dencun）で実装したプロトダンクシャーディング（Proto-Danksharding）という新たなトランザクション形式の保存とネットワーク内における共有方法を変更するというものです。
このプロトダンクシャーディングではイーサリアムをレイヤー1として使用するロールアッププロジェクトが書き込むコールデータ（CALLDATA）をブロブ（Blob）として取り扱い、ブロックとは特別なサイドカーを用意して一定期間のみ保持するという形式となります。
一方でピアダスではこれまでこれらのブロブを全ノードが保管しなければいけなかった方式を大幅に変え、CDやDVDが採用している復元方式を応用してデータの一部を保持することで容量を減らし、理論上約8倍までブロブを増やしてもネットワーク帯域の負担はそのままという画期的な実装方法となるのです。
これにより増えるレイヤー2需要を現状から8倍まで拡大しても問題がないということになるのです。
またピアダスではすべてのブロブデータを有するスーパーノードと128のサブネット（Subnet）という構造も新たに導入し、スーパーノードは3872ETHというステーキング数が必要で、約18.7億円（1ETH=48万円換算）でセキュアに保たれるのです。
ブロブの変更点でソラナレベルのTPSへ
また他のレイヤー2に影響を与えるものとしてはEIP-7892「Blobsのパラメータ変更」やEIP-7918「Blobsの手数料市場調整」があります。
前者のEIP-7892ではピアダスが理論上8倍のスケーリングを現状の負担を変えずにできる一方、即座に8倍にするのではなく需要の増加による段階的変更が望ましいといえるでしょう。そのためここではブロブを各イーサリアムクライアントが段階的に引き上げできるようにするというものであり、5月に変更された目標6ブロブ、最大9ブロブというキャパシティを2026年初旬に向けて目標14ブロブ、最大21ブロブに2段階で引き上げるというものです。
これによりイーサリアムのレイヤー2は最大で1000TPS（秒間トランザクション）を処理することができ、ソラナ（SOL）と同レベルのスケーリング能力を手にすることができるという大きな変更となるでしょう。
後者のEIP-7918はブロブの手数料市場が当初の予定よりも弾性がなく、需要と供給で変動する一方でトランザクションを処理するロールアップのシーケンサーがエコノミックモデルに従っていない実情が指摘されています。そこで手数料市場を調整し、ブロブ手数料が一定数を下回らないように下限を設定して調整するというものです。
ブロックチェーンサイズ問題の解決へ大きく前進
イーサリアムはいわゆる「ロールアップ中心(Rollup-Centric)」のスケーリングを行うことが元から決まっており、デンクン、ペクトラと大きくL2への環境を変更してきたことがわかります。
一方でブロックチェーン問題として解決できていなかった点として「ブロックデータの保持」における運用ノードコスト負担の恒久的な増加という課題があります。そこでイーサリアムではペクトラでトランザクションやコントラクトが実行される実行レイヤー（Execution Layer）においてEIP-4444「１年以上古いデータのプルーニング(切り取り)」をオプションとして導入しました。
これによりクライアント側の設定で任意で古いデータを同期しないことで、300~500GBのSSD容量節約をすることが可能となったのです。
この背景として2022年に行われたプルーフ・オブ・ステークへの完全移行となるマージ（The Merge）から、現在のキャスパーFFGというコンセンサスは32スロット（ブロック）ごとにバリデータがフォークチョイスルールで投票を行い、最終的にその32スロットを確定するファイナライズを行うという形式となっています。
この32スロットを1つのエポック（期間）としたチェックポイント方式は事実上マージ以前の任意のブロックからイーサリアムを攻撃することができず、不必要なデータであるためそれらをすべてのブロックと直近の各アカウントやコントラクトのステート（状態）を有する「フルノード」が同期する義務をなくすというものです。
これはあくまですべてのステート（状態）とブロックデータを有するフルアーカイブノードがデータを保持しているため、必要な場合はそこから復元ができるということになります。
これは一見データ保持のための容量問題を解決したように見えたものの、現状古いブロックデータを参照する機会が減っており、同期を行う際にジェネシスブロック（0番目）のデータを持つノードが見つからないという同期問題を引き起こす原因にもなっているのも事実です。
そこで同期にマージ以前のデータを不要にすることで、より効率的にネットワーク帯域を確保しつつ、同期エラーをなくすことでバリデータ参入の障壁も下げるという効率的な実装であると言えるでしょう。
フサカアップデートに伴うユーザー影響
フサカアップデートには32ETHを自己バリデータノードで運用しているユーザー以外、特に対応を行う必要はありません。基本的に暗号資産取引所（仮想通貨取引所）やサービスプロバイダーが対応を行うため、ETHやステーブルコインなどをレイヤー2上に置いていても一切対応をする必要はないのです。
あくまで分散金融（DeFi）などを使用していたとしても大物のイーサリアムアップデートは各プロジェクトに直接的な影響はないため、そのまま安心して使用することができます。
｜文：墨汁うまい
｜編集：CoinDesk JAPAN編集部
｜画像：Shutterstock
