ERC-20

ERC-20とは？

ERC-20は、スマートコントラクトで作成される代替可能な暗号資産の共通インターフェースを定めるEthereumトークン規格です。

代替可能とは、同じトークンの等しい数量が、トークンコントラクトの会計ルール上、互いに交換可能であることを意味します。

たとえば、一般的なERC-20トークン1単位は、同じトークンの別の1単位と、コントラクトが定める特性において同じです。

公式のERC-20仕様は、トークン供給量と残高の確認、トークンの移転、第三者によるトークン使用の承認に関する関数を定めています。

また、ウォレットやアプリケーションが移転や承認の変更を確認できるよう、標準化されたイベントも定めています。

ERC-20はFinal Ethereum Request for Comments規格であり、Ethereum互換エコシステムにおける代替可能トークンの主要な技術的基盤です。

ウォレット、スマートコントラクト、ブロックチェーンエクスプローラー、カストディシステムなど、さまざまな暗号資産アプリケーションが多くの異なるトークンに同じ基本メソッドを利用できるため、相互運用性が向上します。

ERC-20は、トークンの価格、供給ポリシー、法的分類、ユーティリティ、担保による裏付け、ガバナンス権、投資対象としての品質を定めません。

ERCとは？

ERCは「Ethereum Request for Comments」の略です。

ERCは、開発者がEthereumスマートコントラクトや関連ソフトウェアに実装できる、アプリケーションレベルの規格または慣例を表します。

番号の20は、この代替可能トークンインターフェースを導入した提案を識別します。

トークン数、小数桁数、対応ネットワーク、コントラクト関数の数を表すものではありません。

この文書はEthereum Improvement Proposalのプロセスに含まれるため、ERC-20はEIP-20と呼ばれることもあります。

ERC-20が作られた理由

代替可能トークンの共通規格ができる前は、コントラクトごとに残高確認、移転、委任された使用権限の関数名やルールが異なる場合がありました。

ウォレットは、トークンごとに独自の連携コードを用意する必要がありました。

分散型アプリケーションも、2つのトークンコントラクトが同じ操作に対応していると安全に想定できませんでした。

ERC-20は、多くの代替可能トークンと1つのアプリケーションが連携できる、最低限の共通インターフェースを作りました。

この相互運用性により、支払い、ガバナンス、貸付、流動性システム、ボールト、ゲーム、報酬プログラムなど、さまざまな暗号資産アプリケーションでトークン残高を利用できるようになりました。

基本インターフェースを変更せずに開発者が専門的な機能を追加できるよう、規格の範囲は意図的に限定されています。

ERC-20の仕組み

ERC-20トークンは、Ethereumまたは互換性のあるブロックチェーンにデプロイされたスマートコントラクトによって管理されます。

コントラクトは、各アドレスが所有するトークン数量を記録します。

また、トークンの総供給量と、所有者が支出者に付与した利用許可も記録します。

有効な移転が行われると、コントラクトは送信者の残高を減らし、受取人の残高を増やします。

コントラクトは

イベントを発行し、外部ソフトウェアが移転を確認できるようにします。

所有者が支出者を承認すると、コントラクトは利用許可を更新し、

イベントを発行します。

ブロックチェーンのノードはこれらのコントラクトルールを実行し、受理された状態変更がすべて有効であることを検証します。

トークンコントラクトはホストネットワークの状態とセキュリティモデル内で動作するため、独立したブロックチェーンを維持するものではありません。

ERC-20の主な関数

ERC-20の必須インターフェースには、主な関数が6つあります。

関数は

、、、、、です。

規格は、任意のメタデータ関数である

、、についても説明しています。

ミント、バーン、一時停止、課税、投票、凍結、供給量上限はコアインターフェースの必須機能ではありません。

カスタムロジックや標準化された拡張によって、これらの機能を追加できます。

totalSupply関数

関数は、トークンの報告供給量に現在含まれるトークン単位数を返します。

値は、トークンの最小内部単位で表されます。

最大供給量が自動的に明らかになるわけではありません。

現在の総供給量が公表された最大供給量を大きく下回っていても、コントラクトが将来追加のトークンをミントできる場合があります。

トークンがバーンに対応していれば、現在の総供給量が減少することもあります。

恒久的な希少性の証明として

を使うのではなく、ミント権限や供給量の管理方法を確認してください。

