Lo so, lo so. Ci sono un sacco di progetti crypto e molte forme di consenso: basati sul lavoro e sulla proprietà, sull'oro, sul petrolio, su tortini sfornati (sì, esatto). Che altro ci serve da uno? Questo è ciò di cui propongo di discutere dopo aver letto la traduzione della documentazione tecnica 'semplificata' del progetto *Costellazione (). Certo, questo non è una descrizione completa dell'algoritmo, ma sono interessato all'opinione della comunità di Habr: c'è spazio per un tale consenso o non serve a nulla?
Non ci sono molte lettere, quindi, se ti va solo di scrivere 'uff, quanto si può parlare di crypto', ti prego di astenerti. Se sei interessato a nuove sviluppi nel campo dei sistemi distribuiti e hai qualcosa da condividere nei commenti, ti invito a scorrere.
P.S. Non sono l’autore della tecnologia, non posso garantire una trasmissione completa del concetto, quindi sarei lieto di ricevere commenti correttivi, se ce ne saranno.
Evoluzione dai consensi sincroni a quelli asincroni
I nodi vengono selezionati utilizzando un processo deterministico (lo stesso usato in DHT, ad esempio, bittorrent), che regola dinamicamente i compiti dei nodi per 'alleggerire' la validazione, o, per essere più chiari, per raggiungere il consenso. Selezioniamo gruppi di 3 nodi e svolgiamo turni di consenso in parallelo, affinché un nodo possa essere facilitante in più blocchi. Questo ci consente di elaborare le transazioni in modo asincrono, il che, in sostanza, significa che stiamo formando simultaneamente più blockchain. Il processo è simile a una rete composta da molti fili, a differenza dei nodi che formano una sola catena nel tempo. L’elaborazione asincrona o parallela è alla base della programmazione scalabile, poiché consente di utilizzare tutte le risorse del computer, accelerando i calcoli complessivi. Questa rete è chiamata grafo aciclico orientato, o DAG in informatica.
Larghezza di banda di una blockchain lineare rispetto all'effetto moltiplicativo del DAG, in cui abbiamo più blockchain paralleli.
Implementazione geometrica di una blockchain lineare rispetto al DAG. I punti neri sono blocchi, i punti bianchi sono nodi.
Utilizziamo 3 nodi in ciascun turno di consenso, poiché questo ci fornisce alcuni interessanti processi matematici per ragionare sullo stato, formando una 'superficie piatta' sui dati sotto forma di triangoli con connessioni. Il protocollo poi utilizza i triangoli per 'cucire' una superficie ottimale che non contenga dati ridondanti o contraddittori e abbia il minor numero possibile di triangoli. Algoritmicamente, questo è analogo a un 'taglio minimo' di un grafo, e matematicamente a una derivata o una funzione di ottimizzazione (da cui la funzione trova il percorso più breve che può attraversare la superficie). Questo percorso più breve è equivalente all'ottimizzazione della memorizzazione dei dati (transazioni) in un gruppo di disponibilità delle basi dati. Triangoli 'piastrellati' in conflitto, per mantenere la superficie dell'evento liscia e priva di conflitti.
Implementazione geometrica della rilevazione / gestione dei conflitti. Un blocco conflittuale crea un'ulteriore piastrella superficiale. Rimuoviamo la piastrella aggiuntiva per mantenere la superficie piatta (= senza conflitti) degli eventi.
Consenso basato sulla reputazione
In un sistema p2p decentralizzato ottimale di reputazione, ogni nodo deve essere in grado di determinare autonomamente la propria fiducia negli altri nodi. Il nostro sistema utilizza un modello speciale che include relazioni transitive o relazioni che un nodo ha con altri nodi, nella assegnazione di una valutazione globale. 'Sei buono quanto la tua compagnia'. Il risultato finale è una 'distorsione' o gradiente basato sulla fiducia transitoria o sulla reputazione di tutti i nodi in $DAG o nel canale principale. Questo può essere visto come una grattugia o una spatola per il formaggio, che pulisce la superficie della 'superficie piatta' e decide quali 'piastrelle triangolari' rimuovere e quali mantenere. Ecco come la logica del conflitto rimuove effettivamente le 'piastrelle triangolari'.
DAG con una piastrella conflittuale, passando attraverso uno spazio 'distorto', che è un gradiente simile a una grattugia per il formaggio, e si prepara a rimuovere o 'cancellare' la piastrella conflittuale.
Scalabilità parziale/completa di un nodo
Nella teoria delle reti, una distribuzione ottimale è generalmente nota come “senza scalabilità”, che può essere descritta come una disposizione gerarchica con grandi nodi centrali che controllano molti nodi periferici più piccoli. Questa distribuzione è visibile in natura e, soprattutto, su Internet. Constellation utilizza questa architettura per “scalare”, ovvero aumentare la capacità o la larghezza del nostro Grafo.
L'effetto della suddivisione gerarchica. Possiamo aggiungere più nodi aumentando la larghezza della capacità
Hylochain — Supporto per applicazioni basate su canali
Il nostro approccio al supporto delle applicazioni può essere visto come una “piattaforma decentralizzata per contratti intelligenti”. Invece di una rete centrale che esegue tutta la logica e gestisce tutti i dati dall'applicazione, Constellation coordina i dati dell'applicazione con “canali di stato”, che possono essere visti come una stazione televisiva che trasmette tutti i dati dal sistema di stato. Ogni canale di stato può implementare la propria logica di verifica, risolvendo il problema degli oracoli attraverso la verifica incrociata dell'autenticità dei produttori di dati e della verifica transitiva dei sistemi di stato compositi. Le reti di canali di stato forniscono supporto parallelo per le applicazioni, accelerando il tempo di accettazione, che in una rete con contratti intelligenti è limitato dal consenso sincrono tradizionale.
Due canali di stato che sono “compatibili” attraverso la rete $DAG. Possono interagire o essere interpretati poiché entrambi sono “integrati” con $DAG attraverso l'implementazione di nodi ibridi $DAG + Canale.
La ragione per cui si chiama Hylochain è che nel nostro approccio al supporto delle applicazioni è stato utilizzato un modello funzionale di programmazione degli Schemi di Ricorsione per creare un'interfaccia MapReduce. In particolare, gli schemi di ricorsione Hylomorphism (Hylomorfico) e Metamorphism (Metamorfico) possono essere integrati per creare query verificabili e connessioni a flusso attraverso canali di stato verificando i tipi di dati algebrici proprio come vengono verificati gli op-codes per i contratti intelligenti. Il risultato finale è una interfaccia funzionale MapReduce, che è familiare agli ingegneri dei dati e compatibile con la tecnologia esistente dei big data.
Canali di stato Hylomorfico e Metamorfico a confronto. In uno stato metamorfico, i dati provenienti da due canali di stato vengono inviati a un blocco nel metacanale. In Hilo prendiamo lo stato precedente del canale e lo utilizziamo per interrogare (fare una domanda specifica) due altri canali, quindi conserviamo il risultato della query in un blocco.
Tokenomica e la sua connessione con Hylochain
Quando un canale di stato è creato, può essere integrato nel canale $DAG, utilizzando però l'interfaccia ACI o Application Chain Interface. Questa interfaccia è semplicemente un oggetto JSON con informazioni sulla configurazione e una chiave pubblica associata al canale stesso. La ragione per cui colleghiamo la chiave pubblica con il canale di stato è quella di creare un meccanismo di intermediazione per i dati del canale di stato. Una volta implementato, gli sviluppatori configurano autonomamente come i pagamenti dalla rete $DAG vengono distribuiti tra nodi e operatori.
Flusso per l'acquisto di accesso a informazioni o per la modifica di informazioni. La richiesta viene inviata al $DAG, i fondi vengono inviati al conto del canale, il risultato viene inviato all'acquirente e il checksum della transazione viene inviato alla rete $DAG, che poi sblocca i fondi per il canale di stato.
Fonte: habr.com
