Підписи BLS є скрізь, від консенсусу Ethereum до EigenLayer. Але помилитися з ними легко. Що таке підписи BLS? Поговоримо про те, як правильно і неправильно їх використовувати:

Але спочатку, що таке підписи BLS? Підписи BLS — це криптографічний примітив, який використовується для підписання повідомлень, наприклад ECDSA. Ось як працює математика. Він побудований на основі пар еліптичних кривих. Але що робить їх такими особливими? Навіщо використовувати ці вигадливі пари?

Вбивча особливість BLS: агрегація сигнатур. Ви можете об'єднати багато підписів BLS в один підпис. Це дає змогу передавати та перевіряти N підписів одночасно, що заощаджує більше місця та часу! А в ланцюжку оптимізація надзвичайно важлива для економії газу.

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

EigenLayer – це рівень рестайкінгу для Ethereum. У EigenLayer AVS валідатори підписують результати своїх обчислень валідації. Агрегатор збирає всі ці підписи і відправляє їх в ланцюжок. Зведені підписи перевіряються в мережі.

Завдання містить номер блоку, коли було створено завдання та поріг, що вказує на відсоток валідації оператором, який необхідний для валідації завдання. Оператори, які ввімкнули 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, агрегацію будівель і мультипідпис ознайомтеся з нашою нещодавно опублікованою публікацією в блозі нижче: