Anteriormente: flightofthefox reconstruiu de forma abrangente o sistema de crossing para rastrear transações cross-shard, e sinalizou a execução local como um grande desafio pela frente.
Nesta semana, flightofthefox deixou para trás a reconstrução do sistema de crossing da semana passada e partiu para um tipo diferente de problema difícil: o que acontece quando um shard sofre fork, para ou precisa de um novo validator empossado no meio do voo. Os commits contam uma história de fazer a recuperação e o assentamento de validators funcionarem de forma limpa em shards em execução — tanto em produção quanto no simulador.
19
-89% vs semana passada
commits
+4.0k −1.1k
-84% vs semana passada
linhas alteradas
0
dias seguidos com commits
Commits / dia
pico 19/dia · 1/7 dias ativos
Ritmo
Linhas alteradas / semana
últimas 8 semanas
O que flightofthefox construiu
Reconstruindo shards em fork a partir de anchors
flightofthefox fez com que shards em fork, em produção e no simulador, se reconstruíssem a partir de um anchor conhecido antes que os validators sejam empossados, garantindo que a recuperação sempre comece a partir de estado verificado e não de dados não confiáveis.
→ veja “The Archive” em hyperscale.rsEmpossando validators em shards ativos
Novos validators agora podem entrar em um shard em execução assim que seu store local estabiliza, e validators co-hosted podem ser empossados e liberados em shards de produção e de simulação — a maquinaria para a trickle rotation que mantém os committees honestos.
→ veja “The Lottery” em hyperscale.rsRecuperação de halt fica mais robusta
Os bindings de recuperação agora são resolvidos a partir de histórico limitado em vez de registros pendentes, shards em halt congelam retendo validators em vez de cortar hosts, e o recovery floor é definido antes de descartar dados antigos de frontier.
→ veja “The Overlap” em hyperscale.rsResumo da ópera
Mudança de destaque
Validators agora podem ser empossados e liberados em shards em execução — a maquinaria ativa para a rotação de committees.
O que vem por aí
Provável próximo passo: continuar a endurecer a recuperação de halt e conectar o caminho de assentamento de validators ao sistema de trickle rotation.
Ouvido no chat
O clima: O chat foi dominado por um debate acalorado sobre se os detentores de XRD se beneficiam do Hyperscale, com flightofthefox recusando-se firmemente a prometer qualquer coisa além da tecnologia.
“o que o XRD faz não depende de mim. eu só estou construindo tecnologia; se a Radix quer dar um grant porque isso ajuda a alcançar os objetivos dela, ótimo. esse é um bom alinhamento de incentivos”
— flightofthefox, no Telegram da comunidade
flightofthefox explicou
DePIN no Hyperscale
DePIN não traz desafios técnicos — a parte on-chain geralmente é uma fração minúscula da arquitetura, e a própria plataforma de smart contracts é um framework suficiente.
Token para recompensas de DePIN
É melhor usar tokens discretos para serviços de pure-play do que misturar a tokenomics que existe para cumprir objetivos concretos de segurança.
Seu papel vs. preço do XRD
Ele constrói tecnologia e não consegue resolver todos os problemas; se o XRD se beneficia está fora do domínio dele, embora ele trabalhe duro para ser competitivo com o mercado.
Manter o canal aberto
Sem a Radix não existiria o canal do Telegram; ele o mantém aberto para compartilhar entusiasmo por consenso e responder perguntas, porque a comunidade da Radix se importa com isso.
O conceito da semana
The Lottery— Um júri que você não consegue subornarEmpossar e liberar validators co-hosted em shards em execução é a base prática da trickle rotation — a mudança de committee de um assento por vez que dispersa a corrupção mantendo os shards ativos.
hyperscale.rs/kleroterion Jargão, decifrado
Anchor — Um checkpoint válido na história de um shard a partir do qual a recuperação pode reconstruir com segurança.
Co-hosted validator — Múltiplas identidades de validator rodando na mesma máquina física, que é como os vnodes funcionam.
Frontier — A borda de avanço da chain de um shard que a recuperação deve preservar antes de descartar.
Onde o trabalho aterrissou
empossamento e liberação de validators em shards em execução
reconstrução de shard em fork a partir de anchors antes do assentamento
simulações de recuperação de halt em layouts co-hosted
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 9 · desde agosto de 2026. Desde o primeiro dia: 5.133 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-10-05