En la Fundación IOTA, los ingenieros e investigadores trabajan en estrecha colaboración, a menudo dentro del mismo equipo, siguiendo una metodología ágil. El enfoque es pragmático y sencillo:
- Definir el problema
- Hacer una lluvia de ideas para resolver un problema
- Transformar las ideas más prometedoras en soluciones
- Explorar las soluciones con una variedad de metodologías y diferentes ángulos: analíticamente, mediante simulaciones, mediante experimentos
- Sintetizar los datos recogidos y recoger las lecciones del punto 4 y utilizarlas para mejorar la solución
Uno de los mejores ejemplos de este enfoque es GoShimmer, el prototipo de investigación que lleva IOTA 2.0 DevNet. Su principal objetivo es convertir las ideas procedentes de la investigación en una implementación operativa, de modo que podamos evaluar aspectos importantes como la viabilidad, la protección frente a diferentes ataques y el rendimiento, así como corregir los errores en el camino.
El lanzamiento de la primera iteración de la DevNet IOTA 2.0 marcó un hito muy importante para el proyecto del Coordicide, ya que ahora tenemos la oportunidad de ver, experimentar y analizar el prototipo de nuestra solución totalmente descentralizada. Lo que hemos aprendido ya está ayudando a mejorar lo que hemos construido hasta ahora. Esta entrada del blog se centra en el mecanismo de consenso y en cómo podemos mejorar el protocolo introduciendo On Tangle FPC (OTFPC).
El mecanismo de consenso de IOTA 2.0 está diseñado para ser sin permisos y sin líderes. En su núcleo, combina
- un protocolo de votación binaria (FPC) como preconsenso y que rompa la metaestabilidad (es decir, obliga al sistema a tomar una decisión),
- y un protocolo de votación virtual o peso de aprobación (AW) que proporciona una finalidad similar a la regla de la cadena más larga en el consenso de Nakamoto (es decir, la rama más pesada).
Esta combinación es necesaria por dos razones. En primer lugar, necesitamos FPC para imponer una percepción común de lo que es bueno y malo. En segundo lugar, FPC establece la opinión inicial sobre las transacciones basándose en su hora de llegada (la regla FCoB): no obstante, las horas de llegada son delicadas (piensa en tu conexión a Internet doméstica), y cualquier regla basada en las horas de llegada hará que algunos nodos se desincronicen. Por tanto, el peso de aprobación es necesario para permitir que los nodos que están desincronizados se pongan al día.
Sin embargo, la combinación anterior hace que el código sea bastante complicado. Nos hemos dado cuenta de que podemos imitar el proceso de FPC utilizando el peso de aprobación de cada conflicto. En FPC, un nodo simplemente pregunta a otros nodos su opinión sobre una transacción. Sin embargo, cada vez que alguien hace referencia a una transacción, «vota» por ella, por lo que el peso de la aprobación registra quién ha votado por qué. Al cambiar las consultas directas por el AW, obtenemos un procedimiento que hemos denominado On Tangle FPC (OTFPC). En este post, explicaremos cómo nuestras mejoras consiguen tres cosas
- Simplificar en gran medida nuestro código base
- Reducir la sobrecarga de comunicación
- Acelerar los tiempos de confirmación
FPC
El protocolo Fast Probabilistic Consensus (FPC) es un protocolo de votación binaria en el que cada nodo comienza con una opinión inicial sobre una transacción establecida por FCoB. A continuación, los nodos intercambian consultas y respuestas sobre sus opiniones durante varias rondas, hasta que cada nodo termina con un valor final: me gusta o no me gusta. Pero el resultado de la votación está muy influenciado por la proporción de la opinión inicial. Por ejemplo, consideremos dos transacciones que entran en conflicto y que son vistas por la mayoría de la red dentro del primer tiempo de cuarentena (Q1). Entonces, con una alta probabilidad, ambas serán rechazadas por el FPC y, por tanto, no se añadirán al conjunto de tips y acabarán quedando huérfanas.
Sin un ganador claro, los nuevos nodos que se unan a la red o los nodos existentes que estén solidificando los mensajes que faltan podrían obtener sólo una de las dos transacciones (por ejemplo, debido a la solidificación indirecta a través de referencias débiles o a un fallo de la red), establecer la opinión inicial a gusto a través de FCoB y, por lo tanto, tratar de adjuntar sus nuevos mensajes en un lado del Enredo que no obtendrá suficiente peso de aprobación para ser confirmado alguna vez. Este comportamiento podría mitigarse comunicando simplemente los conflictos rechazados a costa de añadir algo de información extra a las declaraciones de la FPC.
Approval Weight -AW (Peso de Aprobación)
El peso de aprobación de un mensaje mide el porcentaje del mana de consenso activo de los nodos que emitieron un mensaje en su cono futuro (es decir, haciendo referencia a él directa o indirectamente). Además, el peso de aprobación se calcula de manera que el mana de consenso de un nodo no puede contar para el peso de aprobación de dos transacciones en conflicto. Por ejemplo, supongamos que A y B son transacciones conflictivas. Yo soy un nodo de alto mana, y emito un mensaje que hace referencia a A, entonces mi mana de consenso contribuyó al peso de aprobación de A. Pero si más tarde emito un mensaje aprobando B, entonces mi mana de consenso se resta del peso de aprobación de A y se añade a B.
Así, cuando el peso de aprobación de A es mayor del 50%, entonces sabemos que el peso de aprobación de B es menor del 50%. Por lo tanto, podemos decir que un mensaje (o una transacción) se finaliza cuando su peso de aprobación es mayor que el 50% más la fuerza de un posible atacante.
AW era originalmente un principio clave de la propuesta de Hans sobre el On Voting Tangle. En su propuesta, los nodos siempre seleccionarían los tips que hicieran referencia a las transacciones con el mayor peso de aprobación. Sin embargo, no está claro si esta propuesta funcionaría bien cuando el peso de aprobación de dos transacciones en conflicto estuviera empatado, de ahí la necesidad de algún elemento de desempate como el FPC. El peso de aprobación es, en realidad, similar al concepto de peso acumulativo del white paper, pero adaptado a un entorno en el que utilizamos mana como mecanismo de protección de Sybil.
Mejoras
Es importante notar que el protocolo actual no es fundamentalmente deficiente. De hecho, el actual mecanismo de consenso de IOTA 2.0 DevNet basado en FCoB y FPC ha resuelto con éxito cientos de conflictos en nuestro prototipo. Sin embargo, como nos hemos propuesto desarrollar la mejor DLT, nos gustaría optimizar el rendimiento del protocolo minimizando la complejidad del código, el tiempo de confirmación y la sobrecarga de comunicación.
¿Por qué es importante la complejidad del código? En primer lugar, cuanto más complejo sea el código, más difícil será detectar errores, lo que puede dar lugar a problemas de seguridad. En segundo lugar, los desarrolladores quieren construir sobre algo que puedan entender. Mantener el software del nodo más simple fomentará una mayor adopción.
Por esta razón, estamos haciendo dos cambios en el protocolo. En primer lugar, estamos cambiando el FPC por lo que llamamos On Tangle FPC (OTFPC). Como ya hemos dicho, en cada ronda en FPC consultamos a los nodos de la red su opinión sobre una transacción y, en función del porcentaje de consultas de respuestas afirmativas y de un umbral aleatorio, decidimos si nuestra opinión durante la siguiente ronda debe ser «me gusta» o «no me gusta».
En OTFPC, en lugar de utilizar las consultas directas, utilizamos el peso de la aprobación. Dado que los nodos no pueden tener su mana de consenso al peso de aprobación de dos conflictos diferentes, entonces el peso de aprobación es muy similar a una consulta, donde los nodos consultados son esencialmente aquellos que han referenciado ese mensaje. El OTFPC sigue funcionando en rondas, donde cada ronda un nodo utiliza el peso de aprobación y un umbral aleatorio para decidir qué transacciones le gustan. Las transacciones que han gustado dictan qué mensajes son elegibles para la selección de propinas, por lo que sólo las transacciones que han gustado ganarán peso de aprobación.
Con OTFPC, no necesitaremos ningún mecanismo de consulta directa, utilizando la propia Tangle como único medio de comunicación. Esto reducirá la sobrecarga de comunicación, reduciendo el ancho de banda necesario para el funcionamiento de un nodo.
En segundo lugar, en lugar de votar una opción binaria de «sí» o «no» en cada mensaje, los nodos utilizarán el FPC para elegir un ganador de una lista de transacciones en conflicto. Así, empleamos lo que llamamos FPC sobre un conjunto (FPCOS). Sin embargo, como OTFPCOS es un acrónimo poco agradable, omitimos el SO.
Al elegir un ganador, nos libramos de la regla FCoB, la regla que determina a quién gustar en función de los tiempos de llegada. A diferencia del FCoB, el OTFPC no utiliza tiempos de cuarentena que podrían llevar a tiempos de confirmación más largos. Los mensajes entrantes se añaden inmediatamente al conjunto de tips para que cualquier nodo pueda expresar su preferencia y emitir un voto para una determinada transacción dentro de un conjunto de conflictos mediante la selección de tips. Al igual que el mecanismo de peso de aprobación, la preferencia local de un nodo se rige por el peso de mana de consenso asociado a una determinada transacción en conflicto a través de referencias directas e indirectas a la misma. Así, OTFPC alineará mejor la opinión local de un nodo sobre una determinada transacción con su peso de aprobación, ya que sigue la misma regla de la rama más pesada. OTFPC también debería actuar más rápido que FCoB. Además, la aleatoriedad de OTFPC debería evitar que se produzcan estados metaestables.
Si quieres saber más sobre OTFPC puedes leer nuestro post en iota.cafe
Es muy importante destacar que este enfoque no es radicalmente diferente de lo que hemos estado haciendo. Aunque el FPC ha recibido mucha atención, el peso de la aprobación siempre ha sido la piedra angular del protocolo. Además, el FPC (y su primo el FPC sobre un conjunto) siempre se ha estudiado como un modelo matemático sin una implementación explícita. Nuestro desarrollo es simplemente una nueva implementación de este modelo matemático.
Toda la investigación y los experimentos realizados con el FPC siguen siendo relevantes, ya que el FPC sobre un conjunto no es más que una variante de éste, con la principal diferencia de que, dado un conjunto conflictivo, siempre selecciona un ganador. Ambos convergen al pre consenso en una sola ronda «afortunada». Sin embargo, la aparición de esta ronda es aleatoria, y cada vez ocurre con una probabilidad positiva uniforme. Por eso confiamos en que el FPCS es tan matemáticamente sólido como el FPC. No obstante, reconocemos que, aunque estos nuevos conceptos son algo sencillos de entender y, en muchos aspectos, fundamentalmente similares a lo que ya hemos estudiado, aún no han sido analizados en profundidad. Por lo tanto, como el diablo siempre está en los detalles, seguimos mejorando nuestros estudios sobre su comportamiento bajo diferentes casos límite y ataques. Como siempre, compartiremos nuestros hallazgos a través de nuestros medios, incluidas las publicaciones académicas.
Estamos entusiasmados con estas próximas mejoras, así como con otras actualizaciones de otros componentes, como el control de la congestión en el que estamos trabajando actualmente, y las integraremos gradualmente en la IOTA 2.0 DevNet con las próximas versiones.
El camino por delante
Desafortunadamente, los cambios anteriores harán imposible entregar el Coordicide en la red principal de IOTA en 2021. Cada nueva idea, aspecto, visión u oportunidad pasa por la metodología mencionada al principio de este artículo. Esto lleva tiempo: la excelencia no es rápida.
Tomar esta dirección fue una decisión difícil para nosotros y probablemente sea una decepción para algunos, y también somos conscientes de que nuestras estimaciones anteriores eran demasiado ambiciosas. Pero eso no cambia nuestra metodología, ni el rumbo, ni nuestro objetivo: producir el mejor DLT de la historia. A fin de cuentas, sería un error no mejorar el protocolo.
Aunque todavía no está terminado, las soluciones que estamos desarrollando ya están siendo utilizadas por desarrolladores individuales, proyectos y socios de la industria. Tenemos el maravilloso privilegio de haber creado una DLT que ha despertado el interés de un vasto ecosistema de actores globales y líderes de la industria, gobiernos, desarrolladores individuales y una comunidad con la que tenemos la responsabilidad de entregar una red fiable y segura sobre la que construir, con mínimos cambios de ruptura en el camino.
Esto también significa que no tomaremos ningún atajo para cumplir los plazos impulsando una solución técnica que ya querríamos cambiar con el tiempo. Nuestra lealtad está con aquellos que nos ayudan a hacer que la visión de IOTA se convierta en realidad: nuestra comunidad de constructores y hacedores, socios públicos y corporativos que confían en nuestro software y nos ayudan a desarrollar soluciones industriales con él. Están más interesados en la mejor solución posible, que en la solución más rápida pero mediocre que podría significar tener que hacer cambios más adelante. Por lo tanto, nos centramos en aquellos que participan, contribuyen y construyen, y que nos ayudan a realizar el potencial de IOTA. Ellos son los que determinarán el éxito de IOTA, del que todos se beneficiarán finalmente.
Si eres un desarrollador, no busques más allá de nuestros repos y el progreso del desarrollo, y sabrás con mucha antelación cuándo se producirá el Coordicide. Hasta entonces, tenemos mucho más que conseguir junto con IOTA 2.0 DevNet.
Como siempre, invitamos a todo el mundo a pasarse por Discord: ¡nuestro equipo estará más que encantado de responder a todas sus preguntas!
Apéndice: FCoB
Aunque no es estrictamente necesario para entender el post anterior, pensamos que una explicación de la regla FCoB podría aclarar las cosas. La regla del Consenso Rápido de Barcelona (FCoB) está diseñada para establecer una opinión inicial para cada transacción y minimizar la cantidad de votaciones necesarias a través del FPC. A grandes rasgos, FCoB utiliza dos intervalos de tiempo de cuarentena, llamémoslos Q1 y Q2. Para cada transacción recibida, un nodo coloca la transacción X en un búfer durante el tiempo Q1 (por ejemplo, 5 segundos). Durante este primer intervalo de tiempo (Q1), pueden darse diferentes casos
- si llega una transacción diferente Y que entra en conflicto con X, ambas transacciones recibirán una opinión inicial desfavorable y serán votadas activamente a través de FPC;
- si no se ha detectado ningún conflicto con X en Q1, el nodo colocará la transacción X en un segundo búfer durante el tiempo Q2 (por ejemplo, 5 segundos) y fijará su opinión inicial en like (me gusta).
Al igual que en el primer intervalo de tiempo, durante el segundo tiempo de cuarentena (Q2) pueden darse diferentes casos
- si llega una transacción diferente Y que entra en conflicto con X, Y obtendrá una opinión inicial de desagrado, y tanto X como Y serán votados a través de FPC;
- si no se ha detectado ningún conflicto con X, el nodo añadirá finalmente el mensaje que contiene la transacción X a su pool de consejos para que pueda ser seleccionado como consejo.
Una vez que un nodo ha definido su opinión local sobre una transacción X, ya sea a través de FCoB o tras la conclusión de FPC, cualquier nueva transacción posterior que entre en conflicto con X obtendrá una opinión local de desagrado. En última instancia, la combinación de FCoB y FPC es sólo un mecanismo de preconsenso, el peso de aprobación construido sobre el cono futuro de cualquier mensaje dicta el estado de finalidad de un mensaje, así como su transacción incrustada. Así, si un nodo establece una opinión errónea para una transacción, puede corregirla mirando su peso de aprobación.
Está claro que definir la duración de los dos intervalos de tiempo de cuarentena, Q1 y Q2, es fundamental. No sólo la ejecución correcta de FCoB se basa en la suposición de que la mayoría de la red recibirá cualquier mensaje dentro de esos intervalos, sino que los intervalos también tienen un impacto en el tiempo de confirmación general de cualquier transacción, incluso las honestas.
Pongamos un ejemplo estableciendo Q1 = Q2 = 5 segundos. Cualquier nueva transacción X recibida por un nodo tendrá que esperar Q1 + Q2 = 10 segundos antes de entrar en el pool de propinas y estar disponible como propina. Sólo después de que la mayoría de los nodos de Mana con consenso activo emitan un mensaje que apruebe directa o indirectamente X, nuestra transacción se considerará confirmada.
Disminuir los valores de Q1 y Q2 seguramente conduciría a tiempos de confirmación más cortos, pero con la limitación de que sus valores no pueden ser menores que el retraso máximo de la red.
Post Original: Improvements to the IOTA 2.0 Consensus Mechanism
