Sé que sé. Hay muchos proyectos criptográficos, hay muchos consensos: basados en mano de obra y propiedad, oro, petróleo, pasteles horneados (hay uno, sí, sí). ¿Qué más necesitamos de uno? Esto es lo que propongo discutir después de leer la traducción de la documentación técnica “ligera” del proyecto *Constellation (). Por supuesto, esta no es una descripción completa del algoritmo, pero me interesa la opinión de la comunidad Habr: ¿existe lugar para que tal consenso "sea" o es innecesario?
No hay muchas más letras, así que si solo quieres escribir "guau, todo lo que puedas sobre criptomonedas", abstente. Si está interesado en nuevos desarrollos en el campo de los sistemas distribuidos y tiene algo que compartir en los comentarios, consulte el cat.
PD: No soy el autor de la tecnología, no puedo garantizar la transferencia completa de la esencia, por lo que estaré encantado de recibir comentarios con modificaciones, si las hubiera.
Evolución de consensos sincrónicos a asincrónicos
Los nodos se seleccionan mediante un proceso determinista (el mismo que se utiliza en DHT como bittorrent) que ajusta dinámicamente las responsabilidades de los nodos para "facilitar" la validación o, más comprensiblemente, para lograr el consenso. Seleccionamos grupos de 3 nodos y realizamos rondas de consenso en paralelo para que un nodo pueda ser facilitador en múltiples bloques. Esto nos permite procesar transacciones de forma asincrónica, lo que esencialmente significa que se forman múltiples cadenas de bloques al mismo tiempo. El proceso es como una telaraña, formada por muchos hilos, a diferencia de los nodos que forman una sola cadena con el tiempo. El procesamiento asincrónico o paralelo es la base de la programación escalable porque permite el uso de todos los recursos de la computadora, acelerando la computación general. Esta red se llama gráfico acíclico dirigido o DAG en informática.
Ancho del canal de una cadena de bloques lineal versus el efecto multiplicativo de un DAG donde tenemos múltiples cadenas de bloques paralelas.
Implementación geométrica de blockchain lineal contra DAG. Los puntos negros son bloques, los puntos blancos son nodos.
Usamos 3 nodos en cada ronda de consenso porque nos brinda algunos procesos matemáticos interesantes para razonar sobre el estado, formando un "plano de superficie" a través de los datos en forma de triángulos conectados. Luego, el protocolo utiliza los triángulos para unir una superficie óptima que no contiene datos redundantes o inconsistentes y tiene los triángulos más pequeños posibles. Algorítmicamente, esto es análogo a un “corte mínimo” de un gráfico, y matemáticamente, es análogo a una función derivada u optimización (a partir de la cual la función encuentra el camino más corto que puede recorrer a lo largo de la superficie). Esta ruta más corta equivale a almacenar datos (transacciones) de manera óptima en un DAG. “Azulejos” triangulares en conflicto para que la superficie del evento quede lisa y libre de conflictos.
Implementación geométrica de detección/manejo de conflictos. Un bloque en conflicto crea una superficie adicional. Eliminamos mosaicos de superficie adicionales para mantener una superficie del evento plana (= libre de conflictos).
Consenso basado en la reputación
En un sistema de reputación p2p descentralizado óptimo, cada nodo debería poder determinar de forma independiente su confianza en otros nodos. Nuestro sistema utiliza un modelo especial que incluye relaciones transitivas, o relaciones que un nodo tiene con otros nodos, al asignar una puntuación global. "Eres tan bueno como tu empresa". El resultado final es un "sesgo" o gradiente basado en la confianza o reputación transitiva en todos los nodos del $DAG o canal regular. Esto se puede considerar como un cepillo o un rallador de queso que borra a lo largo de un “plano de superficie” y selecciona qué “azulejos triangulares” borrar y cuáles dejar. Así es como la lógica del conflicto elimina en realidad los “cuadros triangulares”.
Un DAG con una ficha en conflicto que atraviesa un espacio "curvo" que es un degradado, similar a un rallador de queso, y va a eliminar o "borrar" la ficha en conflicto.
Escalado de nodo parcial/completo
En teoría de redes, la asignación óptima normalmente se conoce como “sin escala”, que puede describirse como una disposición jerárquica con grandes nodos centrales que administran muchos nodos periféricos más pequeños. Esta distribución es visible en la naturaleza y, sobre todo, en Internet. Constellation utiliza esta arquitectura para "ampliar" o aumentar el rendimiento o el ancho de nuestro Graph.
El efecto de la partición jerárquica. Podemos agregar más nodos aumentando el ancho de banda.
Hylochain: soporte de aplicaciones basadas en canales
Nuestro enfoque de soporte de aplicaciones puede considerarse como una "plataforma de contrato inteligente descentralizada". En lugar de una red central que ejecute toda la lógica y procese todos los datos de la aplicación, Constellation coordina los datos de la aplicación con "canales internos", que pueden considerarse como una estación de televisión que transmite todos los datos del sistema interno. Cada canal de personal puede implementar su propia lógica de verificación para resolver el problema de Oracle mediante la autenticación de extremo a extremo de los productores de datos y la verificación transitiva de sistemas de personal compuestos. Las redes de canales estatales brindan soporte paralelo para aplicaciones, lo que acelera los tiempos de adopción que están limitados por el consenso sincrónico tradicional en una red de contratos inteligentes.
Dos canales estándar que son “compatibles” a través de la red $DAG. Pueden interactuar o ser interpretados ya que ambos están "integrados" con $DAG mediante la implementación de nodos híbridos $DAG + Channel.
La razón por la que se llama Hylochain es porque nuestro enfoque de soporte de aplicaciones utilizó el modelo de programación funcional Recursion Schemes para crear la interfaz MapReduce. En particular, los esquemas de recursión de hilomorfismo y metamorfismo se pueden integrar para crear consultas verificables y transmitir conexiones a través de canales nativos validando tipos de datos algebraicos de la misma manera que se verifican los códigos de operación para contratos inteligentes. El resultado final es una interfaz MapReduce funcional que resulta familiar para los ingenieros de datos y compatible con la tecnología de big data existente.
Hilomorfo y Metamórfico son canales estándar de contraste. En el estado metamórfico, los datos de dos canales regulares se envían a un bloque en el metacanal. En Gilo, tomamos el estado anterior de un canal y lo usamos para consultar (hacer una pregunta específica) otros dos canales y luego almacenar el resultado de la consulta en un bloque.
Tokenomics y su conexión con Hylochain
Una vez creado un canal nativo, se puede integrar al canal $DAG, pero usando ACI o Application Chain Interface. Esta interfaz es simplemente un objeto JSON con información de configuración y una clave pública asociada al propio canal. La razón por la que asociamos una clave pública con un canal normal es para crear un mecanismo de intermediación para los datos del canal normal. Cuando se implementa el canal normal, los desarrolladores configuran ellos mismos cómo se distribuyen los pagos de la red $DAG entre nodos y operadores.
Flujo de compra de acceso a información o modificación de información. La solicitud se envía a $DAG, los fondos se envían a la cuenta del canal, el resultado se envía al comprador y la suma de verificación de la transacción se envía a la red $DAG, que luego libera fondos al canal normal.
Fuente: habr.com