Перейти к содержанию

Ключи и подписи

Криптографический слой COOPOS наследуется от EOSIO: идентичность в сети выражается через разрешения аккаунта и публичные ключи в структурах authority, а операции с цепью подтверждаются подписью упакованной транзакции (или отдельных её частей в специальных режимах).

Асимметричная пара

  • Приватный ключ хранится у субъекта (или в keosd / HSM) и никогда не публикуется в цепь.
  • Публичный ключ записывается в состояние аккаунта (в объекте разрешения) и используется узлом для проверки подписи.

Типичные кривые в экосистеме EOSIO: secp256k1 (часто префикс EOS или PUB_K1_ в строковом представлении) и R1 (P-256, префикс PUB_R1_). Конкретный набор поддерживаемых кривых зависит от сборки узла и настроек цепи; для интеграций важно согласовать формат с кошельком и библиотекой подписи.

Строковый вид приватного ключа в инструментах часто начинается с 5 (наследие формата WIF-подобных кодировок для K1); это секрет — не использовать в примерах в продакшене и не передавать по незащищённым каналам.

Что именно подписывается

Подпись строится над каноническим двоичным представлением транзакции (после сериализации по правилам цепи), с учётом цепочного идентификатора (chain ID): фактически подписывается хеш от соответствующего набора полей. Несколько подписей в массиве signatures соответствуют нескольким требуемым ключам/весам в разрешениях (мультисиг, разные actor@permission на действиях).

Узел проверяет:

  1. Корректность подписи относительно заявленных ключей.
  2. Соответствие суммарных весов порогу (threshold) для каждого требуемого permission у каждого действия (с учётом иерархии owner → active и кастомных имён).

Подробнее о том, какие поля входят в транзакцию и как формируется авторизация действий: Действия и транзакции.

Сбор нескольких подписей до отправки в сеть (контракт eosio.msig и команды cleos): мультисиг в руководстве cleos.

Связь с разрешениями аккаунта

Публичные ключи не «привязаны к аккаунту напрямую»: они входят в required_auth конкретного имени разрешения (owner, active, кастомные). Смена ключей — это транзакция на обновление authority (обычно с @owner для критичных изменений). Иерархия и делегирование: Аккаунты и разрешения.

Разрешение eosio.code

Для inline-действий контракт подписывает от имени своего аккаунта не отдельным пользовательским ключом, а за счёт специального права eosio.code в составе authority (по политике безопасности аккаунта). С точки зрения криптографии пользовательская подпись уже была на исходной транзакции; дальнейшая цепочка исполняется внутри одной атомарной транзакции.

Практика: keosd и cleos

keosd изолирует приватные ключи и выполняет подпись по запросу cleos или API кошелька. Это не часть консенсуса, а способ не вшивать секреты в приложения. См. keosd.

Юридический и прикладной контур

Цифровая подпись транзакции доказывает владение ключом, связанным с разрешением в цепи. Сопоставление «кто человек за аккаунтом» выполняется вне цепи (регистрация у кооператива, договор с провайдером). В Введении описан разделение ролей: блокчейн хранит обезличенные идентификаторы, кооператив — идентификацию участника.

Куда дальше