BLS-signaturer finns överallt, från Ethereums konsensus till EigenLayer. Men det är lätt att använda dem fel. Vad är BLS-signaturer? Låt oss prata om rätt sätt och fel sätt att använda dem:

Men först, vad är BLS-signaturer? BLS-signaturer är en kryptografisk primitiv som används för att signera meddelanden, som ECDSA. Så här fungerar matematiken. Den är byggd ovanpå elliptiska kurvpar. Men vad är det som gör dem så speciella? Varför använda dessa snygga parningar?

BLS:s mördarfunktion: signaturaggregering. Du kan kombinera många BLS-signaturer till en enda signatur. Detta låter dig överföra och kontrollera N-signaturer på en gång, mer utrymme och tidseffektivt! Och i kedjan är optimeringar enormt viktiga för att spara gas.

För en djupgående titt på hur BLS-signaturer fungerar, tillsammans med processen att bygga aggregering och multisignaturer, kolla in hela blogginlägget som är länkat i slutet av den här tråden! Låt oss nu se hur BLS-signaturer kan gå fel och hur EigenLayer använder dem (på rätt sätt för att undvika dessa fallgropar)!

EigenLayer är ett omsättningslager för Ethereum. I EigenLayer AVS:er signerar validerare resultaten av sina valideringsberäkningar. Aggregatorn samlar in alla dessa signaturer och skickar dem i kedjan. De aggregerade signaturerna verifieras i kedjan.

Uppgiften innehåller blocknumret när uppgiften skapades och ett tröskelvärde som anger procentandelen operatörsvalidering, vilket är nödvändigt för att validera uppgiften. Operatörerna som har valt att delta i AVS kan få dessa uppgifter att beräkna uppgiftssvaret och sedan kan operatören skicka svaret med sin BLS-signatur för uppgiften till aggregatorn. Så snart tröskeln för identiska svar har uppnåtts slår aggregatorn samman alla BLS-signaturer till en unik aggregerad signatur och skickar tillbaka den till AVS-kontraktet. Kontraktet verifierar att signaturen är korrekt och öppnar en utmanande period när en utmanare kan ge bevis på att valideringen var felaktig, och om så är fallet, skärs de operatörer som inte beter sig som de ska.

I kontraktet sker verifieringen i funktionen "trySignatureAndApkVerification":

Men om multisignaturer används på fel sätt kommer de med ett allvarligt problem som kallas rogue-key-attacker. Låt oss säga att en ärlig användare har en offentlig nyckel, "pk_0". En angripare som tidigare har sett "pk_0" kan välja sin offentliga nyckel som pk_1 = sk_1⋅G_1—pk_0. Angriparen känner inte till den privata nyckel som är associerad med den offentliga nyckeln. Verifieringen med flera signaturer skulle dock ge följande:

Endast "sk_1" behövs för att signera ett meddelande som resulterar i en giltig multisignatur, även om den första användaren kanske inte har signerat det. Detta kan enkelt generaliseras till hur många "r" som helst av ärliga användare genom att välja den falska nyckeln, som är:

Detta är ett farligt hot eftersom, i vårt tidigare AVS-exempel, en skadlig aggregator som tidigare skulle ha registrerat en falsk nyckel kan skicka aggregerade signaturer som inte signerats av validerarna men som fortfarande accepteras av kontraktet. Detta skulle leda till att validerare skulle skäras ned även om de inte betedde sig illa.

Så för att förhindra en rogue-key-attack är den vanliga metoden att begära att användarna bevisar att de vet att den privata nyckeln matchar deras offentliga nyckel, så kallad proof of possession. I det första registreringssteget uppmanas användaren därför att registrera sin offentliga nyckel tillsammans med bevis på innehav π så att:

I grund och botten uppmanas användaren att signera sin offentliga nyckel eller något annat identifieringsmeddelande. I AVS är meddelandet operatörens adress. I EigenLayer-kontraktet verifieras beviset på innehav av funktionen 'registerBLSPublicKey':

Funktionen "pubkeyRegistrationMessageHash" används för att hasha den anpassade domänavgränsaren "PUBKEY_REGISTRATION_TYPEHASH" och operatörsadressen.

Efter registreringen läggs den offentliga nyckeln till i kontraktet. Vi kan verifiera dess värde genom att anropa funktionen "getRegisteredPubkey". Här är ett exempel på en offentlig BLS-nyckel som är registrerad för EigenDA AVS:

Bevis på innehav är i grunden en BLS-signatur. Det är dock inte heller tillrådligt att använda flera signaturer under beviset, till exempel för att registrera flera offentliga nycklar för en enda deltagare. I så fall skulle deltagaren uppnå en splitting-zero-attack. I det här fallet kan deltagaren registrera nycklar som skulle annulleras när de summerades och kunde kringgå innehavsbeviset.

Vi har sett att BLS-multisignaturer erbjuder en betydande optimeringsmöjlighet. EigenLayers implementering visar kraften i BLS-signaturer och belyser också komplexiteten som är involverad i deras praktiska implementering. Multisignaturer medför dock säkerhetsrisker som rogue-key-attacker, vilket kräver skyddsåtgärder som bevis på innehav. Men med Pectra-uppgraderingen som stöder BLS12-381 kan vi se ytterligare implementering och förbättringar i Solidity, och därför hoppas vi att det här inlägget hjälper till att undvika kända implementeringsbuggar och sårbarheter.

För en djupare dykning i BLS-signaturer, byggnadsaggregering och multisignaturer, kolla in vårt nyligen publicerade blogginlägg nedan: