Справочникdocs/reference/client-native-rpc.md

Нативные операции с клиентской авторизацией

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

Метод использует локальный доступ владельца к RPC. Веб-сервис обращается к ноде через loopback и предоставляет собственный ограниченный API приложения по HTTPS.

Подготовка

Параметры: [owner, request, expected_parent_hash?]. Запрос использует действия нативных операций. Суммы являются десятичными целочисленными строками в минимальных единицах. Необязательный хеш родителя фиксирует канонический снимок, ожидаемый вызывающей стороной.

json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "paranoid_prepareNativeIntent",
  "params": [
    "<owner address>",
    {
      "action": "trade",
      "asset_id": "<64-character asset ID>",
      "buy": true,
      "gross_input": "1000000",
      "slippage_bps": 1000
    },
    "<canonical parent hash>"
  ]
}

Ответ имеет тип NativeClientPlan:

Поле Значение
schema_version Версия схемы ответа, сейчас 1
plan_id Коммитмент BLAKE3 к родителю, владельцу, якорю, запросу и намерению без авторизации
intent_id Логический ID операции или ID авторизации профинансированной сделки
owner Адрес, секрет которого авторизует операцию
candidate_height Высота для выбора правил и планирования комиссии
parent_header_hex Полный канонический 212-байтовый заголовок родителя
chain_id Идентичность сети нативных операций
epoch_anchor Якорь транзакции для высоты кандидата
owner_authorization_version Конструкция, выбранная правилами кандидата
intent_kind operation или trade
unsigned_intent_hex Каноническое намерение формата передачи с пустой авторизацией
review Запрос, идентичность State, точные суммы, комиссии и условия операции

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

Подготовка читает проверенный State и локальный мемпул. Адрес, ключ, локальная активность и резервирования кошелька ноды сохраняются. Несколько клиентов могут запрашивать планы для своих адресов. План представляет снимок без резервирования входов и выходных слотов. Их доступность проверяется при приёме завершённого намерения.

Проверка и авторизация на клиенте

  1. Проверьте schema_version, сеть, заголовок родителя, якорь эпохи и правила кандидата по выбранному приложением соединению с нодой.
  2. Декодируйте unsigned_intent_hex как NativeIntent для operation или TradeOwnerIntent для trade. Проверьте, что авторизация пуста.
  3. Пересчитайте каноническое утверждение владельца и intent_id. Сопоставьте владельца, точное действие, идентичности активов, источники финансирования, получателей, выходы и комиссию с одобренной пользователем операцией. Для торговли проверьте полный вход, минимальный выход, предел комиссии и диапазон допустимости.
  4. Создайте капсулу Owner с выбранной owner_authorization_version. Функции авторизации активов, финансовых операций и торговли проверяют соответствующие публичные отношения перед доказательством.
  5. Локально проверьте готовую капсулу. Поместите байты её канонического пакета в authorization_bytes и сериализуйте то же намерение.
  6. Передайте байты в paranoid_submitTxIntent. Сохраните ID операции и подтверждённый чек для отслеживания и экспорта.

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

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

Воспроизведение идентичности плана

Вычислите BLAKE3 следующей последовательности байтов:

text
"NOIDNativeClientPlan1"
|| parent_header_bytes
|| owner_bytes
|| epoch_anchor_bytes
|| request_json_length_u32_le
|| request_json_bytes
|| unsigned_intent_bytes

request_json_bytes является компактной кодировкой Serde для NativeWalletRequest в порядке объявления полей. Идентичность плана позволяет клиенту сохранять точный проверенный предпросмотр. Капсула Owner связывает утверждение авторизации канонического намерения.

Снимок и границы ресурсов

Несовпадение expected_parent_hash возвращает ошибку -32041 с текущими height и block_hash. Обновите State и повторите подготовку. Планировщик также проверяет привязку записей финансирования к вершине и снимок ожидающих политик.

Кодировка запроса ограничена 32 KiB. Поиск финансирования NOID читает максимум 16 384 проверенных источника. Консолидация уменьшает их число у владельца с раздробленными средствами. Проверки нативных страниц, действий, рынков и комиссий используют обычный бюджет приёма установленного runtime.

Значения по умолчанию и правила срока торговли совпадают с API нативного кошелька. Передайте slippage_bps: 1000 для допуска 10%, принятого в десктопном GUI, или укажите явный минимальный выход. Отслеживайте операцию через getMempoolEntry и канонические чеки. После удаления истёкшей неисполненной политики из мемпула её неизрасходованные источники могут финансировать новый план.

Техническая документация ParanO(1)dПоведение консенсуса определяется исходным кодом.