ERC-777

ERC-777とは？

ERC-777は、基本的なトークンモデルに送金フック、オペレーター権限、トランザクションデータ、より安全なコントラクト受取人チェックを追加した、代替可能な暗号資産向けのEthereumトークン規格です。

ERC-20と同様に、同じトークンの各単位が互いに同じ価値と特性を持つ、交換可能な単位を表します。

公式のERC-777仕様は、代替可能なトークンとウォレットやスマートコントラクトとの連携方法の改善を目的として作成された、FinalステータスのEthereum Request for Comments規格です。

主な機能は、

関数、送信者および受取人のフック、承認済みオペレーター、組み込みのバーン関数、トークンの移動に任意で付加できるデータです。

ERC-777はERC-20との後方互換性を維持し、1つのトークンコントラクトで両方のインターフェースに対応できるよう設計されました。

しかし、コールバックの動作やERC-1820への依存により統合が複雑になり、深刻なリエントランシーリスクが生じる可能性もあることから、ERC-777の普及はERC-20に比べて限定的です。

ERC-777は現在も有効な規格ですか？

ERC-777は、公式のEthereum Improvement ProposalリポジトリでFinalステータスの規格として引き続き掲載されています。

FinalステータスはEIP標準化プロセスを完了したことを意味しますが、広範な普及、ライブラリによる継続的なサポート、あらゆる新規トークンへの適性を保証するものではありません。

主要なスマートコントラクトライブラリは、バージョン4.9でERC-777の実装を非推奨とし、バージョン5.0で削除しました。

最新のOpenZeppelin Contractsの変更履歴には、実装サポートの終了が記録されています。一方、関連する標準インターフェースは引き続き利用できます。

このライブラリの決定によってERC-777が取り消されたわけでも、Finalステータスが変更されたわけでもありません。

ただし、現在の同ライブラリのバージョンで、保守されているERC-777トークン実装を利用できるとは限らないため、開発者は注意が必要です。

既存のERC-777コントラクトはデプロイ済みのコードに従って引き続き動作しますが、新たに統合する場合は、コールバックの動作、依存関係、監査、エコシステムのサポートを慎重に評価してください。

ERC-777が作られた理由

ERC-777は、基本的なERC-20送金に関する使いやすさと安全性のいくつかの課題に対処するために作られました。

ERC-20では、コントラクトへの送金時に受取人のコントラクトがトークンを認識または処理する必要はありません。

そのため、トークンを回収または計上する関数がないコントラクトに送金すると、トークンが取り出せなくなる場合があります。

ERC-20のアプリケーションでは、ユーザーがまず使用者に承認を与え、その後、使用者が

を呼び出す2段階の手順も一般的です。

ERC-777では

が導入され、データを付加したトークンを、互換性のある受取人に同じトランザクション内で通知しながら送れるようになりました。

また、保有者に代わってトークンを移動するアカウントやコントラクトの権限モデルとして、名称付きのオペレーターが導入されました。

この規格は、代替可能なトークンの動作をネイティブETHの送金に近づけるとともに、送信者と受取人がトークンの移動をプログラムで制御できるようにすることを目指していました。

ERC-777の仕組み

ERC-777コントラクトは、トークン残高と総供給量を保存し、送金、バーン、トークン管理権限の委任に関する標準関数を提供します。

トークンを送る際、コントラクトは送信者がERC-1820を通じて送信者フックを登録しているか確認します。

送信者フックが登録されている場合、トークン残高を変更する前にそのフックを呼び出します。

次に、トークンは送信者の残高を減らし、受取人の残高を増やします。

残高の更新後、受取人が受取人フックを登録しているか確認し、必要に応じてそのフックを呼び出します。

フックは移動を受け入れたり、追加の処理を実行したり、トランザクション全体をリバートさせたりできます。

処理はアトミックであるため、必須のフックでリバートが発生すると、通常はトークンの移動と、そのトランザクションに関連するすべての状態変更が取り消されます。

