*Forward the Original Title: カンクンのアップグレード前、プロジェクト開発者必見のいくつかのセキュリティチェック
要約:カンクンアップグレードが近づいており、EIP提案の変更が6つ含まれています。主にEIP-1153、EIP-4788、EIP-4844、EIP-5656、EIP-6780、およびEIP-7516が含まれています。EIP-4844は、イーサリアムのスケーラビリティを向上し、取引コストを削減し、レイヤー2ソリューションの取引を高速化することに焦点を当てています。このアップグレードは、イーサリアムのテストネットでテストされ、3月13日に本番ネットでのアクティベーションが予定されています。Salusは、アップグレード前に開発者がチェックすべき重要なセキュリティに関する考慮事項をまとめました。
EIP-1153は、一時的なストレージオプコードを導入し、ストレージと同様に状態を操作しますが、一時的なストレージは各トランザクション後に破棄されます。つまり、一時的なストレージはストレージから値をデシリアライズせず、ストレージに値をシリアライズせず、ディスクアクセスを避けることでコストを削減します。2つの新しいオプコード、TLOADとTSTORE(「T」は「一時的な」を表します)の導入により、スマートコントラクトは一時的なストレージにアクセスできます。この提案は、イーサリアムでのトランザクション実行中に複数のネストされた実行フレーム間の通信に対する専用かつ効率的なソリューションを提供することを目的としています。
EIP-4788は、ビーコンチェーンブロックのハッシュツリールートをEVMに公開し、これらのルートをスマートコントラクト内でアクセス可能にすることを目的としています。これにより、信頼なしでコンセンサスレイヤーステートにアクセスできるようになり、ステーキングプール、再ステーキング構造、スマートコントラクトブリッジ、MEV緩和などのさまざまなユースケースをサポートします。この提案は、これらのルートをスマートコントラクトに格納し、循環バッファを使用してストレージ消費を制限し、各実行ブロックがこの情報を表すのに定数のスペースのみを必要とすることでこれを実現しています。
EIP-4844は、「Shard Blob Transactions」と呼ばれる新しいトランザクションフォーマットを導入し、イーサリアムのデータ可用性をシンプルかつ後方互換性のある方法で拡張することを目的としています。この提案は、「blob-carrying transactions」を導入することで、EVMからアクセスできない大量のデータを含み、そのコミットメントからアクセスできるようにすることで目標を達成しています。このフォーマットは、将来のフルシャーディングで使用されるフォーマットと完全に互換性があり、ロールアップのスケーラビリティに一時的ですが重要な救済を提供します。
EIP-5656は、メモリ領域の効率的なコピーのための新しいEVM命令、MCOPYを導入しています。この提案は、MCOPY命令を使用してメモリコピー操作のオーバーヘッドを削減することを目的としています。MCOPYは、ソースと宛先アドレスの重複を可能にし、後方互換性を考慮して設計されており、データ構造の構築、効率的なアクセス、メモリオブジェクトのコピーなど、さまざまなシナリオで実行効率を向上させることを目指しています。
EIP-6780は、SELFDESTRUCTオペコードの機能を変更します。この提案では、SELFDESTRUCTはアカウントのみを削除し、契約の作成と同じトランザクションで全てのイーサを転送します。さらに、SELFDESTRUCTを実行する際、契約は削除されず、全てのイーサが指定されたターゲットに転送されます。この変更は、将来のVerkleツリーの使用を容易にし、EVMの実装を簡素化し、状態変更の複雑さを減らすと同時に、SELFDESTRUCTの一般的なユースケースを保持します。
EIP-7516は、現在のブロックの実行におけるブロブの基本料金値を返すための新しいEVM命令、BLOBBASEFEEを導入しています。この命令は、EIP-3198で導入されたBASEFEEオプコードに類似しており、違いは、EIP-4844に従って定義されたブロブ基本料金を返す点です。この機能により、契約はブロブデータのガス価格をプログラムで考慮し、ロールアップ契約は信頼なしにブロブデータの使用コストを計算したり、ブロブデータのコストをスムーズにするためのブロブガス先物を実装したりすることができます。
スマートコントラクト開発者は、一時的なストレージ変数のライフサイクルを理解してから使用する必要があります。一時的なストレージはトランザクションの終了時に自動的にクリアされるため、スマートコントラクト開発者はガスを節約するためにスロットのクリアを回避しようとするかもしれません。ただし、これにより同じトランザクション内での契約とのさらなる相互作用(例:再入ロックの場合)が阻害されたり、他のエラーが発生する可能性があります。したがって、スマートコントラクト開発者は慎重であり、一時的なストレージスロットが同じトランザクション内での将来の呼び出しのために予約されている場合にのみ、ゼロ以外の値を保持すべきです。それ以外の場合、これらのオペコードの動作はSLOADおよびSSTOREと同一であり、再入リスクに特に注意が必要です。
スマートコントラクト開発者は、メモリマッピングの代替として一時的なストレージを使用しようとすることがあります。呼び出しが戻るかリバートされたときにメモリのように一時的なストレージが破棄されないことを認識する必要があり、同一トランザクション内で再入する際の予期しない動作を避けるためにこのようなケースではメモリを優先すべきです。一時的なストレージの高コストは、この使用パターンを既に desu するはずです。メモリ内のマッピングのほとんどの使用ケースは、キーによるエントリのソートされたリストを介してより良く実装でき、スマートコントラクトで一時的なストレージがほとんど必要ない場合がほとんどです(つまり、本番環境での既知の使用ケースはありません)。
このEIPは、ビーコンブロックごとの帯域幅要件を最大で約0.75 MB増やします。 これは、本日のブロックの理論上の最大サイズ(30M Gas / calldataバイトあたり16 Gas = 1.875Mバイト)の40%増加ですので、最悪の場合でも帯域幅が大幅に増加するわけではありません。 ブロックのマージ後、ブロック時間は予測不可能なポアソン分布ではなく静的であり、大規模なブロックの伝播の確実な時間枠を提供します。
限られたコールデータでも、このEIPの持続的な負荷は、実行負荷と同じ期間だけBlobストレージを保持する必要がないため、コールデータのコストを削減できる代替ソリューションよりも大幅に低いです。これにより、これらのBlobを少なくとも一定期間保持する必要がある戦略を実装することが可能になります。選択された具体的な値は、約18日であるMIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTSエポックです。これは、提案された(しかしまだ実装されていない)有効なペイロード履歴の実行の1年間のローテーション時間よりもはるかに短いです。
クライアントは、実装が中間バッファを使用しないように注意する必要があります(たとえば、中間バッファを使用しないC標準ライブラリmemmove関数)。これは、サービス拒否(DoS)ベクトルになり得るためです。バイトの移動に使用されるほとんどの言語組込み関数/標準ライブラリ関数は、ここで正しいパフォーマンス特性を持っています。
また、サービス拒否(DoS)およびメモリ枯渇攻撃の解析は、メモリ拡張が同じ価格設定規則に従うため、他のメモリタッチングオペコードと同じです。
SELFDESTRUCTの以下のアプリケーションは壊れ、この方法で使用しているアプリケーションはもはや安全ではありません:
CREATE2が使用されている場所は、契約を同じ場所に再展開して契約をアップグレード可能にするためです。この機能はもはやサポートされておらず、ERC-2535または他の種類のプロキシ契約に置き換える必要があります。
もし契約がSELFDESTRUCT経由でetherを契約に焼却することに依存している場合、その契約は同じトランザクション内で作成されません。
opcodes TLOADおよびTSTOREを使用する2つのシナリオを考慮してください。
リスク1:
従来のSSTOREやSLOADと比較すると、一時的なストレージの導入は主にデータの保存期間を変更します。TSTOREによって保存されたデータはTLOADを通じて読み取られ、取引の実行後に解放されます。SSTOREのように契約に永続的に記録されるのではなく、取引の実行後に解放されます。これらのオペコードの特性を正しく理解して使用しないと、契約にデータが正しく書き込まれないことがあり、それによって損失が発生する可能性があります。さらに、TSTOREによって保存されたデータはプライベートであり、契約自体しかアクセスできません。このデータに外部からアクセスする必要がある場合は、パラメータを介して渡すか、一時的に公開ストレージ変数に保存する必要があります。
リスク2:
もう1つの潜在的なリスクは、スマートコントラクト開発者が一時的なストレージ変数のライフサイクルを適切に管理しない場合、データが不適切なタイミングで消去されたり、正しく保持されなかったりする可能性があることです。契約がトランザクションの後続呼び出しで一時的なストレージに格納されたデータを使用することを期待しているが、このデータのライフサイクルを適切に管理できない場合、異なる呼び出し間でデータが誤って共有されたり失われたりする可能性があり、論理エラーやセキュリティの脆弱性を引き起こす可能性があります。トークンプロジェクトの残高や許可データなどのデータを正しく格納しないことは、契約の論理エラーを引き起こし、損失をもたらす可能性があります。同様に、これらのオペコードを使用してオーナーアドレスを設定することで、特権のあるアドレスが正しく記録されない場合、契約の重要なパラメータの変更が失われる可能性があります。
仮想通貨取引プラットフォーム上で取引価格を一時記録するために一時ストレージを使用するスマートコントラクトを考えてみましょう。契約は取引後に価格を更新し、ユーザーが短期間で最新の価格を照会できるようにします。ただし、契約設計が取引終了時の一時ストレージの自動クリアリングを考慮していない場合、1つの取引の終了と次の取引の開始の間にユーザーが間違ったまたは古い価格を受け取る可能性があります。これは、ユーザーが誤った情報に基づいて意思決定を行うだけでなく、悪用されてプラットフォームの評判やユーザー資産のセキュリティに影響を与える可能性があります。
この提案は、以前のselfdestructオペコードの動作を変更し、契約が燃やされるのではなくトークンの転送のみが発生し、selfdestruct契約と同じトランザクションで作成された契約のみが燃やされます。このEIPの影響は比較的重要です。
同じアドレスで契約を再展開するためにcreate2を使用して契約をアップグレードすることはもはやサポートされていません。この機能はERC-2535やその他のタイプのプロキシ契約で置き換える必要があります。(これはセキュリティに影響する可能性がありますオンチェーン契約create2)を使用したアップグレード可能なコントラクトの実装。
スマートコントラクトのSELFDESTRUCT操作は、コントラクトを焼却し、コントラクトの残高を指定されたターゲットアドレスに送信することを可能にします。この場合、コントラクトはSELFDESTRUCTを使用してEtherを焼却し、焼却されたEtherをコントラクトに送信します。ただし、このコントラクトは他のコントラクトと同じトランザクション内でのみ作成される必要があります(このコントラクトによって作成されたコントラクトや同じトランザクション内の他のコントラクト)。そうでない場合、Etherは焼却されずに転送されるだけです(たとえば、受益者が自己破壊コントラクトであるselfdestructの場合、何も変化しません)。これはすべてに影響します契約引き出しやその他の操作に依存するselfdestruct機能
1inch CHIトークンと同様のGasトークンは、常にオフセットを維持し、このオフセットでCREATE2またはSELFDESTRUCTを常に展開するように機能します。この更新後、現在のオフセットにあるコントラクトが正しくセルフディストラクトされていない場合、その後のCREATE2は契約を正常に展開することができません。
この提案の実装は契約を直接攻撃することはできませんが、selfdestruct操作に依存する既存の契約の通常のロジックを損ないます(資金の移転にのみselfdestructに依存する契約には影響を与えませんが、後続の操作が必要な契約に対してselfdestruct契約を削除する必要がある契約には影響を与えます)。契約が予期せず動作し、契約のストライキ、資金の損失などにつながる可能性があります(たとえば、元のアドレスで新しい契約を展開するためにcreate2を使用して元の契約をアップグレードのためにself-destructした契約は、もはや正常に展開されません)。長い目で見ると、オペコードの機能を変更することは中央集権化の問題を引き起こすかもしれません。
例えば、更新用の既存のボールト契約があります。
Cancunのアップグレードは、Ethereumの競争上の優位性をさらに高めます。ただし、このアップグレードでのコアスマートコントラクトレイヤーの変更により、既存のDAppsの安全な運用に影響を与えるリスクがもたらされます。スマートコントラクトの開発中には、これらの変更およびそれらがもたらす潜在的なリスクを注意深く監視する必要があります。リスクチェックや監査サポートのためにSalusに連絡するか、変更内容を理解するためのさらなる読替を行うことができます。
Share
*Forward the Original Title: カンクンのアップグレード前、プロジェクト開発者必見のいくつかのセキュリティチェック
要約:カンクンアップグレードが近づいており、EIP提案の変更が6つ含まれています。主にEIP-1153、EIP-4788、EIP-4844、EIP-5656、EIP-6780、およびEIP-7516が含まれています。EIP-4844は、イーサリアムのスケーラビリティを向上し、取引コストを削減し、レイヤー2ソリューションの取引を高速化することに焦点を当てています。このアップグレードは、イーサリアムのテストネットでテストされ、3月13日に本番ネットでのアクティベーションが予定されています。Salusは、アップグレード前に開発者がチェックすべき重要なセキュリティに関する考慮事項をまとめました。
EIP-1153は、一時的なストレージオプコードを導入し、ストレージと同様に状態を操作しますが、一時的なストレージは各トランザクション後に破棄されます。つまり、一時的なストレージはストレージから値をデシリアライズせず、ストレージに値をシリアライズせず、ディスクアクセスを避けることでコストを削減します。2つの新しいオプコード、TLOADとTSTORE(「T」は「一時的な」を表します)の導入により、スマートコントラクトは一時的なストレージにアクセスできます。この提案は、イーサリアムでのトランザクション実行中に複数のネストされた実行フレーム間の通信に対する専用かつ効率的なソリューションを提供することを目的としています。
EIP-4788は、ビーコンチェーンブロックのハッシュツリールートをEVMに公開し、これらのルートをスマートコントラクト内でアクセス可能にすることを目的としています。これにより、信頼なしでコンセンサスレイヤーステートにアクセスできるようになり、ステーキングプール、再ステーキング構造、スマートコントラクトブリッジ、MEV緩和などのさまざまなユースケースをサポートします。この提案は、これらのルートをスマートコントラクトに格納し、循環バッファを使用してストレージ消費を制限し、各実行ブロックがこの情報を表すのに定数のスペースのみを必要とすることでこれを実現しています。
EIP-4844は、「Shard Blob Transactions」と呼ばれる新しいトランザクションフォーマットを導入し、イーサリアムのデータ可用性をシンプルかつ後方互換性のある方法で拡張することを目的としています。この提案は、「blob-carrying transactions」を導入することで、EVMからアクセスできない大量のデータを含み、そのコミットメントからアクセスできるようにすることで目標を達成しています。このフォーマットは、将来のフルシャーディングで使用されるフォーマットと完全に互換性があり、ロールアップのスケーラビリティに一時的ですが重要な救済を提供します。
EIP-5656は、メモリ領域の効率的なコピーのための新しいEVM命令、MCOPYを導入しています。この提案は、MCOPY命令を使用してメモリコピー操作のオーバーヘッドを削減することを目的としています。MCOPYは、ソースと宛先アドレスの重複を可能にし、後方互換性を考慮して設計されており、データ構造の構築、効率的なアクセス、メモリオブジェクトのコピーなど、さまざまなシナリオで実行効率を向上させることを目指しています。
EIP-6780は、SELFDESTRUCTオペコードの機能を変更します。この提案では、SELFDESTRUCTはアカウントのみを削除し、契約の作成と同じトランザクションで全てのイーサを転送します。さらに、SELFDESTRUCTを実行する際、契約は削除されず、全てのイーサが指定されたターゲットに転送されます。この変更は、将来のVerkleツリーの使用を容易にし、EVMの実装を簡素化し、状態変更の複雑さを減らすと同時に、SELFDESTRUCTの一般的なユースケースを保持します。
EIP-7516は、現在のブロックの実行におけるブロブの基本料金値を返すための新しいEVM命令、BLOBBASEFEEを導入しています。この命令は、EIP-3198で導入されたBASEFEEオプコードに類似しており、違いは、EIP-4844に従って定義されたブロブ基本料金を返す点です。この機能により、契約はブロブデータのガス価格をプログラムで考慮し、ロールアップ契約は信頼なしにブロブデータの使用コストを計算したり、ブロブデータのコストをスムーズにするためのブロブガス先物を実装したりすることができます。
スマートコントラクト開発者は、一時的なストレージ変数のライフサイクルを理解してから使用する必要があります。一時的なストレージはトランザクションの終了時に自動的にクリアされるため、スマートコントラクト開発者はガスを節約するためにスロットのクリアを回避しようとするかもしれません。ただし、これにより同じトランザクション内での契約とのさらなる相互作用(例:再入ロックの場合)が阻害されたり、他のエラーが発生する可能性があります。したがって、スマートコントラクト開発者は慎重であり、一時的なストレージスロットが同じトランザクション内での将来の呼び出しのために予約されている場合にのみ、ゼロ以外の値を保持すべきです。それ以外の場合、これらのオペコードの動作はSLOADおよびSSTOREと同一であり、再入リスクに特に注意が必要です。
スマートコントラクト開発者は、メモリマッピングの代替として一時的なストレージを使用しようとすることがあります。呼び出しが戻るかリバートされたときにメモリのように一時的なストレージが破棄されないことを認識する必要があり、同一トランザクション内で再入する際の予期しない動作を避けるためにこのようなケースではメモリを優先すべきです。一時的なストレージの高コストは、この使用パターンを既に desu するはずです。メモリ内のマッピングのほとんどの使用ケースは、キーによるエントリのソートされたリストを介してより良く実装でき、スマートコントラクトで一時的なストレージがほとんど必要ない場合がほとんどです(つまり、本番環境での既知の使用ケースはありません)。
このEIPは、ビーコンブロックごとの帯域幅要件を最大で約0.75 MB増やします。 これは、本日のブロックの理論上の最大サイズ(30M Gas / calldataバイトあたり16 Gas = 1.875Mバイト)の40%増加ですので、最悪の場合でも帯域幅が大幅に増加するわけではありません。 ブロックのマージ後、ブロック時間は予測不可能なポアソン分布ではなく静的であり、大規模なブロックの伝播の確実な時間枠を提供します。
限られたコールデータでも、このEIPの持続的な負荷は、実行負荷と同じ期間だけBlobストレージを保持する必要がないため、コールデータのコストを削減できる代替ソリューションよりも大幅に低いです。これにより、これらのBlobを少なくとも一定期間保持する必要がある戦略を実装することが可能になります。選択された具体的な値は、約18日であるMIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTSエポックです。これは、提案された(しかしまだ実装されていない)有効なペイロード履歴の実行の1年間のローテーション時間よりもはるかに短いです。
クライアントは、実装が中間バッファを使用しないように注意する必要があります(たとえば、中間バッファを使用しないC標準ライブラリmemmove関数)。これは、サービス拒否(DoS)ベクトルになり得るためです。バイトの移動に使用されるほとんどの言語組込み関数/標準ライブラリ関数は、ここで正しいパフォーマンス特性を持っています。
また、サービス拒否(DoS)およびメモリ枯渇攻撃の解析は、メモリ拡張が同じ価格設定規則に従うため、他のメモリタッチングオペコードと同じです。
SELFDESTRUCTの以下のアプリケーションは壊れ、この方法で使用しているアプリケーションはもはや安全ではありません:
CREATE2が使用されている場所は、契約を同じ場所に再展開して契約をアップグレード可能にするためです。この機能はもはやサポートされておらず、ERC-2535または他の種類のプロキシ契約に置き換える必要があります。
もし契約がSELFDESTRUCT経由でetherを契約に焼却することに依存している場合、その契約は同じトランザクション内で作成されません。
opcodes TLOADおよびTSTOREを使用する2つのシナリオを考慮してください。
リスク1:
従来のSSTOREやSLOADと比較すると、一時的なストレージの導入は主にデータの保存期間を変更します。TSTOREによって保存されたデータはTLOADを通じて読み取られ、取引の実行後に解放されます。SSTOREのように契約に永続的に記録されるのではなく、取引の実行後に解放されます。これらのオペコードの特性を正しく理解して使用しないと、契約にデータが正しく書き込まれないことがあり、それによって損失が発生する可能性があります。さらに、TSTOREによって保存されたデータはプライベートであり、契約自体しかアクセスできません。このデータに外部からアクセスする必要がある場合は、パラメータを介して渡すか、一時的に公開ストレージ変数に保存する必要があります。
リスク2:
もう1つの潜在的なリスクは、スマートコントラクト開発者が一時的なストレージ変数のライフサイクルを適切に管理しない場合、データが不適切なタイミングで消去されたり、正しく保持されなかったりする可能性があることです。契約がトランザクションの後続呼び出しで一時的なストレージに格納されたデータを使用することを期待しているが、このデータのライフサイクルを適切に管理できない場合、異なる呼び出し間でデータが誤って共有されたり失われたりする可能性があり、論理エラーやセキュリティの脆弱性を引き起こす可能性があります。トークンプロジェクトの残高や許可データなどのデータを正しく格納しないことは、契約の論理エラーを引き起こし、損失をもたらす可能性があります。同様に、これらのオペコードを使用してオーナーアドレスを設定することで、特権のあるアドレスが正しく記録されない場合、契約の重要なパラメータの変更が失われる可能性があります。
仮想通貨取引プラットフォーム上で取引価格を一時記録するために一時ストレージを使用するスマートコントラクトを考えてみましょう。契約は取引後に価格を更新し、ユーザーが短期間で最新の価格を照会できるようにします。ただし、契約設計が取引終了時の一時ストレージの自動クリアリングを考慮していない場合、1つの取引の終了と次の取引の開始の間にユーザーが間違ったまたは古い価格を受け取る可能性があります。これは、ユーザーが誤った情報に基づいて意思決定を行うだけでなく、悪用されてプラットフォームの評判やユーザー資産のセキュリティに影響を与える可能性があります。
この提案は、以前のselfdestructオペコードの動作を変更し、契約が燃やされるのではなくトークンの転送のみが発生し、selfdestruct契約と同じトランザクションで作成された契約のみが燃やされます。このEIPの影響は比較的重要です。
同じアドレスで契約を再展開するためにcreate2を使用して契約をアップグレードすることはもはやサポートされていません。この機能はERC-2535やその他のタイプのプロキシ契約で置き換える必要があります。(これはセキュリティに影響する可能性がありますオンチェーン契約create2)を使用したアップグレード可能なコントラクトの実装。
スマートコントラクトのSELFDESTRUCT操作は、コントラクトを焼却し、コントラクトの残高を指定されたターゲットアドレスに送信することを可能にします。この場合、コントラクトはSELFDESTRUCTを使用してEtherを焼却し、焼却されたEtherをコントラクトに送信します。ただし、このコントラクトは他のコントラクトと同じトランザクション内でのみ作成される必要があります(このコントラクトによって作成されたコントラクトや同じトランザクション内の他のコントラクト)。そうでない場合、Etherは焼却されずに転送されるだけです(たとえば、受益者が自己破壊コントラクトであるselfdestructの場合、何も変化しません)。これはすべてに影響します契約引き出しやその他の操作に依存するselfdestruct機能
1inch CHIトークンと同様のGasトークンは、常にオフセットを維持し、このオフセットでCREATE2またはSELFDESTRUCTを常に展開するように機能します。この更新後、現在のオフセットにあるコントラクトが正しくセルフディストラクトされていない場合、その後のCREATE2は契約を正常に展開することができません。
この提案の実装は契約を直接攻撃することはできませんが、selfdestruct操作に依存する既存の契約の通常のロジックを損ないます(資金の移転にのみselfdestructに依存する契約には影響を与えませんが、後続の操作が必要な契約に対してselfdestruct契約を削除する必要がある契約には影響を与えます)。契約が予期せず動作し、契約のストライキ、資金の損失などにつながる可能性があります(たとえば、元のアドレスで新しい契約を展開するためにcreate2を使用して元の契約をアップグレードのためにself-destructした契約は、もはや正常に展開されません)。長い目で見ると、オペコードの機能を変更することは中央集権化の問題を引き起こすかもしれません。
例えば、更新用の既存のボールト契約があります。
Cancunのアップグレードは、Ethereumの競争上の優位性をさらに高めます。ただし、このアップグレードでのコアスマートコントラクトレイヤーの変更により、既存のDAppsの安全な運用に影響を与えるリスクがもたらされます。スマートコントラクトの開発中には、これらの変更およびそれらがもたらす潜在的なリスクを注意深く監視する必要があります。リスクチェックや監査サポートのためにSalusに連絡するか、変更内容を理解するためのさらなる読替を行うことができます。