Vitalik o możliwej przyszłości Ethereum (część szósta): The Splurge

W projektowaniu protokołu Ethereum około połowa treści dotyczy różnych typów ulepszeń EVM, a pozostała część obejmuje różne niszowe tematy – to właśnie oznacza „Splurge” (rozkwit).

Oryginalny tytuł: „Possible futures of the Ethereum protocol, part 6: The Splurge”

Autor: Vitalik Buterin

Tłumaczenie: zhouzhou, BlockBeats

Poniżej znajduje się oryginalna treść (dla lepszej czytelności została częściowo zredagowana):

Niektóre rzeczy trudno zaklasyfikować do jednej kategorii, a w projektowaniu protokołu Ethereum istnieje wiele „detali”, które są bardzo istotne dla sukcesu Ethereum. W rzeczywistości około połowa treści dotyczy różnych typów ulepszeń EVM, a pozostała część obejmuje różne niszowe tematy – to właśnie oznacza „Splurge” (rozkwit).

Mapa drogowa 2023: Splurge

Splurge: kluczowe cele

• Przekształcenie EVM w wydajny i stabilny „stan końcowy”
• Wprowadzenie abstrakcji kont do protokołu, umożliwiając wszystkim użytkownikom korzystanie z bezpieczniejszych i wygodniejszych kont
• Optymalizacja ekonomii opłat transakcyjnych, zwiększenie skalowalności przy jednoczesnym obniżeniu ryzyka
• Eksploracja zaawansowanej kryptografii, aby znacząco poprawić Ethereum w długim okresie

Ulepszenia EVM

Jaki problem rozwiązują?

Obecnie EVM trudno poddać analizie statycznej, co utrudnia tworzenie wydajnych implementacji, formalną weryfikację kodu oraz dalszą rozbudowę. Ponadto, efektywność EVM jest niska i trudno wdrożyć wiele zaawansowanych form kryptografii, chyba że zostaną one wyraźnie obsłużone przez prekompilacje.

Co to jest i jak działa?

Pierwszym krokiem w aktualnej mapie drogowej ulepszeń EVM jest EVM Object Format (EOF), który planuje się włączyć do następnego hard forka. EOF to seria EIP, które określają nową wersję kodu EVM z wieloma unikalnymi cechami, z których najbardziej widoczne to:

• Oddzielenie kodu (wykonywalnego, ale nieczytelnego z EVM) od danych (czytelnych, ale niewykonywalnych)
• Zakaz dynamicznych skoków, dozwolone są tylko skoki statyczne
• Kod EVM nie może już obserwować informacji związanych z gazem
• Dodano nowy, jawny mechanizm podprogramów

Struktura kodu EOF

Splurge: ulepszenia EVM (kontynuacja)

Stare kontrakty będą nadal istnieć i mogą być tworzone, choć ostatecznie mogą zostać stopniowo wycofane (a nawet przymusowo przekonwertowane na kod EOF). Nowe kontrakty skorzystają z wydajności EOF – najpierw poprzez nieco mniejszy bajtkod dzięki podprogramom, a następnie dzięki nowym funkcjom specyficznym dla EOF lub niższym kosztom gazu.

Po wprowadzeniu EOF dalsze aktualizacje stają się łatwiejsze, a obecnie najbardziej rozwiniętym pomysłem jest EVM Modular Arithmetic Extension (EVM-MAX). EVM-MAX tworzy zestaw nowych operacji specjalnie dla obliczeń modularnych i umieszcza je w nowej przestrzeni pamięci, do której nie można uzyskać dostępu przez inne opkody, co umożliwia optymalizacje, takie jak mnożenie Montgomery’ego.

Nowszym pomysłem jest połączenie EVM-MAX z funkcją SIMD (Single Instruction Multiple Data), która jako koncepcja istnieje w Ethereum od dawna, po raz pierwszy zaproponowana przez Grega Colvina w EIP-616. SIMD może przyspieszyć wiele form kryptografii, w tym funkcje skrótu, 32-bitowe STARKs i kryptografię opartą na kratkach, a połączenie EVM-MAX i SIMD sprawia, że te dwa wydajne rozszerzenia naturalnie się uzupełniają.

Ogólny projekt połączonego EIP zaczyna się od EIP-6690, a następnie:

• Pozwala na (i) dowolną liczbę nieparzystą lub (ii) dowolną potęgę dwójki do 2768 jako moduł
• Dla każdego opkodu EVM-MAX (dodawanie, odejmowanie, mnożenie) dodaje wersję, która zamiast 3 natychmiastowych liczb x, y, z używa 7: x_start, x_skip, y_start, y_skip, z_start, z_skip, count. W kodzie Python te opkody działają następująco:

for i in range(count):

mem[z_start + z_skip * count] = op(

mem[x_start + x_skip * count],

mem[y_start + y_skip * count]

)

W rzeczywistej implementacji będzie to przetwarzane równolegle.

• Możliwe jest dodanie XOR, AND, OR, NOT i SHIFT (w tym cyklicznych i niecyklicznych), przynajmniej dla potęg dwójki jako modułu. Dodano również ISZERO (który wypycha wynik na główny stos EVM), co wystarczy do realizacji kryptografii krzywych eliptycznych, kryptografii na małych polach (np. Poseidon, Circle STARKs), tradycyjnych funkcji skrótu (np. SHA256, KECCAK, BLAKE) i kryptografii opartej na kratkach. Inne ulepszenia EVM mogą być wdrożone, ale jak dotąd cieszą się mniejszym zainteresowaniem.

Linki do istniejących badań

• EOF: 
• EVM-MAX: 
• SIMD: 

Pozostała praca i kompromisy

Obecnie EOF planowany jest do włączenia w następnym hard forku. Zawsze istnieje możliwość jego usunięcia w ostatniej chwili – w poprzednich hard forkach funkcje były tymczasowo usuwane, ale takie działanie wiąże się z dużym wyzwaniem. Usunięcie EOF oznacza, że wszelkie przyszłe ulepszenia EVM musiałyby być wdrażane bez EOF, co jest możliwe, ale prawdopodobnie trudniejsze.

Główny kompromis EVM polega na złożoności L1 w stosunku do złożoności infrastruktury – EOF to dużo kodu do dodania do implementacji EVM, a statyczna kontrola kodu jest stosunkowo złożona. W zamian jednak można uprościć języki wyższego poziomu, uprościć implementację EVM i uzyskać inne korzyści. Można powiedzieć, że mapa drogowa, która priorytetowo traktuje ciągłe ulepszenia L1 Ethereum, powinna obejmować i opierać się na EOF.

Ważną pracą do wykonania jest wdrożenie funkcji podobnych do EVM-MAX + SIMD oraz przeprowadzenie benchmarków zużycia gazu dla różnych operacji kryptograficznych.

Jak to współdziała z innymi częściami mapy drogowej?

L1 dostosowując swój EVM sprawia, że L2 również łatwiej się dostosowuje; brak synchronizacji może prowadzić do niekompatybilności i negatywnych skutków. Ponadto EVM-MAX i SIMD mogą obniżyć koszty gazu dla wielu systemów dowodzenia, czyniąc L2 bardziej wydajnymi. Umożliwia to także zastąpienie większej liczby prekompilacji kodem EVM wykonującym te same zadania, bez dużego wpływu na wydajność.

Abstrakcja kont

Jaki problem rozwiązują?

Obecnie transakcje mogą być weryfikowane tylko w jeden sposób: podpisem ECDSA. Początkowo abstrakcja kont miała wyjść poza to, pozwalając na dowolną logikę weryfikacji konta jako kod EVM. Umożliwia to szereg zastosowań:

• Przejście na kryptografię odporną na kwanty
• Rotacja starych kluczy (powszechnie uznawana za zalecaną praktykę bezpieczeństwa)
• Portfele multisig i portfele z odzyskiwaniem społecznym
• Używanie jednego klucza do operacji o niskiej wartości, a innego (lub zestawu kluczy) do operacji o wysokiej wartości

Pozwala to protokołom prywatności działać bez relayerów, znacznie upraszczając ich złożoność i eliminując kluczowy scentralizowany punkt zależności

Od 2015 roku, kiedy zaproponowano abstrakcję kont, jej cele rozszerzyły się o wiele „celów wygody”, np. umożliwienie kontu bez ETH, ale z ERC20, płacenia za gaz w ERC20. Poniżej znajduje się podsumowujący wykres tych celów:

MPC (obliczenia wielostronne) to technika mająca już 40 lat, pozwalająca podzielić klucz na kilka części i przechowywać je na różnych urządzeniach, generując podpisy kryptograficznie bez bezpośredniego łączenia tych części.

EIP-7702 to propozycja planowana do wprowadzenia w następnym hard forku, będąca wynikiem rosnącej świadomości potrzeby zapewnienia wygody abstrakcji kont wszystkim użytkownikom (w tym EOA), mająca na celu krótkoterminową poprawę doświadczenia użytkowników i uniknięcie podziału ekosystemu.

Prace rozpoczęły się od EIP-3074 i ostatecznie doprowadziły do EIP-7702. EIP-7702 udostępnia „funkcje wygody” abstrakcji kont wszystkim użytkownikom, w tym dzisiejszym EOA (kontom zarządzanym przez podpisy ECDSA).

Jak widać na wykresie, choć niektóre wyzwania (zwłaszcza te dotyczące „wygody”) można rozwiązać stopniowo, np. przez MPC lub EIP-7702, główne cele bezpieczeństwa pierwotnej propozycji abstrakcji kont można osiągnąć tylko poprzez powrót do pierwotnego problemu: umożliwienie kodowi smart kontraktu kontrolowania weryfikacji transakcji. Do tej pory nie zostało to wdrożone ze względu na wyzwania związane z bezpieczną implementacją.

Co to jest i jak działa?

