Podpisy BLS i schematy podpisów zagregowanych

Podpisy BLS opierają się na parowaniach dwuliniowych — operacji matematycznej na krzywych eliptycznych. Parowanie e: G1 x G2 -> GT odwzorowuje pary punktów z dwóch grup (G1, G2) do grupy docelowej GT. Kluczową właściwością jest dwuliniowość: e(aP, bQ) = e(P, Q)^(ab) dla skalarów a, b oraz punktów P, Q. Umożliwia to sprawdzanie zależności między elementami grupy bez znajomości logarytmów dyskretnych. Najczęściej używaną krzywą parowania w kryptografii jest BLS12-381, wybrana ze względu na 128-bitowy poziom bezpieczeństwa, małe rozmiary elementów grupy (48 bajtów w G1 i 96 bajtów w G2) oraz wydajne obliczanie parowań.

Podpis BLS (Boneh-Lynn-Shacham) działa w następujący sposób. Generowanie kluczy: klucz prywatny x jest losowym skalarem, a klucz publiczny PK = x * G, gdzie G jest generatorem G2. Podpisywanie: dla wiadomości m oblicz H = hash-to-curve(m) w G1, a następnie sigma = x * H. Podpis sigma jest pojedynczym punktem G1 (48 bajtów w BLS12-381). Weryfikacja: sprawdź e(sigma, G) == e(H, PK). Dzięki dwuliniowości e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). Bezpieczeństwo opiera się na założeniu co-CDH: obliczenie x*H na podstawie H i x*G jest trudne bez znajomości x.

Podpisy BLS obsługują nieinteraktywną agregację: mając podpisy sigma_1, ..., sigma_n dla wiadomości m_1, ..., m_n oraz kluczy publicznych PK_1, ..., PK_n, agregator oblicza sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (dodawanie punktów krzywej eliptycznej). Zagregowany podpis jest pojedynczą wartością o rozmiarze 48 bajtów, niezależnie od n. Weryfikacja wymaga n+1 operacji parowania: sprawdź e(sigma_agg, G) == product(e(H_i, PK_i)). W typowym przypadku, gdy wszyscy podpisujący podpisują tę samą wiadomość, weryfikacja sprowadza się do 2 parowań: e(sigma_agg, G) == e(H, sum(PK_i)).

Naive BLS aggregation jest podatna na atak z użyciem złośliwego klucza. Przeciwnik rejestruje PK_adv = x_adv*G - PK_honest. Zagregowany klucz PK_agg = PK_honest + PK_adv = x_adv*G jest w całości kontrolowany przez przeciwnika. Dostępne metody obrony: (1) Proof of Possession (PoP): każdy podpisujący dowodzi znajomości swojego klucza prywatnego, podpisując własny klucz publiczny podczas rejestracji. (2) Rozszerzenie wiadomości: do wiadomości dołączany jest klucz publiczny każdego podpisującego. (3) Delinearyzacja (BGLS): każdy klucz publiczny jest mnożony przez hash(PK_i, all_PKs) przed agregacją, co przełamuje liniowość umożliwiającą ten atak. Ethereum używa PoP podczas rejestracji walidatorów.

Warstwa konsensusu Ethereum (Beacon Chain) szeroko wykorzystuje agregację BLS12-381. W każdym slocie około 400,000+ aktywnych walidatorów poświadcza aktualny wierzchołek łańcucha. Bez agregacji przechowywanie wszystkich podpisów wymagałoby ~400,000 * 96 bytes = 38 MB na slot. Dzięki agregacji BLS dla każdego komitetu (zwykle 512 walidatorów) każdy komitet tworzy jeden zagregowany podpis o rozmiarze 96 bajtów, zmniejszając łączną ilość danych podpisów do kilobajtów na slot. Ciało bloku Beacon Chain zawiera zagregowane poświadczenia: pole bitowe wskazujące, którzy walidatorzy uczestniczyli, oraz jeden zagregowany podpis BLS dla każdego komitetu.

Operacje na podpisach BLS mają inną charakterystykę wydajności niż operacje ECDSA. Podpisywanie BLS wymaga jednego hash-to-curve i jednego mnożenia skalarnego (~1 ms na nowoczesnym sprzęcie). Weryfikacja BLS wymaga dwóch operacji parowania (~3–5 ms każda, czyli łącznie ~6–10 ms). Podpisywanie ECDSA wymaga jednego mnożenia punktu (~0.2 ms), a weryfikacja — dwóch mnożeń punktu (~0.4 ms). Weryfikacja BLS jest wolniejsza dla pojedynczego podpisu, ale znacznie szybsza w agregacji: weryfikacja zagregowanych 1000 podpisów BLS wymaga łącznie ~10 ms, w porównaniu z ~400 ms dla 1000 indywidualnych weryfikacji ECDSA. Punkt przejścia przypada na około 2–3 podpisy.

