Este mes ha sido bastante ajetreado para nosotros, ya que entramos en la recta final de nuestro camino hacia la entrega de Nectar, la primera implementación completa de nuestra red totalmente descentralizada y sin Coordinator, que estará lista en unas semanas. Todos nuestros grupos han hecho excelentes progresos en la conversión de los resultados de nuestra investigación en componentes utilizables, un objetivo en el que estamos orgullosos de participar.
Algunos logros importantes de este mes han impulsado el progreso hacia el lanzamiento de la etapa Nectar de nuestra red sin Coordinador, incluyendo: la implementación de mana en la red de prueba Pollen, que nos permite estudiar los ataques en condiciones de red realistas; la casi finalización de nuestras especificaciones formales, que nos permite comunicar mejor el protocolo a los socios y otras partes interesadas, así como proporcionar el trabajo de base para la estandarización del protocolo IOTA; y la finalización de nuestro documento de autopeering, que es una validación de uno de nuestros componentes de red. A continuación, nuestros grupos de investigación nos informan de estos y otros avances del mes pasado:
Implementación de la Red de Pruebas de Pollen. El equipo desplegó varias iteraciones de la Pollen testnet, comenzando con la v0.5.0 que introdujo mana (el sistema de reputación), así como el control de congestión (que regula el acceso al Tangle), para probar su primera iteración y estudiar su distribución en dicho entorno. Con ese lanzamiento añadimos una serie de nuevas APIs, una nueva sección de mana en el dashboard local, el dashboard de Pollen Analyzer así como en el dashboard de Grafana. Tanto la GUI como los monederos CLI han sido actualizados para permitir al usuario definir la identidad del nodo como receptor de la prenda de mana de acceso y consenso de una transacción.
También hemos refactorizado el componente del Gestor de Consenso para que sea agnóstico con respecto a los mecanismos de consenso reales implementados. De este modo, GoShimmer puede verse no sólo como el prototipo de IOTA 2.0, sino también como un marco flexible para cualquier DLT basada en DAG. De hecho, cualquier mecanismo de consenso, como On Tangle Voting, BFT, basado en un líder, puede ser conectado fácilmente cambiando unas pocas líneas en la inicialización de Tangle. Con las versiones posteriores, empezamos a integrar los primeros componentes con mana, a saber, el Consenso Probabilístico Rápido (protocolo FPC) y el autopeering. Hasta ahora, nuestro módulo de consenso ha tratado las opiniones de cada nodo por igual. Sin embargo, esto no ofrece ninguna protección contra los ataques Sybil, en los que los adversarios manejan cientos o incluso miles de nodos, para perturbar el consenso. Con la integración de Mana, los nodos forman ahora su quórum seleccionando los nodos que serán consultados proporcionalmente a su mana.
Para evitar/limitar los ataques Sybil, el autopeering hace uso de un proceso de selección llamado mana rank, que selecciona un subconjunto de todos los nodos conocidos en función de su similitud de mana. Esto significa que los nodos con mana similar tendrán más probabilidades de convertirse en vecinos. Ya podemos ver su impacto en la topología de la red Pollen:
Los nodos de la parte izquierda del gráfico de la red tienen más Mana de consenso, mientras que en la derecha podemos ver nodos con menos o cero mana. Con este experimento buscamos encontrar los parámetros adecuados para encontrar un buen equilibrio entre la protección de ataques Sybil y la conectividad de la red. Actualmente, tenemos una red con más de 200 nodos y un diámetro de red de 5.
En las próximas semanas, el equipo se centrará en integrar mana con el resto de los módulos: Control de congestión, Finality (peso de aprobación), Reorg y dRNG. Como últimos hitos antes de Nectar, introduciremos Snapshots y Timestamp voting. Una vez terminados, Nectar estará listo para su lanzamiento al público.
Especificaciones. El progreso de las especificaciones ha sido constante, y ahora trabajamos con el objetivo de tener los componentes principales listos alrededor del momento en que actualicemos a Nectar. Todo el proceso está siendo completamente documentado y estandarizado, por lo que podemos controlar mejor cómo va el progreso, así como saber qué módulos necesitan más apoyo.
Hablemos un poco de la estructura del proyecto. Ahora mismo los archivos están divididos en 7 secciones relacionadas con su papel en el proyecto o en la red: Archivos de Control, Archivos de Estructura, Capa de Red, Capa de Comunicación, Aplicación de Transferencia de Valor, Aplicación de Consenso y Gestión de Historial.
En Archivos de Control se trata la información que se refiere a cada archivo, definiendo las pautas de estandarización y organización. Aquí cabe destacar el índice de parámetros y archivos de terminología, que permitirá obtener esta información a través de los archivos en un único lugar de referencia. Los Archivos de Estructura incluyen información esencial sobre los elementos de datos que forman parte del Tangle. Aquí se encuentra el nuevo Message Layout, los principales Payload Layouts así como el flujo de datos por el que pasa un mensaje para ser procesado por un nodo.
La Capa de Red trata de la comunicación entre nodos, incluyendo la metodología de bootstrapping y todos los módulos de Autopeering. La capa de comunicación, probablemente nuestra sección más extensa, muestra el protocolo para que un nodo mantenga su Tangle. Esto incluye la mayoría de los módulos sobre el propio Tangle, como las marcas de tiempo, el algoritmo de selección de tips, la solidificación, el control de velocidad y congestión y los marcadores. La aplicación de transferencia de valores define las directivas para todo lo relacionado con el Ledger, como la sistemática UTXO, los cálculos del estado del Ledger y todas las directivas sobre el mana.
Aplicaciones de consenso, como su nombre indica, es la especificación sobre todo lo relacionado con el consenso. Aquí se encontrará toda la información sobre el consenso probabilístico rápido (FPC), el generador de números aleatorios descentralizado (dRNG), la reorganización de la percepción del nodo y la finalidad. Por último, la gestión de la historia describirá en detalle el proceso de toma de instantáneas.
Esto muestra un poco la naturaleza extensa del proyecto. De nuestro lote inicial de 20 archivos, 7 ya han pasado por la revisión y muchos otros están a punto de completarse. Esperamos un gran avance durante el mes de abril y esperamos compartirlo pronto con la comunidad.
Grupo de estudio de la Testnet de Pollen. Durante el último mes hemos terminado de redactar y presentado nuestro primer artículo de investigación sobre nuestro autopeering basado en sal. Este documento discute varias de nuestras decisiones de diseño y presenta un primer tratamiento cuantitativo de algunos requisitos sobre la topología de la red. Al tener el mana integrado en el autopeering en Pollen continuamos nuestra investigación sobre este módulo de coordinacion.
También analizamos la distribución y la dinámica del maná de acceso y del maná de consenso en la red de prueba actual. Un resultado particular de este primer análisis es un ajuste del «parámetro de suavización» del maná de acceso; un cambio en el maná de acceso se hace efectivo en un tiempo mucho más corto que en nuestra primera propuesta.
Sharding. Seguimos avanzando en nuestro whitepaper sobre la fragmentación de datos o sharding. En el mes anterior, hicimos una lluvia de ideas sobre vectores de ataque adicionales. Aunque hemos comprendido mejor los vectores de ataque anteriores, no hemos encontrado ninguna nueva vulnerabilidad fundamental. Por lo tanto, nuestra propuesta de fragmentación de datos parece ser robusta contra una variedad de comportamientos maliciosos.
También analizamos otras formas de modelar el crecimiento de los datos de la Tangle, para intentar estimar mejor el rendimiento potencial del sistema. Empezamos a trabajar en la creación de simuladores para modelar la creación de child Tangles, y también para modelar las interacciones entre la Tangle parent y child. Estas simulaciones se utilizarán para verificar nuestra comprensión y nuestras suposiciones sobre el comportamiento del sistema.
Con muchas de las cuestiones teóricas iniciales resueltas, ahora sólo nos queda terminar el whitepaper. El mayor impedimento en este momento es encontrar las horas de trabajo para dedicarlas a la redacción, ya que todos nuestros investigadores están también involucrados en la finalización de Nectar.
Post original: IOTA Research Status Update April 2021
