カンクン・アップグレード目前，有哪些需要注意的事项及潜在风险？
TechFlow厳選深潮セレクト
カンクン・アップグレード目前，有哪些需要注意的事项及潜在风险？
カンクンアップグレードは、1月17日、1月30日、2月7日にそれぞれイーサリアムのGoerli、Sepolia、Holeskyテストネットで完了し、3月13日にイーサリアムメインネット上でアクティベートされる予定です。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Salus Insights
要点まとめ：カンクンアップグレードが目前に迫っており、今回のアップグレードは主に6つのEIPによる実行層の変更を含みます。具体的にはEIP-1153、EIP-4788、EIP-4844、EIP-5656、EIP-6780およびEIP-7516です。その中でもEIP-4844が主役であり、イーサリアムのスケーラビリティ向上を目的としており、L2のトランザクションコスト削減と速度向上を実現します。カンクンアップグレードはすでに2024年1月17日、1月30日、2月7日にそれぞれイーサリアムのGoerli、SepoliaおよびHoleskyテストネットで完了しており、メインネットでのアクティベートは3月13日を予定しています。アップグレード前に、Salusは開発者が自身で確認すべき重要なセキュリティ上の注意点を整理しました。
EIPプロポーザルの概要
EIP-1153
EIP-1153は一時的ストレージ操作コード（TLOADおよびTSTORE、「T」は「Temporary」を意味）を導入し、状態操作を可能にします。これらの値は各トランザクション終了後に破棄されるため、永続的なストレージとは異なりディスクアクセスが不要で、コストが低くなります。この提案は、Ethereumのトランザクション実行中に複数のネストされた実行フレームワーク間の通信を効率化する専用ソリューションを提供することを目的としています。
EIP-4788
EIP-4788は、ビーコンチェーンブロックのMerkleツリールートをEVM内で利用可能にするもので、これにより信頼なしにコンセンサス層の状態にアクセスできます。ステーキングプール、リステーキング構造、スマートコントラクトブリッジ、MEV緩和など多様なユースケースをサポートします。本提案ではルートをコントラクト内に格納し、リングバッファ方式でストレージ消費を制限することで、各実行ブロックが一定量の空間で情報を表現できるようにしています。
EIP-4844
EIP-4844は「シャーディング用Blobトランザクション」と呼ばれる新しいトランザクション形式を導入し、シンプルかつ将来互換性のある方法でイーサリアムのデータ可用性を拡張します。Blobを含むトランザクションは大量のデータを運べますが、EVMからはそのデータ自体ではなくコミットメントのみが参照可能です。このフォーマットは将来の完全なシャーディングと互換性があり、ロールアップ型スケーリングに対して一時的だが顕著な負荷軽減を提供します。
EIP-5656
EIP-5656は、メモリ領域を効率的にコピーする新しいEVM命令MCOPYを導入します。これにより、EVM上でのメモリコピー操作のオーバーヘッドを削減し、ソースとターゲットアドレスが重なっても安全に動作します。データ構造の構築やメモリオブジェクトの効率的アクセス・コピーなど、さまざまなシナリオでの実行効率向上を目指しています。
EIP-6780
EIP-6780はSELFDESTRUCT命令の挙動を変更します。この提案では、SELFDESTRUCTは同じトランザクション内で作成されたコントラクトの場合にのみアカウントを削除し、ETHを送金します。それ以外の場合はコントラクト自体は削除されず、ETHの送金のみ行われます。これは将来のVerkleツリーへの移行に備え、EVMの実装を簡素化し、状態変化の複雑さを減らすことを目的としており、同時にSELFDESTRUCTの一般的なユースケースは維持されます。
EIP-7516
EIP-7516は新しいEVM命令BLOBBASEFEEを導入し、現在のブロックにおけるblobの基本料金を返します。これはEIP-3198のBASEFEE命令と類似していますが、EIP-4844で定義されたblob用のガス価格を取得する点が異なります。この機能により、Rollupコントラクトがblob使用量のコストを信頼なく計算したり、blobガスの先物取引を実装してコストを平準化したりすることが可能になります。
公式が提示するセキュリティ上の考慮事項
EIP-1153
スマートコントラクト開発者は、一時的ストレージ変数のライフサイクルを理解した上で使用する必要があります。一時的ストレージはトランザクション終了時に自動クリアされるため、開発者がGas節約のためにスロットのクリアを回避しようとする可能性があります。しかし、これは同一トランザクション内の再入（リエントランシー）ロックなどの場合に、コントラクトとの後続のやり取りを妨げたり、他のバグを引き起こしたりする可能性があるため、注意が必要です。非ゼロ値は、将来の呼び出しで使用されることを明確に意図した場合にのみ保持すべきです。TSTOREおよびTLOADはSSTORE/SLOADと同様の振る舞いをするため、特にリエントランシーのリスクに関する従来のセキュリティ注意点が引き続き適用されます。
また、開発者が一時的ストレージをメモリマップの代替として使う試みを行うかもしれません。しかし、呼び出しがリターンまたはリバートした場合、一時的ストレージはメモリのように破棄されないことに注意が必要です。そのため、再入時の予期しない動作を避けるために、このようなケースではメモリの使用を優先すべきです。一時的ストレージのメモリ上でのコストは必然的に高くなるため、こうした使用法はすでに抑制されています。キーで並べ替えられたエントリリストでメモリマップの大部分の用途は代替可能であり、実際のプロダクション環境ではメモリ内マップの必要性はほとんどありません（著者が知る限り、既知のユースケースは存在しません）。
EIP-4844
本EIPにより、各ビーコンブロックの帯域幅要件が最大で約0.75MB増加します。これは現在のブロックの理論的最大サイズ（30M Gas / calldata 1バイトあたり16 Gas = 1.875M バイト）より40%大きいですが、最悪ケースでの帯域幅の大幅な増加にはなりません。マージ後、ブロック時間は静的であるため、大きなブロックの伝播に必要な時間が保証されています。
calldataのコストを下げる代替案と比べ、本EIPの継続的な負荷ははるかに低く抑えられます。なぜなら、Blobは実行負荷と同じ期間保存する必要がないためです。これにより、Blobの保持期間を最低限に抑える戦略の実装が可能になります。具体的な値としてはMIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS（約18日）が選ばれており、提案されている（まだ実装されていない）1年間の実行ペイロード履歴ローテーションと比較すると、はるかに短い遅延となっています。
EIP-5656
クライアントは、C言語のstd lib memmove関数のように中間バッファを使用しない実装に注意する必要があります。これは潜在的なDoS（サービス拒否）攻撃のベクトルとなる可能性があるためです。多くの言語の組み込み関数／標準ライブラリ関数は、ここでの性能特性に関して適切に設計されています。
その他、DoSおよびメモリ枯渇攻撃に対する分析は、メモリ操作に関連する他のオペコードと同様です。なぜなら、メモリ拡張は同じ価格設定ルールに従っているためです。
EIP-6780
以下のアプリケーションはSELFDESTRUCTの変更により破壊され、そのような使い方はもはや安全ではありません：
CREATE2を使って同じアドレスにコントラクトを再デプロイし、アップグレードを実現する手法。この機能は今後サポートされません。代わりにERC-2535または他のタイプのプロキシコントラクトを使用すべきです。
コントラクトが、自身が作成されたトランザクション外でSELFDESTRUCTを行い、ETHを燃やすことで動作する依存関係を持つ場合、その仕組みは成立しなくなります。
スマートコントラクト関連のリスク
EIP-1153
TLOADおよびTSTORE命令の使用を想定した2つのシナリオ：
-
呼び出されたコントラクトがこの命令を使用する場合
-
呼び出しを行ったコントラクトがこの命令を使用する場合
リスク1：
従来のSSTOREおよびSLOADと比較して、新しく追加された一時的ストレージは主にデータの保存期間を変えます。tstoreで保存されたデータはtloadで読み取ることができますが、トランザクション終了時に解放され、sstoreのように永久的に記録されません。開発者はこの命令の特性を正しく理解し、誤った使用によるデータ損失を防ぐ必要があります。また、tstoreのデータはプライベート変数であり、コントラクト自身からのみアクセス可能です。外部から使用するには、引数経由での渡しか、public storage変数への一時保存が必要です。
リスク2：
別の潜在的リスクとして、スマートコントラクト開発者が一時的ストレージ変数のライフサイクルを不適切に管理した場合、データが不適切なタイミングで消去されたり、逆に不要に保持されたりする可能性があります。トランザクション内の後続の呼び出しで一時的ストレージのデータを使用することを期待しているが、ライフサイクル管理が不十分であれば、異なる呼び出し間でデータが誤って共有または喪失し、論理エラーやセキュリティ脆弱性を引き起こす可能性があります。トークンプロジェクトにおけるbalanceやallowanceのデータが正しく保存されない場合、コントラクトの論理エラーにつながり、資産損失を招く可能性があります。また、ownerアドレスの設定にこの命令を使用した場合、特権アドレスが正しく記録されず、コントラクトの重要パラメータの変更権を失うリスクがあります。
例えば、暗号資産取引所の取引価格を一時的に記録するコントラクトを想定します。このコントラクトは各取引終了時に価格を更新し、ユーザーが短期間で最新価格を照会できるようにします。しかし、一時的ストレージがトランザクション終了時に自動クリアされる特性を考慮していない設計の場合、ある取引終了後から次の取引開始までの間にユーザーが誤ったまたは古くなった価格を受け取る可能性があります。これはユーザーの誤った意思決定を招くだけでなく、悪意ある攻撃者に悪用され、プラットフォームの信頼性やユーザーの資産安全に影響を与える恐れがあります。
EIP-6780
本提案はSELFDESTRUCT命令の挙動を変更し、コントラクトを破棄せずETHのみを送金します。ただし、同一トランザクション内で作成されたコントラクトについては従来通り破棄されます。このEIPの影響は比較的大きいと言えます。
CREATE2を使って同じアドレスに再デプロイすることでコントラクトをアップグレードする手法は、今後サポートされません。代わりにERC-2535または他のタイプのプロキシコントラクトを使用すべきです。（これはオンチェーンコントラクトでCREATE2を用いてアップグレード可能なコントラクトを実装している場合の安全性に影響を与える可能性があります）
スマートコントラクト内のSELFDESTRUCT命令は、コントラクト自体を破棄し、残高を指定アドレスに送金します。しかし、この仕様変更後は、そのコントラクトが同一トランザクション内で作成された場合にのみ破棄されます。そうでなければ、ETHの送金のみが行われ、コントラクトは残ります（例えば、自己破壊かつ受益者が自己である場合、何の変化も生じません）。これはSELFDESTRUCTに依存するすべてのコントラクトに影響を与えます。
1inchのCHI TokenのようなGas Tokenの仕組み：特定のオフセット位置で常にCREATE2またはSELFDESTRUCTを実行することでGasを節約します。このアップデート後、そのオフセットのコントラクトが正しく自壊していない場合、その後のCREATE2によるデプロイは失敗します。
本提案の実施は直接的なコントラクト攻撃を可能にするわけではありませんが、既存のSELFDESTRUCTに依存するコントラクトの正常なロジックを損なう可能性があり、予期しない動作を引き起こします（資金移動のみに依存するコントラクトは影響を受けませんが、後続処理でコントラクトの削除を必須としているものは影響を受けます）。これによりコントラクトの機能停止や資金損失などの被害が生じる可能性があります（例：CREATE2で同じアドレスに新規コントラクトをデプロイし、旧コントラクトを自壊してアップグレードするパターンが、今後は成功しなくなります）。長期的には、ある操作コードの機能を変更することは、中央集権化の問題を引き起こす可能性もあります。
例えば、以下のようなVaultコントラクトの更新を想定します：
-
CREATE2で一時的コントラクトを作成し、Vaultの資金を一時保管
-
Vaultコントラクトを自壊し、資金を一時コントラクトへ送金（資金は移動するがコントラクトは削除されない）
-
元のアドレスにCREATE2で新しいVaultコントラクトをデプロイ（失敗：元のVaultコントラクトが削除されていないため）
-
一時コントラクトを自壊して資金をVaultに戻す（資金損失：Vaultコントラクトが作成されていない）
参考資料
カンクンアップグレードはイーサリアムの競争力をさらに強化します。しかし、コアとなるスマートコントラクト層への変更はリスクを伴い、既存のDAppの安全な動作に影響を与える可能性があります。スマートコントラクト開発においては、これらの変更およびそれが引き起こす可能性のあるリスクについて十分に注意を払う必要があります。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@salus_sec
