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
20
días seguidos con commits
Commits / día
pico 120/día · 6/7 días activos
Impulso
Líneas cambiadas / semana
últimas 8 semanas
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.rsUn 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.rsDefinidos 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.rsFronteras 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.rsLa 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.rsShards 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.rsTambié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 Governor— Un governor, no un votoEl 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
Intent — Una autorización firmada que indica qué cuentas y qué estado toca una transacción, ahora unificada en una sola estructura recursiva.
Leaf — Una sola entrada de datos en el árbol de estado; la unidad por la que el sistema de comisiones cobra lecturas o escrituras.
Preview — Un dry run de solo lectura que le dice a un wallet qué haría una transacción antes de enviarla.
Provision — Una 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
pricing de comisiones y presupuesto de recursos conectados
modelo de intent y autorización de cuentas
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 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 7 · desde agosto de 2026. Desde el día uno: 4,918 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-21