Ten artykuł został skompilowany i zorganizowany przez BlockWeeks
Merge to przejście Ethereum z konsensusu proof-of-work (PoW) na proof-of-stake (PoS), a także najbardziej złożona i radykalna zmiana kodu w historii Ethereum. Jego proces aktywacji różni się od jakiegokolwiek wcześniejszego hard forka: składa się z trzech głównych kroków i wymaga od operatorów węzłów przejścia od uruchamiania tylko jednego klienta oprogramowania do jednoczesnego uruchamiania dwóch klientów. Jako największy na świecie blockchain ogólnego przeznaczenia pod względem kapitalizacji rynkowej i całkowitej zablokowanej wartości, wartość i reputacja stawką w przejściu Ethereum są ogromne.
Co Merge ma rozwiązać: Fuzja dwóch łańcuchów
Obecnie transakcje Ethereum są finalizowane poprzez protokół konsensusu PoW zwany ethash. Równolegle z tym łańcuchem PoW działa Beacon Chain—niezależny blockchain, który od grudnia 2020 roku samodzielnie uruchamia nowy protokół konsensusu PoS Ethereum, Gasper.
Celem Merge jest fuzja obu łańcuchów: sprawienie, by istniejący blockchain Ethereum opierał się całkowicie na Beacon Chain w celu wytworzenia konsensusu sieciowego, i całkowite porzucenie proof-of-work. Znane nam dziś Ethereum nie będzie już przetwarzać transakcji poprzez ethash, lecz będzie istnieć wyłącznie jako Warstwa Wykonawcza (EL), dla zdecentralizowanych aplikacji i użytkowników do rozgłaszania transakcji. Ethereum Virtual Machine (EVM), silnik obliczeniowy Ethereum, będzie nadal normalnie działać w Warstwie Wykonawczej.
Beacon Chain staje się wtedy Warstwą Konsensusu (CL) Ethereum: transakcje z Warstwy Wykonawczej są tutaj odbierane, przetwarzane i finalizowane. Pakowanie transakcji Warstwy Wykonawczej w bloki i finalizowanie ich poprzez protokół Gasper stanie się odpowiedzialnością walidatorów Beacon Chain. Po Merge, aby śledzić główny łańcuch Ethereum, wszyscy walidatorzy i operatorzy pełnych węzłów muszą jednocześnie uruchamiać dwa klienty oprogramowania—klienta Warstwy Wykonawczej i klienta Warstwy Konsensusu.
Krok pierwszy: Hard fork Bellatrix
Najpierw Warstwa Konsensusu Ethereum wykonuje hard fork zwany Bellatrix. Bellatrix wprowadza nową strukturę bloku Beacon Chain w Warstwie Konsensusu, aby pomieścić bloki przenoszące transakcje Warstwy Wykonawczej. Wbudowuje również zestaw instrukcji, aby węzły Warstwy Konsensusu nie zaczęły wpychać transakcji Warstwy Wykonawczej do bloków beacon, dopóki Warstwa Wykonawcza nie osiągnie określonego "Końcowego Całkowitego Trudności" (TTD). Wszystkie węzły Warstwy Konsensusu muszą uaktualnić się do Bellatrix przed określoną wysokością slotu (równoważną wysokości bloku w łańcuchu PoW). Po zakończeniu Bellatrix węzły Warstwy Konsensusu zaczynają monitorować TTD.
Kluczowy projekt: Dlaczego używać TTD zamiast wysokości bloku
Końcowa Całkowita Trudność mierzy skumulowaną trudność wydobycia Warstwy Wykonawczej Ethereum. Tutaj "trudność" odnosi się do tego, jak trudno jest górnikom dołączyć nowy blok do blockchaina, reprezentując, ile kombinacji górnicy zazwyczaj muszą wypróbować, aby znaleźć poprawny hash generujący następny blok. W miarę wzrostu mocy obliczeniowej (hash rate) wnoszonej przez górników, trudność automatycznie rośnie. TTD to suma trudności wydobycia wszystkich bloków w historii Ethereum.
Historycznie aktywacje hard forków Warstwy Wykonawczej nigdy nie opierały się na konkretnym TTD, lecz na wcześniej ustalonej wysokości bloku. Merge porzucił to podejście z powodu możliwości ataku "szybkiego forka": atakujący mógłby użyć mniejszości mocy hash, aby rozwidlić Warstwę Wykonawczą i wydobyć do określonego numeru bloku szybciej niż główny łańcuch. Gdyby tak się stało, Warstwa Konsensusu mogłaby omyłkowo zakończyć merge z łańcuchem mniejszości atakującego zamiast z głównym łańcuchem. Dlatego deweloperzy wybrali TTD jako próg wyzwalający Merge, ponieważ jest znacznie trudniejszy do manipulowania przez złośliwych aktorów.
Ale używanie TTD jako progu ma również koszt: TTD jest niezwykle trudną do przewidzenia wartością, co również sprawia, że przewidywanie czasu aktywacji Merge po Bellatrix jest trudne i nieprecyzyjne. Ta konsekwencja ujawniła się, gdy główni deweloperzy po raz pierwszy próbowali aktywować Merge w testnecie Ropsten—pierwotne ustawienie TTD było niedokładne, powodując odchylenie czasu aktywacji od oczekiwań.
Krok drugi i krok trzeci: Paryż i przełączenie warstwy wykonawczej
Gdy warstwa wykonawcza osiągnie próg TTD, uruchamiane są dwie propozycje aktualizacji warstwy wykonawczej, z których jedna to EIP-4399: zmienia ona sposób generowania losowości w łańcuchu, przestając polegać na trudności wydobycia w celu generowania losowych liczb całkowitych dla dApps. Oba EIP aktywują się jednocześnie w momencie osiągnięcia TTD. Jednocześnie węzły warstwy konsensusu, które oczekiwały i monitorowały tę wartość TTD, również od tego momentu zaczynają przetwarzać transakcje z warstwy wykonawczej.
Należy podkreślić tempo wydawania klientów i komunikacji z interesariuszami. Aby przygotować się do hard forka Bellatrix, oczekuje się, że Fundacja Ethereum opublikuje kilka tygodni wcześniej post na blogu zawierający listę wersji klientów odpowiadających aktualizacjom Paryż i Bellatrix, aby operatorzy węzłów mogli je wcześniej pobrać. Te początkowe wersje będą zawierać niezwykle dużą wartość TTD jako symbol zastępczy. Ponieważ Bellatrix aktywuje się na określonej wysokości slotu, data i szacowany czas tej aktualizacji również zostaną przekazane odpowiednim stronom.
Po zakończeniu Bellatrix nowa wartość TTD zostanie ponownie przekazana operatorom węzłów za pośrednictwem drugiego postu na blogu. Tym razem pełna aktualizacja klientów warstwy konsensusu lub warstwy wykonawczej nie jest wymagana; co najmniej wystarczy dodać jedną linię kodu do każdego z dwóch typów klientów, aby ręcznie nadpisać poprzednią wartość TTD. Opcjonalne aktualizacje klientów mogą być również w tym czasie oferowane, ale jest to decyzja każdego zespołu klienta i bynajmniej nie jest obowiązkowym wydaniem wymaganym do podążania za końcowym etapem Merge.
Po ogłoszeniu wartości nadpisania TTD rozpoczyna się faza oczekiwania na osiągnięcie nowego progu. Chociaż będą przybliżone szacunki czasu, dokładna data i godzina aktywacji Paryża nie mogą być z góry precyzyjnie znane.
Ryzyka wykonawcze, których nie można ignorować
1. Próżnia operacyjna spowodowana nieprzewidywalnym timingiem
Niemożność precyzyjnego przewidzenia TTD oznacza, że wszystkie usługi opierające się na Ethereum nie mogą z góry ustalić dokładnego czasu „momentu Merge”. Dla firm, które muszą wstrzymać lub zamrozić depozyty i wypłaty, stanowi to realne wyzwanie operacyjne.
2. Presja operacyjna architektury dwuklientowej
Po Merge operatorzy węzłów muszą jednocześnie uruchamiać klientów warstwy wykonawczej i warstwy konsensusu, a każda błędna konfiguracja lub niezgodność wersji po którejkolwiek stronie może spowodować opóźnienie węzła. Wczesne próby w sieciach testowych (Sepolia, Goerli) stają się zatem kluczowe.
3. Fundamentalna zmiana w produkcji bloków i logice finalności
Po Merge bloki nie będą już finalizowane w jednostkach wysokości bloku, ale w jednostkach slotów i epok. Walidatorzy przetwarzają jeden slot co 12 sekund, a 32 sloty tworzą jedną epokę, czyli jedną epokę co 6,4 minuty. Transakcje w Beacon Chain osiągają finalność po 2 epokach, około 12,8 minuty. Dla giełd, DEX-ów i innych aplikacji DeFi zbudowanych na różnych założeniach dotyczących finalności transakcji i szybkości potwierdzenia, te nadchodzące zmiany muszą być przewidziane i przygotowane z wyprzedzeniem, aby uniknąć przerw w usługach lub wykorzystania.
Wniosek: Małe prawdopodobieństwo, duży wpływ
Przejście Ethereum z PoW na PoS to najbardziej uważnie obserwowana i najdalej idąca aktualizacja blockchaina warstwy 1 w historii kryptowalut; nigdy wcześniej sieć porównywalna skalą i znaczeniem do Ethereum nie przeszła tak drastycznej zmiany. Ponieważ deweloperzy zainwestowali ogromny wysiłek w testy i przygotowania, prawdopodobieństwo, że powyższe ryzyka poważnie wpłyną na użytkowników i dApps, nie jest wysokie; ale jeśli którykolwiek ze scenariuszy opisanych w tym artykule wystąpi w stopniu wymagającym wycofania aktualizacji poprzez awaryjny hard fork, wartość i reputacja Ethereum jako blockchaina ogólnego przeznaczenia mogą zostać nadszarpnięte.
Dlatego wszystkie zainteresowane strony powinny być świadome tych ryzyk i podejmować działania mające na celu złagodzenie wpływu potencjalnych problemów na ich własne korzystanie z sieci, na przykład poprzez wstrzymanie lub zamrożenie depozytów i wypłat w krytycznych oknach czasowych, w których mogą wystąpić przerwy. Jednocześnie walidatorzy, dApps i dostawcy usług powinni przygotować się, uczestnicząc w kolejnych próbach aktywacji w sieciach testowych Sepolia i Goerli, co może zarówno zapewnić, że operatorzy węzłów opanują najlepsze praktyki dotyczące przeprowadzenia aktualizacji Merge, jak i ujawnić problemy w tym procesie przed aktywacją w sieci głównej. Ponadto czujność Fundacji Ethereum, zespołów klientów i zaufanych mediów wobec dezinformacji związanej z Merge podczas aktywacji jest szczególnie krytyczna — w tym nieprawidłowych wartości TTD, nieprawidłowych wersji klientów, nieprawidłowych oczekiwań dotyczących czasu i nieprawidłowych wskazówek operacyjnych — i muszą one szybko koordynować działania, aby jasno poinformować odpowiednie strony, do czego mają się przygotować w następnej kolejności, aż aktualizacja Merge zostanie całkowicie zakończona.
