ロングストーリー:カンクンのアップグレードが近づいており、このアップグレードには主に6つのEIP、EIP-1153、EIP-4788、EIP-4844、EIP-5656、EIP-6780、およびEIP-7516によって提案されたエグゼクティブレイヤーの変更が含まれています。 EIP-4844 は、イーサリアム、ドロップ 取引コスト L2 のスケーラビリティを向上させ、トランザクション速度を向上させることを目的としたこのアップグレードの主役です。 カンクンのアップグレードは、1月17日、1月30日、2月7日にイーサリアム Goerli、Sepolia、Holesky テストネットで完了し、イーサリアム メインネット年3月13日に稼働する予定です。 アップグレードの前に、Salusは開発者が自分で確認できるように、このアップグレードに関する重要なセキュリティ上の考慮事項をまとめました。
EIPプロポーザルレビュー
公式に開示されたセキュリティ上の考慮事項
スマートコントラクト関連リスク
続きを読む
EIP-1153 では、操作状態に使用されるオペレーションコードであり、ストレージとほぼ同じように動作するエフェメラル ストレージ オペレーションコードが導入されていますが、各トランザクションの完了後に破棄されます。 つまり、一時ストレージはストレージから値を逆シリアル化せず、値をストレージにシリアル化しないため、一時ストレージはディスク・アクセスを必要としないため、コストが低くなります。 TLOADとTSTORE(「T」は「一時」を表す)の2つの新しい操作コードにより、スマートコントラクトは一時ストレージにアクセスできます。 この提案は、イーサリアムのトランザクション実行におけるロングネストされた実行フレームワーク間の通信のための専用で効率的なソリューションを提供することを目的としています。
EIP-4788は、ビーコンチェーンブロックのハッシュツリールートをEVMに公開して、スマートコントラクト内のこれらのルートにアクセスできるようにすることを目的としています。 これにより、コンセンサスレイヤー状態へのトラストレスなアクセスが提供され、ステーキングプール、構造の再取得、スマートコントラクトブリッジ、MEV緩和などのロングユースケースがサポートされます。 この提案では、これらのルートをスマートコントラクトを介して格納し、リングバッファを使用してストレージ消費を制限し、各実行ブロックがこの情報を表すために定数ショートのみを必要とするようにします。
EIP-4844では、イーサリアムのデータ可用性をシンプルで前方互換性のある方法で拡張するように設計された「シャーディングBLOBトランザクション」と呼ばれる新しいトランザクション形式が導入されています。 この提案は、EVMの実行ではアクセスできないが、その約束にはアクセスできる大量のデータを含む「ブロブを運ぶトランザクション」を導入することでこれを実現します。 この形式は、将来フルシャーディングで使用される形式と完全に互換性があり、ローリングスケーリングに一時的ではあるが大幅な軽減を提供します。
EIP-5656 では、メモリ領域を効率的に複製するための新しい EVM 命令である MCOPY が導入されています。 この提案は、MCOPY 命令を介してメモリ間のデータ・レプリケーションを直接有効にすることで、EVM でメモリ・コピー操作を実行する際のオーバーヘッドをドロップすることを目的としています。 MCOPY は、ソースとターゲットのアドレス アドレスをオーバーラップさせ、下位互換性を念頭に置いて設計されており、データ構造の構築、メモリ内オブジェクトへの効率的なアクセス、レプリケーションなど、ロングシナリオでの実行効率を向上させるように設計されています。
EIP-6780 は、自己破壊オペレーションコードの機能を変更します。 この提案では、SELFDESTRUCTはアカウントを削除し、コントラクトが作成されたのと同じトランザクションですべてのエーテルを転送しますが、SELFDESTRUCTが実行されると、コントラクトは削除されず、すべてのエーテルが指定された宛先に転送されます。 この変更は、将来の Verkle ツリーの使用に対応することを目的としており、SELFDESTRUCT で使用される一般的なシナリオの一部を保持しながら、EVM の実装を簡素化し、状態変更の複雑さを軽減することを目的としています。
EIP-7516 では、現在のブロック実行で BLOB の基本料金値を返す新しい EVM 命令 BLOBBASEFEE が導入されています。 このディレクティブは、EIP-3198 の BASEFEE オペレーションコードと似ていますが、EIP-4844 で定義されている BLOB の基本料金を返す点が異なります。 この機能により、たとえば、ロールアップ コントラクトで BLOB データの使用コストをトラストレスに計算したり、これに基づいて BLOB ガス先物を実装して BLOB データのコストを平準化したりすることで、コントラクトで BLOB データのガス価格をプログラムで検討できます。
スマートコントラクト開発者は、一時的なストレージ変数を使用する前に、そのライフサイクルを理解する必要があります。 一時ストレージはトランザクションの終了時に自動的にクリアされるため、スマートコントラクト開発者は、ガスを節約するために呼び出し中にスロットをクリアしないようにしようとする場合があります。 ただし、これにより、同じトランザクションでのコントラクトとのさらなる相互作用が妨げられたり(再入可能ロックの場合など)、他のエラーが発生したりする可能性があるため、スマートコントラクト開発者は、一時スロットが予約されている場合にのみゼロ以外の値を保持するように注意する必要があります。 同じトランザクション内の将来の呼び出しで使用することを意図しています。 SSTORE それ以外の場合、これらの操作コードは SLOAD とまったく同じように動作するため、特に再入のリスクに関しては、すべての一般的なセキュリティ上の考慮事項が適用されます。
スマートコントラクトの開発者は、メモリマッピングの代わりに一時的なストレージを使用することもできます。 エフェメラルストレージは、呼び出しが戻ったり再開されたりするときにメモリのように破棄されないこと、およびこれらのユースケースでは、同じトランザクションでの再入時に予期しない動作を回避するためにメモリに優先順位を付ける必要があることに注意する必要があります。 メモリ上の一時的なストレージは必然的にコストがかかるため、この使用パターンは防げるはずです。 インメモリマッピングの大規模なロング使用は、キーソートされたエントリリストでより適切に実現でき、スマートコントラクトではインメモリマッピングが必要になることはめったにありません(つまり、作成者は本番環境に既知のユースケースがないことを知っています)。
この EIP により、ビーコン ブロックあたりの最大ロングで帯域幅要件が約 0.75 MB 増加します。 これは、現在の理論上の最大ブロックサイズ(コールデータバイトあたり30 Mガス/ 16ガス= 1.875 Mバイト)よりも40%大きいため、ワーストケースの帯域幅が大幅に増加することはありません。 合併後、ブロック時間は予測不可能なポアソン分布ではなく静的であり、大きなブロックの伝播の保証された期間を提供します。
呼び出しデータが限られている場合でも、この EIP の持続負荷は、実行負荷と同じ期間 BLOB を格納する必要がないため、呼び出しデータのコストをドロップできる代替手段よりもロング低くなります。 これにより、これらの BLOB を少なくとも一定期間保持する必要があるというポリシーを実装できます。 選択される特定の値は、MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS エポック (約 18 日) で、実行ペイロード履歴の推奨される 1 年間のローテーション (ただし、まだ実装されていない) と比較して、レイテンシーは ロング です。
クライアントは、サービス拒否 (DoS) ベクトルの可能性があるため、実装が中間バッファーを使用しないことに注意する必要があります (たとえば、C の stdlibmemmove 関数は中間バッファーを使用しません)。 バイトを移動するための言語の組み込み/標準ライブラリ関数のロングは、ここで正しいパフォーマンス特性を持っています。
それ以外は、サービス拒否(DoS)攻撃とメモリ枯渇攻撃の分析は、メモリ拡張が同じ価格ルールに従うため、メモリに触れるための他のオペレーションコードと同じです。
自己破壊の次のアプリケーションは危険にさらされ、この方法でそれを使用するアプリケーションは安全ではなくなります。
ここで、CREATE 2 を使用して、コントラクトを同じ場所に再展開し、コントラクトをアップグレードできるようにします。 この機能はサポートされなくなったため、代わりにERC-2535または別のタイプのプロキシコントラクトを使用する必要があります。
コントラクトが受益者として自己破壊コントラクトを取得してエーテルを燃やすことに依存している場合、コントラクトは同じトランザクションで作成されません。
オペレーションコード TLOAD と TSTORE を使用する 2 つのシナリオについて考えてみます。
リスク1:
従来のSSTOREおよびSLOADと比較して、新しい一時ストレージは主にデータの保存期間を変更し、tstoreによって保存されたデータはtloadを介して読み取られ、データはトランザクションの実行後に解放されます。 開発者は、オペレーションコードを使用する際に、コントラクトに正しく書き込めないデータの誤った使用による損失を回避するために、オペレーションコードの機能を認識する必要があります。 さらに、tstore のデータはプライベート変数であり、コントラクト自体からのみアクセスできます。 データを外部で使用する場合は、データをパラメーターとして渡すか、パブリックストレージ変数にステージングすることしかできません。
リスク2:
別の潜在的なリスクは、スマートコントラクト開発者が一時的なストレージ変数のライフサイクルを適切に管理しない場合、データがパージされたり、不適切なタイミングで誤って保持されたりする可能性があることです。 コントラクトで、トランザクションの後続の呼び出しで一時ストレージに格納されたデータを使用することが想定されているが、そのデータのライフサイクルを適切に管理できない場合、異なる呼び出し間でデータが誤って共有または失われ、論理エラーまたはセキュリティ違反が発生する可能性があります。 同様のトークンプロジェクトの残高または手当データが正しく保存されていないことを考慮すると、契約ロジックにエラーが発生し、損失が発生します。 または、所有者アドレスを設定するときにこのオペレーションコードを使用すると、特権アドレスが正しく記録されなくなり、コントラクトの重要なパラメータの変更が失われます。
一時的なストレージを使用して、暗号資産取引プラットフォームで取引価格を一時的に記録するスマートコントラクトを考えてみましょう。 コントラクトは、各トランザクションが完了すると価格を更新し、ユーザーが短期間で最新の価格を照会できるようにします。 ただし、コントラクトの設計で、一時的なストレージが取引の終了時に自動的にクリアされるという事実が考慮されていない場合、ユーザーは、ある取引の終了から次の取引の開始までの期間に誤った価格または古い価格を取得する可能性があります。 これにより、ユーザーが誤った情報に基づいて意思決定を行うだけでなく、悪意を持って悪用され、プラットフォームの評判やユーザーの資産のセキュリティに影響を与える可能性があります。
この提案は、自己破壊オペレーションコードの以前の動作を変更し、コントラクトを破棄せず、トークンを転送するだけで、自己破壊と同じトランザクションで作成されたコントラクトのみが破棄されます。 このEIPの影響は比較的大きいです。
create 2 と同じアドレスでコントラクトを再展開して、コントラクトをアップグレードします。 この機能はサポートされなくなったため、代わりにERC-2535または別のタイプのプロキシコントラクトを使用する必要があります。 (これは、スケーラブルなコントラクトを実装するためにcreate 2を使用するオンチェーンコントラクトのセキュリティに影響を与える可能性があります)
スマートコントラクトの SELFDESTRUCT 操作により、コントラクトを破棄し、コントラクト残高を指定された宛先アドレスに送信できます。 この場合、コントラクトは SELFDESTRUCT を使用してエーテルをバーンし、バーンされたエーテルをコントラクトに送信します。 ただし、契約は、同じトランザクションで登録された契約 (この契約または同じトランザクション内の別の契約によって登録された契約) のみにすることができます。 それ以外の場合、契約を破棄せずにエーテルのみが転送されます(たとえば、自己破壊し、受益者は自己破壊契約であり、何も変更されません)。 これは、引き出しやその他の操作を自己破壊に依存する契約に影響します。
1インチCHIトークンに似たガストークンが機能します:オフセットを保持し、常にそのオフセットでCREATE 2またはSELFDESTRUCTを実行します。 この更新後、現在のオフセットを持つコントラクトがまだ正しく自己破壊されていない場合、後続の CREATE 2 はコントラクトを正常にデプロイできません。
この提案の実装は、コントラクトへの直接的な攻撃にはつながりませんが、自爆操作に依存する元の展開されたコントラクトの通常のロジックを損ない(資金移動の自己破壊のみに依存するコントラクトは影響を受けず、その後の操作で自爆コントラクトの削除を必要とする場合は影響を受けます)、コントラクトが意図したとおりに機能せず、コントラクトとユーザーのみにとって、コントラクトのストライキ、資金の損失、およびその他の損害(create2の元の使用など)につながる可能性があります。 元のアドレスに新しいコントラクトを展開すると、アップグレードのために元のコントラクトを自己破棄するコントラクトは正常に展開できなくなります)。 長期的には、オペレーションコードを変更する機能は、集中化の問題につながる可能性があります。
たとえば、更新する既存のボールト契約ボルトがあるとします。
カンクンのアップグレードは、イーサリアムの競争上の優位性をさらに高めます。 ただし、このアップグレードは、コアスマートコントラクトレイヤーへの変更にリスクをもたらし、既存のDAppsの安全な運用に影響を与えます。 スマートコントラクトの開発の過程では、これらの変化と発生する可能性のあるリスクにも細心の注意を払う必要があります。 Salusに連絡してリスクチェックや監査サポートを受けるか、さらに読んで変更を理解することができます。
カンクンネットワークアップグレード仕様
EIP-1153 (英語)
EIP-4788 (英語)
EIP-4844 (英語)
EIP-5656 (英語)
EIP-6780 (英語)
EIP-7516 (英語)
Metapod コントラクト
GasToken 2 コントラクト
