De 375 000 grunnene til å forbedre ERC20

Med ERC20 tokenbaserte juggernauts som EOS, Basic Attention Token (BAT) og Storj er det vanskelig å argumentere for at grensesnittkontrakten lykkes. Ethereum-samfunnet har tydelig samlet støtte rundt denne standarden, & både utviklermiljøer og finansmarkeder reagerer positivt. Imidlertid har ERC20-standarden til tross for all suksess resultert i en ikke så ubetydelig feil:

ERC20-tokenstandarden fører til tap av penger for sluttbrukere ved å tillate brukere å sende ERC20-tokens til ingen ERC20-kompatible tokenadresser.

Når en bruker sender et ERC20-token til en Ethereum-kontrakt som ikke gjenkjenner ERC20-tokens, mister brukeren tilgangen til sine midler for alltid. Akkurat hvor mange midler som for øyeblikket er låst på grunn av dette problemet? Igjen, ikke et ubetydelig beløp:

  • 310 067 GNT sitter fast i Golem-kontrakten (for tiden verdt ca $ 217K).
  • 242 REP sitter fast i Augur-kontrakten (for tiden verdt ca $ 15K).
  • 814 DGD sitter fast i Digix DAO-kontrakt (for tiden verdt ca $ 125K).
  • 14,506 1ST sitter fast i FirstBlood-kontrakten (for tiden verdt ca $ 12K).

Dette er over hele $ 370 000 + ERC20-tokens som er frosset i disse kontraktene; siden listen over ERC20-tokens vokser, er dette tallet mest sannsynlig en konservativ undervurdering av den totale mengden av disse tokens som er frosset i kontrakter. Listen over er på ingen måte uttømmende – dette er bare noen få av de mer populære ERC20-tokens.

Ingen av kontraktene ovenfor forventet noen gang å motta ERC20-tokens – så når brukere sender tokens til disse adressene, blir transaksjonene bekreftet av nettverket; mottakerkontrakten gjenkjenner imidlertid ikke tokens. Den vet ikke hva de skal gjøre med disse tokens, noe som resulterer i at midlene blir låst for alltid. Igjen blir ikke tokens avvist – de blir bare ignorert av mottakerkontrakten.

De fleste av disse transaksjonene er utilsiktet begått av sluttbrukere som ringer til overføre funksjon (i motsetning til den automatiserte transferFrom-funksjonen som ble introdusert tidligere). Husk at ERC20 bruker begge overføringene & TransferFrom – som det viser seg at noen sluttbrukere bruker Transfer for å sende ERC20-tokens direkte til kontrakter som ikke forventes, & gjenkjenner derfor ikke de innkommende tokens.

Til slutt bestemte noen få medlemmer av Ethereum-samfunnet seg for å takle dette problemet ved å be om en ny ERC-tokenstandard. Utstedelsesnummeret til denne nye tokenstandarden på GitHub, er nummer nummer 223.

ERC223 Forslag

GitHub-bruker Dexaran foreslo en ny ERC-standard (ERC223) tilbake i mars 5, 2017 som hadde som mål å fikse dette problemet med symbolsk tilbakefall. Sammendraget for GitHub-utgaven nr. 223 nye tokenforslag er følgende:

Følgende beskriver standardfunksjoner som en tokenavtale og kontrakt som arbeider med det angitte tokenet kan implementere for å forhindre utilsiktet sending av tokens til kontrakter og få token-transaksjoner til å oppføre seg som eter-transaksjoner.

Dexarans tokenforslag implementerer to kjernefunksjoner for å umiddelbart stoppe desentraliserte appbrukere fra å ved et uhell sende tokens til smarte kontrakter som ikke er klare til å motta disse tokens:

  1. Konsolidering av ERC20 Overføre & Overfør fra fungerer til en enkelt Overføre funksjon med tre parametere: (adresse _to, uint _value, bytes data).
  2. De motta kontrakt, hvis du mottar tokens, inneholder en TokenFallBack funksjon som definerer nøyaktig hvordan du skal håndtere hvilken type innkommende token.

Overføre & Overfør fra -> Overføre

En viktig del av ERC20-standarden som bidrar til dette vanlige problemet er det faktum at sluttbrukere feilaktig bruker en av de to funksjonene som brukes til å overføre (Transfer & Overfør fra).

ERC223 foreslår at du erstatter begge funksjoner med en enkelt Overføre funksjon.

ERC223 lar dapp-sluttbrukere sende tokens til noen Ethereum-adresse, uansett om kontrakten er en lommebok eller en kontrakt, med samme overføringsfunksjon. Logikken her er at ved å eliminere muligheten for brukere å utløse en overføringsfunksjon eller en TransferFrom-funksjon til bare en enkelt Transfer-funksjon, sluttbrukere har ikke lenger potensialet til å bruke feil funksjon.

Den nylig foreslåtte overføringsfunksjonen godtar tre parametere (tidligere bare akseptert to), og enda viktigere, det ser ut til å påkalle en TokenFallback-funksjon på mottaksadressen. Uten de tre definerte parametrene klarer ikke overføringsfunksjonen å kompilere; uten mottaksadressen som inneholder en TokenFallback-funksjon, vil overføringsfunksjonstransaksjonen mislykkes & ingen tokens blir overført.

funksjon tokenFallBack ()

I Ethereum-utvikling eksisterer det en kontraktsmodifiserende som skal betales som brukes til å utarbeide en kontrakt for å motta Ether – dette betyr at en kontrakt nå forventer den digitale valutaen. Hvis en kontrakt gjør det ikke inneholder modifikatoren som skal betales, kanselleres transaksjonen som sendes & returnert. Ikke noe fancy, dette er Ethereum 101.

En analog måte å tenke på ERC223 tokenFallback-funksjonen er at den betalbare modifikatoren er å forberede en kontrakt for å motta Ether, da tokenFallback-funksjonen er å forberede en kontrakt for å motta x token.

I denne standarden, kontraktutviklere implementere tokenFallback hvis de vil at kontraktene deres skal fungere med spesifikke tokens. Hvis mottakeren er en ikke-kontraktadresse, vil en ERC223-token-transaksjon utføre akkurat som enhver gjeldende ERC20-tokenoverføring. På den annen side, hvis mottakeren er en kontrakt, vil ERC223-token-kontrakten først prøve å ringe tokenFallback på mottakerkontrakten; Hvis ingen tokenFallback-funksjon blir funnet, vil transaksjonen mislykkes.

Utvikling av ERC

Til tross for den grove utkaststilstanden til ERC223, venter en annen ERC-standard i horisonten – ERC 721. ERC721 fokuserer på ikke-soppbar eiendeler som CryptoKitties, Decentraland land, & kanskje til og med en dags eiendeler. ERC 721-fremgang finner du her: https://github.com/ethereum/eips/issues/721

Alt for å vise at Ethereum-samfunnet, mens det er ungt, er veldig seriøst med å forbedre sin smarte kontraktplattform ved å sette de riktige standardene foran en voksende bølge av nye utviklere. Sakte men sikkert vil ERC-token-bugs reduseres – og så blir spørsmålet den siste standardskalaen?

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me