カンクンのアップグレードがもうすぐ始まりますが、注意すべき点と潜在的なリスクは何ですか?

簡単に言うと、カンクンのアップグレードが近づいています。このアップグレードには、主に 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

EIP-1153 では、一時ストレージのオペコードが導入されています。これは状態を操作し、ストレージとほぼ同じように動作するために使用されますが、一時ストレージはトランザクションごとに破棄されます。これは、一時ストレージがストレージからの値を逆シリアル化したり、ストレージに値をシリアル化したりしないことを意味します。そのため、一時ストレージはディスク アクセスが必要ないため、コストが安くなります。スマート コントラクトは、2 つの新しいオペコード、TLOAD および TSTORE (「T」は「一時」を表します) を通じて一時ストレージにアクセスできます。この提案は、イーサリアムのトランザクション実行における複数のネストされた実行フレームワーク間の通信のための専用の効率的なソリューションを提供することを目的としています。

EIP-4788

EIP-4788 は、ビーコン チェーン ブロックのハッシュ ツリー ルートを EVM に公開し、スマート コントラクト内のこれらのルートへのアクセスを許可するように設計されています。これにより、コンセンサス レイヤー ステートへのトラストレス アクセスが提供され、ステーキング プール、再ステーキング構造、スマート コントラクト ブリッジ、MEV 緩和などの複数のユースケースがサポートされます。この提案では、スマート コントラクトを通じてこれらのルートを保存し、リング バッファーを使用してストレージ消費を制限し、各実行ブロックがこの情報を表すために必要なスペースのみが一定であることを保証します。

EIP-4844

EIP-4844 では、「シャード BLOB トランザクション」と呼ばれる新しいトランザクション形式が導入されており、データの可用性をシンプルかつ前方互換性のある方法でイーサリアムを拡張するように設計されています。この提案は、EVM の実行ではアクセスできないが、コミットメントにはアクセスできる大量のデータを含む「BLOB を運ぶトランザクション」を導入することで機能します。この形式は、将来のフル シャーディングで使用される形式と完全な互換性があり、ローリング拡張に対して一時的ではあるが大幅な軽減を提供します。

EIP-5656

EIP-5656 では、メモリ領域のコピー効率を向上させるために設計された新しい EVM 命令 MCOPY が導入されています。この提案は、EVM でのメモリ コピー操作のコストを削減し、MCOPY 命令を通じてメモリ間でデータを直接コピーすることを目的としています。 MCOPYは、下位互換性を考慮しながらソースアドレスとターゲットアドレスを重複させることができ、データ構造の構築やメモリオブジェクトの効率的なアクセスやコピーなど、さまざまなシナリオにおける実行効率の最適化を目指します。

EIP-6780

EIP-6780 SELFDESTRUCT オペコードの機能が変更されました。この提案では、SELFDESTRUCT は、コントラクト作成と同じトランザクションでアカウントの削除とすべてのイーサの転送のみを実行し、さらに SELFDESTRUCT を実行すると、コントラクトは削除されず、すべてのイーサが指定された宛先に転送されます。この変更は、Verkle ツリーの将来の使用に適応するものであり、SELFDESTRUCT のいくつかの一般的なシナリオを維持しながら、EVM の実装を簡素化し、状態変更の複雑さを軽減することを目的としています。

EIP-7516

EIP-7516 では、現在のブロック実行で BLOB 基本料金値を返す新しい EVM 命令 BLOBBASEFEE が導入されています。このコマンドは、EIP-4844 で定義されている BLOB 基本料金を返す点を除いて、EIP-3198 の BASEFEE オペコードに似ています。この機能により、コントラクトは BLOB データのガス価格をプログラムで考慮できるようになります。たとえば、ロールアップ コントラクトで BLOB データの使用コストをトラストレスに計算したり、これに基づいて BLOB ガス先物を実装して BLOB データ コストを平滑化したりできます。

正式に公開されたセキュリティに関する考慮事項

EIP-1153

スマート コントラクト開発者は、使用前に一時ストレージ変数のライフ サイクルを理解する必要があります。一時ストレージはトランザクションの終了時に自動的にクリアされるため、スマート コントラクト開発者は、ガスを節約するために呼び出し中にスロットのクリアを回避しようとする場合があります。ただし、これにより、同じトランザクション内でコントラクトとのさらなる対話が妨げられたり (再入可能ロックの場合など)、他のエラーが発生したりする可能性があるため、スマート コントラクト開発者は、非一時ストレージ スロットが予約されている場合にのみ予約するように注意する必要があります。ゼロ値。同じトランザクション内の将来の呼び出しで使用することを目的としています。それ以外の場合、これらのオペコードは SSTORE および SLOAD とまったく同じように動作するため、特に再入リスクに関して、通常のセキュリティ上の考慮事項がすべて適用されます。

