ブロックチェーンがフォークすると、スマートコントラクトはどうなりますか？

ブロックチェーンフォークとその影響を理解する

ブロックチェーンのフォークは、多くの場合、ネットワークのプロトコルまたはコンセンサスルールの変更により、ブロックチェーンが2つの別々のチェーンに分割されたときに発生します。フォークは、開発者と鉱夫の間のネットワークの問題や意見の相違に起因する、計画されている（ソフトフォークまたはハードフォーク）または偶発的なものです。そのような分割が発生すると、フォークのポイントまでのすべてのデータは両方のチェーンで同一のままです。ただし、フォーク後に作成されたトランザクションまたはスマートコントラクトは、各チェーンで個別に処理されます。

スマート契約は、コードのラインに直接記述された条件との自己執行契約です。これらの契約は、仲介者を必要とせずに、一度展開した後に自律的に運営されます。これらの契約の実行は、基礎となるブロックチェーンの状態およびコンセンサスメカニズムに完全に依存しています。

フォーク後のスマートコントラクトがどのように機能するか

ブロックチェーンフォークの後、フォークが両方のチェーンに存在する前に存在していたスマートコントラクト。これは、契約がブロック100で展開され、フォークがブロック200で発生する場合、両方のチェーンがブロック200まで同じ履歴と同じ契約を結ぶことを意味します。ただし、フォーク後の契約との相互作用は、それらの発生チェーンにのみ影響します。

これはいくつかの重要な質問を提起します：

• 契約は両方のチェーンで同じように動作しますか？
• これは意図しない結果につながる可能性がありますか？
• 誰かがこの複製を悪用するとどうなりますか？

契約の動作は、外部のデータソース、イベント、およびトランザクションとの相互作用に大きく依存します。フォーク後の契約に新しいトランザクションが送信されない場合、両方のバージョンは同一のままです。しかし、アクティビティが一方または両方のチェーンで再開されるとすぐに、契約の状態が分岐し始めます。

フォークされたチェーンの契約実行に関連するリスク

1つの主要なリスクには、1つのチェーンで有効なトランザクションが悪意を持っている、または誤って他のチェーンで繰り返される可能性があるリプレイ攻撃が含まれます。たとえば、ユーザーがチェーンAの契約にETHを送信すると、攻撃者はチェーンBでそのトランザクションを再生し、意図しないアクションを引き起こす可能性があります。

これを軽減するために、開発者はしばしばリプレイ保護メカニズムを実装します。 1つの一般的な方法は、2つのチェーンを区別するための各トランザクションに一意の識別子を含めることです。別のアプローチには、チェーンごとに異なる署名または非セースを使用することが含まれます。

Oraclesまたは外部データフィードがスマートコントラクトと相互作用すると、別の懸念が生じます。 Oraclesは各チェーンに異なる入力を提供し、一貫性のない契約行動につながる可能性があります。開発者は、契約がフォーク後も予測不可能に異なる可能性のある鎖のデータに依存しないことを確認する必要があります。

ハードフォークとソフトフォーク：スマートコントラクトへの影響

ソフトフォークの場合、後方互換性が保持されます。古いソフトウェアを実行するノードは、新しいブロックを検証することができます。つまり、スマートコントラクトは混乱なしに機能し続けます。ソフトフォークによって導入された変更は、通常、機能を強化したり、ルールを締めたりしますが、既存の契約ロジックを変更しません。

逆に、ハードフォークは、後方互換ではない変更を導入します。古いノードは、新しいルールで生成されたブロックを検証できません。その結果、ハードフォークがオペコード、ガスコスト、または契約実行ロジックを変更すると、スマートコントラクトが予期しない動作に直面する可能性があります。

開発者は、ハードフォークの前後に契約を徹底的に監査して、壊れた変更が導入されていないことを確認する必要があります。 MythrilやSlitherなどのツールは、プロトコルのアップグレードによって導入された脆弱性の検出に役立ちます。

フォーク中の開発者向けの実用的なステップ

フォークが差し迫っている場合、開発者は次の手順を考慮する必要があります。

• モニタープロトコルの変更：EIPS（Ethereum改善提案）またはブロックチェーンプラットフォームに関連する同様のドキュメントで更新され続けます。
• 既存の契約を監査する：静的分析ツールを使用して、潜在的な脆弱性または新しいプロトコルルールとの非互換性を検出します。
• リプレイ保護を実装する：チェーン全体で取引を意図せずに複製できないことを確認してください。
• テストネットでのテスト：フォーク環境をシミュレートするために現実世界の動作を観察するテストネットに契約を展開します。
• ユーザーとのコミュニケーション：可能性のある混乱についてユーザーに通知し、安定性が確認されるまで契約とのやり取りを避けるようにアドバイスします。

フォークされた環境での紛争と紛争の処理

ブロックチェーンが分割されると、どのチェーンが「真の」バージョンを表すかについて紛争が発生する可能性があります。そのような場合、スマートコントラクトは、各チェーンで矛盾する結果を実行することになる可能性があります。たとえば、分散型交換契約は、どのチェーンのトークン残高が有効であると見なされるかによって、取引を異なる方法で処理できます。

ガバナンスモデルはここで重要な役割を果たします。堅牢なガバナンスフレームワークを備えたプロジェクトは、どのチェーンをサポートするかについて投票し、混乱を最小限に抑えることができます。さらに、マルチシグネチャウォレットまたはタイムロックはセーフティネットを提供でき、チームは決定に達するまで契約の実行を一時停止できるようにします。

ただし、明確なガバナンスが存在しない場合、紛争は恒久的な断片化につながる可能性があります。開発者は、そのようなシナリオを優雅に処理するために、緊急停止メカニズムやフォールバックロジックなどの緊急時対応計画との契約を設計する必要があります。

よくある質問

Q：ブロックチェーンフォークの後にスマートコントラクトを削除できますか？ A：いいえ、展開すると、自己破壊機能が含まれていない限り、スマートコントラクトを削除することはできません。フォークの後でも、そのような機能を介して明示的に削除されない限り、両方のチェーンは契約を保持します。

Q：分散型アプリケーション（DAPPS）は、フォークの後にスマートコントラクトを再配置する必要がありますか？ A：必ずしもそうではありません。フォークの前に展開された契約は、両方のチェーンに存在します。ただし、DAPP開発者は、各チェーンの更新されたルールまたは機能に合わせた新しいバージョンを展開することを選択できます。

Q：マルチ署名ウォレットはフォークをどのように処理しますか？ A：マルチシグウォレットは、フォーク後の両方のチェーンにも存在します。一方のチェーンで行われたトランザクションは、意図的なアクションが取られない限り、他のチェーンに影響しません。ユーザーは、偶発的なクロスチェーン操作を避けるために、キーを慎重に管理する必要があります。

Q：新しいフォークとの契約互換性を確認するためのツールはありますか？ A：はい、Openzeppelin Defender、優しく、MythXなどのプラットフォームにより、開発者は今後のフォークやアップグレードに関連する互換性とセキュリティの問題について契約を分析できます。