あなたはおそらくいくつかのトークンセールによって配布されたカップルを所有しているので、ERC20トークンに精通しています。しかし、ERC20以外にももっと多くの規格が存在することをご存知ですか?イーサリアムには、開発された標準の長い歴史があります.
ERCの意味をよりよく理解するために、「Ethereum RequestforComment」の略です。これは、実際の基準に対する議論と提案のために提出された提案です。番号(20など)は、コード共有プラットフォームの問題番号を示します Github. まず、ERC20規格を見てみましょう.
ERC20規格
ERC20規格とは正確には何ですか?
ERC20トークンの出現は、暗号通貨市場に革命をもたらし、多数の ICO暗号通貨 ERC20コードは、2017年に世界が目撃したプロジェクトです。2015年に導入されたERC20コードは、特定のイーサリアムベースのトークンが展開する必要のあるルールの特定のリストの概要を示し、イーサリアムのブロックチェーンでトークンの機能をプログラミングするプロセスを簡素化します。基本的に、ERC20トークンは、イーサリアムのブロックチェーンを利用する特別な形式のスマートコントラクトです.
ERC20トークンの最も顕著な例には、Bancor、EOS、Tronix、BNB、VeChain、およびBankexが含まれます。.
イーサリアムトークンのERC20標準が革新される前は、コーダーはトークンを開発してイーサリアムのネットワーク上で起動するための特定の実装標準を作成する必要がありました。それにもかかわらず、ERC20トークンコードは、合理化されたプロトコルとスマートコントラクト標準のおかげで、トークンの作成プロセスを簡素化しました。 ERC20コードは、トークンのスマートコントラクトの実装に関連する複雑さを軽減し、トークンのコントラクトを破る可能性を大幅に減らしました.
2018年4月現在、 66,468ERC20トークン契約, ERC20標準によって提供されるトークンコードの統一性のおかげで、暗号通貨取引所が取引プラットフォームにさまざまなトークンを簡単にリストできるようになりました。このように、ERC20標準は、暗号コミュニティがそのような膨大な数のイーサリアムベースのトークンに関連する可能性のある流動性の問題を克服するのに役立ちました.
ERC20トークン関数:
ERC20コードは、トークンの6つの特定の関数の概要を示しています。
1-を介してトークンの総供給量を取得する "totalSupply" 関数
2-に関連付けられている別のアカウントのトークン残高を取得する "_オーナー" 経由のアドレス " balanceOf(address _owner)定数は収穫逓減(uint256バランス)" 関数.
3-特定の量のトークンを送信する "_値" 経由で指定されたアドレスに " transfer(address _to、uint256 _value)は(ブール成功)を返します" 関数.
4-特定の量のトークンを送信する "_値" あるトークン(契約)アドレスから別のトークン(契約)アドレスへ "transferFrom(address _from、address _to、uint256 _value)は(ブール成功)を返します" 関数.
5-特定のアカウントが自分のアカウントからトークンを繰り返し引き出すことができるようにすると同時に、引き出すトークンの量の上限を事前に定義します。 "_値" パラメータ。これは、 "approve(address _spender、uint256 _value)は(ブール成功)を返します". 引き出しの上限、つまり "_値" パラメータ、関数が呼び出されたときに上書きできます.
6-トークンの残りの量を、によって使用できる上限で定義された事前設定された量の範囲内で返す "_spender" アカウントから撤退する "_オーナー". これは、 "allowance(address * _owner *、address * _spender *)定数は収穫逓減(uint256残り)" 関数.
ERC20コードで定義されているこれらの6つの関数は、これらのトークンが異なるアカウント間で転送される方法や、ユーザーが特定のERC20トークンに関連付けられたデータを取得する方法など、基本的な機能の問題を表しています。これらの機能グループは、イーサリアムベースのトークンがイーサリアムのプラットフォームのどの部分でも同様に機能することを保証するために規定されています。そのため、イーサコインに準拠するすべての暗号ウォレットは、ERC20標準に基づくトークンもサポートします.
重大なバグ:
ERC20 イーサリアムの最初のトークン標準です。新しいコードでよくあることですが、いくつかのバグや論理的な間違いが含まれています。 ERC20は、トークントランザクションを実行する2つの方法を想定しています。まず、転送機能を使用すると、誰かのアドレスにトークンを送信できます。スマートコントラクトにトークンを入金する場合は、「承認+転送元」の組み合わせを使用する必要があります。承認機能を介してトークンを引き出すには、この契約を承認する必要があります。次に、transferFrom関数を介して預金を処理し、トークンを引き出す契約の関数を呼び出す必要があります.
転送機能を備えた契約に誤ってトークンを預けた場合はどうなりますか?トランザクションは成功しますが、このトランザクションは受信者の契約によって認識されません。たとえば、分散型交換契約にトークンを送信すると、交換契約はトークンを受け取りますが、このトークンは交換トークンの残高にクレジットされません。さらに、分散型交換契約が緊急トークン抽出機能を実装していない場合、どのような場合でもトークンを取り戻すことは不可能であり、トークンが永久に失われます。このバグのために、イーサリアムのエコシステムはすでに数百万ドルを失っています.
なぜまだERC20標準を使用しているのですか?
Redditユーザー u / Dexaran, ERC223標準の作成者は、前述のバグについてコミュニティに通知した最初の開発者の1人です。この重大なバグについて知っていても、ERC20がまだ広く使用されている理由を彼に尋ねました。彼は次の理由を挙げました:
- トークン開発者の行為に対する刑事上の無責任のため.
- イーサリアム財団は、バグが含まれていることがわかっている場合でも、ERC20トークン標準を引き続き推進しているためです。以前のTheDAOと同じ状況。彼らは言う必要があります "今これをやめなさい" しかし、彼らはしません.
- トークン開発の主な理由は、製品の作成ではなく、資金の獲得であるためです.
- 別の標準を使用すると、ネットワーク効果が高くなるためです。イーサリアムネットワークにはすでにスケーラビリティの問題があることを考えると、これは私たちが本当に必要としているものではありません.
ERC223標準
ザ・ ERC223 標準は、この記事の作成を支援したu / Dexaranによって提案されました。 ERC223は、トークン転送がエーテルトランザクションとまったく同じように動作することを可能にするトークン標準です。 ERC223は、イベント処理(トランザクションをイベントと見なす)を利用して、未処理のトランザクションでトークンが失われるのを防ぎます。この改善された標準は、転送機能が無効な転送でエラーをスローし、トランザクションをキャンセルして資金が失われないようにすることで、ERC20の重大なバグを解決します。要するに、ERC223はに焦点を当てています セキュリティ.
追加と問題
ERC223は、伝達関数にデータパラメータを追加して、単なるトークン転送よりも複雑な操作を可能にします。.
Dexaranの主な懸念は、前述のように承認メソッドやtransferFromメソッドではなく、転送関数を使用してトークンをコントラクトに送信することでトークンを失う可能性があることです。彼の解決策は、転送方法を変更して、受信アドレスが契約であるかどうか(つまり、データが含まれているかどうか)を確認することです。コントラクトの場合は、それをコールバックするtokenFallback関数があると想定します。主な弱点は、tokenFallbackが存在しない場合、受信側のコントラクトのフォールバック関数が呼び出され、送信されたトークンが失われる可能性があることです。.
ERC777標準
ERC777 は、ERC820(契約疑似イントロスペクションレジストリ)に依存し、イーサリアムエコシステムから数百万ドルの損失をもたらしたトランザクション処理メカニズムの欠如などのERC20の問題を解決しようとする新しい代替可能なトークン標準です。要するに、ERC777は焦点を当てています 可決 提供することによって 幅広いトランザクション処理メカニズム.
利点
ERC777の主な利点は、コントラクトインターフェイスを認識する新しい方法を使用することです。この標準は、イーサリアムのネットワーク上に契約の中央レジストリがあることを前提としています(これはERC820で定義されています)。誰でもこのレジストリを呼び出して、特定のアドレス(このアドレスが契約であるかどうかは関係ありません)が特定の機能セット、つまり「インターフェイス」をサポートしているかどうかを知ることができます。.
イーサリアムの主な問題の1つは、契約がどの機能を実装しているかを知ることができないことです。 ERC820はこれを解決することを目的としています。 ERC777はこのアプローチを利用しています。これは間違いなく良い考えです。.
一方、ERC20のデフォルト関数をオーバーライドなしで新しいERC777関数と一緒に実装するトークンを作成できます(オプションでERC20の重大なバグを継承します)。これにより、この新しいトークン標準の優れたネットワーク効果とより迅速な採用が保証されます。実践が示すように、トークン開発者の主な目標は、トークンを取引所にプッシュする必要があることを前提とした資金を調達することです。新しいトークン標準の新しい機能に関する調査を行わなくても、取引所がレガシーERC20関数を実装するトークンをサポートする方が簡単です(これらの関数にバグが含まれているかどうかは関係ありません)。取引所が新しい標準でトークンをサポートするのが簡単であるほど、より多くの開発者がそれを使用します。これによりERC777の採用が促進されますが、ERC223にはこの特性がありません。.
何が違うの?
このトークン標準は、完全に新しい関数のセット、つまり「伝達」関数の代わりに「送信」関数を定義します。 `approve`の代わりに` authoriseOperator`。 `tokenFallback`ハンドラー関数の代わりに` tokensReceived`ハンドラー関数.
このようなアプローチにより、この標準の機能が他のトークン標準の機能と交差してオーバーライドされないことが保証されるため、ERC777およびERC820標準と同時に互換性のあるトークンを作成することができます。.
ついにERC777が標準化 ミントアンドバーン トークンの機能.
障害点とセキュリティ上の懸念
ERC777は、誰かがあなたに代わってトークンを管理できるようにする `authoriseOperator`関数を実装しています。 Dexaranは、この方法は非推奨であり、使用すべきではないと考えていると説明しました。さらに、誰かにあなたに代わってトークンを管理する権限を与えると、ネットワークの帯域幅が損なわれ、より多くのガスが必要になります。 `authoriseOperator`はすでに1つのトランザクションを表しており、実行するには別のトランザクションが必要です "許可された撤退". したがって、1つのトランザクションで実行できる転送を実行するには、2つのトランザクションが必要です。.
次に、ERC777標準には、ITokenRecipientインターフェイスに関するいくつかのチェックを実行してトークンのスタックを防止し、アドレスがホワイトリストに登録されているかどうかをチェックするオプションのフラグが含まれています。この標準は、数百万ドル相当のトークンを処理するネットワークのセキュリティに焦点を合わせているため、これらのチェックをオプションにするのは良いことではありません。.
その他の基準
のような他の多くの標準があります ERC827 これは、ERC223のいくつかの利点とレガシーERC20機能を組み合わせたものです。ザ・ ERC664 標準は、トークン標準のモジュール性に焦点を当てています。この標準では、トークンコントラクトをアップグレードできますが、ERC20の重大なバグを継承しています。他の規格にはERC721、ERC677、ERC820が含まれますが、あまり知られていません。.
標準間の互換性
Dexaranに、どの標準に下位互換性があるかを尋ねました。彼は、最初に「下位互換性」の意味を理解する必要があると述べました。「下位互換性は、古いレガシーシステム、またはそのようなシステム用に設計された入力との相互運用を可能にするシステム、製品、またはテクノロジーの特性です。」
ERC20 & ERC223: ERC223トークンはERC20と互換性があります。 ERC20で適切に機能するように設計されたもの(ウォレットなど)はすべて、ERC223でも機能します。ここでの唯一の例外は、approve + transferFromトークンデポジットパターンに依存している契約です。ただし、現在標準に含まれていない場合でも、ERC223トークンを使用して承認+ transferFrom関数を実装することは可能です。スマートコントラクトではないウォレットやサードパーティのサービスについては、ERC20トークンの入力通話データがERC223に対して有効であるため、ERC223を自動的にサポートします。.
ERC20 & ERC777:ERC777提案の「下位互換性」セクションに次のステートメントがあります。「このEIPは下位互換性を導入せず、古いERC-20トークン標準と互換性があります。」
ただし、Dexaranは正反対のことを教えてくれ、次の例を示しました。「MetaMask、Mist、MyEtherWalletなどのウォレットとサービスはERC20トークンを処理しています。 ERC20トークン用に設計された入力は、エンコードされたパラメーターと関数シグネチャを含むコントラクト呼び出しです。イーサリアム仮想マシンの関数呼び出しは、トランザクションで送信されるデータの最初の4バイトによって指定されます。これらの4バイトの署名は、関数署名の正規表現のハッシュの最初の4バイトとして定義されます。これは、 `transfer(address、uint256)`関数と `send(address、uint256)`関数の署名が異なることを意味します。その結果、ERC20トークン用に設計された入力は、ERC777トークンでは無効になります。」下位互換性の定義を使用しているため、ERC777はERC20トークン標準と互換性がありません.
どの規格をいつ使用するか
ERC20: Redditユーザーのu / Dexaranは、「バグのために投資家にお金を失ってもらいたいとき」という皮肉なアドバイスをくれました。
ERC223: このトークン標準は、ERC777と一緒に使用することもできます。 ERC777には、ERC223にはないエレガントな機能がいくつかありますが、ERC223のロジックは、ERC777と比較して単純であり、多くの機能を備えていることが保証されます。 エラーが発生しにくいコード. さらに、ERC223は中央サービスに依存していません。つまり、ERC223トークンは独自の実装にのみ依存します。前述したように、ERC223はセキュリティの向上を目的としていますが、これによりERC223トークンがERC20標準に準拠しなくなりました.
ERC777: このトークン標準はすでに使用可能です。一方、ERC777には、前述のようにセキュリティ上の懸念がいくつかあります。また、セキュリティ上の懸念事項である中央契約レジストリにも依存しています。中央レジストリは開発者の作業を楽にすることができますが、ParityMultisigの場合とまったく同じように障害の中心点としても機能します。すべてのパリティマルチシグは、中央のコードライブラリに依存していました。ライブラリにバグがあり、それが悪用されたことがありました。その結果、すべてのパリティマルチシグがクラッシュしました。さらに、ERC777は新しい関数のセットを定義します。これは、トークン開発者が採用のために、トークンをERC20とERC777の両方の標準と同時に互換性を持たせることを可能にする試みです。これは、開発者がERC777のERC20のバグを継承できることを意味しますが、開発者はより多くのトランザクション処理イベントを使用できます。.
一般に:すべてのトークンには、同様のユースケース(ICO)があります。 ERC223とERC777は、ERC20の1つの問題をさまざまな方法で解決しようとしていると言えます。 ERC223はすでにそのニッチを取っています イーサリアムクラシック ERC20の代わりに.
この記事は、ERC223開発者であるDexaranの助けを借りて作成されました。イーサリアムのトークン標準に関するPaulEdgeのコメントの一部も使用されました.