ERC-777の主な関数

ERC-777インターフェースには、トークンのメタデータ、残高、グラニュラリティ、オペレーター、送金、バーンに関する関数が含まれます。

、、、関数は、ERC-20トークンでもおなじみの情報を提供します。

関数は、ミント、送金、バーンが可能な最小の分割できない数量を返します。

関数は、各保有者が権限を取り消す権利を有することを前提に、デフォルトで全保有者に対して承認されたオペレーターを返します。

関数は、あるアドレスが特定の保有者のオペレーターとして動作できるかを確認します。

関数と関数を使って、保有者はオペレーター権限を管理できます。

関数と関数はトークンを移動し、関数と関数は供給量を永久に減らします。

send関数

関数を使うと、保有者は別のアドレスへ直接トークンを送り、というbytesフィールドを付加できます。

付加データには、支払い、アプリケーションの操作、参照番号、受取側のシステムが解釈できるその他の情報を記載できます。

この関数は、ERC-777のルールに従って登録済みの送信者フックと受取人フックを呼び出します。

受取人がコントラクトの場合、ERC-1820を通じてERC-777受取人の実装を登録していなければ、ネイティブのERC-777送金はリバートされなければなりません。

この受取人チェックは、トークンを処理できないコントラクトへの誤送金を減らすことを目的としています。

登録された受取人が誠実、安全、または経済的に信頼できることを証明するものではありません。

operatorSend関数

関数を使うと、承認済みのオペレーターが保有者から受取人へトークンを移動できます。

オペレーターは、トークンのオペレーター規則に基づき、その保有者からあらかじめ承認されている必要があります。

保有者が指定した

と、オペレーターが指定したの両方をトークンの移動に付加できます。

オペレーターのアドレス、保有者、受取人、数量、データは、標準化された

イベントに含まれます。

承認されていないオペレーターによる呼び出しはリバートされなければなりません。

オペレーター権限により、別のアドレスが保有者のトークンを移動またはバーンできる場合があるため、慎重に扱う必要があります。

ERC-777のオペレーターとは？

オペレーターとは、保有者に代わってERC-777トークンを送金またはバーンする権限を与えられたアドレスです。

トークン保有者は、自身の残高に対して常にオペレーターとなります。

保有者は別のアカウントやスマートコントラクトに権限を与え、後から取り消すことができます。

オペレーターは、自動支払い、コントラクトベースのアカウント管理、予定された処理、復旧システム、その他のトークン管理の委任に役立ちます。

数値で示すERC-20の通常のアローワンスとは異なり、通常のオペレーター承認には、指定されたトークン数量の上限がありません。

この広範な権限は利便性を高める一方、オペレーターが悪意を持っている、または侵害された場合の損失可能性を高めます。

ウォレットは、オペレーターを承認すると保有者の残高を継続的に管理できる権限が与えられる場合があることを、明確に説明する必要があります。

デフォルトオペレーター

ERC-777トークンでは、すべての保有者に対して初期状態で承認されるデフォルトオペレーターを設定できます。

デフォルトオペレーターのリストはトークンコントラクトの作成時に固定され、規格上、後から追加または削除できません。

各保有者は、自身のトークンに対するデフォルトオペレーターの権限を取り消せる必要があります。

また、以前に権限を取り消したデフォルトオペレーターを再承認できなければなりません。

デフォルトオペレーターを利用すると、すべての保有者が最初に承認トランザクションを実行しなくても、システム全体のサービスを提供できます。

一方、デフォルトオペレーターはトークン保有者全体に対して広範な権限を初期状態で持つため、重要な信頼上の検討事項になります。

ERC-777トークンを多額保有する前に、デフォルトオペレーターのリストを確認し、その役割を理解してください。

送信者フック

ERC-777の送信者フックは

と呼ばれます。

保有者は、ERC-1820レジストリを通じて、このフックを実装するコントラクトを登録できます。

