Anteriormente: flightofthefox presentó el substate sweep para el garbage collection y añadió encabezados de red firmados a los transaction intents, lo que, junto con el exploit del Radix VM, impulsó su liquidación de XRD y un primer boceto de la ruta de migración
Esta fue la semana más grande del Hito 2 hasta ahora: flightofthefox aterrizó una reescritura casi completa de cómo la VM ejecuta las transacciones, canalizando cada ruta a través de un único punto de control llamado core boundary. Al mismo tiempo, el sistema de settlement entre shards, el substate sweep y las reglas de terminación de shards maduraron en paralelo, y el chat de Telegram se encendió con un debate acalorado sobre lo que Hyperscale significa para el futuro de Radix.
230
igual que la semana pasada
commits
+19k −16k
+39% vs semana pasada
líneas cambiadas
0
días seguidos con commits
Commits / día
pico 69/día · 5/7 días activos
Impulso
Líneas cambiadas / semana
últimas 8 semanas
84% Rust14% Config2% Docs
Lo que construyó flightofthefox
Ejecución reescrita en torno a un solo núcleo
Cada ruta de ejecución de smart contracts pasa ahora por un único core boundary, donde los módulos se publican, evalúan y miden. La VM contabiliza su propio fuel por página de memoria, y el código solo puede alcanzar lo que se le prestó explícitamente, lo que refuerza la seguridad y alinea la ejecución con el sharding.
→ ver “The System” en hyperscale.rsEl ledger entre shards toma forma
Los abandonment records, las counterpart questions y las state probes se unificaron en un solo ledger con una única regla de retención, reemplazando las verificaciones ad-hoc dispersas y haciendo que los compromisos entre shards sean más limpios y verificables.
→ ver “The Generals” en hyperscale.rsEl sweep integrado en los commits de bloque
El substate sweep se incorporó directamente en la ruta de commit de bloque, y cada artefacto derivado de una transacción ahora lleva una única gracia de expiración, de modo que la limpieza ocurre automáticamente a medida que los bloques se finalizan.
→ ver “The Archive” en hyperscale.rsReglas de muerte de shard reforzadas
Se endurecieron las reglas sobre qué ocurre cuando un shard termina a mitad de una transacción: el conjunto settled y el fence ahora gobiernan a todos los straddlers, con evidencia terminal dimensionada al tramo final del shard.
→ ver “The Will” en hyperscale.rsSeguridad ante forks reforzada
Los commits conflictivos a la misma altura de bloque ahora se rechazan de plano, las reclamaciones entre cadenas deben pasar un único vote fence, y los certificados de rondas descartadas se expulsan junto con sus ticks, cerrando varias brechas de seguridad ante forks.
→ ver “The Overlap” en hyperscale.rsSim y CI escalados
La suite de pruebas corre ahora en runners arm64 con mayor paralelismo, el simulador ganó validators asignados a sus hosts, y ambos backends de almacenamiento comparten un único helper de pruebas de conformidad.
→ ver “The Crash Lab” en hyperscale.rsTambién esta semana
- Los snapshots del memory store ahora comparten estructura, reduciendo duplicación entre nodos.
- La ventana del beacon header se acota al insertar, previniendo un crecimiento sin límite.
- Las Merkle proofs llevan siblings vacíos como bits únicos, ahorrando espacio en la red.
- Los abandonment records de bloque ahora se acotan en bytes en lugar de por conteo.
- La clonación del store de RocksDB se simplificó al eliminar su wrapper type.
- La lógica de split del resharding ahora deja espacio en el pool que el committee shuffle no puede tomar.
- Cuatro assertions de reshape se corrigieron para que realmente prueben lo que decían probar.
- Los stores de los shards que partieron ahora se sirven y el enrutado se inicializa al arrancar.
En resumen
Cambio destacado
El modelo de ejecución de la VM se reescribió en torno a un único core boundary: el cambio arquitectónico más grande del Hito 2 hasta ahora.
Lo que viene
Probablemente lo próximo: continuar cableando el ledger de settlement y el sweep en el ciclo de vida de ejecución, y empujar el core boundary de la VM hacia la paridad de features con el component model de Babylon.
Escuchado en el chat
El ánimo: El debate acalorado dominó el chat sobre si flightofthefox le debe a Radix una migración completa, con la frustración desbordándose, pero él reafirmó que ayudará a Radix a adoptar Hyperscale y señaló la reescritura de la VM
“un grant es una trampa hermosa: toma cincuenta y carga con toda la culpa; si el volante no gira preguntarán "¿quién cobró?" - así que tomaré el aplauso, no el chasquido”
— flightofthefox, en el Telegram de la comunidad
flightofthefox explicó
Por qué la ejecución tomó más tiempo
La ejecución local de Leg es una reescritura casi completa de cómo funciona la ejecución, así que el feature ha tardado más en aterrizar que la mayoría.
Substate sweep vs GC
Es limpieza de almacenamiento, no de memoria: reclama espacio de guards que no necesitan existir una vez que expiran las ventanas de validez de los artefactos, como los subintent nullifiers.
Alternativa al session mode
Los componentes de acceso compartido combinados con subintents probablemente ofrezcan una UX tan buena como las sessions, sin los potenciales foot-guns.
Migración más difícil de lo esperado
Él creía de verdad que el Radix Engine existente sería más propicio para el sharding; fue un despertar brusco, y construir una VM completamente nueva resultó necesario.
El concepto de la semana
The System— Divide el trabajo, no el mundoLa reescritura del core boundary es el cambio arquitectónico más grande del Hito 2 hasta ahora: redefine cómo se ejecuta cada transacción, cómo se miden los recursos y cómo se contiene el código, todo para que la ejecución sea compatible con el sharding.
hyperscale.rs Jerga, descifrada
Core boundary — El único punto de control donde todo el código de smart contracts se publica, valida y mide antes de poder ejecutarse.
Abandonment record — Una nota que indica que una transacción dejó cierto estado atrás y que ese estado ya es seguro de reclamar.
Meter — Un contador integrado en cada módulo que limita cuánta computación puede consumir, evitando que el código se descontrole.
Vote fence — Una regla que impide que un bloque se confirme hasta que sus afirmaciones sobre otras cadenas hayan sido verificadas por una votación.
Dónde aterrizó el trabajo
ledger entre shards, settlement y tipos de abandonment
core boundary de la VM, metering y límites de alcance
test harness, CI arm64, compartición de conformidad
enrutado a nivel de nodo, fetch y rutas de commit
imports del kernel, ABI central y cableado de fuel
Referencia — mapa de conceptos, hoja de ruta y enlaces▾
El panorama completo
The ClockConsensus-attested time across independent shards.
The CensusThe leaderless beacon of validators, stake and shards.
The OverlapWhy two conflicting blocks can never both commit.
The GeneralsAll-or-nothing cross-shard commits, computed not voted.
The ArchiveEvery published byte is preserved or provably expired.
The LibraryAll state in one merkle tree; a shard is a subtree.
The WillHow in-flight transactions settle when a shard dies.
The LotteryRandom, ever-moving committees; proven cheats are jailed.
The TriageUnder overload, urgent traffic never waits for bulk.
The GovernorValidator entry is re-priced every epoch, like a market.
The Crash LabThe simulator that replays any failure byte-for-byte.
The ProofProving safety with maths, not just tests.
The AsterisksEvery design's trade-offs — including Hyperscale's own.
El camino a mainnet
✓ M1
Adaptive Sharding
~4 mo
Ahora: Milestone 2 · Radix Engine — Semana 6 · desde agosto de 2026. Desde el día uno: 4,464 commits — un solo desarrollador, totalmente en público.
Enlaces
¿Preguntas? flightofthefox siempre está feliz de conversar en el Telegram de la comunidad.
Escrito por IA a partir de commits públicos, el chat de la comunidad y hyperscale.rs — puede contener errores. · generado 2026-09-14