Progowe BLS rozszerza agregację o dzielenie sekretu. W schemacie progowym (t, n) klucz prywatny jest dzielony na n udziałów za pomocą dzielenia sekretu Shamira nad ciałem skalarów BLS. Każdy posiadacz udziału i tworzy częściowy podpis sigma_i = sk_i * H(m). Dowolne t częściowych podpisów można połączyć za pomocą współczynników interpolacji Lagrange'a: sigma = sum(lambda_i * sigma_i). Wynik jest identyczny z podpisem utworzonym przez pierwotny klucz, ale żadna pojedyncza strona nigdy nie posiada kompletnego klucza. Progowe BLS jest używane w technologii rozproszonych walidatorów (DVT), portfelach MPC oraz usługach podpisywania progowego, takich jak Fireblocks i Web3Auth.

Filecoin używa podpisów BLS w swoim systemie dowodów przechowywania i do podpisywania transakcji. Górnicy przechowywania agregują wiele dowodów za pomocą agregacji BLS, zmniejszając koszty weryfikacji on-chain. Pula komunikatów Filecoin również agreguje wiele podpisów transakcji w jeden zagregowany podpis, zmniejszając rozmiary bloków. Implementacja Filecoin używa standardu BLS z projektu IETF (hash-to-curve zgodnie z RFC 9380, krzywa BLS12-381) w wariancie z minimalnym rozmiarem klucza publicznego, w którym klucze publiczne znajdują się w G1 (48 bajtów), a podpisy w G2 (96 bajtów) — odwrotnie niż w konwencji Ethereum.

Chociaż Zcash używa przede wszystkim dowodów zk-SNARK Groth16, parowania BLS stanowią podstawę wielu konstrukcji zerowej wiedzy opartych na parowaniach. Równanie weryfikacji Groth16 jest sprawdzeniem parowania: e(A, B) = e(alpha, beta) * e(vk, C), gdzie A, B, C są elementami dowodu. Zobowiązania wielomianowe KZG (używane w transakcjach blob EIP-4844 w Ethereum i różnych systemach ZK rollup) również opierają się na parowaniach BLS12-381: zobowiązanie do wielomianu f(x) ma postać C = f(tau)*G, a dowody ewaluacji są weryfikowane za pomocą parowania. BLS12-381 wybrano specjalnie ze względu na wydajne operacje parowania i 128-bitowy poziom bezpieczeństwa.

BLS nie jest jedynym schematem podpisów podlegającym agregacji. Podpisy Schnorra obsługują agregację kluczy (MuSig2, używaną w Bitcoin Taproot), w której wielu podpisujących tworzy pojedynczy podpis Schnorra nieodróżnialny od podpisu pojedynczego podpisującego. FROST (Flexible Round-Optimized Schnorr Threshold) zapewnia progowe podpisy Schnorra w dwóch rundach. Agregacja Schnorra wymaga jednak interakcji między podpisującymi (w przeciwieństwie do nieinteraktywnej agregacji BLS), przez co jest mniej odpowiednia dla dużych zbiorów walidatorów. BLS pozostaje preferowanym rozwiązaniem dla konsensusu blockchaina ze względu na nieinteraktywną agregację i wydajną weryfikację wsadową.

Podpisy BLS bazują na parowaniach na krzywych eliptycznych, które są podatne na działanie komputerów kwantowych uruchamiających algorytm Shora. Wystarczająco wydajny komputer kwantowy mógłby obliczać logarytmy dyskretne w BLS12-381, łamiąc wszystkie istniejące podpisy BLS i podważając bezpieczeństwo mechanizmu konsensusu Ethereum. Nie wiadomo dokładnie, kiedy to nastąpi, ale NIST szacuje, że kryptograficznie istotne komputery kwantowe mogą pojawić się za 15–20 lat. Ethereum i inne łańcuchy zależne od BLS będą musiały przejść na postkwantowe schematy podpisów (CRYSTALS-Dilithium/ML-DSA lub SPHINCS+/SLH-DSA), zanim to zagrożenie stanie się realne. Migracja będzie wymagać zmian na poziomie protokołu, obejmujących rejestrację walidatorów, formaty attestacji oraz weryfikację agregatów.

Jaka jest główna zaleta agregacji podpisów BLS w warstwie konsensusu Ethereum?

Podpisy BLS wykorzystują parowania dwuliniowe na krzywych BLS12-381. Podpisy są 48-bajtowymi punktami G1, a klucze publiczne — 96-bajtowymi punktami G2, zgodnie z konwencją Ethereum. Nieinteraktywna agregacja łączy n podpisów w jedną 48-bajtową wartość, którą weryfikuje się za pomocą n+1 parowań. Atak z użyciem zbójeckiego klucza jest ograniczany przez Proof of Possession podczas rejestracji walidatora. Ethereum używa BLS do kompresowania ponad 400 000 attestacji walidatorów przypadających na jeden slot do rozmiaru kilobajtów. Progowe podpisy BLS umożliwiają działanie rozproszonych walidatorów bez jednego posiadacza klucza. BLS bazuje na parowaniach i nie jest bezpieczny postkwantowo, dlatego w przyszłości będzie wymagać migracji.