Lo so, lo so. Ci sono moltissimi progetti crypto, ci sono vari consensi: basati su lavoro e proprietà, oro, petrolio, panini sfornati (sì, esiste anche questo, sì-sì). Che altro ci serve di uno in più? È questo che propongo di discutere dopo aver letto la traduzione della documentazione tecnica 'semplificata' del progetto *Costellazione (). Certo, non è una descrizione completa dell'algoritmo, ma mi interessa sapere il parere della comunità di Habr, se un tale consenso ha ragione di esistere o è completamente inutile.
Ci sono poche lettere dopo, quindi, se ti va solo di scrivere 'uff, quanto si può parlare di crypto', ti prego di astenerti. Se sei interessato a nuove innovazioni nel campo dei sistemi distribuiti e hai qualcosa da condividere nei commenti, allora ti prego di entrare.
P.S. Non sono l'autore della tecnologia, non posso garantire la trasmissione completa della sostanza, quindi sarò felice di ricevere commenti con correzioni, se ci saranno.
Evoluzione dai consensi sincroni a quelli asincroni
I nodi vengono selezionati utilizzando un processo deterministico (lo stesso utilizzato in DHT, ad esempio, bittorrent), che regola dinamicamente i compiti per i nodi al fine di 'semplificare' la validazione o, per essere più chiari, per raggiungere il consenso. Selezioniamo gruppi di 3 nodi e eseguiamo i turni di consenso in parallelo, in modo che un nodo possa essere facilitatore in più blocchi. Questo ci consente di elaborare le transazioni in modo asincrono, il che, in sostanza, significa che stiamo formando più blockchain contemporaneamente. Il processo è simile a una ragnatela formata 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 è conosciuta come grafo aciclico orientato o DAG nelle scienze informatiche.
Larghezza del canale di una blockchain lineare contro effetto moltiplicativo del DAG, dove abbiamo più blockchain parallele.
Implementazione geometrica di una blockchain lineare contro DAG. I punti neri sono blocchi, i punti bianchi sono nodi.
Utilizziamo 3 nodi in ogni ciclo di consenso, poiché questo ci fornisce alcuni processi matematici interessanti per riflettere sullo stato, formando "il piano della superficie" attraverso i dati a forma di triangoli con collegamenti. Successivamente, il protocollo utilizza i triangoli per "cucire" la superficie ottimale, che non contiene dati ridondanti o contraddittori e ha il minor numero possibile di triangoli. Algoritmicamente, questo è analogo a un "taglio minimo" di un grafo, e matematicamente a una derivata o funzione di ottimizzazione (da cui la funzione trova il percorso più breve che può attraversare la superficie). Questo percorso più breve è equivalente a un'archiviazione ottimale dei dati (transazioni) all'interno di un insieme di disponibilità dei database. “Piastrelle” triangolari in conflitto, affinché la superficie dell'evento sia liscia e priva di conflitti.
Implementazione geometrica di rilevamento / gestione dei conflitti. Un blocco in conflitto crea un'ulteriore piastrella di superficie. Rimuoviamo la piastrella di superficie aggiuntiva per mantenere una superficie piatta (= priva di 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, nell'assegnare una valutazione globale. “Sei tanto valido quanto la tua rete”. Il risultato finale è una “distorsione” o gradiente, basato sulla fiducia transitive o reputazione in tutti i nodi nel $DAG o canale standard. Questo può essere visto come una grattugia o una spatola per formaggio che cancella la superficie “piano della superficie” e decide quali “piastrelle triangolari” cancellare e quali lasciare. Ecco come la logica del conflitto elimina effettivamente le “piastrelle triangolari”.
DAG con una piastrella in conflitto che passa attraverso uno spazio “distorto”, che è un gradiente simile a una grattugia per formaggio, ed è pronto a rimuovere o “cancellare” la piastrella in conflitto.
Scalabilità parziale / totale del nodo
Nella teoria delle reti, la distribuzione ottimale è comunemente nota come "senza scalabilità" e 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, in Internet. Constellation utilizza questa architettura per "scalare", ovvero aumentare la larghezza di banda o la portata del nostro Grafo.
L'effetto della suddivisione gerarchica. Possiamo aggiungere più nodi aumentando la larghezza di banda.
Hylochain - Supporto per applicazioni basate su canali.
Il nostro approccio al supporto delle applicazioni può essere considerato come una "piattaforma decentralizzata di smart contract". Invece di una rete centrale che esegue tutta la logica e gestisce tutti i dati dell'applicazione, Constellation coordina i dati dell'applicazione con "canali statali", che possono essere considerati come una stazione televisiva che trasmette tutti i dati dal sistema statale. Ogni canale statale può implementare la propria logica di verifica, affrontando il problema degli oracoli attraverso la verifica incrociata dell'autenticità dei produttori di dati e la verifica transitiva dei sistemi statali composti. Le reti di canali statali forniscono supporto parziale per le applicazioni, accelerando i tempi di adozione che in una rete di smart contract sono limitati dal consenso sincrono tradizionale.
Due canali statali che sono "compatibili" attraverso la rete $DAG. Possono interagire o essere interpretati, poiché entrambi sono "integrati" con il $DAG attraverso il dispiegamento di nodi ibridi $DAG + Canale.
Il motivo per cui si chiama Hylochain è che nel nostro approccio al supporto delle applicazioni è stato utilizzato un modello di programmazione funzionale chiamato Recursion Schemes per creare un'interfaccia MapReduce. In particolare, gli schemi di ricorsione Hylomorphism e Metamorphism possono essere integrati per creare query verificabili e connessioni di streaming attraverso i canali standard, controllando i tipi di dati algebrici proprio come si verificano gli op-code per i contratti intelligenti. Il risultato finale è un'interfaccia funzionale MapReduce, familiare agli ingegneri dei dati e compatibile con la tecnologia esistente dei big data.
Canali standard Hylomorphic e Metamorphic per il contrasto. Nello stato metamorfico, i dati di due canali standard vengono inviati a un blocco in un metacanale. In Hilo prendiamo lo stato precedente del canale e lo utilizziamo per interrogare (fare una domanda specifica) due altri canali, e poi conserviamo il risultato della query nel blocco.
Tokenomica e la sua connessione con Hylochain
Quando un canale standard è creato, può essere integrato nel canale $DAG, ma utilizzando l'interfaccia ACI o Application Chain Interface. Questa interfaccia è semplicemente un oggetto JSON contenente informazioni sulla configurazione e la chiave pubblica associata al canale stesso. Il motivo per cui colleghiamo la chiave pubblica al canale standard è per creare un meccanismo di brokeraggio per i dati del canale standard. Quando il canale standard è attivato, gli sviluppatori configurano da soli come i pagamenti dalla rete $DAG vengono distribuiti tra i nodi e gli operatori.
Flusso per l'acquisto di accesso a informazioni o modifica di informazioni. La richiesta è inviata al $DAG, i fondi vengono inviati al conto del canale, il risultato viene inviato all'acquirente e l'impronta della transazione viene inviata alla rete $DAG, che poi sblocca i fondi per il canale standard.
Fonte: habr.com
