スマートコントラクトは、展開後にロジックを自動的に変更できますか?

blockchainFebruary 5, 2026·#Blockchain

スマートコントラクトの変動性の包括的な分析: 最新のプロキシアーキテクチャからメタモーフィック技術、ブロックチェーンエコシステムにおける安全なガバナンス戦略まで。

不変性はブロックチェーンテクノロジーの中核的な特性および信頼の基盤であると長い間考えられており、ソースコードがネットワークに展開されると、個人や組織は確立されたルールに干渉したり変更したりすることができなくなります。しかしタンファットデジタルの調査によると、近年の分散型エコシステムの実際の運用は、絶対的な不変性が持続可能な開発に対する大きな障壁であることを示しています。パッチを適用できない重大なセキュリティ脆弱性、更新できない規制変更、および新機能の追加の必要性により、開発者コミュニティは、アドレスとデータの整合性を損なうことなくスマートコントラクトを「アップグレード」する方法を模索するようになりました。

この調査では、一般的なプロキシモデルから物議を醸すメタモルフィック技術まで、導入後のロジック変更を可能にする技術を詳細に分析し、リスクセキュリティリスクと関連するガバナンスの障壁を評価しています。

不変性のパラドックスと可変性の必要性

技術的には、スマートコントラクトのバイトコードは、イーサリアムのようなブロックチェーン上のブロックに永久に保存されると変更できません。各コントラクトアドレスは、固定されたコード部分に関連付けられます。ただし、プログラマは、状態の保存とロジックの実行を完全に分離することで、可変性をシミュレートできます。これにより、ユーザーは固定された「シェル」を操作しますが、実際の動作は可変エンティティによって駆動されるという混乱の層が作成されます。

可変性の必要性は、セキュリティの維持、製品の進化、リスク管理という 3 つの主な要素から生じます。小さなロジックエラーがすぐに解決されないと、数百万ドルの資産の損失につながる可能性があります。従来の金融システムでは、メンテナンスのためのダウンタイムは正常ですが、プロトコルが 24 時間 365 日稼働するブロックチェーンでは、ロジックのアップグレードを通じて「ホットフィックス」できる機能がプロジェクトの存続に不可欠です。

ブロックチェーンプラットフォーム間の設計理念の比較

現在人気のあるプラットフォーム間の設計思想の違い:

イーサリアム(EVM):
- デフォルト状態: 不変。
- ロジック変更メカニズム: プロキシと delegatecall を使用。
- アップグレード手法: アプリケーション層 (アプリケーションパターン)。
- 透明性: のソースコードの検証に依存する。プロキシ。
ステラ (そろばん):
- デフォルト状態: 変更可能。
- ロジック変更メカニズム: WASM バイトコードを直接変更。
- アップグレードアプローチ: プロトコルレベル。
- 透過性:コントラクトのメタデータに組み込まれています。

この違いは、新しいトレンドを示しています。イーサリアムは複雑な設計パターンを必要とするのに対し、ソロバンではコントラクトがプロトコルレベルで独自のバイトコードを変更できるため、不適切なプロキシ実装から生じるリスクを軽減できます。

参照: 悪意のあるスマートコントラクトからの保護

プロキシコントラクトインフラストラクチャとオペコード DELEGATECALL

EVM 互換ネットワーク上のほとんどのアップグレード技術は、単一のオペコード delegatecall に基づいています。契約 A (プロキシ) が契約 B (実装) に対して delegatecall を実行すると、契約 B のコードが実行されますが、実行コンテキスト (storage、balance、msg.sender) は完全に契約 A に属します。

このメカニズムにより、開発者は新しいバージョンのロジック (実装 V2) をデプロイし、V2 を指すようにプロキシのアドレス変数を更新するだけで済みます。ユーザーの観点から見ると、インタラクティブな契約アドレスは同じままで、アカウント残高や関連データは影響を受けませんが、処理ルールは変更されています。

境界の突破: 変成コントラクトおよび CREATE2

ロジックを変更するさらに極端な方法は、「メタモーフィックコントラクト」です。プロキシとは異なり、この手法では、CREATE2 オペコードを使用して、同じアドレスのバイトコードを完全に置き換えることができます。

