Semnăturile BLS sunt peste tot, de la consensul Ethereum la EigenLayer. Dar este ușor să le folosești greșit. Ce sunt semnăturile BLS? Să vorbim despre modul corect și modul greșit de a le folosi:

Dar mai întâi, ce sunt semnăturile BLS? Semnăturile BLS sunt o primitivă criptografică utilizată pentru semnarea mesajelor, cum ar fi ECDSA. Iată cum funcționează matematica. Este construit pe perechi de curbe eliptice. Dar ce le face atât de speciale? De ce să folosiți aceste perechi fanteziste?

Caracteristica ucigașă a BLS: agregarea semnăturilor. Puteți combina mai multe semnături BLS într-o singură semnătură. Acest lucru vă permite să transmiteți și să verificați N semnături simultan, mai eficient în spațiu și timp! Iar în lanț, optimizările sunt extrem de importante pentru economiile de gaz.

Pentru o privire aprofundată asupra modului în care funcționează semnăturile BLS, împreună cu procesul de construire a agregării și a semnăturilor multiple, consultați postarea completă de pe blog legată la sfârșitul acestui subiect! Acum, să vedem cum semnăturile BLS pot merge prost și cum le folosește EigenLayer (corect, evitând aceste capcane)!

EigenLayer este un strat de remiză pentru Ethereum. În AVS-urile EigenLayer, validatorii semnează rezultatele calculelor lor de validare. Agregatorul colectează toate aceste semnături și le împinge în lanț. Semnăturile agregate sunt verificate în lanț.

Sarcina conține numărul blocului la momentul creării sarcinii și un prag care indică procentul de validare a operatorului, care este necesar pentru validarea sarcinii. Operatorii care au optat pentru AVS pot obține acele sarcini pentru a calcula răspunsul la sarcină și apoi operatorul poate trimite răspunsul cu semnătura BLS a sarcinii către agregator. De îndată ce pragul de răspunsuri identice este atins, agregatorul îmbină toate semnăturile BLS într-o semnătură agregată unică și o trimite înapoi la contractul AVS. Contractul verifică dacă semnătura este corectă și deschide o perioadă de provocare în care un contestator poate dovedi că validarea a fost incorectă și, dacă da, operatorii care se comportă greșit sunt tăiați.

În contract, verificarea are loc în funcția "trySignatureAndApkVerification":

Cu toate acestea, semnăturile multiple, dacă sunt utilizate incorect, vin cu o problemă serioasă numită atacuri rogue-key. Să presupunem că un utilizator onest are o cheie publică, "pk_0". Un atacator care a văzut anterior "pk_0" își poate alege cheia publică ca pk_1 = sk_1⋅G_1—pk_0. Atacatorul nu ar cunoaște cheia privată asociată cu cheia publică. Cu toate acestea, verificarea cu mai multe semnături ar oferi următoarele:

Doar "sk_1" este necesar pentru a semna un mesaj care are ca rezultat o semnătură multiplă validă, chiar dacă primul utilizator nu l-a semnat. Acest lucru este ușor de generalizat la orice număr "r" de utilizatori onești prin alegerea cheii necinstite, fiind:

Aceasta este o amenințare periculoasă, deoarece, în exemplul nostru AVS anterior, un agregator rău intenționat care ar fi înregistrat anterior o cheie necinstită ar putea trimite semnături agregate care nu au fost semnate de validatori, dar care ar fi totuși acceptate de contract. Acest lucru ar duce la tăierea validatorilor chiar dacă nu s-au comportat greșit.

Deci, pentru a preveni un atac cu cheie necinstită, metoda obișnuită este de a cere utilizatorilor să dovedească că știu că cheia privată se potrivește cu cheia lor publică, cunoscută sub numele de dovadă de posesie. Astfel, în prima etapă de înregistrare, utilizatorului i se solicită să își înregistreze cheia publică împreună cu dovada deținerii π astfel încât:

Practic, utilizatorului i se cere să semneze cheia publică sau orice alt mesaj de identificare. În AVS, mesajul este adresa operatorului. În contractul EigenLayer, dovada posesiei este verificată de funcția "registerBLSPublicKey":

Funcția "pubkeyRegistrationMessageHash" este utilizată pentru a codifica separatorul de domeniu personalizat "PUBKEY_REGISTRATION_TYPEHASH" și adresa operatorului.

După înregistrare, cheia publică este adăugată la contract. Îi putem verifica valoarea apelând funcția "getRegisteredPubkey". Iată un exemplu de cheie publică BLS înregistrată pentru EigenDA AVS:

Dovada posesiei este practic o semnătură BLS. Cu toate acestea, nu este recomandabil să folosiți mai multe semnături în timpul etapei de dovada posesiei, de exemplu, pentru a înregistra mai multe chei publice pentru un singur participant. Dacă da, participantul ar realiza un atac de divizare zero. În acest caz, participantul ar putea înregistra chei care s-ar anula atunci când ar fi însumate și ar putea ocoli dovada posesiei.

Am văzut că semnăturile multiple BLS oferă o oportunitate semnificativă de optimizare. Implementarea EigenLayer demonstrează puterea semnăturilor BLS și, de asemenea, evidențiază complexitatea implicată în implementarea lor practică. Cu toate acestea, semnăturile multiple introduc riscuri de securitate, cum ar fi atacurile cu cheie necinstită, care necesită garanții precum dovada posesiei. Dar cu upgrade-ul Pectra care suportă BLS12-381, este posibil să vedem implementări și îmbunătățiri suplimentare în Solidity și, prin urmare, sperăm că această postare va ajuta la evitarea erorilor și vulnerabilităților de implementare cunoscute.

Pentru o scufundare mai profundă în semnăturile BLS, agregarea clădirilor și semnăturile multiple, consultați postarea noastră de blog publicată recent mai jos: