Anteriormente: flightofthefox havia conectado o sistema de taxas e precificação de recursos de ponta a ponta e unificado o modelo de intent, avançando mais fundo no trabalho de VM do Milestone 2.
A semana 8 do Milestone 2 trouxe uma reconstrução profunda e focada de como as transações cross-shard são rastreadas e resolvidas dentro da VM. flightofthefox reescreveu todo o sistema de 'crossings' — a engrenagem que permite a uma transação abrangendo múltiplos shards registrar, responder e limpar seus commitments — ao mesmo tempo em que reforçou as fee holds e eliminou caminhos de execução mortos. No Telegram, uma conversa rica sobre migração e compatibilidade mostrou a comunidade engajada seriamente com o que Hyperscale significaria para os apps Radix existentes.
32
-92% vs semana passada
commits
+3.1k −3.4k
-76% vs semana passada
linhas alteradas
28
dias seguidos com commits
Commits / dia
pico 10/dia · 7/7 dias ativos
Ritmo
Linhas alteradas / semana
últimas 8 semanas
O que flightofthefox construiu
Crossings cross-shard reconstruídos
A maior parte da semana redesenhou os 'crossings' — como a VM rastreia transações cross-shard de ponta a ponta. Os crossings agora recebem um nome único, com todas as chaves derivadas desse nome, as respostas carregam dois vereditos, e os blocos carregam registros de crossing diretamente.
→ veja “The Generals” em hyperscale.rsFee holds e depósitos em vault
As reservas de fee agora são tratadas como committed holds dentro do kernel, e os depósitos em vault saíram de jobs espalhados para um caminho único dentro do kernel — tornando o manuseio de recursos mais limpo e previsível.
→ veja “The Journey” em hyperscale.rsCaminhos de execução mortos eliminados
Vários tipos de job desatualizados e um mecanismo de tombstone de crossing foram removidos completamente, substituídos por uma lógica mais simples baseada em flags — menos código para manter, menos casos extremos para quebrar.
→ veja “The System” em hyperscale.rsResumo da ópera
Mudança de destaque
O sistema de crossings — como transações cross-shard são nomeadas, rastreadas, respondidas e limpas — foi totalmente reconstruído.
O que vem por aí
Provável próximo passo: continuar refinando o sistema de crossings e encarar o caminho de execução local que flightofthefox apontou como um grande desafio.
Ouvido no chat
O clima: Uma semana agitada: um desenvolvedor chamado Seböööl mergulhou no codebase e provocou uma troca de ideias detalhada sobre migração, compatibilidade de contratos e se Babylon e Hyperscale podem coexistir.
“leg local execution is my vietnam”
— flightofthefox, no Telegram da comunidade
flightofthefox explicou
Caminho de migração para Hyperscale
O plano aproximado é dump, transformar, genesis — contratos reconstruídos antes do lançamento se os devs estiverem ativos, os atrasados atualizados depois por meio de votação na beacon-chain, com blueprints ficando desativados até lá.
Design de interação entre componentes
Chamadas entre componentes devem funcionar se o alvo estiver em config imutável ou for passado como argumento, mas ele quer explorar estender o DAG do manifest no local da chamada em vez de replicar o method dispatch da Radix Engine.
Atualização de contratos sem proxies
Ele planeja um sistema nativo de upgrade de blueprints para que os desenvolvedores não precisem construir padrões de proxy, com upgrades coordenados por meio de testemunhas da beacon-chain para serem aplicados de forma consistente na mesma epoch.
Por que não há backlog público
A fundação ainda está em fluxo, então manter uma especificação formal atrasaria as coisas — existe uma ordem de operações, e é cedo demais para dimensionar a migração.
O conceito da semana
The Generals— Os dois generais dispensaram seus mensageirosO trabalho dominante nesta semana foi reconstruir como transações cross-shard são rastreadas e resolvidas — o núcleo do commitment atômico cross-shard.
hyperscale.rs/generals Jargão, decifrado
Crossing — O nome que a VM dá ao ciclo de vida rastreado de uma transação cross-shard conforme o estado se move entre shards.
Fee hold — A porção da fee de uma transação reservada antecipadamente, antes de sua execução, para que não possa gastar demais.
Tombstone — Um marcador indicando que um registro cross-shard foi aposentado e é seguro limpá-lo depois.
Onde o trabalho aterrissou
respostas de crossing e efeitos de estado retrabalhados
depósitos em vault, fee holds, crossing jobs
APIs atualizadas para o novo modelo de crossing e fee
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 8 · desde Agosto de 2026. Desde o primeiro dia: 4.959 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-28