Zycord: одноранговая сеть самосертифицирующихся переходов состояния

Zycord: одноранговая сеть самосертифицирующихся переходов состояния.
The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Эта работа полна и самодостаточна. Она заменяет v1.0 [0]; §15 описывает их связь. Запуск, эмиссия, эры и полная таблица параметров находятся в сопроводительном документе, Zycord: запуск, эры и параметры.

Версии. Текст ниже — версия v2.0 работы, без сокращений; за ним на этой странице следует её сопроводительный документ, также v2.0. Оба доступны в виде PDF, каждый с отделённой подписью, сделанной ключом проекта E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29: работа (подпись) и сопроводительный документ (подпись). Каждая версия архивирована под doi:10.5281/zenodo.22167489, который указывает на последнюю; заменённая версия v1.0 — doi:10.5281/zenodo.22167490. Сопроводительный документ архивирован под собственным doi:10.5281/zenodo.23383987.

1. Введение#

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

Zycord разделяет эти три работы. Транзакция становится сертификатом, который несёт собственные входы и выходы, поэтому его проверка — чистая функция его байтов и никогда не касается реестра. Работа цепочки сводится к упорядочиванию сертификатов и выполнению над ними детерминированной свёртки: цикла сравнений и сложений, который обращается к состоянию ровно один раз на сертификат. Конфликты не делают блоки недействительными; они приводят к пропуску отдельных сертификатов, и плата за каждый пропуск взыскивается со стороны, которая приняла этот риск. Параллелизм не обнаруживается во время выполнения; его объявляет, слот за слотом, автор контракта. Родословная — это схема «исполнить — упорядочить — проверить» [3], детерминированное упорядочивание [4], оптимистичное параллельное исполнение [5] и отделение распространения от упорядочивания [6].

Действительность проверяется один раз на сертификат, параллельно, ещё до того, как существует какой-либо блок. Свёртка выполняется один раз на блок, по порядку, и никогда не исполняет.

Архитектура опирается на два мира, которые могут разделять один исполняемый файл, но никогда не должны смешиваться:

Правила консенсуса только проверяют. Их цель в том, чтобы ни один пользователь не терял средства без своего разрешения, никто не списывал средства с баланса, которым он не управляет, и никакой атакующий не мог опустошить, заблокировать или замедлить сеть. То, как работает секвенсор, как секвенсоры общаются друг с другом и сколько они берут, находится вне консенсуса. В цепочке находится расчёт: оплата секвенсора передаётся внутри интента, подписанного пользователем, и выплачивается, только если сертификат применяется.

Следующие разделы определяют сертификат (§2), свёртку (§3), типизированный доступ к состоянию (§4), нативные активы (§5), виртуальную машину (§6), секвенсоры (§7), принудительный путь (§8), два рынка комиссий (§9), сеть (§10), доказательство стейка (§11), путь за пределы полной проверки (§12), принятые риски (§13), соответствие (§14) и связь с v1.0 (§15).

2. Сертификаты перехода состояния#

Сертификат — единственный тип транзакции. Он кодируется в SSZ, что даёт одно каноническое байтовое кодирование; декодирование требует канонической формы, поэтому декодированный сертификат структурно действителен по построению, и никакое последующее правило не перепроверяет форму.

Два дайджеста отвечают на два вопроса. Идентификатор сертификата — это хеш сертификата с пустым списком подписей: он называет то, что сертификат разрешает. Хеш экземпляра охватывает всё кодирование, включая подписи: он называет один конкретный набор байтов. Подписи остаются вне идентификатора, потому что подписание рандомизировано; каждый одноразовый номер (nonce) даёт ещё одну действительную подпись над тем же телом, и идентификатор, который охватывал бы подписи, дал бы одному разрешению неограниченно много идентичностей, с которых можно взыскать плату. Идентификатор служит ключом множества виденных, порядка свёртки и всей дедупликации. Fill и принудительный сертификат берут в качестве идентификатора хеш своего интента (§7, §8); ставка fill запечатана подписью его секвенсора. Хеш экземпляра — это то, к чему обязывается корень сертификатов блока, поэтому идентификатор блока определяет байты, которые несёт блок. Ставка комиссии находится внутри идентификатора и подписана: ставку вне идентификатора мог бы переписать любой, через кого она передаётся. Каждая подпись подписывает сообщение, которое привязывает идентификатор цепочки и корень консенсуса набора параметров, поэтому сертификат нельзя воспроизвести в другой сети.

Действительность не зависит от состояния. Сертификат действителен, если, исходя только из его байтов:

1. он декодируется канонически, называет эту цепочку, и каждый список находится в пределах своего ограничения;
2. каждая подпись проверяется по строгому Ed25519 (канонические кодирования, ключи без кручения), а набор подписей минимален и при этом достаточен;
3. повторное исполнение программы над объявленными чтениями даёт ровно объявленные записи;
4. каждая запись, которой нужно разрешение, его имеет, а ячейка депозита несёт подпись безусловно;
5. депозит — это ячейка нативного баланса пользовательского адреса, и он покрывает наихудший случай сертификата;
6. сертификат внутренне согласован: ни одна запись не противоречит чтению того же слота, ни один одноразовый адрес, с которого списаны средства, не избегает пометки израсходованным, и никакое значение не записывается на израсходованный адрес;
7. он не записывает ни одной ячейки протокола;
8. каждый адрес, который он называет, несёт определённый байт версии;
9. в контракте, ключ секвенсора которого не равен нулю, путь точного чтения несёт подпись этим ключом (§7), кроме как в принудительном сертификате (§8);
10. запись метаданных объявляет точное чтение каждой ячейки, которую она перезаписывает, со значением, которое ячейка имела, когда сертификат строился.

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

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

3. Реестр как свёртка (fold)#

Блок — это заголовок, упорядоченный список хешей экземпляров сертификатов и сами тела сертификатов. Тела — это данные цепочки: блок действителен, только если его тела доступны. Производитель блока ничего не исполняет. Он упорядочивает сертификаты, которые уже видел проверенными, решает доказательство работы [13] (или, при доказательстве стейка, подписывает слот, для которого его выбрал жребий, §11) и несёт множество идентификаторов сертификатов, увиденных в пределах окна TTL, потому что двойное включение одного из них делает блок недействительным.

Состояние цепочки — это свёртка по упорядоченным сертификатам. Для каждого сертификата, по порядку, свёртка резервирует депозит, сверяет каждое объявленное чтение с текущим состоянием, подготавливает записи с проверяемой арифметикой, а затем фиксирует или пропускает:

• APPLIED — каждое объявленное чтение верно, поэтому записи вступают в силу, а комиссия рассчитывается по фактической стоимости.
• SKIPPED — чтение больше не верно (STALE), дельта вывела бы значение за пределы диапазона [0, 2²⁵⁶) (OVERFLOW) или запись попадает под израсходованный адрес (SPENT). Ничего не записывается. Фиксированная комиссия за пропуск сжигается из депозита, а остальное возвращается.
• FORCED_FAILED — принудительный сертификат (§8), вызов которого откатился или нарушил свои границы. С его плательщиков списываются средства и сжигаются, сдача возвращается пользователю, ничего другого не записывается, а идентификатор помечается виденным.
• DROPPED — с сертификата вообще не удалось взыскать плату (ячейка депозита не пополнена или израсходована), поэтому он переносится в блоке, помечается виденным и не оплачивается. Он ничего не платит своему производителю и стоит ему места под потолком. Fill в том же состоянии вместо этого делает блок недействительным (см. ниже), потому что его отбрасывание поглотило бы интент пользователя, и никто бы не получил оплату.

Канонический порядок. Свёртка упорядочивает сертификаты блока в трёх классах и не оставляет производителю никакой свободы выбора. Сначала fill (§7), каждый берётся, как только готов каждый конвейер, в котором он участвует, а равенства разрешаются по (sequencer key, contract, seq, id). Затем все остальные сертификаты по (deposit address, Seq, id). Последними — принудительные сертификаты (§8), по идентификатору. Каждый узел выводит одинаковое состояние из одинаковой последовательности блоков.

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

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

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

Условия, за которые некому платить, делают блок недействительным. У некоторых сбоев нет виновника: fill, счётчик секвенсора которого нарушает порядок, счётчик fence (§7) которого сдвинулся, плательщик которого уже израсходован или депозит которого нельзя зарезервировать; принудительный сертификат, чтения которого не верны. Включение такого сертификата делает блок недействительным, и ничего не взыскивается. Производитель, который строил блок из состояния, которым располагает, — та сторона, которая могла это знать.

Ровно одно обращение к состоянию на сертификат. Свёртка выполняет сравнения, сложения и записи на горячем рабочем множестве «ключ-значение»: без исполнения кода, без проверки подписей, без повторного исполнения, без арифметики эллиптических кривых. Всё это произошло параллельно во время проверки действительности. Там же вычисляется и идентификатор сертификата, который переносится в свёртку.

Равенство значений, а не версии. Применимость сравнивает объявленные значения чтений, а не счётчики версий. Слот, который изменился и вернулся к прежнему значению, по-прежнему применим, поэтому система пропускает строго реже, чем управление параллелизмом на основе версий.

Собственные пролог и эпилог свёртки. Перед сертификатами, на границе эпохи, свёртка записывает ячейки маяка (§4). После них она делит субсидию блока и проворачивает кольцо созревания coinbase (сопроводительный документ), записывает применённый gas для регулятора комиссий (§9) и, на границе эпохи, вычисляет корень состояния эпохи, который должен совпадать с корнем в заголовке. Она возвращает ошибку только при недействительности блока; проблема с сертификатом — это исход, а не ошибка.

4. Ячейки и типизированный доступ к состоянию#

Ячейка — это значение в слоте (address, word): 256-битное беззнаковое целое, в порядке big-endian в 32 байтах. Отсутствующие ячейки читаются как ноль. Помимо ячеек, протокол ведёт реестр израсходованных адресов — постоянное множество одноразовых адресов, полномочия подписи которых сожжены.

Адрес имеет вид version ‖ blake3(tag ‖ version ‖ payload)[:31], кроме адреса протокола, который состоит из байта версии 0x00, за которым следуют нули:

Одноразовый или постоянный — это политика кошелька, выраженная битом адреса, а не два реестра [7]. Кошельки по умолчанию используют свежий одноразовый адрес для каждого входящего платежа, поэтому платёж на только что выведенный адрес — это быстрый путь без конкуренции, а израсходованная ячейка может быть уплотнена, как только блок, который её израсходовал, погребён глубже горизонта отката. Тот, кому нужен счёт, использует постоянную версию. Вознаграждения за майнинг должны поступать на постоянный адрес: консенсус принимает в качестве адреса выплаты адрес любого вида, но одноразовый адрес сжигает все хранящиеся на нём вознаграждения в момент, когда он израсходован, и именно поэтому узел отвергает такой адрес.

Типизированный доступ — источник параллелизма. Свёртка, поддерживающая только точные чтения, сериализовала бы каждый популярный контракт: тысяча сертификатов, обращающихся к одному пулу, дала бы одно применение и 999 пропусков. Вместо этого чтение объявляет, как оно ограничивает ячейку, а запись объявляет, что она с ячейкой делает:

Устаревает только EXACT. Любое число охраняемых списаний и зачислений в один слот коммутирует: они применяются в любом порядке, и пропуск происходит только тогда, когда охрана действительно не выполняется (реальный овердрафт), а не когда баланс просто изменился. Одна дисциплина на слот на сертификат: установка и дельта не сосуществуют в одном и том же слоте. Правило, которое сохраняет модель корректной, состоит в том, что охраняемые значения никогда не попадают в вычисление: проверка утверждения ничего не возвращает, а дельта ничего не читает, поэтому повторное исполнение остаётся чистой функцией объявленных точных чтений. Эта единственная дисциплина охватывает переводы, чеканку с ограничением предложения, разрешения на расходование (allowances), чаевые и доли в хранилищах (vault shares), то есть подавляющее большинство записей в цепочке. Родословная — это эскроу-транзакции, транзакционный бустинг и CRDT [8][9][10]; Zycord делает коммутативность контрактом параллелизма между узлами.

Одноразовые ячейки. Адрес, который никогда не появлялся в цепочке, находится в состоянии ∅; первая запись переводит его в состояние stored; сертификат, который помечает его израсходованным, подписанный его ключом, переводит его в состояние spent, навсегда. Запись реестра, фиксирующая расходование, никогда не уплотняется: именно она не даёт адресу воскреснуть.

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

Маяк эпохи. Программы не должны читать окружающие значения напрямую. Протокол записывает высоту заголовка, открывшего текущую эпоху, а начиная с эры машины — и его время, в зарезервированные ячейки, один раз за эпоху, и программы читают их, как любой другой слот. Это даёт осведомлённость о времени без поблочного устаревания; оба значения постоянны в течение всей эпохи, которая в mainnet длится сутки: 2 880 блоков при доказательстве работы, 17 280 при доказательстве стейка (§11).

5. Активы без машины#

Эре запуска экономика нужна раньше, чем компьютер. Zycord поставляет нативные активы как операции сертификата начиная с блока 0, без участия какой-либо виртуальной машины:

• TRANSFER — до 32 перемещений (asset, from, to, amount) в одном сертификате, в пределах его ограничений на чтения и записи, каждое из которых — охрана balance ≥ Δ в паре с двумя дельтами. Зачисление на чистую дельту или на свежую одноразовую ячейку — это и есть чаевые, поэтому для чаевых не нужен собственный опкод. На адрес контракта можно зачислять только нативную монету, и никогда — на адрес прекомпила (§6), откуда никто не смог бы забрать стоимость.
• ISSUE — создаёт идентификатор актива с потолком предложения в ячейке однократной записи.
• MINT — с охраной: minted + Δ ≤ cap.
• RETIRE — сжигает до 64 одноразовых адресов, каждый из которых разрешён своим владельцем и в пределах ограничений сертификата, не перемещая стоимость: никаких чтений, чистая запись, которая помечает каждую ячейку израсходованной. Собственно расходование происходит автоматически внутри перевода. Вывод из обращения — это примитив уплотнения и конфиденциальности: получатель стирает одноразовый адрес, как только тот отслужил.

Стример, получающий десять тысяч чаевых в одном блоке, стоит свёртке десяти тысяч коммутативных сложений: ноль конфликтов, ноль пропусков, ни секвенсора, ни машины. График предложения нативной монеты и потолок каждого выпущенного актива живут здесь, обеспечиваемые проверяемой арифметикой из §3.

Платёж проводится так. Кошелёк отправителя выбирает одноразовую ячейку, которой он владеет, объявляет на ней охрану, списывает с неё средства, помечает её израсходованной, зачисляет средства на свежий одноразовый адрес получателя и отправляет сдачу на свежий одноразовый адрес, принадлежащий ему самому. Два сертификата, наперегонки расходующие одну и ту же одноразовую ячейку через два разных узла, оба действительны; применяется ровно один, а другой пропускается, и плата взыскивается с указанного в нём депозита.

6. Машина: cEVM#

Zycord выполняет одну виртуальную машину, cEVM, — диалект виртуальной машины Ethereum [2], адаптированный к сертификатам. Выбор сделан намеренно: бюджет новизны проекта потрачен на модель состояния, параллелизма и экономики, а машина должна быть самым привычным элементом системы. Solidity, её компиляторы, аудиторы и инструменты переносятся без изменений. Всё расхождение диалекта — это список удалений, две перепривязки, шесть добавлений и четыре изменения цены.

Хранилище объявляется, а не обнаруживается. Сертификат несёт чтения, которые потребило его исполнение, и записи, которые оно произвело, а проверка действительности сравнивает их с повторным исполнением. До ячейки доходят четыре семейства опкодов: SLOAD и SSTORE в точной дисциплине, а также семейства утверждений и дельт — в коммутативной. Вызываемый фрейм может добавить в объявленное множество не более 16 записей, поэтому вызываемый не может израсходовать лимиты, нужные вызывающему; запись, которая превысила бы этот предел, прерывает этот фрейм и никакой другой.

Добавлены, на байтах, которые ни один форк EVM никогда не назначал: SASSERTGE 0x21, SASSERTLE 0x22, SASSERTEQ 0x23, SDELTAADD 0x24, SDELTASUB 0x25, SETSEQ 0x26. Предикат и знак находятся в опкоде, никогда на стеке. Охрана ничего не возвращает, поэтому никакое ветвление не может зависеть от того, выполняется ли она; итог дельты берётся над целыми числами и никогда по модулю 2²⁵⁶. SETSEQ(key) устанавливает ячейку секвенсора контракта, в контексте которого идёт исполнение, и никакого другого; нулевой или некорректный ключ — это сбой вывода, который делает недействительным весь сертификат.

Перепривязаны: NUMBER и TIMESTAMP отвечают по точным чтениям ячеек маяка эпохи, поэтому оба постоянны в течение всей эпохи, и перенесённый контракт, который использует block.timestamp для крайнего срока, принимает решение по времени, устаревшему на срок до 24 часов.

Удалены (13): у BLOCKHASH, COINBASE, PREVRANDAO, GASLIMIT, BLOBHASH [14], BLOBBASEFEE, SLOTNUM нет референта; GASPRICE и BASEFEE называют поблочные ячейки, точное чтение которых устаревает по построению; BALANCE и SELFBALANCE вынуждали бы точное чтение нативного баланса; у ORIGIN нет отправителя, которого можно было бы назвать; SELFDESTRUCT позволил бы ячейке хеша кода вернуться к нулю.

