Ni känner alla till ERC20-tokens eftersom ni förmodligen äger ett par, distribuerade av någon form av token-försäljning. Men visste du att det finns många fler standarder förutom ERC20? Ethereum har en lång historia av utvecklade standarder.

För att ge dig en bättre uppfattning om vad ERC betyder, står det för “Ethereum Request for Comment”. Detta är ett förslag som läggs fram för diskussion och förslag till den faktiska standarden. Siffran (som 20) hänvisar till ett nummer på koddelningsplattformen Github. Låt oss först ta en titt på ERC20-standarden.

ERC20-standard

Vad är ERC20-standarden exakt?

Tillkomsten av ERC20-tokens revolutionerade kryptovalutamarknaden och öppnade dörren till överflödet av ICO-kryptovaluta projekt som världen har bevittnat under 2017. Infördes 2015 visar ERC20-koden en specifik lista med regler som en given Ethereum-baserad token måste distribuera, vilket förenklar processen för programmering av tokensfunktioner på Ethereums blockchain. I grund och botten är ERC20-tokens speciella former av smarta kontrakt som använder Ethereums blockchain.

De mest framträdande exemplen på ERC20-tokens inkluderar Bancor, EOS, Tronix, BNB, VeChain och Bankex.

Innan innovationen av ERC20-standarden för Ethereum-tokens var kodarna tvungna att skapa specifika implementeringsstandarder för att utveckla en token och starta den i Ethereums nätverk. Ändå har ERC20-token-koden förenklat processen att skapa tokens, tack vare ett strömlinjeformat protokoll och smarta kontraktsstandarder. ERC20-koden lindrade komplexiteten i samband med implementeringen av tokens smarta kontrakt, vilket avsevärt minskade möjligheten att bryta tokens kontrakt.

Från och med april 2018 finns det 66 468 ERC20-tokenavtal, tack vare enhetligheten av token-kod som tillhandahålls av ERC20-standarden, vilket gjorde det enkelt för kryptovalutabörser att lista olika tokens på sina handelsplattformar. Som sådan har ERC20-standarden hjälpt kryptosamhället att övervinna likviditetsproblem som kunde ha associerat ett så enormt antal Ethereum-baserade tokens.

ERC20-tokenfunktioner:

ERC20-koden beskriver sex specifika funktioner för tokens, vilka är

1- Få det totala utbudet av tokens via "totalförsörjning" fungera

2- Hämta tokensaldot för ett annat konto som är associerat med "_ägare" adress via " balanceOf (address _owner) konstant returnerar (uint256-saldo)" fungera.

3- Skicka en viss mängd tokens "_värde" till en given adress via " överföring (adress _to, uint256 _value) returnerar (bool framgång)" fungera.

4- Skicka en viss mängd tokens "_värde" från en token (kontrakt) adress till en annan token (kontrakt) adress via "transferFrom (address _from, address _to, uint256 _value) returnerar (bool-framgång)" fungera.

5- Att möjliggöra för ett specifikt konto att dra ut tokens från sitt konto upprepade gånger, samtidigt som man fördefinierar den övre gränsen för hur många tokens som ska tas ut med "_värde" parameter. Detta kan uppnås via "godkänna (adress _spender, uint256 _värde) returnerar (bool framgång)". Den övre gränsen för uttag, dvs. "_värde" parameter, kan skrivas över när funktionen återkallas.

6- Återställa restmängden tokens, inom det förinställda beloppet som definieras av den övre gränsen som får användas av "_slösare" att ta ut från kontot för "_ägare". Detta kan utföras via "ersättning (adress * _ägare *, adress * _spender *) konstant avkastning (uint256 kvar)" fungera.

Dessa sex funktioner som definieras av ERC20-koden representerar hörnstenfunktionsproblem, som inkluderar hur dessa tokens kommer att överföras mellan olika konton och hur användare kan hämta data som är associerade med en given ERC20-token. Denna grupp av funktioner ordineras för att säkerställa att Ethereum-baserade tokens fungerar på samma sätt inom någon del av Ethereums plattform. Som sådan kommer alla kryptoplånböcker som är kompatibla med etermyntet också att stödja tokens baserade på ERC20-standarden.

Kritisk bugg:

ERC20 är den första token-standarden för Ethereum. Som ofta är fallet med ny kod innehåller den några buggar eller logiska misstag. ERC20 antar två sätt att utföra en token-transaktion. Först och främst låter överföringsfunktionen dig skicka tokens till någons adress. Om du vill sätta in tokens till ett smart kontrakt bör du använda kombinationen ”godkänn + överföringFrom”. Du bör auktorisera detta avtal att dra tillbaka dina tokens via godkännandefunktionen. Sedan måste du ringa en funktion i ett kontrakt som hanterar din insättning och tar ut dina tokens via transferFrom-funktionen.

Vad händer om du sätter in tokens av misstag till ett kontrakt med överföringsfunktionen? Transaktionen kommer att lyckas men transaktionen kommer inte att erkännas av mottagaravtalet. Till exempel, om du skickar tokens till ett decentraliserat utbytesavtal, kommer utbytesavtalet att ta emot dina tokens men det krediterar inte dessa tokens till ditt utbyte token-saldo. Dessutom, om det decentraliserade utbytesavtalet inte implementerar en nödutdragningsfunktion, är det i alla fall omöjligt att få tillbaka dina tokens, vilket resulterar i en permanent förlust av tokens. På grund av detta fel har Ethereums ekosystem redan tappat miljontals dollar.

Varför använder vi fortfarande ERC20-standarden?

Reddit-användare u / Dexaran, skapare av ERC223-standarden, är en av de första utvecklarna som meddelade communityn om det ovan nämnda felet. Vi frågade honom varför ERC20 fortfarande används så mycket, även när vi känner till detta kritiska fel. Han anförde följande skäl:

1. På grund av kriminellt oansvar från tokenutvecklare för deras handlingar.
2. Eftersom Ethereum Foundation fortfarande marknadsför ERC20-tokenstandarden även när det är känt att det innehåller buggar. Samma situation som den var med TheDAO tidigare. De måste säga "Sluta nu" men de kommer inte.
3. Eftersom den främsta anledningen till tokenutveckling är att ta pengar, snarare än att skapa produkter.
4. Eftersom användning av en annan standard leder till högre nätverkseffekter. Det här är inte vad vi verkligen behöver med tanke på att Ethereum-nätverket redan har skalbarhetsproblem.

ERC223-standard

De ERC223 standard föreslogs av u / Dexaran som hjälpte till att skapa den här artikeln. ERC223 är en tokenstandard som gör att tokenöverföringar kan fungera exakt som etertransaktioner. ERC223 använder händelsehantering (betraktar en transaktion som en händelse) för att förhindra att tokens går förlorade i icke hanterade transaktioner. Denna förbättrade standard löser det kritiska ERC20-felet genom att överföringsfunktionen ger ett fel vid ogiltiga överföringar och annullerar transaktionen så att inga pengar går förlorade. Kort sagt fokuserar ERC223 på säkerhet.

Tillägg och problem

ERC223 lägger till en ytterligare dataparameter i överföringsfunktionen för att möjliggöra mer komplexa operationer än bara en tokenöverföring.

Dexarans största oro är att för många människor kan förlora sina tokens genom att skicka dem till kontrakt med överföringsfunktionen, inte godkännande och transferFrom-metoderna som tidigare diskuterats. Hans lösning är att ändra överföringsmetoden för att kontrollera om den mottagande adressen är ett kontrakt (dvs. innehåller data) eller inte. Om det är ett kontrakt antar det att det finns en tokenFallback-funktion för att ringa tillbaka den. Den största svagheten är att om tokenFallback inte existerar, kommer det mottagande kontraktets reservfunktion att anropas och de skickade tokens kan fortfarande gå förlorade.

ERC777-standard

ERC777 är en ny fungibel tokenstandard som bygger på ERC820 (Contract pseudo-introspection registry) och försöker lösa ERC20: s problem, till exempel brist på transaktionshanteringsmekanismer som ledde till förlust av miljontals dollar från Ethereums ekosystem. Kort sagt fokuserar ERC777 på adoption genom att erbjuda en ett brett utbud av transaktionshanteringsmekanismer.

