Els 375.000 motius per millorar ERC20

Amb els juggernauts basats en tokens ERC20 com EOS, Token Basic Attention (BAT) i Storj, és difícil argumentar l’èxit del contracte d’interfície. La comunitat Ethereum ha manifestat clarament el seu suport al voltant d’aquest estàndard, & tant les comunitats de desenvolupadors com els mercats financers responen positivament. No obstant això, per tot el seu èxit, l’estàndard ERC20 ha donat lloc a un error no tan insignificant:

L’estàndard de tokens ERC20 comporta pèrdues de diners per als usuaris finals en permetre als usuaris enviar tokens ERC20 a adreces de tokens que no compleixin ERC20.

Quan un usuari envia un testimoni ERC20 a un contracte Ethereum que no reconeix els tokens ERC20, l’usuari perd l’accés als seus fons per sempre. Quins fons hi ha actualment bloquejats a causa d’aquest problema? De nou, no és una quantitat insignificant:

  • 310.067 GNT estan atrapats en el contracte de Golem (actualment valen uns 217.000 $).
  • 242 REP estan atrapats en el contracte Augur (actualment valen uns 15.000 dòlars).
  • 814 DGD estan atrapats en el contracte de Digix DAO (actualment valen uns 125.000 dòlars).
  • 14.506 1r estan atrapats en un contracte de FirstBlood (actualment valen aproximadament uns 12.000 dòlars).

Això supera els 370.000 € més de tokens ERC20 congelats en aquests contractes; atès que la llista de fitxes ERC20 creix, és probable que aquest nombre sigui una subestima conservadora de la quantitat total d’aquestes fitxes congelades en els contractes. La llista anterior no és en absolut exhaustiva: són només alguns dels tokens ERC20 més populars.

Cap dels contractes anteriors mai no esperava rebre cap testimoni ERC20; per tant, quan els usuaris envien tokens a aquestes adreces, la xarxa confirma les transaccions; no obstant això, el contracte receptor no reconeix les fitxes. No sap què fer amb aquestes fitxes que fan que els fons quedin bloquejats per sempre. Una vegada més, les fitxes no es rebutgen, sinó que són totalment ignorades pel contracte receptor.

La majoria d’aquestes transaccions són compromeses sense voler pels usuaris finals que trucen al transferència function (a diferència de la funció transferFrom automàtica introduïda anteriorment). Recordem que ERC20 fa ús de Transferència & TransferFrom: segons resulta, alguns usuaris finals utilitzen Transfer per enviar directament tokens ERC20 a contractes que no esperaven, & per tant, no reconeixeu les fitxes entrants.

Finalment, uns quants membres de la comunitat Ethereum van decidir abordar aquest problema directament sol·licitant un nou estàndard de token ERC. El número de problema d’aquest nou estàndard de token a GitHub és el número 223.

Proposta ERC223

L’usuari de GitHub, Dexaran, va suggerir un nou estàndard ERC (ERC223) el 5 de març de 2017 que tenia com a objectiu solucionar aquest problema de fallada de token. El resum de la seva nova proposta de token número 223 de GitHub és el següent:

A continuació es descriuen les funcions estàndard que poden implementar un contracte de token i un contracte que treballa amb el testimoni especificat per evitar enviaments accidentals de tokens a contractes i fer que les transaccions de tokens es comportin com transaccions amb èter..

La proposta de tokens de Dexaran implementa dues funcions bàsiques per evitar immediatament que els usuaris descentralitzats d’aplicacions enviïn tokens accidentalment a contractes intel·ligents que no estan preparats per rebre els tokens següents:

  1. Consolidació de l’ERC20 Transferència & Transferència des de funciona en una sola Transferència funció amb tres paràmetres: (adreça _to, uint _value, bytes data).
  2. El rebent contracte, si rep fitxes, haver de contenir un TokenFallBack funció que defineix exactament com gestionar quin tipus de testimoni entrant.

Transferència & Transferència des de -> Transferència

Una part clau de l’estàndard ERC20 que contribueix a aquest problema comú és el fet que els usuaris finals tinguin l’opció d’utilitzar per error una de les dues funcions que s’utilitzen per transferir & Transferència des de).

ERC223 proposa substituir les dues funcions per una sola Transferència funció.

L’ERC223 permet als usuaris finals de dapp enviar fitxes a cap Adreça Ethereum, independentment de si aquest contracte és una cartera o un contracte, amb la mateixa funció de transferència. La lògica aquí és que eliminant l’opció que els usuaris activin una funció de transferència o bé una funció TransferFrom a una sola funció Transfer, els usuaris finals ja no tenen el potencial d’utilitzar la funció incorrecta.

La nova funció de transferència proposada accepta tres paràmetres (abans només s’acceptaven dos) i, el que és més important, sembla que invoca una funció TokenFallback a l’adreça de recepció. Sense els tres paràmetres definits, la funció de transferència no compila; sense l’adreça de recepció que contingui una funció TokenFallback, la transacció de la funció de transferència fallarà & no es transferiran fitxes.

funció tokenFallBack ()

En el desenvolupament d’Ethereum existeix un modificador de contracte a pagar s’utilitza per preparar un contracte per rebre Ether; això vol dir que ara un contracte espera la moneda digital. Si ho fa un contracte no conté el modificador a pagar, la transacció enviada simplement es cancel·la & va tornar. Res de luxe, aquest és Ethereum 101.

Una manera anàloga de pensar sobre la funció ERC223 tokenFallback és que el modificador pagable consisteix a preparar un contracte per rebre Ether, ja que la funció tokenFallback consisteix a preparar un contracte per rebre x token.

En aquesta norma, els desenvolupadors de contractes haver de implementeu tokenFallback si volen que els seus contractes funcionin amb tokens específics. Si el destinatari és una adreça que no és contractual, s’executarà una transacció de testimoni ERC223 igual que qualsevol transferència de testimoni ERC20 actual. En canvi, si el receptor és un contracte, el contracte de token ERC223 primer intentarà trucar a tokenFallback en el contracte de receptor; si no es troba cap funció tokenFallback, la transacció fallarà.

Evolució d’ERC

Malgrat l’estat d’esborrany ERC223, un altre estàndard ERC apareix a l’horitzó: ERC 721. ERC721 se centra en no fungible actius com CryptoKitties, Decentraland land, & potser fins i tot actius immobiliaris d’un dia. El progrés ERC 721 es pot trobar aquí: https://github.com/ethereum/eips/issues/721

Tot per demostrar que, encara que jove, la comunitat Ethereum es preocupa molt per millorar la seva plataforma de contractes intel·ligents posant els estàndards adequats davant d’una onada creixent de nous desenvolupadors. De manera lenta però segura, els errors de token ERC disminuiran i, aleshores, la pregunta es convertirà en l’última escala estàndard?

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