Proof of History: algoritmo di consenso per sincronizzare il tempo sulla blockchain
Wiki

Proof of History: algoritmo di consenso per sincronizzare il tempo sulla blockchain

By Emanuele Pagliari - 18 Ago 2019

Chevron down

Tra le decine di algoritmi di consenso utilizzati per la gestione delle blockchain di differenti progetti, esiste anche la Proof of History, una soluzione sviluppata del team di Project Solana per eliminare definitivamente i problemi legati alla veridicità dei timestamp in un network distribuito.

Le reti decentralizzate hanno parzialmente risolto questo problema affidandosi a soluzioni di temporizzazione di terze parti affidabili ma centralizzate. Per esempio, lo Spanner di Google si appoggia a diversi orologi atomici sincronizzati tra loro e con i vari data center.

Questo problema, però, deve venir risolto in maniera differente sulle blockchain, essendo sistemi trustless. I nodi nella rete non possono fidarsi di una fonte esterna o di un qualsiasi timestamp che appare in un messaggio.

Soluzioni come Hashgraph, ad esempio, risolvono questo problema con un timestamp medio. Ogni messaggio visualizzato dalla rete è firmato e marchiato da un’entità di livello superiore. Viene quindi ottenuto un timestmap medio di sincronizzazione considerando tutti quelli firmati e certificati.

Tuttavia, si tratta di una soluzione poco efficiente, in quanto tutti i messaggi devono venir raccolti dalla rete e firmati. Deve venir poi calcolato il timestamp medio e successivamente va redistribuito in rete. Un sistema troppo lento.

Ed è qui che entra in gioco l’algoritmo di consenso Proof of History.

Proof of History: l’algoritmo blockchain per sincronizzare il tempo

Invece che utilizzare il classico concetto di timestamp si può dimostrare che un messaggio/evento è avvenuto in un certo tempo dopo un evento ma prima di un altro.

Ad esempio, quando si scatta una foto alla copertina del New York Times si crea una prova che dimostra che la foto è stata scattata dopo la pubblicazione del giornale. Con il Proof of History è possibile creare un record che dimostra che un certo evento si è verificato in un momento specifico, prima o dopo altri eventi, il tutto senza usare timestamp o sistemi di sincronizzazione di terze parti.

La Proof of History è una Delay Verifiable Function ad alta frequenza. Questo significa che tale funzione necessita di un certo numero di passaggi sequenziali per valutare e produrre un risultato univoco ed affidabile che viene poi reso pubblico.

Nel caso dell’implementazione attuata in Solana viene utilizzata una funzione che utilizza un sistema di hashing sequenziale resistente alle pre-image (immagini degli hash già pronte).

Per fare ciò, l’output dell’operazione diventa l’input dell’operazione successiva. Periodicamente vengono poi registrati il conteggio, lo stato e l’output corrente.

Nella caso della funzione di hashing SHA256, tale processo risulta impossibile da parallelizzare senza un attacco Brute Force che utilizzi ben 2¹²⁸ core.

Input

I dati possono venir inseriti nella sequenza aggiungendo l’hash dei dati allo stato generato in precedenza. Lo stato, i dati di ingresso ed il conteggio vengono poi pubblicati.

Se si aggiunge l’ingresso, tutti i futuri output cambieranno in modo imprevedibile. E’ quindi ancora impossibile parallelizzare la funzione, e, finché lo SHA256 sarà immune alle pre-image e collisioni, è praticamente impossibile creare un input che generi l’hash desiderato o creare una cronologia alternativa con gli stessi hash.

Si può dunque dimostrare che è passato un certo intervallo di tempo tra due operazionii. Possiamo dimostrare che i dati sono stati creati prima dell’aggiunta.

Back reference

Gli input nella Proof of History possono avere riferimenti a Proof of History precedenti. Il back reference può essere inserito come parte di un messaggio firmato con la firma dell’utente, quindi non può essere modificato senza la chiave privata dell’utente.

Facendo riferimento all’esempio del giornale sarebbe come fare una fotografia di noi stessi con il giornale in mano.

Poiché il messaggio contiene l’hash 0xdeadc0de, si sa che è stato generato dopo la creazione del conteggio 510144806912. Il messaggio, però, viene inserito di nuovo nella funzione sequenziale. Quindi, tornando all’esempio, è come se una volta scattata la foto con il giornale in mano, il giorno successivo il giornale pubblicasse la nostra foto con il giornale in mano.

Emanuele Pagliari
Emanuele Pagliari

Ingegnere delle telecomunicazioni appassionato di tecnologia. La sua avventura nel mondo del blogging è iniziata su GizChina.it nel 2014 per poi proseguire su LFFL.org e GizBlog.it. Emanuele è nel mondo delle criptovalute come miner dal 2013 ed ad oggi segue gli aspetti tecnici legati alla blockchain, crittografia e dApp, anche per applicazioni nell'ambito dell'Internet of Things

Utilizziamo i cookie per essere sicuri che tu possa avere la migliore esperienza sul nostro sito. Se continui ad utilizzare questo sito noi assumiamo che tu ne sia felice.