Глоссарий

Справочник терминов, которые встречаются в документации, REST API и интерфейсах Pert. Термины сгруппированы по доменам; внутри домена идут от общих понятий к частным.

Платформа и доступ

Pert

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

Компания

Юридическое лицо — клиент Pert. Может владеть несколькими workspace (например, разные подразделения, продукты, тестовое и боевое окружения).

Workspace (рабочее пространство)

Изолированная единица учёта внутри Pert: набор vault, кошельков, пользователей, политик, AML-настроек и устройств-подписантов. Ключи разных workspace друг с другом не пересекаются; роли, политики и балансы — изолированы. Подробнее — Структура кошельков.

Workspace Owner (владелец)

Пользователь с ролью OWNER — инициатор создания workspace. Имеет полный набор прав внутри своего workspace, включая создание бэкапа ключей и добавление новых подписантов.

Пользователь workspace

Учётная запись внутри workspace с одной из ролей: OWNER, ADMIN, NON_SIGNING_ADMIN, SIGNER, APPROVER, EDITOR, VIEWER. Роли определяют, что пользователь может видеть и делать: подписывать транзакции, аппрувить, управлять политиками, просматривать историю.

Сервисный аккаунт (service account)

Машинный пользователь для интеграции по API. Не имеет мобильного устройства, аутентифицируется через API-ключ. Используется вашим бэкендом для автоматизированной работы с Pert API.

API-ключ (API key)

Пара ключей ed25519, привязанная к сервисному аккаунту. Приватный ключ хранится у вас и подписывает JWT для авторизации; публичный — загружается в Pert. См. Авторизация и Начало работы.

Устройство (device)

Носитель одной из MPC-долей пользователя: либо мобильное приложение Pert Mobile (для пользователей с правом подписи), либо Co-Signer — headless-инстанс, разворачиваемый клиентом на своей стороне для API-сценариев. Привязывается к учётной записи через процесс pairing.

Pairing (привязка устройства)

Процесс ассоциации нового устройства с пользователем workspace. Устройство генерирует ключевую пару, регистрирует публичный ключ в Pert, после чего владелец workspace выдаёт ему MPC-долю.

Хранение активов

Vault (vault-аккаунт)

Логическая группа кошельков внутри workspace, объединённая общим набором MPC-ключей и общим назначением (например, «казначейство», «горячий кошелёк», «выплаты»). Большинство политик и многих ролей выдаются именно на vault. Подробнее — Структура кошельков.

Wallet (кошелёк)

Контейнер активов одного блокчейна внутри vault: баланс, адрес для приёма средств и история транзакций по конкретной сети/ассету. Бывает двух типов: внутренний (custodial, ключами владеет MPC-схема Pert) и внешний whitelisted (зарегистрированный адрес контрагента). См. Структура кошельков.

Адрес (address)

Конкретный on-chain адрес внутри кошелька. На каждый внутренний кошелёк приходится ровно один адрес — он создаётся вместе с кошельком и далее переиспользуется для всех поступлений, в том числе для UTXO-сетей вроде BTC. Адрес выводится из ключей vault по детерминированному HD-пути (BIP-32).

Whitelisted wallet / адрес

Внешний кошелёк или адрес контрагента, заранее добавленный в whitelist workspace. На whitelisted-адреса можно настроить упрощённый аппрув или автоматический пропуск через политику; выводы на любые другие адреса (см. one-time) обычно требуют более строгого подтверждения.

One-time address

Свободно введённый адрес назначения, не входящий в whitelist. На оценке политик такой адрес учитывается отдельно и обычно требует более строгого аппрува.

Asset

Описание токена/монеты: тикер, decimals, блокчейн, контракт (для ERC-20/TRC-20 и т. п.). Один wallet может содержать несколько asset (нативная монета + токены этой же сети).

Smart-contract (custom asset)

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

Balance

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

Криптография и подписание

MPC (Multi-Party Computation)

Криптографический протокол вычислений над секретом, разделённым между несколькими сторонами. Никто из участников не имеет полного ключа — подпись формируется в результате взаимодействия минимум t из n сторон (threshold). Это основа некастодиальности Pert.

MPC-CMP

Конкретная схема ECDSA MPC (Canetti-Makriyannis-Peled, 2020) с параллельным pre-signing и быстрым sign-online. Используется во всех узлах MPC-схемы Pert.

Доля ключа (key share)

Часть приватного ключа, хранимая одной MPC-стороной. По отдельной доле невозможно ни восстановить ключ, ни подделать подпись. Доли распределяются при создании vault и пересчитываются при добавлении новых подписантов (без изменения публичного ключа).

Keygen / Sign / Refresh

Три основные процедуры MPC-CMP:

• Keygen — совместная генерация нового ключа (доли распределяются при создании vault).
• Sign — совместное подписание транзакции.
• Refresh — пересборка долей без изменения публичного ключа (используется при добавлении нового подписанта).

Threshold (порог)

t-of-n — минимальное число долей, нужное для подписи. В типовой конфигурации Pert схема — 2-of-3: две доли на стороне Pert (в защищённой серверной среде) и одна доля на стороне клиента — либо на headless-устройстве Co-Signer, либо в мобильном приложении Pert Mobile у пользователя-подписанта.

Подписант (signer)

Пользователь workspace с правом подписи и привязанным устройством. Технически — владелец одной MPC-доли. На стадии подписания получает запрос «подписать транзакцию» на своё устройство и подтверждает операцию вручную (Pert Mobile) или автоматически по политикам (Co-Signer).

Sighash

Хэш payload транзакции, который непосредственно подписывается. Для EVM/TRON — один хэш на транзакцию; для BTC — по одному на каждый UTXO-вход.

Derivation (HD path)

BIP-32-путь, по которому из master-доли получается доля для конкретного адреса. Позволяет MPC-схеме формировать подписи для нужного дочернего ключа, не собирая мастер-ключ.

Backup ключей

Экспорт зашифрованных MPC-долей в файл, который владелец может хранить у себя. Шифруется на публичный ключ из desktop-приложения Pert Backup и используется для восстановления при потере устройств-подписантов.

Транзакции

Transaction (транзакция)

Учётная запись об исходящем выводе средств (withdrawal) или входящем зачислении (deposit). Хранит источник, назначение, актив, сумму, статус и историю переходов.

Withdrawal

Исходящая транзакция: создаётся вашим приложением через POST /transaction, проходит проверку политик и AML, после аппрувов подписывается по MPC и отправляется в блокчейн.

Deposit

Входящая on-chain транзакция, обнаруженная Pert на одном из адресов workspace. Создаётся сразу с финальным статусом — никаких аппрувов и подписей со стороны клиента не требуется.

Статусы транзакции

Жизненный цикл исходящей транзакции описывается набором статусов (created, awaiting_approvals, awaiting_signature, awaiting_broadcast, broadcast, finished, declined, frozen и т. п.). Текущий статус и история переходов доступны через REST API и приходят событиями в webhooks.

Approval (аппрув)

Подтверждение исходящей транзакции одним из назначенных аппруверов. Подписывается устройством аппрувера. Сколько и каких аппрувов нужно — определяет политика workspace.

Approval set / quorum

Набор аппруверов, из которых нужно собрать t подписей для пропуска транзакции. Политика может требовать нескольких независимых наборов (например, «2-of-3 финансистов и 1-of-2 руководителей»).

Freeze / Unfreeze

Freeze — приостановка транзакции (исходящей) или vault (для входящих) вручную оператором или автоматически AML-правилом. Заморозить можно только транзакцию до этапа подписания и broadcast. Unfreeze возвращает предыдущий статус.

Broadcast

Отправка подписанной транзакции в блокчейн. После broadcast транзакция считается отправленной; финализация наступает после подтверждения сетью (см. Reconciliation).

Reconciliation

Сверка статуса транзакции в блокчейне с локальным состоянием Pert. По факту достаточного числа сетевых подтверждений транзакция финализируется (finished) либо отклоняется (declined).

Idempotency-Key

Заголовок X-Idempotency-Key на POST /transaction: уникальный ключ, сохраняемый в Pert. Повторный запрос с тем же ключом вернёт уже существующую транзакцию (HTTP 409) — это позволяет безопасно ретраить запросы.

Политики и AML

Policy (политика)

Правило обработки транзакций, заданное на уровне workspace. Описывает условия (источник, назначение, сумма, частота, актив) и действие (allow / require approval / block). Подробнее — Политики.

Transfer policy

Подкласс политик, оценивающих исходящие транзакции. Может ссылаться на vault, whitelisted-кошельки и one-time адреса — например, «выводы на whitelisted из vault payouts до 10 000 USD/сутки проходят без аппрува, всё остальное — с аппрувом 2-of-3». См. Transfer-политики.

AML rule (pre-screening / post-screening)

Правило AML-провайдера, делящееся на:

• Pre-screening — локальная проверка адреса назначения до вызова провайдера, позволяет сэкономить запросы. См. AML pre-screening.
• Post-screening — обработка результата провайдера, в том числе автоматическая заморозка входящего депозита с высоким риск-скором. См. AML post-screening.

Limit / Timeframe

Накопительные ограничения политик: сумма или число операций за заданное окно времени (например, «не более 50 000 USD исходящих за 24 часа»). Лимиты освобождаются обратно, если транзакция была отклонена, заморожена или истёкла.

Approval requirement

Запись о том, какие аппруверы и в каком количестве должны подписать конкретную транзакцию. Формируется по политикам workspace в момент оценки транзакции.

Интеграция

Webhook

HTTP-callback на ваш URL: Pert отправляет события о создании транзакции, смене статуса, депозите и других изменениях. Доставляется с повторными попытками и подписан на стороне Pert, чтобы вы могли убедиться в подлинности уведомления. Можно повторно проиграть пропущенные события через replay. См. Webhooks.

Подпись webhook

Криптографическая подпись тела события, передаваемая в HTTP-заголовке. Позволяет вашему приложению удостовериться, что событие пришло от Pert и не было изменено. См. Подпись webhook.

Replay (повторное проигрывание)

Механизм повторной отправки уже доставленных webhook-событий за выбранный интервал. Используется при сбое на стороне получателя или при первичной выгрузке истории. См. Replay.

Приложения Pert

Pert Console

Web-интерфейс клиента: управление workspace, vault, кошельками, политиками, аппрувами, whitelist'ом, пользователями и сервисными аккаунтами.

Pert Mobile

Мобильное приложение пользователя-подписанта. Хранит долю MPC-ключа, подтверждает подписание и аппрувы вручную владельцем устройства — последняя линия обороны некастодиальной модели.

Co-Signer

Headless-устройство клиента, разворачиваемое на собственной инфраструктуре. В отличие от Pert Mobile действует автоматически на основании политик — используется для API-интеграций и высокочастотных операций без участия человека на каждой подписи.

Pert Backup

Desktop-приложение для безопасного создания и восстановления бэкапа MPC-долей. Шифрует доли публичным ключом, который никогда не покидает рабочую станцию владельца.