ブロックチェーンでのスマートコントラクトアップグレードのオプションは何ですか？

スマート契約は、コードに直接書き込まれた契約の条件との自己実行契約です。彼らはブロックチェーンプラットフォームで実行され、展開すると不変です。ただし、バグの修正、新しい機能の追加、規制環境の変更への適応など、スマートコントラクトのアップグレードが必要になるシナリオがあります。この記事では、ブロックチェーンでのスマートコントラクトアップグレードのさまざまなオプションについて説明します。

不変のスマートコントラクト

不変のスマートコントラクトは、Ethereumのようなブロックチェーン上のほとんどのスマートコントラクトのデフォルト状態です。展開すると、これらの契約を変更することはできません。この不変性は、ブロックチェーンテクノロジーの中心的な機能であり、契約が展開されると、その論理を変更できないことを保証し、それにより高レベルのセキュリティと信頼を提供します。

ただし、この機能も制限になる可能性があります。バグが発見された場合、または新しい機能が必要な場合は、まったく新しい契約を展開する必要があります。これは面倒であり、どの契約と対話するかについてのユーザー間の混乱につながる可能性があります。これらの問題を軽減するために、いくつかのアップグレードメカニズムが開発されました。

プロキシ契約

プロキシ契約は、スマートコントラクトをアップグレードするための最も一般的な方法の1つです。このアプローチでは、コールを実装契約に転送するプロキシ契約を展開することが含まれます。プロキシ契約は不一致のままですが、実装契約は新しいバージョンに交換できます。

プロキシ契約の設定方法は次のとおりです。

• 実装契約の展開：まず、スマート契約の初期バージョンを展開します。この契約には、アプリケーションの実際のロジックが含まれます。
• プロキシ契約の展開：次に、実装契約のアドレスを指すプロキシ契約を展開します。プロキシ契約は仲介者として機能し、すべての呼び出しを実装契約に転送します。
• 実装のアップグレード：アップグレードが必要な場合は、実装契約の新しいバージョンを展開します。プロキシ契約を更新して、新しい実装のアドレスを指す。

この方法により、ユーザーがやり取りする契約アドレスを変更せずにシームレスなアップグレードを可能にし、継続性とユーザーの信頼を維持できます。

永遠のストレージパターン

永遠のストレージパターンは、スマートコントラクトのアップグレードへのもう1つのアプローチです。この方法では、データストレージを契約のロジックから分離します。ストレージ契約は変更されていませんが、ロジック契約をアップグレードできます。

永遠のストレージパターンを実装するには：

• ストレージ契約の展開：すべての状態変数を保持する契約を展開します。この契約には、値を設定および取得する機能が必要です。
• ロジック契約の展開：ストレージ契約と対話するためにデータを読み書きするロジック契約の初期バージョンを展開します。
• ロジック契約のアップグレード：アップグレードが必要な場合は、ロジック契約の新しいバージョンを展開します。新しいロジック契約は、同じストレージ契約と引き続き対話します。

このパターンにより、データはロジック契約のさまざまなバージョンにわたって無傷でアクセスしやすくなり、アップグレードがより管理しやすく、リスクが低くなります。

ダイヤモンド標準

EIP-2535としても知られるダイヤモンド標準は、スマートコントラクトのアップグレードに対する最近の洗練されたアプローチです。これにより、契約の複数のファセットを独立してアップグレードし、よりモジュール式で柔軟なスマート契約システムを可能にします。

ダイヤモンド標準を使用するには：

• ダイヤモンド契約の展開：メインエントリポイントとして機能するダイヤモンド契約を展開します。特定の機能を実装する個々の契約であるファセットのリストが含まれています。
• ファセットの展開：ファセットの初期セットを展開し、それぞれが機能全体の一部を表します。
• アップグレードファセット：アップグレードが必要な場合は、ファセットの新しいバージョンを展開します。ダイヤモンド契約を更新して、新しいファセットアドレスを指す。

この標準により、アップグレードを細かく制御できるようになり、他の人に影響を与えることなく契約の特定の部分を更新することができます。

管理者制御アップグレード

管理者制御されたアップグレードには、契約をアップグレードする権限を持つ管理者の役割と契約を展開することが含まれます。この方法は簡単ですが、管理者が契約の運用に対して大きな力を持っているため、集中化のリスクがあります。

管理者制御されたアップグレードを実装するには：

• アップグレード可能な契約の展開：契約の初期バージョンを展開して、定義された管理者の役割を展開します。
• アップグレード関数の定義：管理者が契約のロジックを更新できるようにする関数を契約に含めます。
• アップグレードの実行：アップグレードが必要な場合、管理者は新しい契約のアドレスを使用してアップグレード機能を呼び出します。

この方法は単純ですが、契約のユーザーの最大の利益のために行動するために管理者に対する信頼が必要です。

タイムロックされたアップグレード

タイムロックされたアップグレードは、アップグレードの提案とその実行の間に遅延を導入することにより、管理者制御アップグレードにセキュリティの追加レイヤーを追加します。この遅延により、ユーザーは提案された変更を確認し、アップグレードに同意しない場合に資金を撤回できます。

タイムロックされたアップグレードを実装するには：

• アップグレード可能な契約の展開：契約の初期バージョンを管理役割とタイムロックメカニズムを展開します。
• アップグレードの提案：管理者は、新しい契約のアドレスとアップグレードが実行される時間を指定することにより、アップグレードを提案します。
• レビュー期間：レビュー期間中、ユーザーは提案された変更を検査し、契約とのやり取りを続けるかどうかを決定できます。
• 実行アップグレード：指定された時間が経過した後、問題が見つからなかった場合、アップグレードは自動的に実行されます。

この方法は、ユーザーのセキュリティと信頼とアップグレードの必要性をバランスさせます。

よくある質問

Q：スマートコントラクトのアップグレードは完全に分散化できますか？

A：ダイヤモンド標準契約やプロキシ契約などの一部の方法により、アップグレードをより分散させる制御が可能になりますが、完全に分散型のアップグレードは依然として困難です。管理者またはガバナンスのメカニズムがアップグレードを提案して実行するには、管理者またはガバナンスのメカニズムが必要であるため、管理者が制御し、タイムロックされたアップグレードには、ある程度の集中化が含まれます。

Q：スマートコントラクトのアップグレードに関連するリスクは何ですか？

A：主なリスクには、新しいコードによって導入される潜在的なセキュリティの脆弱性、適切に管理されていない場合はデータを失う可能性、および管理者がアップグレードをあまりにも多くの制御を持っている場合の集中化のリスクが含まれます。適切なテスト、監査、透明なコミュニケーションは、これらのリスクを軽減するのに役立ちます。

Q：スマートコントラクトのアップグレードについて、ユーザーにどのように通知できますか？

A：ユーザーは、公式のプロジェクトの発表、ソーシャルメディアの更新、アプリケーション内の統合通知システムなど、さまざまなチャネルを通じて通知できます。アップグレード中にユーザーの信頼を維持するためには、透明性と明確なコミュニケーションが重要です。

Q：スマートコントラクトのアップグレードをサポートするツールやフレームワークはありますか？

A：はい、いくつかのツールとフレームワークがスマートコントラクトのアップグレードをサポートしています。たとえば、OpenzePpelinのアップグレード可能な契約は、プロキシベースのアップグレードを実装するための堅牢なフレームワークを提供します。さらに、トリュフやハードハットなどのツールは、アップグレードプロセスを容易にするプラグインとスクリプトを提供します。