Anteriormente: flightofthefox introduziu o substate sweep para garbage collection e adicionou headers de rede assinados aos transaction intents, com o exploit no Radix VM motivando sua liquidação de XRD e um esboço do caminho de migração
Esta foi a maior semana do Milestone 2 até agora — flightofthefox entregou uma reescrita quase completa de como a VM executa transações, levando todo caminho por um único ponto de verificação chamado core boundary. Enquanto isso, o sistema de settlement cross-shard, o substate sweep e as regras de término de shard amadureceram em paralelo, e o chat do Telegram esquentou com um debate acalorado sobre o que Hyperscale significa para o futuro da Radix.
230
igual à semana passada
commits
+19k −16k
+39% vs semana passada
linhas alteradas
0
dias seguidos com commits
Commits / dia
pico 69/dia · 5/7 dias ativos
Ritmo
Linhas alteradas / semana
últimas 8 semanas
84% Rust14% Config2% Docs
O que flightofthefox construiu
Execução reescrita em torno de um único núcleo
Todo caminho de execução de smart contract agora passa por um único core boundary, onde módulos são publicados, julgados e medidos. A VM contabiliza seu próprio fuel por página de memória, e o código só consegue acessar o que foi explicitamente emprestado — reforçando a segurança e alinhando a execução com o sharding.
→ veja “The System” em hyperscale.rsLedger cross-shard ganha forma
Registros de abandono, perguntas de contraparte e state probes foram unificados em um único ledger com uma regra de retenção, substituindo verificações avulsas e espalhadas e tornando os compromissos cross-shard mais limpos e verificáveis.
→ veja “The Generals” em hyperscale.rsSweep integrado ao commit de blocos
O substate sweep foi incorporado diretamente ao caminho de commit de bloco, e todo artefato derivado de transação agora carrega um único prazo de carência — então a limpeza acontece automaticamente à medida que os blocos são finalizados.
→ veja “The Archive” em hyperscale.rsRegras de morte de shard endurecidas
As regras sobre o que acontece quando um shard termina no meio de uma transação foram endurecidas: o settled set e o fence agora governam todo straddler, com evidência terminal dimensionada para o trecho final do shard.
→ veja “The Will” em hyperscale.rsSegurança de fork reforçada
Commits conflitantes na mesma altura de bloco agora são recusados de imediato, claims cross-chain precisam passar por um único vote fence, e certificados de rodadas descartadas são removidos junto com seus ticks — fechando várias brechas de segurança de fork.
→ veja “The Overlap” em hyperscale.rsSim e CI escalados
A suíte de testes agora roda em runners arm64 com paralelismo maior, o simulador ganhou validadores vinculados aos seus hosts, e os dois backends de armazenamento compartilham um único helper de conformance test.
→ veja “The Crash Lab” em hyperscale.rsTambém nesta semana
- Snapshots do memory store agora compartilham estrutura, reduzindo duplicação entre nodes.
- A janela do beacon header é limitada no momento da inserção, evitando crescimento ilimitado.
- Merkle proofs carregam siblings vazios como bits únicos, economizando espaço na comunicação.
- Registros de abandonment de bloco agora são limitados em bytes em vez de por contagem.
- O clone do store RocksDB foi simplificado ao remover seu tipo wrapper.
- A lógica de split do resharding agora deixa espaço no pool que o committee shuffle não consegue tomar.
- Quatro asserções de reshape foram corrigidas para de fato testar o que afirmavam testar.
- Stores de shards extintos agora são servidos e o roteamento é propagado no boot.
Resumo da ópera
Mudança de destaque
O modelo de execução da VM foi reescrito em torno de um único core boundary — a maior mudança arquitetural do Milestone 2 até agora.
O que vem por aí
Provável próximo passo: continuar integrando o ledger de settlement e o sweep ao ciclo de vida da execução, e levar o core boundary da VM à paridade de funcionalidades com o component model da Babylon.
Ouvido no chat
O clima: Um debate acalorado dominou o chat sobre se o flightofthefox deve à Radix uma migração completa, com a frustração transbordando — mas ele reafirmou que vai ajudar a Radix a adotar Hyperscale e destacou a reescrita da VM
“a grant is a beautiful trap: take fifty and wear the whole rap; if the flywheel won't spin they will ask "who cashed in?" - so i'll take the applause, not the clap”
— flightofthefox, no Telegram da comunidade
flightofthefox explicou
Por que a execução demorou mais
A execução local de leg é uma reescrita quase completa de como a execução funciona, então a feature levou mais tempo para pousar do que a maioria.
Substate sweep vs GC
Está limpando armazenamento, não memória — reclamando espaço de guards que não precisam existir quando as janelas de validade dos artefatos expiram, como subintent nullifiers.
Alternativa ao session mode
Componentes de acesso compartilhado combinados com subintents provavelmente dão uma UX tão boa quanto sessions, sem os potenciais foot-guns.
Migração mais difícil que o esperado
Ele realmente acreditava que o Radix Engine existente seria mais receptivo ao sharding — foi um despertar rude, e foi necessário construir uma VM totalmente nova.
O conceito da semana
The System— Divida o trabalho, não o mundoA reescrita do core boundary é a maior mudança arquitetural do Milestone 2 até agora — ela redefine como toda transação é executada, como recursos são medidos e como o código é contido, tudo para tornar a execução compatível com o sharding.
hyperscale.rs Jargão, decifrado
Core boundary — O ponto de verificação único onde todo código de smart contract é publicado, validado e medido antes de poder rodar.
Abandonment record — Um registro de que uma transação deixou certo state para trás e que esse state agora é seguro para ser reclamado.
Meter — Um contador embutido em cada módulo que limita quanto de computação ele pode consumir, evitando código descontrolado.
Vote fence — Uma regra que impede um bloco de ser commitado até que suas claims sobre outras chains sejam verificadas por votação.
Onde o trabalho aterrissou
ledger cross-shard, settlement e tipos de abandonment
core boundary da VM, metering e limites de alcance
test harness, CI arm64, compartilhamento de conformance
roteamento em nível de node, fetch e caminhos de commit
imports do kernel, core ABI e ligação de fuel
Referência — mapa de conceitos, roteiro e links▾
O quadro 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.
O caminho até a mainnet
✓ M1
Adaptive Sharding
~4 mo
Agora: Milestone 2 · Radix Engine — Semana 6 · desde Agosto de 2026. Desde o primeiro dia: 4.464 commits — um único desenvolvedor, totalmente em público.
Links
Dúvidas? flightofthefox está sempre feliz em conversar no Telegram da comunidade.
Escrito por IA a partir de commits públicos, do chat da comunidade e de hyperscale.rs — pode conter erros. · gerado 2026-09-14