Consens sobre la reputació del node. És necessari?

Ho sé, ho sé. Hi ha molts projectes criptogràfics, hi ha molts consensos: basats en mà d'obra i propietat, or, oli, pastissos al forn (n'hi ha, sí, sí). Què més necessitem d'un? Això és el que em proposo comentar després de llegir la traducció de la documentació tècnica “lleugera” del projecte *Constellation (Constel · lació). Per descomptat, aquesta no és una descripció completa de l'algoritme, però m'interessa l'opinió de la comunitat Habr, hi ha un lloc per "ser" aquest consens o és innecessari?

No hi ha moltes més cartes, així que si només voleu escriure "wow, tant com pugueu sobre criptografia", absteniu-vos. Si esteu interessats en nous desenvolupaments en el camp dels sistemes distribuïts i teniu alguna cosa a compartir als comentaris, consulteu el cat.

PD: No sóc l'autor de la tecnologia, no puc garantir la transferència completa de l'essència, així que estaré encantat de rebre comentaris amb esmenes, si n'hi ha.

Evolució de consensos sincrònics a asíncrons

Els nodes es seleccionen mitjançant un procés determinista (el mateix que s'utilitza en DHT com bittorrent) que ajusta dinàmicament les responsabilitats dels nodes per "facilitar" la validació o, més comprensible, per aconseguir consens. Seleccionem grups de 3 nodes i fem rondes de consens en paral·lel perquè un node pugui ser facilitador en diversos blocs. Això ens permet processar transaccions de manera asíncrona, la qual cosa significa essencialment que tenim diverses cadenes de blocs que es formen al mateix temps. El procés és com una teranyina, formada per molts fils, a diferència dels nodes que formen una única cadena al llarg del temps. El processament asíncron o paral·lel és la base de la programació escalable perquè permet l'ús de tots els recursos informàtics, accelerant la computació global. Aquesta xarxa s'anomena graf acíclic dirigit o DAG en informàtica.

Consens sobre la reputació del node. És necessari?
L'amplada del canal d'una cadena de blocs lineal enfront de l'efecte multiplicador d'un DAG on tenim múltiples cadenes de blocs paral·leles.

Consens sobre la reputació del node. És necessari?
Implementació geomètrica de blockchain lineal contra DAG. Els punts negres són blocs, els punts blancs són nodes

Utilitzem 3 nodes a cada ronda de consens perquè ens ofereix alguns processos matemàtics interessants per raonar sobre l'estat, formant un "pla de superfície" a través de les dades en forma de triangles connectats. Aleshores, el protocol utilitza els triangles per unir una superfície òptima que no conté dades redundants o inconsistents i que tingui els triangles més petits possibles. Algorítmicament, això és anàleg a un "tall mínim" d'un gràfic, i matemàticament, és anàleg a una funció derivada o d'optimització (a partir de la qual la funció troba el camí més curt que pot recórrer al llarg de la superfície). Aquest camí més curt equival a emmagatzemar dades (transaccions) de manera òptima en un DAG. "Reds" triangulars en conflicte perquè la superfície de l'esdeveniment sigui llisa i lliure de conflictes.

Consens sobre la reputació del node. És necessari?
Implementació geomètrica de la detecció/maneig de conflictes. Un bloc en conflicte crea una rajola de superfície addicional. Traiem fitxes de superfície addicionals per mantenir una superfície plana (= lliure de conflictes).

Consens basat en la reputació

En un sistema de reputació p2p descentralitzat òptim, cada node hauria de poder determinar de manera independent la seva confiança en altres nodes. El nostre sistema utilitza un model especial que inclou relacions transitives, o relacions que un node té amb altres nodes, quan assigna una puntuació global. "Només sou tan bo com la vostra empresa". El resultat final és un "ses" o gradient basat en la confiança transitiva o la reputació a tots els nodes del $DAG o del canal normal. Això es pot considerar com un pinzell o un ratllador de formatge que esborra a través d'un "pla superficial" i selecciona quines "rajoles triangulars" esborrar i quines deixar. Així és com la lògica del conflicte elimina realment les "rajoles triangulars".

Consens sobre la reputació del node. És necessari?
Un DAG amb una rajola conflictiva que passa per un espai "corbat" que és un degradat, semblant a un ratllador de formatge, i eliminarà o "esborrarà" la rajola en conflicte.

Escalat parcial/complet del node

En teoria de xarxes, normalment l'assignació òptima es coneix com a "sense escala", que es pot descriure com una disposició jeràrquica amb grans nodes centrals que gestionen molts nodes perifèrics més petits. Aquesta distribució és visible per naturalesa i, sobretot, a Internet. Constellation utilitza aquesta arquitectura per "escalar" o augmentar el rendiment o l'amplada del nostre gràfic.

Consens sobre la reputació del node. És necessari?
L'efecte de la partició jeràrquica. Podem afegir més nodes augmentant l'ample de banda

Hylochain: suport d'aplicacions basades en canals

El nostre enfocament al suport d'aplicacions es pot pensar com una "plataforma de contracte intel·ligent descentralitzada". En lloc d'una xarxa central que executa tota la lògica i processa totes les dades de l'aplicació, Constellation coordina les dades de l'aplicació amb "canals domèstics", que es poden considerar com una estació de televisió que transmet totes les dades del sistema domèstic. Cada canal de personal pot implementar la seva pròpia lògica de verificació per resoldre el problema de l'oracle mitjançant l'autenticació d'extrem a extrem dels productors de dades i la verificació transitiva dels sistemes de personal compost. Les xarxes de canals estatals ofereixen suport paral·lel per a aplicacions, accelerant els temps d'adopció que estan limitats pel consens sincrònic tradicional en una xarxa de contracte intel·ligent.

Consens sobre la reputació del node. És necessari?
Dos canals estàndard que són "compatibles" mitjançant la xarxa $DAG. Poden interactuar o interpretar-se ja que tots dos estan "integrats" amb $DAG mitjançant la implementació de nodes híbrids $DAG + Canal.

La raó per la qual s'anomena Hylochain és perquè el nostre enfocament al suport d'aplicacions va utilitzar el model de programació funcional de Recursion Schemes per crear la interfície MapReduce. En particular, els esquemes de recursivitat d'Hilomorfisme i Metamorfisme es poden integrar per crear consultes verificables i connexions de flux sobre canals natius validant els tipus de dades algebraiques de la mateixa manera que es verifiquen els codis operatius per als contractes intel·ligents. El resultat final és una interfície MapReduce funcional que és familiar per als enginyers de dades i compatible amb la tecnologia de big data existent.

Consens sobre la reputació del node. És necessari?
Hilomorf i Metamòrfic són canals estàndard per al contrast. En l'estat metamòrfic, les dades de dos canals regulars s'envien a un bloc del metacanal. A Gilo, prenem l'estat anterior d'un canal i l'utilitzem per consultar (fer una pregunta específica) altres dos canals, i després emmagatzemar el resultat de la consulta en un bloc.

Tokenomics i la seva connexió amb Hylochain

Un cop creat un canal natiu, es pot integrar al canal $DAG, però utilitzant l'ACI o la interfície de la cadena d'aplicacions. Aquesta interfície és simplement un objecte JSON amb informació de configuració i una clau pública associada al propi canal. El motiu pel qual associem una clau pública amb un canal normal és crear un mecanisme d'intermediació per a les dades del canal normal. Quan es desplega el canal normal, els desenvolupadors configuren ells mateixos com es distribueixen els pagaments de la xarxa $DAG entre nodes i operadors.

Consens sobre la reputació del node. És necessari?
Flux de compra d'accés a la informació o modificació d'informació. La sol·licitud s'envia a $DAG, els fons s'envien al compte del canal, el resultat s'envia al comprador i la suma de comprovació de la transacció s'envia a la xarxa $DAG, que després allibera fons al canal normal.

Font: www.habr.com

Afegeix comentari