ERC223 – Voorgestelde ERC20-upgrade

De 375K redenen om ERC20 te verbeteren

Met op ERC20-token gebaseerde juggernauts zoals EOS, Basic Attention Token (BAT) en Storj, is het moeilijk om het succes van het interfacecontract te beargumenteren. De Ethereum-gemeenschap heeft duidelijk steun verzameld rond deze standaard, & zowel ontwikkelaarsgemeenschappen als financiële markten reageren positief. Ondanks al zijn succes heeft de ERC20-standaard echter geresulteerd in een niet zo onbelangrijke bug:

De ERC20-tokenstandaard leidt tot geldverlies voor eindgebruikers doordat gebruikers ERC20-tokens kunnen verzenden naar niet-ERC20-compatibele tokenadressen.

Wanneer een gebruiker een ERC20-token naar een Ethereum-contract stuurt dat ERC20-tokens niet herkent, verliest de gebruiker voor altijd de toegang tot zijn of haar geld. Precies hoeveel fondsen zijn momenteel vergrendeld vanwege dit probleem? Nogmaals, niet een onbeduidend bedrag:

• 310.067 GNT zitten vast in het Golem-contract (momenteel ongeveer $ 217K waard).
• 242 REP zitten vast in Augur-contract (momenteel ongeveer $ 15K waard).
• 814 DGD zitten vast in het Digix DAO-contract (momenteel ter waarde van ongeveer $ 125K).
• 14.506 1e zitten vast in het FirstBlood-contract (momenteel ongeveer $ 12K waard).

Dit is meer dan maar liefst $ 370K + aan ERC20-tokens die in deze contracten zijn bevroren​aangezien de lijst met ERC20-tokens groeit, is dit aantal waarschijnlijk een conservatieve onderschatting van het totale aantal van deze tokens dat in contracten is bevroren. De bovenstaande lijst is zeker niet uitputtend – dit zijn slechts enkele van de meer populaire ERC20-tokens.

Geen van de bovenstaande contracten had ooit verwacht ERC20-tokens te ontvangen – dus wanneer gebruikers tokens naar deze adressen sturen, worden de transacties bevestigd door het netwerk; het ontvangende contract herkent de tokens echter niet. Hij weet niet wat hij met deze tokens moet doen, waardoor het geld voor altijd wordt vergrendeld. Nogmaals, de tokens worden niet afgewezen – ze worden gewoon volledig genegeerd door het ontvangende contract.

De meeste van deze transacties worden onbedoeld gepleegd door eindgebruikers die het overdracht functie (in tegenstelling tot de eerder geïntroduceerde automatische transferFrom-functie). Bedenk dat ERC20 gebruik maakt van beide Transfer & TransferFrom – het blijkt dat sommige eindgebruikers Transfer gebruiken om ERC20-tokens rechtstreeks naar contracten te sturen die niet verwachten, & Herken daarom de inkomende tokens niet.

Uiteindelijk besloten een paar leden van de Ethereum-gemeenschap dit probleem rechtstreeks aan te pakken door een nieuwe ERC-tokenstandaard aan te vragen. Het nummer van deze nieuwe tokenstandaard op GitHub is nummer # 223.

ERC223 Voorstel

GitHub-gebruiker Dexaran stelde op 5 maart 2017 een nieuwe ERC-standaard (ERC223) voor om dit probleem met de terugval van tokens op te lossen. Het abstract voor zijn GitHub-probleem # 223 nieuw tokenvoorstel is het volgende:

Het volgende beschrijft de standaardfuncties die een tokencontract en een contract dat met het opgegeven token werkt, kunnen implementeren om te voorkomen dat per ongeluk tokens naar contracten worden verzonden en dat token-transacties zich gedragen als ethertransacties.

Het tokenvoorstel van Dexaran implementeert twee kernfuncties om te voorkomen dat gedecentraliseerde app-gebruikers per ongeluk tokens verzenden naar slimme contracten die niet klaar zijn om de tokens te ontvangen:

1. Consolidering van de ERC20 Overdracht & TransferFrom functies in een enkele Overdracht functie met drie parameters: (adres _to, uint _value, bytes data).
2. De ontvangen contract, als u tokens ontvangt, moet bevatten een TokenFallBack functie die precies definieert hoe om te gaan met welk type inkomend token.

Overdracht & TransferFrom -> Overdracht

Een belangrijk onderdeel van de ERC20-standaard dat bijdraagt ​​aan dit veelvoorkomende probleem is het feit dat eindgebruikers de mogelijkheid hebben om ten onrechte een van de twee functies te gebruiken die worden gebruikt om (Transfer & TransferFrom).

ERC223 stelt voor om beide functies te vervangen door één Overdracht functie.

Met de ERC223 kunnen dapp-eindgebruikers tokens sturen naar ieder Ethereum-adres, ongeacht of dat contract een portemonnee of een contract is, met dezelfde overdrachtsfunctie. De logica hier is dat door het elimineren van de mogelijkheid voor gebruikers om een ​​overdrachtsfunctie te activeren of een TransferFrom-functie naar slechts één enkele Transfer-functie, eindgebruikers hebben niet langer het potentieel om de verkeerde functie te gebruiken.

De nieuw voorgestelde overdrachtsfunctie accepteert drie parameters (voorheen slechts twee), en wat nog belangrijker is, het lijkt erop dat het een TokenFallback-functie op het ontvangende adres aanroept. Zonder de drie gedefinieerde parameters kan de overdrachtsfunctie niet worden gecompileerd; zonder dat het ontvangende adres een TokenFallback-functie bevat, zal de overdrachtsfunctie-transactie mislukken & er worden geen tokens overgedragen.

functie tokenFallBack ()

Bij de ontwikkeling van Ethereum bestaat er een contractmodifier te betalen dat wordt gebruikt om een ​​contract voor te bereiden om Ether te ontvangen – dit betekent dat een contract nu de digitale valuta verwacht. Als een contract dat doet niet de te betalen modifier bevatten, wordt de verzonden transactie eenvoudig geannuleerd & keerde terug. Niets bijzonders, dit is Ethereum 101.

Een analoge manier van denken over de ERC223 tokenFallback-functie is dat de te betalen modifier is om een ​​contract voor te bereiden om Ether te ontvangen, aangezien de tokenFallback-functie is om een ​​contract voor te bereiden om x-token te ontvangen.

In deze standaard contractontwikkelaars moet implementeren tokenFallback als ze willen dat hun contracten werken met specifieke tokens. Als de ontvanger een niet-contractadres is, wordt een ERC223-tokentransactie uitgevoerd, net als elke huidige ERC20-tokenoverdracht. Aan de andere kant, als de ontvanger een contract is, zal het ERC223-tokencontract eerst proberen tokenFallback op het ontvangercontract aan te roepen; als er geen tokenFallback-functie wordt gevonden, zal de transactie mislukken.

Evolutie van ERC

Ondanks de ruwe diepgang van ERC223, doemt een andere ERC-standaard op: ERC 721. ERC721 richt zich op niet-vervangbaar activa zoals CryptoKitties, Decentraland land, & misschien zelfs eendags onroerend goed. De voortgang van ERC 721 is hier te vinden: https://github.com/ethereum/eips/issues/721

Allemaal om te laten zien dat de Ethereum-gemeenschap, hoewel jong, zeer serieus bezig is met het verbeteren van zijn slimme contractplatform door de juiste normen voor een groeiende golf van nieuwe ontwikkelaars te stellen. Langzaam maar zeker zullen ERC-token-bugs afnemen – en dan wordt de vraag de nieuwste standaardschaal?