Sei que sei. Hai moitos proxectos criptográficos, hai moitos consensos: baseados no traballo e a propiedade, ouro, aceite, empanadas (hai unha, si, si). Que máis necesitamos dun? Isto é o que propoño comentar despois de ler a tradución da documentación técnica "lixeira" do proxecto *Constellation (). Por suposto, esta non é unha descrición completa do algoritmo, pero estou interesado na opinión da comunidade Habr, hai lugar para que ese consenso "sexa" ou é innecesario?
Non hai moitas máis letras, así que se só queres escribir "guau, todo o que poidas sobre cripto", absterse. Se estás interesado en novos desenvolvementos no campo dos sistemas distribuídos e tes algo que compartir nos comentarios, consulta o cat.
PD: Non son o autor da tecnoloxía, non podo garantir a transferencia completa da esencia, polo que estarei encantado de recibir comentarios con emendas, se as houbese.
Evolución de consensos sincrónicos a asíncronos
Os nodos son seleccionados mediante un proceso determinista (o mesmo que se usa en DHT como bittorrent) que axusta dinámicamente as responsabilidades dos nodos para "facilitar" a validación ou, máis comprensiblemente, para conseguir consenso. Seleccionamos grupos de 3 nodos e realizamos roldas de consenso en paralelo para que un nodo poida ser un facilitador en varios bloques. Isto permítenos procesar transaccións de forma asíncrona, o que significa esencialmente que temos varias cadeas de bloques que se están formando ao mesmo tempo. O proceso é como unha tea de araña, formada por moitos fíos, en oposición aos nós que forman unha única cadea ao longo do tempo. O procesamento asíncrono ou paralelo é a base da programación escalable porque permite o uso de todos os recursos informáticos, acelerando a computación global. Esta rede denomínase grafo acíclico dirixido ou DAG en informática.
Ancho da canle dunha cadea de bloques lineal fronte ao efecto multiplicativo dun DAG onde temos varias cadeas de bloques paralelas.
Implementación xeométrica de blockchain lineal contra DAG. Os puntos negros son bloques, os brancos son nós
Usamos 3 nodos en cada rolda de consenso porque nos proporciona algúns procesos matemáticos interesantes para razoar sobre o estado, formando un "plano de superficie" a través dos datos en forma de triángulos conectados. A continuación, o protocolo usa os triángulos para unir unha superficie óptima que non conteña datos redundantes ou inconsistentes e que teña os triángulos máis pequenos posibles. Algorítmicamente, isto é análogo a un "corte mínimo" dun gráfico, e matemáticamente, é análogo a unha función derivada ou de optimización (a partir da cal a función atopa o camiño máis curto que pode percorrer ao longo da superficie). Este camiño máis curto equivale a almacenar datos (transaccións) de forma óptima nun DAG. "Telas" triangulares en conflito para que a superficie do evento sexa lisa e libre de conflitos.
Implementación xeométrica da detección/tratamento de conflitos. Un bloque en conflito crea unha tella de superficie adicional. Eliminamos tellas de superficie adicionais para manter unha superficie plana (= sen conflitos).
Consenso baseado na reputación
Nun sistema de reputación p2p descentralizado óptimo, cada nodo debería poder determinar de forma independente a súa confianza noutros nodos. O noso sistema utiliza un modelo especial que inclúe relacións transitivas, ou relacións que un nodo ten con outros nodos, ao asignar unha puntuación global. "Só es tan bo como a túa empresa". O resultado final é un "sesgo" ou gradiente baseado na confianza transitiva ou na reputación en todos os nós do $DAG ou da canle normal. Isto pódese considerar como un pincel ou un ralador de queixo que borra nun "plano de superficie" e selecciona que "tellas triangulares" borrar e cales deixar. Así é como a lóxica do conflito elimina realmente as "tellas triangulares".
Un DAG cunha tella en conflito atravesando un espazo "curvo" que é un degradado, semellante a un ralador de queixo, e vai eliminar ou "borrar" a tella en conflito.
Escalado de nodos parcial/total
Na teoría de redes, normalmente a asignación óptima coñécese como "sen escala", que se pode describir como unha disposición xerárquica con grandes nodos centrais que xestionan moitos nodos periféricos máis pequenos. Esta distribución é visible na natureza e, sobre todo, en Internet. Constellation usa esta arquitectura para "escalar" ou aumentar o rendemento ou o ancho do noso gráfico.
O efecto da partición xerárquica. Podemos engadir máis nodos aumentando o ancho de banda
Hylochain - Soporte de aplicacións baseadas en canles
O noso enfoque para o soporte de aplicacións pódese considerar unha "plataforma de contrato intelixente descentralizada". En lugar dunha rede central que executa toda a lóxica e procesa todos os datos da aplicación, Constellation coordina os datos da aplicación con "canles domésticos", que se poden considerar como unha estación de televisión que transmite todos os datos do sistema doméstico. Cada canle de persoal pode implementar a súa propia lóxica de verificación para resolver o problema do oráculo mediante a autenticación de extremo a extremo dos produtores de datos e a verificación transitiva dos sistemas de persoal compostos. As redes de canles estatais ofrecen soporte paralelo para aplicacións, acelerando os tempos de adopción que están limitados polo consenso sincrónico tradicional nunha rede de contrato intelixente.
Dúas canles estándar que son "compatibles" a través da rede $DAG. Poden interactuar ou interpretarse xa que ambos están "integrados" con $DAG mediante a implantación de nós híbridos $DAG + Canle.
O motivo polo que se chama Hylochain é porque o noso enfoque para o soporte de aplicacións utilizou o modelo de programación funcional Recursion Schemes para crear a interface MapReduce. En particular, os esquemas de recursión de hilomorfismo e metamorfismo pódense integrar para crear consultas verificables e conexións de transmisión en canles nativas mediante a validación dos tipos de datos alxébricos do mesmo xeito que se verifican os códigos de operación para os contratos intelixentes. O resultado final é unha interface MapReduce funcional que é familiar para os enxeñeiros de datos e compatible coa tecnoloxía de big data existente.
Hylomorphic e Metamorphic son canles estándar para o contraste. No estado metamórfico, os datos de dúas canles regulares envíanse a un bloque da metacanle. En Gilo, tomamos o estado anterior dunha canle e usámolo para consultar (facer unha pregunta específica) outras dúas canles e, a continuación, almacenamos o resultado da consulta nun bloque.
Tokenomics e a súa conexión con Hylochain
Unha vez creada unha canle nativa, pódese integrar na canle $DAG, pero utilizando a interface ACI ou Application Chain. Esta interface é simplemente un obxecto JSON con información de configuración e unha chave pública asociada á propia canle. O motivo polo que asociamos unha chave pública cunha canle normal é para crear un mecanismo de intermediación para os datos da canle normal. Cando se implanta a canle normal, os desenvolvedores configuran por si mesmos como se distribúen os pagos da rede $DAG entre os nodos e os operadores.
Fluxo de compra acceso á información ou modificación da información. A solicitude envíase a $DAG, os fondos envíanse á conta da canle, o resultado envíase ao comprador e a suma de verificación da transacción envíase á rede $DAG, que logo libera fondos á canle normal.
Fonte: www.habr.com