Sednem abstrakcji kont jest prostota: umożliwienie smart kontraktom inicjowania transakcji, a nie tylko EOA. Cała złożoność polega na wdrożeniu tego w sposób przyjazny dla zdecentralizowanej sieci i odporny na ataki typu denial-of-service.

Typowym kluczowym wyzwaniem jest problem wielokrotnej nieważności:

Jeśli 1000 kont ma funkcje weryfikacji zależne od jednej wartości S, a obecna wartość S sprawia, że transakcje w mempoolu są ważne, to pojedyncza transakcja zmieniająca S może unieważnić wszystkie pozostałe transakcje w mempoolu. Umożliwia to atakującemu wysyłanie śmieciowych transakcji do mempoolu przy minimalnym koszcie, blokując zasoby węzłów sieci.

Po latach pracy, mającej na celu rozszerzenie funkcjonalności przy jednoczesnym ograniczeniu ryzyka DoS, ostatecznie powstało rozwiązanie „idealnej abstrakcji kont”: ERC-4337.

ERC-4337 działa, dzieląc przetwarzanie operacji użytkownika na dwa etapy: weryfikację i wykonanie. Najpierw przetwarzane są wszystkie weryfikacje, a następnie wszystkie wykonania. W mempoolu operacje użytkownika są akceptowane tylko wtedy, gdy etap weryfikacji dotyczy wyłącznie ich własnego konta i nie odczytuje zmiennych środowiskowych. Zapobiega to atakom wielokrotnej nieważności. Ponadto na etap weryfikacji nakładane są ścisłe limity gazu.

ERC-4337 został zaprojektowany jako dodatkowy standard protokołu (ERC), ponieważ w tamtym czasie deweloperzy klientów Ethereum skupiali się na Merge i nie mieli zasobów na inne funkcje. Dlatego ERC-4337 używa obiektów zwanych operacjami użytkownika, a nie zwykłych transakcji. Ostatnio jednak zdano sobie sprawę, że przynajmniej część tych funkcji powinna być zapisana w protokole.

Dwa kluczowe powody to:

1. Wrodzona nieefektywność EntryPoint jako kontraktu: każda paczka ma stały narzut ok. 100 000 gazu oraz dodatkowe tysiące gazu na każdą operację użytkownika.
2. Konieczność zapewnienia właściwości Ethereum: np. gwarancje włączenia stworzone przez inclusion list muszą być przeniesione na użytkowników abstrakcji kont.

Ponadto ERC-4337 rozszerza dwa funkcje:

• Paymasters: umożliwiają jednemu kontu płacenie opłat za inne, co narusza zasadę, że etap weryfikacji może dotyczyć tylko konta nadawcy, dlatego wprowadzono specjalne mechanizmy zapewniające bezpieczeństwo paymasterów.
• Aggregators: obsługa agregacji podpisów, np. BLS lub opartej na SNARK. Jest to niezbędne do osiągnięcia maksymalnej efektywności danych na Rollupach.

Linki do istniejących badań

• Wykład o historii abstrakcji kont:
• ERC-4337:
• EIP-7702:
• Kod BLSWallet (z funkcją agregacji):
• EIP-7562 (abstrakcja kont zapisana w protokole):
• EIP-7701 (abstrakcja kont zapisana w protokole oparta na EOF):

Pozostała praca i kompromisy

Obecnie głównym wyzwaniem jest pełne wprowadzenie abstrakcji kont do protokołu. Ostatnio popularny EIP dotyczący abstrakcji kont zapisanej w protokole to EIP-7701, który wdraża abstrakcję kont na EOF. Konto może mieć osobną część kodu do weryfikacji; jeśli konto ją ustawi, kod ten zostanie wykonany w kroku weryfikacji transakcji z tego konta.

Ta metoda jest atrakcyjna, ponieważ jasno pokazuje dwie równoważne perspektywy natywnej abstrakcji kont:

1. Włączenie EIP-4337 jako części protokołu
2. Nowy typ EOA, w którym algorytm podpisu to wykonanie kodu EVM

Jeśli zaczniemy od ścisłego ograniczenia złożoności kodu wykonywanego podczas weryfikacji – brak dostępu do stanu zewnętrznego, a nawet początkowo limity gazu zbyt niskie dla zastosowań odpornych na kwanty lub prywatność – bezpieczeństwo tej metody jest bardzo jasne: po prostu zastępuje się weryfikację ECDSA wykonaniem kodu EVM o podobnym czasie trwania.

Jednak z czasem trzeba będzie poluzować te ograniczenia, ponieważ umożliwienie aplikacjom prywatności działania bez relayerów i odporność na kwanty są bardzo ważne. W tym celu należy znaleźć bardziej elastyczne sposoby radzenia sobie z ryzykiem DoS, bez konieczności ekstremalnego upraszczania kroku weryfikacji.

Główny kompromis wydaje się polegać na „szybkim wdrożeniu mniej satysfakcjonującego rozwiązania” kontra „dłuższym oczekiwaniu na potencjalnie bardziej idealne rozwiązanie”. Idealnym podejściem może być metoda hybrydowa: szybkie wdrożenie niektórych przypadków użycia i pozostawienie czasu na eksplorację innych. Inną opcją jest wdrożenie bardziej ambitnej wersji abstrakcji kont najpierw na L2. Jednak to wymaga, by zespoły L2 były przekonane do propozycji i miały pewność, że L1 i/lub inne L2 będą mogły w przyszłości przyjąć kompatybilne rozwiązanie.

Kolejnym zastosowaniem, które należy wyraźnie rozważyć, są konta do przechowywania kluczy, które przechowują stan konta na L1 lub dedykowanym L2, ale mogą być używane zarówno na L1, jak i na dowolnym kompatybilnym L2. Efektywne wdrożenie tego może wymagać, by L2 obsługiwały opkody takie jak L1SLOAD lub REMOTESTATICCALL, a to wymaga, by implementacja abstrakcji kont na L2 obsługiwała te operacje.

Jak to współdziała z innymi częściami mapy drogowej?

Inclusion list muszą obsługiwać transakcje z abstrakcją kont. W praktyce wymagania inclusion list są bardzo podobne do wymagań zdecentralizowanego mempoolu, choć inclusion list są nieco bardziej elastyczne. Ponadto implementacja abstrakcji kont powinna być jak najbardziej skoordynowana między L1 i L2. Jeśli w przyszłości większość użytkowników będzie korzystać z Rollupów do przechowywania kluczy, projekt abstrakcji kont powinien to uwzględniać.

Ulepszenia EIP-1559

Jaki problem rozwiązują?

EIP-1559 został aktywowany na Ethereum w 2021 roku, znacząco poprawiając średni czas włączenia do bloku.

Czas oczekiwania

Jednak obecna implementacja EIP-1559 nie jest doskonała w kilku aspektach:

1. Wzór jest nieco wadliwy: nie dąży do 50% pełnych bloków, lecz do ok. 50-53%, w zależności od wariancji (związane z nierównością średniej arytmetycznej i geometrycznej).
2. W skrajnych przypadkach dostosowuje się zbyt wolno.

Wzór używany później dla blobs (EIP-4844) został zaprojektowany specjalnie, by rozwiązać pierwszy problem i jest ogólnie prostszy. Jednak ani EIP-1559, ani EIP-4844 nie próbują rozwiązać drugiego problemu. Obecnie mamy więc nieco chaotyczny stan pośredni z dwoma różnymi mechanizmami i poglądem, że oba wymagają z czasem ulepszeń.

Istnieją także inne słabości wyceny zasobów Ethereum niezwiązane z EIP-1559, które można rozwiązać poprzez jego modyfikację. Jednym z głównych problemów jest różnica między przypadkiem średnim a najgorszym: ceny zasobów w Ethereum muszą być ustawione tak, by poradzić sobie z najgorszym przypadkiem (cały blok zużywa jeden zasób), ale rzeczywiste średnie użycie jest znacznie niższe, co prowadzi do nieefektywności.

Czym jest multidymensjonalny Gas i jak działa?

Rozwiązaniem tych nieefektywności jest multidymensjonalny Gas: ustalanie osobnych cen i limitów dla różnych zasobów. Koncepcja ta jest technicznie niezależna od EIP-1559, ale jego istnienie ułatwia jej wdrożenie. Bez EIP-1559 optymalne pakowanie bloku z wieloma ograniczeniami zasobów to złożony problem plecakowy. Z EIP-1559 większość bloków nie osiąga limitu żadnego zasobu, więc prosty algorytm „akceptuj każdą transakcję płacącą wystarczająco dużo” wystarcza.

Obecnie mamy już multidymensjonalny Gas dla wykonania i blobów; w zasadzie można to rozszerzyć na więcej wymiarów: calldata (dane transakcji), odczyty/zapisy stanu i rozrost stanu.

EIP-7706 wprowadza nowy wymiar gazu specjalnie dla calldata. Jednocześnie upraszcza mechanizm multidymensjonalnego Gas, łącząc trzy typy gazu w jeden (w stylu EIP-4844), co rozwiązuje matematyczne wady EIP-1559. EIP-7623 to bardziej precyzyjne rozwiązanie, które ogranicza maksymalne calldata bez wprowadzania nowego wymiaru.

Kolejnym kierunkiem badań jest rozwiązanie problemu szybkości aktualizacji – znalezienie szybszego algorytmu obliczania opłaty bazowej, zachowując kluczowe niezmienniki mechanizmu EIP-4844 (czyli: średnie użycie w długim okresie równe wartości docelowej).

Linki do istniejących badań

• EIP-1559 FAQ: 
• Empiryczna analiza EIP-1559: 
• Propozycje szybkiej regulacji: 
• Część o mechanizmie opłaty bazowej w EIP-4844 FAQ: 
• EIP-7706: 
• EIP-7623: 
• Multidymensjonalny Gas: 

Jakie prace i kompromisy pozostały?

