Ethereum L2 BB84 rezygnuje z podpisów transakcji, aby przeciwdziałać zagrożeniu kwantowemu
Najważniejsze informacje
- •BB84 działa w sieci głównej Ethereum od 30 września, zastępując podpisy ECDSA kontami opartymi na łańcuchach haszowych keccak-256, aby zmniejszyć ekspozycję na przyszłe ataki kwant.
- •Płatności w sieci rozliczane są wyłącznie w mostkowanych USDC i EURC, transakcje commit i reveal są dla użytkowników bezpłatne, a dla każdego odbiorcy generowany jest świeży jednorazowy adres.
- •Lukę front-runningową w niepodpisanych commitach wykryto podczas pisania posta i naprawiono 21 października dzięki regule „first commit wins”, choć ryzyka griefingu i nieuczciwego sekwencera pozostają.
- •Rollup nie ma dowodów błędów (fault proofs), więc według ram klasyfikacji L2BEAT nie kwalifikowałby się nawet jako Stage 0, co uzależnia wypłaty od uprawnionego proponera.
- •Hadamard sugeruje, że walidacja oparta na łańcuchach haszowych mogłaby zostać przyjęta jako tryb w stylu EIP-7702 lub natywna abstrakcja kont na ogólnych sieciach warstwy drugiej, a pełniejsze opracowanie jest przygotowywane dla arXiv.

