Podpisy Bitcoin odporne na kwanty zablokują węzły sieci z danymi 10 razy większymi

Dążenie Coinbase do przygotowania Bitcoina na obliczenia kwantowe dotyczy tego, co się dzieje, gdy portfel wraca z starego backupu lub gdy serwer podpisujący zawodzi.

Brian Armstrong wezwał 20 października do przygotowania i współpracy w całej branży. Szczegóły operacyjne pochodzą z artykułu Shashanka Agrawala z 13 października na Coinbase, który prosi o przyszłe schematy podpisów, aby współpracowały z zwykłymi portfelami, procedurami odzyskiwania i niezależnie działającymi serwerami powierniczymi.

SHRINCS, szkic opartego na haszach schematu podpisu dla Bitcoina, łączy mniejsze podpisy, które wymagają niezawodnego zapisu poprzednich podpisów, z większym planem awaryjnym, który działa bez tego zapisu. Zgodnie z obecnymi zasadami, odzyskiwanie w niepewnym stanie oznacza podjęcie większej ścieżki.

To zachowuje drogę do podpisywania dla kogoś, kto może odzyskać sekret. Umowa polega na tym, że utrzymanie mniejszych podpisów wymaga dodatkowej dyscypliny operacyjnej.

Test odzyskiwania dotyczy portfeli i giełd

Obecna specyfikacja SHRINCS wymienia 48-bajtowy klucz publiczny, podpisy stanowe między 548 a 4 619 bajtów oraz bezstanowy podpis o wielkości 5 777 bajtów.

"Stan" to zmieniający się zapis, które jednorazowe sloty podpisowe klucz już wykorzystał. Kompaktowy komponent SHRINCS (XMSS) zależy od nieużywania tych slotów ponownie. Ponowne użycie jednego dla różnych wiadomości może pozwolić obserwatorowi na fałszowanie podpisów.

Backup może odzyskać długoterminowy sekret bez odzyskiwania wiarygodnego zapisu każdego podpisu utworzonego od czasu backupu. Agrawal wyjaśnił również, że podpisy i aktualizacje stanu niekoniecznie prowadzą do transakcji on-chain.

Gdy poprawny stan jest niedostępny, w tym po przywróceniu z statycznego backupu, implementacja musi odmówić podpisywania stanowego i używać tylko ścieżki bezstanowej. Ta alternatywa pochodzi z SLH-DSA, standardu podpisu opartego na haszach, ale używa zestawu parametrów poza zestawami ustandaryzowanymi w FIPS 205.

Zasady podpisującego zabraniają tworzenia kopii zapasowych i przywracania zmiennego licznika lub eksportowania i importowania go do innego oprogramowania. Jednak stary licznik nie może być po prostu traktowany jako bezpieczny punkt wyjścia dla kompaktowych podpisów.

Podpisy SHRINCS mają od 548 do 4 619 bajtów z wiarygodnym stanem licznika, podczas gdy 5 777-bajtowy tryb bezstanowy zachowuje bezpieczeństwo, gdy ten stan nie może być zaufany.

Pytania dotyczące własności związane z uśpionymi monetami stanowią osobny problem polityczny.

Dla giełdy ten sam wymóg wykracza poza ekran odzyskiwania. Agrawal opisał duże giełdy działające niezależnie w różnych strefach, aby zapewnić niską latencję i wysoką dostępność.

W jego ocenie, podpisywanie stanowe wymagałoby wyłącznego dostępu do klucza i jego stanu podczas generowania podpisu, co komplikuje tę niezależną operację.

Jeśli serwer tworzy podpis, ale wynik jego aktualizacji licznika jest niejasny, serwer zastępczy potrzebuje wiarygodnej podstawy do wiedzenia, który stan pozostaje nieużyty. Skopiowanie starszego licznika na zastępczy nie ustanowiłoby tego.

Obecne zasady SHRINCS zabraniają równoczesnego podpisywania z stanem klucza i wymagają, aby inkrementacja licznika była rejestrowana trwale przed tym, jak podpis wróci do swojego wywołującego. Licznik nigdy nie może maleć, a jego przechowywanie musi być chronione przed nieautoryzowanymi zmianami. Specyfikacja podkreśla trwałe przechowywanie, które opiera się na odporności na wycofanie.