Główne kompromisy multidymensjonalnego Gas są dwa:

1. Zwiększenie złożoności protokołu: wprowadzenie multidymensjonalnego Gas czyni protokół bardziej złożonym.
2. Zwiększenie złożoności algorytmu optymalnego wypełniania bloku: aby optymalnie wypełnić blok, algorytm staje się bardziej złożony.

Złożoność protokołu dla calldata jest stosunkowo niewielka, ale dla wymiarów gazu wewnątrz EVM (np. odczyty/zapisy pamięci) rośnie. Problem polega na tym, że nie tylko użytkownicy ustawiają limity gazu – kontrakty również ustawiają limity przy wywołaniach innych kontraktów. Obecnie mogą to robić tylko w jednym wymiarze.

Prostym rozwiązaniem jest udostępnienie multidymensjonalnego Gas tylko wewnątrz EOF, ponieważ EOF nie pozwala kontraktom ustawiać limitów gazu przy wywołaniach innych kontraktów. Kontrakty nie-EOF muszą płacić za wszystkie typy gazu przy operacjach na stanie (np. jeśli SLOAD zużywa 0,03% limitu gazu na odczyty stanu, użytkownik nie-EOF również zapłaci 0,03% limitu gazu na wykonanie).

Dalsze badania nad multidymensjonalnym Gas pomogą zrozumieć te kompromisy i znaleźć optymalny balans.

Jak to współdziała z innymi częściami mapy drogowej?

Udane wdrożenie multidymensjonalnego Gas może znacznie ograniczyć użycie zasobów w najgorszym przypadku, zmniejszając presję na optymalizację wydajności, np. dla drzew binarnych opartych na STARKed hash. Ustalenie jasnego celu dla wzrostu rozmiaru stanu ułatwi deweloperom klientów planowanie i szacowanie wymagań w przyszłości.

Jak wspomniano, istnienie EOF upraszcza wdrożenie bardziej ekstremalnych wersji multidymensjonalnego Gas, dzięki jego nieobserwowalności gazu.

Funkcje opóźnienia weryfikowalnego (VDF)

Jaki problem rozwiązują?

Obecnie Ethereum używa losowości opartej na RANDAO do wyboru propozycji, gdzie losowość uzyskuje się przez zobowiązanie się każdego proponującego do ujawnienia swojego sekretu, a każdy ujawniony sekret jest mieszany do losowości.

Każdy proponujący ma więc „1 bit kontroli”: może zmienić losowość, nie pojawiając się (co kosztuje). To jest rozsądne przy wyborze proponującego, bo rzadko zdarza się, by rezygnacja z jednej szansy dawała dwie nowe. Ale dla aplikacji on-chain wymagających losowości nie jest to idealne. W idealnym przypadku powinniśmy znaleźć bardziej niezawodne źródło losowości.

Czym jest VDF i jak działa?

Funkcja opóźnienia weryfikowalnego to funkcja, którą można obliczyć tylko sekwencyjnie, bez możliwości przyspieszenia przez równoległość. Prosty przykład to powtarzane haszowanie: for i in range(10**9): x = hash(x). Wynik można udowodnić za pomocą SNARK jako poprawny i użyć jako losowej wartości.

Chodzi o to, by wejście było wybierane na podstawie informacji dostępnych w czasie T, a wyjście nie było znane w czasie T – pojawia się dopiero po pełnym wykonaniu obliczenia. Ponieważ każdy może wykonać obliczenie, nie ma możliwości ukrycia wyniku, a więc i manipulacji.

Główne ryzyko VDF to nieoczekiwane optymalizacje: ktoś znajduje sposób na szybsze wykonanie funkcji niż przewidywano, manipulując informacjami ujawnianymi w czasie T.

Nieoczekiwane optymalizacje mogą wystąpić na dwa sposoby:

1. Przyspieszenie sprzętowe: ktoś tworzy ASIC szybszy niż istniejący sprzęt do danego obliczenia.
2. Nieoczekiwana równoległość: ktoś znajduje sposób na równoległe wykonanie funkcji szybciej, nawet jeśli wymaga to 100 razy więcej zasobów.

Stworzenie udanego VDF polega na uniknięciu obu tych problemów, przy zachowaniu praktycznej wydajności (np. dowodzenie SNARK na żywo dla haszowania wymaga ciężkiego sprzętu). Przyspieszenie sprzętowe zwykle rozwiązuje się przez stworzenie i dystrybucję przez podmiot publiczny niemal optymalnego ASIC VDF.

Linki do istniejących badań

• Strona badań VDF: 
• Przemyślenia o atakach na VDF w Ethereum, 2018: 
• Atak na proponowany VDF MinRoot: 

Pozostała praca i kompromisy

Obecnie nie istnieje konstrukcja VDF, która w pełni spełnia wymagania badaczy Ethereum we wszystkich aspektach. Potrzeba więcej pracy, by znaleźć taką funkcję. Jeśli się uda, główny kompromis to czy ją wdrożyć: prosty kompromis między funkcjonalnością a złożonością protokołu i ryzykiem bezpieczeństwa.

