Жизненный цикл и механика
1. Задайте публичные условия
Opening описывает программу, два постоянных счётчика, две ветки авторизации, двух получателей при закрытии, срок и лимиты расходования. Адрес — обязательство Poseidon2b к этим условиям и счётчикам. Подготовить, изучить или передать условия можно без публикации транзакции.
Продолжающий вызов не меняет программу и правила. Меняться могут только два счётчика. Поэтому новое состояние может иметь другой адрес, сохраняя те же неизменяемые правила контракта. Кошелёк объединяет такие состояния для удобства; идентичность в консенсусе по-прежнему задаётся точным обязательством.
2. Пополните экземпляр
Пополнение — обычный авторизованный платёж на адрес opening. Он создаёт живой
выход с суммой, обязательством и новым creation_id. Файл условий сам по себе
не доказывает наличие депозита. Найдите выход в проверенном State либо проверьте
чек пополнения и затем запросите State.
Каждый депозит независим. Два платежа на один opening создают два экземпляра со своими суммами и счётчиками. Они не пополняют единый общий бюджет и не объединяются автоматически. Один вызов расходует один экземпляр. Обычный баланс кошелька не считает выходы на контрактное обязательство непосредственно расходуемыми выходами вашего адреса; используйте баланс самого контракта.
Официальный кошелёк разрешает пополнение, когда следующий блок-кандидат использует v2. Комиссия показана отдельно перед подтверждением. Сохранение условий без пополнения бесплатно.
3. Проверьте следующий вызов
Укажите opening и точную пару (slot_index, creation_id) депозитного выхода.
Одного индекса повторно используемого слота недостаточно. На высоте кандидата
h ветка выбирается по зафиксированному сроку:
| Условие | Адрес авторизации и получатель при закрытии |
|---|---|
h < deadline_height |
Ветка получения — claim |
h >= deadline_height |
Ветка восстановления — recovery |
В каждой ветке отдельно разрешено продолжение и/или закрытие. Уполномоченная сторона создаёт свежую wallet capsule, доказывающую знание секрета её обычного адреса и привязанную ко всей логической транзакции. Владельцем входа является обязательство контракта; выбранный адрес авторизует его использование.
previewObjectCall строит предлагаемое тело, высоту включения, точную комиссию,
платёж и преемника. При отправке используйте все защитные поля из предпросмотра.
Изменение вершины может поменять высоту, ветку, доступность входа или позиции
выходов. Изменённую транзакцию нужно заново проверить и подтвердить.
4. Продолжите или закройте
| Вызов | Вход | Выход 0 | Необязательный выход 1 |
|---|---|---|---|
| Продолжение без платежа | Точный выход контракта | Контракт-преемник | Нет |
| Продолжение с платежом | Точный выход контракта | Контракт-преемник | Разрешённые получатель и сумма |
| Закрытие | Точный выход контракта | Остаток получателю текущей ветки | Нет |
Каждый вызов занимает одну физическую страницу. Комиссия оплачивается из
расходуемой суммы контракта. Продолжение соблюдает max_fee, max_payout и
min_retained; лимит платежа не включает комиссию. Закрытие также подчиняется
max_fee и программе, но лимиты платежа и резерва для продолжения не ограничивают
вывод остатка. Программа может накладывать дополнительные условия на оба режима.
unrestricted_payout_recipient относится только к платежам с продолжением.
Он не меняет получателя, заданного для закрытия. Каждый живой выход должен иметь
положительную сумму: контракт с нулевой стоимостью не сохраняется как отдельная
бесплатная запись хранения.
Стоимость сохраняется: вход равен остатку плюс платежу плюс комиссии. При закрытии сохраняемый остаток равен нулю, получателю достаётся вход минус комиссия. Обычные правила комиссии и сжигания за рост State применяются к реальным выходам.
5. Доказательство и подтверждение
Мемпул выполняет проверки допуска и резервирует конфликтующие ресурсы. В блоке вызовы контрактов образуют канонический префикс перед обычными пользовательскими платежами. Отношение v2 связывает opening с расходуемым обязательством, доказывает выбранную авторизацию, исполнение целочисленной программы и точное изменение State. Рекурсивный терминал переносит корректность блока дальше.
Отправка ещё не является подтверждением. Ожидающий преемник остаётся кандидатом до принятия транзакции. Конкурирующий вызов может первым потратить тот же экземпляр, а неглубокая реорганизация — заменить подтверждённую операцию. Кошелёк повторно проверяет канонические заголовки и текущий State, не полагаясь на сохранённый статус GUI. Финальность остаётся 18 блоков; допустим откат не более 17 блоков.
6. Сохраните живое право и нужные доказательства
После продолжения сохраните opening преемника. После любого вызова переносимый чек может сохранить исходные условия, операцию и доказательство. Он остаётся проверяемым после удаления обычного тела блока, но не доказывает, что преемник до сих пор не потрачен.
Наблюдатель с известными условиями проверяет баланс через State. Если он пропустил уже удалённый вызов, изменивший счётчики, для поиска преемника понадобится новый opening или чек. Точное поведение журнала и импорта описано в чеках и восстановлении.