---
title: "Подписи BLS"
description: "Руководство по проверке подписей Boneh-Lynn-Shacham, режимам агрегации, наборам шифров, защите от вредоносных ключей, применению в консенсусе Ethereum и рискам реализации."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Подписи BLS
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Подпись Boneh-Lynn-Shacham — цифровая подпись на основе спаривания. В распространенной ориентации секретный ключ `sk` создает публичный ключ `PK = sk * G1`; сообщение `m` отображается в `H(m)` в группе `G2`; подпись `sig = sk * H(m)` проверяется равенством `e(PK, H(m)) = e(G1, sig)`. Конкретные группы, кодировки, набор hash-to-curve и разделение доменов являются параметрами ciphersuite, а не взаимозаменяемыми обозначениями.
BLS обладает необычным эксплуатационным преимуществом: действительные подписи можно сложить в один элемент группы постоянного размера. Это сжимает подписи, но не список подписантов, не доказывает quorum, не определяет уполномоченных валидаторов, не предотвращает equivocation и не обеспечивает финальность консенсуса. Эти свойства задает окружающий протокол.
## Как это работает
1. Зафиксируйте протокол, ciphersuite и версию: кривую, группы публичного ключа и подписи, сериализацию, функцию hash-to-curve, тег разделения домена и построение корня сообщения. Не выводите совместимость только из названия BLS.
2. Создайте `sk` установленной процедурой генерации ключей и получите `PK`. Отклоняйте ноль, бесконечность, поврежденные, неканонические кодировки и точки неверной подгруппы согласно точным правилам `KeyValidate` и десериализации.
3. Сформируйте точные bytes сообщения и домен подписи. В консенсусе Ethereum корень подписи связывает корень объекта SSZ с доменом, выведенным из типа операции и данных fork; отображаемый текст не является подписанным объектом.
4. Подпишите и индивидуально проверьте выбранной схемой. Basic, дополнение сообщения и proof-of-possession по-разному защищаются от rogue key, поэтому их нельзя произвольно смешивать.
5. Выберите агрегатный верификатор по шаблону сообщений. Применяйте `FastAggregateVerify` только к нескольким проверенным публичным ключам, подписавшим одно сообщение, при требуемых предпосылках proof-of-possession; для разрешенного схемой списка ключей и сообщений используйте `AggregateVerify`.
6. Независимо восстановите набор подписантов из данных комитета или participant bitlist, отклоните дублирующиеся и неуполномоченные индексы, примените веса stake или threshold, затем проверьте агрегат. Действительная агрегированная подпись аутентифицирует переданный набор, но не решает, удовлетворяет ли он политике.
7. Сверьте результат с fork choice, условиями slashing, quorum, availability, временем и finality. Сохраните входные bytes, домены, индексы подписантов, версию реализации и test vectors и сравните независимые библиотеки до развертывания.
## Разобранные примеры
- **Сжатие не устраняет данные о составе.** В консенсусе Ethereum публичный ключ BLS занимает `48 bytes`, подпись — `96 bytes`. Для `512` отдельных подписей одного сообщения требуется `512 * 96 = 49,152 bytes`. Одна агрегированная подпись и participant bitlist размером `512-bit = 64-byte` занимают `96 + 64 = 160 bytes`: сокращение на `49,152 - 160 = 48,992 bytes`, или `99.6744791667%`. Публичные ключи валидаторов и соответствие комитету все равно должны быть доступны отдельно.
- **Агрегация одного сообщения.** Зарегистрированные валидаторы `17`, `24` и `91` подписывают одинаковый корень `R`. Их подписи складываются как `sigAgg = sig17 + sig24 + sig91`. Проверка использует упорядоченный проверенный набор `[PK17, PK24, PK91]`, тот же `R` и `FastAggregateVerify`. Действительный результат доказывает, что эти ключи подписали `R` в рамках схемы; отдельное правило определяет их вес и составляет ли три подписанта quorum.
- **Разным сообщениям нужен правильный API.** Ключи `PK1`, `PK2` и `PK3` подписывают разные сообщения `m1`, `m2` и `m3`. Верификатор должен сохранить пары `[PK1, m1]`, `[PK2, m2]`, `[PK3, m3]` и вызвать применимый `AggregateVerify`; замена входов одним сообщением и `FastAggregateVerify` проверяет другое утверждение. В схеме Basic сообщения также должны различаться.
- **Агрегация не является threshold-подписью.** В группе из `8` участников обычная агрегация подписей членов `[1, 2, 4, 6, 8]` дает одну подпись и список из пяти подписантов. Она не превращается в threshold-подпись `5-of-8` под одним групповым публичным ключом. Настоящей threshold-BLS нужны распределенная генерация ключа либо доверенный дилер, индексы долей и правила интерполяции; ее предпосылки доверия и отказа проверяются отдельно.
## Риски
- Использование кривой, ориентации групп или ciphersuite, отличающихся от протокола.
- Подписание разных сериализованных bytes при одинаковом читаемом сообщении.
- Пропуск домена fork, операции или приложения, допускающий replay между контекстами.
- Восприятие истекшего Internet-Draft как неизменного окончательного стандарта.
- Принятие поврежденных, неканонических кодировок или точки бесконечности.
- Пропуск проверок подгруппы и принятие точек неверной кривой или малой подгруппы.
- Самодельный hash-to-curve вместо указанного набора и test vectors.
- Генерация смещенных, нулевых, повторных, раскрытых или предсказуемых секретных ключей.
- Повторное использование ключа в протоколах с разными предпосылками proof-of-possession и домена.
- Агрегация незарегистрированных публичных ключей без требуемой защиты от rogue key.
- Быстрая проверка одного сообщения для разных сообщений или несовпадающих корней.
- Перестановка, дублирование или пропуск связи публичного ключа с сообщением.
- Доверие participant bitlist без проверки членства в комитете и уникальности индексов.
- Подсчет подписей вместо установленных протоколом stake, веса или threshold.
- Предположение, что агрегат указывает, какая индивидуальная подпись неверна.
- Смешение обычной агрегации, multisignatures и threshold signatures.
- Восприятие действительной подписи как доказательства availability, правильности исполнения или finality.
- Игнорирование equivocation, наказуемых сообщений, временных окон или контекста fork choice.
- Зависимость от одной библиотеки, функции CPU или непроверенной оптимизации batch verification.
- Недооценка стоимости спаривания, DoS-входов, побочных каналов, хранения ключей, обновлений и отсутствия постквантовой защиты.
## Распространенные заблуждения
- Агрегированная подпись доказывает участие каждого валидатора.
- Любые публичные ключи и подписи BLS можно безопасно объединить без правил proof-of-possession.
- Агрегация постоянного размера устраняет передачу или восстановление состава подписантов.
- Агрегация BLS и threshold BLS — одна конструкция.
- Действительная подпись BLS делает блок, сообщение моста или протокол экономически безопасным и финальным.
## Связанные темы
- [Криптографическая хеш-функция](/ru/crypto/cryptographic-hash/)
- [Доказательство доли владения](/ru/crypto/proof-of-stake/)
- [Пороговая подпись](/ru/crypto/threshold-signature/)
## Источники
- [BLS Signatures](https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-06) - Internet Research Task Force (accessed: 2026-08-12)
- [RFC 9380: Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) - RFC Editor (accessed: 2026-08-12)
- [Short Signatures from the Weil Pairing](https://doi.org/10.1007/3-540-45682-1_30) - Springer (accessed: 2026-08-12)
- [Ethereum Proof-of-Stake Consensus Specifications](https://github.com/ethereum/consensus-specs) - Ethereum Foundation (accessed: 2026-08-12)
- [Phase 0 Beacon Chain Specification](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/beacon-chain.md) - Ethereum Foundation (accessed: 2026-08-12)
- [Ethereum Annotated Specification: BLS Signatures](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#bls-signatures) - Ethereum Foundation (accessed: 2026-08-12)
- [EIP-2537: Precompile for BLS12-381 curve operations](https://eips.ethereum.org/EIPS/eip-2537) - Ethereum Improvement Proposals (accessed: 2026-08-12)
- [Consensus mechanisms](https://ethereum.org/developers/docs/consensus-mechanisms/) - Ethereum.org (accessed: 2026-08-12)
Source: https://wiki.fcontext.com/ru/crypto/bls-signature/index.mdx