XI'AN · HYPERSCALE FOR RADIX

Hyperscale Weekly

Semana #19 · 14–20 Set 2026 · Milestone 2 · Radix Engine · Semana 7 · desde agosto de 2026
Divida o trabalho, não o mundo
MARCO ATUAL
Milestone 2 · Radix Engine
Portando o Radix Engine para que o Scrypto rode em múltiplos shards
Semana 7 · desde agosto de 2026

Anteriormente: flightofthefox havia reescrito o modelo de execução da VM em torno de um único limite central — a maior mudança arquitetural do Milestone 2 até agora.

Dando continuidade à reescrita da VM da semana passada, flightofthefox entrou num esforço massivo de precificação e orçamento de recursos — o sistema de taxas que permite à rede cobrar das transações exatamente o que elas custam. A semana também viu o modelo de recuperação de conta, a sincronização de blocos e o settlement cross-shard darem passos importantes à frente. Uma semana pesada e ampla.

408
+48% vs semana passada
commits
+18k 9.1k
-21% vs semana passada
linhas alteradas
600
arquivos tocados
20
dias seguidos com commits
Commits / dia
S
T
Q
Q
S
S
D
pico 120/dia · 6/7 dias ativos
Ritmo
Linhas alteradas / semana
últimas 8 semanas
86% Rust14% Config
O que flightofthefox construiu

Transações precificadas pelo que tocam

flightofthefox conectou custos de leitura por leaf, cobranças de framing por evento e precificação de scan na execução — e moveu a tabela de preços para o beacon. As transações agora pagam exatamente pelos recursos que consomem.

→ veja “The Governor” em hyperscale.rs

Um intent para compô-los todos

O modelo de autorização foi unificado em torno de um único intent recursivo — toda transação é um intent que compõe outros, cada um assinado e invalidado independentemente, eliminando tipos de roteamento dispersos.

→ veja “The Journey” em hyperscale.rs

Papéis de recuperação de conta definidos

Novos papéis da VM — um primário, um papel de veto e um segundo fator — permitem que uma conta congele, altere guardiões ou faça rotação instantânea, tudo governado por regras on-chain em vez de confiança.

→ veja “The System” em hyperscale.rs

Fronteiras de sincronização e tips paradas

A sincronização de blocos virou uma máquina de estados de fato, e a recuperação de tip parada foi reconstruída para colher de timeouts verificados e filtrar a composição do comitê antes de fazer commit.

→ veja “The Archive” em hyperscale.rs

Settlement cross-shard mais rigoroso

As janelas de provision agora são compartilhadas em vez de espelhadas, bundles descartados satisfazem seus solicitantes, e taxas não julgadas são liquidadas contra o que o pagador detém — reforçando o caminho de commit.

→ veja “The Generals” em hyperscale.rs

Shards departed retirados de forma limpa

As regras de terminação de shard foram endurecidas: shards departed se retiram quando sua janela de evidência fecha, chains terminadas param de compor ticks, e pools expiradas são limitadas.

→ veja “The Will” em hyperscale.rs
Também nesta semana
  • Carteiras agora podem pedir a um node um preview somente leitura do que uma transação faria antes de submetê-la.
  • Divisões de shard agora podem ser acionadas automaticamente quando um shard chega perto dos seus limites de capacidade.
  • O atraso de rede é estimado a partir da chain commitada, orientando timers de rodada e timeouts de fetch.
  • Timestamps de quorum agora são tomados como a mediana das leituras de relógio dos votantes, suavizando o clock atestado.
  • Um remetente Byzantine simulado agora pode reescrever notificações e gossip, fortalecendo a injeção de falhas.
  • Custos de retenção agora são ponderados pelos bytes reais que um validator mantém.
  • Cada shard atesta sua própria parcela de emissão e é verificado em cada shard.
  • Mensagens agora devem declarar sua classe explicitamente em vez de usar padrão, melhorando a priorização na rede.
