Tots esteu familiaritzats amb els tokens ERC20, ja que probablement en teniu un parell, distribuïts per algun tipus de venda de tokens. Però sabíeu que hi havia molts més estàndards a més d’ERC20? Ethereum té una llarga història d’estàndards desenvolupats.

Per fer-vos una millor idea del que significa ERC, significa “Sol·licitud de comentari Ethereum”. Aquesta és una proposta enviada per a discussió i suggeriments a la norma real. El número (com ara 20) fa referència a un número de problema a la plataforma per compartir codi Github. En primer lloc, fem una ullada a l’estàndard ERC20.

Estàndard ERC20

Què és exactament l’estàndard ERC20?

L’aparició dels tokens ERC20 va revolucionar el mercat de les criptomonedes i va obrir la porta a la gran quantitat de Criptomoneda ICO projectes que el món va presenciar durant el 2017. Introduït el 2015, el codi ERC20 descriu una llista específica de regles que ha de desplegar un determinat testimoni basat en Ethereum, simplificant el procés de programació de les funcions dels tokens a la cadena de blocs d’Ethereum. Bàsicament, els tokens ERC20 són formes especials de contractes intel·ligents que utilitzen la cadena de blocs d’Ethereum.

Els exemples més destacats de tokens ERC20 són Bancor, EOS, Tronix, BNB, VeChain i Bankex..

Abans de la innovació de l’estàndard ERC20 per als tokens Ethereum, els codificadors havien de crear estàndards d’implementació específics per desenvolupar un testimoni i llançar-lo a la xarxa d’Ethereum. No obstant això, el codi de tokens ERC20 ha simplificat el procés de creació de tokens, gràcies a un protocol simplificat i a estàndards de contractes intel·ligents. El codi ERC20 va alleujar la complexitat associada a la implementació dels contractes intel·ligents de tokens, cosa que va reduir significativament la possibilitat de trencar els contractes de tokens.

A l’abril de 2018, n’hi ha 66.468 contractes simbòlics ERC20, gràcies a la uniformitat del codi de tokens proporcionada per l’estàndard ERC20, que va facilitar als intercanvis de criptomonedes la llista de diversos tokens a les seves plataformes comercials. Com a tal, l’estàndard ERC20 ha ajudat la comunitat criptogràfica a superar problemes de liquiditat que podrien haver associat un enorme nombre de tokens basats en Ethereum.

Funcions de token ERC20:

El codi ERC20 descriu sis funcions específiques per als tokens, que són

1- Obtenir el subministrament total de tokens a través de "oferta total" funció

2- Recuperació del saldo simbòlic d’un altre compte associat a "_propietari" adreça via " equilibriOf (adreça _propietari) rendiments constants (saldo uint256)" funció.

3- Enviar una quantitat específica de fitxes "_valor" a una adreça determinada mitjançant " devolució de transferència (adreça _to, uint256 _value) (èxit boolè)" funció.

4- Enviament d’una quantitat específica de fitxes "_valor" d ‘una adreça de contracte (contracte) a una altra adreça de contracte (contracte) a través de "transferFrom (address _from, address _to, uint256 _value) retorna (bool exit)" funció.

5- Habilitar un compte específic per retirar fitxes del compte de manera repetida, mentre es defineix el límit superior per a la quantitat de fitxes a retirar amb el "_valor" paràmetre. Això es pot aconseguir mitjançant "aprovar (adreça _spender, uint256 _value) retorna (èxit boolè)". El límit superior per a la retirada, és a dir, el "_valor" es pot sobreescriure quan es recupera la funció.

6- Devolució de la quantitat residual de fitxes, dins de la quantitat predeterminada definida pel límit superior permès per la "_spender" per retirar del compte de l ‘ "_propietari". Això es pot executar mitjançant el fitxer "bonificació (adreça * _propietari *, adreça * _spender *) devolucions constants (restant uint256)" funció.

Aquestes sis funcions definides pel codi ERC20 representen problemes de funcionalitat de la pedra angular, que inclouen com es transferiran aquests testimonis entre diferents comptes i com els usuaris poden recuperar les dades associades a un determinat testimoni ERC20. Aquest grup de funcions es prescriuen per garantir que els tokens basats en Ethereum funcionin de manera similar dins de qualsevol part de la plataforma d’Ethereum. Com a tal, totes les carteres criptogràfiques que compleixin la moneda d’èter també admetran fitxes basades en l’estàndard ERC20.

Error crític:

ERC20 és el primer estàndard simbòlic d’Ethereum. Com sol passar amb el codi nou, conté alguns errors o errors lògics. ERC20 assumeix dues maneres de realitzar una transacció de token. En primer lloc, la funció de transferència us permet enviar fitxes a l’adreça d’algú. Si voleu ingressar fitxes a un contracte intel·ligent, hauríeu d’utilitzar la combinació ‘aprovar + transferirDe’. Heu d’autoritzar aquest contracte per retirar les vostres fitxes mitjançant la funció d’aprovació. A continuació, haureu de trucar a una funció d’un contracte que gestionarà el vostre dipòsit i retirarà les vostres fitxes mitjançant la funció transferFrom.

Què passa si dipositeu fitxes per accident a un contracte amb la funció de transferència? La transacció tindrà èxit, però no serà reconeguda pel contracte destinatari. Per exemple, si envieu fitxes a un contracte d’intercanvi descentralitzat, el contracte d’intercanvi rebrà les vostres fitxes però no acreditarà aquestes fitxes al vostre saldo de fitxes d’intercanvi. A més, si el contracte d’intercanvi descentralitzat no implementa una funció d’extracció de tokens d’emergència, és impossible recuperar les vostres fitxes en cap cas, cosa que provoca una pèrdua permanent de les fitxes. A causa d’aquest error, l’ecosistema Ethereum ja ha perdut milions de dòlars.

Per què encara fem servir l’estàndard ERC20??

Usuari de Reddit u / Dexaran, creador de l’estàndard ERC223, és un dels primers desenvolupadors que va notificar a la comunitat sobre l’esmentat error. Li vam preguntar per què ERC20 encara s’utilitza tant, fins i tot quan coneixem aquest error crític. Va exposar els motius següents:

1. A causa de la irresponsabilitat criminal dels desenvolupadors de fitxes pels seus fets.
2. Perquè Ethereum Foundation encara promou l’estàndard de token ERC20 fins i tot quan se sap que conté errors. La mateixa situació que amb TheDAO anteriorment. Necessiten dir "Atura això ara" però no ho faran.
3. Perquè el motiu principal del desenvolupament de tokens és la captació de fons, més que la creació de productes.
4. Perquè utilitzar un estàndard diferent comportarà efectes de xarxa més elevats. Això no és el que realment necessitem, ja que la xarxa Ethereum ja té problemes d’escalabilitat.

Estàndard ERC223

El ERC223 estàndard va ser proposat per u / Dexaran, que va ajudar a crear aquest article. ERC223 és un estàndard de token que permet que les transferències de token es comportin exactament com les transaccions amb èter. ERC223 utilitza la gestió d’esdeveniments (considera que una transacció és un esdeveniment) per evitar que es perdin fitxes en transaccions no gestionades. Aquest estàndard millorat resol l’error crític ERC20 fent que la funció de transferència generi un error en les transferències no vàlides i cancel·li la transacció perquè no es perdin fons. En resum, ERC223 se centra en seguretat.

Addicions i problemes

ERC223 afegeix un paràmetre de dades addicional a la funció de transferència, per permetre operacions més complexes que una simple transferència de tokens.

La principal preocupació de Dexaran és que massa gent pot perdre les seves fitxes enviant-les a contractes mitjançant la funció de transferència, no els mètodes aprovar i transferir de com es va comentar anteriorment. La seva solució és modificar el mètode de transferència per comprovar si l’adreça de recepció és un contracte (és a dir, conté dades) o no. Si es tracta d’un contracte, assumeix que hi ha una funció tokenFallback per tornar-la a trucar. La principal debilitat és que si no existeix el tokenFallback, es cridarà la funció de reserva del contracte receptor i es podran perdre els tokens enviats..

Estàndard ERC777

