Anteriormente: flightofthefox había conectado el sistema de comisiones y precios de recursos de punta a punta y unificado el modelo de intent, adentrándose más en el trabajo de VM del Hito 2.
La semana 8 del Hito 2 trajo una reconstrucción profunda y enfocada de cómo se rastrean y resuelven las transacciones cross-shard dentro de la VM. flightofthefox reescribió por completo el sistema de 'crossings' — la maquinaria que permite a una transacción que abarca múltiples shards registrar, responder y limpiar sus compromisos — mientras también ajustaba las fee holds y eliminaba rutas de ejecución muertas. En Telegram, una rica conversación sobre migración y compatibilidad mostró a la comunidad involucrándose seriamente con lo que Hyperscale significaría para las apps existentes de Radix.
32
-92% vs semana pasada
commits
+3.1k −3.4k
-76% vs semana pasada
líneas cambiadas
28
días seguidos con commits
Commits / día
pico 10/día · 7/7 días activos
Impulso
Líneas cambiadas / semana
últimas 8 semanas
Lo que construyó flightofthefox
Crossings cross-shard reconstruidos
La mayor parte de la semana se dedicó a rediseñar los 'crossings' — cómo la VM rastrea las transacciones cross-shard de punta a punta. Ahora los crossings se nombran una sola vez con todas las claves derivadas de ese nombre, las respuestas llevan dos veredictos, y los bloques cargan los registros de crossing directamente.
→ ver “The Generals” en hyperscale.rsFee holds y depósitos en vaults
Las reservas de comisiones ahora se tratan como holds comprometidos dentro del kernel, y los depósitos en vaults pasaron de jobs dispersos a una sola ruta del kernel — haciendo el manejo de recursos más limpio y predecible.
→ ver “The Journey” en hyperscale.rsRutas de ejecución muertas eliminadas
Varios tipos de job obsoletos y un mecanismo de tombstone de crossing se eliminaron por completo, reemplazados por lógica más simple basada en flags — menos código que mantener, menos casos límite que romper.
→ ver “The System” en hyperscale.rsEn resumen
Cambio destacado
El sistema de crossings — cómo se nombran, rastrean, responden y limpian las transacciones cross-shard — fue reconstruido por completo.
Lo que viene
Lo más probable: continuar refinando el sistema de crossings y abordar la ruta de ejecución local que flightofthefox señaló como un gran desafío.
Escuchado en el chat
El ánimo: Una semana intensa: un desarrollador llamado Seböööl se sumergió en el codebase y desató un intercambio detallado sobre migración, compatibilidad de contratos, y si Babylon y Hyperscale pueden coexistir.
“leg la ejecución local es mi Vietnam”
— flightofthefox, en el Telegram de la comunidad
flightofthefox explicó
Ruta de migración a Hyperscale
El plan aproximado es dump, transform, genesis — los contratos se reconstruyen antes del lanzamiento si los devs están activos, los que queden rezagados se actualizan después mediante votación de la beacon-chain con los blueprints desactivados hasta entonces.
Diseño de interacción entre componentes
Las llamadas entre componentes deberían funcionar si el target está en un config inmutable o se pasa como argumento, pero quiere explorar extender el manifest DAG en el sitio de la llamada en vez de replicar el method dispatch del Radix Engine.
Actualizaciones de contratos sin proxies
Planea un sistema nativo de actualización de blueprints para que los developers no tengan que construir patrones de proxy, con actualizaciones coordinadas a través de witnesses de la beacon-chain para que se apliquen de forma consistente en la misma epoch.
Por qué no hay un backlog público
La base todavía está en flujo, así que mantener una spec formal frenaría las cosas — hay un orden de operaciones, y es demasiado temprano para dimensionar la migración.
El concepto de la semana
The Generals— Los dos generales dejaron a un lado a sus mensajerosEl trabajo principal de esta semana fue reconstruir cómo se rastrean y resuelven las transacciones cross-shard — el núcleo del compromiso atómico cross-shard.
hyperscale.rs/generals Jerga, descifrada
Crossing — El nombre que la VM le da al ciclo de vida rastreado de una transacción cross-shard a medida que el estado se mueve entre shards.
Fee hold — La porción de la comisión de una transacción reservada por adelantado antes de que se ejecute, para que no pueda gastarse de más.
Tombstone — Un marcador que indica que un registro cross-shard ha sido retirado y es seguro limpiarlo después.
Dónde aterrizó el trabajo
respuestas de crossing y efectos de estado reestructurados
depósitos en vaults, fee holds, crossing jobs
APIs actualizadas para el nuevo modelo de crossing y comisiones
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 8 · desde agosto de 2026. Desde el día uno: 4,959 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-28