Fördelar

Den största fördelen med ERC777 är att den använder en ny metod för att känna igen kontraktsgränssnittet. Denna standard förutsätter att det finns ett centralt register över kontrakt i Ethereums nätverk (detta definieras i ERC820). Alla kan åberopa detta register för att veta om en viss adress (det spelar ingen roll om den här adressen är ett kontrakt eller inte) stöder en viss uppsättning funktioner, dvs `gränssnitt`.

Ett av de viktigaste problemen med Ethereum är oförmågan att veta vilka funktioner kontraktet implementerar. ERC820 är avsett att lösa detta. ERC777 utnyttjar detta tillvägagångssätt, vilket definitivt är en bra idé.

Å andra sidan kan du skapa en token som implementerar ERC20s standardfunktioner tillsammans med de nya ERC777-funktionerna utan åsidosättningar (och eventuellt ärver ERC20s kritiska fel). Detta kan garantera en bra nätverkseffekt för denna nya tokenstandard och snabbare användning. Som praxis visar är huvudmålet för tokenutvecklare att samla in pengar som förutsätter att de behöver driva sina tokens till utbyten. Det är lättare för utbyten att stödja en token som implementerar äldre ERC20-funktioner (det spelar ingen roll om dessa funktioner innehåller buggar eller inte) utan forskning om nyare funktioner för nya tokenstandarder. Ju lättare det är för utbyten att stödja tokens på en ny standard, desto fler utvecklare kommer att använda den. Detta ökar antagandet av ERC777, medan ERC223 saknar den här egenskapen.

Vad är skillnaden?

Denna tokenstandard definierar en helt ny uppsättning funktioner, dvs `skicka`-funktioner istället för` överför`-funktioner. “authoriseOperator” istället för “godkänna”. hanteringsfunktionen `tokensReceived` istället för hanteringsfunktionen` tokenFallback`.

Ett sådant tillvägagångssätt kan garantera att funktionerna i denna standard inte kommer att korsa och åsidosätta funktioner med någon annan tokenstandard, så det är möjligt att skapa en token som är kompatibel med ERC777- och ERC820-standarderna samtidigt.

Äntligen standardiseras ERC777 Mint och Burn funktionalitet av tokens.

Felpunkter och säkerhetsproblem

ERC777 implementerar funktionen ‘authoriseOperator’ som gör det möjligt för någon att hantera tokens för dina räkning. Dexaran förklarade för oss att han tycker att den här metoden är föråldrad och inte bör användas. Dessutom skadar nätverkets bandbredd att auktorisera någon att hantera tokens för dina räkning och kräver mer gas. “authoriseOperator” representerar redan en transaktion, och en annan transaktion krävs för att utföra "godkänt uttag". Så, två transaktioner krävs för att utföra en överföring som kan göras med bara en transaktion.

Därefter innehåller ERC777-standarden en valfri flagga för att förhindra fasta tokens genom att utföra vissa kontroller av ITokenRecipient-gränssnittet och för att kontrollera om adressen är vitlistad. Eftersom denna standard är inriktad på säkerheten i ett nätverk som hanterar tokens som är värda miljoner dollar, är det inte bra att göra dessa kontroller valfria.

Andra standarder

Det finns många andra standarder som ERC827 som kombinerar några fördelar med ERC223 med äldre ERC20-funktioner. De ERC664 standard fokuserar på tokenstandardens modularitet. Denna standard gör att tokenavtal kan uppgraderas, men den har ärvt ERC20-kritiskt fel. Andra standarder inkluderar ERC721, ERC677 och ERC820, men de är mindre kända.

Kompatibilitet mellan standarder

Vi frågade Dexaran vilka standarder som är bakåtkompatibla. Han berättade för oss att vi först borde förstå vad ”bakåtkompatibilitet” står för: ”Bakåtkompatibilitet är en egenskap hos ett system, en produkt eller en teknik som möjliggör interoperabilitet med ett äldre äldre system eller med ingångar utformade för ett sådant system.

