XI'AN · HYPERSCALE FOR RADIX

Hyperscale Weekly

Semana #19 · 14–20 sept 2026 · Milestone 2 · Radix Engine · Semana 7 · desde agosto de 2026
Divide el trabajo, no el mundo
HITO ACTUAL
Milestone 2 · Radix Engine
Portando el Radix Engine para que Scrypto funcione entre shards
Semana 7 · desde agosto de 2026

Anteriormente: flightofthefox había reescrito el modelo de ejecución de la VM en torno a un único límite central — el cambio arquitectónico más grande del Hito 2 hasta ahora.

Continuando con la reescritura de la VM de la semana pasada, flightofthefox se enfocó en un gran avance de pricing y presupuesto de recursos — el sistema de comisiones que permite a la red cobrar a las transacciones exactamente lo que cuestan. Esta semana también vimos avances importantes en el modelo de recuperación de cuentas, la sincronización de bloques y la liquidación cross-shard. Una semana intensa y de mucho terreno cubierto.

408
+48% vs semana pasada
commits
+18k 9.1k
-21% vs semana pasada
líneas cambiadas
600
archivos tocados
20
días seguidos con commits
Commits / día
L
M
M
J
V
S
D
pico 120/día · 6/7 días activos
Impulso
Líneas cambiadas / semana
últimas 8 semanas
86% Rust14% Config
Lo que construyó flightofthefox

Transacciones con pricing según lo que tocan

flightofthefox conectó los costos de lectura por leaf, los cargos de framing por evento, y el pricing de scans en la ejecución — y movió la tabla de precios al beacon. Ahora las transacciones pagan exactamente por los recursos que consumen.

→ ver “The Governor” en hyperscale.rs

Un solo intent para componerlos a todos

El modelo de autorización se unificó en torno a un único intent recursivo — cada transacción es un intent que compone a otros, cada uno firmado y anulado de forma independiente, eliminando los tipos de routing dispersos.

→ ver “The Journey” en hyperscale.rs

Definidos los roles de recuperación de cuentas

Nuevos roles de la VM — uno primario, un rol de veto y un segundo factor — permiten a una cuenta congelarse, modificar guardianes o rotar al instante, todo gobernado por reglas on-chain en lugar de confianza.

→ ver “The System” en hyperscale.rs

Fronteras de sync y tips detenidos

La sincronización de bloques pasó a ser una máquina de estados proper, y la recuperación de halted-tip se reconstruyó para cosechar de timeouts verificados y revisar la pertenencia al committee antes de hacer commit.

→ ver “The Archive” en hyperscale.rs

La liquidación cross-shard se ajusta

Las ventanas de provision ahora se comparten en lugar de duplicarse, los bundles caídos satisfacen a quienes los piden, y las comisiones no juzgadas se liquidan contra lo que el pagador tiene — ajustando el camino de commit.

→ ver “The Generals” en hyperscale.rs

Shards que parten se retiran limpiamente

Las reglas de terminación de shards se endurecieron: los shards que parten se retiran cuando su ventana de evidencia se cierra, las cadenas terminadas dejan de componer ticks, y los pools expirados quedan acotados.

→ ver “The Will” en hyperscale.rs
También esta semana
  • Los wallets ahora pueden pedirle a un nodo un preview de solo lectura de lo que haría una transacción antes de enviarla.
  • Los shard splits ahora pueden dispararse automáticamente cuando un shard se acerca a sus límites de capacidad.
  • La latencia de red se estima a partir de la cadena commiteada, controlando los temporizadores de ronda y los timeouts de fetch.
  • Los timestamps de quórum ahora se toman como la mediana de las lecturas de reloj de los votantes, suavizando el reloj attestado.
  • Un emisor Byzantine simulado ahora puede reescribir notificaciones y gossip, fortaleciendo la inyección de fallos.
  • Los costos de retención ahora se ponderan por los bytes reales que un validator conserva.
  • Cada shard attest su propia proporción de emisión y se verifica en cada shard.
  • Los mensajes ahora deben declarar su clase explícitamente en lugar de usar un valor por defecto, mejorando la priorización en la red.
En resumen
Cambio destacado
El sistema de comisiones y pricing de recursos quedó conectado de extremo a extremo — desde los costos de lectura por leaf hasta la tabla de precios del beacon — el mayor avance para que las transacciones paguen lo que les toca.
Lo que viene
Lo probable que viene: seguir conectando el sistema de comisiones al ciclo de vida de ejecución y llevar el modelo de intent hacia la paridad de funcionalidades con el component model de Babylon.
Escuchado en el chat

El ánimo: Encendido debate comunitario sobre la futura relación de Hyperscale con Radix, incluyendo una larga propuesta de Wim sobre un posible reinicio con financiamiento. flightofthefox se mantuvo enfocado en los trade-offs honestos.

las blockchains no pueden ser las mejores en todas las dimensiones al mismo tiempo. tienes que elegir tus batallas
— flightofthefox, en el Telegram de la comunidad
flightofthefox explicó
El trade-off central de Hyperscale
La finalidad es el trade-off — siempre es más rápido ejecutar en bloques que ir por ejecución asíncrona cross-shard. Si no necesitas más de un shard, es un downgrade estricto.
Quién debería usar Hyperscale
Literalmente cero sentido usarlo a menos que tengas una situación plausible con cientos de miles o millones de transiciones de estado.
Planes a largo plazo
Trabajaré en otras cosas después de que sea estable y solo lo mantendré. No puedo trabajar en open source para siempre a menos que las redes lo patrocinen.
Posicionamiento en el mercado
El mercado de transacciones que toleran unos segundos extra es más grande que el mercado de finalidad sub-segundo — hasta que las cadenas de baja latencia se queden sin blockspace, los beneficios de los shards no serán obvios.
El concepto de la semana
The GovernorUn governor, no un voto
El trabajo principal fue pricing: lecturas por leaf, framing por evento, costos de scans, y mover la tabla de precios al beacon — la capa económica que hace que cada transacción pague lo que le toca.
hyperscale.rs/governor
Jerga, descifrada
IntentUna autorización firmada que indica qué cuentas y qué estado toca una transacción, ahora unificada en una sola estructura recursiva.
LeafUna sola entrada de datos en el árbol de estado; la unidad por la que el sistema de comisiones cobra lecturas o escrituras.
PreviewUn dry run de solo lectura que le dice a un wallet qué haría una transacción antes de enviarla.
ProvisionUna porción de estado que un shard envía a otro, probada contra un bloque ya commiteado.
Dónde aterrizó el trabajo
FSM de sync, recuperación de halted-tip, provisions
vm/effects · The Governor
pricing de comisiones y presupuesto de recursos conectados
modelo de intent y autorización de cuentas
vm/harness · The Crash Lab
fuzz tests y alineación de blobs en CI
terminación de shards y retiro de los que parten
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 7 · desde agosto de 2026. Desde el día uno: 4,918 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-09-21
Hyperscale Weekly — Semana #19 · 14–20 sept 2026