balanceOf関数

関数は、指定されたアドレスに記録されたトークン残高を返します。

返される値は、トークンの最小内部単位で表されます。

ウォレットに表示される残高は通常、この整数をトークンの小数桁数に応じて整形した値です。

この関数が返すのは、1つのトークンコントラクト内の残高だけです。

他のコントラクトアドレスや別のネットワークで作成された、同じような名前のトークンは含まれません。

特殊なトークンでは、各保有者について通常の移転イベントを発行せずに、リベースなどの会計ロジックで残高が変化する場合があります。

transfer関数

関数は、呼び出し元の残高から指定数量を受取人に移転します。

呼び出し元は、操作を完了できるだけのトークンを保有している必要があります。

移転が成功すると、

イベントが発行されます。

ERC-20仕様では、数量0の移転も通常の移転として処理し、イベントを発行する必要があります。

この関数は、規格上、成功を示す真偽値を返します。

が返されることはないと、アプリケーションが想定してはなりません。

最新の実装の多くは失敗時に

を返す代わりに処理を取り消しますが、連携先のトークン固有の挙動を考慮する必要があります。

approve関数

関数を使うと、トークン所有者は、支出者が所有者の残高から移転できる数量を設定できます。

承認しただけで、支出者にトークンがすぐ渡るわけではありません。

コントラクトは利用許可を記録し、支出者は後から

を使ってその許可を利用できます。

承認は、1人の所有者、1人の支出者、1つのトークンコントラクトに適用されます。

あるネットワークまたはトークンコントラクトへの承認が、別の場所での支出を自動的に許可することはありません。

承認トランザクションは無害なウォレット接続ではなく、金融上の権限付与として扱ってください。

allowance関数

関数は、支出者が所有者から移転する権限を現在持つトークン数を返します。

支出者が

を使うと、利用許可の残額は減る場合があります。

所有者は別の承認トランザクションで利用許可を更新できます。

実装によっては、符号なし整数の最大値を無制限の承認として扱い、移転のたびにその値を減らさないことがあります。

支出者がアクセス権を保持し、所有者にトークン残高がある限り、無制限の承認は危険です。

不要になった権限は確認し、取り消してください。

transferFrom関数

関数を使うと、承認された支出者が所有者から受取人へトークンを移転できます。

支出者には十分な利用許可が必要であり、所有者にも十分な残高が必要です。

実装が無制限の承認として扱わない限り、成功した呼び出しでは通常、利用可能な許可が減ります。

トークン移転時には

イベントを発行する必要があります。

この委任移転の仕組みにより、スマートコントラクトは支払いの回収、入金の受け入れ、担保のロックなど、承認された操作を実行できます。

一方で、悪意のある、または侵害された支出者は、移転ごとに所有者の承認を求めず、残っている利用許可を使えるため、リスクも生じます。

ERC-20のイベント

ERC-20規格は、

イベントとイベントを定義しています。

イベントは、オフチェーンのアプリケーションが効率よくインデックス化できるトランザクションログです。

ウォレット、分析ツール、会計システム、ブロックチェーンエクスプローラーは、これらのログでトークンの活動を追跡します。

イベントは、必ず発行元のコントラクトアドレスと併せて解釈してください。

悪意のあるコントラクトでも、真正または価値のあるトークンではないのに、見慣れたイベント名を使用できます。

Transferイベント

イベントは、送信者、受取人、トークン数量を記録します。

通常の移転では、送信者と受取人のアドレスはゼロアドレスではありません。

トークンの作成は、一般にゼロアドレスから受取人への移転として表されます。

トークンの破棄は、一般に保有者からゼロアドレスへの移転として表されます。

ERC-20仕様では、実装が供給量を作成する際、新規作成トークンについてゼロアドレスからの

イベントを発行する必要があります。

ミントイベントが確認できても、将来のミントが不可能であることの証明にはなりません。

Approvalイベント

イベントは、所有者、支出者、利用許可の数量を記録します。

アプリケーションはこれを使って、委任された支出権限の変更を追跡できます。

承認そのものはトークンを移転せず、所有権も変更しません。

承認によって、支出者は許可された数量の範囲で

を使えるようになります。

利用許可を取り消しても、権限が有効な間に完了したトークン移転は元に戻りません。

ERC-20の名前とシンボル

関数と関数は、人が読めるトークン情報を提供します。

