Ранее: flightofthefox только что переписал сетевой слой на базе iroh и добавил staking-пулам механизмы самостоятельного создания и передачи управления.
Спокойная, сосредоточенная неделя: все шестнадцать изменений попали в новый VM — движок, написанный с нуля, который позволяет смарт-контрактам работать между шардами. flightofthefox всю неделю укреплял то, как движок читает общее состояние и как сжигаются комиссии, а в чате главной темой стали последствия крупного взлома биржи.
16
-83% к прошлой неделе
коммитов
+1.9k −384
-84% к прошлой неделе
строк изменено
Коммиты / день
пик 7/день · 3/7 активных дней
Динамика
Строк изменено / неделя
последние 8 нед.
Что построил flightofthefox
Общее состояние под контролем
Большая часть недели ушла на правила чтения контрактом состояния, переданного из другого шарда: каждое чтение должно идти именно из того фрагмента, который был обслужен, и никогда — из устаревшего. Именно это делает идентичное исполнение — а значит, и атомарные кросс-шардовые платежи — возможным.
→ смотрите «The Generals» на hyperscale.rsКомиссии сжигаются, и это доказуемо
Теперь движок учитывает сжигание комиссий вместе с каждым изменением состояния, так что уничтоженные средства учитываются так же строго, как сами балансы. Это важно: деньги, исчезающие без следа, — именно то, чего аудитируемая сеть позволить себе не может.
→ смотрите «The Journey» на hyperscale.rsСлучайный выбор уважает часы
Новые правила привязывают выбор коммитов к seed случайности строго из более ранних эпох и фиксируют часы на уровне транзакции, а не блока. Это сохраняет назначения validator непредсказуемыми и честными — никто не может подсмотреть seed и лишь потом решать, как действовать.
→ смотрите «The Lottery» на hyperscale.rsГлавное
Главное изменение
Теперь новый VM гарантирует, что контракты могут читать только то кросс-шардовое состояние, которое было им доказано и обслужено.
Что дальше
Вероятно, дальше: продолжение укрепления VM вокруг чтений provisioned state и учёта комиссий, плюс намеченная оптимизированная сетевая архитектура.
Услышано в чате
Настроение: В чате доминировала тема взлома Binance и вопроса о том, должны ли validator сети Radix блокировать украденные кошельки; flightofthefox также провёл живой звонок в пятничных office hours.
“устойчивость к цензуре нельзя просто предполагать — над ней нужно работать”
— flightofthefox, в Telegram сообщества
flightofthefox объяснил
Validator суверенны
Он объяснил, что для блокировки определённых транзакций не нужно скоординированного голосования — каждый validator сам решает, за какие блоки голосовать, и напомнил им, что они суверенны.
Governance встроен в протокол
Он отметил, что у Hyperscale есть собственный governance и голосование, встроенные прямо в протокол, потому что любое DAO-голосование, не совпадающее 1:1 с реальными консенсусными полномочиями, бесполезно.
Пост-квантовость обязательна
На вопрос, будет ли Hyperscale устойчив к квантовым компьютерам, он ответил, что выпускать что-либо неквантостойкое просто не имеет смысла.
Пятничные office hours
Он организовал открытый голосовой звонок TGIF, куда мог зайти любой желающий поболтать о Hyperscale, Radix, крипте, софте или жизни в целом.
Концепция недели
The Generals— Два генерала отправили гонцов в отставкуОсновная часть работы укрепляет чтения движком provisioned state — это фундамент для побайтово-идентичного исполнения кросс-шардовых транзакций на каждом шарде.
hyperscale.rs/generals Жаргон — простыми словами
Fee burn — Комиссии за транзакции, которые безвозвратно уничтожаются, а не выплачиваются кому-либо.
Kernel — Доверенное ядро VM, через которое контракты обязаны проходить при любом чтении или записи состояния.
Provisioned state — Фрагмент состояния шарда, доставленный в другой шард вместе с доказательством, чтобы его можно было проверить, а не слепо доверять.
Куда легла работа
правила чтения обслуженного, доказанного состояния
сжигание комиссии учитывается вместе с изменениями состояния
vm/docs
документирование правил нового VM
Справка — карта концепций, дорожная карта и ссылки▾
Полная картина
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.
Четыре части
✓ готово
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
Полосы — доля изменённых строк за эту неделю. Общая базовая работа относится к Foundations & reliability. С первого дня: 5 733 коммитов — один разработчик, полностью публично.
Ссылки
Есть вопросы? flightofthefox всегда рад обсудить в Telegram сообщества.
Написано ИИ по публичным коммитам, чату сообщества и hyperscale.rs — возможны ошибки. · создано 2026-11-09