Цифровая подпись — криптографический механизм, который доказывает, что сообщение/транзакцию создал владелец соответствующего приватного ключа и что данные не изменялись. В блокчейнах подпись подтверждает право распоряжения средствами без раскрытия секретов: сеть проверяет подпись по публичному ключу и принимает транзакцию в блок (см. блокчейн, транзакция).
Базовые моменты
- Пара ключей. Подписант использует приватный ключ; проверяющий — публичный ключ (см. также кошелёк).
- Неподделываемость и целостность. Подпись неразделима с конкретным сообщением (обычно — хеш от данных). Попытка изменить данные ломает проверку.
- Невозможность отказа. Сторона, обладающая приватным ключом, не может правдоподобно отрицать создание подписи.
- Эффективная проверка. Узлам достаточно публичного ключа и подписи, чтобы проверить её корректность; сам приватный ключ сеть никогда не видит.
- В блокчейнах. Подписывается сериализованная «представляемая к подписи» форма транзакции (хеш) с учётом правил сети; детали зависят от протокола.
Как это работает (упрощённо)
- Хеширование. Из сообщения M получают дайджест h = H(M).
- Подписание. Схема подписи берёт h и приватный ключ sk, выдавая подпись σ.
- Проверка. Любой может вычислить Verify(pk, h, σ) → true/false с публичным ключом pk.
# Псевдокод (абстрактно) h = H(M) σ = Sign(sk, h) ok = Verify(pk, h, σ)
Важно: при подписи транзакций учитываются поля комиссии, входов/выходов, сети и т. п. (см. комиссии, UTXO, nonce). Подпись одного и того же «визуально похожего» перевода в другой сети будет иной из-за отличий в структуре/доменных разделителях.
Алгоритмы подписи (в блокчейнах)
| Алгоритм | Где встречается | Особенности |
|---|---|---|
| ECDSA (secp256k1) | Исторически в Bitcoin, совместим с EVM-сетями (Ethereum). | Требует случайного/детерминированного nonce k; повтор/утечка k раскрывает приватный ключ. Возможна «мalleability», смягчаемая правилами сериализации. |
| Schnorr (BIP-340) | Современные расширения в BTC-экосистеме. | Простая агрегация подписей (мульти-подписи), лучшие математические свойства, детерминированность k. |
| EdDSA (Ed25519 и др.) | Используется во многих L1/L2 за пределами EVM. | Быстрая проверка, детерминированный nonce, простая реализация; кривая отличается от secp256k1. |
Независимо от алгоритма, безопасность опирается на стойкость эллиптических кривых/хеш-функций и корректную реализацию кошелька/устройства.
Риски и уязвимости
- Nonce в подписи. В ECDSA повтор или предсказуемость случайного k → раскрытие приватного ключа. Решение: детерминированный k по RFC 6979 или аппаратная генерация.
- Мalleability (изменяемость) подписи. Ранние форматы позволяли менять представление подписи без изменения смысла; протоколы фиксируют каноническую сериализацию и правила проверки.
- Сайд-чейны и мосты. Подписание «на неверной сети»/домена (нет domain separation) или ошибка моста может приводить к неожиданным последствиям (см. кроссчейн-мосты).
- UX-фишинг. «Слепые» подписи сообщений/доверенных разрешений могут давать злоумышленнику доступ к активам. Читайте подсказки кошелька и проверяйте адреса/контракты.
- Supply-chain риски. Компрометация библиотек/прошивок кошельков и клиентов подписи (см. supply-chain атаки).
Практика / чек-лист
- Аппаратная подпись. Для значимых сумм используйте устройство с дисплеем: проверяйте на нём адреса/суммы перед подтверждением (см. холодный кошелёк).
- Детерминированный nonce. Предпочитайте кошельки, реализующие RFC 6979 или EdDSA; не подписывайте в среде с «плохой» энтропией.
- Минимум разрешений. В dApp выдавайте только необходимые allowance, регулярно отзывйте лишние (см. кошелёк, смарт-контракты).
- Доменные разделители. Подписывайте только сообщения/tx, которые кошелёк чётко интерпретирует (EIP-712 и аналоги).
- Разделение ключей. Рабочий адрес для ежедневных действий — отдельно от адресов хранения; ключи/сид офлайн (см. seed-фраза).
- Логи и доказательства. Храните идентификаторы подписанных tx (tx hash) и, при необходимости, подписи/сообщения для аудита.
Частые вопросы (FAQ)
Подпись «подтверждает личность»? Она подтверждает владение ключом, а не реальную идентичность. Привязка к личности происходит офчейн (KYC, аккаунты и т. п.).
Можно ли одной подписью подтвердить множество входов? Да, в некоторых схемах (напр., Schnorr-агрегация) используют мультиподписи/агрегацию для уменьшения размера и упрощения верификации.
Почему мой кошелёк просит «подписать сообщение» без комиссии? Это офчейн-подпись (например, логин, EIP-712). Она не попадает в блокчейн и не требует газа, но может иметь последствия (разрешения, согласия). Проверяйте текст и домен.
Может ли кто-то «перенести» мою подпись на другую сеть? Если протоколы не используют доменные разделители/разные форматы, риск replay-подписей выше. Современные схемы включают идентификатор сети/домена в данные для подписи.
Что произойдёт, если подпись «сломается» при передаче? Проверка не пройдёт, узлы отклонят транзакцию. Повторите отправку из кошелька.