ERC777 és un nou estàndard de token fungible que es basa en ERC820 (registre de pseudointrospecció de contractes) i que intenta resoldre els problemes d’ERC20, com ara la manca de mecanismes de gestió de transaccions que van conduir a la pèrdua de milions de dòlars de l’ecosistema Ethereum. En resum, ERC777 se centra en adopció oferint un àmplia gamma de mecanismes de gestió de transaccions.

Beneficis

El principal avantatge d’ERC777 és que utilitza un nou mètode de reconeixement de la interfície del contracte. Aquesta norma suposa que hi ha un registre central de contractes a la xarxa d’Ethereum (això es defineix a ERC820). Tothom pot invocar aquest registre per saber si una adreça determinada (no importa si aquesta adreça és un contracte o no) admet un determinat conjunt de funcions, és a dir, “interfície”.

Un dels principals problemes d’Ethereum és la incapacitat de saber quines funcions implementa el contracte. ERC820 està pensat per solucionar-ho. ERC777 aprofita aquest enfocament, que sens dubte és una bona idea.

D’altra banda, podeu crear un testimoni que implementarà les funcions predeterminades d’ERC20 juntament amb les noves funcions ERC777 sense anul·lacions (i heretar opcionalment l’error crític d’ERC20). Això pot garantir un bon efecte de xarxa per a aquest nou estàndard de token i una adopció més ràpida. Com es demostra a la pràctica, l’objectiu principal dels desenvolupadors de fitxes és recaptar diners que suposi que necessiten empènyer les seves fitxes a borses. És més fàcil que els intercanvis admetin un testimoni que implementi funcions ERC20 heretades (no importa si aquestes funcions contenen errors o no) sense cap investigació sobre les noves funcionalitats dels nous estàndards de token. Com més fàcil sigui que els intercanvis admetin tokens en un nou estàndard, més desenvolupadors l’utilitzaran. Això augmenta l’adopció d’ERC777, mentre que ERC223 no té aquesta propietat.

Què és diferent?

Aquest estàndard de testimoni defineix un conjunt de funcions completament nou, és a dir, funcions “enviar” en lloc de funcions “transferir”. “authoriseOperator” en lloc de “aprovar”. Funció de controlador “tokensReceived” en lloc de la funció de controlador “tokenFallback”.

Aquest enfocament pot garantir que les funcions d’aquest estàndard no es creuin i anul·lin amb funcions de cap altre estàndard de token, per tant és possible crear un token que sigui compatible amb els estàndards ERC777 i ERC820 simultàniament.

Per fi, ERC777 estandarditza Mint and Burn funcionalitat de les fitxes.

Punts de falles i problemes de seguretat

ERC777 implementa la funció “authoriseOperator” que permet a algú gestionar fitxes en nom vostre. Dexaran ens va explicar que creu que aquest mètode està obsolet i no s’hauria d’utilitzar. A més, autoritzar algú per gestionar els tokens en nom vostre perjudica l’amplada de banda de la xarxa i requereix més gasolina. “authoriseOperator” ja representa una transacció i cal fer una altra transacció per realitzar la "retirada autoritzada". Per tant, es necessiten dues transaccions per realitzar una transferència que es pot fer amb una sola transacció.

A continuació, l’estàndard ERC777 conté un indicador opcional per evitar tokens bloquejats mitjançant la comprovació de la interfície ITokenRecipient i per comprovar si l’adreça està a la llista blanca. Com que aquest estàndard se centra en la seguretat d’una xarxa que gestiona els tokens que valen milions de dòlars, no és bo fer aquests controls opcionals.

Altres estàndards

Hi ha molts altres estàndards com ERC827 que combina alguns avantatges d’ERC223 amb funcions ERC20 heretades. El ERC664 estàndard se centra en la modularitat de l’estàndard de token. Aquest estàndard permet actualitzar els contractes de token, però ha heretat l’error crític ERC20. Altres estàndards inclouen ERC721, ERC677 i ERC820, però són menys coneguts.

Compatibilitat entre estàndards

Vam preguntar a Dexaran quins estàndards són compatibles amb les versions anteriors. Ens va dir que primer hauríem d’entendre què significa “compatibilitat amb versions anteriors”: “La compatibilitat amb versions anteriors és una propietat d’un sistema, producte o tecnologia que permet la interoperabilitat amb un sistema heretat anterior o amb una entrada dissenyada per a aquest sistema”.

ERC20 & ERC223: Els tokens ERC223 són compatibles amb ERC20. Tot el que està dissenyat per funcionar correctament amb ERC20 (com les carteres) també pot funcionar amb ERC223. L’única excepció aquí són els contractes que depenen de patrons d’aprovació + transferència de dipòsit de tokens. Tanmateix, és possible implementar funcions approve + transferFrom amb tokens ERC223, fins i tot si ara mateix no s’inclouen a l’estàndard. Pel que fa a les carteres i els serveis de tercers que no siguin contractes intel·ligents, admeten ERC223 automàticament perquè les dades de trucades d’entrada del testimoni ERC20 són vàlides per a ERC223.

ERC20 & ERC777: Podeu trobar la següent afirmació a la secció “Compatibilitat cap enrere” de la proposta ERC777: “Aquest EIP no introdueix incompatibilitats cap enrere i és compatible amb l’anterior estàndard de token ERC-20”.

Tanmateix, Dexaran ens va dir exactament el contrari i ens va donar aquest exemple: “Carteres i serveis com MetaMask, Mist i MyEtherWallet funcionen amb tokens ERC20. L’entrada dissenyada per al testimoni ERC20 és una trucada de contracte que conté paràmetres codificats i una signatura de funció. Les trucades de funció a la màquina virtual Ethereum s’especifiquen amb els primers quatre bytes de dades enviades amb una transacció. Aquestes signatures de 4 bytes es defineixen com els primers quatre bytes del hash de la representació canònica de la signatura de la funció. Això significa que les funcions “transferir (adreça, uint256)” i “enviar (adreça, uint256)” tindran signatures diferents. Com a resultat, l’entrada dissenyada per al testimoni ERC20 no serà vàlida per al testimoni ERC777 ”. A mesura que fem servir la nostra definició de compatibilitat amb versions anteriors, ERC777 no és compatible amb l’estàndard de token ERC20.

Quan s’ha d’utilitzar quin estàndard

ERC20: L’usuari de Reddit u / Dexaran ens va donar aquest sarcàstic consell: “Quan vulgueu que els vostres inversors perdin diners a causa d’errors”.

ERC223: Aquest estàndard de token també es pot utilitzar juntament amb ERC777. ERC777 té algunes funcions elegants que no tenen a ERC223, però la lògica d’ERC223 és senzilla en comparació amb ERC777, que pot garantir que continuï molt menys codi propens a errors. A més, ERC223 no confia en cap servei central, cosa que significa que el vostre testimoni ERC223 només dependrà de la vostra pròpia implementació. Com hem esmentat anteriorment, ERC223 té com a objectiu millorar la seguretat, però això fa que els tokens ERC223 no compleixin els estàndards ERC20.

ERC777: Aquest estàndard de token ja es pot utilitzar. D’altra banda, ERC777 té algunes preocupacions de seguretat tal com s’ha esmentat anteriorment. També confien en el registre central de contractes, que també és una qüestió de seguretat. Un registre central pot facilitar la vida del desenvolupador, però també actua com a punt central de fallada exactament igual que amb Parity Multisig. Tots els Multisigs Parity es basaven en una biblioteca de codis central. Va passar que hi havia un error a la biblioteca i que va ser explotat. Com a resultat, tots els Multisigs Parity es van estavellar. A més, ERC777 defineix un nou conjunt de funcions. Es tracta d’un intent de permetre als desenvolupadors de tokens que facin compatibles les seves fitxes amb els estàndards ERC20 i ERC777 simultàniament per adoptar-los. Això significa que un desenvolupador pot heretar un error d’ERC20 a ERC777, però permet que un desenvolupador utilitzi més esdeveniments de gestió de transaccions.

En general: Totes les fitxes tenen un cas d’ús similar: ICO. Diria que ERC223 i ERC777 intenten resoldre un problema d’ERC20 de maneres diferents. ERC223 ja està prenent el seu lloc Ethereum Classic en lloc de l’ERC20.

Aquest article es va crear amb l’ajut de Dexaran, el desenvolupador ERC223. També es van utilitzar alguns dels comentaris de Paul Edge sobre els estàndards simbòlics d’Ethereum.