ブロックチェーンが不変である場合、スマートコントラクトはどのように更新できるのでしょうか?

不変ブロックチェーンとスマート コントラクトの更新のパラドックスを理解する

1. ブロックチェーン テクノロジーは不変性の原理に基づいて構築されています。つまり、データがブロックチェーンに書き込まれると、変更したり削除したりすることはできません。この特性により、分散システムにおける透明性、セキュリティ、信頼性が確保されます。ただし、スマート コントラクト (ブロックチェーン上で実行される自己実行プログラム) は、多くの場合、バグが発見されたり、機能の改善が必要になったりするにつれて進化することが予想されます。不変性と更新の必要性との間の矛盾により、独特の課題が生じます。

2. 開発者は、ブロックチェーンの整合性を侵害することなくスマート コントラクト ロジックをアップグレードできるようにするアーキテクチャ パターンとメカニズムを考案しました。これらのメソッドは元のコードを変更せず、コントラクトの状態とアドレスを維持しながら実行を新しい実装にリダイレクトします。

3. 一般的なアプローチの 1 つは、プロキシ パターンの使用です。プロキシ コントラクトが状態を保持し、インターフェイスとして機能しますが、実際のロジックは別のアップグレード可能な実装コントラクトに存在します。実装への参照を変更することで、開発者は効果的に機能を更新できます。

4. もう 1 つの戦略はコントラクトの移行です。この場合、スマート コントラクトの新しいバージョンが展開され、ユーザーは資産とインタラクションを更新されたコントラクトに移動するように指示またはインセンティブが与えられます。この方法では、アクティビティを新しいコントラクトに移行しながら古いコントラクトをそのままにすることで不変性を維持します。

5. イーサリアムなどの一部のブロックチェーン プラットフォームは、アップグレード可能なコントラクトを実装する安全な方法を定義する ERC-1967 などの標準をサポートしています。これらの標準は、アップグレードが透過的で検証可能であることを保証し、悪意のある変更に関連するリスクを軽減するのに役立ちます。

プロキシ パターン: アップグレード可能なコントラクトの背後にある中心的なメカニズム

1. スマート コントラクトを更新するために最も広く採用されているソリューションは、プロキシ パターンです。この設定では、プロキシ契約と実装契約という 2 つの契約が関係します。プロキシはすべての重要なデータを保存し、関数呼び出しを delegatecall 経由で実装に転送します。

2.更新が必要な場合、開発者は新しい実装コントラクトをデプロイし、新しいアドレスを参照するようにプロキシ内のポインタを更新します。これにより、同じコントラクト アドレスと保存データを維持したままロジックを変更できます。

3. プロキシ パターンには、透過プロキシ、UUPS (Universal Upgradeable Proxy Standard)、ダイヤモンド パターンなど、いくつかのバリエーションがあります。ガスコスト、制御、複雑さの点で、それぞれに異なるトレードオフがあります。

4. 透過的プロキシでは、指定された管理者アドレスが実装をアップグレードする排他的な権限を持ちますが、通常のユーザーは違いに気付かずにコントラクトを操作します。この分離により、不正なアップグレードを防ぐことができます。

5. UUPS は、アップグレード ロジックを実装自体に移動し、プロキシのサイズとコストを削減します。ただし、実装の脆弱性により攻撃者がアップグレード メカニズムをハイジャックできる可能性があるため、これには慎重な監査が必要です。

アップグレード可能なスマート コントラクトのリスクと考慮事項

1. アップグレードにより柔軟性がもたらされる一方で、集中化のリスクも生じます。単一のエンティティがアップグレード キーを制御すると、コントラクトの動作に対して大きな権限を獲得し、分散化が損なわれる可能性があります。

2.悪意のあるアップグレードは、盗難、資金の凍結、または機能の予期しない変更につながる可能性があります。セキュリティが不十分なアップグレード メカニズムが悪用され、多大な経済的損失をもたらした、注目を集める事件が発生しました。

3. 透明性は非常に重要です。ユーザーは、アップグレード中にどのような変更が加えられたかを確認できなければなりません。オープンソース コード、オンチェーンのアナウンス、コミュニティ ガバナンスは、信頼を維持するのに役立ちます。

4. 一部のプロジェクトでは、アップグレードを管理するためにマルチシグネチャ ウォレットまたは分散型自律組織 (DAO) を使用しており、変更を適用する前にコンセンサスが必要です。これにより制御が分散され、分散化の原則に沿ったものになります。

5. 安全対策にもかかわらず、アップグレード メカニズムの存在により、本質的に契約がより複雑になり、攻撃対象領域が増加します。これらのリスクを軽減するには、監査、正式な検証、および時間制限のあるアップグレードが推奨される方法です。

よくある質問

誰でもスマートコントラクトをアップグレードできますか?いいえ、アップグレード キーにアクセスできるエンティティまたはガバナンス システムを介した許可を持つエンティティのみがアップグレードを開始できます。ほとんどのシステムは、悪用を防ぐためにこの機能を制限しています。

アップグレード可能なコントラクトはブロックチェーンの不変性を破壊しますか?既存のコードは変更されません。代わりに、実行を新しいコードにリダイレクトします。元のコントラクトは変更されずにブロックチェーン上に残り、データ レベルでの不変性が維持されます。

契約のアップグレード中にユーザーの資金はどうなりますか?ユーザーの資金とデータは通常、代理契約に保存され、有効なままになります。ストレージ レイアウトに互換性がある限り、アップグレード後も資金は安全にアクセスできます。

契約のアップグレードをネイティブにサポートするブロックチェーンはありますか?はい、EOS や Tezos などの一部のプラットフォームは、アップグレード可能なスマート コントラクトのネイティブ サポートを提供しており、開発者は更新メカニズムをプロトコル層に直接構築できます。