Jeśli uznamy VDF za bezpieczny, a okaże się, że nie jest, w zależności od implementacji bezpieczeństwo spadnie do założenia RANDAO (1 bit kontroli na atakującego) lub nieco gorszego. Nawet jeśli VDF zawiedzie, nie zniszczy to protokołu, ale zaszkodzi aplikacjom lub nowym funkcjom protokołu, które na nim polegają.

Jak to współdziała z innymi częściami mapy drogowej?

VDF to względnie samodzielny element protokołu Ethereum, poza zwiększeniem bezpieczeństwa wyboru proponującego ma zastosowanie w (i) aplikacjach on-chain zależnych od losowości oraz (ii) szyfrowanych mempoolach, choć te ostatnie wymagają dodatkowych odkryć kryptograficznych.

Warto pamiętać, że ze względu na niepewność sprzętową, między wygenerowaniem a potrzebą użycia wyjścia VDF będzie pewien „bufor”. Oznacza to, że informacja będzie dostępna kilka bloków wcześniej. Może to być akceptowalny koszt, ale należy to uwzględnić w projektach z pojedynczym slotem finalizacji lub wyboru komitetu.

Obfuskacja i podpisy jednorazowe: odległa przyszłość kryptografii

Jaki problem rozwiązują?

Jednym z najsłynniejszych artykułów Nicka Szabo jest ten z 1997 roku o „protokole Boga”. Wskazuje w nim, że wiele aplikacji wielostronnych polega na „zaufanej trzeciej stronie” do zarządzania interakcjami. Według niego kryptografia ma stworzyć symulowaną zaufaną trzecią stronę, która wykona tę samą pracę bez konieczności zaufania konkretnemu uczestnikowi.

Do tej pory udało się to osiągnąć tylko częściowo. Jeśli potrzebujemy jedynie przejrzystej wirtualnej maszyny, której danych i obliczeń nie można wyłączyć, cenzurować ani sfałszować, a prywatność nie jest celem, blockchain to umożliwia, choć ze słabą skalowalnością.

Jeśli celem jest prywatność, do niedawna mogliśmy tworzyć tylko konkretne protokoły dla konkretnych zastosowań: podpisy cyfrowe do podstawowej autoryzacji, ring signatures i linkable ring signatures do anonimowości, kryptografia oparta na tożsamości dla wygodniejszego szyfrowania przy określonych założeniach, ślepe podpisy do Chaumian e-cash itd. Każda nowa aplikacja wymagała dużo pracy.

W latach 2010. po raz pierwszy pojawiła się inna, potężniejsza metoda – kryptografia programowalna. Zamiast tworzyć nowy protokół dla każdej aplikacji, można użyć potężnych nowych protokołów – konkretnie ZK-SNARKs – by dodać gwarancje kryptograficzne do dowolnego programu.

ZK-SNARKs pozwalają użytkownikom udowodnić dowolne twierdzenie o posiadanych danych, a dowód (i) jest łatwy do weryfikacji, (ii) nie ujawnia nic poza samym twierdzeniem. To ogromny postęp dla prywatności i skalowalności – porównuję to do wpływu transformatorów w AI. Tysiące lat pracy nad aplikacjami specyficznymi nagle zastępuje uniwersalne rozwiązanie, które radzi sobie z nieoczekiwanie szerokim zakresem problemów.

Jednak ZK-SNARKs to tylko pierwsza z trzech niezwykle potężnych uniwersalnych prymitywów. Są one tak potężne, że przypominają mi zestaw bardzo silnych kart z Yu-Gi-Oh! – gry i serialu, w które grałem jako dziecko: karty egipskich bogów.

Karty egipskich bogów to trzy niezwykle potężne karty, których stworzenie według legendy mogło być śmiertelne, a ich siła sprawiła, że zostały zakazane w pojedynkach. Podobnie w kryptografii mamy trzy takie protokoły bogów:

Czym są ZK-SNARKs i jak działają?

ZK-SNARKs to jeden z tych trzech protokołów, już dość dojrzały. W ciągu ostatnich pięciu lat znacznie wzrosła szybkość generowania dowodów i przyjazność dla deweloperów, czyniąc ZK-SNARKs podstawą strategii skalowalności i prywatności Ethereum. Ale ZK-SNARKs mają ważne ograniczenie: trzeba znać dane, by je udowodnić. Każdy stan w aplikacji ZK-SNARK musi mieć unikalnego „właściciela”, który musi być obecny, by zatwierdzić odczyt lub zapis stanu.

Drugim protokołem, który nie ma tego ograniczenia, jest w pełni homomorficzne szyfrowanie (FHE), które pozwala wykonywać dowolne obliczenia na zaszyfrowanych danych bez ich odszyfrowywania. Umożliwia to wykonywanie obliczeń na danych użytkownika z zachowaniem prywatności danych i algorytmu.

