Skip to main content
IntentionBFT è il protocollo di consenso di Intention: un protocollo BFT della famiglia HotStuff esteso per l’infrastruttura finanziaria. La safety vale incondizionatamente sotto la soglia di guasti; la liveness vale dopo che la rete si è stabilizzata. Qui il consenso fa due cose che il consenso di una catena generalista non fa: conferma un ordinamento come oggetto di prima classe e conferma un vettore di prezzi certificati nello stesso evento. Tutto ciò che il kernel può garantire sull’esecuzione dipende dal fatto che entrambi siano stabiliti prima che l’esecuzione cominci.

​
Il modello

IntentionBFT tollera un avversario bizantino che controlla fino a un terzo dello stake totale. Lo stake onesto è quindi sempre più di due terzi, e il quorum standard è un qualunque insieme di validatori il cui stake combinato supera i due terzi: ciò che queste pagine chiamano quorum 2f+12f+1 pesato per stake. La rete è parzialmente sincrona: prima di un punto di stabilizzazione i ritardi sono arbitrari; dopo, i ritardi tra validatori onesti sono limitati.
Sidecar oracolouno per validatore
Il validatore valida e firmacompresa la freschezza rispetto a soglie configurate
Gossip tra validatorimessaggio della rete di consenso
Prezzi certificatiper epoch e round
La disponibilità del prezzo condiziona i blocchiUn validatore è idoneo a proporre un blocco solo se può presentare osservazioni di prezzo valide per il round corrente — così le firme che confermano le transazioni confermano anche i prezzi contro cui vengono regolate.
Che cosa non garantisceLega il prezzo alla transazione; non rende il prezzo corretto. Il consenso certifica che un quorum di validatori ha inviato queste osservazioni in questo round, nulla di più.
Ogni round ha un leader designato. All’interno di un round una proposta raccoglie successivi aggregati di firme 2f+12f+1, e le fasi si sovrappongono in pipeline tra round adiacenti, così nel caso comune un blocco raggiunge la definitività in due round-trip di rete. In regime di optimistic responsiveness il progresso è limitato dal ritardo effettivo dei messaggi; il backoff del pacemaker entra in gioco solo quando la rete è ostile o partizionata.

​
Confermare un ordinamento

L’ordine delle transazioni dentro un blocco è promosso a oggetto confermato dal consenso invece di restare un artefatto dell’esecuzione. L’hash del blocco copre il payload ordinato, quindi qualunque riordino successivo al consenso invalida le firme che lo hanno confermato. L’effetto: una volta che un blocco è finalizzato, un quorum 2f+12f+1 pesato per stake ha firmato un impegno su quell’esatto ordinamento, e nessun validatore onesto avrà firmato un ordinamento diverso delle stesse transazioni nello stesso round. Unito all’esecuzione sequenziale su quell’ordine confermato, è questo a trasformare il replay deterministico da convenzione implementativa a proprietà che chiunque può verificare.
La discrezionalità del leader dentro una singola proposta — quali batch disponibili includere e come disporli — resta una superficie di attacco residua, mitigata dalla reputazione del leader e dal fatto che senza osservazioni di prezzo valide un leader non può produrre alcun blocco. Costruzioni di fair ordering più forti sono in valutazione come possibile aggiornamento futuro.

​
Disponibilità dei batch

In un protocollo ingenuo il leader propone un blocco il cui payload porta tutte le transazioni del round, legando la dimensione dei messaggi di consenso al throughput. IntentionBFT separa la diffusione dei dati dall’ordinamento. I validatori diffondono in continuo batch di transazioni in background. Ogni batch continua a raccogliere conferme finché chi lo ha originato non può dimostrare una disponibilità 2f+12f+1 pesata per stake, e solo allora una proposta può farvi riferimento — tramite digest, non tramite contenuto. I messaggi di consenso restano piccoli indipendentemente dal throughput, e un blocco confermato è sempre rieseguibile, perché nessun blocco può riferirsi a dati detenuti dalla sola minoranza bizantina.

​
Certificare i prezzi

I validatori sono anche osservatori di prezzo, e un blocco porta con sé i prezzi contro cui è stato eseguito.
Validatoriconsenso · mempool · sidecar oracolo · kernel · archiviazione
Gli unici partecipanti che votano
Full node dei validatoriseguono ed eseguono i blocchi confermati; non votano
Isolamento — assorbono il traffico pubblico di lettura e le connessioni dei peer, così i validatori non sono esposti alla rete aperta
Full node pubblicichiunque può gestirne uno; seguono, eseguono, servono letture
Il livello aperto
Clientfront end · agenti di trading · market maker · indexer
Si collegano ai full node, mai ai validatori. Un client che vuole la vista più completa e a latenza più bassa ne gestisce uno.
Quattro livelli, dal consenso in fuori
Perché il livello esiste
Ogni validatore esegue il proprio sidecar dell’oracolo, che raccoglie i dati delle sedi di negoziazione e produce un prezzo indice per strumento. Il validatore preleva quel prezzo, lo valida — compresa la freschezza rispetto a soglie configurate — lo firma e lo diffonde in gossip agli altri validatori come messaggio della rete di consenso. I prezzi certificati vengono assemblati per epoch e round e portati nel blocco, così le firme che confermano le transazioni confermano anche i prezzi contro cui quelle transazioni vengono regolate. Un validatore è idoneo a proporre un blocco solo se può presentare osservazioni di prezzo valide per il round corrente. La disponibilità del prezzo è quindi una precondizione della produzione dei blocchi, non un input che l’esecuzione spera di trovare.
Questo lega il prezzo alla transazione; non rende il prezzo corretto. Il consenso certifica che un quorum di validatori ha inviato queste osservazioni in questo round. Se le sedi di negoziazione sottostanti siano state accurate è un’altra questione, affrontata dalle regole di aggregazione nella pagina Oracolo e delimitata dall’informativa sui rischi.

​
Reputazione del leader

I leader vengono selezionati round per round con una rotazione deterministica pesata per stake, estesa da un’euristica di reputazione su una finestra scorrevole. Un validatore con proposte fallite ripetute — segno di indisponibilità o di comportamento ostile — viene retrocesso nelle selezioni successive e i suoi slot ridistribuiti a validatori che hanno risposto di recente, così un validatore non disponibile non manda in stallo il progresso rivendicando la leadership degli slot che gli spettano. Poiché le osservazioni di prezzo condizionano l’idoneità a proporre, la reputazione deve anche evitare di concentrare la leadership tra i validatori con la migliore connettività ai dati di mercato. Un requisito di diversità delle sedi di negoziazione — osservazioni tratte da più fonti indipendenti per ogni strumento — chiude quella strada.

​
Epoch e riconfigurazione

Il tempo è organizzato in epoch. All’interno di un’epoch il set di validatori e la maggior parte dei parametri restano costanti. Ai confini tra epoch possono cambiare tramite una riconfigurazione autorizzata dalla governance: modifiche al set di validatori, modifiche ai parametri di consenso, aggiornamenti dei parametri di rischio e azioni d’emergenza. Le transizioni sono atomiche: ogni validatore onesto vede la stessa transizione alla stessa altezza di blocco.

​
Topologia della rete

Leader
Validatori
Catena
Aggregato 2f+1 pesato per stake
Ordinamento e prezzi ora sono immutabili
Propone il blocco — digest dei batch e prezzi certificati
Verifica disponibilità, ordinamento, prezzi
Voto
Certifica il round
Conferma
I validatori partecipano al consenso. Ognuno esegue l’intero stack: consenso, mempool, un sidecar dell’oracolo, l’esecuzione del kernel e l’archiviazione. Sono gli unici partecipanti che votano. I full node dei validatori stanno subito dietro ai validatori. Seguono i blocchi confermati e li eseguono, ma non votano. Il loro scopo è l’isolamento: assorbono il traffico pubblico di lettura e le connessioni dei peer, così i validatori non sono esposti direttamente alla rete aperta. I full node pubblici sono il livello aperto. Chiunque può gestirne uno. Seguono la catena, eseguono i blocchi confermati, servono le letture e alimentano i sistemi a valle. I client — front end, agenti di trading, market maker, indexer — si collegano ai full node, non ai validatori. Un client che ha bisogno della vista più completa e a latenza più bassa gestisce un proprio full node invece di dipendere da quello di qualcun altro. I nodi che entrano in rete non rieseguono dal blocco genesi per impostazione predefinita; vedi sincronizzazione dello stato per come un nuovo nodo si mette in pari.

​
Dove proseguire

Mempool

Che cosa arriva al consenso, in quale ordine e che cosa viene scartato.

IntentionKernel

Che cosa succede a un blocco una volta confermati ordinamento e prezzi.

Oracolo

Come viene prodotto un prezzo indice prima che un validatore lo firmi.

Gestire un nodo

Perché il set di validatori è chiuso e come chiedere di entrare.