Подписи BLS повсюду, от консенсуса Ethereum до EigenLayer. Но их легко использовать неправильно. Что такое подписи BLS? Давайте поговорим о правильном и неправильном способах их использования:

Но сначала, что такое подписи BLS? Подписи BLS — это криптографический примитив, используемый для подписания сообщений, как ECDSA. Вот как работает математика. Это основано на парных эллиптических кривых. Но что делает их такими особенными? Почему использовать эти замысловатые пары?

Убийственная функция BLS: агрегация подписей. Вы можете объединить множество подписей BLS в одну подпись. Это позволяет вам передавать и проверять N подписей сразу, что более эффективно по пространству и времени! А в блокчейне оптимизации имеют огромное значение для экономии газа.

Для глубокого понимания того, как работают подписи BLS, а также процесса создания агрегации и мультиподписей, ознакомьтесь с полным постом в блоге, ссылку на который вы найдете в конце этой темы! Теперь давайте посмотрим, как подписи BLS могут быть ошибочными и как EigenLayer использует их (правильно, избегая этих подводных камней)!

EigenLayer — это слой повторного стекинга для Ethereum. В EigenLayer AVSe валидаторы подписывают результаты своих вычислений валидации. Агрегатор собирает все эти подписи и отправляет их в цепочку. Собранные подписи проверяются в цепочке.

Задача содержит номер блока, когда задача была создана, и порог, указывающий процент валидации операторов, необходимый для проверки задачи. Операторы, которые выбрали участие в AVS, могут получать эти задачи для вычисления ответа на задачу, а затем оператор может отправить ответ с их BLS-подписью задачи агрегатору. Как только порог идентичных ответов достигнут, агрегатор объединяет все BLS-подписи в уникальную агрегированную подпись и отправляет ее обратно в контракт AVS. Контракт проверяет, что подпись верна, и открывает период оспаривания, когда оспаривающая сторона может предоставить доказательства того, что валидация была неверной, и если это так, то недобросовестные операторы будут наказаны.

В контракте проверка происходит в функции `trySignatureAndApkVerification`:

Однако многофункциональные подписи, если их использовать неправильно, имеют серьезную проблему, называемую атаками с подменой ключа. Предположим, что честный пользователь имеет открытый ключ `pk_0`. Злоумышленник, который ранее видел `pk_0`, может выбрать свой открытый ключ как pk_1 = sk_1⋅G_1—pk_0. Злоумышленник не будет знать закрытый ключ, связанный с открытым ключом. Однако проверка многофункциональной подписи даст следующее:

Только `sk_1` необходим для подписи сообщения, что приводит к действительной мультиподписи, даже если первый пользователь не подписал его. Это легко обобщается на любое количество `r` честных пользователей, выбирая злонамеренный ключ, который:

Это опасная угроза, поскольку в нашем предыдущем примере AVS злонамеренный агрегатор, который ранее зарегистрировал бы поддельный ключ, мог бы отправлять агрегированные подписи, не подписанные валидаторами, но все равно приниматься контрактом. Это привело бы к тому, что валидаторы были бы наказаны, даже если они не совершали проступков.

Итак, чтобы предотвратить атаку с использованием украденного ключа, общим методом является просьба к пользователям доказать, что они знают, что их закрытый ключ соответствует открытому ключу, известная как доказательство владения. Таким образом, на первом этапе регистрации пользователя просят зарегистрировать свой открытый ключ вместе с доказательством владения π таким образом:

В основном, от пользователя требуется подписать свой открытый ключ или любое другое идентификационное сообщение. В AVS сообщение — это адрес оператора. В контракте EigenLayer проверка доказательства владения осуществляется с помощью функции `registerBLSPublicKey`:

Функция `pubkeyRegistrationMessageHash` используется для хеширования пользовательского разделителя домена `PUBKEY_REGISTRATION_TYPEHASH` и адреса оператора.

После регистрации открытый ключ добавляется в контракт. Мы можем проверить его значение, вызвав функцию `getRegisteredPubkey`. Вот пример открытого ключа BLS, зарегистрированного для EigenDA AVS:

Доказательство владения — это, по сути, подпись BLS. Однако также не рекомендуется использовать мультиподписи на этапе доказательства владения, например, для регистрации нескольких открытых ключей для одного участника. В противном случае участник мог бы осуществить атаку с нулевым разделением. В этом случае участник мог бы зарегистрировать ключи, которые при сложении взаимно уничтожали бы друг друга и могли бы обойти доказательство владения.

Мы видели, что многофирменные подписи BLS предлагают значительные возможности для оптимизации. Реализация EigenLayer демонстрирует мощь подписей BLS и также подчеркивает сложности, связанные с их практическим развертыванием. Однако многофирменные подписи вводят риски безопасности, такие как атаки с использованием поддельных ключей, что требует мер предосторожности, таких как доказательство владения. Но с обновлением Pectra, поддерживающим BLS12-381, мы можем увидеть дальнейшую реализацию и улучшения в Solidity, и, таким образом, мы надеемся, что этот пост поможет избежать известных ошибок реализации и уязвимостей.

Для более глубокого погружения в подписи BLS, построение агрегации и мультиподписи, ознакомьтесь с нашим недавно опубликованным блогом ниже: