Lo sé, lo sé. Hay una multitud de cripto proyectos, con un montón de consensos: basados en el trabajo y la propiedad, en el oro, el petróleo, y incluso en empanadas horneadas (sí, existe uno así). ¿Qué más podemos esperar de uno más? Esto es lo que propongo discutir después de leer la traducción de la documentación técnica "simplificada" del proyecto *Constelación (). Claro, esta no es una descripción completa del algoritmo, pero me interesa la opinión de la comunidad de Habr, ¿hay lugar para un consenso así o es completamente innecesario?
Hay pocas letras a continuación, así que, si solo quieres escribir "uf, ¿cuánto se puede hablar de cripto?", por favor, abstente. Si te interesan los nuevos desarrollos en el ámbito de los sistemas distribuidos y tienes algo que compartir en los comentarios, por favor, sigue leyendo.
P.D. No soy el autor de la tecnología, no puedo garantizar la transmisión completa de su esencia, así que agradeceré los comentarios con correcciones, si los hay.
Evolución de consensos síncronos a asíncronos
Los nodos se seleccionan utilizando un proceso determinista (el mismo que se utiliza en DHT, por ejemplo, bittorrent), que regula dinámicamente las responsabilidades de los nodos para "facilitar" la validación o, más precisamente, para alcanzar el consenso. Elegimos grupos de 3 nodos y ejecutamos rondas de consenso en paralelo, de manera que un nodo puede actuar como facilitador en varios bloques. Esto nos permite procesar transacciones de manera asíncrona, lo que, en esencia, significa que tenemos múltiples blockchain formándose simultáneamente. El proceso es similar a una red formada por múltiples hilos, a diferencia de los nodos que forman una única cadena con el tiempo. El procesamiento asíncrono o paralelo es la base de la programación escalable, ya que permite utilizar todos los recursos de la computadora, acelerando los cálculos generales. Esta red se llama grafo acíclico dirigido o DAG en ciencias de la computación.
Ancho de banda de una blockchain lineal frente al efecto multiplicativo de un DAG, donde tenemos múltiples blockchains paralelos.
Implementación geométrica de blockchain lineal frente a DAG. Los puntos negros son bloques, los puntos blancos son nodos.
Utilizamos 3 nodos en cada ronda de consenso, porque esto nos proporciona algunos procesos matemáticos interesantes para razonar sobre el estado, formando una "superficie plana" a través de los datos en forma de triángulos con conexiones. Luego, el protocolo utiliza triángulos para "coser" la superficie óptima, que no contiene datos redundantes o contradictorios y tiene el menor número posible de triángulos. Algorítmicamente, esto es análogo a un "corte mínimo" de un grafo, y matemáticamente, a una derivada o función de optimización (de la cual la función encuentra el camino más corto que puede cruzar la superficie). Este camino más corto es equivalente al almacenamiento óptimo de datos (transacciones) en un grupo de base de datos de alta disponibilidad. Los triángulos en conflicto crean "baldosas" para que la superficie del evento sea uniforme y sin conflictos.
Implementación geométrica de detección / procesamiento de conflictos. Un bloque en conflicto crea una baldosa adicional en la superficie. Eliminamos la baldosa adicional de la superficie para mantener una superficie de eventos plana (= sin conflictos).
Consenso basado en la reputación
En un sistema de reputación p2p descentralizado óptimo, cada nodo debe ser capaz de determinar por sí mismo su confianza en otros nodos. Nuestro sistema utiliza un modelo especializado que incluye relaciones transitivas o relaciones que un nodo tiene con otros nodos, al asignar una evaluación global. "Eres tan bueno como tu empresa". El resultado final es una "distorsión" o gradiente basado en la confianza o reputación transitiva en todos los nodos en el $DAG o canal local. Esto se puede considerar como un rallador o una espátula que raspa sobre la "superficie plana" y elige qué "baldosas triangulares" borrar y cuáles dejar. Así es como la lógica del conflicto realmente elimina las "baldosas triangulares".
DAG con una baldosa en conflicto atravesando un espacio "curvado", que es un gradiente, similar a un rallador, y se prepara para eliminar o "borrar" la baldosa en conflicto.
Escalado parcial/completo de un nodo
En teoría de redes, la distribución óptima se conoce comúnmente como "sin escalado", que puede describirse como una disposición jerárquica con grandes nodos centrales que gestionan muchos nodos periféricos más pequeños. Esta distribución se observa en la naturaleza y, sobre todo, en Internet. Constellation utiliza esta arquitectura para "escalar", o aumentar el ancho de banda o la capacidad de nuestro Grafo.
Efecto de la partición jerárquica. Podemos agregar más nodos aumentando el ancho de banda.
Hylochain — Soporte para aplicaciones basadas en canales.
Nuestro enfoque para el apoyo a aplicaciones puede considerarse como una "plataforma descentralizada de contratos inteligentes". En lugar de una red central que ejecuta toda la lógica y procesa todos los datos de la aplicación, Constellation coordina los datos de la aplicación con "canales nativos", que pueden considerarse como una estación de televisión transmitiendo todos los datos del sistema nativo. Cada canal nativo puede implementar su propia lógica de verificación, permitiendo resolver el problema de los oráculos a través de la verificación cruzada de la autenticidad de los productores de datos y la verificación transitive de sistemas nativos compuestos. Las redes de canales nativos proporcionan soporte paralelo para aplicaciones, acelerando el tiempo de adopción, que en redes con contratos inteligentes está limitado por el consenso sincrónico tradicional.
Dos canales nativos 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 + Canal.
La razón por la que se llama Hylochain es que usamos un modelo funcional de programación a través de Esquemas de Recursión para crear una interfaz MapReduce en nuestro enfoque de soporte de aplicaciones. En particular, los esquemas de recursión Hylomorphism y Metamorphism pueden integrarse para generar consultas verificables y conexiones en flujo a través de canales estándar verificando 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 funcional MapReduce que es familiar para los ingenieros de datos y es compatible con la tecnología existente de Big Data.
Canales estándar Hylomorphic y Metamorphic para contrastar. En el estado metamórfico, los datos de dos canales estándar se envían a un bloque en el metacanale. En Hilo, tomamos el estado anterior del canal y lo usamos para consultar (formular una pregunta específica) otros dos canales, y luego guardamos el resultado de la consulta en un bloque.
Tokenómica y su relación con Hylochain
Cuando se crea un canal estándar, puede integrarse en el canal $DAG, pero utilizando la interfaz ACI o Interfaz de Cadena de Aplicaciones. 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 vinculamos la clave pública al canal estándar es para crear un mecanismo de corretaje para los datos del canal estándar. Una vez que el canal estándar está desplegado, los desarrolladores configuran cómo se distribuyen los pagos de la red $DAG entre nodos y operadores.
Flujo para comprar acceso a información o modificar 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 el resumen de la transacción se envía a la red $DAG, que luego desbloquea los fondos para el canal estándar.
Fuente: habr.com
