XI'AN · HYPERSCALE FOR RADIX

Hyperscale Weekly

Semana #14 · 10–16 ago 2026 · Milestone 2 · Radix Engine · Semana 2 · ~mes 1 de 5
Divide el trabajo, no el mundo
PROGRESO DEL HITO 29%

Anteriormente: flightofthefox había unificado el codebase en un solo motor sin dependencias externas de Radix y había comenzado a conectar el sistema de comisiones y el settlement entre shards a la nueva base.

Esta fue una semana grande y de mucho alcance. flightofthefox reestructuró la forma en que las transacciones demuestran que tienen permiso para actuar, puso en funcionamiento las firmas post-cuánticas, y detalló con precisión qué sucede con las transacciones entre shards cuando un shard termina. El trabajo de paridad de características del Radix Engine del Milestone 2 está alcanzando su ritmo.

206
-16% vs semana pasada
commits
+21k 5.5k
-17% vs semana pasada
líneas cambiadas
427
archivos tocados
1
días seguidos con commits
Commits / día
L
M
M
J
V
S
D
pico 60/día · 6/7 días activos
Impulso
Líneas cambiadas / semana
últimas 8 semanas
89% Rust8% Config2% Docs
Lo que construyó flightofthefox

Los badges reemplazan a las firmas

El modelo de autorización de la VM fue reconstruido: ahora tener un badge otorga permiso donde antes se usaba una firma directa, y las cuentas generan un proof que pueden presentar después. Esto lleva el control de acceso del Radix Engine a la VM shardeada.

→ ver “The Journey” en hyperscale.rs

Criptografía post-cuántica en vivo

Las firmas post-cuánticas ML-DSA-65 y secp256k1 ahora están conectadas a través del camino de transacciones, y el sistema de direcciones fue reconstruido con derivaciones fijadas por hash de protocolo. flightofthefox señaló paridad con los esfuerzos post-cuánticos de la industria.

→ ver “The System” en hyperscale.rs

El testamento del shard muerto, completamente detallado

Decenas de commits endurecieron las reglas para las transacciones entre shards atrapadas cuando un shard termina — ventanas de evidencia medidas en beacon epochs, ventanas de servicio de settled-sets, y registros de frontera que reconstruyen cuentas que un replay nunca alcanzó.

→ ver “The Will” en hyperscale.rs
En resumen
Cambio destacado
El modelo de autorización ahora usa badges y proofs en lugar de firmas directas — un cambio fundamental que lleva el control de acceso del Radix Engine a la VM shardeada.
Lo que viene
Probablemente lo siguiente: continuar portando los tipos de recursos del Radix Engine como non-fungible tokens y colecciones, y conectar el sistema de comisiones más profundamente en el camino de autorización ahora consciente de badges.
Escuchado en el chat

El ánimo: El chat estuvo activo con conversaciones sobre auditoría de seguridad con IA y si la criptografía de campos binarios podría cambiar las elecciones de funciones hash, con flightofthefox tranquilizando a todos de que cambiar un hash es trivial y que el red-teaming debería

será un ejercicio muy divertido en el primer testnet, que todos apunten sus modelos frontera favoritos al código y traten de hackear su camino hasta ser los reyes de la colina 😅
— flightofthefox, en el Telegram de la comunidad
El concepto de la semana
The JourneyUn pago cruza un mundo shardeado
El modelo de autorización es el corazón del objetivo de paridad de características Babylon del Milestone 2 — los badges, los proofs y las reglas almacenadas son cómo el Radix Engine controla quién puede hacer qué, y esta semana ese sistema tomó forma sobre la base shardeada.
hyperscale.rs/journey
Jerga, descifrada
ML-DSA-65Un estándar de firma post-cuántica aprobado por NIST, diseñado para resistir futuras computadoras cuánticas.
BadgeUna credencial digital almacenada on-chain que otorga permiso para realizar operaciones, reemplazando la necesidad de una firma directa cada vez.
SecurifyActualizar una cuenta para que reglas lógicas almacenadas gobiernen su autorización en lugar de una simple verificación de firma.
Dónde aterrizó el trabajo
revisión del sistema de direcciones y esquema de firmas
settlement del straddler y endurecimiento del handoff terminal
vm/manifest-builder · The Journey
construcción de transacciones y conexión de autorización
Referencia — mapa de conceptos, hoja de ruta y enlaces
El panorama completo
The System
The whole sharded design at a glance.
The Journey
One transaction's trip through the network.
The Clock
Consensus-attested time across independent shards.
The Census
The leaderless beacon of validators, stake and shards.
The Overlap
Why two conflicting blocks can never both commit.
The Generals
All-or-nothing cross-shard commits, computed not voted.
The Archive
Every published byte is preserved or provably expired.
The Library
All state in one merkle tree; a shard is a subtree.
The Will
How in-flight transactions settle when a shard dies.
The Lottery
Random, ever-moving committees; proven cheats are jailed.
The Triage
Under overload, urgent traffic never waits for bulk.
The Governor
Validator entry is re-priced every epoch, like a market.
The Crash Lab
The simulator that replays any failure byte-for-byte.
The Proof
Proving safety with maths, not just tests.
The Asterisks
Every design's trade-offs — including Hyperscale's own.
El camino a mainnet
✓ M1
Adaptive Sharding
~4 mo
M2
Radix Engine
~5 mo
M3
Gateway & API
~3 mo
M4
Validator GUI
~3 mo
M5
Migration
~3 mo
M6
Live support
12 mo
Ahora: Milestone 2 · Radix Engine — Semana 2 · ~mes 1 de 5 · 9%. Desde el día uno: 3,174 commits — un solo desarrollador, totalmente en público.
Enlaces
Escrito por IA a partir de commits públicos, el chat de la comunidad y hyperscale.rs — puede contener errores. · generado 2026-08-17
Hyperscale Weekly — Semana #14 · 10–16 ago 2026