「変換」手順には、未指定の init_code (初期化コード) の使用が含まれます。 init_code は、固定ロジックを含める代わりに、別のコントラクトを呼び出して新しい実行可能バイトコードを取得するようにプログラムできます。変更が必要な場合、開発者はコマンド SELFDESTRUCT を実行して古いコントラクトを削除し、同じ salt 値を持つ CREATE2 を使用して同じアドレスに新しいコードをデプロイします。この手法は状態 (ストレージ) を消去し、監査組織を欺くために悪用される可能性があるため、危険であると考えられています。

変数契約のセキュリティリスクマトリックス

ロジックの変更を許可すると、特定のセキュリティ脆弱性が発生します。

ストレージレイアウトの衝突: 新しいバージョンで変数の順序が変更されると発生し、誤ったデータが上書きされます。たとえば、Audius ハッキング (2022) では、新しい変数が初期化フラグを上書きしたため、プロジェクトに 600 万ドルのコストがかかりました。
初期化の脆弱性: プロキシは constructor を使用しないため、initialize() 関数が必要です。この関数を呼び出すのを忘れると、攻撃者が管理者権限を乗っ取る可能性があります。ワームホールハッキング (3 億 2,000 万ドル) は、この間違いの典型的な例です。
管理用バックドア: 一部の不正プロジェクトは、資金を集めた後に意図的にプロキシを使用して悪意のあるコードをインストールします。

人気のあるタイプのバックドア:

ミントバックドア: 管理者は無限のトークンを作成します。
ブラックリスト/凍結: ユーザーがトークンを引き出したり販売したりできないようにアカウントをロックします。
排出ロジック: 資産を攻撃者のウォレットに直接転送する引き出し機能を修正します。
プロキシリダイレクト: 実装アドレスを悪意のあるサーバーにリダイレクトします。

ガバナンス戦略と多層防御

柔軟性と安全性のバランスを取るため、Tan Phat Digital はプロジェクトに厳格なガバナンスプロセスを適用することを推奨しています。

マルチシグの使用: アップグレード権限は、個々の弱点を排除するために、2/3 または 3/5 の承認しきい値を持つマルチシグネチャウォレット (Gnosis Safe など) によって保持される必要があります。
タイムロックメカニズム: すべてのアップグレードコマンドに対して、少なくとも 24 時間、最大 7 日間のタイムロックを適用します。これにより、コミュニティはソースコードを検査したり、異常が検出された場合には資産を撤回したりすることができます。
ストレージギャップを維持する: 将来のアップグレードで競合を引き起こすことなく変数を追加できるように、ストレージにギャップを残しておきます。
継続的な監査: 各ロジックのアップグレードは新しいプロジェクトとして扱われ、独立した監査プロセスを受ける必要があります。

よくある質問 (FAQ)

1.プロキシ契約とは何ですか?なぜ重要ですか?

プロキシはデータと資産を保持する仲介契約であり、実行ロジックは別の契約内にあります。コントラクトアドレスを変更せずにロジックを更新できるため、ユーザーエクスペリエンスとプロトコルの継続性の維持に役立ちます。

2.契約を Solidity から Vyper にアップグレードすることはできますか?

はい。 Solidity と Vyper はどちらも EVM 上で実行されるバイトコードにコンパイルされるためです。新しい Vyper バージョンのストレージレイアウトが古い Solidity バージョンと完全に一致している限り、ロジックの交換は技術的に可能です。

3. Etherscan で契約がプロキシであるかどうかを確認するにはどうすればよいですか?

ユーザーは Etherscan の「プロキシ契約検証」ツールを使用できます。 EIP-1967 標準に準拠するコントラクトには、[プロキシとして読み取り] または [プロキシとして書き込み] タブがあり、バックグラウンドで実行されている実際の実装アドレスを確認できます。

4. 24 KB のソースコード制限とは何ですか? また、Diamond Standard はこれにどのように対処しますか?

EVM は、コントラクトのバイトコードサイズを最大 24 KB に制限します。 Diamond Standard (EIP-2535) では、ロジックを複数の「ファセット」(コントラクトピース) に分割できるため、1 つのアドレスでほぼ無制限の量のロジックを実行できます。

5. 「ストレージ衝突」とは正確には何ですか?

