Parano1d v2. От живой стоимости к живым правам

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

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

В статье «Децентрализация во времени» я описывал возможность распространить proof-carrying State с денег на права и обязательства. В Parano1d v2 для этого появляется конкретное контрактное ядро: живой выход фиксирует программу, правила доступа и текущие счётчики, а допустимость каждого изменения входит в общее рекурсивное доказательство блока.

Текущее право несёт проверяемую связь со всеми допустимыми переходами, которые его создали.

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

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

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

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

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

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

Что остаётся в State

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

Каноническое открытие ABI 3 занимает 699 байт. В него входят 16 инструкций, два счётчика, полномочия основной и возвратной ветвей, получатели при закрытии, высота границы и ограничения расходования. Программа, политика и текущее состояние связываются отдельными доменами хеширования.

При продолжающем вызове программа и политика сохраняются, а счётчики могут измениться. Новое значение счётчика меняет обязательство и адрес. GUI объединяет связанные состояния по неизменным условиям, чтобы пользователь работал с одним понятным контрактом. В консенсусе по-прежнему проверяется точное обязательство конкретного состояния.

Номер слота также недостаточен для идентификации входа. После траты слот может занять другой выход. Пара slot_index и creation_id отличает действующий экземпляр от прежнего содержимого того же места.

Условия и деньги появляются отдельно

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

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

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

Кто и что может сделать

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

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

Сумма входа сохраняется между остатком, выплатой и комиссией. Живой выход обязан содержать положительную стоимость: контракт нельзя оставить бесплатной записью с нулевым балансом.

Исполнение внутри доказательства блока

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

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

Таким образом, контракт не держится на доверии к предварительной проверке mempool или заявлению майнера об успешном исполнении. Его правила входят в доказательство, на основании которого блок становится допустимым.

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

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

Постквантовая защита живых прав

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

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

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

В модели безопасности v2 опубликована ресурсная оценка уровня NIST PQC Category 1 при явно заданных предпосылках. Они относятся к композиции корней доказательств, идеальному компилятору, конкретной конструкции Poseidon2b, учёту квантовых ресурсов и честной предобработке аутентифицированных старых матриц. Вывод оценки учитывает авторизацию кошелька, рекурсивную связь с прошлым и редукции, позволяющие отказаться от старых матриц. Удаление данных не исключает связанные с ними криптографические риски из расчёта.

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

Пример: ограниченный бюджет программы

Вернёмся к автоматизированному клиенту. В его экземпляр внесено 100 NOID. Политика разрешает выплату не более 3 NOID за вызов, ограничивает комиссию, сохраняет резерв и предусматривает отдельный ключ возврата. Программа дополнительно задаёт бюджет 10 NOID за период, включая комиссии.

Два постоянных счётчика хранят остаток бюджета и следующую границу периода. Выплата 2 NOID с комиссией 0,01 NOID оставит 97,99 NOID в экземпляре и 7,99 NOID доступного бюджета. Это разные величины, и переход должен доказать обе.

Следующий вызов не может снова объявить бюджет равным 10. Его открытие обязано совпасть с живым обязательством после предыдущей операции. Выплата выше ограничения не пройдёт. Повторная трата того же экземпляра не пройдёт. Подстановка другой программы также не пройдёт.

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

После удаления старых тел остаток 7,99 всё ещё аутентифицирован текущим обязательством и рекурсивным доказательством. Для проверки его допустимости будущему узлу не нужен архив первого платежа.

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

Что умеет программа

В распоряжении автора 16 последовательных инструкций, два постоянных u64-счётчика и два временных регистра. Временные регистры начинают каждый вызов с нуля. Последующие инструкции видят результаты предыдущих.

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

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

Для пользовательских программ важно различать физические позиции выходов. При продолжении выход 0 хранит преемника, а выход 1 — выплату. При закрытии выход 0 уже платит получателю закрытия, а выход 1 отсутствует. Поэтому программа с обоими режимами должна правильно обрабатывать флаг terminal: смысл слова «выплата» в ответе RPC не всегда совпадает с операндом физического выхода 1.

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

Шесть готовых сценариев

Шаблон — удобный способ получить программу общего ядра. Его название не является записью в разрешительном списке консенсуса.

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

Для любого действия по расписанию нужна авторизованная транзакция. Её отправляет кошелёк, бот или сервис. Фонового таймера, который сам просыпается и выплачивает средства, в консенсусе нет. Поле max call fee со значением 1 NOID задаёт верхнюю границу комиссии; создание условий не стоит 1 NOID.

State, квитанция и журнал

Здесь особенно полезно разделить три вопроса.

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

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

Две стороны, одна из них офлайн

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

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

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

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

Поэтому резервная копия включает секрет кошелька и публичные данные контрактов. Секрет восстанавливает полномочия. Условия и квитанции восстанавливают сведения, необходимые для их использования. Если все стороны утратят открытие, а в сохранённых телах и квитанциях его не окажется, хеш не восстановит программу.

Как этим пользоваться

В официальном GUI появился раздел F7 Contracts. Create готовит шаблон или пользовательскую программу и позволяет проверить пополнение. My Contracts показывает сохранённые контракты, их балансы, действия, правила и журнал. Open File открывает условия, обновления и контрактные квитанции. Настройки находятся на F8.

Через CLI и RPC доступны те же основные процессы. Важная точка интеграции — предварительный просмотр: previewObjectCall возвращает конкретный вход, комиссию, выходы, преемника и условия проверки перед отправкой. Изменение вершины может изменить высоту включения, доступный вход, ветку или размещение выходов. Изменившуюся транзакцию нужно вновь просмотреть и авторизовать.

Отправленная операция ещё не подтверждена. Другой вызов может первым потратить тот же экземпляр; допустимый реорг может заменить недавнее подтверждение. Кошелёк проверяет канонические заголовки и живое состояние. Граница финальности остаётся 18 блоков, максимальный откат — 17.

Практический вход — инструкция GUI, руководство API и описание ABI. Приложению в пределах этого ядра не требуется отдельная регистрация или новая матрица сети.

Границы, на которых можно строить

Оба класса v2 имеют предел 63 вызова и 504 входа. У Small 63 пользовательские страницы, у Large — 206. Вызов занимает страницу и вход, поэтому Large может вместить 63 вызова и ещё 143 одностраничных платежа в общем лимите входов. Дополнительная обязательная системная страница при необходимости занимает одну позицию.

При цели 30 секунд предел составляет 2,1 вызова в секунду. У программы нет межконтрактных вызовов, произвольной базы данных и обновления кода на месте. Разрешённый перевод может перенести стоимость в новые условия. Добавление новых операций ядра потребует отдельной работы над консенсусом.

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

Проверяемое настоящее становится программируемым

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

Так появляется путь от proof-native денег к приложениям. Действующие обязательства занимают живое состояние. Исполненные обязательства не превращаются автоматически в вечный архив исполнения для каждого будущего узла. Заинтересованные стороны сохраняют нужные свидетельства, а новый участник по-прежнему может самостоятельно проверить нынешнюю сеть.

Живая стоимость дала основу. Живые права позволяют задавать правила её использования внутри того же независимо проверяемого настоящего.