R3E Network distribuisce il prototipo di rete elastica multi-L2 sul TestNet di Neo N3

R3E Network ha distribuito il suo prototipo di rete elastica neo-n4 sul TestNet di Neo N3, segnando la prima distribuzione live dell'architettura multi-L2 indipendente costruita dal core developer di Neo Jimmy Liao. Sebbene porti il nome "neo-n4", il progetto è separato dal lavoro sul protocollo Neo 4 canonico di Erik Zhang: l'iniziativa di Zhang punta a un'evoluzione RISC-V VM del livello di esecuzione centrale di Neo, mentre il neo-n4 di Liao è un livello di scalabilità L2 costruito sopra Neo N3. Il progetto neo-n4 non è affiliato a, né approvato da, Neo Global Development, la Neo Foundation o l'organizzazione neo-project.

Con cinque contratti di settlement principali ora operativi sul TestNet, il progetto è andato oltre il repository di codice esplorativo coperto da Neo News Today (NNT) a maggio ed è diventato un prototipo funzionante on-chain. Il repository copre ora le Fasi 0-6, con contratti live a sostituzione di quanto esisteva in precedenza solo come specifiche mai distribuite.

Liao, fondatore di R3E Network, ha illustrato l'intento del progetto il giorno della distribuzione: "Same thesis as Neo X and SpoonOS: Neo N4 isn't about launching a new chain. It's about building chain-native apps on top of N3, application-centric, serving users better in the AI era." Il riferimento punta a Neo X, la sidechain di Neo compatibile EVM, e a SpoonOS, un framework per agenti AI nell'ecosistema Neo, come precedenti espressioni della stessa tesi application-centric.

Cosa consente il modello di rete elastica

Il modello di rete elastica è progettato per far girare le applicazioni su catene dedicate proprie, mentre Neo N3 funge da livello comune di settlement e sicurezza. Un'applicazione di, per esempio, potrebbe girare su una catena ottimizzata per alta velocità elaborativa e bassa latenza, mentre un'applicazione DeFi occupa una catena separata con garanzie di sicurezza più rigorose—eppure entrambe farebbero affidamento sullo stesso bridge per il movimento degli asset e sullo stesso framework di governance. Utenti e asset potrebbero quindi spostarsi tra queste catene senza che ogni applicazione debba costruire ex novo il proprio bridge o la propria infrastruttura di sicurezza. L'approccio rispecchia le architetture multi-rollup in fase di sperimentazione su Ethereum, adattate allo stack di protocollo di Neo.

Contratti distribuiti sul TestNet

Cinque contratti di settlement L1 sono stati distribuiti sul TestNet di Neo N3, ciascuno con un ruolo distinto nell'architettura di rete elastica:

• RollupHub: registro delle catene, invio dei batch e inclusione forzata.
• SharedBridge: escrow degli asset per gestire depositi e prelievi tra i livelli.
• GovernanceController: governance basata su council con proposte e meccanismi di timelock.

Due ulteriori contratti gestiscono la verifica delle proof: ZkVerifier instrada le proof, mentre Sp1Groth16Verifier verifica le attestazioni del comitato utilizzando l'accoppiamento SP1 v6.2.1 Groth16/BN254.

Panoramica dell'architettura

L'architettura neo-n4 segue un design a tre livelli adattato dal pattern ZKsync Elastic Chain e ricostruito sullo stack di Neo, combinando il consenso dBFT 2.0, gli standard di token NEP-17 e NeoFS per la disponibilità dei dati.

NeoHub siede al livello di base su Neo N3 e coordina il settlement su più catene L2. Ogni catena L2 mantiene il proprio ambiente di esecuzione condividendo al contempo l'infrastruttura di bridge utilizzata per spostare gli asset tra i livelli. Tra L1 e L2 si colloca un livello opzionale di aggregazione Gateway che gestisce l'aggregazione delle proof.

Il sistema supporta tre percorsi di proof: attestazione multisig, optimistic rollup con una finestra per fraud-proof e validity proof ZK tramite SP1 RISC-V. Sette modelli di elastic chain—che coprono casi d'uso DEX, gaming, DeFi, social, NFT, pagamenti ed enterprise—sono inclusi come prototipi di ricerca per validazione e test.

Risultati della validazione

Le distribuzioni su TestNet di questo tipo consentono a una suite di contratti di girare in un ambiente pubblico senza asset di mainnet in gioco. I test pre-distribuzione hanno coperto 1.475 test su 1.478—338 test VM, 55 test di integrazione e 1.082 test unitari—raggiungendo una copertura del 99,8%. Lo smoke testing post-distribuzione ha restituito 12 test superati su 12, con tutte e cinque le distribuzioni dei contratti and a buon fine e sei collegamenti inter-contratto verificati.

La validazione RPC ha registrato 11 controlli superati su 14; i tre fallimenti rimanenti erano problemi di formato dei parametri segnalati come non bloccanti. Lo stato di genesi è stato preparato per la prima catena L2.

Ambito e avvertenze

Il repository contiene ora 38 progetti di test .NET, 16 librerie off-chain principali, otto plugin per nodi, cinque progetti di contratti L1 con 10 contratti nativi L2, sette strumenti CLI e quattro sorgenti SDK tra .NET, TypeScript, Rust e Python.

La distribuzione presenta tuttavia avvertenze significative. Nessuna fase nella matrice dello stato di implementazione è contrassegnata come pronta per la produzione. Il repository non ha subito un audit di sicurezza reso noto, e diversi requisiti di produzione—tra cui l'integrazione di firmatari HSM/KMS e un backend NeoFS revisionato—restano irrisolti. Un audit di sicurezza reso noto è un prerequisito consueto per la distribuzione in produzione di infrastrutture di questo tipo. Le proof SP1 reali sono opzionali tramite un flusso di lavoro manuale, mentre la CI standard esegue solo rapidi controlli di compatibilità. I sette modelli di elastic chain sono descritti esplicitamente come prototipi di ricerca, non come catene di produzione pianificate.

Prospettive future

La distribuzione sul TestNet porta neo-n4 dall'architettura teorica al prototipo operativo, anche se il progetto resta saldamente in una fase di ricerca ed esplorazione. Dalla copertura di NNT a maggio, R3E Network ha completato le Fasi 4-6, aggiungendo validity proof NeoVM2/SP1 RISC-V, aggregazione Gateway e strumenti CLI, in aggiunta alle Fasi 0-3 già esistenti.

Non è stata resa nota alcuna tempistica per la distribuzione sul MainNet, e il lavoro continua come ingegneria esplorativa indipendente da parte di R3E Network. Gli indicatori da monitorare includono la risoluzione dei tre fallimenti non bloccanti relativi al formato dei parametri RPC, il passaggio delle proof SP1 reali dal flusso manuale opt-in alla CI standard, e se lo stato di genesi preparato avanzi a una prima catena L2 attiva sul TestNet; qualsiasi passo verso la produzione richiederebbe inoltre l'audit di sicurezza ancora pendente, l'integrazione di firmatari HSM/KMS e un backend NeoFS revisionato, segnalati come irrisolti.

I risultati completi della distribuzione e il repository sono disponibili all'indirizzo: https://github.com/r3e-network/neo-n4