Pozwala to również rozszerzyć systemy głosowania takie jak MACI, zapewniając niemal doskonałe bezpieczeństwo i prywatność. Przez długi czas FHE uważano za zbyt nieefektywne do praktycznego użycia, ale obecnie stało się wystarczająco wydajne, by pojawiły się pierwsze zastosowania.

Cursive to aplikacja wykorzystująca obliczenia dwustronne i FHE do prywatnego odkrywania wspólnych zainteresowań.

Jednak FHE ma swoje ograniczenia: każda technologia oparta na FHE nadal wymaga, by ktoś posiadał klucz deszyfrujący. Może to być rozproszony układ M-of-N, można też użyć TEEs jako drugiej warstwy ochrony, ale to nadal ograniczenie.

Trzeci protokół jest jeszcze potężniejszy niż dwa poprzednie razem: indistinguishability obfuscation (obfuskacja nierozróżnialna). Choć technologia ta jest jeszcze daleka od dojrzałości, od 2020 roku mamy teoretycznie skuteczne protokoły oparte na standardowych założeniach bezpieczeństwa, a ostatnio rozpoczęto pierwsze implementacje.

Obfuskacja nierozróżnialna pozwala stworzyć „zaszyfrowany program”, który wykonuje dowolne obliczenia, ukrywając wszystkie szczegóły wewnętrzne programu. Prosty przykład: można umieścić klucz prywatny w obfuskowanym programie, który pozwala tylko podpisywać liczby pierwsze i rozprowadzić ten program. Inni mogą podpisywać dowolne liczby pierwsze, ale nie wyciągną klucza. Możliwości są jednak znacznie większe: w połączeniu z haszowaniem można zrealizować dowolny inny prymityw kryptograficzny i wiele więcej.

Jedyną rzeczą, której obfuskowany program nie może zrobić, jest zapobieganie kopiowaniu samego siebie. Jednak w tej kwestii na horyzoncie czekają jeszcze potężniejsze technologie, choć wymagają, by każdy miał komputer kwantowy: quantum one-shot signatures (kwantowe podpisy jednorazowe).

Łącząc obfuskację i podpisy jednorazowe, możemy zbudować niemal doskonałą zaufaną trzecią stronę. Jedynym celem, którego nie da się osiągnąć samą kryptografią, jest odporność na cenzurę – tu nadal potrzebny jest blockchain. Te technologie mogą nie tylko uczynić Ethereum bezpieczniejszym, ale także umożliwić budowę potężniejszych aplikacji na jego bazie.

Aby lepiej zrozumieć, jak te prymitywy zwiększają możliwości, weźmy głosowanie jako przykład. Głosowanie to ciekawe zagadnienie, bo wymaga wielu złożonych właściwości bezpieczeństwa, w tym bardzo silnej weryfikowalności i prywatności. Choć protokoły głosowania o silnych właściwościach istnieją od dekad, możemy podnieść poprzeczkę i wymagać obsługi dowolnego protokołu głosowania: głosowania kwadratowego, par ograniczonych kwadratowych dotacji, klastrowanych kwadratowych dotacji itd. Innymi słowy, chcemy, by krok „liczenia głosów” był dowolnym programem.

Najpierw załóżmy, że wyniki głosowania są publicznie na blockchainie. Daje to publiczną weryfikowalność (każdy może sprawdzić poprawność wyniku, reguł liczenia i kwalifikacji) oraz odporność na cenzurę (nie można nikomu zabronić głosowania). Ale nie ma prywatności.

Następnie dodajemy ZK-SNARKs – teraz mamy prywatność: każdy głos jest anonimowy, a jednocześnie tylko uprawnieni wyborcy mogą głosować i każdy tylko raz.

Kolejny krok to mechanizm MACI: głosy są szyfrowane kluczem centralnego serwera, który liczy głosy, usuwa duplikaty i publikuje dowód ZK-SNARK wyniku. Zachowuje to poprzednie gwarancje (nawet jeśli serwer oszukuje!), a jeśli serwer jest uczciwy, dodaje odporność na przymus: użytkownik nie może udowodnić, jak głosował, nawet jeśli chce. Może udowodnić, że oddał głos, ale nie, że nie oddał głosu niwelującego tamten. To chroni przed przekupstwem i innymi atakami.

Liczenie głosów odbywa się w FHE, a następnie następuje obliczenie progowe N/2-of-N do odszyfrowania. Odporność na przymus rośnie do N/2-of-N zamiast 1-of-1.

Obfuskowany program liczący głosy jest zaprojektowany tak, by wynik można było uzyskać tylko po autoryzacji – np. dowodem konsensusu blockchaina, dowodem pracy lub ich połączeniem. Odporność na przymus staje się niemal doskonała: przy konsensusie blockchain potrzeba 51% walidatorów do złamania; przy dowodzie pracy nawet pełna zmowa wymagałaby ogromnych kosztów, by próbować wyodrębnić zachowanie pojedynczego wyborcy. Można nawet dodać niewielką losową korektę do wyniku, by jeszcze bardziej utrudnić ekstrakcję zachowań.