Изменена цена: SLOAD и SSTORE стоят фиксированную цену тёплого доступа; надбавка за холодный доступ удалена везде; KECCAK256 подорожал до 720 gas плюс 144 за слово, по измерению на собственной реализации этой машины, — единственное изменение цены, которое повышает плату. Опкоды утверждений и дельт стоят столько же, сколько тёплый доступ SLOAD.

Прекомпилы — замкнутый набор из пяти: sha256, identity, modexp, ed25519_verify и blake3.

Два счётчика. Последовательный gas выводится из объявленного числа чтений, записей и записей реестра и никогда не измеряется машиной. Параллельный счётчик — это то, что считает интерпретатор, относительно бюджета, который сертификат объявляет в единицах вывода; его превышение на глубине 0 делает сертификат недействительным.

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

Запись контракта — это пять ячеек: хеш кода, развёртывающий, ключ секвенсора, администратор и счётчик fence (§7). Ячейка администратора хранит адрес; ноль означает, что администратор — развёртывающий, а 32 байта 0xff означают, что от роли отказались, необратимо. Администратор устанавливает ключ секвенсора через сертификат регистрации и передаёт роль или отказывается от неё через сертификат установки администратора; оба объявляют точные чтения ячеек развёртывающего и администратора, поэтому сертификат от заменённого администратора или администратора, отказавшегося от роли, пропускается. Код контракта никогда не назначает администратора; он перемещает собственный секвенсор с помощью SETSEQ, и именно так секвенсор получает и контракт, созданный фабрикой.

Стандартная библиотека. Токен, банка для чаевых и эскроу, написанные в первую очередь на дельтах, заранее развёрнуты по известным адресам в блоке, который активирует машину, вместе с дельта-обёрткой, которую они вызывают. Перенесённый контракт Ethereum, который избегает удалённых опкодов и прекомпилов, с первого дня корректно работает в режиме «всё точное», сериализуемый секвенсором, если он горячий; параллелизм включается по выбору для каждого слота, обычно небольшим изменением, которое переводит карту балансов с load/store на assert/delta.

7. Секвенсоры#

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

Привязка. Запись каждого контракта (§6) хранит ключ секвенсора. Контракт с ненулевым ключом является секвенированным: сертификат может читать точно, охранять по равенству или устанавливать одну из его ячеек только с подписью этим ключом. Контракт с нулевым ключом является открытым: любой может пройти по его точному пути собственным сертификатом, а контракт защищён только своим кодом. Ключ устанавливает развёртывающий при развёртывании, позже — администратор или собственный код контракта через SETSEQ, и именно так механизм управления заменяет секвенсор без администратора. Привязка может назвать любой ключ; ключ, который никто не обслуживает, не является ошибкой консенсуса — контракт просто непригоден к использованию, пока кто-нибудь его не обслужит или принудительный путь (§8) его не изменит. Охраняемые дельты коммутируют и никогда не ограничиваются, поэтому секвенированный токен по-прежнему принимает каждый перевод от кого угодно.

Каталог. Секвенсор объявляет, где отвечает его сервис, сертификатом каталога: своим ключом и строкой от 1 до 256 байт печатаемого ASCII, обычно URL, объявленной с постоянного адреса. Запись истекает через 90 дней после TTL объявившего её сертификата, если её не продлить, а сертификат отзыва удаляет её сразу. Консенсус хранит строку и никогда её не интерпретирует. Каталог — это обнаружение, а не авторизация: кошельки читают его, чтобы узнать, к кому обращаться.

Интенты. Пользователь не строит сертификат для секвенированного контракта. Пользователь подписывает интент (intent): цель и calldata, параллельный бюджет, одноразовый номер (nonce), окно от NotBefore до TTL, где TTL − NotBefore не более 8 блоков, постоянный адрес секвенсора, набор границ для результата, оплату, причитающуюся секвенсору, оплаты, причитающиеся всем со-секвенсорам, одноразовых плательщиков, которые всё это финансируют, и выходы сдачи. Граница — это предикат над ячейкой, которую записывает вызов: final-at-least, final-at-most, delta-at-least или delta-at-most, и хотя бы одна граница должна называть слот, который вызов записал. Интент — это всё разрешение пользователя; секвенсор не может изменить то, что он делает, только то, когда.

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

Квитанции. Секвенсор отвечает на подписанный интент за миллисекунды, задолго до того, как появится блок: он исполняет интент, подписывает fill и возвращает кошельку fill или подписанную квитанцию, называющую идентификатор интента, seq конвейера и результат. Это предварительное подтверждение. Это обещание секвенсора, а не цепочки; оно становится окончательным, когда fill применяется. Поскольку каждая квитанция подписана, недобросовестное поведение является доказательством: две квитанции от одного ключа, которые дают один seq разным интентам или одному интенту разные результаты, — это доказательство, которое любой может проверить по байтам. Консенсус за это не наказывает. Наказывает рынок. Формат квитанции, цена, идентичность и репутация находятся вне цепочки и свободны по замыслу, поэтому пользователи выбирают между более дешёвым секвенсором, публично идентифицированным или анонимным и уходят от того, кого поймали на двойном подписании.

Конвейеры. Цепочка хранит для каждой пары (sequencer key, contract) последний применённый seq. Fill объявляет seq для каждого конвейера, в котором он участвует, и может войти, только когда счётчик стоит на seq − 1; счётчики продвигаются только тогда, когда fill применяется. Поэтому пропущенный fill оставляет свой счётчик там, где он был: fill, построенные за ним, не могут войти, и секвенсор перестраивает их с того же номера. Два fill с одним seq: входит первый в порядке свёртки, второй не может. Конвейер секвенсора фиксируется в том порядке, в котором секвенсор подписывал, в каком бы порядке его ни получил производитель, и у производителя, смешивающего конвейеры нескольких секвенсоров, нет выбора относительно результата.

Счётчик fence. Каждый контракт хранит в своей записи счётчик fid. Fill объявляет fid каждого контракта, который он читает точно или в котором устанавливает значения; несовпадение означает, что fill не может войти. Счётчик увеличивается на единицу, когда применяемый принудительный сертификат (§8) устанавливает ячейку контракта, и когда записывается ячейка секвенсора контракта. Чтение или дельта его не продвигают: чтение ничего не меняет, а дельта коммутирует с тем, что fill охраняет или изменяет дельтами. Fill, который точно читает ячейку, изменяемую другими через дельты, отвечает за это чтение, как любой сертификат, и его секвенсор платит за пропуск, если ячейка изменилась. Именно так принудительный путь и смена секвенсора аннулируют каждый fill, построенный над состоянием, которое они обошли, без взыскания платы с кого-либо: секвенсор видит, что fence сдвинулся, перестраивает и публикует заново, теряя только задержку.

Совместное секвенирование. Вызов, который пересекает контракты, привязанные к разным секвенсорам, попадает в цепочку как один fill, несущий подпись каждого секвенсора, чей точный путь он затрагивает, в пределах ограничения сертификата в 16 подписей, причём каждая учитывается в потолке подписей блока и в параллельном gas, у каждой свой seq в собственном конвейере, и каждому выплачивается то, что для него называет интент. Координация — кто ведёт, как делаются резервирования, сколько берёт каждый — находится вне цепочки и свободна по замыслу; цепочка видит один сертификат, атомарный по построению. Совместный fill, который так и не опубликован, блокирует только те конвейеры, в которых он участвует; как только его окно проходит, каждый подписант повторно использует номер, который он подписал.

Кто платит за пропуск. Когда fill входит, а чтение устарело или запись переполняется, ничего не записывается, никому не платится, а комиссию за пропуск платит тот, кто ошибся: решает первое чтение или первая запись, которые не прошли в порядке сертификата, и счёт выставляется секвенсору, объявившему себя для этого контракта, если контракт находится на точном пути fill и запись цепочки с этим согласна; во всех остальных случаях он выставляется лидеру — секвенсору, депозит которого называет fill. У каждого перечисленного секвенсора на позиции fill берётся резерв именно для этого. Пользователь никогда не платит за пропуск. Оплата пользователя каждому секвенсору проводится, только когда fill применяется.

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

8. Принудительный путь: включение есть применение#

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

Пользователь подписывает открытый интент: интент в точности как в §7, без названного секвенсора и без со-секвенсоров, финансируемый собственными одноразовыми плательщиками пользователя, и ретранслирует его в сеть. Он перемещается в мемпуле как интент, а не как сертификат. Производитель блока, который хранит полное состояние и уже провёл каждый обычный сертификат блока, вычисляет состояние на конец блока и исполняет над этим состоянием выбранные им открытые интенты в порядке идентификаторов интентов, добавляя получившиеся принудительные сертификаты последними сертификатами блока. Идентификатор принудительного сертификата — хеш его интента, как и у fill. Включение есть применение: нет ни очереди, ни аренды, ни квоты, ни крайнего срока. Принудительный сертификат, объявленные чтения которого не верны относительно состояния, где он размещён, вообще не может войти в блок; его построил производитель, поэтому производитель и есть та сторона, которая могла это знать.