ERC20 & ERC223: ERC223-tokens är kompatibla med ERC20. Allt som är utformat för att fungera korrekt med ERC20 (som plånböcker) kan också fungera med ERC223. Det enda undantaget här är kontrakt som är beroende av godkännande + överföring från insättningsmönster. Det är dock möjligt att implementera godkännande + transferFrom-funktioner med ERC223-tokens, även om de inte ingår i standarden just nu. När det gäller plånböcker och tjänster från tredje part som inte är smarta kontrakt stöder de ERC223 automatiskt eftersom ingångssamtalet för ERC20-token är giltigt för ERC223.

ERC20 & ERC777: Du kan hitta följande uttalande i avsnittet ”Bakåtkompatibilitet” i ERC777-förslaget: ”Denna EIP introducerar inte bakåtkompatibiliteter och är kompatibel med den äldre ERC-20-tokenstandarden.”

Dexaran berättade dock exakt motsatsen och gav oss detta exempel: ”Sådana plånböcker och tjänster som MetaMask, Mist och MyEtherWallet arbetar med ERC20-tokens. Ingången som är utformad för ERC20-token är ett kontraktsanrop som innehåller kodade parametrar och en funktionssignatur. Funktionssamtal i Ethereum Virtual Machine specificeras av de första fyra bytes data som skickas med en transaktion. Dessa 4-byte-signaturer definieras som de första fyra byten av hash för den kanoniska representationen av funktionssignaturen. Detta betyder att funktionerna “överföring (adress, uint256)” och “skicka (adress, uint256)” kommer att ha olika signaturer. Som ett resultat kommer ingången som utformats för ERC20-token inte att vara giltig för ERC777-token. ” Eftersom vi använder vår definition av bakåtkompatibilitet är ERC777 inte kompatibel med ERC20-tokenstandarden.

När ska man använda vilken standard

ERC20: Reddit-användare u / Dexaran gav oss detta sarkastiska råd, “När du vill att dina investerare ska förlora pengar på grund av fel.”

ERC223: Denna tokenstandard kan också användas tillsammans med ERC777. ERC777 har några eleganta funktioner som ERC223 saknar, men logiken i ERC223 är enkel jämfört med ERC777 som kan garantera att den sammanfaller mycket mindre felbenägen kod. Dessutom förlitar sig ERC223 inte på någon central tjänst, vilket innebär att din ERC223-token bara beror på din egen implementering. Som vi har nämnt tidigare syftar ERC223 till säkerhetsförbättringar, men detta gjorde att ERC223-tokens inte överensstämmer med ERC20-standarderna.

ERC777: Denna tokenstandard är redan användbar. Å andra sidan har ERC777 vissa säkerhetsproblem som nämnts ovan. De är också beroende av det centrala avtalsregistret, vilket också är ett säkerhetsproblem. Ett centralt register kan göra utvecklarens liv enklare men det fungerar också som en central felpunkt precis som det var med Parity Multisig. Alla Parity Multisigs förlitade sig på ett centralt kodbibliotek. Det hände att det fanns ett fel i biblioteket och det utnyttjades. Som ett resultat kraschade alla Parity Multisigs. Dessutom definierar ERC777 en ny uppsättning funktioner. Detta är ett försök att tillåta tokenutvecklare att göra sina tokens kompatibla med både ERC20- och ERC777-standarderna samtidigt för antagandet. Detta innebär att en utvecklare kan ärva ett fel från ERC20 i ERC777, men det tillåter en utvecklare att använda fler transaktionshändelser.

I allmänhet: Alla symboler har ett liknande användningsfall – ICO. Jag skulle säga att ERC223 och ERC777 försöker lösa ett problem med ERC20 på olika sätt. ERC223 tar redan sin nisch Ethereum Classic istället för ERC20.

Den här artikeln skapades med hjälp av Dexaran, ERC223-utvecklaren. Några av Paul Edges kommentarer om Ethereums tokenstandarder användes också.