Il test di decentralizzazione di Cardano va oltre il numero di nodi

Nick Regan, cofondatore e conduttore di Cheeky Crypto, ha pubblicato un'analisi di 24 minuti su un rischio meno visibile all'interno della decentralizzazione di Cardano, software sviluppato in modo indipendente che può non essere d'accordo sulle regole della rete. Cheeky Crypto è una piattaforma di analisi ed educazione crypto fondata nel 2020 da Nick e Chris Regan.

Regan ha collegato la sua analisi a CPS-0034, una Cardano Problem Statement aperta che propone l'espansione dei test di conformità per i valutatori di Plutus Core usati dalle implementazioni alternative dei nodi Cardano. La discussione va oltre la distribuzione dei pool di staking, la partecipazione alla governance e il numero di macchine connesse alla rete.

Più client non aumentano automaticamente la sicurezza

Regan distingue tra la distribuzione fisica di una rete e la distribuzione del suo software. Cardano può avere migliaia di nodi gestiti da entità diverse in più paesi, mentre gran parte di tale infrastruttura fa ancora affidamento sulla stessa implementazione del nodo core.

Se un'implementazione comune contiene un difetto critico per il consenso, un gran numero di nodi distribuiti geograficamente potrebbe incontrare lo stesso problema simultaneamente. I client alternativi riducono tale concentrazione consentendo a team separati di usare linguaggi di programmazione, architetture e decisioni ingegneristiche diversi.

Un altro rischio emerge quando tali implementazioni interpretano il protocollo in modo diverso.

Un client potrebbe accettare una transazione che un altro rifiuta. Due valutatori di Plutus potrebbero elaborare lo stesso script ma restituire risultati diversi o calcolare costi di esecuzione differenti. Poiché la validità di un blocco può dipendere da tali esiti, il disaccordo tra i nodi potrebbe produrre un fork della catena invece che una maggiore resilienza.

UPLC, ovvero Untyped Plutus Core, è il linguaggio di esecuzione in cui vengono compilati gli smart contract di Plutus. Un valutatore alternativo non deve riprodurre la struttura dell'implementazione Haskell consolidata di Cardano, ma deve riprodurre il comportamento rilevante per il consenso atteso dal protocollo.

Regan descrive tale requisito come una necessità di accordo indipendente.

Codebase separate forniscono una ridondanza significativa solo quando raggiungono in modo coerente la stessa risposta per input validi, casi limite e versioni storiche del protocollo.

Regan usa il titolo “ADA Has a Decentralisation Problem” per distinguere questo rischio a livello di software dai dibattiti sulla decentralizzazione che la maggior parte dei detentori incontra. La sua analisi si concentra su lavori infrastrutturali preventivi piuttosto che su un incidente già avvenuto in mainnet.

CPS-0034 estende i test di conformità di Plutus Core

Il team di Plutus Core ha aperto la proposta alla revisione pubblica il 12 agosto. I redattori CIP le hanno successivamente assegnato il numero CPS-0034 a seguito della revisione iniziale, mentre la proposta tecnica rimane aperta ai commenti.

Secondo la proposta CPS-0034, Cardano fornisce attualmente agli sviluppatori esterni circa 1.000 test golden file predefiniti. Questi consentono a un valutatore indipendente di eseguire uno script fornito e confrontarne l'output con il risultato atteso.

La suite esistente fornisce un controllo iniziale di compatibilità ma presenta due limitazioni individuate. Non espone i test basati su proprietà usati internamente dal team di Plutus e copre solo l'ultima combinazione di versione del protocollo, versione del linguaggio del ledger e modello di costo.

I test basati su proprietà vanno oltre una piccola raccolta di esempi preparati manualmente. Un generatore può produrre centinaia o migliaia di input variati, costruire da essi script Plutus e verificare se le proprietà comportamentali definite continuano a valere.

Questo approccio amplia la copertura su combinazioni inusuali, valori di confine e condizioni che possono apparire raramente durante l'attività normale. Sono anche le situazioni in cui implementazioni sviluppate in modo indipendente hanno maggiori probabilità di rivelare assunzioni diverse sul comportamento del protocollo.

CPS-0034 propone di distribuire i casi di test generati in un formato portabile che le implementazioni esterne possano consumare con lavoro di integrazione minimo. Ogni test potrebbe contenere il programma, i suoi input, il risultato atteso e, ove applicabile, il budget di esecuzione atteso.

È inclusa anche la copertura storica. Cardano ha attraversato più ere del ledger, hard fork, versioni del linguaggio Plutus e cambi di modello di costo. Un nodo alternativo deve interpretare correttamente tale storia se ci si aspetta che riproduca la catena e convalidi i blocchi precedenti.

La proposta è specificamente focalizzata sulla conformità dei valutatori di Plutus Core. Non definisce un framework di test completo per ogni componente di rete, ledger e consenso all'interno di un nodo Cardano. La sua rilevanza per la sicurezza del nodo deriva dal fatto che risultati diversi della valutazione degli script possono cambiare se una transazione o un blocco è considerato valido.

Il codice indipendente deve dimostrare un comportamento coerente

CPS-0034 contiene ancora diverse questioni tecniche aperte. Gli sviluppatori stanno discutendo come distribuire i test generati, come riportare le differenze tra risultati attesi e reali, come filtrare i casi per versione del protocollo e come eseguire migliaia di test in modo efficiente.

Gli sviluppatori collegati ad Amaru si sono già uniti alla discussione pubblica. Amaru è un client open source del nodo Cardano scritto in Rust, che fornisce agli operatori un'implementazione sviluppata separatamente dal consolidato cardano-node in Haskell.

Un contributor di Amaru ha riferito che il progetto consuma già le suite di conformità semantiche e flat esistenti. Il feedback ha supportato test più ampi basati su proprietà e su versioni, richiedendo al contempo scenari on chain realistici, formati dati neutrali rispetto al client e un percorso semplice per consentire a terze parti di contribuire con casi aggiuntivi.

Gli approcci suggeriti includevano fixture di test strutturate e la marcatura dei casi in base alle versioni di protocollo e linguaggio che coprono. La discussione ha anche sollevato preoccupazioni sull'implementazione del generatore esclusivamente in Haskell, perché ciò potrebbe creare una barriera aggiuntiva per i team che lavorano in altri linguaggi.

Uno standard di test condiviso non richiederebbe codice sorgente identico. Ogni team potrebbe mantenere la propria architettura, il proprio linguaggio di programmazione e il proprio approccio di sviluppo, mentre il comportamento di esecuzione risultante resterebbe compatibile con le regole di Cardano.

Per i detentori di ADA, la questione riguarda la resilienza dell'infrastruttura più che le prestazioni di mercato nel breve periodo. Exchange, wallet, applicazioni decentralizzate e sistemi istituzionali dipendono dal fatto che nodi diversi raggiungano decisioni deterministiche su transazioni, script e blocchi.

Se CPS-0034 produrrà una suite di conformità portabile e consapevole delle versioni, un client Cardano alternativo non dimostrerà più la compatibilità solo esistendo come codebase separata. Sarà in grado di fornire prove riproducibili che software scritto in modo indipendente raggiunge lo stesso risultato e lo stesso costo di esecuzione attraverso la storia del protocollo di Cardano, esponendo i disaccordi durante i test prima che possano raggiungere un blocco live.