TL;DR:
Proporcionamos una visión detallada del estado actual y los próximos pasos para IOTA 2.0. Los esfuerzos actuales se centran principalmente en la optimización de la capa de consenso y comunicación para hacer el protocolo más eficiente y menos complejo. Los próximos pasos implican la implementación de defensas activas y características de usabilidad como los snapshots locales.
Introducción
El lanzamiento de la DevNet para IOTA 2.0 marcó uno de los hitos más importantes en la historia de la Fundación IOTA. Por primera vez, no sólo fuimos capaces de demostrar las ideas detrás de IOTA 2.0 en una red real, totalmente descentralizada y libre de Coordinator, sino que también pudimos estudiar la interacción de los diferentes componentes.
La capacidad de medir y evaluar el rendimiento de cada uno de estos componentes nos ha permitido discutir y decidir una serie de optimizaciones para hacer el protocolo más robusto, eficiente y menos complejo.
La mayoría de los cambios consisten en pequeñas optimizaciones del flujo de datos y simplificaciones del código. Pero también hemos realizado ajustes en la capa de comunicación y algunos cambios cruciales en la capa de consenso.
Las mejoras en la capa de consenso simplifican significativamente el protocolo al derivar toda la información de la Tangle y manejar las transacciones entrantes de manera optimista. La primera implementación se ha completado, y simultáneamente estamos trabajando en simulaciones en profundidad y en artículos de investigación. Sólo quedan por implementar algunos cambios más, mientras seguimos por un camino claro.
En cuanto a la capa de comunicación, actualmente se ha implementado un algoritmo de programación eficiente en la IOTA 2.0 DevNet. Este funciona con un módulo de fijación de tarifas para garantizar la equidad y los retrasos cortos. Como siguiente paso, implementaremos un mecanismo para penalizar a los atacantes, que ya está especificado. Además, actualmente estamos trabajando para ofrecer una experiencia de usuario mejorada que facilite el uso de la red.
Este blog, de carácter más técnico, se adentra en los detalles de las mejoras de IOTA 2.0, describe el estado actual y traza un panorama general del camino que tenemos por delante.
Capa de consenso
La visión
Como se describió en un anterior del blog, en lugar de pedir la opinión de otros nodos para resolver conflictos, los nodos obtienen ahora toda la información que necesitan simplemente observando la Tangle. El protocolo resultante es muy similar a la visión original de IOTA, que utilizaba un consenso puro al estilo de Nakamoto sin una sobrecarga de votación adicional, donde los nodos declaran su opinión creando mensajes en la Tangle.
Con FCOB+FPC cada transacción se penalizaba con un tiempo de cuarentena para establecer una opinión inicial y romper la meta estabilidad desde el principio en el raro caso de conflictos que no puedan resolverse a tiempo. Por el contrario, los cambios en el consenso permiten a los nodos exponer su opinión sin aplicar un tiempo de cuarentena. Sólo cuando un conflicto queda sin resolver durante algún tiempo se activa un mecanismo de ruptura de la meta estabilidad como el FPCS para decidir el conflicto. Este procedimiento optimista no sólo acelera los tiempos de confirmación, sino que también hace que el protocolo sea mucho más sencillo y ligero.
Dónde estamos ahora mismo
La implementación de las mejoras del consenso avanza a gran velocidad: Se ha completado una primera implementación de la Votación On Tangle (OTV) como función modular de selección de conflictos y el interruptor like esté completo y actualmente estamos en la fase de pruebas, corrección de errores y redacción de la documentación. Los próximos pasos inmediatos implican la simplificación de los marcadores para el Peso de Aprobación (AW) y la actualización de las herramientas, es decir, la cartera GUI, la biblioteca y su documentación.
La primera versión de nuestro rompedor de meta estabilidad basado en FPC ha sido validada exhaustivamente por el mundo académico (FPC-BI, Fast Probabilistic Consensus with Weighted Votes). Los mismos resultados y conceptos pueden extenderse a nuestra actual propuesta optimizada, que es una modificación directa del FPC original y que pronto estará disponible en un riguroso artículo científico. Continuaremos nuestra validación preparando un artículo de investigación científica que demuestre la fuerza de nuestro mecanismo de consenso mejorado.
Además de describir el mecanismo de OTV, analizaremos su rendimiento realizando amplios estudios de simulación basados en el simulador multiverso, que actualmente se está ampliando para que sirva de marco general de simulación para nuestro consenso. Esto incluye el estudio de los tiempos de confirmación y la resistencia en varios escenarios de doble gasto, así como la consideración de un entorno adverso. Por último, incorporaremos OTV junto con FPC en un conjunto (FPCS) y exploraremos las implicaciones de estas simbiosis en detalle.
El camino a seguir
Con la OTV pura, los nodos establecen su opinión inicial sobre los conflictos basándose en su percepción del branch más pesado, lo que hace que el protocolo se comporte de forma similar a la regla de la cadena más larga de Bitcoin. Esto significa que el consenso es inherentemente probabilístico y el cliente (por ejemplo, un nodo, una cartera o un intercambio) decide en su umbral de seguridad cuándo considerar una transacción como confirmada (esto se conoce como la regla de los 6 bloques en Bitcoin). En consecuencia, introduciremos varios Grados de Finalidad (GoF), principalmente basados en el Peso de Aprobación, que definen umbrales de seguridad crecientes. Cuanto mayor sea el grado, mayor será la seguridad. Sin embargo, en casos raros (por ejemplo, al ser eclipsado o estar parcialmente desconectado) un nodo podría recibir información faltante en un momento posterior, lo que podría provocar la necesidad de reorganizar su percepción local, al igual que en Bitcoin. Afortunadamente, una configuración alta de GoF hace que estos sucesos sean prácticamente imposibles. No obstante, este procedimiento de reorganización debe implementarse en el software del nodo para restablecer los componentes que dependen de la confirmación.
Una vez que tengamos una versión estable de la OTV pura con la reorganización en marcha, podemos centrarnos en la implementación de un mecanismo de ruptura de meta estabilidad que vaya de la mano de la OTV pura, y que se active si un conflicto no se resuelve durante demasiado tiempo. En concreto, primero implementaremos el Consenso Probabilístico Rápido en un conjunto (FPCS) como mecanismo de ruptura de meta estabilidad, utilizando resultados positivos de investigaciones anteriores. La función modular de selección de conflictos nos permite intercambiar fácilmente la forma en que establecemos la opinión inicial; por lo tanto, incluso experimentar con otros enfoques para alcanzar el consenso sólo implica pequeños ajustes de código.
Como protección Sybil, los votos se ponderan por cMana. Sin embargo, los valores absolutos de cMana podrían no aportar suficiente información. En su lugar, utilizamos cMana activo para expresar el peso de un nodo en relación con todos los nodos recientemente activos. Por lo tanto, la cMana activa es un componente crucial y necesita un estudio riguroso para entender sus límites y limitaciones.
Capa de comunicación
La visión
En las tecnologías tradicionales de ledger distribuido basadas en Proof of Work (DLT), el derecho a añadir un nuevo mensaje al ledger está garantizado por el proceso de minería, en el que uno de los nodos es elegido tras completar alguna tarea computacionalmente costosa. Como incentivo para realizar dicha tarea, el nodo ganador obtiene tasas de transacción y recompensas por bloque. En este tipo de DLTs, las tasas actúan como un filtro para seleccionar qué mensajes deben añadirse al libro de contabilidad: en consecuencia, durante los periodos de congestión, el importe de las tasas es mayor.
IOTA, por otro lado, pretende ser la columna vertebral de las economías digitales emergentes, en particular la economía de las máquinas. Por lo tanto, un protocolo que requiere cuotas y dispositivos de alta gama no es factible ni sostenible. Sin embargo, la supresión de las cuotas requiere la adopción de un mecanismo explícito para hacer frente a las grandes ráfagas de tráfico.
En la Fundación IOTA adoptamos un enfoque inspirado en la «Internet estándar» para definir el Algoritmo de Control de Congestión IOTA (ICCA). A diferencia de las DLTs basadas en Proof of Work, nuestro enfoque permite la explotación óptima de los recursos de la red, limitada únicamente por las restricciones físicas de la red en términos de ancho de banda y capacidad de procesamiento de transacciones. Además, ICCA puede ser utilizado eficientemente por los nodos de gama baja, ya que no requiere ninguna tarea costosa o tasas. Nuestra solución ofrece otras características fundamentales:
- Consistencia: todos los nodos escriben finalmente los mismos mensajes en su ledger local.
- Equidad: el acceso a la red se concede de forma proporcional a un «recurso escaso», que es el maná de acceso (véase a continuación).
- Eficiencia: si existe la demanda, se utilizará todo el potencial de la red.
Dónde estamos ahora
Esta subsección describe las acciones que debe realizar un nodo cuando se crea un nuevo mensaje y cuando se recibe un mensaje de un vecino, y que actualmente están implementadas en la IOTA 2.0 DevNet.
Generación de mensajes
Una cantidad llamada access Mana proporciona derechos de escritura a los nodos. Desde la perspectiva del usuario, el Mana de acceso se traduce en un cierto rendimiento para el nodo. Curiosamente, este rendimiento se adapta a las condiciones de tráfico actuales: los nodos aumentan progresivamente su tasa de generación de mensajes (rendimiento) hasta el punto en que se detecta la congestión; una vez que esto ocurre, el rendimiento se reduce. Los nodos detectan la congestión observando el número de sus propios mensajes en espera en su búfer de salida.
Recepción de mensajes
Una vez que un mensaje sólido recién recibido (véase el siguiente párrafo) pasa ciertos filtros de validación (como la comprobación de la firma y la validación sintáctica), se añade al ledger local. Después de esto, el mensaje se añade al búfer de salida gestionado por un planificador para decidir qué mensaje debe añadirse al conjunto de consejos y cotillear a los vecinos. El programador utiliza un algoritmo ligero de rotación para tratar con eficacia un gran número de mensajes simultáneos. Recientemente, hemos trasladado el scheduler después de la reserva de mensajes para optimizar el procedimiento de resincronización.
Solidificación
La solidificación es el proceso de solicitar mensajes cuyo cono pasado aún no es conocido por un nodo. Del mismo modo, cuando se trata de transacciones, las salidas (entradas) consumidas de una transacción deben ser conocidas por un nodo para poder validar correctamente la transacción. En el pasado, el protocolo requería que todas las entradas de una transacción estuvieran en el cono pasado de su mensaje. Para validar si algo está en el cono del pasado puede ser necesario caminar por el Tangle, lo cual es una operación cara y ha demostrado ser inviable en la DevNet. Por lo tanto, se ha implementado la primera versión de un enfoque diferente de la solidificación, que no sólo elimina el requisito del cono pasado, sino que también simplifica el flujo de datos y permite una mayor paralelización.
El camino a seguir
Resistencia a los ataques
En las DLT, los nodos maliciosos tienen un gran interés en afectar al funcionamiento de la red. Por esta razón, cada solución debe ser validada contra todas las amenazas potenciales. Como hemos demostrado experimentalmente, ICCA es resistente a los ataques: cuando los atacantes intentan obtener un rendimiento más rápido que el permitido, sus mensajes son retrasados por los nodos honestos, ya que no serán programados de acuerdo con el vector de acceso Mana actual. Por lo tanto, los mensajes emitidos por el atacante permanecerán en las bandejas de salida de los nodos honestos durante mucho tiempo. Aunque esto no afecta al rendimiento de los mensajes honestos, es importante identificar estos comportamientos maliciosos por dos razones (i) el atacante puede inflar el número de mensajes en las bandejas de salida de sus vecinos, haciendo que se queden sin recursos; (ii) los nodos honestos pueden haber adjuntado encima mensajes maliciosos, lo que lleva a libros de contabilidad inconsistentes entre los nodos. Para superar estos problemas, pondremos en una lista negra a los nodos maliciosos, eliminando sus mensajes. Los flujos maliciosos se detectan cuando el número de sus mensajes en la bandeja de salida supera un umbral determinado. El modo en que se establece este umbral (que es fundamental para detectar rápidamente el comportamiento malicioso sin poner en la lista negra a los nodos honestos) se ha descrito en un artículo reciente y pronto se implementará en nuestra DevNet.
También es importante tener una estimación precisa de la validez de las marcas de tiempo dentro de los mensajes. Por ejemplo, los mensajes antiguos no deberían añadirse al planificador ya que, con alta probabilidad, ya han sido recibidos por los vecinos. Además, no es deseable añadir mensajes antiguos, ya que esto aumentaría el tiempo de confirmación de los nuevos (suponemos que los mensajes antiguos ya han sido validados). Además, se necesitan marcas de tiempo precisas para garantizar una resincronización rápida y disuadir a los atacantes de perjudicar el rendimiento del protocolo. Actualmente estamos investigando una métrica, llamada puntuación de inclusión, que evalúa la probabilidad de que un mensaje sea considerado como «reciente» y esté listo para ser programado: esta métrica tiene en cuenta la marca de tiempo del mensaje y la ocupación del programador de los mensajes del nodo emisor.
Experiencia del usuario
El rendimiento de un nodo está regulado por el algoritmo de fijación de la tasa. Esto significa que los nodos no pueden generar continuamente mensajes en caso de congestión, ya que serían penalizados por ICCA. Actualmente estamos trabajando para proporcionar estimaciones del rendimiento de los nodos calculadas en función del vector de acceso Mana. Con una estimación razonable, sería posible responder a la siguiente pregunta: supongamos que un usuario (un monedero o un nodo) tiene un nuevo mensaje que emitir: ¿qué nodo debe elegirse para que este mensaje se añada rápidamente al ledger de IOTA? Esta dirección de investigación trata de asignar nuevos mensajes a los nodos que están menos ocupados en un momento dado. Hemos formulado este reto como un problema de optimización y estamos probando algunas políticas propuestas basadas en la ocupación del creador de mensajes o el retraso por nodo.
Por otro lado, recordemos que el tiempo necesario para que un mensaje sea entregado a todos los nodos es (casi) independiente del Mana de acceso del nodo emisor. Esto implica que el vector Mana de acceso sólo regula el ritmo de creación de nuevos mensajes, pero no afecta a la usabilidad de la red. Por término medio, se espera que los retrasos sean razonablemente bajos: estimamos que, en condiciones normales, los mensajes permanecen en el planificador durante apenas fracciones de segundo; en condiciones de mucho tráfico, este retraso aumenta ligeramente. En la propuesta actual, tratamos el tráfico intenso estableciendo un umbral mínimo de mana requerido a los nodos para poder emitir mensajes: trivialmente, si dicho umbral es menor, más nodos pueden emitir mensajes y potencialmente crear congestión. Actualmente estamos trabajando en la adaptación oportunista de este umbral con respecto al tráfico actual.
Snapshots
La Tangle puede llegar a ser muy grande, y no todos los usuarios podrán hacer un seguimiento de toda su historia hasta su génesis. Por lo tanto, los Snapshots locales deberían permitir a los nodos podar su base de datos de forma segura; es decir, se pueden eliminar datos suficientemente antiguos sin dañar la seguridad de la red. Los Snapshots dependen de muchas partes del protocolo y tienen un impacto directo en la tolerancia a las particiones, ya que éstas no pueden fusionarse más allá de los Snapshots locales. También está estrechamente relacionado con la sincronización sin confianza, porque los nodos que no tienen el historial completo desde la génesis no pueden verificar fácilmente el estado del ledger sin un mecanismo adicional, como el árbol de merkle o los compromisos polinómicos. Estos temas se están investigando actualmente.
Conclusión
La DevNet de IOTA 2.0 ha proporcionado a nuestro equipo una valiosa información sobre nuestra búsqueda para descentralizar completamente la red IOTA con un protocolo de ledger distribuido sin líderes, sin fees y sin permisos.
Hemos hecho grandes progresos en la implementación de GoShimmer añadiendo algunas de las recientes mejoras (especialmente con el consenso) y empezando a refactorizar el código base. Aunque estamos entusiasmados con este progreso iterativo hacia una implementación estable de la red, todavía hay varias cuestiones clave de investigación que nuestro equipo debe evaluar, validar y luego implementar en GoShimmer. Confiamos en que estos cambios harán que el protocolo sea en general más seguro, más sencillo de implementar y más rápido de usar.
Una vez que hayamos implementado todos los cambios necesarios, actualizaremos la IOTA 2.0 DevNet e invitaremos a la comunidad IOTA, junto con nuestro equipo y socios de investigación, a participar y experimentar con el protocolo mejorado. Basándose en los resultados y en los comentarios de esa red, nuestro equipo trabajará entonces en la finalización de las especificaciones de IOTA 2.0 y comenzará con el desarrollo de una implementación estable en Go y Rust. Esto conducirá al lanzamiento de IOTA 2.0.
