Evoluzione di Kadena, la prima vera blockchain privata

George Samman è un consulente e advisor specializzato in blockchain e Criptovaluta , che di recente è stato coautore di un rapporto fondamentale sull'architettura blockchain con KPMG.

Qui Samman spiega come l'algoritmo di consenso elaborato da Raft sia stato infine perfezionato dal suo lontano parente, Kadena.

Questo articolo riguarda la blockchain di Kadena. Utilizza ScalableBFT per offrire alte prestazioni (8.000-12.000 transazioni al secondo) con replicazione e distribuzione complete a scale precedentemente impossibili (capacità per oltre 500 nodi partecipanti).

Questo, insieme al modello di sicurezza multistrato e all'hashing incrementale, consente una blockchain veramente solida. Basato su Raft e Juno, Kadena incorpora un linguaggio completo per smart contract (Pact) nella sua blockchain che può essere eseguito come transazioni pubbliche (testo normale) o private (crittografia a doppio cricchetto).

Si tratta di un enorme passo avanti nel settore blockchain, che probabilmente rappresenta una nuova generazione di Tecnologie blockchain interamente attraverso l'introduzione dell'idea di "determinismo pervasivo".

Simile a Bitcoin, la blockchain di Kadena è strettamente integrata e comprendere di cosa è capace e cosa implicano queste capacità richiede di coprire una notevole quantità di terreno. Pertanto, ho suddiviso l'articolo in tre parti: 1) Introduzione e Zattera, 2) I predecessori di Kadena –TangaroaeGiunonee 3) Blockchain di Kadena – ScalableBFT, Pact e determinismo pervasivo.

Parte 1: Introduzione e algoritmo di consenso Raft

La storia di Kadena è un interessante caso di studio nel nuovo campo degli algoritmi di consenso blockchain e del calcolo distribuito.

Kadena è un "parente lontano" del Algoritmo di consenso RaftIl meccanismo di consenso Raft è stato seguito daTangaroa(una zattera tollerante ai guasti bizantini (BFT)) e il progetto JP MorganGiunone(una diramazione di Tangaroa), nessuna delle quali è più in fase di sviluppo attivo.

La nuova blockchain Quorum di JP Morgan

è molto diverso da Juno e utilizza una fusione di idee provenienti da sidechain ed Ethereum : sulla blockchain sono consentiti contratti intelligenti pubblici oltre ai contratti privati, che sono rappresentati come hash crittografati e replicati tramite canali laterali.

Kadena è la "nuova generazione di Juno". Utilizza un nuovo protocollo, ma correlato, chiamato ScalableBFT, generato dal codice open source del progetto Juno e sviluppato dai due sviluppatori chiave che hanno creato Juno. Prima di immergerci in Kadena, è necessario discutere una breve storia e descrizione di Raft e dei predecessori di Kadena .

Consenso della zattera

L'algoritmo di consenso Raft è un sistema basato su un singolo leader per la gestione di un log replicato. Utilizza un'architettura di macchina a stati replicati e produce un risultato equivalente a Paxos, ma è strutturalmente diverso.

Mantenere il log replicato coerente è compito dell'algoritmo di consenso. In questo modello, il leader fa la maggior parte del lavoro perché sta emettendo tutti gli aggiornamenti del log, convalidando le transazioni e gestendo in generale il cluster. Il consenso Raft garantisce un ordinamento e una replicazione rigorosi dei messaggi. Non gli importa cosa contengono i messaggi.

Un nuovo leader viene eletto tramite timeout randomizzati, che vengono attivati se un follower non riceve alcuna comunicazione dal leader prima che il timeout venga attivato. Questi sono chiamati "heartbeat".

Se il follower non riceve alcuna comunicazione in questo periodo di tempo, diventa un candidato e avvia un'elezione. Un candidato che riceve voti dalla maggioranza del cluster completo (nodi nella rete) diventa il nuovo leader. I leader in genere operano finché non falliscono. Gli heartbeat vengono inviati per assicurarsi che il leader sia ancora lì; se non viene ricevuto nulla, si verifica una nuova elezione.

Le fasi seguenti illustrano come Raft giunge al consenso:

• Viene avviato un cluster di server di nodi Raft con ogni nodo avviato come "Follower". Alla fine, ONE nodo scadrà, diventerà un candidato, otterrà la maggioranza dei voti e diventerà il leader.
• Ogni nodo memorizza un log contenente i comandi. È compito del Leader accettare nuovi comandi, ordinare rigorosamente i comandi nel suo log, replicare il suo log ai suoi follower e infine informare i follower quando eseguire il commit dei log che hanno replicato. L'algoritmo di consenso assicura quindi che i log di ogni server siano nello stesso ordine.
• I log vengono "commitati" quando sono stati replicati sulla maggioranza dei nodi. Il leader raccoglie il conteggio delle repliche e, quando viene visualizzata la maggioranza, esegue il commit delle proprie nuove voci di log e informa i propri follower di fare lo stesso.
• Al momento del "commit", il comando in ogni voce di log viene valutato da una macchina a stati. Poiché Raft è indifferente al corpo del comando, qualsiasi macchina a stati può elaborare voci committate. Inoltre, il consenso assicura che l'esecuzione del comando avvenga sempre nello stesso ordine in cui i comandi provengono dal Log, che è rigorosamente ordinato.
• Le macchine a stati rimarranno coerenti finché le esecuzioni dei comandi saranno deterministiche.
• Quando un client invia un comando a ONE dei server, quel server inoltrerà il comando al leader o sarà il leader. Il leader raccoglie il nuovo comando, gli assegna un indice di registro, lo incapsula in una voce di registro e aggiunge il comando alla parte non impegnata del suo registro.
• Ogni volta che il leader ha voci non impegnate, replica questa porzione del log ai suoi follower. Quando il leader viene informato della replicazione riuscita dalla maggioranza del cluster, impegna le nuove voci e ordina ai suoi follower di fare lo stesso.
• Ogni volta che viene eseguita una nuova voce di log, si è raggiunto un consenso su questa voce. Viene quindi valutata dalla macchina a stati su ogni server.
• Da questo punto in poi, Raft è terminato e gli implementatori possono decidere come gestire le risposte: rispondere al client o attendere che il client richieda il risultato.

Le risposte al client sono generalmente asincrone.

Il protocollo di consenso Raft è proprio questo: un algoritmo di consenso. Non ha una nozione di ed è, di default, completamente aperto a qualsiasi client che emetta comandi. L'unica restrizione di partecipazione che impone è su quali nodi esistono in un dato momento.

Inoltre, il leader ha autorità assoluta sul cluster e ordina ai follower di replicare e impegnarsi. Non presuppone attacchi bizantini, deve solo gestire i crash fault, perché i nodi sono considerati altruistici.

Parte 2: I predecessori di Kadena: Tangaroa e Giunone

Tangaroa: il primo passo verso un Raft BFT

Tangaroa è una variante Byzantine Fault Tolerant (BFT) dell'algoritmo di consenso Raft, ispirata all'algoritmo Raft originale e all'algoritmo Practical Byzantine Fault Tolerance (PBFT).

La tolleranza ai guasti bizantini si riferisce a una classe di guasti causati da nodi dannosi che attaccano la rete. Se alcuni nodi vanno giù, è fondamentale che la rete continui a funzionare senza fermarsi.

In Raft standard, è necessario replicare una voce di registro alla maggior parte dei nodi nel cluster prima di eseguirne il commit. Per gli algoritmi di consenso BFT, incluso Tangaroa, la dimensione del cluster richiesta è almeno 2f + 1, dove f è il numero di errori che si desidera tollerare (inclusi sia i nodi bloccati che quelli compromessi). Il consenso si ottiene con un voto di maggioranza del cluster; se f <= 3, la dimensione del cluster = 7 e i nodi non bizantini = 4. Alcuni protocolli BFT possono persino richiedere 3f+1.

Un Leader Bizantino può decidere di aumentare arbitrariamente l'indice di commit di altri nodi prima che le voci di log siano state replicate a sufficienza, causando così violazioni della sicurezza quando i nodi falliscono in seguito. Tangaroa sposta la responsabilità del commit lontano dal leader e ogni nodo può verificare da sé che una voce di log è stata replicata in modo sicuro a un quorum di nodi e che questo quorum concorda su un ordinamento.

