To signaturalgoritmer dominerer kryptografien bak moderne blokkjeder, og de løser helt forskjellige problemer. ECDSA har vært ryggraden i Bitcoin, Ethereums kontolag og store deler av web-PKI i over et tiår. BLS-signaturer, bygget på parbaserte elliptiske kurver, har tatt over der tusenvis av validatorer må signere samtidig, som på Ethereums konsensuslag. Valget mellom dem handler ikke om hvem som “vinner”, men om hvilket problem systemet ditt faktisk har: kompatibilitet og bred verktøystøtte, eller massiv aggregering av signaturer til et eneste bevis.
Denne artikkelen går gjennom byte-for-byte spesifikasjoner, ytelsesdata fra tre uavhengige kilder, virkelige eksempler fra Ethereum, Bitcoin, Chia og Zcash, og en praktisk migreringsguide. Målet er å gi deg et datadrevet grunnlag for å velge riktig algoritme i 2026, uten gjetting.
Begge algoritmene er digitale signaturskjemaer, men de bygger på forskjellige matematiske fundamenter og løser forskjellige flaskehalser i et system. ECDSA er enkel, rask å verifisere isolert og støttet overalt. BLS er mer komplisert å implementere riktig, men gjør noe ECDSA ikke kan: slå sammen et ubegrenset antall signaturer til én enkelt matematisk enhet. Den forskjellen alene forklarer hvorfor begge fortsatt lever side om side i 2026, i stedet for at den ene har utkonkurrert den andre.
ECDSA: den etablerte standarden for digitale signaturer
ECDSA (Elliptic Curve Digital Signature Algorithm) er standarden de fleste utviklere møter først. Algoritmen bygger på det diskrete logaritme-problemet over elliptiske kurver, og den er formalisert i NISTs FIPS 186-5. Bitcoin signerer hver transaksjon med ECDSA over kurven secp256k1. Ethereums kontolag (execution layer) bruker samme kurve for å autorisere transaksjoner fra brukerkontoer. TLS-sertifikater og store deler av web-PKI lener seg på ECDSA med NIST-kurvene P-256, P-384 og P-521, ofte side om side med RSA og EdDSA.
En komprimert ECDSA-signatur ligger typisk på 70 til 72 byte i vanlig DER-kodet form for 256-bit kurver som secp256k1 eller P-256. Mange implementasjoner bruker en fast “kompakt” koding på 64 byte uten gjenopprettingsmetadata. Den tilhørende offentlige nøkkelen er 33 byte i komprimert form. Det er ingen innebygd måte å slå sammen flere ECDSA-signaturer til én. Skal flere parter signere sammen, må de bruke en separat konstruksjon som MuSig2, som i praksis er bygget på Schnorr-signaturer og ikke på ECDSA selv.
Styrken til ECDSA er modenhet. Algoritmen er støttet i praktisk talt hver kryptografibibliotek, hvert hardware-sikkerhetsmodul og hver nettleser som finnes. Det gjør den til standardvalget når bred kompatibilitet betyr mer enn effektiv aggregering.
En viktig detalj ved moderne ECDSA-implementasjoner er hvordan nonce-verdien genereres. Tidlige implementasjoner lente seg på tilfeldighetskilder som i praksis viste seg å være svake eller gjenbrukte, noe som historisk har ført til konkrete nøkkellekkasjer i produksjonssystemer. RFC 6979 løser dette ved å gjøre nonce-genereringen deterministisk og utledet fra meldingen og den private nøkkelen, slik at samme input alltid gir samme signatur uten å lekke informasjon om nøkkelen. De fleste moderne biblioteker, inkludert implementasjonene som brukes i Bitcoin og Ethereum sine lommebøker, følger denne standarden i dag. Kombinert med bred støtte i hardware-sikkerhetsmoduler og maskinvarelommebøker som Ledger og Trezor, gjør dette ECDSA til det tryggeste utgangspunktet for nye systemer som ikke har et spesifikt aggregeringsbehov.
BLS-signaturer: parbasert kryptografi bygget for aggregering
BLS-signaturer, oppkalt etter Boneh, Lynn og Shacham, bruker en helt annen matematisk byggekloss: bilineære par (pairings) over elliptiske kurver. Den dominerende kurven i produksjon er BLS12-381, som har et 381-bit grunnfelt og gir rundt 128-bit klassisk sikkerhet. Sikkerheten til BLS støtter seg på det diskrete logaritme-problemet over elliptiske kurver, pluss par-spesifikke antakelser som uttrykkes gjennom varianter av co-Diffie-Hellman-problemet i de relevante pargruppene.
En komprimert BLS12-381-signatur er typisk 96 byte, mens en komprimert offentlig nøkkel er 48 byte. Den egenskapen som skiller BLS fra alt annet på denne listen, er aggregering. Mange signaturer på kompatible meldinger kan kombineres matematisk til én enkelt signatur, som deretter verifiseres i en operasjon. Egenskapen gjør BLS attraktiv overalt hvor svært mange parter signerer nesten samtidig, som i blokkjede-konsensus og terskelsignatursystemer.
Prisen for denne egenskapen er kompleksitet. BLS krever par-operasjoner som er tyngre å implementere korrekt enn vanlig skalarmultiplikasjon, og biblioteker må håndtere undergruppekontroller og domeneseparasjon nøye for å unngå kjente angrepsklasser. Et høyytelsesbibliotek som blst er bygget spesifikt for produksjonsbruk, mens referanseimplementasjoner som py_ecc i Python primært er tenkt for læring og testing, ikke for ytelseskritisk drift.
Valget av nettopp BLS12-381 som kurve er ikke tilfeldig. Pairing-vennlige kurver har over tid blitt utsatt for stadig bedre angrep mot det underliggende matematiske problemet, og eldre kurver i samme familie måtte etter hvert forkastes eller erstattes med større parametre for å holde samme sikkerhetsnivå. BLS12-381 ble valgt fordi den gir et godt balansert forhold mellom sikkerhetsmargin, ytelse og interoperabilitet mellom ulike prosjekter. Biblioteket noble-curves, som implementerer BLS12-381 i JavaScript, lister blant annet Algorand, Chia, Dfinity, Ethereum, Filecoin og Zcash som kompatible økosystemer, noe som i praksis har gjort kurven til en de facto bransjestandard for parbasert kryptografi i blokkjeder.
Spesifikasjonstabell: BLS12-381 mot ECDSA side om side
Tabellen under samler de tekniske egenskapene som avgjør hvilken algoritme som passer et gitt system. Tallene for signatur- og nøkkelstørrelse er de komprimerte, produksjonsvanlige verdiene for hver algoritme.
| Egenskap | BLS12-381 | ECDSA (secp256k1 / P-256) |
|---|---|---|
| Signaturstørrelse (komprimert) | 96 byte | 64 til 72 byte |
| Offentlig nøkkel (komprimert) | 48 byte | 33 byte |
| Kurvetype | Parvennlig (pairing-friendly) | Ikke-parbasert elliptisk kurve |
| Krever par-operasjoner | Ja | Nei |
| Native aggregering av signaturer | Ja | Nei (krever MuSig2/Schnorr) |
| Sikkerhetsantakelse | ECDLP + co-Diffie-Hellman-varianter | ECDLP |
| Klassisk sikkerhetsnivå | Cirka 128 bit | Cirka 128 bit (256-bit kurver) |
| Post-kvantesikker | Nei | Nei |
| NIST-standardisert | Nei | Ja (FIPS 186-5) |
| Hovedytelseskostnad | Par-basert verifisering | Skalarmultiplikasjon og nonce-håndtering |
| Krever Proof-of-Possession mot rogue-key-angrep | Ja, ved aggregering | Ikke relevant |
| Typisk bruksområde | Konsensus, terskelsignaturer, validatornettverk | Transaksjoner, TLS, sertifikater, web-PKI |
Legg merke til at BLS har et litt større fotavtrykk per signatur og nøkkel enn ECDSA. Fordelen kommer først når antallet signerende parter stiger, fordi BLS lar deg erstatte N separate signaturer med én aggregert signatur, mens ECDSA alltid krever N signaturer lagret og overført separat.
To rader i tabellen fortjener litt ekstra forklaring. NIST-standardisering betyr i praksis at ECDSA har en formell spesifikasjon (FIPS 186-5) som myndigheter, revisorer og compliance-ansvarlige kan peke på direkte. BLS mangler et tilsvarende FIPS-dokument, selv om algoritmen er godt beskrevet gjennom IETFs BLS-signaturutkast i regi av IRTF CFRG. Raden om Proof-of-Possession er ikke en formalitet. Uten den kravet kan en aggregeringsprotokoll bli utsatt for rogue-key-angrep, der en deltaker konstruerer en offentlig nøkkel som ser gyldig ut, men som i realiteten gjør det mulig å forfalske en aggregert signatur sammen med andres gyldige nøkler.
Raden om sikkerhetsantakelse er den som ofte overses i raske sammenligninger, men den er viktig for alle som må gjøre en risikovurdering. ECDSA sin sikkerhet hviler på ett enkelt, grundig studert problem: det diskrete logaritme-problemet over en elliptisk kurve. BLS hviler på samme grunnproblem, pluss en ekstra familie av par-spesifikke antakelser. Flere antakelser betyr ikke automatisk svakere sikkerhet i praksis, men det betyr at et sikkerhetsbevis for BLS er mer sammensatt enn for ECDSA, og at eventuelle fremtidige kryptanalytiske fremskritt mot par-baserte konstruksjoner ville kunne påvirke BLS uten nødvendigvis å påvirke ECDSA på samme måte.
Aggregering: hvorfor BLS forandrer valideringsarbeidet
Aggregering er ikke bare en komprimeringstrick. Den endrer hvordan et nettverk med mange signerende noder skalerer. I et system med tusenvis av validatorer som alle skal signere den samme meldingen, vokser mengden data som må lagres og overføres lineært med ECDSA. Med BLS kan de samme tusenvis av signaturene kombineres til én enkelt signatur som verifiseres i en operasjon, uavhengig av hvor mange som opprinnelig signerte.
Chia Network beskriver dette direkte i sin tekniske dokumentasjon fra mars 2026: BLS-signaturer er aggregerbare, og tusenvis av individuelle signaturer fra tusenvis av myntbruk kollapser til én enkelt valideringsoperasjon, ifølge Chia Network. Det samme prinsippet driver Ethereums konsensuslag, der beacon chain-validatorer bruker BLS12-381 til attestasjoner, aggregering, synkroniseringskomiteer og validatorsignaturer. Aggregeringen reduserer båndbreddebehovet i konsensusmeldinger drastisk, siden noder ikke lenger må overføre og lagre hver enkelt validatorsignatur separat.
Under er en forenklet illustrasjon av hvordan aggregering fungerer matematisk. Dette er konseptuell pseudokode, ikke en kopi fra et spesifikt bibliotek, men den viser prinsippet bak BLS-aggregering: signaturer er punkter på en elliptisk kurve, og punktaddisjon gir aggregering nesten gratis.
# Konseptuell illustrasjon av BLS-aggregering
# sig_i = skalarmultiplikasjon(privat_nokkel_i, hash_til_kurve(melding))
aggregert_signatur = sig_1
for sig_i in [sig_2, sig_3, ..., sig_N]:
aggregert_signatur = punkt_addisjon(aggregert_signatur, sig_i)
# Verifisering skjer med en par-operasjon mot
# aggregerte offentlige nokler, ikke N separate operasjoner
er_gyldig = pairing_check(aggregert_signatur, aggregerte_offentlige_nokler, melding)ECDSA tilbyr ingen ekvivalent mekanisme. Multisignaturer basert på ECDSA krever enten at alle signaturer lagres individuelt, eller at systemet går over til en helt annen konstruksjon som MuSig2, som er bygget på Schnorr-matematikk. Vil du ha ekte aggregering uten å endre signaturalgoritme fullstendig, er BLS i praksis det eneste alternativet blant de to.
En annen praktisk konsekvens av aggregering er hvordan feilsøking fungerer når noe går galt. Med ECDSA kan en node umiddelbart peke ut nøyaktig hvilken signatur som var ugyldig, siden hver signatur verifiseres separat. Med en fullt aggregert BLS-signatur vet noden bare at summen ikke stemmer, ikke hvilken av de opprinnelige bidragsyterne som leverte en feil signatur. Systemer som bruker BLS-aggregering i produksjon må derfor bygge inn egne mekanismer for å identifisere og isolere feilende deltakere, typisk gjennom binær søking blant delmengder av signaturene eller ved å kreve at hver deltaker også sender sin individuelle signatur til verifisering i bakgrunnen.
Det er også verdt å skille mellom ekte aggregering og batch-verifisering. Aggregering slår flere signaturer sammen til én enkelt matematisk enhet før verifisering, slik Ethereums synkroniseringskomiteer og Chias myntbruk gjør. Batch-verifisering er noe annet: klienten lar være å aggregere signaturene i seg selv, men verifiserer flere signaturer samlet i en optimalisert operasjon for å spare regnekraft. Begge teknikkene er nyttige og utfyller hverandre, men bare aggregering gir den dramatiske lagrings- og båndbreddegevinsten som er vist i kostnadstabellen senere i artikkelen.
Ytelse og benchmarks fra tre kilder
Ytelsestall for kryptografiske algoritmer varierer enormt med prosessor, biblioteksvalg, batch-størrelse og om undergruppekontroller er aktivert. Det finnes ikke noe pålitelig 2025/2026-benchmarktabell som sammenligner blst, py_ecc og OpenSSL under identiske forhold, så et enkelt tall som “BLS er X ganger tregere” ville vært misvisende. Det vi derimot har, er konkrete tall fra navngitte, verifiserte kilder.
IRTF CFRG, forfatterne av BLS-signaturspesifikasjonen hos IETF, oppgir konkrete tidsverdier for ECDSA: “For 128 bits security, ECDSA takes 37 and 79 micro-seconds to sign and verify a signature on a typical laptop”, ifølge IETF. Det betyr 37 mikrosekunder for signering og 79 mikrosekunder for verifisering på en vanlig bærbar PC, for 128-bit sikkerhetsnivå.
NISTs kryptografiske modulteam har presentert en direkte sammenligning mellom BLS, ECDSA og Schnorr på flere dimensjoner: terskelsignering, multisignaturer, aggregering, kompakthet og ytelse. Konklusjonen deres er at BLS er mest terskel-, multisig- og aggregeringsvennlig av de tre, ifølge NISTs presentasjonsmateriale.
Den tredje kilden er Chia Networks egen tekniske dokumentasjon, som kvantifiserer aggregeringsgevinsten i praksis: tusenvis av signaturer kollapser til én valideringsoperasjon. Samlet gir de tre kildene et konsistent bilde. ECDSA er billig å verifisere isolert, spesielt i optimaliserte OpenSSL-bygg. BLS blir mer attraktivt når aggregeringen reduserer tusenvis av signaturer til ett objekt, selv om hver enkelt par-verifisering i seg selv er tyngre beregningsmessig enn en enkelt ECDSA-verifisering.
Når du selv leser et benchmark for en av algoritmene, bør du sjekke hvilke forutsetninger tallet bygger på før du stoler på det. Relevante variabler inkluderer prosessormodell og instruksjonssett, om implementasjonen er kompilert native kode eller tolket (som ren Python), om testen måler en enkelt verifisering eller batch-verifisering, om BLS-undergruppekontroller er aktivert, hvilken kurve og hash-til-kurve-modus som brukes, og hvor mange signaturer som inngår i et eventuelt aggregeringsscenario. Et benchmark som utelater disse detaljene gir et tall uten kontekst, og slike tall bør behandles med skepsis uansett hvor imponerende de ser ut.
Virkelige eksempler: hvem bruker BLS, og hvem bruker ECDSA
Teori blir konkret når man ser hvilke systemer som faktisk har valgt hver algoritme, og hvorfor. Mønsteret under er ikke tilfeldig, det følger direkte av hvor mange parter som må signere samtidig i hvert system.
Blokkjeder og systemer som bruker BLS
- Ethereums konsensuslag: Beacon chain-validatorer bruker BLS12-381 til attestasjoner, aggregering, synkroniseringskomiteer og validatorsignaturer. Dette er separat fra kontolaget, som fortsatt bruker ECDSA.
- Chia Network: Bruker BLS-aggregering i stor skala for å validere myntbruk, der mange individuelle signaturer slås sammen til én.
- Dfinity / Internet Computer: Bruker BLS12-381-kompatible signaturer i terskelsignaturmekanismer knyttet til undernett (subnets).
- Zcash: Bruker BLS12-381-relatert kryptografi i deler av sitt Sapling-baserte bevis- og verifiseringssystem, men ikke som algoritme for hver enkelt transaksjonssignatur.
Det som binder disse fire eksemplene sammen, er at hvert system periodisk må håndtere et stort antall signaturer fra mange uavhengige deltakere nesten samtidig. Ethereums beacon chain produserer en ny slot hvert tolvte sekund, og hver slot krever attestasjoner fra tusenvis av validatorer. Chia validerer potensielt enorme mengder myntbruk i hver blokk. I begge tilfeller ville det vært upraktisk tungt å lagre og overføre hver signatur separat, noe som gjør aggregeringsegenskapen til BLS til en arkitekturell nødvendighet snarere enn en teoretisk fordel.
Systemer som fortsatt bruker ECDSA
- Bitcoin: Standard transaksjonssignaturer bruker ECDSA over secp256k1. Taproot-oppgraderingen la til støtte for Schnorr-signaturer, men ECDSA er fortsatt i utbredt bruk.
- Ethereums kontolag: Brukerkontoer og transaksjonsautorisasjon bruker ECDSA over secp256k1, uavhengig av at konsensuslaget bruker BLS.
- TLS og web-PKI: Nettlesersertifikater og store deler av offentlig nøkkelinfrastruktur bruker ECDSA med NIST-kurvene P-256, P-384 og P-521, ofte sammen med RSA og EdDSA. BLS er ikke en normal sertifikatalgoritme i nettlesere.
Mønsteret er tydelig. Systemer som trenger å validere svært mange signaturer samtidig, som blokkjede-konsensus, lener seg mot BLS. Systemer som trenger bred kompatibilitet med eksisterende lommebøker, maskinvare og sertifikatinfrastruktur, holder seg på ECDSA. De tre ECDSA-eksemplene over deler et motsatt kjennetegn av BLS-eksemplene: hver signatur blir sjekket individuelt, av en enkelt part, mot en enkelt nøkkel, uten behov for å kombinere den med tusenvis av andre signaturer. Det er nøyaktig scenarioet der ECDSA sin enkelhet og modenhet slår BLS sin aggregeringsevne.
Kostnadsbilde: lagringsplass og båndbredde i praksis
BLS og ECDSA er protokoller, ikke abonnementstjenester, så det gir ikke mening å sette en kronepris på dem. Den relevante “prisen” i blokkjedesammenheng er lagringsplass og båndbredde, som direkte påvirker gebyrer og nodekrav. Tabellen under er et regnestykke basert på de dokumenterte byte-størrelsene fra spesifikasjonstabellen, ikke en offisiell benchmark, og viser hvordan kostnaden utvikler seg når antall signerende parter øker.
| Scenario | Datamengde med ECDSA | Datamengde med BLS |
|---|---|---|
| 1 signatur | 64 til 72 byte | 96 byte |
| 10 signerende parter (uten aggregering) | Cirka 640 til 720 byte | 960 byte (uten aggregering) |
| 10 signerende parter (med BLS-aggregering) | Ikke mulig uten egen protokoll | 96 byte (1 aggregert signatur) |
| 1000 signerende parter (uten aggregering) | Cirka 64 000 til 72 000 byte | 96 000 byte (uten aggregering) |
| 1000 signerende parter (med BLS-aggregering) | Ikke mulig uten egen protokoll | 96 byte (1 aggregert signatur) |
| Offentlige nøkler, 1000 parter | 33 000 byte | 48 000 byte |
Tabellen viser det sentrale poenget konkret. Uten aggregering er BLS faktisk litt dyrere per signatur enn ECDSA. Gevinsten kommer bare når aggregering faktisk brukes, og da snur regnestykket fullstendig i BLS sin favør for antall signaturer som må lagres og overføres. Offentlige nøkler aggregeres ikke på samme måte, så den kostnaden forblir proporsjonal med antall deltakere for begge algoritmer.
I et nettverk som Ethereums beacon chain, med flere hundre tusen aktive validatorer, blir denne forskjellen ikke bare teoretisk. Hver eneste slot krever attestasjoner fra et stort antall av disse validatorene, og hvis hver attestasjon måtte overføres som en separat signatur, ville nettverkstrafikken mellom noder vokse til et nivå som ville gjort det vanskeligere å drive en node på vanlig forbrukermaskinvare. Aggregering er derfor ikke bare en optimalisering for Ethereum, den er en forutsetning for at desentralisert konsensus med så mange deltakere skal være praktisk gjennomførbart i utgangspunktet.
Sikkerhetsantakelser: diskret logaritme mot par-basert kryptografi
Begge algoritmer bygger til syvende og sist på at det diskrete logaritme-problemet over elliptiske kurver er vanskelig å løse med klassiske datamaskiner. ECDSA stopper der. BLS legger til et ekstra lag: par-spesifikke antakelser, ofte uttrykt som varianter av co-Diffie-Hellman-problemet i de relevante pargruppene. Flere matematiske antakelser betyr i prinsippet flere steder noe kan vise seg svakere enn forventet over tid, selv om BLS12-381 i dag anses som godt studert og mye brukt i produksjon.
En praktisk sikkerhetsrisiko som er spesifikk for BLS, er rogue-key-angrep i aggregeringsscenarioer. Hvis en angriper kan velge sin offentlige nøkkel fritt etter å ha sett andres nøkler, kan de i teorien konstruere en falsk aggregert signatur. Løsningen er Proof-of-Possession, der hver deltaker må bevise at de faktisk kjenner den private nøkkelen som tilhører sin offentlige nøkkel, før nøkkelen godtas inn i et aggregeringsoppsett. Dette er obligatorisk i alle seriøse BLS-implementasjoner som brukes til aggregering i dag.
ECDSA har sin egen historie med fallgruver, spesielt rundt dårlig tilfeldighetsgenerering i nonce-verdien, som har ført til faktiske nøkkellekkasjer i produksjonssystemer tidligere. Moderne implementasjoner bruker deterministisk nonce-generering etter RFC 6979 for å eliminere denne risikoklassen. Ingen av algoritmene er dermed “tryggere enn den andre” i et generelt sikkerhetsperspektiv. Risikoprofilene er bare forskjellige.
Signaturmalleabilitet er en annen praktisk detalj som skiller de to. ECDSA-signaturer kan kodes på mer enn én gyldig måte, og tidlige Bitcoin-implementasjoner måtte legge til en egen regel, “low-S”, for å hindre at noder regnet to ulike kodinger av samme signatur som to forskjellige transaksjoner. BLS-signaturer har en enklere kanonisk form når de implementeres korrekt, men introduserer i stedet en annen klasse av implementasjonsrisiko gjennom undergruppekontroller og hash-til-kurve-funksjonen, som begge må være riktige for at sikkerhetsbeviset bak algoritmen skal holde.
Hva fagfolk sier om BLS og ECDSA
NISTs kryptografiske modulteam har presentert BLS sin kjernegenskap i et offentlig foredrag: “Furthermore, BLS supports easy aggregation of multiple signatures on the same messages but with different public keys (multi-signatures) and also various signatures on different messages (aggregate signatures)”, ifølge NIST.
Forfatterne av IETFs BLS-signaturspesifikasjon beskriver samme egenskap fra et teknisk perspektiv: “BLS also allows for signature aggregation. In other words, a single signature is sufficient to authenticate multiple messages and public keys”, ifølge IETF-dokumentet nevnt ovenfor. De samme forfatterne har også oppgitt det konkrete ytelsestallet for ECDSA referert tidligere i artikkelen, hentet fra samme spesifikasjonsdokument.
Vitalik Buterin, Ethereums medgrunnlegger og protokollforsker, har diskutert batch-verifisering av BLS-signaturer som en ytelsesoptimalisering på klientsiden i Ethereums forskningsforum. Han beskriver teknikken som “a purely client-side optimization that can voluntarily be done by clients verifying blocks that contain multiple signatures”, ifølge Ethereum Research. Poenget hans er at klienter kan velge å batch-verifisere flere BLS-signaturer samtidig for å spare beregningstid, uten at dette er påkrevd av protokollen selv.
I samme NIST-presentasjon rangeres BLS konkret som den mest terskel-, multisig- og aggregeringsvennlige av de tre algoritmene som ble sammenlignet, der konklusjonen oppsummeres som at BLS er det mest aggregeringsvennlige alternativet av algoritmene som ble vurdert.
Det som gjør disse fem kildene nyttige sammen, er at de kommer fra tre helt forskjellige vinkler på samme spørsmål. NIST representerer standardiseringsperspektivet og vurderer BLS opp mot etablerte alternativer på en strukturert måte. IETF-spesifikasjonsforfatterne representerer den tekniske protokolldefinisjonen, med konkrete tallverdier for ytelse. Vitalik Buterin representerer et operativt blokkjedeperspektiv, der batch-verifisering er en reell optimalisering utviklere faktisk bruker i klientkode. Ingen av dem motsier hverandre. De bekrefter i stedet samme konklusjon fra tre uavhengige synsvinkler: aggregering er BLS sin reelle, dokumenterte fordel, ikke en markedsføringspåstand.
Implementasjonsbiblioteker: hva produksjonssystemer faktisk bruker
Valget av bibliotek påvirker ytelsen vel så mye som valget av algoritme. For BLS er blst den mest brukte høyytelsesimplementasjonen i produksjon, skrevet i lavnivåkode og optimalisert for nettopp BLS12-381-operasjoner som par-beregning og hash-til-kurve. py_ecc, derimot, er primært en referanseimplementasjon i Python, bygget for å være lett å lese og verifisere korrekthet mot, ikke for å kjøre fort. Å sette dem opp mot hverandre som om de representerte sammenlignbar produksjonsytelse gir et misvisende bilde, siden den ene er en ren læringsreferanse.
For ECDSA er situasjonen motsatt. OpenSSL sin mest optimaliserte vei er bygget rundt ECDSA og tradisjonell elliptisk-kurve-matematikk, ikke BLS12-381 og par-operasjoner, siden dette har vært biblioteket sitt kjerneområde i over to tiår. JavaScript-miljøer har de siste årene fått tilgang til BLS12-381 gjennom biblioteker som noble-curves, som eksplisitt lister opp Ethereum, Chia, Dfinity, Filecoin, Algorand og Zcash som kompatible målsystemer. Dette gjør det stadig enklere å bygge BLS-baserte applikasjoner uten å skrive lavnivå par-aritmetikk selv, men det fjerner ikke behovet for å forstå undergruppekontroller, domeneseparasjon og Proof-of-Possession før koden settes i produksjon.
Bruksområder: når bør du velge BLS, og når bør du velge ECDSA
Valget avhenger nesten alltid av ett spørsmål: må systemet ditt validere svært mange signaturer samtidig, eller må det snakke med eksisterende infrastruktur som allerede forventer ECDSA?
| Scenario | Anbefalt algoritme | Begrunnelse |
|---|---|---|
| Blokkjede-konsensus med mange validatorer | BLS | Aggregering reduserer båndbredde og lagringskrav drastisk |
| Betalingssystemer og lommebøker | ECDSA | Bred kompatibilitet med hardware-lommebøker og eksisterende verktøy |
| TLS-sertifikater og web-PKI | ECDSA | Nettlesere og sertifikatmyndigheter forventer standardiserte algoritmer |
| Terskelsignatur- og multi-part-oppsett | BLS | Native aggregering uten separat multisig-protokoll |
| Synkroniseringskomiteer i konsensusprotokoller | BLS | Mange signaturer må komprimeres til en verifiserbar enhet |
| Nye blokkjeder med begrenset verktøystøtte | ECDSA | Enklere å finne revisorer, biblioteker og utviklere med erfaring |
| Systemer som krever NIST-standardisert algoritme | ECDSA | FIPS 186-5 dekker ECDSA, ikke BLS |
Legg merke til at svaret ikke alltid er binært. Ethereum selv kjører begge algoritmer samtidig i to forskjellige lag av samme nettverk, fordi de to lagene har fundamentalt forskjellige krav til signaturvalidering. Tommelfingerregelen er enkel å huske: tell hvor mange uavhengige parter som typisk må signere den samme meldingen eller blokken samtidig i systemet ditt. Er svaret i enkelttall, gir BLS sjelden nok fordel til å rettferdiggjøre kompleksiteten. Er svaret i hundrevis eller tusenvis, snur regnestykket raskt i BLS sin favør, slik kostnadstabellen tidligere i artikkelen illustrerer.
Migrasjonsguide: fra et ECDSA-basert system til BLS, eller en hybridløsning
Å bytte signaturalgoritme i et produksjonssystem er ikke en enkelt kodeendring. Det påvirker nøkkelformater, lommebokkompatibilitet, konsensusregler og i mange tilfeller tidligere lagrede data som må forbli verifiserbare. Her er stegene som i praksis styrer en forsvarlig migrering eller et hybridoppsett.
- Kartlegg aggregeringsbehovet først. Hvis systemet ditt aldri trenger å validere mer enn noen få signaturer samtidig, gir BLS sannsynligvis ikke nok gevinst til å rettferdiggjøre kompleksiteten.
- Velg kurve og bibliotek med omhu. BLS12-381 er de facto-standarden. For produksjon bør du bruke et høyytelsesbibliotek som blst, ikke referanseimplementasjoner som py_ecc, som er bygget for læring og testing.
- Implementer domeneseparasjon korrekt. BLS-signaturer må bindes til en spesifikk kontekst (domain separation tag) for å unngå at samme signatur kan misbrukes i en annen protokoll.
- Aktiver undergruppekontroller. Manglende validering av at punkter faktisk ligger i riktig undergruppe på kurven er en kjent kilde til sårbarheter i BLS-implementasjoner.
- Krev Proof-of-Possession for alle deltakere. Dette stopper rogue-key-angrep før aggregering tas i bruk, og bør være en hard forutsetning, ikke en valgfri innstilling.
- Behold ECDSA for ytre kompatibilitet. Hvis systemet ditt må snakke med lommebøker, sertifikatmyndigheter eller eksisterende infrastruktur, behold ECDSA i de grensesnittene selv om det interne konsensuslaget bruker BLS.
- Test interoperabilitet grundig. Kjør parallelle valideringer mot referanseimplementasjoner før du stoler fullt på en ny BLS-integrasjon i produksjon. Bruk gjerne py_ecc eller en annen referanseimplementasjon som sannhetskilde i testene, selv om den er for treg til produksjonsdrift.
- Dokumenter nøkkelformatet eksplisitt. BLS og ECDSA bruker helt forskjellige nøkkelstørrelser og kodinger. Systemer som lagrer nøkler i databaser, API-er eller lommebøker må oppdatere valideringslogikk og lagringsskjema samtidig, ikke i separate utrullinger.
- Planlegg for en fremtidig overgang til post-kvantealgoritmer. Verken BLS eller ECDSA er kvantesikre, så en migreringsplan bør aldri anta at valget er permanent.
Ethereums egen arkitektur er et godt forbilde for hybridtilnærmingen. Konsensuslaget kjører BLS for validatorsignaturer, mens kontolaget fortsatt kjører ECDSA for brukertransaksjoner. De to lagene snakker aldri direkte samme signaturspråk, og det er helt bevisst. Et nytt prosjekt som designer et validatornettverk fra grunnen av, bør se på denne separasjonen som en arkitekturmal snarere enn en historisk tilfeldighet: la det laget som trenger massiv aggregering bruke BLS, og la laget som trenger bred ekstern kompatibilitet bruke ECDSA, i stedet for å tvinge hele systemet gjennom én algoritme.
Fordeler og ulemper
Oppsummert i rene fordeler og ulemper, uten å blande inn konteksten fra tidligere avsnitt, ser bildet slik ut for hver algoritme.
BLS-signaturer, fordeler:
- Native aggregering av tusenvis av signaturer til én
- Reduserer båndbredde og lagringskrav dramatisk i validatornettverk
- Støtter terskelsignaturer og multi-part-oppsett uten separat protokoll
- Godt studert sikkerhetsgrunnlag gjennom BLS12-381 i produksjon
BLS-signaturer, ulemper:
- Krever par-operasjoner, som er tyngre å implementere korrekt enn ECDSA
- Ikke NIST-standardisert på samme måte som ECDSA
- Sårbar for rogue-key-angrep uten Proof-of-Possession
- Mindre verktøy- og hardware-støtte enn ECDSA i dag
ECDSA, fordeler:
- Bredest mulige kompatibilitet med lommebøker, hardware og biblioteker
- NIST-standardisert gjennom FIPS 186-5
- Lavere implementasjonskompleksitet enn par-basert kryptografi
- Veldokumentert i over et tiår med produksjonsbruk i Bitcoin og TLS
ECDSA, ulemper:
- Ingen native aggregering, må bruke separate protokoller som MuSig2
- Skalerer dårlig når svært mange parter må signere samtidig
- Historisk sårbar for dårlig nonce-generering uten RFC 6979
Post-kvante-utsikten for begge algoritmene
Ingen av algoritmene er trygge mot en tilstrekkelig kraftig kvantedatamaskin som kjører Shors algoritme. Både BLS og ECDSA bygger på det diskrete logaritme-problemet over elliptiske kurver, og det problemet faller hvis store nok kvantedatamaskiner blir en realitet. NIST har allerede ferdigstilt sine første post-kvante-signaturstandarder, ML-DSA (FIPS 204) og SLH-DSA (FIPS 205), og anbefaler at organisasjoner begynner migreringsplanlegging nå i stedet for å vente.
NIST fortsatte også arbeidet med flere post-kvante-signaturkandidater i 2025 og 2026. Ni kandidater gikk videre til tredje runde av prosessen for tilleggssignaturer i mai 2026, ifølge NISTs offentlige statusrapporter. Dette viser at feltet fortsatt er i aktiv standardisering, og at verken BLS eller ECDSA kommer til å bli erstattet av en ferdig løsning over natten.
For blokkjedesystemer er dette spesielt vanskelig fordi en overgang til post-kvantealgoritmer ikke bare handler om å bytte ut selve signaturfunksjonen. Nøkkelformater, transaksjonsgrenser, validator- og kontostrukturer, maskinvareakselerasjon, konsensusregler og bakoverkompatibilitet må alle vurderes samtidig. En hybrid tilnærming, der eksisterende ECDSA- eller BLS-signaturer kombineres med en post-kvante-algoritme i en overgangsperiode, er den mest realistiske veien fremover for systemer som allerede har betydelig verdi låst i eksisterende signaturskjemaer. Ingen store blokkjeder har i dag annonsert en fullstendig overgang bort fra BLS eller ECDSA, men planleggingsarbeidet er tydelig i gang hos standardiseringsorganer som NIST.
Størrelsesforskjellen mellom dagens algoritmer og post-kvante-alternativene er betydelig. En forskningsartikkel om kryptovaluta i kvantealderen viser at ML-DSA-44-signaturer er 2420 byte, mot 64 byte for Ed25519, ifølge en 2026-forskningsartikkel på arXiv. Det er over 37 ganger større. For blokkjedesystemer som allerede sliter med lagringskostnad per signatur, forklarer dette hvorfor kompakt aggregering med BLS forblir attraktivt selv om BLS i seg selv ikke er kvantesikker. Migrering til post-kvantealgoritmer for validatornettverk som i dag bruker BLS, vil kreve nøye vurdering av nøyaktig denne størrelsesøkningen.
Verdikt: hvilken bør du velge i 2026?
Svaret er ikke at en algoritme er bedre enn den andre generelt. Dataene peker mot et klart skille basert på arkitektur. Velg BLS når systemet ditt må validere et stort antall signaturer samtidig, som i blokkjede-konsensus, synkroniseringskomiteer eller terskelsignaturoppsett, og du kan akseptere kompleksiteten som følger par-basert kryptografi og Proof-of-Possession. Velg ECDSA når bred kompatibilitet med eksisterende lommebøker, hardware, sertifikatmyndigheter og biblioteker er viktigere enn å spare plass på aggregerte signaturer.
Ethereums arkitektur illustrerer hvorfor dette ikke trenger å være et enten-eller-valg. Konsensuslaget kjører BLS fordi tusenvis av validatorer signerer samtidig hver eneste slot. Kontolaget kjører ECDSA fordi det må forbli kompatibelt med alt fra hardware-lommebøker til tiår med eksisterende verktøy. Begge valgene er riktige for sitt respektive lag, og det er nøyaktig den typen vurdering du bør gjøre for ditt eget system før du lener deg mot én algoritme for alt.
Uansett hvilken du velger i dag, er ingen av dem et permanent svar. Begge bygger på elliptisk-kurve-matematikk som en tilstrekkelig kraftig kvantedatamaskin kan knekke, så en realistisk plan for 2026 og videre bør inkludere et blikk mot NISTs ferdigstilte post-kvante-standarder, selv om selve overgangen trolig ligger flere år fram.
Den praktiske testen du kan bruke på ditt eget system er enkel. Skriv ned hvor mange uavhengige signaturer som typisk må verifiseres mot samme melding i løpet av noen sekunder i produksjon. Er svaret lavt, vil ECDSA sin modenhet og brede verktøystøtte nesten alltid vinne på enkelhet alene. Er svaret høyt og stigende, som i et validatornettverk som vokser, er BLS sin aggregeringsevne ikke bare en fordel, men etter en viss skala en arkitekturell forutsetning for at systemet skal fungere effektivt i det hele tatt.
Ofte stilte spørsmål
Er BLS-signaturer raskere enn ECDSA?
Det finnes ikke et pålitelig, direkte sammenlignbart 2025/2026-benchmark mellom de to for enkeltsignaturer. ECDSA-verifisering er vanligvis billigere isolert, spesielt i optimaliserte OpenSSL-bygg, mens BLS blir mer effektivt totalt sett når aggregering av mange signaturer er involvert.
Hvorfor bruker Ethereum både BLS og ECDSA?
Fordi de to lagene i nettverket har forskjellige krav. Konsensuslaget trenger å validere tusenvis av validatorsignaturer effektivt gjennom aggregering, mens kontolaget trenger bred kompatibilitet med eksisterende lommebøker og verktøy som forventer ECDSA.
Kan ECDSA-signaturer aggregeres?
Ikke nativt. Standard ECDSA har ingen innebygd aggregeringsmekanisme. Multisignaturoppsett basert på ECDSA krever enten at alle signaturer lagres separat, eller at systemet bruker en helt annen konstruksjon som MuSig2, som er bygget på Schnorr-matematikk.
Er BLS12-381 den eneste kurven som brukes til BLS-signaturer?
Det er den dominerende kurven i produksjon i dag, brukt av blant annet Ethereum, Chia, Dfinity og deler av Zcash sitt system. Andre parvennlige kurver eksisterer, men BLS12-381 har bred verktøystøtte og er den mest utbredte.
Er BLS eller ECDSA trygge mot kvantedatamaskiner?
Nei, ingen av dem. Begge bygger på det diskrete logaritme-problemet over elliptiske kurver, som en tilstrekkelig kraftig kvantedatamaskin som kjører Shors algoritme kan knekke. NIST anbefaler migreringsplanlegging mot ferdigstilte post-kvante-standarder som ML-DSA og SLH-DSA.
Bør en ny blokkjede velge BLS eller ECDSA?
Det avhenger av konsensusmodellen. Hvis prosjektet har mange validatorer som signerer samtidig i hver blokk eller hver slot, gir BLS en reell skaleringsfordel. Hvis prosjektet prioriterer rask integrasjon med eksisterende lommebøker og verktøy, er ECDSA det tryggere og mer veldokumenterte valget å starte med.
Hva er et rogue-key-angrep, og hvorfor er det relevant for BLS?
Det er et angrep der en deltaker velger sin offentlige nøkkel på en måte som utnytter aggregeringsmatematikken til å konstruere en falsk aggregert signatur. Proof-of-Possession, der hver deltaker beviser at de faktisk eier den tilsvarende private nøkkelen, er den etablerte motvirkningen og bør være obligatorisk i alle BLS-aggregeringsoppsett.
Kan jeg bruke BLS-signaturer i en nettleserapplikasjon?
Det er mulig gjennom biblioteker som noble-curves, som implementerer BLS12-381 i JavaScript og er kompatibelt med økosystemer som Ethereum, Chia, Dfinity og Zcash. Standard nettlesersertifikater og TLS-forbindelser bruker likevel fortsatt ECDSA eller RSA, ikke BLS, så BLS i en nettleserkontekst er typisk knyttet til en spesifikk applikasjon som selv implementerer verifiseringslogikken, ikke til sertifikatinfrastrukturen i seg selv.