A l’última reunió de desenvolupadors bàsics de Neo, els col·laboradors es van centrar a simplificar el mecanisme de tarifes de contracte personalitzat proposat NEP, avaluar un enfocament basat en transaccions per demostrar la vivacitat dels nodes i preparar canvis de govern i criptografia per a les properes versions. La sessió també va aportar claredat addicional a l’arquitectura d’alt nivell de Neo N4, centrada en Neo N3 com a cadena principal amb cadenes laterals pont.
El mecanisme de tarifa de contracte personalitzat es redueix a només GAS
Els desenvolupadors van revisar l’esborrany de NEP que introdueix una manera estandarditzada per als contractes intel·ligents per definir les tarifes d’execució personalitzades a més dels costos estàndard de la xarxa. La proposta utilitza un nou camp de metadades de tarifa al contracte ABI, recolzat per les eines DevPack i aplicat per Neo VM, que permet models com ara el pagament per ús, l’accés a l’estil de subscripció i la compensació directa per als mantenedors del contracte.
La discussió es va centrar a reduir la complexitat limitant la primera versió del mecanisme als pagaments només de GAS. Restringir el disseny a GAS es va veure com una simplificació significativa en comparació amb el suport de fitxes NEP-17 arbitraris, tot i que encara es va abordar la necessitat bàsica de cobrar les tarifes a nivell de contracte.
També hi va haver interès en un disseny encara més racionalitzat on una part de la tarifa del sistema existent es redirigeix al contracte o a un beneficiari designat mitjançant una trucada d’interoperabilitat dedicada. Això evitaria la introducció d’un model d’actius ric a la versió inicial i confiaria únicament en el GAS que ja està present a la màquina virtual durant l’execució de la transacció.
Els conceptes més avançats, com ara el pagament de comissions d’execució en altres fitxes mitjançant contractes de liquiditat nativa, es van reconèixer com a valuosos a llarg termini, però es van considerar fora de l’abast de l’actual NEP. La prioritat és finalitzar un mecanisme net i només de GAS que després es pugui ampliar sense trencar la compatibilitat ni complicar excessivament la implementació inicial.
El NEP s’actualitzarà per reflectir aquesta direcció, incorporant comentaris de revisió recents i simplificant l’especificació en conseqüència.
Les proves de vida dels nodes es mouen cap a un model basat en transaccions
El grup va continuar treballant de disseny en un mecanisme de “prova de node” per garantir que els membres del comitè registrats operen nodes en directe i configurats correctament.
Idees anteriors, com ara una prova de treball lleugera o confiar en missatges extensibles d’igual a igual, van plantejar preocupacions sobre el correu brossa de la xarxa i l’ambigüitat a l’hora de distingir els problemes de connectivitat del temps d’inactivitat real. La direcció preferida és ara un enfocament a la cadena on es demostra la vivacitat del comitè mitjançant transaccions periòdiques.
Sota aquest model, els membres del comitè estarien obligats a enviar una petita transacció a intervals definits. La responsabilitat de cada transacció de vivacitat es podria assignar de manera determinista en funció de dades com ara el hash de bloc anterior, i el connector dBFT podria gestionar la creació de transaccions automàticament. Això garanteix que només els nodes que funcionen correctament poden satisfer el requisit sense intervenció manual.
Un contracte natiu dedicat orientat a la governança podria mantenir un registre d’aquests pings, inclòs quan cada membre del comitè va enviar per última vegada una transacció de vitalitat i mètriques d’èxit agregades al llarg del temps. En comparació amb els missatges de la capa P2P, aquest disseny ofereix una auditabilitat més clara, una limitació natural de la tarifa mitjançant tarifes de transacció i menys canvis als permisos a nivell de xarxa.
Els detalls com ara les finestres de temps, les penalitzacions per pings perduts i la integració amb la futura lògica de selecció de candidats es perfeccionaran en el treball de seguiment, però hi va haver una àmplia alineació al voltant de l’ús de transaccions com a base per al seguiment de la vivacitat dels nodes.
Recuperació de fons bloquejats dirigida a Neo 3.9
Se’ls va recordar als desenvolupadors que revisin el Sol·liciteu fons bloquejats sol·licitud d’extracció, que encara està en discussió i una funció candidata per incloure-la a la versió Neo 3.9.
El canvi afegiria un mecanisme de recuperació controlada per a adreces que s’han congelat per accions de govern, com ara després d’un pirateig o un ús maliciós de fons. Un cop transcorregut un període d’un any, els saldos bloquejats només es podrien moure amb l’aprovació de 19 dels 21 membres del comitè, assegurant que qualsevol operació de recuperació requereixi una forta supermajoria.
La funció no està dissenyada explícitament per a escenaris de clau perduda en què els usuaris ja no poden demostrar la propietat. En canvi, pretén formalitzar un camí estret per gestionar les adreces sancionades sota estrictes restriccions de temps i signatura, millorant la claredat i la predictibilitat per a les parts interessades de l’ecosistema.
La interfície BLS compatible amb Ethereum progressa mitjançant neo-go
La reunió també va abordar el treball en curs per donar suport a la serialització compatible amb Ethereum per a BLS12-381 al contracte natiu CryptoLib, principalment per als casos d’ús adjacents a Neo X i EVM.
Una sol·licitud d’extracció de neo-go ara implementa la interfície desitjada, reflectint l’acord previ que els mètodes compatibles amb Ethereum de CryptoLib encara haurien d’alinear-se amb el disseny de l’API existent en lloc d’introduir un estil separat de només bytes. Els comentaris de l’equip de Neo X ja s’han incorporat i s’han sol·licitat revisions addicionals per finalitzar la interfície.
Un cop la versió neo-go es consideri estable, el mateix enfocament es portarà a la implementació C#. L’expectativa és que aquest patró es pugui ampliar posteriorment a altres corbes com BN254, conservant una interfície criptogràfica multiplataforma coherent i mantenint la interoperabilitat amb les eines EVM.
Arquitectura N4: cadena principal N3 amb cadenes laterals de pont natiu
Per tancar la reunió, els desenvolupadors van discutir com es relaciona el full de ruta de Neo N4 en evolució amb l’actual xarxa Neo N3 i els propers treballs de pont.
Neo N4 s’està posicionant com una arquitectura on Neo N3 continua funcionant com a cadena principal, sense canvis necessaris per a les dApps existents i sense necessitat de migració per als usuaris. Es va destacar la compatibilitat entre N4 i N3. Les cadenes laterals específiques de l’aplicació executaran codi Neo N4 (desenvolupat a la branca mestra) i es connectaran de nou a la cadena principal mitjançant ponts natius basats en contractes intel·ligents que gestionen la comunicació entre cadena i el moviment d’actius.
S’ha demanat a l’equip de desenvolupament principal que explori diversos dissenys de ponts nadius que s’adaptin a aquest model, inclosa la possibilitat d’incorporar o adaptar solucions existents com ara el pont AxLabs. Un cop documentades diverses opcions, el lideratge de Neo seleccionarà l’enfocament que millor s’ajusti als objectius d’escalabilitat i interoperabilitat a llarg termini de N4.
Aquesta direcció reforça Neo N3 com a capa base estable i compatible alhora que ofereix un camí clar per expandir l’ecosistema mitjançant cadenes laterals especialitzades i una infraestructura de cadena creuada estandarditzada.
El debat complet es pot trobar al següent enllaç:
https://youtu.be/96kpFwQe9EA