Dodajemy podpisy jednorazowe – prymityw oparty na kwantach, pozwalający na podpisanie tylko raz określonego typu informacji. To daje naprawdę doskonałą odporność na przymus.

Obfuskacja nierozróżnialna umożliwia też inne potężne zastosowania, np.:

1. DAO, aukcje on-chain i inne aplikacje z dowolnym tajnym stanem wewnętrznym.
2. Prawdziwie uniwersalne trusted setup: ktoś tworzy obfuskowany program z kluczem, uruchamia dowolny program i podaje wynik, wkładając hash(key, program) jako wejście. Każdy może włożyć program 3 do siebie, łącząc klucz programu i własny, rozszerzając setup. Można to wykorzystać do generowania trusted setup 1-of-N dla dowolnego protokołu.
3. Weryfikacja ZK-SNARKs za pomocą jednego podpisu: wystarczy trusted environment, w którym ktoś tworzy obfuskowany program, który podpisuje wiadomość kluczem tylko przy ważnym ZK-SNARK.
4. Szyfrowany mempool: szyfrowanie transakcji staje się bardzo proste, tak że można je odszyfrować dopiero po wystąpieniu określonego zdarzenia on-chain, np. wykonaniu VDF.

Dzięki podpisom jednorazowym można zabezpieczyć blockchain przed 51% atakami cofającymi finalność (choć ataki cenzurujące nadal są możliwe). Podobne prymitywy umożliwiają quantum money, rozwiązując problem double spend bez blockchaina, choć wiele bardziej złożonych zastosowań nadal wymaga łańcucha.

Jeśli te prymitywy staną się wystarczająco wydajne, większość aplikacji na świecie będzie mogła działać zdecentralizowanie. Główną barierą będzie weryfikacja poprawności implementacji.

Oto kilka linków do istniejących badań:

• Protokół obfuskacji nierozróżnialnej (2021): 
• Jak obfuskacja może pomóc Ethereum: 
• Pierwsza znana konstrukcja podpisu jednorazowego: 
• Próba implementacji obfuskacji (1): 
• Próba implementacji obfuskacji (2): 

Jakie prace i kompromisy pozostały?

Pozostaje wiele pracy – obfuskacja nierozróżnialna jest nadal bardzo niedojrzała, a kandydackie konstrukcje są ekstremalnie wolne (lub gorzej), przez co nie nadają się do praktycznego użycia. Teoretycznie działają w czasie wielomianowym, ale w praktyce czas działania może być dłuższy niż wiek wszechświata. Ostatnie protokoły nieco to poprawiły, ale narzut jest nadal zbyt wysoki – jeden z implementatorów szacuje czas działania na rok.

Komputery kwantowe jeszcze nie istnieją: wszystkie konstrukcje, które widzisz w internecie, to albo prototypy nieprzekraczające 4 bitów, albo w ogóle nie są rzeczywistymi komputerami kwantowymi, choć mogą mieć elementy kwantowe, ale nie wykonają sensownych obliczeń jak algorytm Shora czy Grovera. Ostatnio pojawiły się sygnały, że „prawdziwe” komputery kwantowe są już blisko. Jednak nawet jeśli pojawią się wkrótce, miną dekady, zanim zwykli ludzie będą mogli ich używać na laptopach czy telefonach, zanim potężne instytucje będą mogły łamać kryptografię krzywych eliptycznych.

W przypadku obfuskacji nierozróżnialnej kluczowym kompromisem są założenia bezpieczeństwa – istnieją bardziej agresywne projekty oparte na specjalnych założeniach, które zwykle są szybsze, ale czasem okazują się błędne. Z czasem możemy lepiej zrozumieć kratki i zaproponować trudniejsze do złamania założenia, ale to ryzykowna droga. Bardziej konserwatywne podejście to trzymać się protokołów, których bezpieczeństwo można zredukować do „standardowych” założeń, ale to może oznaczać dłuższe oczekiwanie na wystarczająco szybkie protokoły.

Jak to współdziała z innymi częściami mapy drogowej?

Ekstremalnie potężna kryptografia może całkowicie zmienić zasady gry, np.:

1. Jeśli weryfikacja ZK-SNARKs stanie się tak prosta jak podpis, agregacja może być zbędna – można weryfikować bezpośrednio on-chain.
2. Podpisy jednorazowe mogą oznaczać bezpieczniejsze protokoły proof-of-stake.
3. Wiele złożonych protokołów prywatności może zostać zastąpionych przez jedną prywatną maszynę wirtualną Ethereum (EVM).
4. Szyfrowany mempool stanie się łatwiejszy do wdrożenia.

Początkowo korzyści pojawią się na warstwie aplikacji, ponieważ L1 Ethereum musi pozostać konserwatywne pod względem założeń bezpieczeństwa. Jednak już samo użycie na warstwie aplikacji może być przełomowe, jak pojawienie się ZK-SNARKs.