Deweloper Ethereum, Derek Chiang, powiedział 7 września, że autorzy EIP-8141 znaleźli sposób na wyrażenie kilku funkcji transakcyjnych jako programowalnych wywołań kontraktów, zamiast dodawania ich osobno do koperty transakcyjnej Ethereum.
Podsumowanie
- Deweloperzy Ethereum twierdzą, że EIP-8141 może wyrażać funkcje transakcyjne poprzez wywołania kontraktów znane jako programowalne ramki.
- Ramki mogą wspierać wygaśnięcie, agregację podpisów, dowody prywatności i asercje po transakcji bez nowych pól w kopercie.
- EIP-8141 jest zaplanowany na Hegotá, chociaż jego specyfikacja pozostaje w fazie projektu, a daty aktywacji nie są ustalone.
- Deweloperzy koordynują EIP-8141 z EIP-8130, aby zachować strukturę i poprawić czytelność transakcji dla infrastruktury.
- Vitalik Buterin argumentuje, że rozdzielenie akcji transakcyjnych i zależności może umożliwić równoległą walidację i obniżyć koszty.
Chiang, współautor EIP-8141 i współpracownik Ethlabs, opisał to osiągnięcie jako „przełom projektowy” w poście omawiającym ostatnie prace autorów propozycji. Podejście to traktuje wygaśnięcie transakcji, zagregowane podpisy, korzenie Merkle dla puli prywatności i asercje po transakcji jako wywołania zwane „ramkami”.
Oficjalna specyfikacja projektu definiuje transakcję ramkową jako sekwencję wywołań kontraktów. Różne ramki mogą walidować transakcję, zatwierdzać jej opłatę za gaz lub wykonywać operacje użytkownika. Propozycja obecnie przewiduje trzy tryby: DEFAULT, VERIFY i SENDER.
Ramka VERIFY może sprawdzać, czy wymagany warunek jest spełniony. Ramka SENDER wykonuje operację z konta zidentyfikowanego jako nadawca transakcji. Ramki mogą być również grupowane w atomowe partie, co oznacza, że każda operacja w partii kończy się sukcesem razem lub cała grupa jest wycofywana.
Propozycja nadal definiuje podstawową kopertę transakcyjną zawierającą pola takie jak identyfikator łańcucha, nonce, nadawca, opłaty, podpisy i listę ramek. Punkt Chianga jest węższy: deweloperzy mogą być w stanie wprowadzić więcej funkcjonalności poprzez nowe cele ramek i wzorce wywołań bez tworzenia kolejnego formatu koperty dla każdej funkcji.
Stabilna koperta może zmniejszyć prace koordynacyjne
Zmiana koperty transakcyjnej Ethereum wpływa na więcej niż tylko klienty wykonawcze. Portfele, sieci warstwy 2, eksploratory bloków, urządzenia do podpisywania, biblioteki oprogramowania i dostawcy infrastruktury muszą zrozumieć nowy format.
Chiang powiedział, że aktualizacje Ethereum odbywają się mniej więcej co dziewięć miesięcy, co sprawia, że powtarzające się zmiany koperty są powolne i wymagają dużej koordynacji. Wystarczająco ogólny format ramek może służyć jako stabilny interfejs, podczas gdy kontrakty lub wyznaczone komponenty protokołu zapewniają nowe metody walidacji.
To nie oznacza, że przyszłe funkcje nigdy nie będą wymagać aktualizacji sieci. Sam EIP-8141 zmienia zasady konsensusu Ethereum i wymaga implementacji klienta. Nowe opkody, prekompilacje lub zasady dotyczące gazu mogą również wymagać hard forków. Proponowaną korzyścią jest to, że deweloperzy nie musieliby koniecznie przeprojektowywać kontenera transakcyjnego za każdym razem.
Specyfikacja EIP-8141 wymienia natywną abstrakcję konta wśród swoich głównych celów. Może wspierać rotację kluczy, alternatywne systemy podpisów, sponsorowane opłaty za gaz i grupowanie transakcji. Ma również na celu zmniejszenie zależności kont Ethereum od systemu podpisów secp256k1 używanego przez konwencjonalne konta zewnętrzne.
Jak donosi crypto.news w swoim artykule o proponowanym przez Vitalika Buterina przeprojektowaniu transakcji Ethereum, programowalna walidacja mogłaby w końcu pomóc Ethereum w przyjęciu nowych systemów uwierzytelniania bez zastępowania jednego stałego schematu podpisu innym.
EIP-8130 może ułatwić inspekcję ramek
Chiang przyznał również, że istnieje pewien kompromis. Wysoce abstrakcyjne transakcje mogą stać się trudne do analizy dla portfeli, sekwencerów i innej infrastruktury przed wykonaniem. Na przykład sekwencer warstwy 2 może chcieć akceptować tylko określone metody podpisu, ponieważ ich koszty obliczeniowe są przewidywalne.
Deweloperzy badają zatem, jak ramki mogłyby współpracować z EIP-8130, kolejnym projektem propozycji abstrakcji kont. EIP-8130 tworzy łańcuchowy magazyn kluczy, w którym konta rejestrują aktorów i kontrakty uwierzytelniające. Transakcje jednoznacznie określają swoją metodę uwierzytelniania.
Taka struktura pozwala węzłowi określić, który proces walidacji wymaga transakcja przed uruchomieniem dowolnego kodu portfela. Zgodnie z proponowanym profilem warstwy 2 EIP-8130, łańcuch mógłby ograniczyć swoją ścieżkę transakcyjną do kanonicznego zestawu uwierzytelniaczy o stałym koszcie, pozostawiając inne metody uwierzytelniania dostępne poprzez zwykłe wykonanie EVM.
Chiang powiedział, że EIP-8130 mógłby narzucić określone struktury na ramki EIP-8141. Współpraca mogłaby zachować elastyczność ramek, jednocześnie zapewniając portfelom i łańcuchom o wysokiej przepustowości bardziej czytelny format transakcji. Połączony projekt nie został sfinalizowany, a obie specyfikacje pozostają otwarte na zmiany.
Wcześniejsze doniesienia crypto.news analizowały konkurencję między EIP-8141 a EIP-8130 podczas początkowego procesu ustalania zakresu Hegotá. Najnowsze komentarze sugerują, że deweloperzy szukają obecnie kompatybilnych elementów, zamiast traktować propozycje wyłącznie jako wzajemnie wykluczające się alternatywy.
Buterin łączy ramki z równoległą walidacją
Vitalik Buterin rozwinął kierunek techniczny w osobnym poście, rozróżniając „akcje” i „zależności” transakcji. Akcja zmienia stan Ethereum, na przykład przeniesienie ETH. Zależność to warunek, który musi być spełniony, taki jak podpis, dowód Merkle'a lub dowód wiedzy zerowej.
Buterin argumentował, że niezależne zależności mogłyby być sprawdzane równolegle. Warunki, które nie uzyskują dostępu do stanu Ethereum, mogłyby być potencjalnie przetwarzane raz przez mempool zamiast być powtarzane podczas wykonania. Wiele kontroli mogłoby ostatecznie być reprezentowanych przez rekurencyjny dowód STARK, chociaż pozostaje to kierunkiem badań, a nie zatwierdzoną funkcją.
Rozróżnienie to mogłoby również pomóc klientom oddzielić przewidywalne transakcje od operacji wymagających pełnego dynamicznego środowiska wykonawczego Ethereum. Buterin stwierdził, że bardziej statycznie analizowalna aktywność mogłaby otrzymać niższe koszty gazu i skalować się dalej. Żaden taki harmonogram opłat nie został zatwierdzony.
Model ramek zapewnia potencjalny interfejs dla tego podejścia, ponieważ walidacja i wykonanie pojawiają się jako identyfikowalne wywołania. Ethereum zachowałoby elastyczne wykonywanie kontraktów, jednocześnie pozwalając prostszym transakcjom na deklarowanie większej ilości informacji o ich wymaganiach.
EIP-8141 jest zaplanowany, ale daty pozostają otwarte
Oficjalny Hegotá Meta EIP wymienia obecnie Frame Transactions i FOCIL jako zaplanowane do włączenia w aktualizacji Hegotá Ethereum. Oznacza to silniejszy status niż wcześniejsze rozważania, ale nie zamraża obecnego projektu technicznego EIP-8141.
EIP-8141 pozostaje oznaczony jako projekt propozycji Core. Jego autorzy mogą zmieniać tryby ramek, obsługę podpisów, rozliczanie gazu i relację z EIP-8130 w miarę kontynuacji prac nad implementacją. Dokument Hegotá pozostawia również pola aktywacji Sepolia, Hoodi i mainnet puste.
Kolejne mierzalne kroki obejmują zaktualizowane specyfikacje, implementacje klientów wykonawczych, sieci deweloperskie oraz testy interoperacyjności z portfelami i systemami warstwy 2. Deweloperzy muszą również zbadać ryzyko ataków typu denial-of-service na mempool, ponieważ programowalna walidacja może sprawić, że odrzucanie nieprawidłowych transakcji będzie bardziej kosztowne obliczeniowo.
Testowanie określi, czy proponowane połączenie elastycznych ram i strukturalnych uwierzytelniaczy może spełnić potrzeby warstwy bazowej Ethereum i szybszych łańcuchów EVM. Do czasu opublikowania parametrów aktywacji, EIP-8141 pozostaje zaplanowaną, ale niedokończoną częścią Hegotá.
