Erik Zhang rilascia Neo N3 v3.10.2, corregge un bypass della verifica dei witness multisig
Punti chiave
- •Neo ha pubblicato Neo N3 v3.10.2 il 23 ottobre, una release di sicurezza scritta dal co-fondatore Erik Zhang che contiene una singola correzione logica e nessuna nuova funzionalità.
- •La patch elimina un bypass della verifica dei witness causato da una validazione incoerente delle chiavi pubbliche tra gli overload dei contratti multisignature, che in precedenza consentiva a script malformati di superare un percorso di validazione e fallirne un altro.
- •Ora tutti i percorsi di codice di validazione impongono la decodifica crittografica completa delle chiavi pubbliche prima di classificare uno script come contratto multisig valido, grazie a una piccola modifica a Helper.cs.
- •Il commit aggiunge due nuovi test e aggiorna un test esistente per confermare che gli script conavi pubbliche non valide siano respinti da ogni percorso di validazione, incluso un caso di transazione completa con witness hash non corrispondenti.
- •Non è stata segnalata alcuna exploitation confermata su Neo N3 MainNet, e la correzione ha effetto solo sui nodi che eseguono la release patchata, rendendo l'adozione da parte degli operatori il prossimo passo chiave.

Neo ha rilasciato Neo N3 v3.10.2, una patch di sicurezza mirata che chiude un bypass della verifica dei witness che in precedenza consentiva a script multisignature malformati di superare un percorso di validazione mentre ne venivano respinti da un altro. Per gli utenti comuni, la correzione elimina una via attraverso cui una transazione non valida poteva apparire valida a una parte del software del nodo.
Il rilascio, opera del co-fondatore di Neo Erik Zhang, è stato pubblicato il 23 ottobre. Contiene una singola correzione logica alla logica di validazione dei contratti multisignature di Neo N3, senza nuove funzionalità.
Cosa affronta la correzione
Quando una transazione viene inviata alla rete Neo N3, il protocollo verifica che le firme allegate siano valide e provengano dalle parti corrette. Questi dati di autorizzazione — le firme e i controlli allegati a una transazione — sono ciò che il protocollo chiama witness, ed è il livello che questa patch rafforza. Per i contratti multisignature, che richiedono un numero minimo di firmatari autorizzati per approvare una transazione e sono comunemente usati ovunque più parti condividano il controllo degli stessi fondi, tale verifica include il controllo che ogni chiave pubblica elencata nello script del contratto sia crittograficamente valida.
La patch chiude una lacuna nel modo in cui tale controllo veniva applicato. La logica di validazione multisig di Neo N3 includeva più percorsi di codice per ispezionare uno script multisig. Uno di questi percorsi decodificava completamente ogni chiave pubblica, un processo che respingeva immediatamente qualsiasi chiave che non fosse un punto valido sulla curva ellittica. Un secondo percorso controllava solo la struttura dello script — le lunghezze in byte corrette e il numero corretto di chiavi — senza eseguire la decodifica crittografica. Uno script contenente una chiave pubblica malformata poteva quindi superare il secondo percorso e fallire il primo, lasciando i due percorsi in disaccordo sulla validità dello script. Questo tipo di disaccordo va contro una proprietà di base che la validazione blockchain dovrebbe garantire: lo stesso script produrre lo stesso esito indipendentemente dal percorso di codice che lo ispeziona.
L'incoerenza non era sconosciuta. Il comportamento era documentato nella suite di test di Neo stessa dal 2024, quando la sviluppatrice di Neo SPCC Anna Shaleva ha trasferito nuovo codice di verifica dei witness da NeoGo al nodo di riferimento C#. Un test aggiunto in quella pull request segnalava l'overload basico di IsMultiSigContract come "sfortunato" per aver saltato la decodifica delle chiavi, ma trattava il risultato come comportamento previsto e non come un difetto. Le due implementazioni in gioco — il nodo di riferimento C# e NeoGo — sottolineano perché un comportamento uniforme è importante: su una rete mantenuta in più di un'implementazione di nodo, ognuna deve giudicare allo stesso modo la stessa transazione.
La correzione risolve la discrepanza. Ora tutti i percorsi della logica di validazione impongono la decodifica completa delle chiavi prima di classificare uno script come contratto multisig valido.
Correzione e copertura dei test
La modifica è una piccola correzione a src/Neo/SmartContract/Helper.cs. La fix decodifica la chiave ogni volta, così ogni percorso che ispeziona uno script multisig esegue ora lo stesso controllo.
Il commit aggiunge due nuovi test e aggiorna un test esistente. Il primo nuovo test passa uno script multisig con una chiave pubblica danneggiata a tutti e tre i percorsi di validazione e conferma che ciascuno lo respinge. Il secondo costruisce una transazione completa con un witness multisig danneggiato e conferma che la rete la rifiuta. Quel test viene eseguito due volte — una con l'indirizzo del firmatario corrispondente al witness e una con una mancata corrispondenza — coprendo il caso dei "mismatched witness hashes" indicato nelle note di rilascio.
Il test aggiornato, TestIsMultiSigContract_WrongCurve, si aspettava in precedenza che il percorso scorciatoia accettasse script con chiavi non valide. Ora si attende che tutti e tre i percorsi li respingano, consolidando il comportamento corretto nella suite contro future regressioni.
Jimmy Liao, sviluppatore core di Neo e fondatore di R3E Network, ha descritto il rilascio su X:
Neo N3 v3.10.2 — security release. Fixes a witness-verification bypass from inconsistent public-key validation between
IsMultiSigContractoverloads. Keys are now validated before multisig classification.
Nessun exploit noto
Nessun advisory di sicurezza formale è stato pubblicato insieme al rilascio. Né le note di rilascio né il messaggio di commit descrivono alcuna exploitation confermata su Neo N3 MainNet.
Gli operatori dei nodi e i fornitori di infrastruttura che eseguono Neo N3 dovrebbero aggiornare alla v3.10.2 — trattandosi di una correzione lato client, il suo controllo più restrittivo ha effetto solo sui nodi che eseguono effettivamente la release patchata, il che rende l'adozione da parte degli operatori il prossimo passo concreto da monitorare. Il rilascio completo è disponibile su GitHub.