スマート コントラクトの開発者は、メモリ マッピングの代わりに一時ストレージを使用しようとすることもあります。一時ストレージは呼び出しが戻ったり再開したりするときにメモリのように破棄されないことに注意する必要があり、これらの使用例では、同じトランザクション内での再入時の予期しない動作を避けるためにメモリを優先する必要があります。メモリ上の一時的なストレージ コストは必然的に高くなるため、この使用パターンは抑制されるはずです。インメモリ マッピングのほとんどの使用法は、キー順のエントリ リストを使用して実装する方が適切であり、スマート コントラクトではインメモリ マッピングが必要になることはほとんどありません (つまり、作成者は運用環境での既知の使用例を認識していません)。

EIP-4844

この EIP により、帯域幅要件がビーコン ブロックあたり最大約 0.75 MB 増加します。これは、今日のブロックの理論上の最大サイズ (呼び出しデータ バイトあたり 30M ガス / 16 ガス = 1.875M バイト) より 40% 大きいため、最悪の場合の帯域幅が大幅に増加するわけではありません。マージ後、ブロック時間は予測不可能なポアソン分布ではなく静的となり、大きなブロックの伝播に保証された期間が提供されます。

呼び出しデータが限られている場合でも、負荷が実行される限り BLOB を保存する必要がないため、この EIP の持続的な負荷は、通話データのコストを削減する代替手段よりもはるかに低くなります。これにより、これらの BLOB を少なくとも一定期間保持する必要があるポリシーを実装することが可能になります。選択される具体的な値は MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS エポックで、これは約 18 日で、ペイロード履歴を実行するために推奨される (ただしまだ実装されていない) 1 年のローテーションよりもはるかに短いレイテンシーです。

EIP-5656

クライアントは、サービス拒否 (DoS) の可能性があるため、実装で中間バッファを使用しないことに注意する必要があります (例: C stdlibmemmove 関数は中間バッファを使用しません)。 ) ベクトル。バイトを移動するための言語の組み込み/標準ライブラリ関数のほとんどは、適切なパフォーマンス特性を備えています。

それ以外の場合、メモリ拡張は同じ価格設定ルールに従うため、サービス拒否 (DoS) およびメモリ枯渇攻撃の分析は、メモリに触れる他のオペコードの分析と同じになります。

EIP-6780

次のアプリケーション SELFDESTRUCT は壊れるため、この方法でそれを使用するアプリケーションは安全ではなくなります:

コントラクトを再デプロイするために CREATE2 が使用される場所契約をアップグレードできるようにします。この機能はサポートされなくなったため、代わりに ERC-2535 または別のタイプのプロキシ コントラクトを使用する必要があります。

コントラクトが SELFDESTRUCT コントラクトを受益者として持つことにより、イーサの燃焼に依存している場合、そのコントラクトは同じトランザクションで作成されていません。

スマート コントラクトに関連するリスク

EIP1153

オペレーション コード TLOAD および TSTORE を使用する 2 つのシナリオを想像してください。

1. 呼び出されたコントラクトはこのオペレーションを使用します。コード
2. このオペコードを使用して通話コントラクトを開始します

リスク 1:

従来の SSTORE および SLOAD と比較して、新しい Transient storage は主にデータの保存期間を変更するもので、tstore に保存されたデータは tload を通じて読み取られ、sstore のようにコントラクトによって永続的に記録されるのではなく、トランザクションの実行後にデータが解放されます。開発者は、データがコントラクトに誤って書き込まれ、損失が発生する可能性のある誤った使用を避けるために、このオペコードを使用する際にその特性を認識する必要があります。さらに、tstore 内のデータはプライベート変数であり、コントラクト自体によってのみアクセスできます。データを外部で使用する場合は、パラメータの形式で渡すか、パブリック記憶域変数に一時的に保存することしかできません。

リスク 2:

