Podpisy BLS są wszędzie, od konsensusu Ethereum po EigenLayer. Ale łatwo jest je używać w niewłaściwy sposób. Czym są podpisy BLS? Porozmawiajmy o właściwym i niewłaściwym sposobie ich używania:

Ale najpierw, czym są podpisy BLS? Podpisy BLS to prymityw kryptograficzny używany do podpisywania wiadomości, podobnie jak ECDSA. Oto jak działa matematyka. Jest oparty na parowaniach krzywych eliptycznych. Ale co sprawia, że są takie wyjątkowe? Dlaczego używać tych wymyślnych parowań?

Zabójcza cecha BLS: agregacja podpisów. Możesz połączyć wiele podpisów BLS w jeden podpis. Dzięki temu możesz przesyłać i sprawdzać N podpisów jednocześnie, co jest bardziej efektywne pod względem przestrzeni i czasu! A na łańcuchu, optymalizacje są niezwykle ważne dla oszczędności gazu.

Aby dokładnie zrozumieć, jak działają podpisy BLS, oraz proces budowania agregacji i multi-podpisów, zapoznaj się z pełnym wpisem na blogu, który znajduje się na końcu tego wątku! Teraz zobaczmy, jak podpisy BLS mogą się nie udać i jak EigenLayer je wykorzystuje (prawidłowo, unikając tych pułapek)!

EigenLayer to warstwa restakingowa dla Ethereum. W EigenLayer AVS, walidatorzy podpisują wyniki swoich obliczeń walidacyjnych. Agregator zbiera wszystkie te podpisy i przesyła je na łańcuch. Agregowane podpisy są weryfikowane na łańcuchu.

Zadanie zawiera numer bloku, w którym zadanie zostało utworzone, oraz próg wskazujący procent walidacji operatora, który jest niezbędny do zatwierdzenia zadania. Operatorzy, którzy przystąpili do AVS, mogą otrzymać te zadania, aby obliczyć odpowiedź na zadanie, a następnie operator może wysłać odpowiedź z ich podpisem BLS zadania do agregatora. Gdy tylko osiągnięty zostanie próg identycznych odpowiedzi, agregator łączy wszystkie podpisy BLS w unikalny podpis zbiorczy i wysyła go z powrotem do kontraktu AVS. Kontrakt weryfikuje, że podpis jest poprawny i otwiera okres wyzwań, w którym challenger może przedstawić dowód, że walidacja była niepoprawna, a jeśli tak, to niewłaściwie działający operatorzy są karani.

W umowie weryfikacja odbywa się w funkcji `trySignatureAndApkVerification`:

Jednakże, wieloznakowe podpisy, jeśli są używane nieprawidłowo, wiążą się z poważnym problemem zwanym atakami z użyciem fałszywego klucza. Załóżmy, że uczciwy użytkownik ma klucz publiczny, `pk_0`. Napastnik, który wcześniej widział `pk_0`, może wybrać swój klucz publiczny jako pk_1 = sk_1⋅G_1—pk_0. Napastnik nie znałby klucza prywatnego związanego z kluczem publicznym. Jednak weryfikacja wieloznakowego podpisu dałaby następujący wynik:

Tylko `sk_1` jest potrzebny do podpisania wiadomości, co skutkuje ważnym podpisem wielokrotnym, nawet jeśli pierwszy użytkownik nie podpisał jej. To łatwo uogólnić na dowolną liczbę `r` uczciwych użytkowników, wybierając klucz oszusta, którym jest:

To jest niebezpieczne zagrożenie, ponieważ w naszym poprzednim przykładzie AVS, złośliwy agregator, który wcześniej zarejestrowałby nieuczciwy klucz, mógłby wysyłać podpisy zbiorcze, które nie byłyby podpisane przez walidatorów, ale nadal byłyby akceptowane przez kontrakt. To doprowadziłoby do ukarania walidatorów, nawet jeśli nie popełnili wykroczenia.

Aby zapobiec atakowi z użyciem klucza, powszechną metodą jest żądanie od użytkowników udowodnienia, że znają klucz prywatny odpowiadający ich kluczowi publicznemu, znane jako dowód posiadania. W związku z tym, w pierwszym kroku rejestracji, użytkownik jest proszony o zarejestrowanie swojego klucza publicznego wraz z dowodem posiadania π, tak aby:

W zasadzie użytkownik jest proszony o podpisanie swojego klucza publicznego lub innej wiadomości identyfikacyjnej. W AVS wiadomością jest adres operatora. W kontrakcie EigenLayer, dowód posiadania jest weryfikowany przez funkcję `registerBLSPublicKey`:

Funkcja `pubkeyRegistrationMessageHash` jest używana do haszowania niestandardowego separatora domeny `PUBKEY_REGISTRATION_TYPEHASH` oraz adresu operatora.

Po rejestracji klucz publiczny jest dodawany do kontraktu. Możemy zweryfikować jego wartość, wywołując funkcję `getRegisteredPubkey`. Oto przykład klucza publicznego BLS zarejestrowanego dla EigenDA AVS:

Dowód posiadania to w zasadzie podpis BLS. Jednak nie jest również zalecane używanie wielu podpisów podczas etapu dowodu posiadania, na przykład do rejestrowania wielu kluczy publicznych dla jednego uczestnika. W takim przypadku uczestnik mógłby osiągnąć atak zerowy. W tym przypadku uczestnik mógłby zarejestrować klucze, które wzajemnie się anulowały, gdyby zostały zsumowane, i mógłby obejść dowód posiadania.

Zauważyliśmy, że wielozdaniowe podpisy BLS oferują znaczną możliwość optymalizacji. Implementacja EigenLayera pokazuje moc podpisów BLS i jednocześnie podkreśla złożoności związane z ich praktycznym wdrożeniem. Jednak wielozdaniowe podpisy wprowadzają ryzyko bezpieczeństwa, takie jak ataki z użyciem nieautoryzowanych kluczy, co wymaga zabezpieczeń, takich jak dowód posiadania. Jednak dzięki aktualizacji Pectra wspierającej BLS12-381, możemy zobaczyć dalsze wdrożenie i ulepszenia w Solidity, dlatego mamy nadzieję, że ten post pomoże uniknąć znanych błędów wdrożeniowych i luk w zabezpieczeniach.

Aby głębiej zrozumieć podpisy BLS, budowanie agregacji i podpisy wielokrotne, zapoznaj się z naszym niedawno opublikowanym wpisem na blogu poniżej: