Sicurezza e architettura
La sicurezza di ZooBC poggia su firme e hash, non sull'energia consumata. Ogni blocco, transazione, ricevuta e prova del seed è firmato, e ogni nodo verifica tutto ciò che accetta, quindi nessun nodo deve fidarsi sulla parola di un altro. Attorno a questo nucleo, l'architettura aggiunge alcuni limiti rigidi: la cronologia consolidata non può essere riscritta, un nuovo nodo può trovare da solo la catena autentica e una firma vale su una sola catena.
L'attaccante che ZooBC mette in conto
Il progetto presuppone un attaccante in grado di gestire un numero qualsiasi di nodi e account, che vede ogni messaggio, sfrutta qualsiasi difetto logico ed è ricco, ma che non può falsificare firme, trovare collisioni di hash o comprare ogni token. I suoi obiettivi sarebbero rubare, censurare, riscrivere la cronologia o disturbare la catena. Da cosa si difende il Proof of Participation esamina ogni attacco e la relativa risposta.
Due catene in ogni nodo
Ogni nodo mantiene due catene. La catena principale produce un blocco ogni 15 secondi e contiene le transazioni; i suoi blocchi sono prodotti da nodi registrati estratti a sorte (vedi Proof of Participation). La catena spine produce un blocco al giorno su mainnet e non contiene transazioni: ogni blocco è un checkpoint della catena principale, una registrazione delle chiavi dei nodi entrate o uscite e i manifest degli snapshot di stato più recenti, co-firmato da due terzi dei seggi.
Livelli di difesa
| Livello | Che cosa garantisce | Articolo |
|---|---|---|
| validazione da parte di ogni nodo | un blocco conta solo se lo ha firmato il produttore estratto e se la prova del seed, le transazioni e le ricevute sono corrette | Proof of Participation |
| seggi uguali e cadenzati | il potere non si compra in fretta: una possibilità uguale per seggio, un'ammissione per ciclo | Da cosa si difende il Proof of Participation |
| rollback limitato | nessun nodo fa rollback di più di 720 blocchi (3 ore) | Finalità e rollback |
| checkpoint della spine | nessun nodo si riorganizza sotto un checkpoint co-firmato da due terzi dei seggi | La catena spine |
| fast sync verificato | un nuovo nodo carica lo stato indicato dalla spine, verifica ogni hash e interroga a campione i suoi peer | Snapshot e fast sync |
| pin della release | una nuova installazione rifiuta una cronologia della spine che contraddice la sua release | Il pin della release |
| firme legate alla catena | una transazione firmata per una catena viene rifiutata su ogni altra | Firme legate alla catena |
| decisioni dei due terzi | checkpoint, trasferimenti del bridge, fatti degli oracoli e veti sulle release richiedono due terzi dei seggi | Le regole dei due terzi |
| seed imprevedibili | nessun produttore può scegliere la casualità che sceglie il produttore successivo | Il seed del blocco (VRF) |
| segnalazioni di doppia firma | un produttore che firma due blocchi sullo stesso padre viene smascherato e sanzionato | Doppia firma (equivocazione) |
I livelli si sovrappongono. Una riscrittura della cronologia a partire da un anno prima, per esempio, fallisce di per sé a ciascuno di più livelli: il limite di rollback, la soglia dei checkpoint, le co-firme della spine e il pin della release.
Che cosa potrebbe e non potrebbe fare una maggioranza
Anche un attaccante che detenesse più della metà dei seggi potrebbe solo ritardare o censurare transazioni e sostituire blocchi recenti entro il limite di 3 ore. Non potrebbe falsificare firme, spendere le monete altrui, coniare più del piano della coinbase o scendere sotto il checkpoint della spine, perché ogni nodo verifica ogni blocco da sé.
Su che cosa non si basa la sicurezza di ZooBC
- Sulla segretezza. Il traffico tra peer è semplice gRPC; la protezione viene da firme e verifiche.
- Su energia o hardware. Non si risolve alcun enigma e nessuna macchina dà un vantaggio.
- Su una parte fidata. Nessuna fondazione controfirma i blocchi, nessun sito web garantisce gli snapshot, e un solo peer onesto basta per conoscere la catena più pesante.
Vedi anche
Articoli su questo argomento
- Da cosa si difende il Proof of Participation
L'attaccante a cui ZooBC è progettata per resistere, e come il Proof of Participation risponde a ogni attacco: potere comprato, seggi Sybil, una maggioranza, giochi sul seed, riscritture long-range ed eclipse. - Finalità e rollback
Fino a dove un nodo ZooBC fa rollback per seguire un ramo più pesante (720 blocchi, 3 ore), perché non scende mai sotto il checkpoint della spine e come si ricostruisce un nodo rimasto isolato. - Firme legate alla catena
Perché una transazione firmata per una catena ZooBC non può essere riprodotta su un'altra: ogni firma copre l'hash genesi della catena, l'unica identità che una catena ZooBC possiede. - Il pin della release
Il pin che una release ZooBC può includere: una riga pubblica che indica un blocco spine per altezza e hash, e che un nodo verifica all'avvio per non funzionare mai su una cronologia della spine falsificata. - La catena spine
La lenta seconda catena che ogni nodo ZooBC mantiene: un blocco al giorno, co-firmato da due terzi dei seggi, con i checkpoint della catena principale, i cambi delle chiavi dei nodi e i manifest degli snapshot. - Le regole dei due terzi
Quali decisioni di ZooBC richiedono due terzi dei seggi registrati (blocchi spine, trasferimenti del bridge, fatti degli oracoli, veti sulle release, aggiornamenti delle regole), come contano i seggi sospesi e che cosa non richiede alcun voto. - Snapshot e fast sync
Come un nuovo nodo ZooBC arriva al presente senza riprodurre ogni blocco: snapshot mensili dello stato indicati nella spine, verificati porzione per porzione e confrontati con i peer.