名前は資産を説明し、シンボルは短い表示ラベルを提供する場合があります。

ERC-20の初期仕様では、どちらの関数も任意です。

名前とシンボルは一意ではありません。

誰でも、別の資産の名前やシンボルをコピーしたトークンをデプロイできます。

ウォレットとユーザーは、ブランド名だけに頼らず、完全なコントラクトアドレスとブロックチェーンネットワークを確認してください。

ERC-20の小数桁数とは？

任意の

関数は、トークンの最小単位を人が読める表示形式にする方法をアプリケーションに伝えます。

小数桁数が18のトークンでは、通常の表示上、内部の整数数量を10の18乗で割ります。

たとえば、小数桁数が6のトークンでは、内部数量が1,000,000単位の場合にトークン1枚を表します。

小数桁数があっても、ブロックチェーン上の残高が浮動小数点数になるわけではありません。

スマートコントラクトは整数でトークンの会計処理を行います。

小数桁数は表示方法と単位に影響しますが、基礎となる演算モデルは変わりません。

小数桁数18が一般的で、最新のOpenZeppelin ERC-20実装でもデフォルトですが、別の値を使うERC-20トークンもあります。

ERC-20の供給モデル

ERC-20は、トークン供給量の作成方法を定めていません。

固定供給量のトークンは、デプロイ時に供給量全体をミントし、それ以降のミント関数を公開しない場合があります。

上限付きトークンは、コントラクトで定めた最大値に達するまでミントを許可できます。

上限のないトークンは、恒久的な最大供給量を設けず、認可されたアカウントまたはプロトコルの処理によって追加発行できる場合があります。

アルゴリズム型トークンは、プログラムされた条件に従って供給量を調整できます。

ラップドトークンは、基礎資産を預け入れたときにトークンを発行し、その資産を出金するときにトークンをバーンする場合があります。

公式のERC-20供給ガイドでは、適切なミントの仕組みを通じて基本実装に供給ロジックを追加する必要があると説明されています。

ERC-20トークンのミント

ミントは新しいトークン単位を作成し、総供給量を増やします。

ERC-20コアインターフェースは、公開ミント関数を定めず、誰が呼び出せるかも指定していません。

トークンは、管理者、ガバナンスプロセス、ブリッジ、ステーキングシステム、ボールト、その他コントラクトが定める権限者にミントを制限できます。

安全でないミント権限は、既存保有者の持分を希薄化させたり、担保に関する前提を崩したりする可能性があります。

ミントが可能か、誰が管理しているか、上限があるか、実装をアップグレードできるかを確認してください。

トークン供給量が固定されているという説明は、デプロイ済みコントラクトのロジックと特権権限を通じて検証する必要があります。

ERC-20トークンのバーン

バーンはトークン単位を破棄し、通常は総供給量を減らします。

コア規格は、保有者が公開バーン関数を使えることを必須としていません。

実装によっては、保有者が自分のトークンをバーンしたり、承認済みの支出者が利用許可を通じてバーンしたりできます。

償還、決済、プロトコル操作の際にのみトークンをバーンするシステムもあります。

アクセスできないアドレスにトークンを送ることは、必ずしもコントラクト上のバーンと同じではありません。報告される総供給量が変わらない場合があるためです。

供給データを解釈する前に、トークンの実際のバーンロジックを確認してください。

ERC-20の承認と利用許可の競合状態

既存の非ゼロ利用許可を、別の非ゼロ数量へ直接変更すると、トランザクションの順序に関するリスクが生じることがあります。

所有者が変更後の承認を確定する前に支出者が古い利用許可を使い、その後に新しい利用許可も受け取る可能性があります。

元のERC-20仕様では、ユーザーインターフェースは別の非ゼロ値を設定する前に、利用許可を一度0に設定するよう案内する必要があるとされています。

古いアプリケーションとの互換性が低下するため、トークンコントラクト自体がこの順序を必須としてはなりません。

利用許可を丁寧に設計されたヘルパー関数で増減できれば使いやすさが向上しますが、実装によって対応状況が異なります。

アプリケーションが合理的に必要とする範囲を超える利用許可を残さないようにしてください。

無制限のトークン承認

無制限の承認では通常、256ビット符号なし整数の最大値を利用許可として設定します。

これにより、操作のたびに新しい承認を送信する必要が減ります。

