ERC20を改善するための375Kの理由
EOS、Basic Attention Token（BAT）、StorjなどのERC20トークンベースのジャガーノートでは、インターフェース契約の成功について議論するのは困難です。イーサリアムコミュニティは、この標準を中心に明確に支持を集めています, & 開発者コミュニティと金融市場の両方が前向きに反応しています。ただし、その成功のすべてについて、ERC20標準は1つのそれほど重要ではないバグをもたらしました。
ERC20トークン標準は、ユーザーがERC20トークンを非ERC20準拠のトークンアドレスに送信できるようにすることで、エンドユーザーの金銭的損失につながります。.
ユーザーがERC20トークンを認識しないイーサリアム契約にERC20トークンを送信すると、ユーザーは自分の資金に永久にアクセスできなくなります。この問題のために現在ロックされているファンドの正確な数は？繰り返しますが、取るに足らない量ではありません：
- 310,067 GNT ゴーレム契約で立ち往生している（現在約21万7000ドルの価値がある）.
- 242 REP Augur契約で立ち往生している（現在約15,000ドルの価値がある）.
- 814 DGD Digix DAO契約で立ち往生している（現在約$ 125Kの価値がある）.
- 14,5061ST FirstBlood契約で立ち往生している（現在約$ 12Kの価値がある）.
これは、これらの契約で凍結されているERC20トークンのなんと37万ドル以上を超えています; ERC20トークンのリストが増えているため、この数は、契約で凍結されたこれらのトークンの合計量を控えめに過小評価している可能性があります。上記のリストは完全なものではありません—これらはより人気のあるERC20トークンのほんの一部です.
上記の契約はいずれもERC20トークンを受け取ることを期待していませんでした。したがって、ユーザーがこれらのアドレスにトークンを送信すると、トランザクションはネットワークによって確認されます。ただし、受信側の契約はトークンを認識しません。これらのトークンをどう処理するかわからないため、資金が永久にロックされます。繰り返しになりますが、トークンは拒否されません。受信側の契約では完全に無視されます。.
これらのトランザクションの大部分は、エンドユーザーが 転送 関数（以前に導入された自動化されたtransferFrom関数とは対照的）。 ERC20は両方の転送を利用することを思い出してください & TransferFrom —一部のエンドユーザーは、Transferを使用して、予期しない契約にERC20トークンを直接送信していることが判明しました。, & したがって、受信トークンを認識しません.
最終的に、イーサリアムコミュニティの数人のメンバーは、新しいERCトークン標準を要求することによってこの問題に正面から取り組むことを決定しました。 GitHubでのこの新しいトークン標準の発行番号は、発行番号＃223です。.
ERC223提案
GitHubユーザーのDexaranは、2017年3月5日に、このトークンフォールバックの失敗の問題を修正することを目的とした新しいERC標準（ERC223）を提案しました。彼のGitHub問題＃223の新しいトークン提案の要約は次のとおりです。
Dexaranのトークン提案は、分散型アプリのユーザーがトークンを受け取る準備ができていないスマートコントラクトに誤ってトークンを送信するのを即座に防ぐために、2つのコア機能を実装しています。
- ERC20の統合 転送 & からの転送 単一に機能します 転送 3つのパラメータを持つ関数:(アドレス_to、uint _value、バイトデータ）.
- ザ・ 受信 トークンを受け取る場合は契約, しなければならない を含む TokenFallBack どのタイプの着信トークンを処理するかを正確に定義する関数.
転送 & からの転送 -> 転送
この一般的な問題の原因となるERC20標準の重要な部分は、エンドユーザーが転送に使用される2つの機能のいずれかを誤って使用するオプションを持っているという事実です（転送 & からの転送）.
ERC223は、両方の機能を1つに置き換えることを提案しています 転送 関数.
ERC223を使用すると、dappエンドユーザーはにトークンを送信できます。 どれか その契約がウォレットであるか契約であるかに関係なく、同じ伝達関数を持つイーサリアムアドレス。ここでのロジックは、ユーザーが伝達関数をトリガーするオプションを削除することによってです または TransferFrom関数を単一のTransfer関数に変更すると、エンドユーザーは誤った関数を使用する可能性がなくなります。.
新しく提案された伝達関数は、3つのパラメーター（以前は2つしか受け入れられなかった）を受け入れ、さらに重要なことに、受信アドレスでTokenFallback関数を呼び出すように見えます。 3つの定義されたパラメーターがないと、伝達関数はコンパイルに失敗します。 TokenFallback関数を含む受信アドレスがないと、伝達関数トランザクションは失敗します & トークンは転送されません.
関数tokenFallBack（）
イーサリアムの開発には、契約修飾子が存在します 支払い可能 これは、Etherを受け取るための契約を準備するために使用されます。これは、契約が現在デジタル通貨を期待していることを意味します。契約がある場合 ない 支払い可能な修飾子が含まれている場合、送信されたトランザクションは単にキャンセルされます & 戻ってきた。特別なことは何もありません、これはイーサリアム101です.
ERC223 tokenFallback関数についての同様の考え方は、tokenFallback関数がxトークンを受け取るためのコントラクトを準備することであるため、支払い可能な修飾子がEtherを受け取るためのコントラクトを準備することであるということです。.
この標準では、契約開発者 しなければならない コントラクトを特定のトークンで機能させる場合は、tokenFallbackを実装します。受信者が非契約アドレスの場合、ERC223トークントランザクションは、現在のERC20トークン転送と同じように実行されます。一方、レシーバーがコントラクトの場合、ERC223トークンコントラクトは最初にレシーバーコントラクトでtokenFallbackを呼び出そうとします。 tokenFallback関数が見つからない場合、トランザクションは失敗します.
ERCの進化
ERC223のドラフト状態は大まかなものですが、もう1つのERC標準が間近に迫っています—ERC721。ERC721は 代替不可能 CryptoKitties、Decentraland土地などの資産, & おそらく一日の不動産資産ですら。 ERC 721の進捗状況は、次のとおりです。 https://github.com/ethereum/eips/issues/721
イーサリアムコミュニティは、若いうちに、成長する新しい開発者の波の前に適切な標準を配置することで、スマートコントラクトプラットフォームの改善に真剣に取り組んでいることを示しています。ゆっくりと、しかし確実に、ERCトークンのバグは減少します—そして問題は最新の標準スケールになります?