ERC-777の送金またはバーン時、トークンコントラクトは保有者の残高を減らす前にフックを呼び出さなければなりません。

フックには、オペレーター、送信者、受取人、数量、保有者データ、オペレーターデータが渡されます。

提案された移動を確認し、保有者が設定したルールに反する場合はリバートできます。

スマートウォレットは送信者フックを利用して、支出ポリシー、通知、追加の承認ロジックを適用できます。

同じ登録済みフックが複数のERC-777トークンに関する呼び出しを受ける可能性があるため、フックコントラクトは想定したトークンコントラクトから呼び出されていることを確認する必要があります。

受取人フック

ERC-777の受取人フックは

と呼ばれます。

受取アドレスは、ERC-1820を通じてこのフックを実装するコントラクトを登録できます。

送金またはミント時、受取人の残高を増やした後にトークンがフックを呼び出します。

フックは内部会計を更新したり、別のコントラクト操作を実行したり、支払いデータを記録したり、リバートして受取を拒否したりできます。

この設計により、トークンの送金と受取人の応答を1つのアトミックなトランザクションで行えます。

一方、ERC-777トークンの受取時には、元のトークン呼び出しが終了する前に外部コードが実行されることになります。

ERC-777トークンを受け取るプロトコルは、関連するすべての状態変更関数でこのコールバックの動作を考慮する必要があります。

ERC-1820とは？

ERC-777は、送信者フック、受取人フック、対応インターフェースの検出にERC-1820を使用します。

ERC-1820仕様は、あるアドレスが対応するインターフェースと、その実装コントラクトを公開できるユニバーサルレジストリを定義します。

このレジストリでは、通常のアカウントとスマートコントラクトの両方についてインターフェースを登録できます。

アカウント自身を実装者として登録することも、別のコントラクトを指定して自身に代わりインターフェースを処理させることもできます。

ERC-777フックを呼び出す前に、トークンはレジストリに問い合わせ、該当する送信者または受取人の実装を確認します。

このレジストリへの依存により、ERC-777の処理には外部コントラクトの検索が追加されます。

標準実装を正しく動作させるには、対応ネットワーク上に想定されるERC-1820レジストリがデプロイされ、適切に連携している必要があります。

ERC-777のイベント

ERC-777では、

、、、、の各イベントが定義されています。

イベントには、オペレーター、送信者、受取人、数量、保有者データ、オペレーターデータが記録されます。

イベントは、新しいトークンの生成と受取アドレスを記録します。

イベントは、トークンの破棄と対象となる保有者を記録します。

オペレーター関連のイベントにより、ウォレットや監視サービスは委任権限の変更を追跡できます。

ERC-20にも対応するトークンは、規格で必須のERC-777イベントに加えて、ERC-20の

イベントを発行する場合があります。

両方のイベントタイプが同じ送金を示しているとき、アプリケーションは同一の経済的な移動を二重計上しないようにしてください。

グラニュラリティと小数表示

グラニュラリティは、ERC-777コントラクトがミント、送金、バーンに許可する最小の内部トークン数量です。

この値はコントラクト作成時に設定され、規格上変更できません。

すべての残高と移動数量は、トークンのグラニュラリティの倍数でなければなりません。

ほとんどのトークンではグラニュラリティが1に設定され、内部単位の整数単位であれば移動できます。

ERC-777では、内部単位に対する表示上の額面を小数点以下18桁と定めています。

ERC-777トークンが任意のERC-20

関数も公開する場合、仕様上、その関数は18を返さなければなりません。

アプリケーションでは整数演算を使用し、浮動小数点数でトークン残高を計算せず、表示用に値をフォーマットしてください。

ERC-777とERC-20の互換性

ERC-777は、トークンがERC-777インターフェースと並行してERC-20関数を実装できるよう設計されています。

ERC-20規格では、

、、、などの一般的な関数が定義されています。

両方に対応するトークンは、ERC-20のみを理解する旧式のウォレットやアプリケーションでも利用できます。

送信者または受取人が該当するフックを登録していれば、互換性のあるERC-20送金にもERC-777のフックが適用される場合があります。

ただし、コントラクト受取人の保護方法は、2つのインターフェース間で異なります。

未登録の受取コントラクトへのネイティブERC-777の

はリバートされなければなりません。一方、ERC-20互換の送金は実行され、トークンがそのコントラクトに残る場合があります。

統合する側は、同じトークンのすべての移動でコールバックや受取人の動作が同じだと思い込まず、どの関数が呼び出されるかを確認してください。

ERC-777とERC-20のアローワンス

ERC-20では一般に、所有者から使用者へ、使用者が移転できるトークン数量を制限する数値のアローワンスを付与します。

ERC-777では、権限が取り消されるまで、オペレーターに保有者の残高を管理する権限を与えます。

オペレーターモデルは、役割を明示し、標準化された送金とバーンを可能にします。

アローワンスモデルでは、ユーザーが必要以上に大きな数量を承認する場合もありますが、数量上限を設けられます。

どちらの仕組みでも、悪意のある、または侵害されたコントラクトを承認すると損失が生じる可能性があります。

ウォレットは、操作によって固定アローワンス、無制限アローワンス、ERC-777のオペレーター権限のどれが付与されるかを表示する必要があります。

トークンが両方の規格に対応している場合、一方の権限を取り消しても、もう一方の権限が取り消されるとは限りません。

ERC-777のリエントランシーリスク

ERC-777の統合に伴う最も重要なリスクは、フックに起因します。

受取人フックは、トークンの送金処理中に外部コントラクトコードを実行します。

その外部コードは、プロトコルの元の関数が完了する前に、プロトコルへコールバックできます。

この動作をリエントランシーと呼びます。

脆弱なプロトコルでは、残高を計算してERC-777トークンを送金した後、内部会計が更新される前にコールバックを受け、古い内部会計を使って操作を繰り返される可能性があります。

両方に対応するERC-777トークンは、ERC-20形式の関数が呼び出された場合でも、登録済みフックを実行する場合があるため、この問題は発生し得ます。

関数名が通常のERC-20送金に似ているからといって、代替可能なトークンの送金にコールバックがないと思い込んではいけません。

リエントランシーリスクの軽減

設計上可能な場合、外部トークン関数を呼び出す前に、プロトコルは重要な会計情報を更新してください。

機密性の高いエントリーポイントには、適切なリエントランシーガードを使用してください。

1つの関数への再入を防いでも別の関数が悪用される可能性があるため、関連する関数をまとめて確認する必要があります。

コールバックの動作が不明な任意の資産を受け入れるのではなく、トークンコントラクトを検証してください。

テストでは、悪意のある送信者フック、悪意のある受取人フック、入れ子になったトークン移動、リバートするコールバック、複数関数への再入を確認してください。

ERC-777のフックは通常の送金に限られないため、ミントとバーンの経路も確認してください。

監査によってリスクを軽減できる場合はありますが、すべてのコールバック処理の安全性を保証することはできません。

受取人保護とその限界

ERC-777の受取人チェックは、トークンを処理できないコントラクトでトークンが永久に取り出せなくなるのを減らす目的で設計されました。

でトークンを受け取るコントラクトは、ERC-777の受取人実装を登録する必要があります。登録がなければ処理はリバートされます。

これは、トークン処理ロジックのない受取コントラクトへの送金も成功する可能性がある基本的なERC-20送金より強い保護です。

ただし、登録によって確認できるのは、そのインターフェースの実装が登録されていることだけです。

受取人が残高を正しく記録すること、出金を許可すること、セキュリティ監査を受けていることを証明するものではありません。

悪意のある受取人は、意図的にトークンを受け入れた後、損害を与えるロジックを実行する可能性があります。

ユーザーは送金先のコントラクトとトランザクションの目的を引き続き確認する必要があります。

ERC-777のメリット

ERC-777では、代替可能なトークンを受け取ったときにコントラクトへ通知できます。

送金と受取人による処理を1つのトランザクションにまとめられます。

プログラム可能なフックを通じて、送信者と受取人がトークンの移動を拒否できます。

アプリケーションが支払いや操作を解釈するために利用できるデータを付加できます。

オペレーターモデルにより、委任管理と明示的な権限取り消しを標準化できます。

ネイティブERC-777送金では、トークン受取に対応していないコントラクトへの誤送金を減らせます。

後方互換性により、1つのトークンをERC-20インフラで利用しながら、ERC-777対応アプリケーション向けの高度な機能も提供できます。

ERC-777の制約

フックにより、スマートコントラクトはトークンの移動を安全に判断することが難しくなります。

ERC-1820の照会によって外部依存と統合の複雑さが加わります。

オペレーター権限は、ユーザーが想定するより広範になる可能性があります。

デフォルトオペレーターには、重要な信頼と権限に関する検討事項が伴います。

ERC-20との互換性により、どの送金インターフェースを使うかによって動作が異なります。

ERC-777イベントとERC-20イベントの両方を誤って処理すると、アプリケーションが送金を二重計上する可能性があります。

現在の多くの開発ツールやアプリケーションは主にERC-20を中心としているため、ERC-777を実装する実用上のメリットは限られます。

広く使われているコントラクトライブラリから保守対象のERC-777実装が削除されたことで、新たな導入を安全に構築・維持するための作業が増えます。

ERC-777の普及が限定的だった理由

ERC-777が導入された時点で、ERC-20はウォレット、アプリケーション、分析ツール、スマートコントラクトシステムで広くサポートされていました。

そのネットワーク効果を置き換えるには、新たなコールバックやレジストリのロジックを正当化できるだけのメリットが必要でした。

多くのプロトコルは、予測可能なERC-20の送金とアローワンスの動作を前提に構築されていました。

ERC-777のフックは、単純な残高更新だと統合側が想定している操作に、予期しない外部呼び出しを導入しました。

ERC-2612の動機に関するセクションでは、ERC-777は機能を大幅に拡張しており、一般的なコントラクトで予期しない動作が生じる可能性があると指摘されています。

開発者は、トークン送金のライフサイクル全体を変更するのではなく、より限定的なERC-20拡張を採用して個別の使いやすさの課題に対応するようになりました。

そのためERC-777は技術的に重要な規格であり続けていますが、Ethereumの新規プロジェクトにおける代替可能トークンの標準的な選択肢ではありません。

開発者は新しいERC-777トークンを作るべきですか？

開発者はまず、提案するトークンにERC-777のどの機能が不可欠なのかを明確にしてください。

主な目的が署名付き承認であれば、より限定的なERC-20拡張で、汎用的な送金フックを導入せずにその機能を提供できる場合があります。

受取人のコールバックが必要な場合は、専用のアプリケーションコントラクトで、より安全かつ明確な動作を実現できるか検討してください。

新しいERC-777実装では、仕様全体、ERC-1820の登録、フック、オペレーター、イベント、ミント、バーン、ERC-20互換性を慎重に確認する必要があります。

古く保守されていない実装を、コンパイラの変更や既知のセキュリティ上の前提を確認せずに再利用するのは安全ではありません。

価値のある資産を扱う前に、コントラクトの単体テスト、ファズテスト、不変条件テスト、統合テストを十分に行い、独立したセキュリティレビューを受けてください。

また、利用を想定するウォレット、カストディシステム、ブリッジ、分散型アプリケーションが、トークンのコールバック動作に対応しているか確認してください。

ユーザーがERC-777トークンを評価する方法

最初に、信頼できる情報源を通じてトークンのコントラクトアドレスを確認します。

次に、コントラクトがERC-777のみに対応しているのか、ERC-20関数も公開しているのかを確認します。

3つ目に、デフォルトオペレーターを確認し、どのような権限を持つかを判断します。

4つ目に、ミント、バーン、一時停止、凍結、アップグレード、管理者権限を確認します。

5つ目に、購入後にロジックを変更できるプロキシをコントラクトが使用しているか確認します。

6つ目に、監査、ソースコードの検証、テスト範囲、過去のインシデントを確認します。

7つ目に、オペレーターの承認を確認し、不要になった権限を取り消します。

8つ目に、受取側のアプリケーションがERC-777とそのフックに明示的に対応しているか確認します。

9つ目に、多額を送金する前に少額のトランザクションを試します。

10個目に、トークンインターフェースへの準拠だけでは、金融価値、支払い能力、投資の安全性が証明されないことを忘れないでください。

ERC-777による支払いの例

ユーザーがERC-777トークンでオンチェーンのサブスクリプションコントラクトに支払うとします。

サブスクリプションコントラクトは、ERC-1820レジストリを通じて

の実装を登録します。

ユーザーは、コントラクトアドレス、支払額、エンコードされたサブスクリプション参照情報を指定して

を呼び出します。

トークンはユーザーの送信者フックを確認し、登録されている場合は残高を変更する前に呼び出します。

トークンはユーザーの残高を減らし、サブスクリプションコントラクトの残高を増やします。

次に、支払いの詳細を添えてコントラクトの

フックを呼び出します。

サブスクリプションコントラクトは、サブスクリプション期間を延長する前に、トークンアドレス、支払者、金額、付加された参照情報を確認します。

フックが支払いを拒否すると、トランザクション全体がリバートされ、トークン残高は元の状態に戻ります。

この処理は、ERC-777の開発動機となった、支払いと通知をアトミックに行う機能を示しています。

ERC-777でよくある間違い

よくある間違いの一つは、ERC-777が単にERC-20を置き換える新しい規格だと思い込むことです。

別の間違いは、トークン送金をコールバックのない処理として扱うことです。

3つ目は、呼び出し元のトークンコントラクトを確認せずに

の呼び出しを受け入れることです。

4つ目は、保有者の残高全体が権限の対象になり得ると理解せずにオペレーターを承認することです。

5つ目は、トークン作成時に設定されたデフォルトオペレーターを無視することです。

6つ目は、

イベントとイベントを別々の経済的な移動として処理することです。

7つ目は、ERC-20インターフェースでコントラクトにトークンを送り、ERC-777の受取人保護によってリバートされると思い込むことです。

8つ目は、最新のテストや依存関係の確認をせずに古い実装をデプロイすることです。

9つ目は、EIPのFinalステータスが現在のライブラリサポートやエコシステムでの広範な普及を意味すると考えることです。

10個目は、規格への準拠を、トークンが正当または安全である証拠として扱うことです。

よくある質問

ERC-777とは何ですか？

ERC-777は、フック、オペレーター、データフィールド、トークン送金、トークンバーンを定義する、FinalステータスのEthereum代替可能トークン規格です。

ERC-777は代替可能ですか、それとも非代替性ですか？

ERC-777は代替可能トークンの規格で、同じトークンの各単位は互いに交換可能です。

ERC-777は現在も有効ですか？

はい。公式提案はFinalステータスのままですが、普及は限定的で、主要なコントラクトライブラリからERC-777の実装が削除されています。

ERC-777はERC-20と同じですか？

いいえ。ERC-777はフック、オペレーター、付加データ、受取人チェックを追加しています。ただし、1つのトークンが両方の規格に対応することは可能です。

ERC-777の主な機能は何ですか？

よく知られている機能は、トークンの移動時に登録済みの送信者コントラクトと受取人コントラクトへ通知できることです。

tokensReceivedとは何ですか？

は、送金またはミントでERC-777の残高が増えた後に呼び出される受取人フックです。

tokensToSendとは何ですか？

は、送金またはバーンでERC-777の残高が減る前に呼び出される送信者フックです。

ERC-777のオペレーターとは何ですか？

オペレーターとは、保有者に代わってトークンを送金またはバーンする権限を与えられたアドレスです。

ERC-777のオペレーターはユーザーのトークンをすべて移動できますか？

通常のオペレーター権限は数値で指定するアローワンスではないため、保有者が取り消すまで、承認済みオペレーターが広範な管理権限を持つ場合があります。

デフォルトオペレーターとは何ですか？

デフォルトオペレーターは、トークン作成時にすべての保有者に対して承認されたアドレスです。ただし、各保有者は個別にその権限を取り消せなければなりません。

ERC-777がERC-1820を使用するのはなぜですか？

ERC-1820を使うと、トークンは送信者フック、受取人フック、対応するトークンインターフェースを実装しているコントラクトを検出できます。

ERC-777トークンをスマートコントラクトに送れますか？

はい。ただし、受取コントラクトが必要な受取人フックを登録していない場合、ネイティブのERC-777送金はリバートされなければなりません。

ERC-777トークンがコントラクトから取り出せなくなる場合はありますか？

ネイティブ送金では受取人チェックによってリスクが軽減されますが、ERC-20互換の送金や受取人ロジックの不備により、残高にアクセスできなくなる可能性は残ります。

ERC-777には小数桁がありますか？

この規格は表示上の額面を小数点以下18桁とし、任意のERC-20互換

関数は18を返す必要があります。

ERC-777のグラニュラリティとは何ですか？

ミント、送金、バーンが可能な最小の内部数量です。

ERC-777でリエントランシーが発生する可能性があるのはなぜですか？

トークン処理中にフックが外部コントラクトコードを実行するため、受取人または送信者の実装から、元の呼び出しが終わる前に別の関数を呼び出せる可能性があります。

すべてのERC-777トークンは危険ですか？

いいえ。ただし、すべての統合でコールバック、オペレーター権限、ERC-1820の照会、トークン固有のコントラクトロジックを意図的に処理する必要があります。

OpenZeppelin ContractsからERC-777実装が削除されたのはなぜですか？

普及が限定的で、複雑なフックの動作を汎用コンポーネントとして安全にサポートすることが難しかったためです。

既存のERC-777トークンは引き続き動作しますか？

はい。デプロイ済みのコントラクトは、それ自体のアップグレードまたは管理機能によって変更されない限り、コードに従って動作し続けます。

新しいトークンにERC-777を使うべきですか？

フックとオペレーターが、追加のセキュリティ、統合、保守の複雑さに見合う不可欠なメリットをもたらすかどうかによって判断します。

まとめ

ERC-777は、フック、オペレーター、トランザクションデータ、コントラクト受取人チェックを通じてトークン連携の改善を目指す、FinalステータスのEthereum代替可能トークン規格です。

関数を使うと、トークンを送金し、互換性のある受取コントラクトへ1つのアトミックなトランザクションで通知できます。

フックとフックにより、プログラム可能な送信者ルールと受取人ルールを設定できます。

オペレーターは標準化された権限委任を可能にし、デフォルトオペレーターは保有者が権限を取り消せることを前提に、システム全体の機能を提供できます。

ERC-1820は、これらのフックとインターフェースの検出に使用するレジストリを提供します。

ERC-777はERC-20との互換性を維持できますが、2つのインターフェースを使った送金で受取人の動作が常に同じになるとは限りません。

合成可能性を高める同じコールバック機能が、リエントランシーを引き起こし、統合の動作を把握しにくくする可能性があります。

開発者は呼び出し元を検証し、関連するすべての状態変更関数を保護し、オペレーター権限を確認し、悪意のあるフックをテストし、送金処理の全体を理解する必要があります。

この規格は引き続きFinalステータスですが、普及が限定的で、現在利用されている主要なコントラクトライブラリから削除されているため、新しいトークンの標準的な選択肢ではなく、特定用途向けの選択肢となっています。

ERC-777を理解すると、トークンコールバックのメリットと、代替可能トークンの送金が外部コードを実行することで生じるセキュリティリスクの両方を把握しやすくなります。