一方で、支出者に現在と将来のトークン残高に対する継続的な権限を与えることになります。

支出者のコントラクトがエクスプロイトを受けたり、悪意を持ってアップグレードされたり、侵害された管理者に制御されたりすると、利用許可を使って保有者のトークンが移転される可能性があります。

利便性と、権限の数量・有効期間を比較して判断してください。

上限を設けた利用許可なら、支出者が1つ侵害された場合の最大損失を抑えられる可能性があります。

ERC-2612 Permitとは？

ERC-2612は、署名メッセージによってERC-20所有者が利用許可を作成できるようにする拡張規格です。

署名された権限は、別のアカウントまたはスマートコントラクトからオンチェーンに送信できます。

これにより、承認とアプリケーション操作を1つのユーザーフローにまとめられる場合があります。

公式のERC-2612 permit仕様は、ERC-20に

、、を追加します。

permitが成功するとノンスが消費され、通常、同じ署名を再利用できなくなります。

期限を設定すると、署名が有効な期間を制限できます。

permitへの対応は任意であり、ERC-20の初期コアインターフェースには含まれていません。

Permit署名のリスク

permit署名により、所有者からオンチェーントランザクションをすぐ送信しなくても、トークンの支出を承認することになります。

フィッシングサイトは、permitをログイン、認証、または無害なガスレスメッセージとして提示する場合があります。

支出者は有効なpermitを後から送信し、期限前に得られた利用許可を使うことができます。

署名する前に、トークン、支出者、数量、ネットワーク、ノンス、有効期限を確認してください。

ウォレットにガス代の支払いが不要と表示されても、署名リクエストが安全とは限りません。

コントラクトウォレットでは、基本的な外部所有アカウントの方式以外に追加の署名検証対応が必要となる場合があります。

ERC-20は受取人への自動コールバックに対応していますか？

ERC-20コアの移転関数は、受取先のスマートコントラクトにトークンの受領確認を求めません。

そのため、受取先コントラクトにトークンを記録または返却する関数がなくても、移転が成功する場合があります。

その結果、互換性のないコントラクトに資産が閉じ込められる可能性があります。

通常の移転後にERC-20が自動的に受取人のコードを呼び出すこともありません。

ERC-1363拡張は、コールバックが必要なアプリケーション向けに、transfer-and-callおよびapprove-and-call操作を追加します。

コールバック対応の拡張は外部呼び出しを追加するため、再入可能性やレシーバーのセキュリティリスクを確認する必要があります。

SafeERC20と標準仕様に準拠しないトークン

ERC-20仕様では、呼び出し元は返り値が

の場合に対応する必要があります。

実際には、一部の古いトークンや特殊なトークンは、移転に成功しても真偽値を返しません。

失敗時に

を返す代わりに処理を取り消す実装もあります。

特定の挙動を前提とするインターフェースを直接呼び出すと、失敗したり結果を誤って解釈したりする場合があります。

最新のSafeERC20ユーティリティはトークン操作をラップし、

を返すトークンと、値を返さない一部のトークンに対応します。

ラッパーは互換性を高めますが、悪意のあるトークンを経済的に安全にするものではありません。

移転手数料のあるトークン

移転手数料のあるトークンは、トークンの移動時に手数料を差し引きます。

受取人が受け取る数量は、送信者または呼び出し元のコントラクトが指定した数量より少なくなります。

実際に受け取った量を測定せず、要求された量を入金額として計上するプロトコルは、担保不足になる可能性があります。

このトークン挙動に対応するアプリケーションは、移転前後のトークン残高を比較する必要があります。

コントラクトがアップグレード可能、または管理者の制御下にある場合、手数料ルールが変更されることもあります。

ERC-20の標準関数名が使われていても、移転結果が一定であるとは限りません。

リベース型ERC-20トークン

リベース型トークンは、コントラクトで定められた調整処理に従い、アカウント残高を変更します。

保有者が通常の移転を行わなくても、

に表示される残高が増減する場合があります。

プラスのリベースでは表示残高が増え、マイナスのリベースでは減ります。

内部シェアを使い、交換レートを通じて表示残高を計算するシステムもあります。

残高は移転によってのみ変わると想定するアプリケーションは、リベース型トークンの会計を誤る可能性があります。

トークンが固定単位の残高を表すのか、変動する比例的な請求権を表すのかを確認してください。

ラップドERC-20トークン

ラップドERC-20トークンは、スマートコントラクトまたはカストディの仕組みを通じて別の資産を表します。

ユーザーは基礎資産を預け入れ、対応するERC-20単位を受け取る場合があります。

償還時には通常、ラップドトークンをバーンまたは返却し、基礎資産を受け取ります。

ラッパーの価値は、裏付けの仕組みが利用可能で、正しく機能しているかによって異なります。

スマートコントラクトのエクスプロイト、カストディ障害、ブリッジ障害、担保の凍結、会計ミスによって、想定される連動関係が崩れる場合があります。

ERC-20への準拠が示すのはインターフェースの互換性であり、十分な裏付け資産の存在ではありません。

ERC-20ガバナンストークン

ERC-20トークンを拡張し、オンチェーンガバナンスシステムの投票権を表すことができます。

投票権は、現在残高、委任済み残高、過去の残高スナップショットに応じて決まる場合があります。

最新のERC-20実装ライブラリーには、委任と過去の投票権照会に対応するERC-20投票拡張があります。

トークンを保有していても、一部のシステムでは委任が必要なため、自動的に投票権が有効になるとは限りません。

トークン投票は、保有の集中、借入資産、低い投票率、管理者権限の影響を受ける場合もあります。

ERC-20コア規格はガバナンスルールを定めていません。

ERC-20のボールトシェア

ERC-20トークンは、トークン化ボールトのシェアを表すために使用できます。

各シェアは、基礎トークンの固定数量ではなく、ボールトが管理する資産に対する比例的な請求権を表します。

ERC-4626トークン化ボールト規格は、ERC-20に入金、出金、ミント、償還、換算の標準関数を追加します。

戦略の運用成績、手数料、損失、会計ルールに応じて、ボールトシェアの基礎資産に対する価値は上昇または下落します。

ERC-20への準拠だけでは、シェアトークンの裏付けや償還方法は分かりません。

ERC-20のエラーメッセージ

元のERC-20規格はSolidityのカスタムエラーより前に作られたため、失敗時のメッセージを標準化していません。

トークンによって、

を返す、テキストメッセージとともに処理を取り消す、カスタムエラーで処理を取り消す、誤った挙動をするなどの違いがあります。

FinalERC-6093規格は、一般的なトークンエラー向けの構造化カスタムエラーを定めています。

例として、残高不足、送信者無効、受取人無効、利用許可不足、承認者無効、支出者無効などのエラーがあります。

エラーの標準化により、ウォレットやアプリケーションが失敗をより一貫して説明できます。

ERC-6093はERC-20コアインターフェースを変更せず、既存のすべてのトークンにエラーの採用を求めるものでもありません。

ERC-20はERC-165を使いますか？

ERC-20の初期規格は、ERC-165によるインターフェース検出を必須としていません。

アプリケーションは、

を呼び出せばすべてのERC-20トークンを特定できると想定できません。

ソフトウェアは通常、コントラクトABI、検証済みソースコード、既知のトークンリスト、レジストリーデータ、関数の直接テストを通じて互換性を確認します。

見慣れた関数セレクターが存在しても、規格への完全な準拠を証明するものではありません。

悪意のあるコントラクトは、インターフェースの一部を模倣しながら、有害または予期しない挙動を実行する場合があります。

ERC-20とネイティブETHの違い

ETHはEthereumのネイティブ暗号資産であり、それ自体はERC-20トークンではありません。

Ethereumアカウントは、プロトコルレベルのvalue transferを通じてネイティブETHを送信できます。

ERC-20残高は、それぞれのスマートコントラクト内に存在します。

別のシステムが手数料を肩代わりまたは抽象化しない限り、移転する資産がERC-20トークンであっても、Ethereumのトランザクション手数料にはETHが必要です。

トークンインターフェースを必要とするアプリケーション向けにETHのERC-20形式を作成できますが、ラップされた資産はネイティブETHとは別のものです。

ERC-20とERC-721の違い

ERC-20は代替可能な残高を表し、ERC-721は個別に識別される非代替性トークンを表します。

ERC-20アカウントは、交換可能な単位を数量として保有します。

ERC-721アカウントは、個別のトークンIDを所有します。

ERC-20では通常、小数桁数に基づく表示が用いられます。一方、ERC-721トークンは通常、完全な固有単位として移転されます。

またERC-721には、ERC-20コア規格にない安全な移転先の確認機能があります。

ERC-20とERC-1155の違い

ERC-20は、1つのコントラクトインターフェースで1種類の代替可能トークンを管理します。

ERC-1155は、1つのコントラクトで複数のトークンIDとそれぞれの残高を管理できます。

ERC-1155のトークンIDは、代替可能、準代替可能、固有の資産を表す場合があります。

ERC-1155は、一括移転操作とレシーバーコールバックも定めています。

適切な規格は、1種類の代替可能資産を必要とするのか、1つのコントラクトで複数の資産タイプを管理するのかによって異なります。

ERC-20の一般的なユースケース

価値連動型トークンは、準備資産、担保システム、アルゴリズムの仕組みに関連する移転可能な単位をERC-20で表すことができます。

ガバナンスシステムでは、ERC-20残高または委任された単位を投票権として利用できます。

ブロックチェーンゲームでは、交換可能な通貨、報酬、資源にERC-20トークンを利用できます。

ボールトやステーキングシステムは、預け入れたポジションを表すERC-20の受取トークンを発行できます。

ラップド資産では、別の場所で保有する資産に対する請求権をERC-20で表せます。

プロジェクトは、ロイヤリティポイント、アクセス権、決済単位、トークン化された金融上の請求権などにもこの規格を利用できます。

このインターフェースは、特定の用途が合法か、十分に裏付けられているか、分散化されているか、経済的に持続可能かを定めません。

ERC-20スマートコントラクトのリスク

ERC-20の実装には、移転、利用許可、ミント、バーン、課税、アクセス制御のロジックに誤りが含まれる可能性があります。

特権を持つ管理者は、移転の一時停止、残高の凍結、アドレスのブロック、供給量のミント、手数料の変更、コントラクトのアップグレードを実行できる場合があります。

プロキシのアップグレードによって、保有者がトークンを取得した後に挙動が変わる可能性があります。

カスタムトークンロジックに含まれる外部呼び出しは、再入可能性やサービス妨害のリスクにつながる場合があります。

トークン自体がコードに従って動作していても、連携の誤りによって資金が失われることがあります。

規格への準拠は相互運用性を高めますが、監査、テスト、ソースコードのレビュー、権限の分析に代わるものではありません。

トークン承認を悪用するフィッシング

承認フィッシングは、悪意のある支出者をユーザーに承認させようとします。

インターフェース上では、認証、接続、報酬の対象確認、アカウント復旧などの操作として説明される場合があります。

承認が確定すると、支出者は

を使い、利用許可の範囲内でトークンを移転できます。

permit署名でも、被害者がすぐにオンチェーン承認トランザクションを送信せずに、同様の権限を作成できる場合があります。

承認やpermitのたびに、トークンコントラクト、支出者アドレス、利用許可額、ネットワーク、操作目的を確認してください。

ERC-20の利用許可を取り消すために、シードフレーズや秘密鍵をアプリケーションへ入力してはなりません。

トークン移転詐欺

詐欺師は、所有者の許可なしに未知のERC-20トークンをウォレットへ送信できます。

トークン名、シンボル、メタデータに、誤解を招くウェブサイトや主張が含まれている場合があります。

宣伝されたサイトにアクセスすると、悪意のある承認や署名を求められる可能性があります。

攻撃者は、ユーザーの取引履歴にあるアドレスと見た目が似たアドレスを作成することもあります。

先頭と末尾の文字が一致するだけで送金先を選ばず、信頼できる記録から検証済みアドレスをコピーしてください。

未知のトークンを受け取っても、ウォレット所有者がそれを操作する必要はありません。

開発者によるERC-20の実装方法

開発者は通常、レビュー済みで継続的に保守されている実装を土台にする必要があります。

最新のERC-20開発ガイドには、permit、上限、バーン、一時停止、投票、ラッピング、ボールトなどに対応するコアコントラクトと拡張が用意されています。

供給量の作成方法を明確に定め、適切なアクセス制御で保護してください。

移転をカスタマイズする場合も、残高、供給量、イベント、利用許可に関する不変条件を保つ必要があります。

数量0の移転、最大値、残高不足、利用許可不足、ミント、バーン、承認、特殊なアドレスとの移転をテストしてください。

対応する資産に応じて、

を返すトークン、値を返さないトークン、移転手数料のあるトークン、リベース型トークン、一時停止中のトークン、コールバック対応トークンでも連携をテストする必要があります。

ユーザーによるERC-20トークンの評価方法

最初に、ブロックチェーンネットワークと完全なトークンコントラクトアドレスを確認します。

次に、現在の供給量、最大供給量に関する主張、ミント権限を調べます。

3つ目に、管理者、一時停止、凍結、ブロックリスト、手数料、アップグレードの権限を確認します。

4つ目に、トークンが別の資産に裏付けられているか、償還がどのように行われるかを確認します。

5つ目に、移転手数料、リベースの挙動、制限、ウォレットに及ぼす特殊な影響を確認します。

6つ目に、監査、検証済みソースコード、インシデント履歴を調べます。ただし、監査を保証として扱わないでください。

7つ目に、保有者の集中度、利用可能な流動性、流動性が失われる条件を確認します。

8つ目に、トークンのブランドに頼らず、実際の需要や利回りの源泉を理解します。

9つ目に、見慣れないスマートコントラクトを利用する前後に承認を確認します。

10個目に、多額の資金を預ける前に、新しいトークンやコントラクトを少額で試してください。

ERC-20の移転例

AliceがERC-20トークンを500単位保有し、そのうち75単位をBobに送ろうとしているとします。

Aliceのウォレットは、正しいブロックチェーン、トークンコントラクト、受取人アドレス、数量、トランザクション手数料を確認します。

ウォレットは、トークンの

関数を呼び出すトランザクションを送信します。

トークンコントラクトは、Aliceが75単位以上を保有しているか確認します。

Aliceの残高を425単位に減らし、Bobの残高を75単位増やします。

コントラクトは、Aliceのアドレス、Bobのアドレス、移転数量を含む

イベントを発行します。

Ethereumのバリデーターはトランザクションをブロックに含め、ノードは結果として生じる状態変更を個別に検証します。

承認後、ウォレットやアプリケーションはトークンコントラクトから更新された残高を読み取れます。

ERC-20の承認例

AliceがERC-20トークンを100単位、代理でボールトコントラクトに預け入れてもらうとします。

Aliceはまず、ボールトコントラクトのアドレスと、ボールトが使用するトークンを確認します。

を呼び出し、ボールトに100単位の利用許可を付与します。

トークンコントラクトは利用許可を記録し、

イベントを発行します。

その後、Aliceはボールトの入金関数を呼び出します。

ボールトは

を使用して、Aliceから100単位をボールトへ移転します。

移転を完了する前に、トークンコントラクトはAliceの残高とボールトに対する利用許可を確認します。

移転後、使用済みの利用許可は通常、トークンの実装に従って減少します。

ERC-20でよくある間違い

よくある間違いの1つは、トークン名やシンボルだけでトークンを特定することです。

もう1つは、すべてのERC-20トークンが小数桁数18を使うと思い込むことです。

3つ目は、信頼できないコントラクトに無制限の承認を付与することです。

4つ目は、ウォレットを切断すればトークンの利用許可が取り消されると考えることです。

5つ目は、トークン移転の真偽値や標準外の挙動を無視することです。

6つ目は、移転手数料のあるトークンの入金を、実際の受取量ではなく要求量で計上することです。

7つ目は、

を恒久的な供給量上限の証明として扱うことです。

8つ目は、ERC-20への準拠が担保による裏付けや償還価値を証明すると考えることです。

9つ目は、支出者、数量、有効期限を確認せずpermitに署名することです。

10個目は、監査や検証済みソースコードによってトークンの障害が起こらないと考えることです。

よくある質問

ERC-20とは何ですか？

ERC-20は、代替可能なスマートコントラクトトークンの共通関数とイベントを定めるEthereum規格です。

ERC-20は暗号資産ですか？

ERC-20は技術規格です。この規格を実装する個別のコントラクトが、暗号資産トークンを作成できます。

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

いいえ。Ethereumはブロックチェーンネットワークであり、ERC-20はそのネットワーク上で動作するトークンに使われるスマートコントラクトインターフェースです。

ETHはERC-20トークンですか？

いいえ。ETHはEthereumのネイティブ資産であり、それ自体はERC-20コントラクトインターフェースを使用しません。

ERC-20トークンは代替可能ですか？

はい。通常のERC-20トークンでは、同じトークンの等しい数量は、コントラクトの会計ルール上、互いに交換可能です。

ERC-20のコア関数6つは何ですか？

、、、、、です。

ERC-20が定めるイベントは何ですか？

イベントとイベントです。

name、symbol、decimalsは必須ですか？

いいえ。ERC-20の初期仕様では、3つのメタデータ関数はいずれも任意です。

すべてのERC-20トークンは小数桁数18ですか？

いいえ。18が一般的ですが、トークンごとに異なる小数桁数を設定できます。

ERC-20の承認は何をしますか？

指定した利用許可の範囲内で、支出者が所有者のトークンを移転する権限を付与します。

transferFromは何に使いますか？

認可された支出者が、所有者から受取人へトークンを移転するために使います。

ERC-20の無制限承認とは何ですか？

支出者が承認を繰り返さずにトークンを移転し続けられるよう、利用許可に極めて大きな最大値を設定することです。

ウォレットを切断すると承認は取り消されますか？

いいえ。オンチェーンの利用許可は、トークンコントラクトで変更されるか、その他の理由で効力を失うまで有効です。

ERC-20 permitとは何ですか？

permitは、所有者が承認トランザクションを直接送信せずに、利用許可を作成または変更できる、任意のERC-2612署名メッセージです。

ERC-20トークンはミントできますか？

できます。実装にミントの仕組みがあり、認可された当事者またはプロトコルの条件によって利用できる場合に限ります。

ERC-20トークンはバーンできますか？

できます。実装にトークン単位を破棄するコントラクトロジックがある場合に可能です。

ERC-20は供給量の固定を必須としていますか？

いいえ。供給ポリシーは個別のトークン実装によって決まります。

ERC-20の移転で手数料を課せますか？

はい。コア規格で必須ではありませんが、カスタマイズされたトークンは移転手数料を差し引くことができます。

移転なしにERC-20残高が変わることはありますか？

あります。リベースやカスタム会計モデルによって、通常の保有者間移転なしに報告残高が変わる場合があります。

ERC-20トークンがコントラクト内で動かせなくなることはありますか？

あります。コア移転関数は、受取先コントラクトがトークンを扱ったり返却したりできることの確認を求めません。

ERC-20はERC-165によるインターフェース検出に対応していますか？

いいえ。ERC-20の初期仕様ではERC-165を必須としていません。

ERC-20はトークンの裏付けを保証しますか？

いいえ。この規格は準備金、担保、償還権、支払能力を検証しません。

ERC-20に準拠していればトークンは安全ですか？

いいえ。互換性のあるトークンにも、危険な権限、欠陥のあるコード、不十分な裏付け、低い流動性、悪意のある管理者が存在する可能性があります。

正しいERC-20トークンはどのように特定できますか？

信頼できる情報源を通じて、ブロックチェーンネットワークと完全なコントラクトアドレスを確認してください。

ERC-20の主な利点は何ですか？

多くの暗号資産ウォレットやスマートコントラクトが理解できる共通インターフェースによる相互運用性です。

まとめ

ERC-20は、スマートコントラクトで作成される代替可能トークンのEthereumにおける基礎規格です。

供給量と残高の確認、トークン移転、委任された支出権限の付与に共通のメソッドを定めています。

イベントとイベントにより、暗号資産アプリケーションはトークン移転と権限を監視できます。

任意のメタデータ関数はトークン名、シンボル、小数桁数を提供しますが、これらの値は真正性を証明しません。

この規格は、供給量の作成方法、トークンの裏付け、管理者、資産の金融的価値を定めません。

拡張により、署名済みpermit、投票、一時停止、供給上限、コールバック、ボールト機能、標準化されたエラーなどを追加できます。

悪意のある支出者は有効な利用許可を

で使えるため、承認はユーザーにとって特に大きなリスクの1つです。

開発者は、

を返すトークン、値を返さないトークン、移転手数料、リベース、コールバック、特殊な小数桁数、カスタム制限を考慮する必要があります。

ユーザーはコントラクトアドレスを確認し、権限を見直し、ミント権限とアップグレード権限を理解し、トークンの裏付けや経済設計を調べてください。

ERC-20互換性は共通の技術言語をもたらしますが、スマートコントラクトのセキュリティ、慎重なトランザクション確認、独立した金融調査に代わるものではありません。