BB84, rollup OP Stack działający w sieci głównej Ethereum pod identyfikatorem łańcucha 42069000, całkowicie usunął podpisy transakcji ze swojej sieci, zastępując je łańcuchami haszowanymi w stylu Lamporta — w projekcie mającym stępić długoterminowe kwantowe zagrożenie dla kryptografii konwencjonalnej. Sieć działa w mainnecie od 30 września. Jej twórca, publikujący pod pseudonimem Hadamard, opisał system w poście na Ethereum Research z 24 października i poprosił o krytyczne uwagi.
Zwykłe konta Ethereum autoryzują transakcje podpisami ECDSA, które wystarczająco duży komputer kwantowy działający algorytmem Shora mógłby złamać. Dziś nie istnieje maszyna zdolna do tego, ale ostrzeżenia o narażonych kluczach portfeli skłoniły programistów do poszukiwania alternatyw — klucz staje się publicznie widoczny, gdy tylko konto wyśle transakcję. Konstrukcje oparte na haszowaniu należą też do najstarszych kandydatów postkwantowych: Leslie Lamport zaproponował schemat podpisu oparty na haszowaniu w 1979 roku, a standardy postkwantowe NIST z 2024 roku obejmują schemat haszowy SLH-DSA.
Konta oparte na łańcuchach haszowanych, krok po kroku
Każde konto BB84 jest zbudowane z sekretu, który jest wielokrotnie haszowany funkcją keccak-256 — tą samą, której sam Ethereum używa — tworząc łańcuch wartości, z którego tylko ostatnia jest publiczna. Aby zapłacić, portfel ujawnia wartość poprzedzającą bieżącą pozycję, którą każdy może zweryfikować, haszując ją raz. Sieć następnie rejestruje tę wartość i przesuwa konto o jeden krok w dół łańcucha.
Domyślnie protokół przewiduje 1000 płatności na łańcuch haszowy, natomiast narzędzie CLI deweloperskie BB84 tworzy łańcuchy 10-krok dla każdego jednorazowego adresu. Krok jest zużywany nawet wtedy, gdy sama płatność się nie powiedzie, a łańcuch odrzuca każdą transakcję podpisaną w konwencjonalny sposób.
Płatności odbywają się wyłącznie w mostkowanych USDC i EURC. Zarówno transakcja commit, jak i reveal są dla użytkowników bezpłatne, a płacący tworzy świeży jednorazowy adres dla każdego odbiorcy.
Kompromis w kwestii bezpieczeństwa
Post precyzuje ograniczenia projektu. Wewnątrz sieci wszystko opiera się na trudności odwrócenia keccak-256, a kwantowy algorytm wyszukiwania Grovera skracałby ją jedynie do około 2^128 operacji. Adresy są jednak skracane do 160 bitów, co pozostawia około 2^80 odporności kwantowej na samym adresie. Dokumentacja BB84 reklamuje 128-bitowe bezpieczeństwo postkwantowe bez tego zastrzeżenia. Sieć główna Ethereum nadal również opiera się na ECDSA: wpłaty pochodzą ze zwykłych portfeli Ethereum, a wypłaty są na nie realizowane.
Luka front-runningowa wykryta podczas pisania posta
Ujawnienie sekretu czyni go publicznym, więc każdy obserwujący mógłby skopiować go do transakcji płacącej samemu sobie. Aby temu zapobiec, portfel najpierw wysyła transakcję commit, która blokuje sekret do jednej konkretnej płatności bez jego ujawniania. Reveal musi nastąpić domyślnie w ciągu pięciu bloków.
Słabym punktem było to, że commity nie mają podpisu, bo nie ma się czym podpisywać. W pierwszej wersji nowy commit po prostu zastępował oczekujący. Atakujący, który zauważył sekret w oczekującym reveali, mógł podmienić commit wiążący ten sekret z własną płatnością. Hadamard mówi, że zespół wykrył lukę podczas pisania posta i naprawił ją nową regułą, która weszła w życie 21 października. Zgodnie ze zmienioną regułą wygrywa pierwszy commit, slot jest czyszczony dopiero po pasującym reveali lub wygaśnięciu, portfel czeka, aż jego commit trafi do bloku, zanim ujawni sekret, a publiczne RPC nie ujawnia oczekujących transakcji.
Czego poprawka nie obejmuje
Griefing pozostaje możliwy: każdy może wysłać bezwartościowy commit i zablokować adres na maksymalnie pięć bloków, choć nie może przenieść jego środków. Złos SEQWENCER to kolejne ryzyko resztkowe: jeśli uczciwy commit wygaśnie lub zostanie wyciągnięty reorganizacją, gdy jego reveal jest oczekujący, sekret przestaje być zablokowany. Obecnie tylko własny sekwencer BB84 widzi oczekujące transakcje.
Hadamard sugeruje ostrzejszą regułę „Guy Fawkes”, w której commity są dopisywane, a nie zastępowane, ale mówi, że nie została ona zbudowana. Dokumentacja idzie dalej niż post, twierdząc, że commit i reveal oznaczają, że sekwencer nie może ukraść wypłaty.
Portfel, który nie może stracić rachuby
Ponieważ każdy łańcuch ma stałą liczbę krok, portfel musi odnowić go na ostatnim kroku, dołączając nowe zobowiązanie w tej końcowej płatności. Jeśli przegapi ten krok, adres jest martwy. Równie ważne jest pilnowanie rachuby: Hadamard mówi, że aplikacja i łańcuch rozsynchronizowały się w produkcji, więc portfele muszą umieć się resynchronizować z danych łańcucha.
Sekrety nadal wymagają ochrony jak klucze. CLI ostrzega, że jego plik portfela przechowuje klucze wydawania w postaci niezaszyfrowanej i wymienia szyfrowanie jako punkt roadmapy. Usunięcie podpisów zmienia sposób autoryzacji wydawania środków, a nie konieczność dbania o bezpieczeństwo sekretów.
Wypłaty opierają się na zaufanym operatorze
BB84 nie ma dowodów błędów (fault proofs). Uprawniony propozera publikuje stan sieci w Ethereum za pośrednictwem niestandardowej gry spornej rozstrzyganej natychmiast, a przy braku systemu dowodów Hadamard pisze, że według ram L2BEAT łańcuch „nie byłby nawet Stage 0”. Ramy te klasyfikują rollupy od Stage 0 do Stage 2 według tego, jak bardzo użytkownicy muszą ufać operatorowi zamiast systemowi dowodów. Wypłaty opierają się zatem na zaufaniu do proponera. Dokumentacja nadal opisuje wypłaty jako zgodne z przepływem fault-proof OP Stack z siedmiodniowym okresem dojrzewania, ale jak wyjaśnia objaśnienie Optimism, dowody błędów istnieją po to, by można było kwestionować błędny stan — a tutaj nic nie może być kwestionowane w trakcie tego oczekiwania. Sekwencer również jest prowadzony przez BB84.
Co zmieniłoby obraz
Post kończy się pytaniami wykraczającymi poza jeden łańcuch. Najważniejsze z nich: czy konta oparte na łańcuchach haszowanych mogłyby stać się trybem walidacji w stylu EIP-7702 lub natywnym trybem abstrakcji kont na ogólnego przeznaczenia sieciach warstwy drugiej, co uczyniłoby ideę dostępną bez przenoszenia się na dedykowany łańcuch. EIP-7702, aktywny od czasu aktualizacji Ethereum Pectra w maju 2025 roku, pozwala zwykłym kontom przyjmować kod inteligentnych kontraktów. Hadamard dodaje, że dodatkowe sprawdzenia są na tyle proste, że można je udowodnić istniejącym narzędziem Cannon od Optimism, że reguła commitów typu append-only zamknęłaby zarówno lukę griefingową, jak i sekwencerową, oraz że dłuższe opracowanie z pełnymi regułami jest przygotowywane dla arXiv. Szerszy wysiłek migracyjny Ethereum, opisany w jego roadmapie kwantowej, obejmuje także podpisy walidatorów, zobowiązania danych i systemy dowodów.
Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady finansowej ani inwestycyjnej. Sieci eksperymentalne wiążą się z ryzykiem technicznym i związanym z przechowywaniem aktywów.
Źródło: Coindoo