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