Erik Zhang, cofundador i desenvolupador principal de Neo, ha finalitzat NEP-21, un estàndard que defineix una interfície comuna per a les aplicacions descentralitzades de Neo N3 per comunicar-se amb els proveïdors de carteres. L’estàndard ha assolit l’estat d'”Acceptat” al repositori de propostes de millora Neo després d’un període de revisió ampliat que va començar el novembre de 2021 i va concloure amb una activitat renovada al març.
NEP-21 està dirigit a resoldre un problema persistent a l’ecosistema Neo: sense una interfície compartida, els desenvolupadors dApp han d’escriure una lògica d’integració separada per a cada cartera, ja que les carteres defineixen els seus propis mètodes i formats de dades, fent que els usuaris es trobin amb un comportament inconsistent segons quina cartera es connectin. El nou estàndard ofereix a ambdues parts un llenguatge comú.
Què permet NEP-21
Amb NEP-21 al seu lloc, els desenvolupadors dApp poden crear una integració de cartera única que funcioni amb qualsevol cartera compatible en lloc de mantenir un codi separat per a cada proveïdor. Els desenvolupadors de carteres aconsegueixen un objectiu clar per implementar, reduint la barrera perquè les noves carteres entrin a l’ecosistema. Per als usuaris, el resultat és una experiència més consistent a l’hora de connectar carteres, signar transaccions i interactuar amb dApps, independentment de quina cartera trien.
La norma forma una cadena amb dues propostes relacionades. NEP-20, l’estàndard d’autenticació basat en cartera que NNT va tractar a principis d’aquest mes, defineix com les aplicacions verifiquen el control d’un usuari d’una adreça NEONeo. NEP-21 proporciona la interfície unificada a través de la qual els dApps criden carteres per completar aquesta autenticació i altres operacions. Una proposta relacionada, NEP-33, té com a objectiu normalitzar encara més el punt d’entrada d’inici de sessió en un flux “Iniciar sessió amb Neo”.
Com funciona l’estàndard
NEP-21 defineix una interfície anomenada IDapiProvider que implementen els proveïdors de carteres. La interfície cobreix diverses categories de capacitat.
Per a la identitat i la connexió, dApps pot trucar authentication() per verificar l’adreça d’un usuari (seguint l’esquema NEP-20), recuperar els comptes connectats o demanar a l’usuari que seleccioni una adreça diferent.
Per llegir dades a la cadena, l’estàndard proporciona mètodes per invocar contractes fora de la cadena, blocs de consultes, transaccions, registres d’aplicacions, emmagatzematge de contractes i informació de testimoni sense requerir la signatura d’un usuari.
Per a la invocació de contractes i la gestió de transaccions, les dApps poden invocar un o més contractes a la cadena, construir transaccions sense difondre-les (útil per a fluxos de treball de signatures múltiples) i retransmetre transaccions signades a la xarxa. An abortOnFail El paràmetre permet a dApps especificar que una transacció sencera s’ha de revertir si una única invocació torna falsa, una característica dissenyada per a operacions transaccionals on l’execució parcial seria perjudicial.
Per a la signatura de missatges, l’estàndard inclou mètodes per signar missatges arbitraris mitjançant ECDSA amb SHA256, que admeten casos d’ús com ara l’autorització fora de la cadena i les declaracions de protocol.
Per a les notificacions d’esdeveniments, les carteres emeten esdeveniments estandarditzats quan un usuari canvia de compte o canvia de xarxa, cosa que permet a les dApps mantenir sincronitzat el seu estat d’interfície.
Descobriment del proveïdor
L’estàndard defineix un mecanisme de descoberta perquè les dApps i les carteres es trobin entre elles. Quan una cartera està a punt, envia un Neo.DapiProvider.ready esdeveniment al navegador window objecte. Una dApp també pot sol·licitar de manera proactiva un proveïdor enviant un Neo.DapiProvider.request esdeveniment. Si responen diverses carteres, la dApp tria quin proveïdor utilitzarà.
Aquest disseny és independent de la capa de transport. NEP-21 no prescriu si la cartera és una extensió del navegador, una aplicació d’escriptori o un client mòbil. Estandarditza quines capacitats exposa una cartera, no com s’estableix la connexió.
Àmbit i propers passos
L’estàndard acceptat cobreix les xarxes Neo N3 MainNet i TestNet. El suport per afegir xarxes personalitzades (similar a com MetaMask permet canviar entre Ethereum, Polygon i altres cadenes) es va discutir durant el cicle de revisió, però es va ajornar a una versió futura 2.0.
Zhang va assenyalar que la implementació d’això requereix canvis a la biblioteca central Neo per llegir la configuració específica de la xarxa ProtocolSettingsque va qualificar de no trivial.
L’anunci complet es pot trobar al següent enllaç:
https://x.com/erikzhang/status/2042271274215567432
