Autor oryginalny |Vitalik

Kompilacja |. Odaily Planet Daily Nan Zhi

Jedną z ważnych cech dobrego doświadczenia użytkownika blockchain jest szybki czas potwierdzenia transakcji. Dziś Ethereum jest znacznie ulepszone w porównaniu z tym, co było pięć lat temu. Dzięki EIP-1559 i stabilnemu czasowi blokowania po przejściu na PoS (The Merge) transakcje wysyłane przez użytkowników na L1 można zwykle potwierdzić w ciągu 5-20 sekund, co mniej więcej odpowiada płaceniu kartą kredytową. Jednakże dalsze ulepszanie komfortu użytkownika ma sens, a niektóre aplikacje wymagają nawet opóźnień rzędu setek milisekund lub mniej. W tym artykule omówimy kilka praktycznych opcji poprawy czasu potwierdzania transakcji w Ethereum.

Przegląd istniejących pomysłów i technik

finał w jednym miejscu

Obecnie konsensus Gaspera w Ethereum wykorzystuje architekturę pojedynczego gniazda (Slot) i Epoch. Co 12 sekund podzbiór walidatorów głosuje na początek łańcucha i co 32 sekundy (6,4 minuty) wszyscy walidatorzy mają szansę oddać jeden głos. Głosy te są następnie reinterpretowane jako komunikaty w algorytmie konsensusu podobnym do PBFT, co daje bardzo silną gwarancję ekonomiczną zwaną ostatecznością po dwóch epokach (12,8 minuty).

W ciągu ostatnich kilku lat staliśmy się coraz bardziej niezadowoleni z naszego obecnego podejścia. Są ku temu dwa główne powody. Po pierwsze, metoda ta jest skomplikowana i występuje wiele błędów w interakcji pomiędzy mechanizmem głosowania typu slot-to-slot a mechanizmem finalizacji Epoch-to-Epoch. Po drugie, 12,8 minuty jest za długie i nikt tego nie chce czekać tak długo.

Single Slot Finality (SSF) zastępuje tę architekturę mechanizmem podobnym do konsensusu Tendermint, w którym blok N jest finalizowany przed wygenerowaniem bloku N+1. Główną różnicą w stosunku do Tendermint jest to, że zachowujemy mechanizm „wycieku braku aktywności”, który pozwala łańcuchowi na dalsze działanie i regenerację, jeśli więcej niż 1/3 walidatorów jest offline.

Głównym wyzwaniem związanym z finalizacją pojedynczego slotu jest to, że oznacza to, że każdy uczestnik Ethereum musi publikować dwie wiadomości co 12 sekund, co stanowi znaczne obciążenie łańcucha. Istnieje kilka sprytnych pomysłów na złagodzenie tego problemu, w tym niedawna propozycja Orbit SSF. Chociaż znacznie przyspiesza to „ostateczność” poprawy doświadczenia użytkownika, nie zmienia to faktu, że użytkownicy muszą poczekać 5-20 sekund.

Wstępne potwierdzenie rollupu

W ciągu ostatnich kilku lat Ethereum podążało za planem działania skupiającym się na rollupach, projektując warstwę bazową Ethereum (L1) w celu obsługi dostępności danych i innych funkcji, które są następnie udostępniane protokołom L2, takim jak rollupy, validium i Plasma Able to zapewnić użytkownikom taki sam poziom bezpieczeństwa jak Ethereum na większą skalę.

Stwarza to rozdzielenie obaw w ekosystemie Ethereum: Ethereum L1 koncentruje się na odporności na cenzurę, niezawodności, stabilności oraz utrzymaniu i ulepszaniu podstawowej funkcjonalności określonej warstwy podstawowej, podczas gdy L2 koncentruje się na bardziej bezpośredniej komunikacji za pośrednictwem różnych kultur i technologii użytkownikom. Ale jeśli pójdziesz tą ścieżką, pojawi się nieunikniony problem: L2 chce zapewnić użytkownikom potwierdzenia szybsze niż 5-20 sekund.

Jak dotąd, przynajmniej teoretycznie, zadaniem L2 było stworzenie własnej sieci „zdecentralizowanych sekwencerów”. Mała grupa walidatorów może podpisywać bloki co kilkaset milisekund i stawiać za nimi swoje stawki. Ostatecznie pliki nagłówkowe tych fragmentów L2 są publikowane w L1.

Jednak zestaw walidatorów L2 może popełnić „oszustwo”: może najpierw podpisać blok B1, a następnie podpisać sprzeczny blok B2 i przekazać go do łańcucha przed B1. Jeśli jednak tak się stanie, zostaną przyłapani i stracą zastawiony majątek. Rzeczywiście widzieliśmy praktyczne przykłady wersji scentralizowanych, ale z drugiej strony pakiety zbiorcze rozwijały zdecentralizowane sieci zamówień powoli. Można argumentować, że wymaganie decentralizacji wszystkich L2 jest niesprawiedliwe: prosimy, aby pakiet zbiorczy wykonał prawie tę samą pracę, co utworzenie zupełnie nowego L1. W związku z tym Justin Drake promuje sposób, w jaki wszystkie L2 (a także L1) mogą korzystać ze wspólnego mechanizmu wstępnego potwierdzenia obejmującego cały Ethereum: podstawowego potwierdzenia wstępnego.

Podstawowe wstępne potwierdzenie

Podejście oparte na wstępnych potwierdzeniach zakłada, że ​​proponujący Ethereum to wysoce wyrafinowani uczestnicy powiązani z MEV. Podejścia oparte na wstępnym potwierdzeniu wykorzystują tę złożoność, zachęcając złożonych oferentów do przyjęcia odpowiedzialności za świadczenie usług wstępnego potwierdzenia.

Podstawową ideą tego podejścia jest stworzenie ustandaryzowanego protokołu, w ramach którego użytkownicy będą mogli po wniesieniu dodatkowej opłaty uzyskać natychmiastową gwarancję, że transakcja zostanie uwzględniona w kolejnym bloku, a także roszczenie o skutki realizacji tej transakcji. Jeśli oferent złamie jakąkolwiek obietnicę złożoną któremukolwiek użytkownikowi, może zostać obcięty.

Jak stwierdzono, transakcje L1 są gwarantowane na podstawie wstępnego potwierdzenia. Jeśli podsumowania są „oparte”, wówczas wszystkie bloki L2 są transakcjami L1, więc ten sam mechanizm może zostać użyty do zapewnienia wstępnego potwierdzenia dla dowolnego L2.

Na co właściwie patrzymy?

Załóżmy, że osiągniemy ostateczność pojedynczego slotu. Używamy technologii podobnej do Orbit, aby zmniejszyć liczbę osób podpisujących walidatory na slot, ale nie za bardzo, abyśmy mogli poczynić postępy w realizacji kluczowego celu, jakim jest zmniejszenie minimalnej stawki wynoszącej 32 ETH. Czas slotu może zostać wydłużony do 16 sekund, wtedy stosujemy wstępne potwierdzenie typu rollup lub wstępne potwierdzenie podstawowe, aby zapewnić użytkownikom szybsze potwierdzenie. Co ostatecznie otrzymaliśmy: architekturę epokową.

Istnieje głęboki filozoficzny powód, dla którego tak trudno uniknąć architektury epokowo-szczelinowej: zgrubne uzgodnienie czegoś zajmuje mniej czasu niż osiągnięcie porozumienia w sprawie czegoś o największym stopniu „ostateczności ekonomicznej”.

Prostym powodem jest liczba węzłów. Chociaż stary kompromis w zakresie decentralizacji liniowej/czasu końcowego/narzutu wygląda teraz łagodnie ze względu na ultra zoptymalizowaną agregację BLS i nadchodzące ZK-STARK, nie można zignorować następujących powodów:

  • „Przybliżony konsensus” wymaga tylko niewielkiej liczby węzłów, podczas gdy ostateczność ekonomiczna wymaga zdecydowanej większości węzłów.

  • Gdy liczba węzłów przekroczy określony rozmiar, należy poświęcić więcej czasu na zbieranie podpisów.

