BLS-handtekeningen zijn overal, van de consensus van Ethereum tot EigenLayer. Maar het is gemakkelijk om ze verkeerd te gebruiken. Wat zijn BLS-handtekeningen? Laten we het hebben over de juiste en de verkeerde manier om ze te gebruiken:

Maar eerst, wat zijn BLS-handtekeningen? BLS-handtekeningen zijn een cryptografische primitief die wordt gebruikt voor het ondertekenen van berichten, zoals ECDSA. Hier is hoe de wiskunde werkt. Het is gebouwd op elliptische kromme paringen. Maar wat maakt ze zo speciaal? Waarom deze fancy paringen gebruiken?

De killerfunctie van BLS: handtekeningaggregatie. Je kunt veel BLS-handtekeningen combineren tot één enkele handtekening. Dit stelt je in staat om N handtekeningen in één keer te verzenden en te controleren, wat ruimte- en tijdbesparend is! En op de blockchain zijn optimalisaties enorm belangrijk voor gasbesparingen.

Voor een diepgaande kijk op hoe BLS-handtekeningen werken, samen met het proces van het bouwen van aggregatie en multi-handtekeningen, bekijk de volledige blogpost die aan het einde van deze thread is gelinkt! Laten we nu eens kijken hoe BLS-handtekeningen verkeerd kunnen gaan, en hoe EigenLayer ze gebruikt (juist, om deze valkuilen te vermijden)!

EigenLayer is een herstakingslaag voor Ethereum. In EigenLayer AVSes ondertekenen validators de resultaten van hun validatieberekeningen. De aggregator verzamelt al deze handtekeningen en plaatst ze op de blockchain. De geaggregeerde handtekeningen worden on-chain geverifieerd.

De taak bevat het bloknummer wanneer de taak is aangemaakt en een drempel die het percentage van operatorvalidatie aangeeft, wat nodig is om de taak te valideren. De operators die zich hebben aangemeld voor de AVS kunnen die taken krijgen om het taakantwoord te berekenen en vervolgens kan de operator het antwoord met hun BLS-handtekening van de taak naar de aggregator sturen. Zodra de drempel van identieke antwoorden is bereikt, voegt de aggregator alle BLS-handtekeningen samen tot een unieke aggregaat-handtekening en stuurt deze terug naar het AVS-contract. Het contract verifieert of de handtekening correct is en opent een uitdagingsperiode waarin een uitdager bewijs kan leveren dat de validatie onjuist was, en als dat zo is, worden de zich misdragende operators gestraft.

In het contract vindt de verificatie plaats in de `trySignatureAndApkVerification` functie:

Echter, multi-handtekeningen, als ze verkeerd worden gebruikt, hebben een ernstig probleem genaamd rogue-key aanvallen. Stel je voor dat een eerlijke gebruiker een openbare sleutel heeft, `pk_0`. Een aanvaller die eerder `pk_0` heeft gezien, kan zijn openbare sleutel kiezen als pk_1 = sk_1⋅G_1—pk_0. De aanvaller zou de privésleutel die bij de openbare sleutel hoort, niet kennen. Echter, de multi-handtekening verificatie zou het volgende geven:

Alleen `sk_1` is nodig om een bericht te ondertekenen, wat resulteert in een geldige multi-handtekening, ook al heeft de eerste gebruiker het misschien niet ondertekend. Dit kan gemakkelijk worden gegeneraliseerd naar elk aantal `r` eerlijke gebruikers door de rogue sleutel te kiezen, zijnde:

Dit is een gevaarlijke bedreiging, aangezien in ons vorige AVS-voorbeeld een kwaadaardige aggregator die eerder een ongeoorloofde sleutel had geregistreerd, geaggregeerde handtekeningen zou kunnen verzenden die niet door de validators zijn ondertekend, maar toch door het contract zouden worden geaccepteerd. Dit zou ertoe leiden dat validators worden gestraft, zelfs als ze zich niet misdragen.

Dus, om een rogue-key aanval te voorkomen, is de gebruikelijke methode om gebruikers te vragen te bewijzen dat ze weten dat de privésleutel overeenkomt met hun publieke sleutel, bekend als bewijs van bezit. Dus, in de eerste registratie stap, wordt de gebruiker gevraagd om hun publieke sleutel te registreren samen met bewijs van bezit π zodat:

In wezen wordt de gebruiker gevraagd om hun openbare sleutel of een ander identificatiebericht te ondertekenen. In AVS is het bericht het adres van de operator. In het EigenLayer-contract wordt het bewijs van bezit geverifieerd door de `registerBLSPublicKey` functie:

De functie `pubkeyRegistrationMessageHash` wordt gebruikt om de aangepaste domeinscheiding `PUBKEY_REGISTRATION_TYPEHASH` en het adres van de operator te hashen.

Na registratie wordt de openbare sleutel aan het contract toegevoegd. We kunnen de waarde verifiëren door de functie `getRegisteredPubkey` aan te roepen. Hier is een voorbeeld van een BLS openbare sleutel die is geregistreerd voor EigenDA AVS:

Bewijs van bezit is in wezen een BLS-handtekening. Het is echter ook niet raadzaam om multi-handtekeningen te gebruiken tijdens de bewijs-van-bezit stap, bijvoorbeeld om meerdere openbare sleutels voor een enkele deelnemer te registreren. Als dat het geval is, zou de deelnemer een splitting-zero aanval kunnen uitvoeren. In dit geval zou de deelnemer sleutels kunnen registreren die elkaar opheffen wanneer ze bij elkaar worden opgeteld en zo het bewijs van bezit kunnen omzeilen.

We hebben gezien dat BLS-multi-handtekeningen een aanzienlijke optimalisatiekans bieden. De implementatie van EigenLayer toont de kracht van BLS-handtekeningen aan en benadrukt ook de complexiteit die gepaard gaat met hun praktische inzet. Multi-handtekeningen introduceren echter beveiligingsrisico's zoals rogue-key-aanvallen, wat waarborgen zoals bewijs van bezit noodzakelijk maakt. Maar met de Pectra-upgrade die BLS12-381 ondersteunt, kunnen we verdere implementatie en verbeteringen in Solidity zien, en daarom hopen we dat deze post helpt om bekende implementatiefouten en kwetsbaarheden te vermijden.

Voor een diepere duik in BLS-handtekeningen, het bouwen van aggregatie en multi-handtekeningen, bekijk onze recent gepubliceerde blogpost hieronder: