Lo so, lo so. Ci sono molti progetti crittografici, ci sono molti consensi: basati su lavoro e proprietà, oro, petrolio, torte al forno (ce n'è uno, sì, sì). Cos'altro abbiamo bisogno da uno? Questo è ciò di cui mi propongo di discutere dopo aver letto la traduzione della documentazione tecnica “leggera” del progetto *Constellation (). Naturalmente, questa non è una descrizione completa dell'algoritmo, ma mi interessa l'opinione della comunità Habr, c'è spazio per un tale consenso o non è necessario?
Non ci sono molte altre lettere, quindi se vuoi semplicemente scrivere "wow, tutto quello che puoi sulle criptovalute", per favore astieniti. Se sei interessato ai nuovi sviluppi nel campo dei sistemi distribuiti e hai qualcosa da condividere nei commenti, fai riferimento al cat.
PS Non sono l'autore della tecnologia, non posso garantire il trasferimento completo dell'essenza, quindi sarò lieto di ricevere commenti con eventuali modifiche.
Evoluzione dai consensi sincroni a quelli asincroni
I nodi vengono selezionati utilizzando un processo deterministico (lo stesso utilizzato nei DHT come bittorrent) che regola dinamicamente le responsabilità dei nodi per “facilitare” la convalida o, più comprensibilmente, per raggiungere il consenso. Selezioniamo gruppi di 3 nodi ed eseguiamo cicli di consenso in parallelo in modo che un nodo possa fungere da facilitatore in più blocchi. Ciò ci consente di elaborare le transazioni in modo asincrono, il che significa essenzialmente che abbiamo più blockchain che si formano contemporaneamente. Il processo è come una tela di ragno, formata da molti fili, in contrapposizione ai nodi che formano un'unica catena nel tempo. L'elaborazione asincrona o parallela è alla base della programmazione scalabile perché consente l'utilizzo di tutte le risorse del computer, velocizzando l'elaborazione complessiva. Questa rete è chiamata grafo aciclico diretto o DAG in informatica.
Larghezza del canale di una blockchain lineare rispetto all'effetto moltiplicativo di un DAG in cui abbiamo più blockchain parallele.
Implementazione geometrica della blockchain lineare contro DAG. I punti neri sono blocchi, i punti bianchi sono nodi
Usiamo 3 nodi in ogni round di consenso perché ci forniscono alcuni processi matematici interessanti per ragionare sullo stato, formando un “piano superficiale” attraverso i dati sotto forma di triangoli collegati. Il protocollo utilizza quindi i triangoli per unire insieme una superficie ottimale che non contenga dati ridondanti o incoerenti e abbia i triangoli più piccoli possibili. Algoritmicamente, questo è analogo a un “taglio minimo” di un grafico e, matematicamente, è analogo a una funzione derivata o di ottimizzazione (dalla quale la funzione trova il percorso più breve che può percorrere lungo la superficie). Questo percorso più breve equivale all'archiviazione ottimale dei dati (transazioni) in un DAG. “Tessere” triangolari contrastanti in modo che la superficie dell'evento sia liscia e priva di conflitti.
Implementazione geometrica del rilevamento/gestione dei conflitti. Un blocco in conflitto crea una tessera di superficie aggiuntiva. Rimuoviamo le tessere di superficie aggiuntive per mantenere una superficie dell'evento piatta (= senza conflitti).
Consenso basato sulla reputazione
In un sistema di reputazione p2p decentralizzato ottimale, ciascun nodo dovrebbe essere in grado di determinare in modo indipendente 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, quando assegna un punteggio globale. "Sei bravo quanto la tua compagnia." Il risultato finale è una "distorsione" o gradiente basato sulla fiducia transitiva o sulla reputazione su tutti i nodi nel $DAG o nel canale normale. Questo può essere pensato come un pennello o una grattugia che cancella su un “piano di superficie” e seleziona quali “piastrelle triangolari” cancellare e quali lasciare. Questo è il modo in cui la logica del conflitto rimuove effettivamente le “tessere triangolari”.
Un DAG con una tessera in conflitto che attraversa uno spazio "curvo" che è un gradiente, simile a una grattugia, e rimuoverà o "cancellerà" la tessera in conflitto.
Ridimensionamento parziale/completo del nodo
Nella teoria delle reti, in genere l’allocazione ottimale è nota come “senza scala”, che può essere descritta come una disposizione gerarchica con grandi nodi centrali che gestiscono molti nodi periferici più piccoli. Questa distribuzione è visibile in natura e, soprattutto, su Internet. Constellation utilizza questa architettura per "scalare" o aumentare il throughput o la larghezza del nostro grafico.
L'effetto del partizionamento gerarchico. Possiamo aggiungere più nodi aumentando la larghezza di banda
Hylochain: supporto per applicazioni basate su canali
Il nostro approccio al supporto applicativo può essere considerato una “piattaforma di contratto intelligente decentralizzata”. Invece di una rete centrale che gestisce tutta la logica ed elabora tutti i dati dell’applicazione, Constellation coordina i dati dell’applicazione con i “canali domestici”, che possono essere pensati come una stazione televisiva che trasmette tutti i dati dal sistema domestico. Ciascun canale del personale può implementare la propria logica di verifica per risolvere il problema dell'oracolo attraverso l'autenticazione end-to-end dei produttori di dati e la verifica transitiva dei sistemi compositi del personale. Le reti di canali statali forniscono supporto parallelo per le applicazioni, accelerando i tempi di adozione che sono limitati dal tradizionale consenso sincrono in una rete di contratti intelligenti.
Due canali standard “compatibili” tramite la rete $DAG. Possono interagire o essere interpretati poiché sono entrambi “integrati” con $DAG distribuendo nodi ibridi $DAG + Canale.
Il motivo per cui si chiama Hylochain è perché il nostro approccio al supporto dell'applicazione ha utilizzato il modello di programmazione funzionale Recursion Schemes per creare l'interfaccia MapReduce. In particolare, gli schemi di ricorsione Ilomorfismo e Metamorfismo possono essere integrati per creare query verificabili e connessioni in streaming su canali nativi convalidando i tipi di dati algebrici nello stesso modo in cui vengono verificati i codici operativi per i contratti intelligenti. Il risultato finale è un'interfaccia MapReduce funzionale, familiare agli ingegneri dei dati e compatibile con la tecnologia Big Data esistente.
Ilomorfo e metamorfico sono canali standard per il contrasto. Nello stato metamorfico, i dati provenienti da due canali regolari vengono inviati a un blocco nel metacanale. In Gilo, prendiamo lo stato precedente di un canale e lo usiamo per interrogare (fare una domanda specifica) altri due canali, quindi archiviare il risultato della query in un blocco.
Tokenomics e la sua connessione con Hylochain
Una volta creato un canale nativo, è possibile integrarlo nel canale $DAG, ma utilizzando l'ACI o l'Application Chain Interface. Questa interfaccia è semplicemente un oggetto JSON con informazioni di configurazione e una chiave pubblica associata al canale stesso. Il motivo per cui associamo una chiave pubblica a un canale regolare è creare un meccanismo di intermediazione per i dati del canale regolare. Quando viene implementato il canale normale, gli sviluppatori configurano autonomamente il modo in cui i pagamenti dalla rete $DAG vengono distribuiti tra nodi e operatori.
Flusso per l'acquisto dell'accesso alle informazioni o la modifica delle informazioni. La richiesta viene inviata a $DAG, i fondi vengono inviati all'account del canale, il risultato viene inviato all'acquirente e il checksum della transazione viene inviato alla rete $DAG, che quindi rilascia i fondi al canale normale.
Fonte: habr.com