Antes: flightofthefox había rediseñado el interior de la VM — layouts formales de componentes, identidad de recursos y obtención de registros por nodo y shard — avanzando hacia la paridad de features con Babylon.
Esta fue una semana de endurecimiento profundo e intenso de la VM: flightofthefox hizo que el Radix Engine rechace construcciones inválidas por todos lados, formalizó cómo se describen los vaults y los recursos, y reestructuró grandes porciones de código en módulos más limpios. En la comunidad, una discusión animada sobre verificación formal y privacidad mostró cuánto resuena la filosofía de testing primero del proyecto.
349
-21% vs semana pasada
commits
+17k −6.9k
-44% vs semana pasada
líneas cambiadas
0
días seguidos con commits
Commits / día
pico 134/día · 5/7 días activos
Impulso
Líneas cambiadas / semana
últimas 8 semanas
79% Rust18% Config1% Docs1% Specs
Lo que construyó flightofthefox
La VM aprende a decir que no
Decenas de commits hacen que el engine rechace inputs erróneos — campos duplicados, cambios de supply aplicados a medias, shapes inválidas — en build time en vez de crashear en runtime, haciendo todo el sistema más seguro por construcción.
→ ver “The System” en hyperscale.rsVaults y recursos toman forma
Los vaults ahora son state fields con nombre y pares mint-burn explícitos, los cambios de supply deben aplicarse completos o no aplicarse, y las denominaciones de tokens se fijan a sus recursos — dándole al sistema de tokens una estructura precisa y verificable.
→ ver “The System” en hyperscale.rsLas pruebas obtienen procedencia y estructura
Las pruebas de autoridad ahora llevan procedencia trazable, el sign-in por threshold obtiene un path de presentación formal, y el badge-gating se vincula a evidencia a nivel de protocol — haciendo el control de acceso verificable en lugar de asumido.
→ ver “The Journey” en hyperscale.rsEn resumen
Cambio destacado
El Radix Engine ahora rechaza un rango enorme de construcciones inválidas — shapes incorrectas, campos duplicados, cambios de tokens aplicados a medias — antes de que el código se ejecute, convirtiendo las fallas de smart contracts en un problema de build time en lugar de un crash en runtime.
Lo que viene
Lo más probable para la próxima: continuar cableando operaciones de recursos como minting, burning y movimientos de vault en la VM endurecida, y terminar los paths de presentación de pruebas y autorización que claramente están en pleno vuelo.
Escuchado en el chat
El ánimo: El chat vibró con la verificación formal después de que un bug de Zcash salió en los titulares, con flightofthefox explicando cómo funcionarían los relays de privacidad y comentando que todavía no ha ido tras el M1 payment admin — demasiado ocupado construyendo.
“mientras más integrado esté el testing robusto desde el inicio - más te habilita para moverte a una velocidad ridícula - y moverte con confianza”
— flightofthefox, en el Telegram de la comunidad
El concepto de la semana
The System— Divide el trabajo, no el mundoCasi todos los commits de esta semana perforaron la arquitectura núcleo del Radix Engine — la capa de ejecución que corre cada smart contract — endureciendo su sistema de tipos, modelo de recursos y autorización contra clases enteras de fallas antes de que puedan ocurrir.
hyperscale.rs Jerga, descifrada
Vault — Un campo con nombre dentro de un componente de smart contract que guarda un tipo específico de token, rastreando cuánto de ese recurso contiene.
Provenance — Un registro de dónde provino una prueba de autoridad, para que el sistema pueda verificar que la persona correcta autorizó una acción.
Manifest — Un archivo blueprint que describe qué contiene un package de smart contract y cómo debería publicarse a la red.
Dónde aterrizó el trabajo
63 archivos: rechazos de operaciones de recursos y validación
52 archivos: manifest builder y proyecciones en tiempo de construcción
38 archivos: consolidación de tests y scaffold de invitados in-repo
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 4 · ~mes 1 de 5 · 18%. Desde el día uno: 4,003 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-08-31