Cardano cerca uno standard per il software dei produttori di blocchi

Un Cardano Problem Statement sta cercando un metodo condiviso per identificare il software utilizzato per produrre i singoli blocchi. La discussione su CPS-0036 è stata aperta il 2 settembre e ha ricevuto l’etichetta Confirmed il 16 settembre, ma la proposta rimane aperta e non stabilisce uno standard tecnico.

Il suo scopo è definire il problema prima che una Cardano Improvement Proposal separata specifichi il formato di segnalazione, il registro del software e le regole di implementazione.

Cardano si espande oltre una singola implementazione del nodo

Cardano si è storicamente basato sul cardano-node basato su Haskell, mentre ulteriori implementazioni sono ora in fase di sviluppo sotto le stesse regole di consenso. CPS-0036 menziona Amaru e Dingo e la discussione sulla proposta fa riferimento anche a Gerolamo.

In questo contesto, un client è il software del nodo che valida il protocollo di Cardano e può partecipare alla produzione dei blocchi. È distinto dai wallet e da altre applicazioni usate per interagire con la rete.

Implementazioni indipendenti possono migliorare la resilienza perché un difetto che interessa una codebase può non esistere in un’altra. Tale beneficio dipende dall’adozione. Se un client continua a produrre la maggior parte dei blocchi, la rete rimane operativamente dipendente da quella implementazione anche quando sono disponibili alternative.

Attualmente Cardano non ha un campo standardizzato che attribuisca ogni blocco al software che lo ha creato. Ricercatori, block explorer e piattaforme di monitoraggio devono stimare indirettamente la distribuzione dei client, producendo dataset che possono essere incompleti o difficili da confrontare.

L’attività sulla rete ha reso la questione più immediata. Il revisore yHSJ ha affermato che Dingo e Gerolamo hanno già prodotto blocchi utilizzando il campo della versione minore del protocollo come identificatore del software, mentre Amaru prevede di seguire lo stesso approccio.

CPS-0036 delinea una segnalazione software volontaria

CPS-0036 richiede un meccanismo compatto, volontario e neutro rispetto al consenso. I blocchi senza un identificatore del software rimarrebbero validi e ogni operatore di stake pool deciderebbe se pubblicare l’informazione.

La discussione descrive due approcci esistenti. Uno utilizza quattro byte dal campo della versione minore del protocollo nell’intestazione del blocco. L’altro utilizza una transazione marcatore di circa 60 byte. Senza una specifica comune, le implementazioni potrebbero adottare formati diversi e costringere i fornitori di infrastruttura a mantenere regole di decodifica separate.

La proposta richiede anche un registro a governance aperta che assegni un identificatore riconoscibile a ciascuna implementazione. I block explorer, i ricercatori e le dashboard potrebbero quindi interpretare il segnale in modo coerente su tutta la rete.

L’identità del client è il primo caso d’uso proposto. In seguito il meccanismo potrebbe supportare dichiarazioni sulla disponibilità delle funzionalità o sulla prontezza del software prima degli aggiornamenti del protocollo.

Diverse questioni di progettazione restano irrisolte. Un identificatore autodichiarato può essere falsificato, mentre vincolarlo crittograficamente alle credenziali KES o VRF aggiungerebbe complessità. Pubblicare versioni software dettagliate potrebbe anche esporre operatori che eseguono release vulnerabili. Qualsiasi specifica dovrebbe rimanere compatibile con Leios e la sua struttura del blocco in evoluzione.

I dati sui client potrebbero rafforzare il monitoraggio della rete di Cardano

Un identificatore standard consentirebbe a Cardano di misurare la diversità dei client dichiarata direttamente dai blocchi prodotti. Gli operatori di rete e i ricercatori potrebbero calcolare la quota associata a ciascuna implementazione, identificare un affidamento eccessivo su una sola codebase e verificare se i client alternativi stiano entrando nell’infrastruttura attiva.

I dati potrebbero anche supportare gli aggiornamenti del protocollo. Se in seguito lo standard includesse la prontezza delle funzionalità, l’ecosistema potrebbe ottenere una visione a livello di rete prima di un hard fork o di una major release del software. Test e coordinamento rimarrebbero processi separati, mentre il segnale on chain fornirebbe un insieme di dati operativo comune.

La discussione indica che si potrebbe già stare formando una convenzione pratica attorno al campo della versione minore del protocollo. L’editor CIP Robert Phair ha affermato che una CIP orientata alla soluzione basata sulla pratica attuale potrebbe fornire un percorso più diretto rispetto a documentare solo il problema.

La segnalazione software non può creare diversità tra i client né prevenire i guasti, ma può rendere l’infrastruttura di Cardano più facile da misurare. Se adottato, lo standard consentirebbe ai block explorer e agli strumenti di monitoraggio di sostituire stime frammentate con dati coerenti a livello di blocco su quale client dichiarato stia producendo i blocchi della rete.