Tangaroa consente ai client di interrompere la leadership attuale se non riesce a fare progressi, nello stesso modo in cui altri algoritmi BFT Consensus consentono al client di comportarsi come un oracolo fidato per deporre determinati nodi. Ciò consente a Tangaroa di impedire ai leader bizantini di far morire di fame il sistema, ma si fida molto del client.

Elezione del leader e fasi

Tangaroa usa Raft come fondamento per il consenso; quindi c'è un singolo leader. In Tangaroa, come in Raft, ogni nodo è in ONE dei tre stati: leader, follower o candidato.

Simile a Raft, ogni nodo inizia come follower, ONE dei quali alla fine scadrà e indirà un'elezione. Il vincitore dell'elezione funge da leader per il resto del termine; i termini terminano quando viene eletto un nuovo leader. A volte, un'elezione si concluderà con un voto diviso e il termine terminerà senza un leader. In questo caso, un follower scadrà di nuovo (i timeout vengono ripristinati quando viene espresso un voto o viene indetta un'elezione) e ricomincerà il processo di voto.

Per iniziare un'elezione, un follower incrementa il suo termine attuale e invia RequestVote (RV)Chiamata di procedura remota (RPC)in parallelo a ciascuno degli altri nodi nel cluster che chiedono il loro voto. Gli RPC utilizzati da Tangaroa sono simili agli RPC di Raft, con l'eccezione che ogni RPC è firmato e convalidato tramite firme PPK.

Le RPC consentono lo scambio di dati tra diversi computer residenti in una rete e le firme consentono ai nodi riceventi di verificare quale nodo ha inviato la RPC, oltre a consentire a qualsiasi nodo di inoltrare la RPC di qualsiasi altro nodo in qualsiasi momento.

Quando un nodo Tangaroa riceve un RV RPC con una firma valida, concede un voto immediatamente solo se al momento non ha un leader (si verifica solo all'avvio). Altrimenti, inizia il processo che Tangaroa chiama "LazyVote".

Lo scopo di un LazyVote è proteggere i Follower non-Byzantine dall'eleggere un nuovo leader quando il leader non è difettoso; senza il lazy voting, un nodo byzantine potrebbe innescare elezioni ripetute in qualsiasi momento e far morire di fame il sistema. Quando un follower riceve un nuovo RV, salva il RV e attende che siano soddisfatte tutte le seguenti condizioni:

a) Il timeout di elezione del follower innesca incendi prima che gestisca un heartbeat dal suo attuale leader. Se viene ricevuto un heartbeat, il LazyVote viene cancellato.

b) La nuova durata del RV è maggiore della sua durata attuale.

c) Il mittente Request è un candidato idoneo (firma PPK valida e il client T ha bannato il nodo).

d) Il nodo che riceve la RV non ha votato per un altro leader per il mandato proposto.

e) Il candidato condivide un prefisso di log con il nodo che contiene tutte le voci impegnate. Un nodo rifiuta sempre la Request se sta ancora ricevendo messaggi heartbeat dal leader attuale e ignora l'RPC RequestVote se il termine proposto è già iniziato.

Se una RequestVote è valida e per un nuovo mandato, e il candidato ha un registro sufficientemente aggiornato, ma il destinatario sta ancora ricevendo heartbeat dall'attuale leader, registrerà il suo voto localmente e poi invierà una risposta di voto se il nodo stesso subisce un timeout elettorale o riceve da un client che l'attuale leader non risponde.

Con il voto pigro, un nodo non concede un voto a un candidato a meno che non ritenga che il leader attuale sia difettoso. Ciò impedisce ai nodi che avviano elezioni non necessarie di ottenere i voti necessari per diventare leader e far morire di fame il sistema.

I nodi aspettano finché non ritengono che sia necessario che si svolgano elezioni prima di esprimere un voto. Una volta inviato un voto, il nodo aggiornerà il suo numero di mandato. Tuttavia, non presume che il nodo per cui ha votato abbia vinto le elezioni e rifiuterà comunque gli RPC AppendEntries (AE) del candidato se nessuno di essi contiene un set di voti che dimostri che il candidato ha vinto le elezioni. Gli AE hanno il duplice scopo di heartbeat e di vettori di nuove voci di registro che necessitano di replicazione. Il candidato continua nello stato candidato finché non si verifica ONE delle tre cose:

a) Vince le elezioni ricevendo la maggioranza dei voti dal cluster. Un candidato deve salvare questi voti (RPC RequestVoteResponse (RVR)) per una futura distribuzione.

b) Un altro nodo si afferma come leader

c) Trascorre un periodo di tempo senza alcun vincitore (ad esempio: si verifica un altro timeout elettorale)

Un candidato che vince le elezioni si promuove quindi a stato leader e invia un messaggio heartbeat AE contenente i voti che lo hanno eletto e il numero di mandato aggiornato per stabilire la sua autorità e impedire nuove elezioni. I voti firmati impediscono efficacemente a un nodo bizantino di promuoversi arbitrariamente come leader di un mandato più alto. Inoltre, ogni follower esegue un riconteggio sul voto di maggioranza sopra menzionato, convalidando e contando ogni voto trasmesso dal nuovo leader per verificare in modo indipendente la validità dell'elezione.

Governo

Come Raft, Tangaroa usa timeout randomizzati per innescare le elezioni del leader. Il leader di ogni termine invia periodicamente messaggi heartbeat (RPC AE vuoti) per mantenere la propria autorità. Se un follower non riceve alcuna comunicazione da un leader per un periodo di tempo scelto casualmente, il timeout delle elezioni, allora diventa un candidato e avvia una nuova elezione.

Oltre alle elezioni spontanee innescate dai follower, Tangaroa consente anche l'intervento del client: quando un client non osserva alcun progresso con un leader per un periodo di tempo chiamato timeout di progresso, trasmette RPC UpdateLeader a tutti i nodi, dicendo loro di ignorare i futuri heartbeat da quello che il client ritiene essere il leader attuale nel termine corrente. Questi follower ignoreranno i messaggi heartbeat nel termine corrente e scadranno come se il leader attuale avesse fallito, avviando una nuova elezione.

Dati ricevuti

I dati (nuovi comandi) provengono dai client del cluster Raft, che inviano richieste al leader. Il leader replica queste richieste al cluster e risponde al client quando viene raggiunto un quorum nel cluster su quella Request.

Ciò che costituisce una "Request" dipende dal sistema. Il modo in cui i dati vengono archiviati dipende dal sistema. È importante che lo stato persista sul disco, in modo che i nodi possano recuperare e ricordare le informazioni su cui hanno eseguito il commit (per quali nodi hanno votato, quali voci di registro hanno eseguito il commit, ETC.). Senza questo, il protocollo non funzionerà.

Tangaroa aggiunge BFT all'evoluzione della zattera

Giunone

Il progetto Juno di JP Morgan è un fork di Tangoroa ed è stato una prova di concetto in grado di espandere Tangaroa fino a includere fino a 50 nodi e aumentare la velocità delle transazioni fino a 5.000 transazioni al secondo.

Il team JPM dietro Juno ha visto il potenziale rappresentato da un approccio simile a Tangaroa: una blockchain privata ad alte prestazioni. Hanno iterato sull'idea per un anno e hanno reso open source il progetto a febbraio 2016. Hanno aggiunto un linguaggio di contratto intelligente, corretto alcuni errori di progettazione e sono riusciti a ottenere un aumento delle prestazioni di 10 volte, il che ha consentito di votare per cambiare il numero di nodi mentre il sistema era in esecuzione. Juno consentiva l'aggiunta e la rimozione di nodi ed era un sistema distribuito autorizzato in cui tutti i nodi della rete erano noti.

Le fasi del meccanismo e il processo di elezione del leader sono gli stessi di Tangaroa (vedi sopra). Allo stesso modo, una transazione è considerata attiva una volta che è stata completamente replicata e inserita nel log.

Il leader decide l'ordine dei comandi e ogni nodo convalida. Ogni nodo decide in modo indipendente quando inviare una voce di registro in base alle prove che riceve dagli altri nodi. Ogni voce di registro viene inviata individualmente e sottoposta a hash incrementale rispetto alla voce precedente. Ci vogliono circa 5 ms perché una singola voce di registro passi dal leader che riceve la voce al raggiungimento del consenso completo e alla latenza di rete.

Parte 3: Blockchain di Kadena – ScalableBFT, Pact e determinismo pervasivo

Crittografia

Diversamente da Raft, ogni replica in un sistema Raft BFT (una famiglia di algoritmi che include Tangaroa, Juno e ScalableBFT di Kadean) calcola un hash crittografico ogni volta che aggiunge una nuova voce al suo registro. L'hash viene calcolato sull'hash precedente e sulla voce di registro appena aggiunta.

Un nodo può firmare il suo ultimo hash per dimostrare di aver replicato l'intero log, e altri server possono verificarlo rapidamente utilizzando la firma e l'hash. I nodi e i client BFT Raft firmano sempre prima di inviare messaggi e rifiutano i messaggi che non includono una firma valida.

I BFT Rafts utilizzano l'hashing incrementale, consentendo ai nodi di essere certi che sia il contenuto sia l'ordinamento dei log degli altri nodi corrispondano ai propri. Utilizzando questa conoscenza, i nodi possono eseguire il commit indipendente delle voci di log in modo sicuro, perché sia il contenuto sia l'ordinamento dei log degli altri nodi sono attestati tramite hash incrementali corrispondenti.

BFT Rafts utilizza ampiamente le firme digitali per autenticare i messaggi e verificarne l'integrità. Ciò impedisce a un leader bizantino di modificare il contenuto del messaggio o di falsificarlo e protegge il cluster in genere da un gran numero di attacchi bizantini.

Consenso

In Raft, un Leader viene eletto tramite timeout randomizzati che attivano un Follower per proporsi come Candidato e Request voti. Anche ScalableBFT fa lo stesso, ma in modo crittograficamente protetto. Ad esempio, se un Leader diventa irraggiungibile, un timeout innescherebbe una nuova elezione, ma il processo di elezione è robusto contro i nodi Bizantini che dichiarano elezioni. ScalableBFT risolve i problemi riscontrati da Juno e Tangaroa in merito al voto pigro.

Le uniche capacità esclusive del Leader sono: 1) l'ordinamento delle nuove transazioni prima della replica e 2) la replica delle nuove transazioni nei nodi Follower. Da quel momento in poi, tutti i nodi dimostrano in modo indipendente sia la validità del consenso sia l'integrità delle singole transazioni.

La rimozione della partecipazione anonima è un requisito di progettazione per le blockchain private, e questo ha consentito a un meccanismo di consenso BFT ad alte prestazioni di sostituire il mining. L'aggiunta principale di ScalableBFT alla famiglia di BFT Rafts è la capacità di scalare in migliaia di nodi senza ridurre la produttività del sistema.

Ogni transazione viene replicata su ogni nodo. Quando la maggior parte dei nodi ha replicato la transazione, la transazione viene sottoposta a commit. I nodi raccolgono e distribuiscono informazioni (hash incrementale) su ciò che hanno replicato e utilizzano queste informazioni per decidere in modo indipendente quando effettuare il commit (>50% degli altri nodi invia loro hash incrementali per le transazioni non sottoposte a commit con cui sono d'accordo).

Funziona fondamentalmente tramite una votazione a maggioranza su cosa impegnare. Impegnare una transazione T significa che verrà eseguita, ma solo che è stata replicata in modo permanente dalla maggioranza del cluster. Le transazioni errate, quelle che generano errori o hanno firme errate, vengono replicate e il lavoro del consenso è quello di fornire una replica ordinata perfetta.

L'esecuzione di una transazione consente a ciascun nodo di valutare in modo indipendente (analizzare/decifrare/convalidare la Cripto/eseguire/ ETC.) ogni transazione in modo identico. Ogni transazione viene associata a un output, che può variare da " Cripto non valida" all'output del livello di contratto intelligente (che può anche essere un errore).

Infine, oltre al leader che replica le nuove transazioni su ogni nodo, i nodi sono più o meno indipendenti. Invece di "sincronizzarsi", trasmettono "Ho replicato fino all'indice di registro N e ha un hash incrementale di H" al cluster e raccolgono queste informazioni da altri nodi: in base ai risultati di altri nodi, ogni nodo può decidere in modo indipendente se il cluster ha replicato oltre la barra necessaria per il commit (una replica di maggioranza per alcuni come indice di registro N ancora non committato).

Ecco la parte sottile: l'hash incrementale implica la replica di tutto ciò che è venuto prima. Se il leader replica 8.000 nuove transazioni (che è ciò che fa attualmente), ogni nodo deve solo distribuire e raccogliere prove per l'ultima transazione di quel batch poiché implica la corretta replica di quelle che lo hanno preceduto. Invece di inviare 8.000 messaggi (ONE per ogni transazione) che attestano la corretta replica, i nodi discutono solo dell'ultima transazione.

Ecco perché Kadena ha avuto così tanto bisogno di un processo di pipeline: il team ha capito come eseguire 8.000 transazioni alla stessa velocità di una singola transazione.

ScalableBFT rappresenta una svolta nel campo del consenso BFT in quanto è il primo e unico meccanismo di consenso BFT deterministico in grado di scalare oltre centinaia di nodi con replicazione e crittografia complete. ScalableBFT fornisce anche un modello di sicurezza unico noto come determinismo pervasivo che fornisce sicurezza non solo a livello di transazione ma anche a livello di consenso, crittografando ogni singola transazione utilizzando il protocollo Noise (vedere di seguito).

Kadena utilizza il consenso deterministico

Il meccanismo di consenso è deterministico se il processo di consenso è completamente specificato nel protocollo e questo processo non impiega casualità. Come affermato sopra, Raft, ad esempio, usa timeout randomizzati per innescare elezioni quando un leader va giù (poiché il leader T può comunicare "Sto per andare in crash", c'è un timeout che scatta per sollecitare un nodo a controllare se il leader è giù) ma l'elezione T fa parte del consenso a livello di transazione, è invece un mezzo per trovare un nodo per orchestrare il consenso.

ScalableBFT è deterministico e rafforzato in modo tale che:

• I nodi si impegneranno solo quando la maggioranza del cluster sarà d'accordo con loro
• La prova dell'accordo deve essere completamente verificabile in ogni momento
• In mancanza di prove di accordo, non fare nulla.

Kadena è specificamente progettato per reti autorizzate e, in quanto tale, presuppone che certi attacchi (come un DoS) siano improbabili e fuori dal suo controllo. Se ne dovesse verificarsi ONE , il sistema si bloccherebbe (tutti i nodi alla fine andrebbero in timeout ma un'elezione non avrebbe mai successo) o resterebbe inattivo.

Una volta che un evento del genere finisce, i nodi torneranno al consenso e le cose torneranno alla normalità. Tuttavia, in una rete autorizzata, gli amministratori avrebbero il pieno controllo e interromperebbero la connessione che causa il problema.

L'elezione del leader è molto simile a Raft in quanto qualsiasi nodo può essere eletto leader, ogni nodo ha diritto a ONE voto per mandato e le elezioni vengono indette quando si attiva il timeout casuale ONE dei nodi (il timer viene reimpostato ogni volta che un nodo riceve notizie dal leader).

La differenza più grande è che in Raft un nodo che ottiene abbastanza voti assume la leadership, mentre in ScalableBFT un nodo che ottiene la maggioranza dei voti distribuisce tali voti a tutti gli altri nodi per dimostrare (in modo BFT) di essere stato eletto leader dal cluster.

Il meccanismo di ScalableBFT risolve i problemi riscontrati in Juno e Tangaroa, come un "candidato in fuga" in cui un nodo non bizantino è scaduto a causa di una partizione di rete ma, poiché il suo termine è stato incrementato, T può tornare al consenso e continua invece il timeout, quindi incrementa il suo termine ("Runaway").

Il consenso Raft garantisce un rigoroso ordinamento e replicazione dei messaggi; T importa cosa c'è in ogni messaggio e può variare da numeri casuali a testo cifrato a contratti intelligenti in testo normale. Kadena sfrutta il livello di log come servizio di messaggistica quando viene eseguito in un contesto crittografato; proprio come Signal può eseguire la crittografia del protocollo Noise su SMS. ScalableBFT esegue Noise su una blockchain.

ScalableBFT aggiunge la robustezza del consenso, che il livello che si occupa dell'interpretazione dei messaggi assume come garanzia, ma anche hash incrementali che assicurano una replica perfetta dei messaggi. Slot di protocollo di rumore tra consenso ed esecuzione di smart contract, crittografando/decrittografando i messaggi secondo necessità; poiché i messaggi sono testo cifrato, sono necessari solo alcuni dei normali trucchi per evitare un'esplosione cartesiana di test live da eseguire per messaggio senza perdite di informazioni.

Modello di sicurezza/determinismo pervasivo

Kadena usa il termine "determinismo pervasivo" per descrivere "l'idea di una blockchain che utilizza la crittografia basata su PPK-Sig per le garanzie di paternità (come Bitcoin) ed è composta da un livello di consenso completamente deterministico oltre a un livello di contratto intelligente a assegnazione singola e incompleto di Turing.

Le implicazioni di una blockchain “pervasivamente deterministica” sono piuttosto profonde, in quanto consente di estendere una classe di verificabilità del registro bitcoin in profondità nel livello di consenso concatenando più livelli di fiducia crittografica.

Prendiamo come esempio una transazione che carica un nuovo modulo smart contract chiamato "prestiti". Diciamo che "prestiti" importa un altro modulo chiamato "pagamenti" che è già presente nella catena. La sola importazione riuscita di "pagamenti" implica quanto segue (ognuno dei quali è completamente verificabile tramite mezzi crittografici):

• Chi ha firmato la transazione che ha caricato i “pagamenti”
• Quali nodi di consenso erano presenti nel cluster al momento del caricamento
• Quali nodi di consenso hanno concordato che la transazione era valida
• Quali nodi hanno votato per il leader attuale al momento del caricamento
• Chi era il leader?
• Chi era il precedente leader?
• ETC.

Un sistema pervasivamente deterministico consente alle nuove transazioni di sfruttare non solo la fiducia crittografica che si verifica naturalmente quando le transazioni vengono concatenate in una blockchain, ma anche la fiducia di come tali transazioni sono entrate nel registro in primo luogo. Così facendo, puoi creare un sistema più sicuro di Bitcoin perché il processo di consenso diventa altrettanto crittograficamente attendibile, verificabile e intrecciato, con esecuzioni a livello di transazione che implicano che si siano verificati Eventi specifici a livello di consenso e con ogni implicazione che è crittograficamente verificabile.

Ciò fornisce BFT non solo per il livello di consenso ma anche per il livello di transazione (Bitcoin lo fa già). Questo è diverso da, diciamo, PBFT che presuppone che le transazioni inviate dal server del client siano valide, il che lascia loro la possibilità di essere compromesse. Inoltre, i BFT non Raft generalmente affidano al client la possibilità di deporre/bannare nodi. Pervasive Determinism adotta un punto di vista alternativo: non fidarti di nulla, controlla tutto.

Consentire a ScalableBFT di incorporare il determinismo pervasivo crea un sistema completamente paranoico che è robusto a ogni livello tramite sicurezza permanente (ad esempio: una forma di sicurezza crittografica che può essere salvata su disco). Ha il modello di sicurezza di bitcoin per le transazioni, estende questo modello al livello di consenso e aggiunge contratti intelligenti senza la necessità di mining o i compromessi a cui la maggior parte del settore si è abituata. È una vera blockchain veloce e scalabile.

Ho chiesto a Will Martino (co-fondatore di Kadena) i dettagli di come funzionava per ogni livello:

Qual è il vostro modello di sicurezza a livello di consenso?

Per la replica, Kadena utilizza un log incrementale hash delle transazioni che viene replicato in modo identico da ogni nodo. Questi concordano sul contenuto del log tramite i messaggi distribuiti firmati contenenti l'hash incrementale di un dato indice di log, che vengono poi raccolti da altri nodi e utilizzati per ragionare individualmente su quando è giustificato un commit. Non sono ammessi duplicati nel log e i messaggi di replica dal leader contenenti duplicati vengono immediatamente rifiutati.

Utilizziamo hash blake2 e numero di termine per definire l'unicità, consentendo ai client del sistema di non preoccuparsi di inviare duplicati per sbaglio o di un nodo/man-in-the-middle (MITM) dannoso che reinvia i comandi. Utilizziamo una sicurezza permanente, un approccio basato su PPK-sig per la verifica dell'autore (o qualsiasi tipo di approccio che può essere salvato su disco) che è molto simile al modo in cui Bitcoin verifica le transazioni ma a livello di consenso (oltre al livello di transazione).

Questo è in contrasto con la sicurezza effimera che utilizza canali protetti (TLS) per la convalida dell'autore, un approccio di gran lunga inferiore in cui alla domanda "chi ha inviato la transazione X?" si risponde non tramite crittografia PPK ma tramite una query a livello di consenso perché nessun singolo nodo è in grado di fornire una risposta BFT.

Qual è il vostro modello di sicurezza a livello di transazione?

Le idee di sicurezza effimera e permanente abbracciano sia il livello di consenso che quello di transazione, poiché è il consenso che consegna al livello di esecuzione dello smart contract le singole transazioni. A livello di smart contract/transazione utilizziamo anche la sicurezza permanente, supportando l'autorizzazione della chiave pubblica a livello di riga in modo nativo in Pact.

Ciò è importante perché effimero implica che un aggressore è a ONE server di distanza dall'impersonare un'entità; i canali protetti funzionano tramite distribuzione punto a punto di nuove transazioni da parte del client/submitter ai nodi del cluster tramite TLS e il consenso garantisce che una determinata transazione debba essere impegnata e replicata. Tuttavia, se un aggressore hackera il server client che detiene l'altra estremità della connessione TLS, può effettuare transazioni come se fosse il client senza che il cluster se ne accorga.

La sicurezza permanente, d'altro canto, ha molte chiavi per i singoli ruoli in una data entità, richiedendo quindi a un aggressore di ottenere l'accesso alle singole chiavi; inoltre, con la sicurezza permanente le transazioni del CEO sono firmate con una chiave diversa rispetto alle transazioni dell'addetto alle poste, rispetto alla sicurezza effimera in cui "chi sta inviando questa transazione" è determinato da un campo "da: X".

Se la stessa connessione TLS viene utilizzata per inviare le transazioni sia del CEO che del Clerk, allora la logica di paternità e autorizzazione è un modello "perché l'ho detto io/fidati di me" rispetto a un approccio PPK-sig in cui verifichi con la chiave appropriata prima dell'esecuzione. La blockchain di Kadena è progettata per fidarsi il meno possibile; se conoscessimo un approccio più paranoico o dettagliato rispetto alle firme PPK a livello di riga, useremmo quello.

Qual è il vostro modello di transazione riservata?

Utilizziamo il protocollo Double-Ratchet (quello che Signal, WhatsApp, ETC... usano per le comunicazioni crittografate) incorporato nella blockchain (corpi di transazione crittografati) per casi d'uso che preservano la Privacy multi-parte. Lavoriamo con la nozione di database disgiunti tramite la primitiva "pact" in Pact: descrivono un flusso di lavoro di commit multifase su database disgiunti tramite messaggi crittografati.

Contratti intelligenti

Pact è un linguaggio completo per smart contract, il cui interprete è costruito in Haskell. In Kadena, ogni transazione è uno smart contract e il linguaggio per smart contract Pact è open source. Pact è focalizzato sul database, transazionale, Turing-incompleto, single-assignment (le variabili non possono essere modificate nel loro ciclo di vita) e quindi altamente adatto alla verifica statica.

Pact è anche interpretato, il codice che scrivi è ciò che viene eseguito on-chain, mentre Solidity è compilato, rendendo difficile la verifica del codice e anche impossibile correggere i problemi di sicurezza nelle vecchie versioni del linguaggio, una volta compilato. Pact viene fornito con il suo interprete, ma può essere eseguito in qualsiasi blockchain con input deterministico e può supportare diversi backend, inclusi RDBMS commerciali. Nella blockchain ScalableBFT, viene eseguito con un veloce livello di archiviazione SQLite.

La blockchain Kadena contiene tutte queste caratteristiche:

In conclusione, Kadena ha sviluppato un algoritmo di consenso completamente replicabile, scalabile e deterministico per blockchain private ad alte prestazioni. Questa soluzione blockchain può rappresentare un enorme passo avanti per le società di servizi finanziari che cercano di impiegare una vera soluzione privata che rimanga fedele a molte delle principali funzionalità della blockchain Bitcoin senza mining (proof of work), anonimato e resistenza alla censura, pur soddisfacendo le principali funzionalità di progettazione che i servizi finanziari desiderano ardentemente, in particolare scalabilità e riservatezza.

Questo articolo è stato precedentemente pubblicato suBlog di Sammanticsed è stato riprodotto qui con autorizzazione. Sono state apportate alcune modifiche per motivi di stile e brevità.

Immagine di ingranaggitramite Shutterstock