Anteriormente: flightofthefox tinha acabado de reconstruir a camada de rede em torno do iroh e dado às staking pools caminhos de auto-fundação e de handover.
Uma semana tranquila e focada: todos os dezesseis commits caíram no novo VM, o engine construído do zero que permite que smart contracts rodem entre shards. flightofthefox passou a semana aperfeiçoando a forma como o engine lê o estado compartilhado e como as taxas são queimadas, enquanto o chat foi dominado pelas consequências de um grande hack em uma exchange.
16
-83% vs semana passada
commits
+1.9k −384
-84% vs semana passada
linhas alteradas
2
dias seguidos com commits
Commits / dia
pico 7/dia · 3/7 dias ativos
Ritmo
Linhas alteradas / semana
últimas 8 semanas
O que flightofthefox construiu
Mantendo o estado compartilhado honesto
Boa parte da semana foi dedicada às regras de como um contrato lê o estado entregue por outro shard: toda leitura precisa vir exatamente do trecho que foi servido, nunca de algum lugar desatualizado. É isso que torna possível a execução idêntica — e, com isso, pagamentos cross-shard atômicos.
→ veja “The Generals” em hyperscale.rsTaxas são queimadas, de forma comprovável
O engine agora registra a queima de taxas junto com cada mudança de estado, de modo que as taxas destruídas são contabilizadas com o mesmo rigor que os próprios saldos. Isso importa porque dinheiro sumindo sem registro é exatamente o que uma rede auditável não pode permitir.
→ veja “The Journey” em hyperscale.rsSorteios aleatórios respeitam o relógio
As novas regras amarram os sorteios de comitês a seeds de aleatoriedade de épocas estritamente anteriores, e fixam o relógio por transação, em vez de por bloco. Isso mantém as atribuições de validator imprevisíveis e justas — ninguém consegue espiar as seeds antes de decidir como agir.
→ veja “The Lottery” em hyperscale.rsResumo da ópera
Mudança de destaque
O novo VM agora garante que os contratos só consigam ler exatamente o estado cross-shard que lhes foi provado e servido.
O que vem por aí
Provavelmente a seguir: mais blindagem do VM em torno das leituras de estado servido e da contabilidade de taxas, além do design otimizado de rede que foi insinuado.
Ouvido no chat
O clima: O chat foi dominado pelo hack da Binance e pela questão de se os validators da Radix deveriam bloquear as carteiras roubadas; flightofthefox também conduziu uma animada chamada de office hours na sexta-feira.
“resistência à censura não é algo que você pode simplesmente presumir, tem que ser trabalhada”
— flightofthefox, no Telegram da comunidade
flightofthefox explicou
Validators são soberanos
Ele explicou que não é necessário um voto coordenado para bloquear certas transações — cada validator pode decidir individualmente em quais blocos votar, e lembrou que eles são soberanos.
Governança embutida no protocolo
Ele disse que o Hyperscale tem sua própria governança e votação embutidas no protocolo, porque qualquer votação estilo DAO que não esteja alinhada 1:1 com os poderes reais de consenso não tem dentes.
Pós-quântico é obrigatório
Perguntado se o Hyperscale será resistente a quantum, ele respondeu que não vale a pena lançar nada que não seja quantum-resistant.
Office hours de sexta-feira
Ele criou uma chamada de voz aberta, estilo TGIF, para quem quiser conversar sobre Hyperscale, Radix, cripto, software ou a vida em geral.
O conceito da semana
The Generals— Os dois generais depuseram seus mensageirosA maior parte do trabalho blinda as leituras de estado provisionado pelo engine, que é a base para executar transações cross-shard byte a byte de forma idêntica em cada shard.
hyperscale.rs/generals Jargão, decifrado
Fee burn — Taxas de transação que são permanentemente destruídas em vez de pagas a alguém.
Kernel — O núcleo confiável do VM, pelo qual todos os contratos precisam passar para ler ou escrever qualquer estado.
Provisioned state — Um pedaço do estado de um shard enviado a outro shard acompanhado de uma proof, para que possa ser verificado em vez de apenas confiado.
Onde o trabalho aterrissou
regras para leitura de estado servido e comprovado
queima de taxas atrelada às mudanças de estado
vm/docs
documentando as regras do novo VM
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.
As quatro partes
✓ concluído
Adaptive Sharding
Shards that split and merge on their own · Aug 2026
100%
The new VM
A new engine built from scratch so smart contracts run across shards
–
Indexing & APIs
So wallets and apps can read a sharded network
–
Validator tooling & testnet
Running a node, and a public test network
–
Foundations & reliability
Networking, storage, crypto and testing that every part stands on
As barras mostram a fatia de linhas alteradas nesta semana. O trabalho de base compartilhado conta como Foundations & reliability. Desde o primeiro dia: 5.733 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-11-09