KERRIGAN: мультиалгоритмная Proof-of-Work криптовалюта с конфиденциальностью на основе доказательств с нулевым разглашением и консенсусом на основе печатей

Версия 1.0 | Март 2026

«Плести последовательности. Комбинировать. Улучшать. Никогда не идеально. Совершенство — цель, которая меняется.»

— Абатур, StarCraft II: Heart of the Swarm


Аннотация

◆

KERRIGAN — это мультиалгоритмная proof-of-work криптовалюта, объединяющая аппаратное разнообразие, конфиденциальность на основе доказательств с нулевым разглашением и новый уровень консенсуса на основе печатей, называемый Hivemind Protocol. Четыре алгоритма майнинга (X11, KawPoW, Equihash 200,9 и Equihash 192,7) работают одновременно с генезис-блока, каждый с независимой корректировкой сложности, основанной на мультиалгоритмном подходе DigiByte. Экранированные транзакции Sapling на базе zk-SNARK предоставляют пользователям возможность полной конфиденциальности транзакций. Hivemind Protocol добавляет второе измерение консенсуса поверх PoW, где майнеры коллективно заверяют блоки с помощью BLS-подписей и верифицируемого случайного выбора комитета. V1 запускается как блокчейн, ориентированный на майнинг, с мастернодами и ончейн-управлением. V2 расширяет сеть до GPU-вычислений для ИИ-инференса, перенаправляя вознаграждения за блок на стимулирование провайдеров инференса наряду с майнерами.


1. Введение

◆

Большинство блокчейнов на основе proof-of-work зависят от одного алгоритма майнинга. Это создаёт хрупкую сеть, в которой один производитель оборудования или одна конструкция ASIC может доминировать в хешрейте, а единственная алгоритмическая уязвимость способна скомпрометировать всю цепочку. SHA-256 Bitcoin майнится почти исключительно специализированными ASIC. Ethash Ethereum Classic неоднократно подвергался атакам 51% после миграции GPU-майнеров на proof-of-stake Ethereum. Одноалгоритмные цепочки концентрируют риск.

Конфиденциальность — другой пробел. Прозрачные PoW-цепочки раскрывают каждую транзакцию для публичного анализа. Аналитические компании могут отслеживать средства по переходам, связывать адреса с личностями и составлять полные финансовые профили. Некоторые блокчейны добавляют опциональную конфиденциальность как надстройку; другие полностью жертвуют прозрачностью. Ни одна из крайностей не служит пользователям хорошо.

KERRIGAN решает обе проблемы. Четыре алгоритма майнинга гарантируют, что ни один класс оборудования не сможет монополизировать производство блоков. ASIC-майнеры конкурируют на X11, в то время как GPU-майнеры распределяются между KawPoW, Equihash 200,9 и Equihash 192,7. Каждый алгоритм имеет собственную корректировку сложности, поэтому перемещение хешрейта между алгоритмами не дестабилизирует сеть. Экранированные транзакции Sapling на базе zk-SNARK обеспечивают криптографическую конфиденциальность для пользователей, которые этого хотят, не убирая прозрачный уровень транзакций.

Блокчейн построен на основе форка Dash, наследуя детерминированный список мастернод (DIP3), сервисы на основе кворумов (LLMQ) и систему спорков для безопасной активации функций. Мы убрали то, что нам не нужно, заменили то, что не подходило, и создали новые системы там, где унаследованный код оказался недостаточным. Мультиалгоритмный PoW-движок, интеграция Sapling и Hivemind Protocol — всё это оригинальные разработки KERRIGAN.


2. Мультиалгоритмный Proof of Work

◆

KERRIGAN параллельно использует четыре алгоритма майнинга, все активны с генезис-блока. Каждый блок добывается ровно одним алгоритмом, и алгоритм кодируется непосредственно в поле версии блока.

2.1 Алгоритмы

X11 — это нативная хеш-функция Dash: одиннадцать последовательно связанных криптографических функций (BLAKE, BMW, Groestl, JH, Keccak, Skein, Luffa, CubeHash, SHAvite, SIMD, ECHO). Она поддаётся майнингу на ASIC, что означает, что хешрейт X11, вероятно, будет доминироваться специализированным оборудованием. Это сделано намеренно. ASIC обеспечивают стабильное высокопроизводительное хеширование, которое стабилизирует базовый уровень.

KawPoW — это вариант ProgPoW от Ravencoin, алгоритм, оптимизированный для GPU, который сопротивляется разработке ASIC через генерацию случайных программ. Реализация KawPoW в KERRIGAN совместима на уровне протокола с Ravencoin, что означает, что существующие RVN-майнеры могут направить свои установки на пулы KERRIGAN с минимальной конфигурацией. Блоки KawPoW несут дополнительные поля заголовка: nHeight, nNonce64 (8-байтовый нонс) и mix_hash (32 байта).

Equihash 200,9 — это требовательный к памяти алгоритм Zcash. Параметры (200,9) требуют примерно 700 МБ рабочей памяти на попытку нахождения решения. ASIC для Equihash 200,9 существуют (в частности, серия Bitmain Z9), поэтому эта линия не является строго «только для GPU». KERRIGAN использует совместимый с Zcash 140-байтный формат заголовка: 108 байт из CEquihashInput (версия, предыдущий хеш, корень Меркла, зарезервированный хеш, время, биты) плюс 32-байтовый nNonce256. Решения сериализуются с ограничением в 1400 байт.

Equihash 192,7 использует другие параметры, которые снижают требования к памяти по сравнению с (200,9), сохраняя при этом устойчивость к ASIC. Набор параметров (192,7) был популяризирован ZClassic и другими форками Equihash. Тот же формат заголовка, что и у Equihash 200,9, но с собственным пространством решений и кривой сложности.

2.2 Кодирование версии

Алгоритм майнинга кодируется в битах с 8-го по 11-й поля nVersion блока с использованием маски 0x0F00:

АлгоритмВнутренний EnumБиты версииHex
X11ALGO_X11 = 00 << 80x0000
KawPoWALGO_KAWPOW = 12 << 80x0200
Equihash 200,9ALGO_EQUIHASH_200 = 24 << 80x0400
Equihash 192,7ALGO_EQUIHASH_192 = 36 << 80x0600

Внутренние значения enum (0-3) используются в коде для индексации массивов. Биты версии используют равномерное расположение (0, 2, 4, 6), чтобы оставить место для будущих алгоритмов. Соответствие между ними — это таблица поиска, а не прямой битовый сдвиг значения enum.

Любой код, проверяющий nVersion для сигнализации софт-форков BIP9, должен сначала очистить биты 8-11. WarningBitsConditionChecker пропускает эти биты, чтобы избежать ложных предупреждений.

2.3 Хеширование

KERRIGAN использует два различных хеша для каждого блока: идентификационный хеш для индексации и хеш proof-of-work для валидации майнинга.

Идентификационный хеш — это X11, вычисленный по базовому заголовку блока. Для блоков X11 и KawPoW это стандартный 80-байтный заголовок (версия, предыдущий хеш, корень Меркла, время, биты, нонс). Для блоков Equihash — 140 байт (версия, предыдущий хеш, корень Меркла, hashReserved, время, биты, nNonce256). Именно на него ссылается hashPrevBlock, именно его возвращают RPC и использует индекс цепочки. X11 применяется для идентификационного хеширования на всех алгоритмах, чтобы каждый узел индексировал каждый блок одинаково.

