Jakie EIP zostaną uwzględnione w aktualizacji Pectra? Czy spowoduje to wzrost inflacji ETH?

Zatwierdzone EIP zwiększą programowalność kont, efektywność walidacji Ethereum oraz optymalizację stakingu, natomiast niezatwierdzone EIP koncentrują się na poprawie skalowalności L2.

Autor: 0XNATALIE

Następna aktualizacja Ethereum, Pectra, zawdzięcza swoją nazwę połączeniu słów Prague i Electra.

Prague oznacza aktualizację warstwy wykonawczej, nazwaną na cześć miasta Praga, w którym odbyła się konferencja deweloperów Ethereum (Devcon 4), natomiast Electra symbolizuje aktualizację warstwy konsensusu, gdzie nazwy gwiazd są przypisywane alfabetycznie. Wybrana gwiazda Electra odpowiada literze „E”.

Aktualizacja Pectra może być w historii Ethereum hard forkiem obejmującym największą liczbę Ethereum Improvement Proposals (EIP). Zawiera ona szereg propozycji dotyczących operacji walidatorów i poprawy wydajności mainnetu, a także wprowadza propozycje optymalizujące L2. Sieć testowa Pectra Devnet 4 właśnie została uruchomiona, a obecnie już 8 EIP zostało potwierdzonych do włączenia w aktualizację Pectra.

Potwierdzone EIP oraz ich wpływ

Te 8 EIP wpływa na użytkowników w następujący sposób: poprzez dodanie możliwości wykonywania kodu przez EOA zwiększają elastyczność kont, umożliwiając wykonywanie bardziej złożonych operacji; zwiększenie limitu stakingu może zwiększyć popyt na ETH; jednocześnie optymalizacja procesów walidatorów poprawia bezpieczeństwo i efektywność, zwiększając szybkość i przepustowość Ethereum.

