Vitalik: Przegląd różnych typów L2

Projekty L2 będą coraz bardziej zmierzać w kierunku heterogeniczności.

Oryginalny tytuł: „Different types of layer 2s”

Autor: Vitalik Buterin

Tłumaczenie: BlockBeats

Ekosystem gwałtownie się rozwinął w ciągu ostatniego roku. Tradycyjnie ekosystem ZK-EVM rollup, reprezentowany przez StarkNet, Arbitrum, Optimism i Scroll, szybko się rozwija, stale zwiększając swoje bezpieczeństwo, a strona L2beat dobrze podsumowuje stan każdego projektu.

Ponadto widzimy, że niektóre zespoły budują sidechainy, a jednocześnie zaczynają rozwijać rozwiązania rollup (np. Polygon), niektóre projekty L1 próbują przejść w kierunku walidacji efektywności (np. Celo), a także pojawiają się zupełnie nowe próby (np. Linea, Zeth…).

Jednym z nieuniknionych rezultatów jest to, że widzimy, iż projekty L2 stają się coraz bardziej heterogeniczne (czyli „heterogeniczne”. Uwaga tłumacza: w kontekście kryptowalut „heterogeniczność” odnosi się do współistnienia lub mieszania się różnych rodzajów lub natur rzeczy. Termin ten jest często używany do opisu różnych blockchainów, protokołów, technologii lub aktywów, które mają różne cechy, zasady lub właściwości). Przewiduję, że ten trend będzie się utrzymywał z następujących powodów:

Obecnie niektóre niezależne projekty L1 dążą do ściślejszej integracji z ekosystemem Ethereum i mogą potencjalnie przekształcić się w projekty L2. Projekty te mogą chcieć przyjąć etapowy sposób przejścia. Natychmiastowe, całościowe przejście obniżyłoby użyteczność, ponieważ technologia nie jest jeszcze gotowa na przeniesienie wszystkiego do rozwiązania rollup. Z kolei zbyt późne całościowe przejście może spowodować utratę impetu i brak realnego znaczenia.

Niektóre scentralizowane projekty chcą zapewnić swoim użytkownikom większe bezpieczeństwo i badają rozwiązania oparte na blockchainie. W wielu przypadkach projekty te mogłyby wcześniej rozważać „dozwolone łańcuchy konsorcjalne”. W rzeczywistości mogą one potrzebować tylko poziomu „pół-scentralizowanego”. Ponadto zazwyczaj charakteryzują się bardzo wysoką przepustowością, co przynajmniej w krótkim okresie nie nadaje się do rozwiązań rollup.

Zastosowania niefinansowe, takie jak gry czy media społecznościowe, chcą się zdecentralizować, ale potrzebują tylko określonego poziomu bezpieczeństwa.

W przypadku mediów społecznościowych w rzeczywistości różne części aplikacji są obsługiwane w różny sposób: rzadkie i wartościowe działania, takie jak rejestracja nazwy użytkownika i odzyskiwanie konta, powinny być realizowane w rozwiązaniu rollup, ale częste i niskowartościowe działania, takie jak posty i głosowania, wymagają mniejszego poziomu bezpieczeństwa – jeśli awaria blockchaina spowoduje zniknięcie Twojego posta, jest to akceptowalna cena; ale jeśli awaria blockchaina spowoduje utratę konta, to już poważniejszy problem.

Ważnym tematem jest to, że chociaż obecnie aplikacje i użytkownicy na Ethereum L1 są skłonni w krótkim okresie płacić niewielkie, ale nadal widoczne opłaty rollup, użytkownicy spoza świata blockchain są mniej skłonni do tego: jeśli wcześniej płaciłeś 1 dolara, to zapłacenie 0,10 dolara jest łatwiejsze do zaakceptowania, ale jeśli wcześniej płaciłeś 0 dolarów, to jest to trudniejsze do przyjęcia.

Dotyczy to zarówno aplikacji, które są dziś nadal scentralizowane, jak i mniejszych projektów L1, które zwykle mają bardzo niskie opłaty przy małej liczbie użytkowników.

Naturalnym pytaniem jest: dla konkretnej aplikacji, która z tych złożonych kompromisów pomiędzy rozwiązaniami rollup, validium (walidacja efektywności) i innymi systemami jest dla niej rozsądna?

Rollupy vs Validium vs Systemy odłączone

Pierwszy wymiar bezpieczeństwa i skalowalności, który omówimy, można opisać następująco: jeśli posiadasz aktywo wydane na L1, następnie deponujesz je na L2, a potem przenosisz na swoje konto, to jak dużą masz gwarancję, że możesz je wycofać z powrotem na L1?

Jednocześnie pojawia się powiązane pytanie: jakie wybory technologiczne prowadzą do tego poziomu gwarancji i jakie są kompromisy tych wyborów?

Możemy opisać ten problem za pomocą prostego wykresu:

Warto zauważyć, że jest to uproszczony schemat, w którym istnieje wiele opcji pośrednich. Na przykład:

Pomiędzy rollupem a validium: w validium każdy może dokonać płatności on-chain, aby pokryć opłatę transakcyjną, wtedy operator będzie zmuszony dostarczyć pewne dane on-chain, w przeciwnym razie straci depozyt.

Pomiędzy plasma a validium: system Plasma zapewnia gwarancje bezpieczeństwa podobne do rollup, z dostępnością danych off-chain, ale obsługuje tylko ograniczoną liczbę aplikacji. System może zapewnić pełną EVM i dla użytkowników niekorzystających z bardziej złożonych aplikacji oferować gwarancje na poziomie Plasma, a dla korzystających z tych aplikacji – na poziomie validium.

Te opcje pośrednie można postrzegać jako spektrum pomiędzy rollupem a validium. Co jednak skłania aplikacje do wyboru konkretnego punktu na tym spektrum, a nie bardziej na lewo lub prawo? Tutaj są dwa główne czynniki:

1. Koszt natywnej dostępności danych Ethereum, który wraz z rozwojem technologii będzie z czasem maleć. Nadchodzący hard fork Ethereum, Dencun, wprowadza EIP-4844 (znany również jako „proto-danksharding”), który zapewnia około 32 kB/s dostępności danych on-chain.

Oczekuje się, że w ciągu najbliższych kilku lat, wraz z wprowadzeniem pełnego dankshardingu, dostępność danych będzie stopniowo wzrastać, a ostatecznym celem jest około 1,3 MB/s dostępności danych. Jednocześnie ulepszenia kompresji danych pozwolą nam osiągnąć więcej przy tej samej ilości danych.

2. Własne potrzeby aplikacji: jak poważna jest strata użytkownika z powodu wysokich opłat w porównaniu do problemów z aplikacją? Aplikacje finansowe tracą więcej w przypadku awarii aplikacji; gry i media społecznościowe obejmują dużą liczbę aktywności użytkowników o stosunkowo niskiej wartości, więc dla nich różne kompromisy bezpieczeństwa mają sens.

Ten kompromis wygląda mniej więcej jak na poniższym wykresie:

Innym wartym wspomnienia typem są pre-confirmations (wstępne potwierdzenia). Pre-confirmations to wiadomości podpisane przez grupę uczestników w rollupie lub validium, które stwierdzają: „potwierdzamy, że te transakcje są zawarte w tej kolejności, a post-state root jest taki”. Uczestnicy ci mogą podpisać pre-confirmation niezgodne z rzeczywistością, ale jeśli tak się stanie, ich depozyt zostanie zniszczony.

Jest to bardzo przydatne dla aplikacji o niskiej wartości (np. płatności konsumenckie), podczas gdy aplikacje o wysokiej wartości (np. transfery finansowe na miliony dolarów) mogą poczekać na „zwykłe” potwierdzenie wspierane przez pełne bezpieczeństwo systemu.

Pre-confirmations można postrzegać jako kolejny przykład systemu hybrydowego, podobnie jak wspomniany wcześniej „plasma/validium mix”, ale tym razem jest to mieszanka pomiędzy rollupem (lub validium) o pełnym bezpieczeństwie, ale wysokim opóźnieniu, a systemem o niższym poziomie bezpieczeństwa, ale niskim opóźnieniu. Aplikacje wymagające niskiego opóźnienia uzyskują niższe bezpieczeństwo, ale mogą współistnieć w tym samym ekosystemie z tymi, które są gotowe zaakceptować wyższe opóźnienie dla maksymalnego bezpieczeństwa.

Bezpieczne odczytywanie Ethereum bez zaufania

Inny, rzadziej rozważany, ale nadal bardzo ważny rodzaj połączenia dotyczy zdolności systemu do odczytywania blockchaina Ethereum. W szczególności obejmuje to zdolność systemu do cofania się w przypadku cofnięcia Ethereum. Aby zrozumieć, dlaczego jest to wartościowe, rozważ następującą sytuację:

Załóżmy, jak pokazano na rysunku, że blockchain Ethereum ulega cofnięciu. Może to być tymczasowa przerwa w epoce, gdy blockchain nie został jeszcze ostatecznie potwierdzony; lub może to być okres nieaktywności, gdy zbyt wielu walidatorów jest offline i blockchain nie może zostać ostatecznie potwierdzony przez dłuższy czas.

Najgorszy możliwy przypadek wygląda następująco: załóżmy, że pierwszy blok górnego łańcucha (top chain) odczytuje pewne dane z najbardziej lewego bloku łańcucha Ethereum. Na przykład ktoś deponuje 100 ETH na górnym łańcuchu. Następnie Ethereum ulega cofnięciu, ale górny łańcuch nie. W rezultacie przyszłe bloki górnego łańcucha poprawnie podążają za nowymi, prawidłowymi blokami łańcucha Ethereum, ale błędna transakcja (czyli depozyt 100 ETH) nadal istnieje w górnym łańcuchu. Ta luka może prowadzić do inflacji waluty, zamieniając mostkowane ETH na górnym łańcuchu w częściową rezerwę.

Istnieją dwa sposoby rozwiązania tego problemu:

1. Górny łańcuch może odczytywać tylko ostatecznie potwierdzone bloki Ethereum, więc nigdy nie musi się cofać;

2. Jeśli Ethereum się cofnie, górny łańcuch również może się cofnąć. Oba sposoby zapobiegają temu problemowi. Pierwszy jest łatwiejszy do wdrożenia, ale jeśli Ethereum wejdzie w okres nieaktywności, może to prowadzić do utraty funkcjonalności przez dłuższy czas. Drugi jest trudniejszy do wdrożenia, ale zapewnia zawsze najlepszą funkcjonalność.

Zwróć uwagę, że pierwszy sposób ma szczególny przypadek. Jeśli Ethereum padnie ofiarą ataku 51%, prowadząc do dwóch nowych, niekompatybilnych bloków, które oba wydają się ostatecznie potwierdzone, górny łańcuch może wybrać zły blok (czyli blok, którego ostatecznie nie popiera konsensus społeczny Ethereum) i będzie musiał się cofnąć, aby przełączyć się na właściwy blok. Można powiedzieć, że nie trzeba pisać kodu na tę sytuację z wyprzedzeniem; można to rozwiązać przez hard fork górnego łańcucha.

Zdolność blockchaina do bezpiecznego odczytywania Ethereum ma dwa ważne powody:

Po pierwsze, ta zdolność może zmniejszyć problemy z bezpieczeństwem związane z mostkowaniem tokenów wydanych na Ethereum (lub innych rozwiązaniach drugiej warstwy) na ten łańcuch;

Po drugie, ta zdolność umożliwia portfelom abstrakcyjnym z użyciem wspólnej struktury kluczy bezpieczne przechowywanie aktywów na tym łańcuchu.

Mimo kontrowersji, znaczenie pierwszego sposobu zostało szeroko uznane. Podobnie drugi sposób jest bardzo ważny, ponieważ oznacza, że możesz mieć portfel, który łatwo zmienia klucze i przechowuje aktywa na wielu różnych łańcuchach.

Czy posiadanie mostu czyni łańcuch validium?

Załóżmy, że górny łańcuch początkowo uruchamia się jako niezależny łańcuch, a następnie ktoś wdraża kontrakt mostkujący na Ethereum. Kontrakt mostkujący to po prostu kontrakt, który akceptuje nagłówki bloków górnego łańcucha, weryfikuje, czy dowolny nagłówek bloku przesłany do niego ma ważny certyfikat potwierdzający, że został zaakceptowany przez konsensus górnego łańcucha, i dodaje ten nagłówek do listy.

Aplikacje mogą na tej podstawie budować funkcje, takie jak depozyty i wypłaty tokenów. Gdy taki most zostanie ustanowiony, czy zapewnia on jakiekolwiek gwarancje bezpieczeństwa aktywów, o których wcześniej wspominaliśmy?

Jak dotąd – nie! Są dwa powody:

1. Weryfikujemy podpisy bloków, ale nie weryfikujemy, czy transformacja stanu jest prawidłowa. Jeśli więc zdeponujesz aktywa wydane na Ethereum na górnym łańcuchu, a walidatorzy górnego łańcucha staną się nieuczciwi, mogą podpisać nieprawidłową transformację stanu i ukraść te aktywa;

2. Górny łańcuch nadal nie może odczytywać Ethereum. Dlatego nie możesz zdeponować natywnych aktywów Ethereum na górnym łańcuchu, chyba że polegasz na innych (potencjalnie niebezpiecznych) mostach stron trzecich.

Teraz zbudujmy most jako most weryfikujący: nie tylko weryfikuje konsensus, ale także sprawdza, czy stan każdego nowego bloku obliczony za pomocą dowodu ZK-SNARK jest prawidłowy.

Po wykonaniu tego kroku walidatorzy górnego łańcucha nie mogą już ukraść Twoich środków. Mogą opublikować blok z niedostępnymi danymi, uniemożliwiając wszystkim wypłatę środków, ale nie mogą ich ukraść (chyba że spróbują wymusić ujawnienie danych umożliwiających wypłatę środków przez żądanie okupu od użytkowników). To ten sam model bezpieczeństwa, co validium.

Jednak nadal nie rozwiązaliśmy drugiego problemu: górny łańcuch nie może odczytywać danych z Ethereum. Aby to osiągnąć, musimy zastosować jedną z dwóch metod:

1. Umieścić na górnym łańcuchu kontrakt mostkujący, który weryfikuje ostatecznie potwierdzone bloki Ethereum;

2. Dołączyć do każdego bloku górnego łańcucha hash ostatniego bloku Ethereum i zastosować regułę wyboru forków, aby wymusić powiązanie hashów. Oznacza to, że blok górnego łańcucha powiązany z blokiem Ethereum spoza głównego łańcucha sam staje się blokiem spoza głównego łańcucha. Jeśli blok Ethereum, do którego odwołuje się blok górnego łańcucha, początkowo był na głównym łańcuchu, ale później stał się blokiem bocznym, blok górnego łańcucha również musi stać się blokiem bocznym.

Te fioletowe połączenia mogą być powiązaniami hash lub kontraktami mostkującymi weryfikującymi konsensus Ethereum

Czy to wystarczy? W rzeczywistości nie, ponieważ istnieją pewne drobne przypadki brzegowe:

1. Co się stanie, jeśli Ethereum padnie ofiarą ataku 51%?

2. Jak obsłużyć aktualizacje hard fork Ethereum?

3. Jak obsłużyć aktualizacje hard fork Twojego łańcucha?

Atak 51% na Ethereum spowoduje skutki podobne do ataku 51% na górny łańcuch, ale w odwrotną stronę. Hard fork Ethereum może unieważnić most Ethereum w górnym łańcuchu. Zobowiązanie społeczne (social commitment), że jeśli Ethereum cofnie ostatecznie potwierdzony blok, to zostanie cofnięty, a jeśli Ethereum przeprowadzi hard fork, to zostanie przeprowadzony hard fork, jest najczystszym sposobem rozwiązania tego problemu.

Takie zobowiązanie w rzeczywistości może nigdy nie wymagać faktycznego wykonania: jeśli organ zarządzający górnym łańcuchem wykryje dowody na możliwy atak lub hard fork, może aktywować organ zarządzający i tylko w przypadku jego niepowodzenia przeprowadzić hard fork górnego łańcucha.

W przypadku trzeciego problemu jedyną wykonalną odpowiedzią jest ustanowienie jakiejś formy organu zarządzającego na Ethereum, aby umożliwić kontraktowi mostkującemu na Ethereum rozpoznanie aktualizacji hard fork górnego łańcucha.

Podsumowanie: dwukierunkowa weryfikacja mostu jest prawie wystarczająca, aby blockchain stał się validium. Głównym pozostałym elementem jest zobowiązanie społeczne, że jeśli na Ethereum wystąpią nieprawidłowości uniemożliwiające prawidłowe działanie kontraktu mostkującego, drugi blockchain przeprowadzi hard fork w odpowiedzi.

Wnioski

„Połączenie z Ethereum” ma dwa kluczowe wymiary:

1. Bezpieczeństwo wycofywania do Ethereum;

2. Bezpieczeństwo odczytywania Ethereum.

Oba są bardzo ważne i mają różne czynniki do rozważenia. W obu przypadkach istnieje spektrum:

Zwróć uwagę, że każdy wymiar ma dwa różne sposoby pomiaru (w rzeczywistości są cztery wymiary): bezpieczeństwo wycofywania można mierzyć przez (i) poziom bezpieczeństwa oraz (ii) ilu użytkowników lub przypadków użycia korzysta z najwyższego poziomu bezpieczeństwa;

Bezpieczeństwo odczytu można mierzyć przez (i) jak szybko łańcuch może odczytywać bloki Ethereum, szczególnie różnicę między blokami ostatecznie potwierdzonymi a dowolnymi blokami, oraz (ii) poziom zobowiązania społecznego w obsłudze przypadków brzegowych, takich jak ataki 51% i hard forki.

W wielu obszarach tej przestrzeni projektowej istnieje wartość dla projektów. Dla niektórych aplikacji wysoki poziom bezpieczeństwa i ścisłe połączenie są kluczowe. Dla innych, w celu uzyskania większej skalowalności, można zaakceptować bardziej elastyczne warunki. W wielu przypadkach rozpoczęcie dziś od bardziej elastycznych warunków i stopniowe przechodzenie do ściślejszej integracji w ciągu najbliższej dekady, wraz z postępem technologicznym, może być optymalnym wyborem.