Ограничен по построению. Блок несёт не более 16 принудительных сертификатов, и каждый объявляет не более 4 000 единиц вывода параллельного бюджета (200 000 gas машины). Каждый выход, который предлагает контракт, — вывод средств, отмена, вывод из обращения, перевод — должен укладываться в этот бюджет; правило для авторов контрактов: вывод средств укладывается в принудительный бюджет. При полной загрузке принудительный путь занимает одну треть параллельного потолка генезиса, а обычный трафик сохраняет остальное.

Неудачный вызов всё равно попадает в блок. Принудительный сертификат, вызов которого откатывается, нарушает свои границы или исчерпывает gas, входит в своей неудавшейся форме, FORCED_FAILED: с его плательщиков списываются средства и сжигаются, сдача возвращается пользователю, идентификатор помечается виденным, и больше ничего не записывается. Проверка действительности принимает неудавшуюся форму, только когда повторное исполнение вызова над объявленными чтениями действительно завершается неудачей. Именно это делает путь устойчивым к злоупотреблениям: атакующий, который ретранслирует открытые интенты, не способные завершиться успешно, платит за каждый из них, а пользователя, чей интент корректен, они не могут оставить без обслуживания, потому что производителю платят за то, что он включает, и он предпочитает излишек.

Fence. Принудительный сертификат, который применяется и устанавливает ячейку контракта, продвигает счётчик fence этого контракта (§7), поэтому ни один fill, построенный над изменённым им состоянием, не может войти. Принудительный сертификат, который только читает секвенированный контракт, точно или через охрану, или только перемещает в нём дельты, оставляет fence в покое, как и тот, что попадает в блок в неудавшейся форме; ожидающие fill по-прежнему входят, и пропускается только тот, что точно прочитал ячейку, которую изменил принудительный сертификат (§7). Секвенсор теряет задержку, не более того, а пользователь, который принудительно проводит одну транзакцию на блок в горячем контракте, каждый раз платит принудительную цену.

Оплата. Оплата интента покрывает комиссии сертификата по базовым комиссиям блока; часть базовой комиссии сжигается, а остальное присоединяется к чаевым производителя. Производитель получает то же, что получил бы секвенсор.

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

9. Два рынка: последовательный и параллельный gas#

Цепочка потребляет три ресурса разных классов масштабируемости — данные, проверку и изменение, — и оценка их на одном рынке означает, что проверка подписи конкурирует на аукционе с записью в хранилище. Zycord делит комиссию на два независимых рынка, у каждого из которых собственная цель, потолок и базовая комиссия, хранящиеся в состоянии консенсуса:

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

Оба рынка имеют форму EIP-1559 [12], каждый в своей единице: базовая комиссия сжигается, а приоритетная комиссия выплачивается производителю — за сертификаты, которые применяются, и только за них. Комиссия пропущенного сертификата сжигается полностью и никому не выплачивается. Это несущее правило экономической модели. Если бы пропуск приносил чаевые, сторона, которая выбирает содержимое блока, получала бы плату за то, что устраивает чужие неудачи. Сжигание переворачивает это: пропуск занимает место под потолком и ничего не приносит, поэтому производитель, максимизирующий доход, максимизирует применение и активно противится тому, чтобы вызывать пропуски.

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

Последовательный потолок эластичен. Последовательная цель T — это состояние консенсуса с блока 0, а не константа, и её сдвигает регулятор эпохи:

• В пределах блока мягкий потолок равен 2T, а жёсткий лимит — 4T. Производитель, который выходит за мягкий потолок, оставаясь в пределах жёсткого, теряет квадратичную долю собственного дохода, часть субсидии плюс комиссии блока, и никогда — чью-либо чужую долю.
• От эпохи к эпохе T следует за спросом: удвоенная нижняя медиана применённого gas в эпохе, ограниченная пределами от T − T/1024 до T + T/512, не ниже значения генезиса и не выше ёмкости генезиса (сопроводительный документ). Рост не допускается, когда проверка здоровья сообщает, что сеть нездорова: конкурирующие заголовки цитируются более чем в 2 % блоков эпохи.
• Число сертификатов, число подписей и лимит байтов масштабируются вместе с T от своих значений генезиса, вплоть до статических ёмкостей (2²⁵ сертификатов, 8 MB).

Пропущенные сертификаты сжигают свои комиссии и ничего не регистрируют, поэтому единственный способ поднять потолок — добиться применения: устойчивого, неконфликтующего использования, сжигающего базовую комиссию. Принудительное наращивание стоит атакующему ровно столько, сколько органическое принятие стоит всем остальным. Параллельному рынку такая осторожность не нужна: его цель и его потолок закреплены на постоянном кратном, 3×, от последовательных цели и потолка, то есть 3T и 6T, и наследуют их рост. Родословная — штрафная медиана Monero [15] и работа об адаптивном лимите [16].

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

10. Сеть#

Тела — это данные цепочки. Тела сертификатов блока должны быть получаемыми, чтобы блок был действительным, поэтому состояние всегда можно восстановить по одной лишь цепочке, и ни один оператор, включая секвенсор, никогда не является хранителем данных. Сертификаты больше классических транзакций, потому что несут свои чтения и записи; меры смягчения структурные: fill срезают внутренние записи, израсходованные одноразовые ячейки уплотняются, как только погребены глубже горизонта отката, а узел может обрезать тела ниже нижней границы, которую он объявляет пирам.

Транспорт. TCP, затем TLS 1.3 с идентичностями пиров Ed25519 в самоподписанных сертификатах: канал привязан к ключу, и большего не утверждается. Каждое сообщение — это 5-байтовый кадр, длина и тип, и длина сверяется с собственным потолком типа до любого выделения памяти. Тип, добавленный более новой сборкой, читается и отбрасывается в пределах небольшого лимита, а не закрывает соединение.

Ретрансляция начинается с хешей. Сертификаты распространяются независимо и проверяются на действительность при поступлении, без состояния и параллельно. Ретранслирующему узлу не нужно состояние, чтобы ограничить стоимость фильтрации спама: действительность без состояния проверяется по байтам, а узел, который хранит состояние, также отвергает сертификат, депозит которого не может его покрыть. Ретрансляция имеет дело с экземплярами, а не с идентификаторами: сертификат, подписи которого не проходят, стоит этому экземпляру, и ничего не записывается против идентификатора, потому что более поздний экземпляр того же разрешения может быть годным. Блоки ретранслируются как заголовки плюс списки хешей относительно мемпула [11], поэтому задержка распространения не масштабируется с содержимым блока, а получатель проверяет работу заголовка до загрузки любого тела.

Синхронизация выбирает по проверенной работе. Догоняющий узел предпочитает пира, чьи заголовки действительно доказали наибольшую работу, а не пира, заявляющего наибольшую высоту. Заголовки проверяются как цепочка до загрузки тел; конкурирующая ветвь принимается, только если она подключается в пределах горизонта отката и несёт больше работы, чем цепочка, которую она заменяет (при доказательстве стейка — больше слотов, §11). Закреплённые контрольные точки, встроенные в релиз и принимаемые только тогда, когда блоку не менее одной эпохи, отвергают противоречащую им цепочку, какой бы тяжёлой она ни была, — как защита эры запуска от переписывания истории; оператор может добавить закреплённую точку флагом.

Пиры получают оценку по идентичности: недействительное сообщение стоит 20, нарушение протокола — 50, неотданное тело — 10, чрезмерный запрос — 5; полезное сообщение приносит 1; пир блокируется на −100. Дорогие проверки — эпохи ключей и вычисления доказательства работы — имеют бюджет на каждого пира и возмещаются, когда блок оказывается полезным, поэтому атакующий не может заставить узел перемалывать работу над объявлениями, которые никуда не ведут.

Цитирование. Заголовок может бесплатно цитировать до четырёх недавних конкурирующих заголовков на высоте своего родителя: для цитирования нужно настоящее доказательство работы, тогда как для подавления сигнала почти каждый производитель должен был бы его опускать. Цитируемая частота форков — это сигнал здоровья, который читает регулятор комиссий (§9).

Интерфейс узла. Чтения обслуживаются по HTTP, по умолчанию привязанному к localhost; единственные записи — отправка сертификатов, открытых интентов и подписанных карточек сервисов. Чтения ограничены по частоте для каждого клиента, с токеном доверия, освобождающим от ограничения собственные инструменты оператора. Конечная точка Stratum в диалекте, на котором говорят распространённые CPU-майнеры, позволяет узлу майнить внешним программным обеспечением.

11. Доказательство стейка#

Этот раздел определяет консенсус эры, в которой производство блоков переходит от доказательства работы к стейку. Правила §2–§10 остаются неизменными, кроме тех мест, где этот раздел говорит иное; график и все значения находятся в сопроводительном документе. Константы, помеченные как открытые, фиксируются релизом этой эры.