もう 1 つの潜在的なリスクは、スマート コントラクト開発者が一時ストレージ変数のライフ サイクルを適切に管理しない場合、データが次のタイミングで保存される可能性があることです。時刻がクリアされたり、間違って保持されたりすることはありません。コントラクトでは、トランザクションの後続の呼び出しで一時ストレージに保存されたデータを使用することが期待されているが、このデータのライフサイクルを適切に管理できなかった場合、呼び出し間でデータが誤って共有されたり失われたりして、ロジック エラーやセキュリティの脆弱性が発生する可能性があります。トークンプロジェクトと同様の残高や手当のデータを正しく保存できないことを考慮すると、契約ロジックに誤りが生じ、損失が発生する可能性があります。または、所有者アドレスを設定するときにこのオペコードを使用すると、特権アドレスが正しく記録されず、コントラクトの重要なパラメータの変更が失われます。

一時ストレージを使用して仮想通貨取引所で取引価格を一時的に記録するスマート コントラクトを考えてみましょう。この契約では、各取引が完了すると価格が更新され、ユーザーは短期間で最新の価格を照会できるようになります。ただし、トランザクションの終了時に一時ストレージが自動的にクリアされるという機能が契約の設計で考慮されていない場合、ユーザーは、トランザクションの終了から次のトランザクションの開始までの間に、間違ったトランザクションまたは古いトランザクションを取得する可能性があります。取引の価格です。これは、ユーザーが誤った情報に基づいて意思決定を行うよう導くだけでなく、悪用されてプラットフォームの信頼性やユーザー資産のセキュリティに影響を与える可能性があります。

EIP-6780

この提案は、以前の自己破壊オペコードの動作を変更します。コントラクトは破壊されず、トークンのみが転送され、自己破壊と同じトランザクションで作成されたコントラクトのみが転送されます。破壊は破壊されます。この EIP の影響は比較的大きいです。

create2 を使用して同じアドレスにコントラクトを再デプロイし、コントラクトをアップグレードします。この機能はサポートされなくなったため、代わりに ERC-2535 または別のタイプのプロキシ コントラクトを使用する必要があります。 (これは、create2 を使用してアップグレード可能なコントラクトを実装するオンチェーン コントラクトのセキュリティに影響を与える可能性があります)

スマート コントラクトの SELFDESTRUCT 操作により、コントラクトを破棄し、コントラクト残高を指定されたターゲット アドレスに送信できます。この場合、コントラクトは SELFDESTRUCT を使用してイーサを破棄し、破棄されたイーサをコントラクトに送信します。ただし、その契約は、同じトランザクションで作成された契約（この契約または同じトランザクション内の他の契約によって作成された契約）のみにすることができます。それ以外の場合は、コントラクトを破棄せずにエーテルのみが転送されます (たとえば、コントラクトが自己破棄され、受益者が自己破棄するコントラクトである場合、これによって変更は生じません)。これは、引き出しやその他の操作で自己破壊に依存するすべての契約に影響します。

1 インチ CHI トークンと同様のガス トークンは、オフセットを維持し、常にこのオフセットで CREATE2 または SELFDESTRUCT を実行することによって機能します。この更新後、現在のオフセットにあるコントラクトが正しく自己破壊されていない場合、後続の CREATE2 はコントラクトを正常にデプロイできなくなります。

この提案の実装は、契約への直接的な攻撃にはつながりませんが、自己破壊操作に依存する最初に展開された契約 (資金移動の自己破壊のみに依存する契約) の通常のロジックに損傷を与えることになります。影響を受けません。その後の操作では、自己消滅するコントラクトを削除する必要があります。そうでない場合は影響を受けます)、コントラクトが予期せず機能する原因となります。コントラクトとユーザーに対してのみ、コントラクトがストライキされる可能性があります。資金の損失やその他の危険 (たとえば、最初は create2 を使用して元のアドレスに新しいコントラクトをデプロイしていましたが、アップグレードのために元のコントラクトを自己破棄するコントラクトは正常にデプロイできなくなりました)。長期的には、オペコードの機能を変更すると、集中化の問題が発生する可能性があります。

たとえば、更新する既存のボールト契約ボールトがある場合:

• create2 一時ストレージ契約は、ボールトの資金を一時的に予約するために使用されます。ボールト コントラクトを自己破棄し、資金を一時コントラクトに転送します (契約は破棄せずに資金のみが転送されました)
• 元のアドレスに新しいボールト コントラクトを 2 つ作成します (元のボールト コントラクトが破棄されなかったため失敗しました)
• 資金を保管庫に返すための一時契約を自己破棄します (資金の損失、保管庫契約は作成されませんでした)

以上がカンクンのアップグレードがもうすぐ始まりますが、注意すべき点と潜在的なリスクは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。