Nos complace compartir la siguiente actualización de nuestros grupos de investigación. El departamento sigue centrado en mejorar la implementación del protocolo IOTA 2.0 en la DevNet.
Este mes, nuestra actualización presenta dos nuevos grupos: el Grupo de Consenso y el Grupo de Capa de Comunicación. El Grupo de Consenso se formó para resolver el problema de retraso en la propagación de los mensajes, que se expuso en nuestra actualización mensual de Julio. El trabajo de simulación y prueba de nuestro mecanismo de consenso mejorado ha dado buenos resultados hasta ahora. El Grupo de la Capa de Comunicación, como su nombre indica, trabaja en varios aspectos de la comunicación en el protocolo IOTA 2.0. Esto incluye temas como la verificación del rendimiento de la red, las optimizaciones y las marcas de tiempo (timestamps). Como siempre, lee a continuación para conocer todos los detalles.
Implementación de DevNet. Desde la última actualización, el equipo ha publicado las versiones 0.7.4 y 0.7.5, que mejoran la estabilidad general del software, corrigen varios errores y desplazan el componente del programador hacia el final del flujo de datos. Esto permite un mejor proceso de sincronización, así como la simplificación del flujo general. Todavía hay algunos problemas relacionados con la asignación de marcadores que dificultan que algunos nuevos participantes puedan sincronizar con éxito sus nodos. Por este motivo, el equipo está trabajando en una nueva función que permitirá a los nodos de la comunidad descargar una base de datos reciente para poder sincronizarse de forma más rápida y fiable.
La implementación de las nuevas mejoras en el consenso está avanzando a un ritmo muy rápido, ya que el equipo se encuentra en la fase de pruebas. En concreto, ya se han añadido a la base de código una interfaz de consenso modular, el mecanismo On Tangle Voting (OTV), un nuevo tipo de parent (es decir, el conmutador Like) y una validación sintáctica de mensajes refactorizada, pero aún no se han fusionado. La cantidad de peso de aprobación construida en cada mensaje puede ahora traducirse en grados de finalidad (GoF): bajo, medio y alto. También se ha añadido una colección de nuevas métricas específicamente diseñadas para analizar la OTV y se ha desarrollado una nueva página de resumen de conflictos para el tablero local del nodo, de modo que cada operador de nodo pueda comprobar en tiempo real el comportamiento de su nodo mientras vota los conflictos.
Se han integrado en el flujo otros componentes del protocolo, entre ellos el fijador de rate, componente central del control de la congestión. Por último, se está realizando un esfuerzo considerable para mejorar la calidad del código. El uso de la inyección de dependencias en la inicialización de los plugins, la unificación de los parámetros, una serialización más genérica y una biblioteca de deserialización son sólo algunos ejemplos.
La documentación oficial ha sido migrada a docusaurus y puedes consultarla aquí.
Redes. El enfoque actual del equipo es analizar el rendimiento del algoritmo de control de congestión de IOTA (ICCA) y en las mejoras de la experiencia del usuario. Más concretamente, ICCA se ha diseñado con el objetivo de minimizar el retraso máximo, que es el tiempo necesario para entregar un mensaje a todos los nodos. Esto significa que los umbrales utilizados por ICCA (blacklisting, self back-off y minimum mana) actúan como reguladores de dicho retardo máximo. Para entenderlo, piense en un búfer de tamaño infinito, en el que los retrasos podrían ser infinitos; si el mismo búfer tiene un tamaño pequeño, un nuevo mensaje sólo tiene que esperar hasta que todos los (pocos) mensajes existentes estén programados. Por esta razón, estamos trabajando en el análisis de los distintos parámetros para averiguar cómo afectan al rendimiento real de ICCA, y cómo se pueden optimizar estos parámetros. Como resultado preliminar, hemos descubierto que la forma en que se asigna el déficit y el tope tiene un fuerte impacto en el rendimiento.
Paralelamente, estamos trabajando en el equilibrio de la carga entre los nodos tratando de responder a la siguiente pregunta: supongamos que un usuario (wallet o nodo) tiene un nuevo mensaje que emitir, ¿qué nodo debe elegirse para que este mensaje se cree en poco tiempo? Recordemos que cada nodo tiene un módulo de creación de mensajes y que el ritmo de adición de nuevos mensajes en el planificador está regulado por el algoritmo rate setter; por lo tanto, este proyecto trata de asignar nuevos mensajes a los nodos que están menos ocupados en un momento dado. Hemos formulado este problema como un problema de optimización y estamos probando algunas políticas propuestas basadas en la ocupación del creador de mensajes o en el retraso por nodo.
En el contexto de las funciones de retardo verificables (VDF), estamos optimizando el tiempo de cálculo y evaluación de nuestro algoritmo propuesto para la prevención del spam utilizando técnicas de multi exponenciación que hemos estudiado previamente. Hemos descubierto que uno de los aspectos más costosos (en términos de tiempo) de la verificación de las VDF es encontrar el número mínimo para que el hash de este número más un mensaje de entrada sea primo. Actualmente nos centramos en acelerar esta función.
Sharding. En las últimas semanas, el grupo de fragmentación de datos se ha centrado en varios aspectos: Principalmente, discusiones sobre las cadenas ISCP y la motivación de la fragmentación de datos, simulaciones sobre el modelo y la formalización de nuestros hallazgos, definiciones y discusiones.
Los miembros del grupo de fragmentación de datos realizaron dos simulaciones diferentes. La primera fue un modelo basado en el usuario, en el que consideramos que diferentes usuarios con diferentes requisitos de MPS (mensajes por segundo) se unían a la red y se asignaban de forma óptima. A partir de este modelo, comprobamos datos interesantes como la asignación de maná por shard, los MPS esperados por cuota de maná y los MPS por capa. El segundo modelo es un modelo basado en fragmentos, en el que nos centramos principalmente en la sobrecarga causada por la comunicación entre los fragmentos. Ambas simulaciones nos dieron resultados esperados o positivos. Los resultados se formalizarán y contribuirán a nuestro trabajo en curso.
Consenso. El Grupo de Consenso se ha formado recientemente para abordar todo lo relacionado con los cambios de consenso. Como tal, es un grupo interdisciplinario que actualmente se centra principalmente en la implementación y prueba de los cambios modulares del consenso y del Like switch, la simulación de la OTV, la redacción de un artículo sobre la OTV y la discusión de nuevas ideas para simplificar y mejorar el protocolo.
Basándose en el simulador del multiverso, el equipo está construyendo un marco de simulación general que nos ayudará a comprender en profundidad el mecanismo de consenso, sus ventajas y limitaciones. También servirá como campo de batalla para varios ataques a la OTV pura y a la OTV con FPCS como mecanismo de ruptura de meta estabilidad y, potencialmente, a otros. Actualmente, el marco de simulación se encuentra en un estado muy inicial y no se pueden obtener resultados significativos. En un futuro próximo, el marco nos ayudará a tomar decisiones informadas sobre la configuración de los parámetros (por ejemplo, ¿cuándo debe activarse el FPCS?), a tener una idea de los tiempos de confirmación con diferentes distribuciones de maná y tasas de declaración, y a proporcionar contenido para nuestros artículos sobre OTV.
El equipo también está estudiando nuevas simplificaciones del protocolo. Por ejemplo, con el conmutador like, ahora tenemos una clara separación entre el peso de aprobación (AW) para las ramas y los marcadores. Al utilizar una única secuencia de marcadores para aproximar el AW, podemos separar estos componentes, acelerar el cálculo del AW y hacer las cosas más fáciles de entender. Además, estamos discutiendo la noción de cMana activa (cMana que se tiene en cuenta para los conflictos/mensajes actuales) y la terminación del consenso, ya que seguir la rama más pesada es un esquema de votación interminable, al igual que la regla de la cadena más larga en los blockchains.
Capa de comunicación. El grupo de la capa de comunicación es otro equipo recién formado. Se centra en temas de comunicación y sincronización que surgieron durante la investigación en la red, así como en el grupo GoShimmer.
Este mes, el equipo ha realizado pruebas y evaluaciones comparativas de los componentes scheduler y rate setter añadidos recientemente a la DevNet. En este caso, se establecieron varias configuraciones de red virtual para verificar que la implementación existente se ajusta a los resultados esperados de la investigación de redes. Otro aspecto de estas pruebas era identificar posibles cuellos de botella en el rendimiento en determinados escenarios de casos límite.
En un plano más teórico, hemos evaluado diferentes métodos de sellado de tiempo. Las marcas de tiempo permiten comparar y ordenar directamente los mensajes, lo que resulta útil para diversos componentes. Estos diferentes métodos deben ser evaluados en cuanto a su precisión, fiabilidad y complejidad computacional.
Post original: IOTA Research Status Update September 2021
