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

Подписи BLS

Руководство по проверке подписей Boneh-Lynn-Shacham, режимам агрегации, наборам шифров, защите от вредоносных ключей, применению в консенсусе Ethereum и рискам реализации.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Подпись 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 делает блок, сообщение моста или протокол экономически безопасным и финальным.

Связанные темы

Источники

Навигация

Поиск по вики...