Хеш proof-of-work зависит от алгоритма и фиксирует все поля, критические для консенсуса данного алгоритма:

Эта двухуровневая система хеширования означает: идентификационный хеш обеспечивает стабильный, единообразный идентификатор блока для всех алгоритмов, в то время как PoW-хеш гарантирует, что специфичные для алгоритма поля (решения, mix-хеши, расширенные нонсы) полностью зафиксированы и защищены от подделки. См. Приложение A для точных сериализованных байтовых раскладок по алгоритмам.

2.4 Hivemind-сложность

Каждый алгоритм имеет собственную независимую сложность, корректируемую по схеме, основанной на мультиалгоритмной сложности DigiByte (DigiShield v4). Параметры:

Эта поалгоритмная сложность означает, что внезапный приток GPU-майнеров на KawPoW не повлияет на сложность X11 или Equihash. Каждый алгоритм находит своё равновесие независимо.


3. Токеномика

◆

3.1 Эмиссия

Эмиссия следует стандартному графику халвинга: 25 KRGN за первые 1 051 200 блоков, затем 12,5, затем 6,25 и так далее. Геометрический ряд сходится к 52 560 000 KRGN в сумме.

3.2 Распределение вознаграждений за блок (V1)

Coinbase-транзакция каждого блока делит вознаграждение в 25 KRGN на пять частей:

ПолучательДоляKRGN/блокХранениеНазначение
Фонд роста40%10,00Консенсусно-заблокированный эскроуЛистинги на биржах, партнёрства, развитие экосистемы
Майнеры20%5,00Немедленный доступВознаграждение за PoW-блок
Мастерноды20%5,00Немедленный доступСетевые сервисы (переходит майнеру, если мастерноды не зарегистрированы)
Казначейство15%3,75Мультиподпись 2-из-3Операционные расходы, маркетинг, сообщество, зарплаты команды
Разработчики / Основатели5%1,25Немедленный доступКомпенсация основателям и текущая приверженность проекту

Фонд роста — это не казначейство. Это консенсусно-заблокированный эскроу, из которого команда не может тратить средства без одобрения мастернод (см. раздел 3.4). Аллокации на казначейство и разработчиков/основателей (20% в совокупности) — это операционный бюджет проекта, сопоставимый с историческим 20%-ным фондом разработки Zcash. Адрес казначейства — это мультиподписной кошелёк P2SH 2-из-3, требующий двух из трёх держателей ключей для авторизации любого расхода. Если в сети не зарегистрировано мастернод, 20%-ная доля мастернод остаётся у майнера как механизм мягкой деградации.

3.3 Почему 40% на эскроу роста

KERRIGAN не имеет поддержки венчурных фондов, ICO, премайна и продажи токенов. Оборудование оплачивается из собственного кармана. Код написан командой. Нет резервного фонда в $5M на мультиподписи от раунда посевного финансирования.

Это означает, что сеть должна финансировать собственный рост. Листинги на биржах, обеспечение ликвидности, развёртывание мостов и партнёрские сделки стоят реальных денег, и без внешнего финансирования сама цепочка — единственный источник. Эскроу роста — это механизм, превращающий добытые монеты в торгуемый актив. Отсутствие листинга на бирже означает отсутствие ликвидности. Отсутствие ликвидности означает, что монеты, которые зарабатывают майнеры, бесполезны.

Эскроу роста накапливает 10 KRGN за блок:

Вот как это выглядит при разных ценах KRGN, при условии типичного листинга на бирже второго уровня за $150 000 и листинга третьего уровня за $30 000:

Цена KRGNЭскроу / месяцСрок до листинга 3-го уровня ($30K)Срок до листинга 2-го уровня ($150K)
$0,01$2 160~14 месяцев~69 месяцев
$0,05$10 800~3 месяца~14 месяцев
$0,10$21 600~6 недель~7 месяцев
$0,50$108 000~8 дней~6 недель
$1,00$216 000~4 дня~3 недели

Даже при цене $0,05 за KRGN эскроу может профинансировать листинг на бирже третьего уровня в течение одного квартала. При $0,10 листинг второго уровня становится достижимым в течение первого года.

Эскроу является временным. У него есть жёсткий потолок на блоке 262 800 (~12 месяцев). Каждая монета в нём заблокирована с момента создания. Ни одна монета не покидает эскроу без голосования мастернод, одобряющего конкретный расход. Майнеры, финансирующие ранний рост, получают вознаграждение в виде работающей экосистемы и монеты, которая торгуется на реальных биржах.

3.4 Эскроу роста: заблокирован до голосования

40%-ная аллокация фонда роста создаётся каждый блок и отправляется на консенсусно-заблокированный адрес эскроу. Монеты существуют в цепочке, учитываются в общей эмиссии и полностью проверяемы, но их нельзя потратить. Ни один подписант мультиподписи, ни один член команды, ни одна отдельная сущность не может их переместить. Расходование требует одобрения сетью мастернод конкретного предложения.

Как это работает:

  1. Каждый блок 10 KRGN отправляются на адрес эскроу роста. Монеты создаются по обычному графику эмиссии (с сохранением жёсткого лимита в 52 560 000 KRGN).
  2. Предложения о расходовании подаются в систему управления с описанием конкретного расхода: сумма, адрес получателя и назначение (например, «Высвободить 50 000 KRGN на [адрес] для листинга на бирже третьего уровня»).
  3. Операторы мастернод голосуют, используя свои зарегистрированные ключи голосования через gobject vote-many. Применяется стандартный порог управления: предложение проходит, если ДА - НЕТ >= max(10, взвешенное_количество_мастернод / 10).
  4. Если предложение проходит, указанная сумма разблокируется из эскроу для этого конкретного расхода. Если оно не проходит, монеты остаются заблокированными.
  5. Монеты, оставшиеся заблокированными на блоке 262 800 (~12 месяцев), сжигаются через OP_RETURN. Это правило консенсуса, а не решение управления.

Голосование о продлении: Каждый цикл суперблока (16 616 блоков, примерно 23 дня) продолжение накопления эскроу также должно быть подтверждено голосованием мастернод. Если голосование о продлении не проходит, 40%-ный coinbase-выход сжигается в следующем цикле вместо поступления в эскроу. Нет голосования — нет накопления. Безразличие убивает фонд, а не действие.

Почему такая конструкция:

Что происходит при завершении: Когда эскроу роста прекращает работу (из-за не прошедшего голосования о продлении или жёсткого потолка на блоке 262 800), оставшиеся заблокированные монеты сжигаются через OP_RETURN. 40%-ная coinbase-аллокация сжигается для всех последующих блоков. Она не перенаправляется майнерам, мастернодам или кому-либо ещё. Сожжённые монеты уменьшают обращающуюся эмиссию, принося пользу всем держателям в равной степени. Реструктуризация вознаграждений V2 (раздел 3.6) — это отдельное обновление консенсуса, перенаправляющее 40% провайдерам ИИ-инференса.

3.5 Операционный бюджет: казначейство и разработчики/основатели

Оставшиеся 20% вознаграждений за блок (казначейство 15% + разработчики/основатели 5%) — это операционный бюджет проекта. Эти монеты выпускаются в обычном порядке, без блокировки в эскроу.

Казначейство (15% / 3,75 KRGN за блок): Операционные расходы, обеспечивающие работу проекта. Маркетинг, управление сообществом, вознаграждение модераторов, серверные расходы, эирдропы, розыгрыши и партнёрские расходы. Адрес казначейства — это мультиподписной кошелёк P2SH 2-из-3, требующий двух из трёх держателей ключей для авторизации любого расхода.

Разработчики / Основатели (5% / 1,25 KRGN за блок): Компенсация за создание KERRIGAN с нуля и постоянная приверженность поддержке и развитию протокола. Выпускается без блокировки.

Этот 20%-ный операционный бюджет сопоставим с историческим 20%-ным фондом разработки Zcash. Разница: ростовой капитал KERRIGAN (остальные 40%) находится в консенсусно-заблокированном эскроу, к которому команда не может получить доступ без одобрения сети. Только 20% доступны для свободного расходования.

Подотчётность операционного бюджета:

3.6 Распределение вознаграждений за блок V2 (будущее)

V2 реструктурирует вознаграждение за блок вокруг сети ИИ-инференса. GPU-операторы получают доход за каждый запрос инференса поверх своей доли вознаграждения за блок, делая оборудование для майнинга KERRIGAN продуктивным между блоками:

ПолучательДоля V1Доля V2Примечания
ИИ GPU-инференс0%40%Поверх дохода от оплаты за каждый инференс
Майнинг20%20%Без изменений
Мастерноды20%20%Без изменений
Казначейство15%15%Без изменений
Разработчики / Основатели5%5%Без изменений
Фонд роста40%0%Выполнил своё назначение

Фонд роста обнуляется, когда экосистема сформирована. 40%, которые финансировали ранние листинги на биржах и партнёрства, перенаправляются участникам ИИ GPU-инференса, превращая KERRIGAN в цепочку двойного назначения: майнинг обеспечивает безопасность сети, а GPU-вычисления обслуживают ИИ-нагрузки. 40%-ная аллокация на инференс накладывается поверх прямых комиссий за каждый инференс, предоставляя GPU-операторам два источника дохода от одного и того же оборудования.


4. Экранированные транзакции Sapling

◆

KERRIGAN интегрирует протокол Sapling от Zcash для экранированных транзакций с нулевым разглашением. Пользователи могут перемещать средства между прозрачными адресами (начинающимися с «K») и экранированными адресами, используя доказательства Groth16 zk-SNARK, которые не раскрывают ничего об отправителе, получателе или сумме.

4.1 Структура транзакции

Экранированные транзакции используют nType = 10 (TRANSACTION_SAPLING). Дополнительная полезная нагрузка содержит:

Максимум — 500 описаний расходов и 500 описаний выходов на транзакцию. Rust-билдер Sapling дополняет пакеты выходов до минимума в 2 выхода (добавляя фиктивные выходы при необходимости), чтобы предотвратить анализ графа транзакций на основе количества выходов.

4.2 Криптографическая основа

Схема Sapling работает на эллиптической кривой Jubjub, вложенной в BLS12-381. Доказательства генерируются и проверяются через Rust FFI-мост с использованием крейтов bellman, jubjub и group, скомпилированных через CXX в C++ узел.

Ключевые примитивы:

Фронтир дерева Меркла (минимальные данные, необходимые для добавления новых листьев) хранится для каждого блока в LevelDB. Свидетели на стороне кошелька отслеживают путь аутентификации каждой заметки для доказательств расходования.

Доверенная настройка: KERRIGAN повторно использует параметры Sapling от Zcash (ключи доказательства и верификации, сгенерированные церемонией Zcash Powers of Tau и Sapling MPC). Схемы идентичны Zcash Sapling. Новая церемония доверенной настройки для экранированных транзакций не требуется.

4.3 Подписание

Подписание транзакций следует схеме sighash в стиле ZIP 243. Прообраз sighash включает hashPrevouts, hashSequence и hashOutputs, покрывающие как прозрачные, так и экранированные компоненты. Это предотвращает изменяемость подписи и обеспечивает криптографическую связку прозрачной и экранированной частей транзакции.

4.4 Структура комиссий

Экранированные транзакции используют модель комиссий на основе действий:

4.5 Активация и RPC

Sapling активируется на блоке 500 основной сети, примерно через 16 часов после генезиса. Девять RPC-вызовов обеспечивают полную функциональность кошелька:

RPCФункция
z_getnewaddressГенерация нового экранированного адреса
z_listaddressesСписок всех экранированных адресов в кошельке
z_getbalanceПолучение экранированного баланса для адреса
z_listunspentСписок неизрасходованных экранированных заметок
z_sendmanyОтправка на/с экранированных адресов (t-to-z, z-to-z, z-to-t)
z_exportkeyЭкспорт экранированного ключа расходования
z_importkeyИмпорт экранированного ключа расходования
z_exportviewingkeyЭкспорт полного ключа просмотра Sapling
z_importviewingkeyИмпорт полного ключа просмотра Sapling

5. Мастерноды и управление

◆

5.1 Типы мастернод

KERRIGAN поддерживает два уровня мастернод, унаследованных от фреймворка Dash Evolution:

ТипЗалогВес голоса
Обычная10 000 KRGN1x
Evo (HPMN)40 000 KRGN4x

Мастерноды регистрируются в блокчейне с использованием детерминированных регистрационных транзакций DIP3:

Детерминированный список мастернод полностью выводится из ончейн-транзакций. Каждый узел вычисляет один и тот же список из одного и того же состояния цепочки, устраняя разногласия в консенсусе, которые мучили недетерминированные системы мастернод.

5.2 Кворумные сервисы

Долгоживущие кворумы мастернод (LLMQ) обеспечивают два ключевых сервиса:

InstantSend блокирует входы транзакций в течение секунд, предотвращая попытки двойного расходования. Кворум мастернод подписывает сообщение о блокировке, и любая конфликтующая транзакция отклоняется сетью.

ChainLocks финализируют блоки путём подписания кворумом первого блока, увиденного на каждой высоте. После распространения подписи ChainLock блок не может быть реорганизован, даже атакующим с 51%.

Оба сервиса управляются через спорки и отключены при генезисе. LLMQ требует минимального количества зарегистрированных мастернод для формирования кворумов, поэтому эти функции активируются через спорк, когда набор мастернод достигает критической массы:

5.3 Управление

Операторы мастернод могут подавать бюджетные предложения и голосовать по ним. Предложения проходят, если ДА - НЕТ >= max(10, взвешенное_количество_мастернод / 10). Система управления обрабатывает предложения сообщества, маркетинговые инициативы и финансирование инфраструктуры. Она также контролирует голосование о продлении фонда роста (раздел 3.4): 40%-ная аллокация фонда роста должна активно подтверждаться голосованием мастернод каждый цикл суперблока (~23 дня), иначе она автоматически сжигается.


6. Hivemind Protocol (HMP)

◆

6.1 Основная идея

В настоящей пчелиной колонии каждый член несёт химические маркеры, идентифицирующие его как часть улья. Ни одна пчела не производит запах колонии. Он возникает из коллектива. Hivemind Protocol работает так же: майнинг-пулы коллективно создают криптографический «феромон», который вплетается в каждый блок. Как смешивание красок: синяя, жёлтая и красная заливаются внутрь, получается определённый оттенок коричневого. Вы можете проверить, что коричневый правильный. Вы не можете разделить его, чтобы извлечь отдельные цвета. Но если кто-то попытается сделать этот коричневый без синего — это будет неправильный оттенок. Мгновенно обнаруживаемый.

HMP находится поверх proof-of-work. PoW определяет, кто добывает блок. HMP определяет, ручаются ли активные майнеры сети за этот блок. Атакующий, который создаёт форк цепочки в тайне, не может принести с собой феромон колонии, потому что честные майнеры никогда не участвовали в форке. Атакующая цепочка пахнет неправильно.

6.2 Совместимость с программным обеспечением пулов

Критическое требование к дизайну: никаких изменений в программном обеспечении для майнинга. HMP полностью работает внутри демона. Пульное программное обеспечение (s-nomp, Miningcore или любой Stratum-совместимый стек) взаимодействует с демоном через стандартные RPC getblocktemplate и submitblock. Демон обрабатывает управление идентичностью, подписание печатей, сборку печатей, рассылку обязательств и P2P-ретрансляцию внутренне. Шаблоны блоков уже включают встроенные данные печати HMP в coinbase-транзакцию — тот же паттерн, что используют BIP34 (высота в coinbase), SegWit (корень свидетеля в coinbase) и merge mining (AuxPoW в coinbase). Майнеры хешируют шаблон вслепую. Протокол Stratum не изменяется.

6.3 Идентичность и привилегии

Каждый демон генерирует постоянную BLS-пару ключей при первом запуске (хранится как hmp_identity.dat). Эта идентичность загружается автоматически при запуске. По мере того как демон добывает блоки и участвует в заверении, он накапливает запись привилегий:

УровеньТребованияВозможности
UNKNOWNНет истории или в 10-блочном прогревеНе может участвовать в заверении
NEWЗавершил прогрев, участвуетМожет заверять со стандартным весом
ELDERДобыл 10+ блоков И участие в заверении в окне 100 блоковПолный вес, право на кросс-алгоритмный бонус

Окно привилегий составляет 100 блоков. Майнер, прекращающий участие, возвращается к уровню UNKNOWN после выхода из окна. Привилегия требует реальной работы: вы не можете стать ELDER, не добыв фактически блоки, что превращает любую Sybil-атаку в дорогостоящую честную операцию майнинга.

6.4 Перекличка (Фаза 1: обязательства по открытым ключам)

Перед заверением демон должен зафиксировать свой публичный BLS-ключ в цепочке. Считайте это листком посещаемости. Каждый демон, желающий участвовать, рассылает свой публичный ключ. Эти ключи попадают в цепочку двумя способами: неявно (путём добычи блока, который встраивает публичный ключ майнера в поле minerIdentity CCbTx v4) или явно (до 16 дополнительных обязательств по публичным ключам на блок в поле vCommitments CCbTx v5).

Зафиксированный ключ должен «вызреть» 10 блоков, прежде чем подписант станет допущенным. Это штраф за прогрев. Если сервис переключения прибыли вроде NiceHash работает циклами короче прогрева (~20 минут), эти майнеры никогда не вносят вклад в феромон. Они майнят, получают вознаграждения, уходят. Нулевое влияние на идентичность колонии.

Если зафиксированный ключ остаётся достаточно долго, чтобы заработать привилегию, он становится одним равноправным голосом в колонии. Когда он уходит, один голос исчезает. Запах колонии едва меняется.

6.5 Заверение (Фаза 2: производство феромона)

Когда поступает новый блок, демон автоматически проверяет допуск, вычисляет VRF-доказательство, подписывает хеш блока своим BLS-ключом и рассылает долю печати в сеть. Это происходит в ConnectBlock без участия пула.

Каждая доля печати содержит:

Что утверждает zk-доказательство:

Подписант знал состояние публичной цепочки на недавней высоте, обязательство было сгенерировано после наблюдения этого состояния (предотвращает предвычисление), и ключевой материал свежий для этого раунда (предотвращает повтор).

Что скрывает zk-доказательство:

Конкретный хешрейт подписанта, точное время его наблюдений и приватный ключевой материал, используемый в обязательстве. Обратите внимание, что доли печати включают публичный ключ подписанта (псевдонимная идентичность видна для отслеживания привилегий), но zk-доказательство гарантирует, что операционные детали и ключевой материал остаются приватными.

Почему это важно для атак:

Атакующий, добывающий секретный форк, не может создать валидные доказательства, потому что он не наблюдал публичную цепочку в требуемые моменты. Входные данные доказательства ссылаются на энтропию, полученную из состояния публичной цепочки, которое существует только в честной цепочке. Доказательства привязаны к конкретным хешам блоков, поэтому они не могут быть перенесены между цепочками.

Доли печати распространяются через P2P-сообщения SEALSHARE. После 5-секундного окна подписания демон собирает полученные доли в CAssembledSeal с агрегированной BLS-подписью. Печать для блока N встраивается в coinbase блока N+2, давая сети время на сбор долей без остановки производства блоков. Майнинг никогда не ждёт подписей.

Настройка для доказательств HMP: схема обязательств MiMC использует Groth16 на BLS12-381. Схема намеренно компактна (время доказательства <2 с на обычном оборудовании, время верификации <50 мс, размер доказательства <256 байт). Ключи доказательства и верификации генерируются через церемонию многосторонних вычислений. Предположение безопасности стандартно для Groth16: настройка безопасна, если хотя бы один участник церемонии был честен и уничтожил свой «токсичный отход». Транскрипты церемонии и хеши параметров публикуются для верификации.

6.6 Выбор цепочки

HMP модифицирует выбор цепочки, добавляя бонус печати к стандартному кумулятивному PoW:

chain_weight = sum( block_pow_work + seal_bonus(block) ) for all blocks in chain

Для каждого блока множитель печати вычисляется как значение в базисных пунктах, применяемое к block_pow_work:

weighted_proof = block_pow_work * seal_multiplier / 10000 seal_multiplier: No seal or below threshold: 10000 bps (1.0x, neutral) Partial shade (>= threshold): 12000-15000 bps (interpolated by Elder ratio) Full shade (all Elders signed): 15000-18000 bps (interpolated by Elder ratio) Cross-algo bonus: +500 bps per additional ELDER algo domain (max +1500) Maximum possible: 19500 bps (1.95x)

Множитель печати использует градуированную систему уровней. Только подписи уровня ELDER, чей algoId совпадает с алгоритмом майнинга блока, учитываются при определении полноты одноалгоритмного покрытия. Внутри каждого уровня множитель интерполируется линейно на основе отношения присутствующих ELDER к общему числу ELDER для данного алгоритма. Кросс-алгоритмный бонус добавляет фиксированные +500 базисных пунктов за каждый дополнительный домен алгоритма ELDER (помимо собственного алгоритма блока), с ограничением в +1500 бп (все 4 алгоритма представлены). Полностью заверенный блок со всеми 4 алгоритмными доменами достигает 1,95x от своей PoW-работы. Незаверенный блок стоит 1,0x. На протяжении сотен блоков цепочка с последовательно полными феромонами накапливает значительно больший вес, чем цепочка со слабыми или отсутствующими феромонами, даже если сырой PoW эквивалентен.

Требуемое согласие подписантов масштабируется с поалгоритмным количеством ELDER:

ELDER (на алгоритм)Требуемое согласиеОбоснование
6+80%Полная безопасность, поглощает индивидуальные сбои
4-575%Сильная, немного более терпимая
366% (2 из 3)Деградированная, но функциональная
2100% (оба)Максимальная осторожность
0-1Н/Д, режим чистого PoWКолония ещё не сформирована

Это означает, что сеть стартует в режиме чистого PoW и органически переходит к консенсусу, защищённому HMP, по мере роста майнинговой колонии. Безопасность возникает из участия, а не из флага назначенного дня.

6.7 VRF-выбор комитета (уровень ретрансляции)

Не каждый зарегистрированный подписант участвует в каждом заверении. BLS-VRF (верифицируемая случайная функция) определяет, чьи доли печати ретранслируются по P2P-сети. Хеш предыдущего блока служит сидом VRF. Каждый допущенный демон запускает VRF со своим долгосрочным ключом. Выбор детерминирован (все узлы могут проверить, кто был допущен), но непредсказуем (зависит от хешей блоков, которые никто не может предсказать заранее).

В V1 VRF — это фильтр уровня ретрансляции, а не правило консенсуса. Узлы отбрасывают доли печати от подписантов, не прошедших проверку допуска VRF, снижая сетевую полосу и затрудняя атакующему перебор или заполнение пула долей. Скоринг выбора цепочки учитывает все валидные BLS-подписи в собранной печати независимо от статуса VRF (см. Приложение A.4). Будущие обновления протокола могут повысить допуск VRF до проверки валидности печати на уровне консенсуса.

6.8 Перехват доминирования

Пул считается привилегированным, если он добыл блок за последние 100 блоков, ИЛИ если он входит в число последних 6 уникальных пулов, добывших блок на данном алгоритме, — используется больший из двух просмотров. Это означает, что привилегированный набор на любом алгоритме никогда не может сократиться менее чем до 6 (при условии, что 6 различных пулов когда-либо майнили на этом алгоритме).

Если крупный пул с переключением прибыли добывает 100 подряд KawPoW-блоков, 5 других пулов, которые последними добыли KawPoW-блоки перед этой серией, по-прежнему считаются привилегированными. Их голоса остаются в колонии. Расширенный просмотр ограничен 1000 блоками (~33 часа). За этим пределом участие считается слишком устаревшим.

6.9 Почему бы не использовать только ChainLocks?

KERRIGAN наследует систему ChainLock от Dash (финализация блоков на основе LLMQ мастернодами), и она будет активирована через спорк, когда будет зарегистрировано достаточно мастернод. Но ChainLocks требует функционирующего кворума мастернод, на формирование которого нужно время после генезиса. HMP заполняет пробел: он обеспечивает устойчивость к реорганизации с первого дня, используя майнеров, которые уже есть в сети. По мере роста набора мастернод ChainLocks наслаивается поверх HMP для дополнительной финальности. Они дополняют друг друга.

6.10 Мультиплекс из четырёх залов

Вы в кинотеатре. Вы уходите посреди фильма за попкорном. На выходе вы замечаете парня в красной рубашке у двери, пожилую пару в третьем ряду, группу подростков впереди. Вы получаете попкорн, возвращаетесь, и сразу что-то не так. Красная рубашка исчезла. Пожилая пара переместилась. Подростки пропали. Ни одно лицо не совпадает. Вы в неправильном зале. Вам не нужно было, чтобы кто-то сказал — вы просто заметили, что людей, которых вы ожидали, здесь нет.

Именно так HMP обнаруживает атакующую цепочку. Сеть знает, какие майнеры постоянно присутствовали — добывали блоки, участвовали в заверениях, зарабатывали статус ELDER. Когда появляется конкурирующая цепочка, протокол проверяет, присутствуют ли эти знакомые лица. Если завсегдатаи отсутствуют, цепочка пахнет неправильно. Никакого кросс-цепочечного сравнения не нужно. Вы просто зашли не в тот зал.

Теперь масштабируем до четырёх залов. KERRIGAN не показывает один сеанс — он запускает мультиплекс из четырёх залов. X11, KawPoW, Equihash 200,9 и Equihash 192,7 — у каждого свой зал со своими завсегдатаями. Пул X11 зарабатывает репутацию в зале X11. Пул KawPoW — в зале KawPoW. Это совершенно независимые сообщества с совершенно разным оборудованием.

Блок сильнее всего, когда завсегдатаи из нескольких залов ручаются за него. Блок KawPoW, одобренный только завсегдатаями KawPoW, получает частичный бонус. Добавьте подписи завсегдатаев X11, Equihash 200,9 и Equihash 192,7, и блок получит кросс-алгоритмный бонус (раздел 6.6), до 1,95x от его сырого PoW-веса. Атакующему нужно заполнить все четыре зала убедительными лицами одновременно — четыре независимые толпы, четыре независимые аппаратные экосистемы, четыре независимые истории честного майнинга, подделанные разом.

6.11 Как на самом деле выглядит атака 51%

Рассмотрим максимально изощрённого атакующего: неограниченный бюджет, техническая экспертиза, терпение.

  1. Приобрести хешрейт по всем 4 алгоритмам. Разное оборудование для каждого. Четыре независимые задачи закупки.
  2. Пережить 10-блочный период прогрева. Видим на публичной сети всё это время.
  3. Зафиксировать публичные ключи в публичной цепочке. Создаёт постоянную запись их существования.
  4. Заработать привилегию ELDER на всех 4 алгоритмах. Должен добывать блоки И участвовать в заверении в пределах окна просмотра, по каждому алгоритму. Честный майнинг всё это время.
  5. Начать майнинг секретного форка. Именно здесь всё разваливается:
    • Честные пулы никогда не фиксировались в форке. Их публичные ключи Фазы 1 были зафиксированы в публичной цепочке. У форка нет их листка посещаемости.
    • Честные пулы никогда не добавляли свою краску. Блоки атакующего лишены большинства подписей ELDER колонии. Феромон неполный.
    • Печати атакующего могут содержать только его собственные подписи ELDER. С отсутствующими честными ELDER, коэффициент полноты низкий и бонус печати минимален.
    • Кросс-алгоритмный бонус требует подписей уровня ELDER от 2+ доменов алгоритмов. Атакующий, контролирующий только одну аппаратную экосистему, не получает кросс-алгоритмного веса.
    • На уровне ретрансляции фильтрация VRF и проверки zk-доказательств затрудняют атакующему сбор или повтор долей печати из честной сети.
  6. Транслировать атакующую цепочку. Честная цепочка имеет больший суммарный вес (полные печати ELDER с кросс-алгоритмными бонусами). Атакующая цепочка имеет меньший вес (неполные печати, отсутствующие подписи ELDER). Узлы следуют за более тяжёлой цепочкой.

Уровни защиты не являются независимыми препятствиями. Они взаимно усиливают друг друга. Вы не можете заработать привилегию без честного майнинга, который укрепляет цепочку, на которую вы пытаетесь напасть. Вы не можете произвести валидный феромон на секретном форке, потому что честные пулы никогда не добавляли свою краску. Атакующий не сталкивается с семью проблемами. Он сталкивается с одной невозможной проблемой, рассмотренной с семи сторон: можно ли быть одновременно изолированным и совместно действующим?

6.12 Риски цензуры и картелей

HMP — это механизм координации, а механизмы координации могут быть злоупотреблены. Картель подписантов ELDER, контролирующий достаточно привилегий для заполнения expected_signers, мог бы избирательно удерживать печати от блоков, добытых целевыми пулами. Блоки целевого пула накапливали бы меньший вес цепочки (более низкий коэффициент полноты), что делало бы их более склонными к проигрышу в гонках реорганизации против заверенных блоков.

Несколько факторов ограничивают эту поверхность атаки:

Честная оценка: HMP значительно увеличивает стоимость атак 51%, но вводит поверхность координации, которой нет в чистом PoW. Достаточно крупный картель модифицированных демонов мог бы использовать удержание печатей как инструмент мягкой цензуры. Описанные выше меры делают это дорогим и обнаруживаемым, но не невозможным. Этот компромисс сделан намеренно. Альтернатива (чистый PoW без HMP) строго более уязвима к более простой и дешёвой атаке аренды хешрейта.

6.13 Активация

HMP активируется поэтапно в основной сети:

ЭтапВысотаОписание
Этап 2Блок 100Открытие обязательств по публичным ключам
Этап 3Блок 300Мягкое заверение начинается (только положительные веса)
Этап 4Блок 500Полный HMP с негативными доказательствами

Положительные и негативные доказательства: На Этапе 3 заверенные блоки получают бонусный вес цепочки (положительное доказательство: «этот блок имеет поддержку колонии»). На Этапе 4 отсутствие ожидаемых подписантов также становится сигналом (негативное доказательство: «в этой цепочке отсутствуют майнеры, которые, как мы знаем, должны быть здесь»).

Негативные доказательства вычисляются детерминировано только из самой цепочки-кандидата, без кросс-цепочечного сравнения. Каждая цепочка несёт собственное состояние привилегий: набор подписантов ELDER выводится из истории блоков этой цепочки (кто добывал блоки, кто участвовал в заверениях, в пределах окна просмотра). Если трекер привилегий цепочки показывает 6 подписантов ELDER для KawPoW, но печати на недавних блоках содержат только 2 из них, коэффициент полноты низкий и бонус печати минимален. Никакой ссылки на другую цепочку не нужно. Узлы оценивают каждую цепочку-кандидат независимо, используя собственное состояние этой цепочки.

Это тест кинозала из раздела 6.10: вы зашли не в тот зал, и завсегдатаев нет на своих местах. Никакого сравнения не нужно — вы просто замечаете, кого нет.

В V1 негативные доказательства влияют только на скоринг веса цепочки. Они являются эвристикой выбора, а не жёстким правилом валидности. Цепочка с отсутствующими подписантами не является недействительной; она просто накапливает меньше веса, чем цепочка, где ожидаемые подписанты присутствуют. Этот консервативный подход позволяет избежать ложных штрафов при сетевых разделениях или кратковременных проблемах связности. Будущие обновления протокола могут ужесточить применение негативных доказательств по мере взросления сети.

Аварийный выключатель (SPORK_25_HMP_ENABLED) позволяет экстренно деактивировать HMP при возникновении проблем после запуска.


7. Сетевые параметры

◆

7.1 Адресация

ПараметрЗначение
Префикс публичного адресаK (байт 45)
Префикс скриптового адреса7 (байт 16)
Sapling bech32m HRPks
Тип монеты BIP4499888 (незарегистрированный; формальная регистрация SLIP-0044 ожидается)
Сетевая магия0x4B 0x52 0x47 0x4E ("KRGN")

7.2 Порты

СетьP2P-портRPC-порт
Mainnet71207121
Testnet1712017121
Devnet3712019798
Regtest2712019898

7.3 DNS-сиды

Четыре географически распределённых сид-узла обеспечивают первоначальное обнаружение пиров:

СидРегион
seed1.kerrigan.networkСША
seed2.kerrigan.networkИндия
seed3.kerrigan.networkЯпония
seed4.kerrigan.networkГермания

7.4 Сжатые заголовки

KERRIGAN определяет сжатые заголовки блоков на основе DIP25 с расширениями для мультиалгоритмных полей. Сжатые заголовки в настоящее время отключены до решения граничных случаев мультиалгоритмной десериализации; первоначальная загрузка блоков использует полные заголовки. Однобайтовое битовое поле управляет включением полей:

Это значительно снижает полосу для передачи заголовков при первоначальной загрузке блоков, где лишь для части блоков необходимо передавать полные решения Equihash или данные KawPoW.

7.5 Генезис-блок

ПараметрЗначение
Временная метка1 773 446 400 (11 марта 2026, 12:00 UTC)
Нонс1 338 121
Биты0x1e0ffff0
Субсидия25 KRGN
Хеш0x00000444f8dbee14c599ac723b35cc8021b12d48d092c7ac67d45f6d8a0b9c32

8. Модель безопасности

◆

8.1 Мультиалгоритмное разнообразие

Наиболее прямая выгода безопасности от четырёх алгоритмов майнинга — устойчивость к одновекторным атакам. Атакующий, контролирующий 51% хешрейта X11, контролирует примерно 25% общего производства блоков сети. Для проведения устойчивой атаки 51% ему нужно было бы доминировать как минимум на двух алгоритмах одновременно или подавить один алгоритм, превосходя честных майнеров на остальных. Hivemind Protocol делает это ещё сложнее: одного хешрейта недостаточно, когда выбор цепочки также учитывает аттестации печатей от зарегистрированных, подтверждённых подписантов.

8.2 Безопасность экранированных транзакций

Набор нуллификаторов Sapling предотвращает двойное расходование экранированных заметок. Каждая заметка имеет уникальный нуллификатор, выведенный из её позиции в дереве Меркла и ключа расходования. Как только нуллификатор появляется в цепочке, любая транзакция, пытающаяся потратить ту же заметку, отклоняется на уровне консенсуса. Доказательства Groth16 вычислительно надёжны при предположении о дискретном логарифме на BLS12-381; подделка доказательства без знания свидетеля неосуществима.

8.3 Безопасность сетевых данных

Все данные, десериализуемые из P2P-сети, проверяются на границы перед выделением памяти, итерацией в циклах или индексацией массивов. Решения Equihash ограничены 1400 байтами. Списки подписантов печати ограничены 200 записями. Доказательства zk ограничены 256 байтами. Списки обязательств по публичным ключам ограничены 16 на блок. Ни одно поле из сетевых данных не может вызвать неограниченное выделение памяти.

8.4 Экстренное управление

Система спорков позволяет команде разработчиков отключать функции в продакшене без хард-форка. Критические спорки включают:

Ключи спорков используют порог 2-из-3, требуя двух из трёх держателей ключей для авторизации любого изменения спорка.


9. Дорожная карта

◆

9.1 V1: Запуск (Q1 2026)

V1 — это запуск, ориентированный на майнинг, со всеми основными системами активными:

9.2 V2: Сеть GPU-вычислений (~12 месяцев после запуска)

V2 расширяет KERRIGAN от чисто майнинговой цепочки до сети GPU-вычислений для ИИ-инференса. Оценка основной разработки — приблизительно 12 недель, с общим сроком 48 недель, включающим тестирование, аудит и готовность экосистемы. Архитектура модульная, поэтому V2 может быть выпущена сразу после готовности; 12-месячная оценка консервативна, а не обязательство.

Компоненты V2:

Регистрация провайдеров инференса: GPU-операторы регистрируются в блокчейне с требованиями стейкинга, аттестацией оборудования и эндпоинтами сервиса. Регистрационные транзакции следуют тому же паттерну детерминированного списка, что и мастерноды DIP3, обеспечивая, что каждый узел вычисляет один и тот же набор провайдеров.

P2P-распределение задач: Запросы инференса распределяются провайдерам через протокол распространения. Назначение задач использует VRF-выбор, взвешенный по стейку провайдера и истории производительности. Результаты фиксируются в блокчейне с хеш-доказательствами для разрешения споров.

Верифицируемые вычисления: Провайдеры отправляют аттестации вычислений, которые могут быть выборочно проверены другими провайдерами. Неправильные результаты вызывают слэшинг стейка провайдера. Схема верификации балансирует пропускную способность (не каждый результат проверяется) с безопасностью (мошенничество статистически обнаруживается и наказывается).

Реструктуризация вознаграждений за блок: Coinbase-сплит изменяется для направления 40% вознаграждений за блок участникам ИИ GPU-инференса, поверх их дохода от оплаты за каждый инференс. Майнинг остаётся на 20%, мастерноды — 20%, казначейство — 15%, разработчики/основатели — 5%. Фонд роста обнуляется, выполнив своё назначение на этапе запуска V1.

9.3 После V2

С завершением V1 и V2 фокус смещается на зрелость экосистемы:


10. Заключение

◆

KERRIGAN решает проблему аппаратной централизации, заставляя четыре алгоритма майнинга конкурировать параллельно, каждый на своей кривой сложности. Экранированные транзакции Sapling дают пользователям реальную конфиденциальность, подкреплённую доказательствами с нулевым разглашением Groth16. Hivemind Protocol добавляет второе измерение консенсуса, делая атаки 51% значительно более сложными, требуя аттестации печатей от зафиксировавшихся, проверенных майнеров.

40%-ный фонд роста гарантирует, что проект располагает финансовыми ресурсами для создания биржевого присутствия и экосистемной инфраструктуры при любой цене токена. V1 запускается как полноценный блокчейн, ориентированный на майнинг. V2 расширяет ту же GPU-инфраструктуру до ИИ-инференса, превращая оборудование для майнинга в ресурсы вычислений общего назначения.

Код с открытым исходным кодом. Параметры цепочки зафиксированы. Майнинг начинается с генезиса.


Ссылки

◆
КомпонентИсходные файлы
Мультиалгоритмный PoWsrc/primitives/block.h, src/primitives/block.cpp, src/pow.cpp
Токеномикаsrc/chainparams.cpp, src/masternode/payments.cpp
Saplingsrc/sapling/, src/rust/src/bridge.rs, src/sapling/sapling_tx_payload.h
Мастернодыsrc/evo/dmn_types.h, src/evo/deterministicmns.h
HMPsrc/hmp/, src/rust/src/hmp/
Сетевые параметрыsrc/chainparams.cpp, src/chainparamsbase.cpp
Сжатые заголовкиsrc/primitives/block.h (CompressibleBlockHeader)

Приложение A: Правила консенсуса

◆

A.1 Сериализация заголовков по алгоритмам

X11 (стандартный 80-байтный заголовок):

[version:4][prevHash:32][merkleRoot:32][time:4][bits:4][nonce:4] = 80 bytes

Идентификационный хеш: X11(выше). PoW-хеш: тот же.

KawPoW (80-байтный заголовок + расширенные поля):

[version:4][prevHash:32][merkleRoot:32][time:4][bits:4][nonce:4] = 80 bytes Extended: [nHeight:4][nNonce64:8][mix_hash:32] = 44 bytes

Идентификационный хеш: X11(первые 80 байт). PoW-хеш: ProgPoW(sha256d(первые 80 байт), nHeight, nNonce64), проверяемый по mix_hash. Сид-хеш ProgPoW — это sha256d (не X11), что соответствует стандарту Ravencoin, который используют все KawPoW-майнеры. Порядок байтов: ethash использует big-endian (bytes[0] = MSB), Bitcoin использует little-endian (begin() = LSB). Байты переворачиваются на каждой границе преобразования.

Equihash 200,9 и 192,7 (140-байтный ввод + решение):

CEquihashInput: [version:4][prevHash:32][merkleRoot:32][hashReserved:32][time:4][bits:4] = 108 bytes Mining input: [CEquihashInput:108][nNonce256:32] = 140 bytes Solution: [nSolution: variable, max 1400 bytes]

Идентификационный хеш: X11(version + prevHash + merkleRoot + hashReserved + time + bits + nNonce256, 140-байтная раскладка). PoW-хеш: валидация решения Equihash по тому же 140-байтному вводу. Решение фиксируется в полной сериализации блока.

Ввод идентификационного хеша Equihash: Блоки Equihash используют 140-байтный ввод (включая hashReserved и nNonce256) для идентификационного хеширования, а не стандартный 80-байтный заголовок. 4-байтное поле nNonce не используется для блоков Equihash. Поскольку идентификационный хеш непосредственно фиксирует nNonce256, не существует изменяемости между майнинговым нонсом и идентификатором блока.

A.2 Идентификатор блока, prevHash и уникальность

Идентификатор блока (на который ссылается hashPrevBlock в следующем блоке) — это идентификационный хеш: X11 по базовому заголовку блока (80 байт для X11/KawPoW, 140 байт для вариантов Equihash). X11 используется для идентификационного хеширования на всех алгоритмах.

Гарантия уникальности: 80-байтный заголовок включает корень Меркла, который фиксирует полную coinbase-транзакцию. Coinbase содержит: высоту блока, обязательную по BIP34, адрес выплат майнера, данные идентичности HMP (CCbTx v4+ включает BLS-публичный ключ майнера), встроенные данные печати и пулспецифичный extranonce. Два независимо добытых блока на одной высоте всегда создадут разные coinbase-транзакции (разные майнеры, разные extranonce, разные идентичности HMP) и, следовательно, разные корни Меркла и разные идентификационные хеши.

Чтобы сделать эту гарантию явной на уровне протокола: KERRIGAN требует, чтобы coinbase-транзакция включала публичный ключ HMP майнера в поле minerIdentity CCbTx (v4 HMP_SEAL и v5 HMP_COMMITMENT, после активации HMP Этапа 3 на блоке 300). Поскольку каждый демон имеет уникальную BLS-пару ключей, coinbase гарантированно уникален для каждого демона на каждой высоте. До активации (блоки 0-299) уникальность обеспечивается стандартным механизмом BIP34 высота + extranonce, которого достаточно для ранней цепочки с низкой конкуренцией. На Этапе 2 (блоки 100-299) майнеры регистрируют идентичности через неявные и явные обязательства, но принудительное исполнение откладывается, чтобы дать экосистеме время на адаптацию.

Принудительное исполнение на уровне консенсуса: Узлы отклоняют любой блок на высоте активации HMP Этапа 3 или выше, чей CCbTx не содержит валидного поля minerIdentity. Это правило консенсуса, а не предположение о поведении майнера. Блок без идентичности майнера после активации Этапа 3 недействителен, точка.

Фиксация алгоритмно-специфичных полей: Решения Equihash, mix-хеши KawPoW и расширенные нонсы фиксируются проверкой валидации PoW, а не идентификатором блока. Изменение любого алгоритмно-специфичного поля делает недействительным доказательство PoW. Цепочечная связка (prevHash) единообразна и алгоритмно-агностична.

Множественные валидные свидетели: В астрономически маловероятном событии, что один майнер найдёт два валидных PoW-решения для одного и того же 80-байтного заголовка (один идентификационный хеш, разные алгоритмно-специфичные свидетели), протокол рассматривает их как один и тот же блок. Первый полученный валидный свидетель принимается; последующие свидетели для уже известного идентификационного хеша игнорируются. Это безопасно, потому что идентификационный хеш фиксирует корень Меркла (и, следовательно, все транзакции), поэтому оба свидетеля представляют одно и то же содержимое блока с одинаковым экономическим эффектом.

Защита от отравления недействительным блоком: Поскольку идентификационный хеш не фиксирует алгоритмно-специфичные поля, вредоносный ретранслятор теоретически мог бы изменить решение Equihash или mix_hash KawPoW валидного блока, чтобы создать недействительный блок с тем же идентификационным хешем. Если узел кэширует «этот хеш недействителен» и позднее получит реальный блок, он может его отклонить. KERRIGAN решает это, валидируя алгоритмно-специфичное PoW-доказательство до фиксации заголовка блока в индексе. Блок, чья PoW-проверка не прошла, отбрасывается на сетевом уровне без отравления индекса блоков. Этот же подход используется DigiByte и другими мультиалгоритмными цепочками, разделяющими идентификационное хеширование и PoW-валидацию.

A.3 Формула выбора цепочки

total_chain_weight = sum( weighted_proof(block) ) for all blocks weighted_proof(block) = block_pow_work * seal_multiplier / 10000 seal_multiplier (basis points): No seal / below threshold: 10000 (1.0x) Partial shade (>= threshold): 12000 + (above_threshold / range) * 3000 Full shade (all Elders): 15000 + (elders_present / elder_count) * 3000, cap 18000 Cross-algo bonus: +500 per additional ELDER algo domain (cap +1500) Maximum: 19500 (1.95x)

elders_present, elder_count и block_pow_work определены в разделе A.4. При сравнении двух конкурирующих цепочек на одной высоте побеждает цепочка с большим total_chain_weight.

A.4 Валидность и скоринг печати

Определения:

Динамический порог согласия:

ELDER (на алгоритм)Требуемое согласиеrequired_count (пример)
680%ceil(0.80 * 6) = 5
575%ceil(0.75 * 5) = 4
475%ceil(0.75 * 4) = 3
366%ceil(0.66 * 3) = 2
2100%ceil(1.00 * 2) = 2
0-1Н/ДРежим чистого PoW (seal_multiplier = 10000 для всех блоков)

Правила валидности печати (критичные для консенсуса):

  1. Печать валидна, если содержит не менее 2 BLS-подписей от различных подписантов, чьи публичные ключи были зафиксированы в цепочке не менее чем за nHMPCommitmentOffset (10) блоков до заверяемого блока.
  2. BLS-подпись каждого подписанта должна верифицироваться по H("KRGN-HMP-SEAL-V1" || blockHash || signerPubKey || algoId), где blockHash — идентификационный хеш (X11 по базовому заголовку блока). Доменный тег предотвращает кросс-контекстный BLS-повтор; signerPubKey и algoId в прообразе предотвращают кросс-подписантный и кросс-алгоритмный повтор подписей.
  3. Каждый подписант должен иметь не менее уровня привилегий NEW на высоте заверяемого блока.
  4. Печать с менее чем 2 валидными подписями рассматривается как отсутствующая (seal_bonus = 0).
  5. algoId каждого подписанта ДОЛЖЕН равняться алгоритмному домену, для которого подписант имеет привилегию NEW или ELDER на высоте заверяемого блока, как определено трекером привилегий. Подпись с незаработанным algoId недействительна и исключается из печати.
  6. Только подписи уровня ELDER, чей algoId совпадает с алгоритмом майнинга блока, учитываются в signers_present для коэффициента полноты. Подписи уровня NEW принимаются в печать (они удовлетворяют порог минимум-2 в правиле 1), но не увеличивают completeness_ratio. Подписи ELDER от других алгоритмных доменов учитываются в проверке кросс-алгоритмного бонуса (правило ниже), но не в signers_present. Это предотвращает инфляцию по Sybil через дешёвые идентичности NEW и ограничивает коэффициент полноты сообществом собственного алгоритма блока.
  7. Скоринг печати использует градуированную систему уровней (см. раздел 6.6). Полное затенение требует присутствия всех поалгоритмных ELDER; частичное затенение требует elders_present >= required_count. Множитель интерполируется линейно внутри уровней. Дополнительные подписанты сверх elder_count не увеличивают множитель выше лимита 18000 бп.

VRF и zk-доказательства (неконсенсусные в V1):

VRF-выбор комитета и zk-доказательства Groth16 переносятся в долях печати на уровне P2P и служат защитой от DoS и перебора. В V1 они не являются критичными для консенсуса: валидность печати зависит только от BLS-подписей, зрелости обязательств и проверок привилегий, перечисленных выше. Узлы валидируют VRF и zk-доказательства перед ретрансляцией долей печати (недействительные доказательства отбрасываются на сетевом уровне), но собранные печати в coinbase оцениваются исключительно по их BLS-подписям. Этот консервативный подход минимизирует правила консенсуса при запуске. Будущие обновления протокола могут повысить допуск VRF и верификацию zk-доказательств до правил консенсуса, когда система доказательств будет проверена в бою на mainnet.

Зрелость печати и скользящее окно:

Печать для блока N встраивается в coinbase блока N+2 (nHMPSealTrailingDepth = 2). Это означает:

A.5 Индекс блоков и обработка недействительных свидетелей

Узлы следуют этим правилам при обработке блоков с алгоритмно-специфичными PoW-полями:

  1. Валидировать PoW до индексации. Алгоритмно-специфичная PoW-проверка (валидация решения Equihash, верификация ProgPoW KawPoW или сравнение хеша X11) ДОЛЖНА пройти успешно до добавления заголовка блока в mapBlockIndex. Блок, не прошедший PoW-валидацию, отбрасывается без создания записи в индексе.
  2. Не кэшировать недействительность только по идентификационному хешу. Если блок не прошёл PoW-валидацию, узлы НЕ ДОЛЖНЫ записывать идентификационный хеш как перманентно недействительный. Тот же идентификационный хеш с другим (валидным) свидетелем может прийти позже.
  3. Ограничивать скорость PoW-валидации по идентификационному хешу. Для предотвращения DoS через повторные недействительные свидетели для одного идентификационного хеша узлы МОГУТ кэшировать пары (identity_hash, witness_hash), не прошедшие валидацию, и пропускать ревалидацию той же пары. witness_hash — это SHA256(algoId || algo_specific_fields), где algoId — байт идентификатора алгоритма (доменное разделение), а algo_specific_fields — полные сериализованные данные расширенного заголовка:
    • KawPoW: nHeight || nNonce64 || mix_hash
    • Equihash: hashReserved || nNonce256 || nSolution
    • X11: пусто (идентификационный хеш = PoW-хеш, нет расширенных полей)
    Включение hashReserved в хеш свидетеля Equihash предотвращает вариант отравления, при котором атакующий изменяет hashReserved, сохраняя nNonce256 и nSolution идентичными.
  4. Первый валидный свидетель побеждает. Как только валидный свидетель принят для идентификационного хеша, последующие валидные свидетели для того же идентификационного хеша игнорируются.

A.6 Сводка доверенных настроек

КомпонентПараметрыИсточник
Sapling (экранированные транзакции)Ключи доказательства/верификации Groth16 на BLS12-381Zcash Powers of Tau + Sapling MPC (повторно используются, схемы идентичны)
HMP MiMC circuitКлючи доказательства/верификации Groth16 на BLS12-381Многосторонняя церемония; безопасна, если хотя бы один участник был честен; транскрипты опубликованы