Ograniczenia dotyczące kluczy nie oznaczają, że giełda musi przestać przetwarzać każdy inny klucz, podczas gdy jeden podpisuje. Artykuł Agrawala zawierał SHRINCS wśród kandydatów wartych oceny i wzywał do dostępnego trybu operacyjnego tylko bezstanowego.

Coinbase twierdzi, że posiada około 12% istniejącego BTC w kontekście swojej działalności powierniczej.

Co zmienia plan awaryjny w modelu opłat Bitcoin

A 5,777-bajtowy podpis jest większy niż 548-bajtowy podpis, ale ten stosunek nie opisuje bezpośrednio opłaty za transakcję. Transakcje zawierają inne dane, a Bitcoin traktuje dane świadków inaczej niż inne bajty.

Zgodnie z definicjami wagi transakcji BIP 141, waga równa się trzykrotności rozmiaru transakcji po usunięciu danych plus całkowity rozmiar. Wirtualny rozmiar to waga podzielona przez cztery, zaokrąglona w górę.

Bajt ładunku podpisu umieszczony w świadku przyczynia się do jednej jednostki wagi w tym rozrachunku, podczas gdy prefiksy i inne dane serializacji nadal liczą się osobno.

Rozważmy celowo hipotetyczny model z jednym podpisem. Utrzymaj wszystko poza tym podpisem na 400 jednostkach wagi, zakładając niezmienioną księgowość świadków i ustalając stawkę opłaty na 10 satoshi za wirtualny bajt.

Stanowe wiersze używają minimalnych i maksymalnych rozmiarów podpisów z projektu. Obliczenie to całkowita waga = 400 + bajty podpisu, a następnie wirtualny rozmiar = całkowita waga podzielona przez cztery, zaokrąglona w górę:

W tym modelu, fallback dodaje 13,080 sats w porównaniu do najmniejszego przypadku stanowego, lub 2,900 sats w porównaniu do największego.

W przypadku samodzielnego przechowywania, transakcja odzyskiwania będzie miała większy podpis, gdy brak jest poprawnego stanu, więc jej twórca będzie musiał uwzględnić tę wagę przy ustalaniu opłaty sieciowej. Custodian stoi przed zadaniem zachowania wiarygodnego stanu oraz wagi transakcji jakiegokolwiek bezstanowego podpisu, którego używa.

Czy ponosi te koszty, czy przekazuje je klientom, to osobna decyzja cenowa, którą te dokumenty nie ustalają.

Podział oferuje ścieżkę do oceny

Stanowe podpisy mają również łagodzenia poza jednym wspólnym licznikiem. Wrześniowy informacyjny RFC 10033 kataloguje podejścia, w tym sektorowanie, zarezerwowane interwały i kontrolowany transfer kluczy i materiałów stanu.

Sektorowanie dzieli przestrzeń podpisu na nieprzechodzące części, którymi mogą zarządzać oddzielne urządzenia. Umożliwia to równoległe podpisywanie bez konieczności koordynowania każdego podpisu przez każde inne urządzenie.

Dla przechowywania Bitcoin, to czyni projekt podzielony istotną ścieżką inżynieryjną do oceny. Wartość RFC polega na identyfikacji konkretnych sposobów zarządzania stanem i operacyjnymi ryzykami, które każdy z nich wprowadza.

SHRINCS pozostaje projektem, a jego dowód bezpieczeństwa i w pełni zoptymalizowana implementacja są nadal wymieniane jako niedokończone. Wezwanie Armstronga do przygotowania dostarcza nowej uwagi, podczas gdy artykuł Agrawala dostarcza wymagań, według których można oceniać kandydatów.

Następnym użytecznym dowodem byłby projekt wdrożenia i implementacje pokazujące, jak kompaktowa ścieżka zachowuje się podczas przerwanych zapisów, wymiany serwera i przywracania portfela.

Istniejący fallback już czyni wybór wyraźnym: gdy wiarygodny stan jest niedostępny, zachowaj zdolność podpisywania, używając większego podpisu. Zachowanie oszczędności mniejszej ścieżki wymaga udowodnienia, że zwykłe awarie nie doprowadzą do ponownego użycia stanu.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.