Bewertungen

ERC223 - vorgeschlagenes ERC20-Upgrade

Die 375K Gründe für die Verbesserung von ERC20

Mit ERC20-Token-basierten Molochern wie EOS, Basic Attention Token (BAT) und Storj ist es schwierig, den Erfolg des Schnittstellenvertrags zu diskutieren. Die Ethereum-Community hat die Unterstützung rund um diesen Standard deutlich erhöht, und sowohl die Entwicklergemeinschaften als auch die Finanzmärkte reagieren positiv. Trotz seines Erfolgs hat der ERC20-Standard zu einem nicht unerheblichen Fehler geführt:

Der ERC20-Token-Standard führt zu Geldverlusten für Endbenutzer, indem Benutzern ermöglicht wird, ERC20-Token an nicht-ERC20-kompatible Token-Adressen zu senden.

Wenn ein Benutzer ein ERC20-Token an einen Ethereum-Vertrag sendet, der ERC20-Tokens nicht erkennt, verliert der Benutzer für immer den Zugriff auf sein Geld. Genau wie viele Fonds sind derzeit aufgrund dieses Problems gesperrt? Auch hier keine unbedeutende Menge:

  • 310, 067 GNT stecken im Golem-Vertrag fest (derzeit im Wert von etwa 217.000 $).
  • 242 REP stecken im Augur-Vertrag fest (derzeit im Wert von ca. 15.000 $).
  • 814 DGD stecken im Digix DAO-Vertrag (derzeit im Wert von ca. 125.000 $).
  • 14, 506 1ST stecken im FirstBlood-Vertrag (derzeit etwa 12.000 $).

Dies ist über eine satte $ 370K + ERC20 Token, die in diesen Verträgen eingefroren sind ; Da die Liste der ERC20-Tokens wächst, ist diese Zahl wahrscheinlich eine konservative Unterschätzung der Gesamtmenge dieser in Kontrakten eingefrorenen Token. Die obige Liste ist keineswegs erschöpfend - dies sind nur einige der beliebtesten ERC20-Token.

Keiner der oben genannten Verträge hat jemals erwartet, dass ERC20-Token empfangen werden. Wenn Benutzer Tokens an diese Adressen senden, werden die Transaktionen vom Netzwerk bestätigt. Der Empfangsvertrag erkennt die Token jedoch nicht. Es weiß nicht, was mit diesen Token zu tun ist, was dazu führt, dass die Gelder für immer gesperrt werden. Auch hier werden die Token nicht abgelehnt - sie werden vom empfangenden Vertrag einfach ignoriert.

Die meisten dieser Transaktionen werden unbeabsichtigt von Endbenutzern ausgeführt, die die Funktion transfer aufrufen (im Gegensatz zur zuvor eingeführten automatisierten Funktion transferFrom). Erinnern Sie sich, dass ERC20 sowohl Transfer & TransferFrom verwendet - wie sich herausstellt, dass einige Endbenutzer Transfer verwenden, um ERC20-Token direkt an Verträge zu senden, die die eingehenden Token nicht erwarten und daher nicht erkennen.

Schließlich beschlossen einige Mitglieder der Ethereum-Community, dieses Problem direkt anzugehen, indem sie einen neuen ERC-Token-Standard forderten. Die Ausgabenummer dieses neuen Tokenstandards auf GitHub ist die Ausgabenummer 223.

ERC223-Vorschlag

GitHub-Benutzer Dexaran hat am 5. März 2017 einen neuen ERC-Standard (ERC223) vorgeschlagen, mit dem das Problem mit dem Token-Fallback-Fehler behoben werden soll.Der Abstract für den neuen Token-Vorschlag des GitHub-Problems Nr. 223 lautet wie folgt:

Im Folgenden werden Standardfunktionen eines Token-Vertrags und eines mit dem angegebenen Token arbeitenden Vertrags beschrieben, um versehentliches Senden von Token an Verträge zu verhindern und Token-Transaktionen wie Ether zu verhalten Transaktionen.

Der Token-Vorschlag von Dexaran implementiert zwei Kernfunktionen, um dezentrale App-Benutzer daran zu hindern, versehentlich Tokens an Smart Contracts zu senden, die diese Token nicht empfangen können:

  1. Konsolidierung des ERC20 Transfer & TransferFrom funktioniert in einer einzigen Transfer -Funktion mit drei Parametern: (Adresse _to, Uint_value, Bytes Daten).
  2. Der empfangende Vertrag, wenn er Token empfängt, muss eine TokenFallBack -Funktion enthalten, die genau definiert, wie mit welchem ​​Typ von eingehenden Token umzugehen ist.

Transfer & TransferFrom -> Transfer

Ein wichtiger Teil des ERC20-Standards, der zu diesem häufigen Problem beiträgt, ist die Tatsache, dass Endbenutzer irrtümlicherweise eine der beiden Funktionen zum Übertragen verwenden (Transfer & TransferFrom).

ERC223 schlägt vor, beide Funktionen durch eine einzige Transfer -Funktion zu ersetzen.

Der ERC223 ermöglicht es Dapp-Endbenutzern, Tokens mit derselben Übertragungsfunktion an beliebige Ethereum-Adresse zu senden, unabhängig davon, ob der Vertrag eine Wallet oder ein Vertrag ist. Die Logik hier ist, dass durch die Eliminierung der Option für Benutzer, eine Transfer-Funktion oder eine TransferFrom-Funktion auf nur eine einzige Transfer-Funktion auszulösen, Endbenutzer nicht mehr die Möglichkeit haben, die falsche Funktion zu verwenden.

Die neu vorgeschlagene Übertragungsfunktion akzeptiert drei Parameter (bisher nur zwei akzeptiert) und, was noch wichtiger ist, sie sucht nach einer TokenFallback-Funktion für die Empfangsadresse. Ohne die drei definierten Parameter kann die Transfer-Funktion nicht kompiliert werden; Ohne die Empfängeradresse, die eine TokenFallback-Funktion enthält, schlägt die Übertragungsfunktions-Transaktion fehl und es werden keine Token übertragen.

Funktion tokenFallBack ()

In der Ethereum-Entwicklung gibt es einen Vertragsmodifikator zahlbar , der verwendet wird, um einen Vertrag für den Empfang von Ether vorzubereiten - das heißt, ein Vertrag erwartet nun die digitale Währung. Wenn ein Vertrag nicht enthält, wird die gesendete Transaktion einfach storniert und zurückgegeben. Nichts Schickes, das ist Ethereum 101.

Eine analoge Denkweise über die ERC223 tokenFallback-Funktion ist, dass der zahlbare Modifikator einen Vertrag zum Empfang von Ether vorbereitet, da die tokenFallback-Funktion einen Vertrag zum Empfang eines x-Tokens vorbereitet.

In diesem Standard müssen Vertragsentwickler tokenFallback implementieren, wenn ihre Verträge mit bestimmten Tokens arbeiten sollen. Wenn es sich bei dem Empfänger um eine Nicht-Vertragsadresse handelt, wird eine ERC223-Token-Transaktion genau wie jede aktuelle ERC20-Token-Übertragung ausgeführt. Wenn der Empfänger andererseits ein Vertrag ist, versucht der ERC223-Token-Vertrag zuerst, tokenFallback auf dem Empfängervertrag aufzurufen; Wenn keine tokenFallback-Funktion gefunden wird, schlägt die Transaktion fehl.

Evolution von ERC

Trotz des Rohentwurfsstatus von ERC223 steht ein weiterer ERC-Standard am Horizont - ERC 721. ERC721 konzentriert sich auf nicht-fungible Assets wie CryptoKitties, Decentraland Land, & vielleicht sogar eintägige Immobilien. ERC 721 Fortschritt kann hier gefunden werden: // github. com / ethereum / eips / issues / 721

Alles, um zu zeigen, dass die Ethereum-Community in jungen Jahren sehr ernsthaft daran interessiert ist, ihre intelligente Vertragsplattform zu verbessern, indem sie die richtigen Standards vor einer wachsenden Welle neuer Entwickler setzt. Langsam aber sicher werden ERC-Token-Bugs abnehmen - und dann wird sich die Frage stellen, kann die aktuelle Standardskala?

Ähnliche