Tras el entusiasmo por el lanzamiento de la DevNet a principios de junio, nuestro equipo ha vuelto a su ritmo normal, y ha continuado trabajando en la finalización de las especificaciones, en la optimización de ciertos aspectos del protocolo, como el algoritmo de control de la congestión, y en la reanudación de nuestro trabajo sobre el Data Sharding (Sharding de datos)
Sin embargo, lo que es diferente es que tenemos el beneficio de los datos que se van recogiendo de la DevNet para informar nuestro trabajo. Esperamos que las siguientes actualizaciones sean informativas para ustedes, ya que explicamos exactamente cómo se están utilizando esos datos, y cuáles serán los próximos pasos para el Departamento de Investigación de IOTA.
Implementación de DevNet. Estamos reuniendo datos valiosos de la mayoría de los nodos de la DevNet. Con esos datos, hemos podido descubrir algunos errores en nuestro stack de red que provocan que algunos mensajes se propaguen por la red con un retraso mayor del esperado.
Independientemente de haber solucionado este problema con la v0.7.3, este problema puso de manifiesto un inconveniente relacionado con el FCoB, el protocolo por el que los nodos establecen su opinión inicial sobre cada transacción. Más concretamente, debido a la implementación actual de FCoB y FPC, puede ocurrir que dos (o más) conflictos sean rechazados. Sin un ganador claro, los nuevos nodos que se unen a la red o los nodos existentes que están solidificando los mensajes que faltan podrían recibir sólo uno de ellos, y por lo tanto tratar de adjuntar sus nuevos mensajes en un lado de la Tangle que no obtendrá suficiente peso de aprobación para ser confirmado alguna vez.
Aunque podríamos mejorar FCoB añadiendo redundancia de comunicación para los conflictos rechazados, nos gustaría aprovechar esta oportunidad para estudiar una variante de FPC denominada «FPC on a set», que siempre elegiría un ganador dentro de un conjunto de conflictos. Esto también nos permitiría empezar a experimentar con un mecanismo más parecido a la Votación en la Tangle (On Tangle Voting – OTV) combinada con FPC en un conjunto como su interruptor de meta estabilidad.
También se están mejorando otros aspectos de la implementación. Por ejemplo, estamos trasladando el scheduler (el núcleo del control de la congestión) después del booker. Esto da lugar a un comportamiento más natural durante la sincronización, ya que el nodo no necesita saltarse explícitamente el scheduler para ponerse al día con la red.
Además, el equipo está reelaborando el mecanismo de solidificación para que un mensaje se considere sólido si tanto sus padres como su carga útil (es decir, su transacción) lo son. Esto nos permitirá eliminar la costosa comprobación del cono pasado.
Actualización del protocolo. Con la implementación de DevNet llegó la primera ola de comentarios sobre los muchos componentes que formarán nuestra red IOTA 2.0. Aunque la mayoría de los componentes mostraron resultados prometedores, también nos dimos cuenta de que algunos de ellos requerirían cambios para estar a la altura de los estándares que esperamos de la futura red. Por suerte, la naturaleza modular de IOTA 2.0 nos permite desarrollar componentes con los que estamos satisfechos y, al mismo tiempo, investigar y mejorar los que requieren atención.
Todo el departamento de investigación se reunió para determinar qué componentes podrían beneficiarse de una mayor investigación y decidir cómo lo organizaremos de forma que no entorpezca los demás proyectos en curso. Las principales mejoras en las que trabajaremos son
- Aumentar la modularidad del algoritmo de consenso introduciendo la «Función de Selección de Conflictos», que generaliza todos los mecanismos de consenso que pueden ser implementados en IOTA 2.0. Actualizar el FPC al «On Tangle FPC on a set» utilizando las funciones de selección de conflictos.
- Eliminar la necesidad de votar sobre timestamps y clasificar los mensajes como elegibles para la selección de tips mediante la introducción del mecanismo de «Inclusion Score».
- Eliminar la necesidad de aprobaciones débiles y estudiar cómo se comporta el protocolo bajo el spam de conflictos.
Tras definir estos temas de investigación, nos dividimos en dos grupos para abordarlos. El objetivo principal de esta investigación es llegar a resultados que puedan incluirse en las especificaciones. Esperamos tener algunos resultados que compartir para la próxima actualización de la investigación.
Especificaciones. Después de un extenso trabajo para conseguir que el primer lote de especificaciones esté listo para ser compartido con la comunidad, el equipo hizo un estudio de nuestra investigación actual para decidir los próximos objetivos. Para ello fue crucial el reciente lanzamiento de la DevNet. Las nuevas tareas que se decidieron fueron: actualizar las especificaciones de acuerdo con los recientes resultados de la DevNet; proceder al proceso de normalización de los archivos que no se verán afectados por los resultados de la DevNet; y trabajar en el segundo lote de especificaciones para tener todos los archivos escritos.
Dado que en los próximos dos meses el departamento de investigación se centrará principalmente en la investigación, el trabajo de especificación seguirá naturalmente. A medida que la investigación se complete, añadiremos los resultados pertinentes a las especificaciones.
Networking. La investigación del equipo de redes se centra actualmente en la implementación del Algoritmo de Control de Congestión en el DevNet y su integración con el resto del protocolo.
Como resultado, estamos estudiando un conjunto de optimizaciones que nos permiten simplificar el código a la vez que mejorar el rendimiento. El cambio más importante en comparación con la idea original es el hecho de que los mensajes pueden bookearse inmediatamente después de ser sólidos, por lo que el programador sólo determina qué mensajes se gossipean y se añaden a la lista de tips. Esto permite una sincronización mucho más rápida para los nodos desincronizados, que pueden recuperar los mensajes antiguos a un ritmo más rápido que el del scheduler. Por otro lado, trasladar el scheduler al final del flujo de datos abre la posibilidad de ataques, que se están estudiando actualmente. Podemos mitigar los posibles ataques mediante la introducción de la Inclusion Score, una métrica que mide la probabilidad de que un mensaje se convierta en parte permanente de la Tangle en el futuro.
Como segundo tema de investigación, actualmente estamos investigando un modelo para mejorar la calidad de la experiencia de los usuarios. En concreto, el rates setteler determina el rendimiento de un usuario determinado, en función del maná access. Preguntas como «¿cuántos mensajes puedo enviar, como nodo, con X maná?» o «¿cuándo puedo emitir el siguiente mensaje?» serán respondidas por este modelo.
Por último, nos enorgullece anunciar que nuestro artículo, escrito en colaboración con el profesor Bob Shorten y su equipo del Imperial College de Londres, «Access Control for Distributed Ledgers in the Internet of Things: A Networking Approach«, ha sido aceptado para su publicación en la revista IEEE Internet of Things Journal (factor de impacto 9,936), una de las mejores revistas de informática.
Sharding. Durante los dos últimos meses, todo el departamento de investigación se ha centrado en dos cosas: El desarrollo de DevNet y la publicación de las especificaciones. Por lo tanto, el grupo de sharding entró, junto con otros grupos, en un paréntesis para permitir que nuestra fuerza de trabajo se asignara adecuadamente a esas tareas. Con la publicación de DevNet y la primera versión de las especificaciones completadas, el departamento de investigación ha vuelto a trabajar en sus soluciones de sharding. La primera propuesta, un whitepaper sobre la fragmentación de datos, está ahora mismo en producción, y esperamos que se publique pronto para compartir nuestras ideas con la comunidad.
Esperamos que el desarrollo del Data Sharding mejore significativamente el rendimiento de la red para los mensajes de datos, y su implementación puede paralelizarse con el futuro Fluid Sharding.
Post original: IOTA Research Status Update July 2021
