BLS-signaturer er overalt, fra Ethereums konsensus til EigenLayer. Men det er lett å bruke dem feil. Hva er BLS-signaturer? La oss snakke om den riktige måten og feil måte å bruke dem på:

Men først, hva er BLS-signaturer? BLS-signaturer er en kryptografisk primitiv som brukes til å signere meldinger, som ECDSA. Slik fungerer regnestykket. Den er bygget på toppen av elliptiske kurvepar. Men hva gjør dem så spesielle? Hvorfor bruke disse fancy sammenkoblingene?

BLS sin morderfunksjon: signaturaggregering. Du kan kombinere mange BLS-signaturer til én enkelt signatur. Dette lar deg overføre og sjekke N-signaturer på en gang, mer plass og tidseffektivt! Og på kjeden er optimaliseringer enormt viktige for gassbesparelser.

For en grundig titt på hvordan BLS-signaturer fungerer, sammen med prosessen med å bygge aggregering og multisignaturer, sjekk ut hele blogginnlegget som er lenket til på slutten av denne tråden! La oss nå se hvordan BLS-signaturer kan gå galt, og hvordan EigenLayer bruker dem (riktig, og unngår disse fallgruvene)!

EigenLayer er et gjentakingslag for Ethereum. I EigenLayer AVS-er signerer validatorer resultatene av valideringsberegningene sine. Aggregatoren samler alle disse signaturene og skyver dem på kjeden. De aggregerte signaturene verifiseres i kjeden.

Oppgaven inneholder blokknummeret da oppgaven ble opprettet, og en terskel som angir prosentandelen av operatørvalidering, som er nødvendig for å validere oppgaven. Operatørene som valgte AVS kan få disse oppgavene til å beregne oppgavesvaret, og deretter kan operatøren sende svaret med sin BLS-signatur av oppgaven til aggregatoren. Så snart terskelen for identiske svar er nådd, slår aggregatoren sammen alle BLS-signaturene til en unik aggregert signatur og sender den tilbake til AVS-kontrakten. Kontrakten bekrefter at signaturen er korrekt og åpner en utfordrende periode der en utfordrer kan bevise at valideringen var feil, og i så fall blir operatørene som oppfører seg dårlig, kuttet.

I kontrakten skjer bekreftelsen i 'trySignatureAndApkVerification'-funksjonen:

Imidlertid kommer multisignaturer, hvis de brukes feil, med et alvorlig problem som kalles useriøse nøkkelangrep. La oss si at en ærlig bruker har en offentlig nøkkel, 'pk_0'. En angriper som tidligere har sett «pk_0», kan velge sin offentlige nøkkel som pk_1 = sk_1⋅G_1—pk_0. Angriperen vil ikke vite den private nøkkelen som er knyttet til den offentlige nøkkelen. Bekreftelsen med flere signaturer vil imidlertid gi følgende:

Bare "sk_1" er nødvendig for å signere en melding som resulterer i en gyldig multisignatur, selv om den første brukeren kanskje ikke har signert den. Dette kan enkelt generaliseres til et hvilket som helst tall 'r' for ærlige brukere ved å velge den useriøse nøkkelen, som er:

Dette er en farlig trussel siden, i vårt forrige AVS-eksempel, en ondsinnet aggregator som tidligere ville ha registrert en falsk nøkkel, kan sende aggregerte signaturer som ikke er signert av validatorene, men fortsatt bli akseptert av kontrakten. Dette vil føre til at validatorer blir kuttet selv om de ikke oppfører seg dårlig.

Så for å forhindre et falskt nøkkelangrep, er den vanlige metoden å be brukere om å bevise at de vet at den private nøkkelen samsvarer med deres offentlige nøkkel, kjent som bevis på besittelse. I det første registreringstrinnet blir brukeren derfor bedt om å registrere sin offentlige nøkkel sammen med bevis på besittelse π slik at:

I utgangspunktet blir brukeren bedt om å signere sin offentlige nøkkel eller annen identifikasjonsmelding. I AVS er meldingen operatørens adresse. I EigenLayer-kontrakten verifiseres beviset på besittelse av 'registerBLSPublicKey'-funksjonen:

Funksjonen 'pubkeyRegistrationMessageHash' brukes til å hashe den egendefinerte domeneskilletegnet 'PUBKEY_REGISTRATION_TYPEHASH' og operatøradressen.

Etter registrering legges den offentlige nøkkelen til kontrakten. Vi kan bekrefte verdien ved å kalle 'getRegisteredPubkey'-funksjonen. Her er et eksempel på en offentlig BLS-nøkkel registrert for EigenDA AVS:

Bevis på besittelse er i utgangspunktet en BLS-signatur. Det er imidlertid heller ikke tilrådelig å bruke multisignaturer under bevis-of-possession-trinnet, for eksempel for å registrere flere offentlige nøkler for en enkelt deltaker. I så fall vil deltakeren oppnå et splitting-zero-angrep. I dette tilfellet kunne deltakeren registrere nøkler som ville kanselleres når de ble summert sammen og kunne omgå beviset på besittelse.

Vi har sett at BLS multisignaturer tilbyr en betydelig optimaliseringsmulighet. EigenLayers implementering demonstrerer kraften til BLS-signaturer og fremhever også kompleksiteten som er involvert i deres praktiske distribusjon. Multisignaturer introduserer imidlertid sikkerhetsrisikoer som useriøse nøkkelangrep, som krever sikkerhetstiltak som bevis på besittelse. Men med Pectra-oppgraderingen som støtter BLS12-381, kan vi se ytterligere implementering og forbedringer i Solidity, og derfor håper vi dette innlegget bidrar til å unngå kjente implementeringsfeil og sårbarheter.

For et dypere dykk i BLS-signaturer, bygningsaggregering og multisignaturer, sjekk ut vårt nylig publiserte blogginnlegg nedenfor: