Ethereum L2 BB84 schrapt transactiesignaturen om kwantumdreiging te weerstaan
Belangrijkste punten
- •BB84 draait sinds 30 september op Ethereum mainnet en heeft ECDSA-handtekeningen vervangen door keccak-256 hash-chain-accounts om blootstelling aan toekomstige kwantumaanvallen te verminderen.
- •Betalingen op het netwerk worden uitsluitend afgewikkeld in gebrugde USDC en EURC, met gratis commit- en reveal-transacties voor gebruikers en per ontvanger een nieuw eenmalig adres.
- •Een front-running-kwetsbaarheid in niet-ondertekende commits werd ontdekt tijdens het schrijven van de onderzoekspost en op 21 oktober verholpen met een first-commit-wins-regel, al blijven griefing- en rogue-sequencer-risico's bestaan.
- •De rollup heeft geen fault proofs en zou volgens het staging-raamwerk L2BEAT niet eens Stage 0 zijn, waardoor opnames afhankelijk zijn van een gepermiteerde proposer.
- •Hadamard stelt voor dat hash-chain-validatie zou kunnen worden opgenomen als EIP-7702-achtige of native account-abstraction-modus op algemene layer-2-netwerken; een uitvoeriger uitwerking wordt voorbereid voor arXiv.

BB84, een OP Stack rollup die live is op Ethereum mainnet onder chain ID 42069000, heeft transactiesignaturen volledig uit zijn netwerk verwijderd en vervangen door Lamport-achtige hashketens, in een ontwerp dat bedoeld is om de langetermijnkwantumdreiging voor conventionele cryptografie af te zwakken. Het netwerk draait sinds 30 september op mainnet. De oprichter, die publiceert onder het pseudoniem Hadamard, beschreef het systeem in een Ethereum Research-post van 24 oktober en verzocht om kritische feedback.
Gewone Ethereum-accounts autoriseren transacties met ECDSA-handtekeningen, die een voldoende grote kwantumcomputer met Shor's algoritme zou kunnen breken. Vandaag bestaat er geen machine die dat kan, maar waarschuwingen over blootgestelde walletsleutels hebben ontwikkelaars aangezet om naar alternatieven te zoeken — een sleutel wordt publiek zichtbaar zodra een account een transactie heeft verstuurd. Hash-gebaseerde constructies behoren ook tot de oudste post-kwantumkandidaten: Leslie Lamport stelde in 1979 een hash-gebaseerd handtekeningschema voor, en de post-kwantumstandaarden van NIST uit 2024 omvatten een hash-gebaseerd schema, SLH-DSA.
Hash-chain-accounts, één stap per keer
Elk BB84-account is opgebouwd uit een geheim dat steeds opnieuw wordt gehasht met keccak-256 — dezelfde hashfunctie die Ethereum zelf gebruikt — waardoor een keten van waarden ontstaat waarbij alleen de laatste waarde publiek is. Om te betalen, onthult de wallet de waarde vóór de huidige positie, die iedereen kan verifiëren door hem één keer te hashen. Het netwerk registreert die waarde vervolgens en schuift het account één stap op in de keten.
De protocolstandaard is 1.000 betalingen per hashketen, terwijl de developer-CLI van BB84 ketens van 10 stappen aanmaakt voor elk eenmalig adres. Een stap wordt verbruikt zelfs als de betaling zelf mislukt, en de keten verwerpt elkeioneel ondertekende transactie.
Betalingen verlopen uitsluitend in gebrugde USDC en EURC. Zowel de commit- als de reveal-transacties zijn gratis voor gebruikers, en betalers maken per ontvanger een nieuw eenmalig adres aan.
De security-afweging
De post schetst de grenzen van het ontwerp. Binnen het netwerk rust alles op het feit dat keccak-256 moeilijk om te keren is, en Grover's kwantum-zoekalgoritme zou dat slechts terugbrengen tot ongeveer 2^128 operaties. Adressen zijn echter ingekort tot 160 bits, wat ongeveer 2^80 aan kwantumweerstand overlaat op het adres zelf. De documentatie van BB84 adverteert met 128-bit post-kwantumbeveiliging zonder die kanttekening. Ethereum mainnet is bovendien nog steeds ECDSA: stortingen beginnen bij gewone Ethereum-wallets en opnames worden daarnaar uitbetaald.
Een front-running-fout gevonden tijdens het schrijven van de post
Het onthullen van een geheim maakt het publiek, dus iedereen die meekijkt zou het kunnen kopiëren naar een transactie die aan zichzelf betaalt. Om dat te voorkomen, stuurt de wallet eerst een commit-transactie die het geheim vergrendelt aan één exacte betaling zonder het te tonen. De reveal moet standaard binnen vijf blokken volgen.
Het zwakke punt was dat commits geen handtekening dragen, omdat er niets is om mee te ondertekenen. In de eerste versie verving een nieuwe commit eenvoudigweg de hangende. Een aanvaller die een geheim in een hangende reveal opmerkte, kon een commit inbouwen die dat geheim aan zijn eigen betaling koppelde. Hadamard zegt dat het team de fout vond tijdens het schrijven van de post en deze verholpen met een nieuwe regel die op 21 oktober inging. Volgens de herziene regel geldt dat de eerste commit wint, de sleuf pas wordt vrijgegeven na de bijbehorende reveal of afloop, de wallet wacht tot zijn commit in een blok is opgenomen voordat hij onthult, en de publieke RPC geen hangende transacties blootgeeft.
Wat de fix onopgelost laat
Griefing blijft mogelijk: iedereen kan een zinloze commit plaatsen en een adres tot vijf blokken blokkeren, hoewel het geld niet kan worden verplaatst. Een rogue sequencer is een ander rest risico: als een eerlijke commit verloopt of door een reorganisatie verdwijnt terwijl de reveal hangt, is het geheim niet langer vergrendeld. Momenteel ziet alleen de eigen sequencer van BB84 hangende transacties.
Hadamard stelt een striktere "Guy Fawkes"-regel voor, waarbij commits worden toegevoegd in plaats van vervangen, maar zegt dat deze niet is gebouwd. De documentatie gaat verder dan de post en stelt dat commit en reveal betekenen dat een sequencer een opname niet kan stelen.
Een wallet die de tel niet mag verliezen
Omdat elke keten een vast aantal stappen heeft, moet de wallet deze bij de allereerste laatste stap vernieuwen door een nieuwe commitment op te nemen in die laatste betaling. Als die stap wordt gemist, is het adres dood. De tel bijhouden is minstens zo: Hadamard zegt dat de app en de keten in productie uit de pas liepen, dus wallets moeten opnieuw kunnen synchroniseren vanaf chaindata.
De geheimen moeten nog steeds worden beschermd zoals sleutels. De CLI waarschuwt dat het walletbestand spend keys onversleuteld opslaat en vermeldt versleuteling als roadmap-item. Het verwijderen van handtekeningen verandert hoe uitgaven worden geautoriseerd, niet de noodzaak om geheimen veilig te bewaren.
Opnames rusten op een vertrouwde operator
BB84 heeft geen fault proofs. Een gepermiteerde proposer publiceert de status van het netwerk naar Ethereum via een custom dispute game die onmiddellijk beslist, en zonder proofsysteem schrijft Hadamard dat de keten volgens het raamwerk van L2BEAT "not even Stage 0" zou zijn. Dat raamwerk beoordeelt rollups van Stage 0 tot Stage 2 op basis van hoeveel gebruikers een operator moeten vertrouwen in plaats van een proofsysteem. Opnames vertrouwen daarom de proposer. De documentatie beschrijft opnames nog steeds als volgend op de OP Stack fault-proof-flow met een volwassenheidsvertraging van zeven dagen, maar zoals Optimism's uitleg uiteenzet, bestaan fault proofs zodat een foutieve status kan worden aangevochten — en hier kan tijdens die wachttijd niets worden aangevochten. De sequencer wordt ook door BB84 gerund.
Wat het beeld zou veranderen
De post sluit af met vragen die verder reiken dan één keten. De grootste is of hash-chain-accounts een EIP-7702-achtige of native account-abstraction-validatiemodus zouden kunnen worden op algemene layer-2-netwerken, waardoor het idee beschikbaar zou komen zonder naar een specifieke keten te hoeven verhuizen. EIP-7702, live sinds Ethereum's Pectra-upgrade in mei 2025, laat gewone accounts smart-contract-code aannemen. Hadamard voegt toe dat de extra controles eenvoudig genoeg zijn om te bewijzen met Optimism's bestaande Cannon-tooling, dat een append-only commit-regel zowel de griefing- als sequencer-lekken zou dichten, en dat een langere uitwerking met de volledige regels wordt voorbereid voor arXiv. Ethereum's bredere migratie-inspanning, uiteengezet in zijn kwantumroadmap, omvat ook validatorhandtekeningen, data-commitments en proofsystemen.
Dit artikel wordt uitsluitend ter informatie verstrekt en vormt geen financieel of beleggingsadvies. Experimentele netwerken brengen technische en custodian-risico's met zich mee.
Bron: Coindoo