Что меняется. Две вещи. Право произвести следующий блок, которое доказательство работы продаёт за хеши, разыгрывается жребием пропорционально стейку; а интервал блоков сокращается с 30 до 5 секунд. Всё остальное остаётся в силе: каждое правило действительности из §2 проверяется каждым узлом, для каждого сертификата, по байтам; свёртка та же; два рынка gas те же; недействительный сертификат внутри блока делает блок недействительным. Правило цитирования из §10 остаётся в силе, с подписью слота цитируемого заголовка вместо его работы. Поверхность, которую открывает эта эра, — это поверхность доказательства стейка, и никакая другая.

Куда уходят вычисления. Майнер доказательства работы тратит вычисления на хеши, которые покупают безопасность и ничего больше. Производитель в этой эре тратит те же вычисления на проверку: проверяет подписи, повторно исполняет программы, выводит сертификаты — параллельно, до того как их упорядочить. Работа, за которую платит сеть, становится работой, которая сети нужна. Обычный компьютер проверяет тысячи сертификатов на блок; производитель с большим числом ядер не отстаёт по мере роста объёма. Параллельная проверка поднимает потолок намного выше того, что потребляет последовательный цикл; то, что лежит за ним, описано в §12.

Стейк. Участник вносит нативную монету в залог нативной операцией BOND, которая перемещает баланс с постоянного адреса в ячейку стейка, привязанную к этому адресу. Ячейки стейков — это ячейки протокола: сертификат разрешает перемещение, а свёртка выполняет запись, как она делает это для счётчиков секвенсоров. Ключ этого адреса и есть ключ, который подписывает блоки. Стейк становится активным через одну эпоху после внесения в залог, поэтому стейки нельзя создавать и отбрасывать сериями; UNBOND возвращает баланс после задержки, превышающей горизонт отката. Минимум устанавливается сопроводительным документом. Один ключ — один стейк.

Жеребьёвка. Блоки занимают слоты фиксированного интервала. Для каждого слота производитель выбирается жребием из множества стейков, активных на момент открытия эпохи, с вероятностью, пропорциональной стейку, по зерну, которое цепочка зафиксировала в течение предыдущей эпохи и записала в ячейки маяка (§4); производители блоков, фиксирующих зерно, не должны иметь возможности смещать его. Заголовок несёт слот и подпись выбранного производителя вместо доказательства работы; заголовок, подписанный другим ключом или вне своего слота, недействителен. Слот без блока остаётся пустым, и следующий выбранный производитель строит на последнем известном ему блоке. Жеребьёвка — функция состояния, зафиксированного до открытия эпохи, поэтому каждый узел выводит её самостоятельно, и никакими сообщениями консенсуса, кроме самого блока, обмениваться не нужно. Родословная — лотерея лидера слота в Ouroboros [17] и поэпохальное расписание лидеров Solana [21]; сокрытие лидера за верифицируемой случайной функцией [31], как это делает Praos [18], — альтернатива на случай, если отказ в обслуживании против известных производителей станет проблемой.

Выбор цепочки. Там, где §10 выбирает по проверенной работе, эта эра выбирает по длине: среди действительных цепочек — ту, что занимает больше всего слотов [17]; из двух цепочек равной длины — ту, у которой первый блок после форка находится в более раннем слоте. Горизонт отката и закреплённые контрольные точки из §10 остаются и служат защитой от переписывания ключами, залог которых с тех пор выведен: узел, присоединяющийся к сети, принимает историю, которую закрепляет его релиз, и никакая более длинная цепочка ей не противоречит.

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

Двойное подписание. Консенсус наказывает только одно нарушение: два заголовка, подписанные одним ключом для одного слота. Как и недействительный сертификат, это доказательство в одном сообщении, которое любой может проверить по байтам. Сертификат с сообщением о нарушении несёт оба заголовка; свёртка сжигает собственный залог подписанта, удаляет ключ из активного множества и выплачивает сообщившему открытую долю. Сообщение принимается, пока не завершится выход стейка. Никакое другое поведение не наказывается в консенсусе, и никакое поведение производителя не затрагивает чужие монеты. Прецедент — слэшинг предлагающих (proposer slashing) в beacon chain Ethereum [19].

Пулы. Пул — это стейк, принимающий делегирование. Любой постоянный адрес может внести залог и нативной операцией DELEGATE направить свой залог на ключ пула; у залога, который только делегирует, минимум меньше, чем у производящего. Баланс никогда не покидает делегатора, который перенаправляет его или выводит из залога с той же задержкой выхода. Вес пула в жеребьёвке — его собственный залог плюс то, что ему делегировано. Вознаграждение за блоки, которые производит пул, свёртка делит раз в эпоху, вне поблочного пути, между пулом, по марже, которую он объявляет при регистрации, и его делегаторами, пропорционально стейку. При двойном подписании сжигается собственный залог пула, а его делегирования возвращаются делегаторам. Как проверка распределяется внутри пула — дело самого пула: каждый участник проверяет полученную им часть, один сертификат может уйти более чем одному участнику, а оператор сводит ответы, собирает блок и подписывает его выбранным жребием ключом. Всё это — построение, вне консенсуса и свободное по замыслу (§1): цепочка видит таблицу делегирований, заголовок, подписанный одним ключом, и блок, сертификаты которого каждый полный узел проверяет заново. Небольшой узел вносит те ядра, которые у него есть; держатель, у которого есть только монеты, вносит стейк. Родословная — стейк-пулы Cardano [20], которые так же никогда не применяют слэшинг к делегаторам.

Разгон. Эра вступает в силу в три этапа, каждый из которых — правило консенсуса.

1. Внесение залога. BOND, UNBOND и DELEGATE принимаются. Доказательство работы продолжает производить каждый блок и получать всю долю производителя.
2. Разгон, в течение 90 эпох. Каждый блок по-прежнему добывается майнингом и несёт подпись стейка, выбранного жребием для его высоты, в заголовке вне прообраза доказательства работы; идентификатор блока её охватывает, поэтому подписанный блок и его неподписанная копия — это два блока, и при равной работе побеждает подписанный. Выбор цепочки по-прежнему делается по работе, и две подписи на одной высоте не являются двойным подписанием. Доля производителя в субсидии делится между майнером и стейкером: счётчик k начинается с 1 и растёт на единицу с каждой эпохой, прошедшей порог, а стейкер получает k/180, так что работа сохраняет не менее половины до перехода. Блок, перенесённый без подписи, является действительным и никому не платит: доля его производителя в субсидии и его приоритетные комиссии сжигаются, поэтому майнер ничего не выигрывает, оставляя стейкера в стороне, а стейкер ничего не выигрывает, отсутствуя. Эпоха проходит порог, когда не менее 90 % её блоков несли подпись, а активный стейк, включая делегирования, составлял не менее 10 % предложения. Разгон начинается, когда активный стейк достигает 10 % предложения на протяжении 30 эпох, или, самое позднее, на эпохе, которую фиксирует сопроводительный документ, с тем стейком, который существует. Ни один блок не производится одним лишь стейком, пока стейк не подписал в реальной работе девять блоков из десяти на протяжении 90 эпох. Прецеденты — гибрид Decred, в котором добытые блоки несут голоса стейка, а субсидия делится между ними [22], и Merge, в котором стейк вёл собственную цепочку почти два года, прежде чем взял на себя производство блоков [23].
3. Переход. Первый блок эпохи, следующей за 90-й эпохой, прошедшей порог, — это слот 0: доказательство работы заканчивается, интервал становится 5 секунд, а эпоха — 17 280 слотов. То, что эпоха выплачивает в виде субсидии, не меняется; каждый блок выплачивает одну шестую, а пустой слот не выплачивает ничего. Поблочные потолки (§9) с их нижними и верхними пределами, а также число принудительных сертификатов (§8) делятся на шесть с округлением вниз, так что ёмкость в сутки в момент перехода остаётся той же, и регулятор эпохи продолжает работу оттуда. Каждая константа, измеряемая в блоках и измеряющая время (созревание, максимальный TTL, окно интента, горизонт отката, окно медианного времени, срок жизни записи каталога), умножается на шесть, а созревание или TTL, установленные до перехода, пересчитываются на блоке перехода.

Окончательность. Блок становится окончательным по глубине, как при доказательстве работы. Финансовым сервисам следует ждать 10 минут: 120 блоков там, где доказательство работы требовало 20. Блоки старше одной эпохи могут быть закреплены как контрольные точки.

12. За пределами полной проверки#

В эрах доказательства работы и доказательства стейка каждый узел проверяет каждый сертификат. Вычисления не являются пределом: проверка параллельна, а потолки §9 перезакрепляются на границах эр вплоть до структурной ширины списка сертификатов, 2²⁵ на блок. Раньше этой стены ограничивают данные: пропускная способность сети, чтобы получать каждое тело, и хранилище, чтобы держать каждое тело и каждую запись реестра израсходованных адресов. Этот раздел говорит о том, что известно о пути дальше, и оставляет его более поздней эре, активируемой по мере надобности, когда дневной объём приблизится к тому, что проверяет обычный узел. Это направление, а не спецификация: у проблем есть несколько решений с разными компромиссами, сеть ещё долго обслуживает любой спрос, с которым столкнётся, без какого-либо из них, а детальная подготовка к далёкому будущему стоит не больше, чем оставленный размеченным путь для того, кто по нему пойдёт. Ничто из изложенного ранее не меняется. Действительность как функция байтов, свёртка, типизированный доступ, два рынка, секвенсоры и принудительный путь остаются такими, какие есть. Меняется только то, кто проверяет каждый сертификат.

Что позволяет сертификат. В цепочках с повторным исполнением — Ethereum, Solana и производных от них — каждый валидатор исполняет каждую транзакцию над глобальным состоянием, проверка наследует ограничения состояния, а исторически ответом были более мощные машины, то есть меньше узлов. Параллельное исполнение внутри узла с объявленными списками доступа, как в Solana [21], делает каждую машину быстрее и не меняет того, кому она нужна. Cardano подошла ближе: в расширенной модели UTXO валидация детерминирована и локальна [24], но скрипты выполняются на каждом узле, а общее состояние порождает конкуренцию, которую модель разрешает, вынося сериализацию к внецепочечным пакетировщикам (batchers), не признаваемым цепочкой. Роллапы, как оптимистичные, так и основанные на доказательствах корректности [25][26], вынесли исполнение из базовой цепочки и оставили ей проверку: это правильное разделение, оплачиваемое вторым уровнем, мостом, единственным секвенсором, чей принудительный путь ждёт за задержкой, и, в зависимости от вида, неделей интерактивного спора или прувером, который стоит на порядки больше, чем исполнение. Сертификат Zycord — это пакет роллапа, который базовая цепочка проверяет по его собственным байтам и никогда не исполняет над своим состоянием, и поэтому ему не нужен второй уровень: моста нет, потому что состояние одно; спора нет, потому что недействительный сертификат сам является доказательством мошенничества, в одном сообщении; прувера нет, потому что проверка стоит столько же, сколько исполнение; секвенсор назначается на контракт, принудительный путь попадает в следующий блок, а два контракта под разными секвенсорами компонуются в одном атомарном сертификате (§7), тогда как двум роллапам нужен мост. А там, где ответом на рост служит шардинг — изначальная траектория Ethereum, Near [27], парачейны [28], — который разделяет состояние и теряет атомарность между разделами, разделение в Zycord, когда оно наступит, разделит проверку, а не состояние: состояние остаётся единым, свёртка остаётся единой, и каждый сертификат остаётся атомарным, потому что то, кто проверяет сертификат, — свободный выбор, когда действительность является функцией байтов.

Выборочная проверка. При стейке, внесённом в залог, ответственность за проверку сертификата может быть возложена жребием на подмножество стейков, вместо того чтобы ложиться на все. Сертификат входит в блок с аттестациями своего комитета; любой узел по-прежнему свободен проверять что угодно; недействительный сертификат по-прежнему сам является доказательством мошенничества, в одном сообщении, без состояния и без интерактивной игры [29]; а то, что добавляет эра, — это слэшинг того, кто аттестовал. Размер комитета, форма аттестации, окно оспаривания и то, что происходит с применённым поверх аннулированного сертификата, — это спецификация той эры, и они остаются открытыми. Эффект — инвертировать кривую: ёмкость растёт с каждым присоединяющимся узлом, потому что каждый проверяет меньшую долю, а комитет растёт вместе с множеством.

Конус проверки. Тому, кто получает сертификат, не нужна вся цепочка, чтобы ему доверять. Чтения объявлены, поэтому множество сертификатов, от которых он зависит, перечислимо по цепочке: для каждой прочитанной ячейки — сертификаты, которые записывали её с тех пор, как был зафиксирован последний корень состояния эпохи, и их сертификаты, рекурсивно. Этот конус, повторно проверенный по байтам и привязанный к корню эпохи, к которому обязывается заголовок (§3), — полная проверка того, что важно получателю, выполняемая за секунды, в сетевом времени, без схемы и без специального доказательства. Биржа, получающая депозит, проверяет конус депозита, а не сеть; при выборочной проверке остаётся переждать реорганизации и окно оспаривания, что она и так делает уже сегодня. Доказательство того, что ячейка имела заданное значение в корне эпохи, — единственный новый объект, который для этого требуется, и его форма открыта; родословная — упрощённая проверка платежей [1].

Хранилище. Что сеть уже делает: израсходованные одноразовые ячейки уплотняются за горизонтом отката (§4), а узел обрезает тела ниже объявляемой им нижней границы (§10). Что остаётся предметом изучения: реестр израсходованных адресов на каждую эпоху, в котором одноразовые адреса истекают, а реестр закрывается; аккумулятор вместо реестра [30]; и хранение старых тел частью узлов, с корнем эпохи в качестве гарантии того, что хранимое — это то, что было израсходовано.

Пропускная способность. Два пути. Первый — топология, которая в архитектуре уже есть: кошелёк, секвенсор, производитель. Fill не обязан наводнять сеть; он идёт от секвенсора к производителям, а все остальные получают хеш, как ретрансляция уже делает с блоками (§10). Второй — отделить голову сертификата от его тела. Голова — это то, к чему обращается свёртка: идентификатор, чтения, записи, депозит и ставка. Тело — это то, что потребляет проверка: программа, calldata, подписи. При выборочной проверке производителю нужно тело только тех сертификатов, на проверку которых его выбрал жребий, и голова всех остальных, и его пропускная способность падает на порядки. Блок продолжает обязываться к хешу всего экземпляра, а тела продолжают быть данными цепочки, обслуживаемыми теми, кто их проверил, и теми, кто их архивирует; как гарантируется их доступность, когда не каждый узел их хранит, — это вопрос, на который эра должна ответить, прежде чем она появится [29].

13. Принятые риски#

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

1. Контракт, у которого исчезли и секвенсор, и администратор, и код, меняющий секвенсор, можно покинуть только по принудительному пути: медленно и дороже, но он жив.
2. При пустых блоках обе базовые комиссии останавливаются на 7, выше своего минимума 1: ниже 8 шаг вниз округляется до нуля. Чтобы сдвинуть эту точку покоя, нужно изменение параметра на границе эры.
3. Около одного блока оплачиваемого вредительства через комиссии в горячем контракте: собственные принудительные сертификаты производителя, размещённые вокруг сертификата пользователя и ограниченные границами пользователя, и по одному принудительному сертификату на блок, заставляющему секвенсор перестраивать свой конвейер.
4. Открытый контракт, с нулевым ключом секвенсора, защищён только своим кодом, а автор сертификата для него сам платит за свои пропуски: чтения выбрал автор.
5. Ненативный актив, зачисленный на одноразовый адрес кем-либо, кроме сертификата, который этот адрес сжигает, замораживается сжиганием, которое перемещает только нативный баланс и ячейки, записываемые этим сертификатом. Проверка балансов активов на адресе перед его сжиганием — правило кошелька, а не правило протокола.
6. Сертификат, который только перемещает дельты, не продвигает fence (§7); fill, построенный до него и точно читающий ячейку, которую тот изменил, пропускается в более позднем блоке, а плата взыскивается с секвенсора. Секвенсор избегает этого, не читая точно ячейку, которую его контракт позволяет кому угодно менять через дельту.
7. Остаточное вредительство в отношении исполнителя принудительного пути: атакующий с множеством плательщиков может ретранслировать открытые интенты, которые не может нести ни один сертификат, например интент, у плательщика которого недостаточно средств для оплаты. Вызов, который лишь откатывается или нарушает свои границы, к ним не относится: он попадает в блок в неудавшейся форме и платит (§8). Каждый непереносимый интент стоит исполнителю одного построения; затем копия вытесняется и помещается в карантин, а замена на том же плательщике должна платить строго больше.
8. Соподписант не блокирует ни одной ячейки. Совместный fill, который он подписал, удерживает место в его конвейере, пока fill не будет перенесён в блок или не пройдёт его окно (§7). Совместный fill, не перенесённый вовремя, может встретиться с другими fill на тех же ячейках; тот, что входит в свёртку вторым, пропускается, а плата взыскивается с его собственного депонента.
9. В открытом контракте гонку за точные чтения выигрывает сертификат, адрес депозита которого сортируется первым, а адреса дёшево подбирать перебором; контракт с конкурентным точным состоянием выбирает секвенсор, конвейер которого задаёт порядок.
10. Простой вызов на точном пути открытого контракта объявляет ячейку секвенсора контракта как точный ноль. Если контракт получит ключ до того, как сертификат попадёт в блок, чтение устаревает и вызов пропускается, а плата взыскивается с вызывающего; кошелёк предупреждает об этом до построения такого вызова.
11. Комиссия за пропуск фиксирована, поэтому при высоких базовых комиссиях пропуск стоит меньше, чем применение; перебирать несколько вариантов одного сертификата дёшево, и каждый узел проверяет каждый из них.
12. Пропускная способность сети и хранение при высокой пропускной способности — объявленная открытая проблема, а не решённая: тела — это данные цепочки, каждый узел несёт каждый байт, вызов машины несёт исполняемый им код, а реестр израсходованных адресов растёт на одну запись за каждое расходование одноразового адреса. Путь описан в §12.
13. При доказательстве стейка (§11) безопасность цепочки — это безопасность обычного доказательства стейка: она стоит столько, сколько стоит собрать большинство веса в жеребьёвке, включая делегирования. Разгон начинается в свой крайний срок с тем стейком, который существует, и именно порог не даёт переходу завершиться, пока живой стейк не удерживает десятую часть предложения; отсутствие десятой части стейка приостанавливает его. Двойное подписание пула стоит только его собственного залога, сколько бы ему ни было делегировано; делегаторы выбирают свой пул, зная это. Дальнее переписывание ключами, залог которых с тех пор выведен, исключают только закреплённые контрольные точки (§10), которые присоединяющийся узел принимает из своего релиза и не выводит из цепочки.

14. Соответствие#

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

• векторы свёртки: (pre-state, block) → (post-state | invalid, outcomes, fees); недействительный вектор фиксирует единственное правило, которое он нарушает;
• векторы вывода: (program, declared reads and writes, deposit) → (reads, writes, artifact, parallel gas), либо правило, которое отвергает сертификат до того, как дело дойдёт до машины;
• векторы сложности: (parameters, headers) → next target, с вердиктом по заголовку-кандидату; при доказательстве стейка — (stake set, seed, slot) → drawn key.

Векторы генерируются и никогда не редактируются вручную. Регенерация запускает эталонную свёртку, воспроизводит результат через неё, а затем воспроизводит зафиксированный JSON через вторую, намеренно наивную свёртку, не разделяющую с первой никакого кода; регенерация, с которой вторая свёртка не согласна, завершается неудачей. Регенерация, которая меняет существующий вектор, является изменением консенсуса и рассматривается как таковое. Реализация соответствует протоколу, когда она воспроизводит идентификатор генезиса и проходит векторы; тогда она — пир, а не форк.

15. Связь с v1.0#

Эта работа полностью заменяет v1.0 [0]. Там, где они расходятся, протоколом является эта работа, и v1.0 не следует читать вместе с ней. Тезис не изменился: самосертифицирующиеся сертификаты, свёртка, которая никогда не исполняет, типизированный доступ к состоянию и два рынка комиссий. Изменения ниже были обнаружены в ходе реализации архитектуры; каждое убрало поверхность консенсуса и целые классы ошибок.

16. Заключение#

Zycord упорядочивает сертификаты вместо того, чтобы исполнять транзакции: действительность проверяется кем угодно, где угодно, параллельно, по одним лишь байтам; состояние продвигается свёрткой, которая только сравнивает и складывает; конфликты пропускаются, оцениваются и оплачиваются стороной, которая их выбрала; параллелизм объявляется, а не обнаруживается; приложения подтверждаются за миллисекунды секвенсорами, которым доверяют в части живучести и никогда в части безопасности; принудительный путь сохраняет каждый контракт достижимым; а консенсус, как только монета распределена, тратит свои вычисления на проверку вместо хешей. Проверка масштабируется вширь на оборудовании, которым сеть не владеет. Фиксация остаётся последовательной и почти бесплатной.

Ссылки#

[0] The Simstoshi. Zycord: A Peer-to-Peer Network of Self-Certifying State Transitions, v1.0. 2026. Заменена этой работой.
[1] S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.
[2] V. Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. 2013.
[3] E. Androulaki et al. Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains. EuroSys 2018.
[4] A. Thomson et al. Calvin: Fast Distributed Transactions for Partitioned Database Systems. SIGMOD 2012.
[5] R. Gelashvili et al. Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing. 2022.
[6] G. Danezis et al. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus. EuroSys 2022.
[7] J. Zahnentferner. Chimeric Ledgers: Translating and Unifying UTXO-based and Account-based Cryptocurrencies. IACR ePrint 2018/262.
[8] P. E. O'Neil. The Escrow Transactional Method. ACM TODS, 1986.
[9] M. Herlihy, E. Koskinen. Transactional Boosting: A Methodology for Highly-Concurrent Transactional Objects. PPoPP 2008.
[10] M. Shapiro et al. Conflict-free Replicated Data Types. SSS 2011.
[11] M. Corallo. BIP 152: Compact Block Relay. 2016.
[12] EIP-1559: Fee Market Change for the ETH 1.0 Chain. Ethereum Improvement Proposals, 2019.
[13] tevador et al. RandomX: Proof-of-Work Algorithm Optimized for General-Purpose CPUs. 2019.
[14] EIP-4844: Shard Blob Transactions. Ethereum Improvement Proposals, 2022.
[15] Monero: Dynamic Block Weight and Penalty. Monero Research Lab documentation.
[16] bitcoincashautist. CHIP-2023-04: Adaptive Blocksize Limit Algorithm for Bitcoin Cash. 2023.
[17] A. Kiayias, A. Russell, B. David, R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. CRYPTO 2017.
[18] B. David, P. Gaži, A. Kiayias, A. Russell. Ouroboros Praos: An Adaptively-Secure, Semi-Synchronous Proof-of-Stake Blockchain. EUROCRYPT 2018.
[19] Ethereum Foundation. Ethereum Consensus Specifications: The Beacon Chain (слэшинг предлагающих, proposer slashings). 2020.
[20] L. Brünjes, A. Kiayias, E. Koutsoupias, A.-P. Stouka. Reward Sharing Schemes for Stake Pools. IEEE EuroS&P 2020.
[21] A. Yakovenko. Solana: A New Architecture for a High Performance Blockchain. 2017.
[22] Decred Documentation: Proof-of-Stake. docs.decred.org.
[23] Ethereum Foundation. The Merge. ethereum.org, 2022.
[24] M. M. T. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. Peyton Jones, P. Wadler. The Extended UTXO Model. Financial Cryptography Workshops 2020.
[25] H. Kalodner, S. Goldfeder, X. Chen, S. M. Weinberg, E. W. Felten. Arbitrum: Scalable, Private Smart Contracts. USENIX Security 2018.
[26] V. Buterin. An Incomplete Guide to Rollups. 2021.
[27] A. Skidanov, I. Polosukhin. Nightshade: Near Protocol Sharding Design. 2019.
[28] G. Wood. Polkadot: Vision for a Heterogeneous Multi-Chain Framework. 2016.
[29] M. Al-Bassam, A. Sonnino, V. Buterin. Fraud and Data Availability Proofs: Maximising Light Client Security and Scaling Blockchains with Dishonest Majorities. 2018.
[30] D. Boneh, B. Bünz, B. Fisch. Batching Techniques for Accumulators with Applications to IOPs and Stateless Blockchains. CRYPTO 2019.
[31] S. Micali, M. Rabin, S. Vadhan. Verifiable Random Functions. FOCS 1999.

Zycord: запуск, эры и параметры#

The Simstoshi
2026 — v2.0
GPG: E724 39CE DD85 11F9 D607 550B 87FD 60D5 EB4A 0B29

Этот документ сопровождает работу Zycord: одноранговая сеть самосертифицирующихся переходов состояния, v2.0 («работа»). Работа определяет механизмы. Этот документ излагает, как был запущен mainnet, как эмитируется монета, какая эра что активирует, и значение каждого параметра. Он полностью заменяет §13 и §14 работы v1.0; там, где они расходятся, определяющую силу имеет этот документ.

1. Запуск#

Генезис mainnet: 2026-10-07 00:00 UTC (1791331200), идентификатор цепочки 1.

• Блоки каждые 30 секунд при доказательстве работы; каждые 5 секунд начиная с перехода на доказательство стейка (§6). Доказательство работы: RandomX v2, добываемый на CPU. Сложность: LWMA по окну в 90 блоков.
• Блок 0 не содержит ни сертификата, ни адреса, ни ключа. До блока 0 не существует ни одной монеты. Генезис воспроизводим из опубликованных исходников.
• Ни инвесторского раунда, ни ключей администратора. Ни один путь в коде не позволяет какому-либо ключу приостановить, обновить, выпустить, цензурировать или реорганизовать.

Стартовое обязательство. Набор параметров несёт обязательство к секретному стартовому сообщению. Блок 1 должен раскрыть это обязательство в своём заголовке, поэтому только держатель сообщения может произвести блок 1, и никто другой не может накопить работу на цепочке, которая начинается раньше объявленного генезиса; разгон эмиссии делает любую фору малоценной. Начиная с блока 2 строить может любой майнер.

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

2. Эмиссия#

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

E(0) = E0
E(n) = max(tail, E(n−1) − floor(E(n−1) / Q))

где E0 = 21 ZCD за блок, Q = 1054 и tail = 0,33 ZCD за блок, при интервале доказательства работы в 30 секунд. Ставка уменьшается вдвое примерно каждые два года. Нет ни чисел с плавающей точкой, ни таблицы. Блок генезиса не выплачивает coinbase. Хвост начинается на эпохе 4 376, примерно на 12-й год, при запланированных 61 836 900,03 ZCD: это 62 744 838,47, к которым сводится график, за вычетом стартового разгона и блока генезиса. Эти цифры — то, что даёт рекуррентное соотношение; ни один узел никогда не вычисляет замкнутую форму. Один ZCD — это 100 000 000 drops.

Медленный старт. Первые 86 400 блоков (30 дней) — это разгон: блок h выплачивает E(30) · h / 86,400, ставку эпохи, в которой разгон заканчивается, с округлением вниз, поэтому вознаграждение растёт по прямой от почти нуля до графика. То, что разгон удерживает, около 907 917 ZCD, никогда не возвращается.

Смена интервала. Начиная с перехода на доказательство стейка (§6) эпоха составляет 17 280 слотов, а субсидия на блок — E(n)/6 с округлением вниз в drops; рекуррентное соотношение не меняется. То, что выплачивают сутки полных слотов, одинаково при обоих интервалах: 21 ZCD за блок на кривой генезиса равны 3,5 за 5-секундный блок, а хвост в 0,33 равен 0,055. Хвост начинается на той же эпохе, 4 376. Округление удерживает менее тысячной доли ZCD за эпоху, и это никогда не возвращается.

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

3. Разделение субсидии#

Каждая субсидия блока делится в пропорции 94 / 3 / 3 консенсусом начиная с блока 0. Разделение применяется только к субсидии, никогда к комиссиям, и одинаково к каждому блоку. Во время разгона доказательства стейка (§6) 94 % производителя сами делятся между майнером и выбранным жребием стейкером, в той доле, которой достиг разгон.

Премайна нет: разделение — это правило, применяемое к каждому добытому блоку, а не распределение в генезисе. За три года доля основателя в сумме составляет менее 2 % предложения до начала хвоста. Производитель, превышающий мягкий потолок (работа, §9), теряет только из собственной доли; доли казны и основателя берутся из несокращённой субсидии.

4. Казна#

Ячейка казны — это нативный баланс адреса протокола. Ни один ключ не хешируется в этот адрес, ни один сертификат не может списать с него средства, а генезис не называет никакого кворума. Она пополняется с блока 1, и этот релиз вообще не содержит пути расходования. Путь расходования определяется обновлением, не раньше высоты 259 200 (около 5 января 2027 года), с подписантами, выбранными сообществом, а не основателем. До тех пор ячейка — это публичное целое число, которое любой может проверить и никто не может тронуть.

5. Попечение: первые три года (предложение)#

Статус. Этот раздел — направление для обсуждения сообществом. Ничто в нём не является правилом консенсуса, пока обновление казны из §4 не закрепит набор ключей, а детали определяются только после того, как направление будет принято.

Что получает казна. Около 533 000 ZCD в год 1, 396 000 в год 2 и 280 000 в год 3: всего около 1,21 млн. Начиная с года 4 она также получает 3 % основателя (§3), всего около 396 000 за тот год. Что на это можно купить, зависит от цены, которую никто не знает, а тонкий рынок не может поглотить крупные продажи, поэтому план должен работать и при низкой цене:

Поэтому каждая сумма ниже — это доля поступлений в казну, а не цифра в долларах или в ZCD.

Пять мест. Место определяется раньше, чем его держатель. У каждого места есть публичный устав: его обязанности, результаты, порядок отчётности и оплата. Подать заявку может любой. Тот, кто занимает место, исполняет устав, как по договору.

Решения.

• Для расхода нужно 3 из 5.
• Замена держателя, ротация ключей, расходование резерва или изменение устава требуют 4 из 5 и публичны в течение 7 дней, прежде чем вступят в силу.
• Сроки полномочий длятся один год и возобновляемы. Кандидатуры публичны в течение 30 дней. Первые пять держателей — это набор ключей, закреплённый обновлением, которое принимают операторы узлов; более поздний хардфорк может закрепить его заново.

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

Бюджет в долях поступлений.

Инфраструктура имеет первоочередное право: узлы, сиды, обозреватель и серверы сборки сегодня стоят около US$ 500 в месяц. Возмещение пересчитывается по рыночной цене на день выплаты. Доля покрывает эти расходы при цене около US$ 0,06 за ZCD в год 1, US$ 0,08 в год 2 и US$ 0,11 в год 3; ниже этой цены недостача переносится вперёд без процентов и выплачивается, когда доля это позволяет.

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

Что обеспечивает консенсус. Как только обновление вступит в силу: расход 3 из 5 и ротацию 4 из 5 с её задержкой. Всё остальное в этом разделе — норма. Норму обеспечивает то, что каждый расход — обычный сертификат, публичный и подсчитываемый по одной лишь цепочке.

Открыто. Потолок на место. Правовая форма, в которой подписывает публичный представитель. Будет ли шестимесячная блокировка обеспечиваться эскроу-контрактом стандартной библиотеки, как только машина будет активна.

6. Эры#

Эры — это константы высоты, скомпилированные в публичные релизы. Блок ниже рубежа, несущий программу, которую этот рубеж включает, недействителен, и эта проверка высоты — единственное, что разделяет эры, за исключением разгона и перехода Era 2, которые запускаются состоянием в пределах границ по высоте. Новая эра может добавлять правила и типы записей; она никогда не меняет смысла существующего блока ниже своей высоты активации.

Эры 2 и S выходят каждая собственным релизом через хардфорк, со спецификацией, состязательной сетью разработки (devnet) и рецензированием. Era 2 открывает внесение залога по высоте, начинает свой разгон по стейку с крайним сроком и выполняет переход, когда разгон завершается: самое раннее, когда может произойти переход, — эпоха 303 (10-й месяц), а крайний срок начала гарантирует, что к концу 9-го месяца разгон уже идёт. Для порога в 10 % стейк — это активный стейк вместе с его делегированиями, а предложение — выпущенные монеты, и то и другое на момент открытия эпохи. Порог может приостановить переход за пределы эпохи 363; чего он сделать не может — так это помешать ему начаться.

Стейк. Минимальный залог — 1 000 ZCD, и стейк участвует через одну эпоху после внесения в залог. У залога, который только делегирует, минимум меньше; он фиксируется релизом эры, и такой залог никогда не покидает распоряжения делегатора. Минимум выражен в ZCD, а не в долларах, потому что никакое правило не может прочитать цену; он пересматривается на границах эр по мере роста потолка блока.

Эра 0 намеренно крошечная, а эра 1 сведена к тому, что нужно архитектуре: без ключей администратора нет кнопки паузы, поэтому каждая строка консенсуса — это строка, которая может убить сеть без возможности исправления. Недостижимый код консенсуса — это непроверяемый код консенсуса, и он не поставляется. Эра, которая не докажет, что стоит своей сложности, никогда не запускается.

Переход осуществим, потому что свёртке безразлично, кто упорядочивает: Era 2 меняет то, чья подпись стоит на заголовке.

Рубеж Era 1. Блок рубежа записывает скомпилированные константы эры в ячейки протокола, так что с этого момента корень состояния обязывается к ним. В первые 240 блоков после рубежа сертификат, выполняющий SETSEQ, должен нести TTL, превышающий рубеж не менее чем на 240 блоков, и ждать, пока не войдёт в допустимый диапазон.

Era 2 и высоты, измеряющие время. После перехода высота растёт в шесть раз быстрее. Каждую константу генезиса, которая на самом деле является длительностью (окончание доли основателя, созревание coinbase, максимальный TTL, окно интента, глубина отката, окно медианного времени, срок жизни записи каталога), Era 2 читает в той единице, которую она измеряет: высота 3 153 600 — это 1 095 эпох по 2 880, и эра заканчивает долю основателя на эпохе 1 095. Таблица параметров генезиса не меняется, потому что корень консенсуса проходит по каждому параметру, и сдвиг одного из них сдвинул бы идентификатор генезиса каждой действующей сети; константы эры скомпилированы, как у Era 1.

7. Параметры#

Набор параметров заморожен в генезисе, встроен в каждый исполняемый файл при компиляции и изменяем только хардфорком. Его корень консенсуса входит в каждую подпись. zcd params выводит скомпилированные значения сборки; zcd genesis выводит сеть, идентификатор цепочки, хеш параметров, идентификатор генезиса и корень состояния.

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

Константы Era 2 скомпилированы по той же причине.