これは、プロキシコントラクトとロジックコントラクトが、2 つの異なる変数を格納するためにメモリ内の同じ場所 (スロット) を誤って使用してしまうことです。その結果、一方の変数がもう一方の変数を上書きすることになり、重大な論理エラーが発生したり、攻撃者に乗っ取られる可能性があります。

6.アップグレード時にプロジェクトにタイムロックが必要なのはなぜですか?

タイムロックにより、アップグレードが有効になるまで待機期間 (通常は 24 時間以上) が作成されます。これにより、コミュニティは反応したり、ソースコードをチェックしたり、新しいアップデートを信頼できない場合は撤退したりする時間が与えられます。

7.透過的プロキシと UUPS はどのように異なりますか?

透過的プロキシはアップグレードロジックをプロキシに置き、より多くのガスを消費しますが、管理者権限が明確に分離されているため、より安全です。 UUPS はアップグレードロジックを実装に組み込むことで、より多くのガソリンを節約できますが、アップグレードが失敗した場合、契約は二度と修復されないため、リスクが高くなります。

8. Metamorphic コントラクトは通常のプロキシとどのように異なりますか?

プロキシはそのアドレスにバイトコードを保持し、それが指す論理アドレスのみを変更します。 Metamorphic コントラクトは、サイト自体のソースコード全体を直接置き換えますが、既存のデータと残留物はすべて消去されます。

9. EIP-6780 はコントラクトのアップグレードにどのような影響を与えますか?

EIP-6780 は、SELFDESTRUCT コマンドがコントラクトを開始した同じトランザクション内でのみ動作するように制限します。これにより、新しいコードを再デプロイするために任意の時点でコントラクトを破棄することに依存していた古い「メタモーフィック」手法のほとんどが無効になります。

10. 「ストレージギャップ」は何に使用されますか?

これは、基本コントラクトに配置される空の変数の配列 (通常は uint256 __gap) です。将来アップグレードするときに、開発者が従来のコントラクトのストレージレイアウトを歪めることなく新しい変数を追加できるように、ストレージスペースを予約します。

11.契約を「アップグレード可能」から「不変」に変換できますか?

はい。開発者は最終アップグレードを実行して、アップグレード機能を削除したり、管理者 (所有者) を「ゼロ」アドレス (0x0) に移動したりできます。アップグレード機能がなくなると、ロジックは永久にロックされます。

12. 「初期化されていないプロキシ」のリスクは何ですか?

開発者が展開直後に初期化関数 (initialize) を呼び出すのを忘れた場合、誰でも初期化関数を呼び出してコントラクト所有者になることができます。ワームホールハッキングは、このエラーにより数億ドルの損失が発生しそうになった典型的な例です。

13.実際にアップグレードされるコントラクトの割合はどれくらいですか?

調査によると、イーサリアム上のコントラクトのうちアップグレード向けに設計されているのはわずか約 3% であり、そのうち展開後に実際にアップグレードされるのは約 0.34% だけです。

14.ビーコンプロキシはいつ使用されますか?

ビーコンプロキシは、何千もの同一のコントラクト (スマートウォレットなど) を展開する必要がある場合に使用されます。各コントラクトを更新するのではなく、「Beacon」で 1 つのアドレスを更新するだけで、すべてのウォレットのロジックが同時に変更されます。

15.プロキシの代わりに「コントラクト移行」を使用する必要があるのはどのような場合ですか?

ストレージスロットの競合によりプロキシが処理できないコアデータ構造を変更する必要がある場合 (ERC-20 から ERC-777 標準への変更など)。この時点で、完全に新しいコントラクトをデプロイし、新しいアドレスに資産を転送するようにユーザーに依頼する必要があります。

スマートコントラクトにおける可変性の未来

アップグレード技術の開発により、静的ブロックチェーンソースコードの固定概念が打ち破られました。不変性は究極の理想ですが、セキュリティ上の欠陥や市場の変化に対処するには、制御された可変性が不可欠です。

将来の傾向は、DAO や OpenZeppelin Upgrades Plugins などの自動テストツールの使用によるアップグレード権限の分散化に向かうでしょう。可変性は、透過的かつ適切に実装された場合、ブロックチェーンの価値を損なうことはなく、むしろ回復力があり、継続的に進化できるエコシステムを生み出します。

スマートコントラクトは、展開後にロジックを自動的に変更できますか?