Resumo da ópera
Mudança de destaque
O sistema de taxas e precificação de recursos foi conectado de ponta a ponta — dos custos de leitura por leaf até a tabela de preços do beacon — o maior avanço para fazer as transações pagarem seu próprio caminho.
O que vem por aí
Provável próximo passo: continuar conectando o sistema de taxas ao ciclo de vida da execução e levar o modelo de intent em direção à paridade de recursos com o modelo de componentes do Babylon.
Ouvido no chat

O clima: Aceso debate na comunidade sobre a futura relação do Hyperscale com o Radix, incluindo uma longa proposta do Wim sobre uma possível reinicialção financiada. flightofthefox manteve o foco em trade-offs honestos.

blockchains não podem ser as melhores em todas as dimensões simultaneamente. você tem que escolher suas batalhas
— flightofthefox, no Telegram da comunidade
flightofthefox explicou
O trade-off central do Hyperscale
Finalidade é o trade-off — é sempre mais rápido executar em blocos do que passar por execução assíncrona para cross-shard. Se você não precisa de mais de um shard, é uma desvantagem clara.
Quem deveria usar o Hyperscale
Literalmente não há sentido em usar a menos que você tenha uma situação plausível com centenas de milhares ou milhões de transições de estado.
Planos de longo prazo
Vou trabalhar em outras coisas depois que estiver estável e apenas manter. Não dá pra trabalhar em open source pra sempre a menos que as redes patrocinem.
Posicionamento de mercado
O mercado de transações que toleram alguns segundos a mais é maior do que o mercado de finalidade sub-segundo — até que chains de baixa latência esgotem o blockspace, os benefícios dos shards serão não óbvios.
O conceito da semana
The GovernorUm governador, não um voto
O trabalho dominante foi precificação: leituras por leaf, framing por evento, custos de scan, e mover a tabela de preços para o beacon — a camada econômica que faz cada transação pagar seu próprio caminho.
hyperscale.rs/governor
Jargão, decifrado
IntentUma autorização assinada que nomeia quais contas e estados uma transação toca, agora unificada em uma única estrutura recursiva.
LeafUma única entrada de dados na árvore de estado; a unidade pela qual o sistema de taxas cobra leituras ou escritas.
PreviewUm dry run somente leitura que diz a uma carteira o que uma transação faria antes de ser submetida.
ProvisionUm pedaço de estado que um shard envia a outro, comprovado contra um bloco commitado.
Onde o trabalho aterrissou
FSM de sync, recuperação de tip parada, provisions
vm/effects · The Governor
precificação de taxas e orçamento de recursos conectados
modelo de intent e autorização de conta
vm/harness · The Crash Lab
fuzz tests e alinhamento de blob no CI
terminação de shard e retirada de departed
Referência — mapa de conceitos, roteiro e links
O quadro completo
The System
The whole sharded design at a glance.
The Journey
One transaction's trip through the network.
The Clock
Consensus-attested time across independent shards.
The Census
The leaderless beacon of validators, stake and shards.
The Overlap
Why two conflicting blocks can never both commit.
The Generals
All-or-nothing cross-shard commits, computed not voted.
The Archive
Every published byte is preserved or provably expired.
The Library
All state in one merkle tree; a shard is a subtree.
The Will
How in-flight transactions settle when a shard dies.
The Lottery
Random, ever-moving committees; proven cheats are jailed.
The Triage
Under overload, urgent traffic never waits for bulk.
The Governor
Validator entry is re-priced every epoch, like a market.
The Crash Lab
The simulator that replays any failure byte-for-byte.
The Proof
Proving safety with maths, not just tests.
The Asterisks
Every design's trade-offs — including Hyperscale's own.
O caminho até a mainnet
✓ M1
Adaptive Sharding
~4 mo
M2
Radix Engine
~5 mo
M3
Gateway & API
~3 mo
M4
Validator GUI
~3 mo
M5
Migration
~3 mo
M6
Live support
12 mo
Agora: Milestone 2 · Radix Engine — Semana 7 · desde agosto de 2026. Desde o primeiro dia: 4.918 commits — um único desenvolvedor, totalmente em público.
Links
Escrito por IA a partir de commits públicos, do chat da comunidade e de hyperscale.rs — pode conter erros. · gerado 2026-09-21
Hyperscale Weekly — Semana #19 · 14–20 Set 2026