Puntos clave de la noticia:
- IOTA llevó el consenso Starfish a mainnet mediante v1.21.1 y la versión de protocolo 24, apuntando al estrés real de red.
- Starfish cambia la recuperación pull de Mysticeti por movimiento de datos push-based, reduciendo solicitudes pull en cerca de un orden de magnitud.
- El diseño separa metadata y payloads, usa fragmentos Reed-Solomon para disponibilidad y acepta una latencia ordinaria algo mayor para mejorar casos bajo presión.
IOTA llevó el consenso Starfish a mainnet mediante v1.21.1 y la versión de protocolo 24, introduciendo un diseño push-based pensado para mantener alineados a los validadores cuando las redes reales se vuelven complejas. La actualización apunta a condiciones en las que los nodos se ralentizan, los mensajes llegan tarde o algunos participantes actúan de forma incorrecta. La sincronización pasa a formar parte del consenso, no a ser una tarea secundaria, porque un validador no puede votar sobre bloques que no ha visto ni certificar datos de transacciones que no puede reconstruir. El resultado es un giro técnico con una pregunta práctica: ¿puede un movimiento de datos más rápido reducir el estrés antes de que los bloques faltantes se conviertan en cuellos de botella para validadores y usuarios?
Starfish envía datos antes de que los validadores los pidan
Starfish se apoya en el DAG de IOTA, donde los bloques hacen referencia a bloques anteriores y muestran lo que los validadores ya observaron. Bajo el modelo anterior, Mysticeti, los datos faltantes se gestionaban más mediante un comportamiento pull: un validador detectaba una brecha, pedía a sus pares el bloque ausente y esperaba. La recuperación pull-based ahorraba ancho de banda en condiciones tranquilas, pero bajo presión cada elemento faltante creaba otra solicitud, otro retraso y otro paso de recuperación. Starfish invierte ese flujo al empujar información útil antes de que otros la soliciten, ayudando a que los nodos rezagados reciban datos probablemente necesarios antes de que el historial faltante llegue a la ruta crítica en producción durante periodos de alta actividad.
La arquitectura no se limita a inundar a los validadores con payloads completos de transacciones. Starfish separa metadata y payloads, permitiendo que los headers transporten referencias, votos, acuses de recibo, detalles de tiempo y compromisos de payload, mientras los datos de transacciones se mueven por separado. La codificación Reed-Solomon es la palanca de eficiencia, dividiendo el payload de un bloque en fragmentos asignados entre validadores. El payload puede reconstruirse con cualquier subconjunto suficiente de fragmentos válidos: f+1 fragmentos válidos pueden reconstruirlo, mientras 2f+1 acuses crean la condición de disponibilidad necesaria para la seguridad bizantina. Eso significa que no todos los validadores necesitan tener el payload completo al mismo tiempo en conjuntos distribuidos de validadores.
El trade-off es explícito. Starfish usa más ancho de banda que Mysticeti en condiciones probadas, pero envía comunicación estructurada antes para evitar recuperaciones costosas más adelante. El gráfico de solicitudes salientes de IOTA mostró que las peticiones pull cayeron alrededor de un orden de magnitud. La latencia se convierte en un intercambio por resiliencia, ya que añadir un paso de disponibilidad antes de la secuenciación puede elevar ligeramente la latencia ordinaria de las transacciones, mientras mejora los casos más lentos y reduce el tiempo dedicado a recuperar información faltante. La próxima prueba será operativa: si Starfish mantiene a IOTA alineada cuando el uso real, validadores imperfectos y presión de red converjan en mainnet sin sacrificar disponibilidad bajo condiciones adversas.