1. EIP-2537 (wsparcie dla podpisów BLS): Poprzez wprowadzenie szeregu prekompilowanych kontraktów (precompiles), Ethereum zyskuje wsparcie dla operacji na krzywej BLS12-381, umożliwiając weryfikację podpisów BLS oraz agregację wielu podpisów w jeden, co zmniejsza złożoność weryfikacji. Podpisy BLS to algorytm kryptograficzny, który pozwala generować krótsze podpisy i wspiera agregację podpisów. To pomoże L2, które wymagają masowej weryfikacji podpisów i danych, działać wydajniej.
2. EIP-2935 (przechowywanie historycznych hashów bloków w stanie): Poprzez przechowywanie ostatnich 8192 hashów bloków w kontrakcie systemowym, wspiera model Stateless Clients i zapewnia bardziej elastyczne zapytania o historyczne hashe bloków. Hashe te mogą być bezpośrednio odpytywane przez kontrakty i dołączane jako dowody (witness) dla klientów bezstanowych. Klient nie musi utrzymywać pełnej historii blockchaina ani przechowywać dużych ilości danych, wystarczy polegać na hashach bloków przechowywanych w stanie i odpowiednich dowodach, aby zweryfikować legalność bloków i transakcji.
3. EIP-6110 (udostępnianie depozytów walidatorów on-chain): Przenosi obsługę depozytów walidatorów z warstwy konsensusu do warstwy wykonawczej, umożliwiając obsługę i weryfikację on-chain, bez polegania na dodatkowym mechanizmie głosowania w warstwie konsensusu w celu potwierdzenia ważności informacji o depozycie. Zwiększa to bezpieczeństwo procesu depozytów, zmniejsza opóźnienia w obsłudze oraz upraszcza projekt warstwy konsensusu i klientów.
4. EIP-7002 (wyjście inicjowane przez warstwę wykonawczą): Pozwala właścicielom voucherów wypłat samodzielnie inicjować wyjście, bez konieczności polegania na aktywnym kluczu walidatora (klucz BLS), zwiększając autonomię użytkownika. Obecnie tylko aktywny klucz walidatora może inicjować wyjście, co oznacza, że jeśli aktywny klucz zostanie utracony lub walidator powierzy zadania walidacyjne stronie trzeciej (np. dostawcy usług stakingowych), właściciel vouchera wypłaty (czyli faktyczny właściciel środków) nie może samodzielnie kontrolować stakowanego ETH. Propozycja ta umożliwia inicjowanie wyjścia i wypłaty ETH przez warstwę wykonawczą, a posiadacz vouchera wypłaty może zainicjować wyjście bez polegania na aktywnym kluczu.
5. EIP-7251 (zwiększenie limitu stakingu): Zwiększa maksymalne saldo efektywne walidatora, pozwalając każdemu walidatorowi posiadać więcej niż 32 ETH w stakingu, przy zachowaniu minimalnego progu stakingu na poziomie 32 ETH. Ma to na celu umożliwienie dużym operatorom węzłów zmniejszenia liczby walidatorów w sieci poprzez łączenie wielu walidatorów, co zmniejsza obciążenie P2P, agregację podpisów oraz wymagania dotyczące przechowywania.
6. EIP-7549 (przeniesienie indeksu komitetu poza dowód): Przenosząc pole indeksu komitetu poza wiadomość Attestation (dowód), umożliwia bardziej efektywną agregację głosów konsensusu. Obecnie w mechanizmie konsensusu Ethereum każdy walidator głosuje, obejmując: głosowanie LMD GHOST (zawierające root bloku i slot), głosowanie Casper-FFG (zawierające informacje o źródle i celu), indeks komitetu (numer komitetu walidatora). Ponieważ indeks komitetu jest zawarty w podpisanej wiadomości, gdy wielu walidatorów głosuje na ten sam blok, nawet jeśli treść głosowania jest taka sama, generowane rooty podpisów są różne, co uniemożliwia łatwą agregację tych głosów. Przeniesienie pola indeksu komitetu poza samą wiadomość podpisu umożliwia bardziej efektywną agregację głosów, zmniejszając koszty weryfikacji i obciążenie sieci.
7. EIP-7685 (uniwersalne żądania warstwy wykonawczej): Definiuje uniwersalne ramy dla warstwy wykonawczej (EL) do przechowywania i obsługi żądań wywoływanych przez smart kontrakty. Ramy te wspierają więcej zachowań wywoływanych przez warstwę wykonawczą i umożliwiają jednolitą obsługę różnych typów żądań, upraszczając proces dodawania nowych typów żądań bez konieczności modyfikowania struktury bloku wykonawczego.
8. EIP-7702 (dodanie możliwości wykonywania kodu przez EOA): Dodaje możliwość wykonywania kodu przez konta zewnętrzne (EOA), zwiększając elastyczność i programowalność kont. EOA mogą poprzez autoryzowany podpis wskazać smart kontrakt do pośredniczenia w wykonywaniu określonych operacji, takich jak transakcje zbiorcze czy kontrola uprawnień. Pozwala to na korzystanie z pewnych funkcji smart kontraktów bez konieczności przekształcania konta w smart kontrakt.

EIP rozważane priorytetowo

Poniżej przedstawiono kilka aktywnie rozważanych EIP, które głównie poprzez optymalizację blobów zwiększają stabilność kosztów publikacji danych L2, wzmacniają zdolność przetwarzania transakcji L2 i skutecznie obniżają koszty L2. Ponadto, zmiana kosztu calldata może wpłynąć na ilość spalanych ETH, zwiększając presję inflacyjną na ETH.

• EIP-7742 (zniesienie zależności liczenia blobów między warstwą konsensusu a wykonawczą): Oddziela liczbę blobów między warstwą konsensusu a wykonawczą, upraszcza proces weryfikacji blobów, zmniejsza zbędną złożoność i zwiększa skalowalność oraz elastyczność protokołu. Obecnie warstwa wykonawcza i konsensusu mają zakodowaną na sztywno maksymalną liczbę blobów, co prowadzi do zbędnej weryfikacji. Propozycja ta znosi weryfikację maksymalnej liczby blobów przez warstwę wykonawczą, a zamiast tego warstwa konsensusu dynamicznie przekazuje wartość docelową blobów do warstwy wykonawczej. Pozwala to na bardziej elastyczną regulację parametrów blobów, dostosowując się do przyszłych potrzeb skalowania. EIP-7742 jest najmniej kontrowersyjną propozycją na liście EIP rozważanych do włączenia w aktualizację. Według najnowszego spotkania warstwy konsensusu, deweloperzy zgodzili się rozpocząć implementację EIP-7742 w pectra-devnet 5, ale ostateczne włączenie zależy od opinii warstwy wykonawczej podczas ACDE (All Core Developers Execution Layer Meeting).
• EIP 7762 (minimalna podstawowa opłata za blob): Podnosi MIN_BASE_FEE_PER_BLOB_GAS, aby skrócić czas potrzebny na dostosowanie ceny blobów do rozsądnego poziomu. Obecnie minimalna podstawowa opłata za blob wynosi 1 wei, a gdy popyt na blob przewyższa podaż, proces odkrywania ceny (czyli ustalania rozsądnej ceny blob Gas) jest zbyt powolny i wymaga dużo czasu, by osiągnąć odpowiedni poziom opłat. Podniesienie minimalnej podstawowej opłaty za blob pozwala skrócić czas dostosowania ceny, szybciej osiągnąć równowagę rynkową i zapewnić stabilność sieci podczas szczytowego zapotrzebowania.
• EIP-7623 (zwiększenie kosztu calldata): Podnosi koszt calldata w transakcjach, aby zmniejszyć maksymalny rozmiar bloku i zakres jego zmienności, zapewniając płynniejsze przetwarzanie transakcji przez sieć. Obecnie maksymalny rozmiar bloku wynosi około 1,79 MB, ale ze względu na masową publikację danych przez aplikacje typu rollup, średni rozmiar bloku stale rośnie. Zwiększając koszt calldata, głównie wykorzystywanego do transakcji związanych z dostępnością danych (DA), maksymalny rozmiar bloku zostaje zmniejszony do około 0,72 MB, pozostawiając miejsce na przyszłe zwiększenie limitu Gas bloku lub więcej blobów. Koszt transakcji dla zwykłych użytkowników pozostaje bez zmian, a zmiana ta dotyczy głównie transakcji polegających na masowym przechowywaniu danych na Ethereum. Jednak wzrost kosztu calldata może zmniejszyć konkurencyjność Ethereum w zakresie przechowywania danych. Ponadto, wzrost kosztu calldata może zmniejszyć liczbę transakcji, a tym samym ilość ETH spalanych przez mechanizm EIP-1559, co zwiększa presję inflacyjną na ETH.
• EIP 7782 (skrócenie czasu slotu): Skraca czas slotu Ethereum z 12 sekund do 8 sekund, częściej generując bloki, aby obsłużyć więcej transakcji, jako alternatywa dla zwiększenia liczby blobów w celu zwiększenia przepustowości transakcji. Może to jednak zakłócić działanie niektórych smart kontraktów zakodowanych na 12-sekundowy czas slotu oraz przyspieszyć problem rozrostu stanu Ethereum, zwiększając obciążenie przechowywania i obliczeń.
• EIP-7783 (stopniowe zwiększanie limitu Gas bloku): Jako łagodniejsza alternatywa dla EIP-7782, dynamicznie dostosowuje limit Gas bloku, stopniowo zwiększając liczbę transakcji możliwych do zawarcia w każdym bloku, zwiększając wydajność sieci. W porównaniu do bezpośredniego skrócenia czasu slotu, stopniowa regulacja limitu Gas pozwala na bardziej płynne skalowanie sieci. Propozycja ta nie wymaga hard forka, ale może wpłynąć na dane stanu.

Ponieważ aktualizacja Pectra obejmuje dużą liczbę EIP, aby zmniejszyć złożoność pojedynczej aktualizacji i przyspieszyć wdrożenie części EIP, w maju zespół inżynierów Ethereum Foundation, EthPandaOps, zasugerował podzielenie Pectra na dwie części, ale obawiano się wówczas opóźnienia aktualizacji, więc nie rozważano tego poważnie. We wrześniu badacz Ethereum, Alex Stokes, ponownie zaproponował podział, tym razem zyskując poparcie deweloperów. Taki podział pomoże ukończyć pierwszą część aktualizacji w ciągu sześciu miesięcy:

• Część pierwsza: obejmuje EIP już działające w sieci testowej Pectra Devnet (czyli już zatwierdzone 8 EIP), które są stosunkowo łatwe do wdrożenia i przeszły już wiele testów.
• Część druga: bardziej złożone EIP (takie jak PeerDAS, propozycje związane z EOF) oraz inne wymagające więcej czasu na testy zostaną wdrożone w drugiej fazie. Propozycje te wymagają dalszego rozwoju, audytu i testowania, szczególnie te dotyczące koordynacji warstwy konsensusu i wykonawczej.