XI'AN · HYPERSCALE FOR RADIX

Hyperscale Weekly

Неделя №19 · 14–20 сентября 2026 · Milestone 2 · Radix Engine · Неделя 7 · с августа 2026
Раздели работу, а не мир
ТЕКУЩИЙ ЭТАП
Milestone 2 · Radix Engine
Перенос Radix Engine, чтобы Scrypto работал между shard'ами
Неделя 7 · с августа 2026

Ранее: flightofthefox переписал модель выполнения VM вокруг единого центрального контура — крупнейшее архитектурное изменение Этапа 2 на сегодняшний день.

Развивая прошлонедельную переработку VM, flightofthefox переключился на масштабную работу над ценообразованием и бюджетированием ресурсов — fee-системой, которая позволяет сети взимать с транзакций ровно столько, сколько они стоят. На этой неделе также модели восстановления аккаунтов, синхронизация блоков и кросс-шардовый сеттлмент сделали большие шаги вперед. Очень насыщенная и широкая неделя.

408
+48% к прошлой неделе
коммитов
+18k 9.1k
-21% к прошлой неделе
строк изменено
600
файлов затронуто
20
дней подряд с коммитами
Коммиты / день
П
В
С
Ч
П
С
В
пик 120/день · 6/7 активных дней
Динамика
Строк изменено / неделя
последние 8 нед.
86% Rust14% Config
Что построил flightofthefox

Транзакции оплачиваются по тому, к чему они прикасаются

flightofthefox встроил в выполнение стоимость чтения для каждого leaf, плату за формирование каждого event и цену сканирования — а также перенес таблицу цен на beacon. Теперь транзакции платят ровно за те ресурсы, которые потребляют.

→ смотрите «The Governor» на hyperscale.rs

Единый intent для объединения всего

Модель авторизации была объединена вокруг единого рекурсивного intent — каждая транзакция представляет собой один intent, который компонует другие, причем каждый подписывается и аннулируется независимо, что устраняет разбросанные типы маршрутизации.

→ смотрите «The Journey» на hyperscale.rs

Определены роли для восстановления аккаунта

Новые роли VM — основная, роль вето и второй фактор — позволяют аккаунту замораживаться, изменять гардианов или мгновенно ротироваться, и всем этим управляют on-chain правила, а не доверие.

→ смотрите «The System» на hyperscale.rs

Границы синхронизации и остановленные tip'ы

Синхронизация блоков перешла на полноценную машину состояний, а восстановление остановленных tip'ов перестроено: теперь сбор данных идет от проверенных таймаутов, а состав комитета проверяется перед commit.

→ смотрите «The Archive» на hyperscale.rs

Кросс-шардовый сеттлмент становится жестче

Окна provision теперь общие, а не зеркальные, дропнутые bundle удовлетворяют свои запросы, а неоцененные fee сеттлятся против того, чем владеет плательщик — что делает commit-путь более жестким.

→ смотрите «The Generals» на hyperscale.rs

Покинутые shard'ы уходят чисто

Правила завершения работы shard'ов стали строже: покинувшие сеть shard'ы уходят, когда их evidence-окно закрывается, завершенные цепочки перестают компоновать тики, а истекшие пулы ограничены.

→ смотрите «The Will» на hyperscale.rs
Ещё на этой неделе
  • Кошельки теперь могут запрашивать у ноды read-only preview того, что сделает транзакция перед ее отправкой.
  • Сплиты shard'ов теперь могут срабатывать автоматически, когда shard приближается к лимитам своей емкости.
  • Сетевая задержка оценивается по committed-цепочке и управляет таймерами раундов и таймаутами fetch.
  • Временные метки кворума теперь берутся как медиана показаний часов голосующих, что сглаживает аттестованные часы.
  • Симулированный византийский отправитель теперь может переписывать уведомления и gossip, что усиливает fault-инъекцию.
  • Стоимость хранения теперь взвешивается по реальным байтам, которые хранит validator.
  • Каждый shard аттестует свою долю эмиссии и верифицируется на каждом shard'е.
  • Сообщения теперь должны явно указывать свой класс, а не использовать значение по умолчанию, что улучшает сетевую приоритизацию.
Главное
Главное изменение
Система fee и ценообразования ресурсов была встроена от начала до конца — от стоимости чтения per-leaf до таблицы цен на beacon — крупнейший рывок к тому, чтобы транзакции платили сами за себя.
Что дальше
Вероятно дальше: продолжение встраивания fee-системы в жизненный цикл выполнения и доведение модели intent до feature-паритета с компонентной моделью Babylon.
Услышано в чате

Настроение: В сообществе шли жаркие дискуссии о будущем Hyperscale и его отношениях с Radix, включая длинное предложение от Wim о возможном перезапуске с финансированием. flightofthefox сохранял фокус на честных компромиссах.

blockchains can't be the best across every dimension simultaneously. you have to pick and choose your battles
— flightofthefox, в Telegram сообщества
flightofthefox объяснил
Ключевой компромисс Hyperscale
Финальность — это компромисс: всегда быстрее выполнять блоками, чем проходить через асинхронное выполнение для кросс-шардового взаимодействия. Если вам не нужен больше один shard, это строго ухудшение.
Кому стоит использовать Hyperscale
Нет вообще смысла использовать это, если у вас нет правдоподобной ситуации с сотнями тысяч или миллионами переходов состояний.
Долгосрочные планы
После стабилизации я займусь другими вещами и буду просто поддерживать это. Не могу вечно работать над open source, если сети не будут это спонсировать.
Позиционирование на рынке
Рынок транзакций, которые могут потерпеть несколько лишних секунд, больше, чем рынок sub-second finality — пока low-latency цепочки не исчерпают blockspace, преимущества shard'ов будут неочевидными.
Концепция недели
The GovernorГувернер, а не голосование
Основная работа велась над ценообразованием: чтение per-leaf, формирование per-event, стоимость сканирования и перенос таблицы цен на beacon — экономический слой, который заставляет каждую транзакцию платить сама за себя.
hyperscale.rs/governor
Жаргон — простыми словами
IntentПодписанная авторизация, которая указывает, к каким аккаунтам и состоянию обращается транзакция, теперь объединенная в единую рекурсивную структуру.
LeafЕдиничная запись данных в дереве состояний; единица, за чтение или запись которой взимает плату fee-система.
PreviewDry run в режиме чтения, который показывает кошельку, что сделала бы транзакция до ее отправки.
ProvisionКусок состояния, который один shard отправляет другому, верифицированный против committed-блока.
Куда легла работа
FSM синхронизации, восстановление остановленных tip'ов, provisions
vm/effects · The Governor
встроены ценообразование fee и бюджетирование ресурсов
модель intent и авторизация аккаунтов
vm/harness · The Crash Lab
fuzz-тесты и выравнивание CI-блобов
завершение работы shard'а и уход покинувших
Справка — карта концепций, дорожная карта и ссылки
Полная картина
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.
Путь к мейннету
✓ 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
Сейчас: Milestone 2 · Radix Engine — Неделя 7 · с августа 2026. С первого дня: 4 918 коммитов — один разработчик, полностью публично.
Ссылки
Написано ИИ по публичным коммитам, чату сообщества и hyperscale.rs — возможны ошибки. · создано 2026-09-21
Hyperscale Weekly — Неделя №19 · 14–20 сентября 2026