ДВИЖОК
Движок матчинга на безопасном по памяти Rust. Детерминированный повтор из WAL. Двойная запись с контрольным гейтом баланса на каждом батче. Аудит-цепь на blake3, которая заметно ломается при любом вмешательстве.
За каждым утверждением — готовый механизм. Никаких прилагательных без доказательств: доверие к движку и есть доверие к бирже.
01 · Детерминизм
Ордера и исполнения переживают сбой через WAL (fsync). Состояние повторяется, а не пересчитывается — при восстановлении сборка идёт бит-в-бит.
Механизм: fsync в WAL и детерминированный повтор с genesis.
02 · Сохранение
Двойная запись на TigerBeetle. Баланс проверяет гейт (кеш ↔ реестр в lockstep). 0 drift по построению.
Механизм: двойная запись и контрольные гейты баланса.
03 · Следы вмешательства
Хеш-цепь на blake3 с дозаписью в конец. Роли БД по минимуму привилегий. Экспорт hash-tip за пределы машины делает цепь проверяемой снаружи.
Механизм: blake3 с дозаписью в конец и аудит-БД с разделением ролей.
04 · Безопасность памяти
Движок на Rust. Однопоточный актор матчинга с низкой задержкой. Без сюрпризов stop-the-world, как у управляемых сред исполнения.
Механизм: Rust и однопоточное ядро матчинга.
05 · Инженерия риска
Кросс-маржа на едином счёте. Частичная ликвидация худших позиций в первую очередь. Модель поддерживающей маржи, страховой фонд и каскад ADL — всё на виду, ничего не спрятано.
Механизм: единая маржа и частичная ликвидация худших позиций первыми.
06 · Доступ по capability
RPC с аутентификацией по capability-модели. Никто не может прочитать чужой счёт. Комиссии проставляются на входе и закрепляются балансом через реестр.
Механизм: capability-токены с привязкой к счёту.
Все значения измерены на канареечном железе под синтетической длительной нагрузкой. Методология опубликована рядом с каждой цифрой — в этом и весь смысл.
Зачем детерминизм, что даёт WAL-before-ack, как обеспечивается 0 drift и откуда цифры.
Затем, что детерминированный движок можно повторить, а не просто ему верить. Состояние собирается повтором журнала WAL, а не пересчётом, поэтому восстановление ложится на бит-в-бит состояние каждый раз — и это как раз то, что делает аудит-цепь и контрольный гейт осмысленными. Недетерминированный движок нельзя вывести заново из его лога, а значит, его историю нельзя проверить независимо.
Каждый принятый ордер пишется в журнал WAL с fsync до того, как изменит хоть какое-то состояние или будет подтверждён, — лог это источник истины, а состояние движка это его детерминированный повтор. Запись до подтверждения и делает сбой переживаемым: не подтверждается ничего, что сперва не стало долговечным, поэтому восстановление собирает бит-в-бит состояние из лога.
Балансы двигаются только парами переводов по двойной записи, и контрольный гейт сверяет кеш с реестром шаг в шаг на каждой пачке. Если они расходятся, пачка обрывается, а не проходит. «0 drift» — это то самое свойство: знаковые балансы по активу всегда сходятся в ноль — обеспечивается гейтом непрерывно, как тест, а не заявляется как маркетинговый бенчмарк.
Все значения измерены на канареечном железе под синтетической длительной нагрузкой, на in-process matching path с одним инструментом, и методология опубликована рядом с каждой цифрой — order-ack показан как p50 и p99 вместе (5 µs / 9 µs), а не только выгодный. Синтетическая нагрузка выбрана намеренно: измеренный потолок стоит выше реального потока ордеров любой биржи, и он помечен как бенчмарк, а не боевой трафик.
Главная страница закрепляет один ордер, пока он идёт через движок — проверен, записан, сматчен, проведён, захеширован — и отдаёт доказательство на каждой стадии. Это тот же конвейер, что описывают эти механизмы, только виден целиком.