22 August 2026
23 August 2026
24 August 2026
Victor 🇲🇽 🇲🇽text not yet in the index
Pregunta, tiene rato que me desconecte de Sora, veo que al cambiar mis pswap a xor en la wallet de fearless su valor es 0, aún no actualizan el Xor en fearless?
D RPor lo que estoy leyendo, todo mi dinero invertido en XOR lo he perdido porque vele 0 ? Ó sea lo he perdido todo?
Ya se te respondió en Febrero, hubo varias redenominaciones.
Omar🦴Pregunta, tiene rato que me desconecte de Sora, veo que al cambiar mis pswap a xor en la wallet de fearless su valor es 0, aún no actualizan el Xor en fearless?
Hace poco hubo un artículo donde estaban trabajando en Fearless, al parecer pronto habrá actualización
25 August 2026
Фотография
click to show
click to show
🛠 ACTUALIZACIÓN DE DESARROLLO DE Hyperledger IROHA 3 / SORA NEXUS
15–22 de agosto de 2026
El trabajo de esta semana se centró principalmente en la fiabilidad, la recuperación, la privacidad y la implementación segura.
En lugar de añadir una gran función visible para el usuario, el equipo reforzó las bases que permiten a Iroha 3 seguir funcionando correctamente cuando los validadores se reinician, los mensajes llegan tarde, es necesario recuperar el almacenamiento, se interrumpen los pagos sin conexión o se prepara una nueva versión del software para su implementación.
A continuación, se detallan los cambios y su importancia.
⚙️ 1. CONSENSO MÁS SEGURO Y RECUPERACIÓN DE VALIDADORES
Sumeragi es el protocolo de consenso de Iroha: el proceso mediante el cual los validadores acuerdan el siguiente bloque y lo finalizan.
Esta semana, el equipo reforzó la forma en que Sumeragi gestiona las condiciones de red difíciles:
• Se impide que los mensajes de una ronda de consenso anterior interfieran con el trabajo más reciente.
• Los validadores que se recuperan tras un reinicio pueden obtener el cuerpo de un bloque faltante y verificarlo antes de continuar.
• Los bloques pendientes ahora conservan información más clara sobre su progreso hacia la finalización.
• El comportamiento de los tiempos de espera se limitó para evitar retrasos incontrolados causados por fallos repetidos.
• Las pruebas con cuatro validadores abarcaron reinicios, uniones tardías, pares desconectados, mensajes retrasados, propuestas abandonadas y la recuperación por parte de un nuevo líder de validadores.
Por qué es importante: un libro mayor distribuido debe funcionar más allá de las condiciones ideales. Cuando las máquinas se reinician o las redes se vuelven inestables, los validadores deben alcanzar el mismo resultado correcto o detenerse de forma segura. Nunca deben finalizar historiales conflictivos porque un mensaje antiguo llegó en el momento incorrecto.
💾 2. ALMACENAMIENTO, INSTANTÁNEAS Y
44 · AXT coordina los intercambios entre estos espacios de datos. Por ejemplo, un activo podría transferirse en un espacio de datos mientras que otro se transfiere en un espacio de datos diferente. El intercambio debe ser atómico: o todas las partes autorizadas se completan con éxito, o el intercambio completo falla.
El trabajo de esta semana reforzó la seguridad de AXT:
• Los presupuestos de uso y los límites de velocidad ahora se almacenan de forma persistente y se conservan tras los reinicios.
• Eliminar registros de reproducción caducados ya no borra la información contable permanente.
• Se rechaza la reutilización de un número de subtransacción antiguo, incluso después de haber eliminado los registros temporales.
• Volver a registrar un activo con el mismo identificador visible no puede reactivar los permisos creados para una versión anterior de dicho activo.
• Los cambios locales de la transacción permanecen aislados hasta que se acepta la operación completa.
• Los validadores pueden cargar solo la información presupuestaria exacta afectada por una transacción, en lugar de copiar todo el estado global.
Importancia: Un atacante no debe poder restablecer un límite de gasto reiniciando un nodo, esperando a que caduque un registro temporal o recreando un activo con el mismo nombre. Los intercambios entre espacios de datos requieren las mismas protecciones persistentes que los saldos contables habituales.
📴 4. FIABILIDAD DE LAS TRANSACCIONES SIN CONEXIÓN Y LAS CARTERAS MÓVILES
Las transacciones sin conexión permiten que dos dispositivos transfieran valor incluso cuando uno o ambos están desconectados de la red. El pago resultante puede sincronizarse, canjearse y liquidarse posteriormente en el libro mayor.
Los avances de esta semana incluyen:
• Compatibilidad con Kotlin para solicitudes de canje sin conexión, estado de liquidación y pruebas criptográficas de canje.
• Conjuntos de pruebas compartidos para verificar que los diferentes SDK codifican e interpret
37 · 🧠 6. EJECUCIÓN MÁS DETERMINISTA DE CONTRATOS INTELIGENTES
La Máquina Virtual de Iroha (IVM) es el entorno de ejecución de los contratos inteligentes de Iroha.
Las mejoras implementadas esta semana incluyeron:
• Al cargar un nuevo programa, se reinicia el perfil de ejecución completo, evitando así que el estado de un programa anterior se filtre al siguiente.
• Se unificó el comportamiento aritmético y de los registros en diferentes configuraciones de compilación.
• Las instrucciones indefinidas, mal formadas o no canónicas se rechazan con mayor antelación.
• Se corrigieron los casos límite de asignación de memoria.
• Se reforzaron las transcripciones de prueba y el manejo de claves de verificación.
• Se actualizaron los modelos de contratos inteligentes, espacio de datos y activos, junto con sus representaciones en el SDK.
Importancia: cada validador debe obtener exactamente el mismo resultado del mismo contrato. El comportamiento no debe depender del modo de compilación utilizado, del programa ejecutado previamente ni de cómo una entrada mal formada llegó a la máquina virtual.
🚪 7. API, ENRUTAMIENTO E INTEGRACIÓN DE APLICACIONES MÁS SEGUROS
Torii es la puerta de enlace API de Iroha. Carteras, exchanges, exploradores y aplicaciones institucionales la utilizan para enviar transacciones, consultar el libro mayor y suscribirse a eventos.
Esta semana se han implementado mejoras en:
• Manejo de errores de consulta.
• Registro y resolución de alias de cuenta.
• Enrutamiento entre canales y espacios de datos.
• Compatibilidad con SDK de JavaScript, Kotlin, Java, Python y Swift.
• Configuración y manejo de parámetros.
• Integración con Iroha Connect y herramientas para desarrolladores.
• Telemetría de gobernanza, incluyendo el estado de membresía de la gobernanza de red y el número exacto de miembros.
Importancia: la corrección del libro mayor no es suficiente si diferentes SDK construyen transacciones distintas o si las aplicaciones reciben resultados am
49 · Ссылка
click to show
click to show
Por qué es importante: el código determinista del libro mayor aún puede verse comprometido mediante una dependencia de compilación maliciosa. El código fuente, el archivo de bloqueo de dependencias y la compilación resultante deben permanecer dentro del perímetro de seguridad.
📌 RESUMEN
El principal logro de esta semana no fue una sola característica destacada, sino una reducción significativa en la cantidad de casos donde podría persistir un estado ambiguo:
• El trabajo de consenso antiguo no puede controlar silenciosamente una ronda más reciente.
• Reiniciar no puede borrar los presupuestos de intercambio permanentes.
• Recrear un activo no puede reactivar un permiso obsoleto.
• Los pagos fuera de línea interrumpidos pueden recuperarse a partir de evidencia duradera.
• Los componentes de prueba no pueden mezclarse en diferentes contextos.
• Una compilación candidata no puede promoverse utilizando validadores o configuraciones incompatibles.
La dirección es clara: las transiciones de estado importantes deben ser deterministas, autenticadas, reproducibles y recuperables. Cuando falta la evidencia requerida, el sistema debe detenerse de forma segura en lugar de adivinar.
Esto representa un progreso significativo hacia la preparación para el lanzamiento de Iroha 3 y SORA Nexus.
🔗 https://github.com/hyperledger-iroha/iroha/tree/optimizations
64 · 26 August 2026
27 August 2026