W dzisiejszym Ethereum 12-sekundowy przedział jest podzielony na trzy podsekcje: publikacja i dystrybucja blokowa, atestacja i agregacja atestów. Jeśli liczba sprawdzających zostanie znacznie zmniejszona, możemy zredukować do dwóch podslotów i zastosować 8-sekundowy przedział czasowy. Innym, bardziej realistycznym i większym czynnikiem jest „jakość” węzła. Kolejnym większym czynnikiem jest „jakość” węzła. Gdybyśmy mogli również polegać na wyspecjalizowanym podzbiorze węzłów w celu osiągnięcia przybliżonej zgodności (i nadal używać pełnego zestawu walidatorów do określenia ostateczności), moglibyśmy skrócić to do ~2 sekund.

Zatem moim zdaniem architektura epoki i szczeliny jest oczywiście poprawna, ale nie wszystkie architektury epoki i szczeliny są sobie równe, dlatego warto pełniej zbadać przestrzeń projektową. Kierunek godny dalszych badań nie jest tak ściśle powiązany jak u Gaspera, ale z silniejszym rozdzieleniem obaw pomiędzy obydwoma mechanizmami.

Co powinien zrobić L2?

Moim zdaniem L2 ma obecnie trzy rozsądne strategie:

  • Zarówno technicznie, jak i duchowo „oparte”. Oznacza to, że optymalizują właściwości techniczne warstwy bazowej Ethereum i jej wartości (wysoka decentralizacja, odporność na cenzurę itp.). W najprostszej formie można myśleć o tych pakietach zbiorczych jako o „markowych fragmentach”, ale mogą one być również znacznie bardziej ambitne i obejmować intensywne eksperymenty z nowymi projektami maszyn wirtualnych i innymi ulepszeniami technicznymi.

  • Zostań „serwerem z rusztowaniem blockchain” i wykorzystaj go w pełni. Jeśli zaczniesz od serwera, a następnie dodasz dowody ważności STARK, aby upewnić się, że serwer przestrzega zasad, aby zapewnić użytkownikom prawo do wycofywania lub wymuszania transakcji oraz swobodę zbiorowego wyboru, albo poprzez skoordynowane wypłaty masowe, albo poprzez zmianę zamawiającego głosuj, to masz. Osiąga większość korzyści płynących z łączenia w górę, zachowując jednocześnie większość wydajności serwera.

  • Środek: szybki łańcuch ze stu węzłami, Ethereum zapewnia dodatkową interoperacyjność i bezpieczeństwo. Jest to de facto aktualny plan działania dla wielu projektów L2.

W przypadku niektórych zastosowań (np. ENS, przechowywanie kluczy, niektóre protokoły płatności) wystarczający jest czas blokowania wynoszący 12 sekund. W przypadku zastosowań, w których nie ma to zastosowania, jedynym rozwiązaniem jest architektura epokowo-slotowa. W trzech przypadkach „epoką” jest SSF Ethereum, ale slot jest inny w każdym z trzech powyższych przypadków:

  • Architektura epoki i slotu natywna dla Ethereum

  • Wstępne potwierdzenie serwera

  • wstępne potwierdzenie komisji

Kluczowym pytaniem jest, jak dobrzy możemy być w kategorii 1? W szczególności, jeśli będzie naprawdę dobrze, wydaje się, że kategoria 3 nie będzie miała tak dużego znaczenia. Ponieważ wszystkie rozwiązania „oparte” nie mają zastosowania do danych L2 poza łańcuchem, takich jak plazmy i walidacje, kategoria 2 zawsze będzie istnieć. Jeśli architekturę epoki i szczeliny natywną dla Ethereum można skrócić do 1 sekundy czasu szczeliny, wówczas przestrzeń dla kategorii 3 stanie się znacznie mniejsza.

Dziś jesteśmy daleko od ostatecznych odpowiedzi na te pytania. Kluczowym pytaniem jest, jak bardzo złożoności staną się proponujący bloki, co pozostaje obszarem dużej niepewności. Projekty takie jak Orbit SSF są bardzo nowatorskie, zatem przestrzeń projektowa projektów takich jak wykorzystanie Orbit SSF jako epoki w epoce i szczelinie jest nadal warta pełnego zbadania. Im więcej mamy opcji, tym lepiej możemy zrobić dla użytkowników L1 i L2 i możemy ułatwić życie programistom L2.