Deweloperzy Ethereum i Base zakończyli prace nad wspólnym standardem abstrakcji kont po nieudanych próbach pogodzenia EIP-8141 i EIP-8130, pozostawiając obie sieci w dążeniu do odrębnych projektów transakcji.
Podsumowanie
- Deweloperzy Ethereum i Base zakończyli wysiłki mające na celu dostosowanie EIP 8141 i EIP 8130 po niepowodzeniu uzgodnienia wspólnego projektu abstrakcji kont.
- Ethereum priorytetowo traktuje odporność na cenzurę, prywatność i bezpieczeństwo, podczas gdy Base koncentruje się na skali, personalizacji i zgodności.
- EIP 8141 został oznaczony jako propozycja, która musi zostać wdrożona w ramach aktualizacji Hegotá Ethereum, podczas gdy Base będzie kontynuować rozwój EIP 8130 osobno.
- Deweloperzy portfeli mogą potrzebować obsługi dwóch natywnych formatów transakcji, jeśli obie propozycje zostaną ostatecznie wdrożone.
Deweloper Ethlabs Derek Chiang powiedział w poniedziałek, że autorzy obu propozycji przestali pracować nad wspólną specyfikacją w zeszłym tygodniu po odkryciu, że dostępne opcje techniczne wymagałyby, aby Ethereum lub Base poszły na kompromis w zakresie kluczowych wymagań.
Obie propozycje mają na celu uproszczenie interakcji użytkowników z portfelami kryptowalutowymi, w tym umożliwienie transakcji bez konieczności posiadania przez użytkowników ETH na opłaty za gaz oraz obsługę metod uwierzytelniania, takich jak klucze dostępu w telefonie. Zespoły badały, czy jeden projekt mógłby obsłużyć Ethereum Warstwę 1 i Base Warstwę 2.
„Chociaż zidentyfikowaliśmy szereg rozwiązań technicznych, wszystkie wymagały, aby jedna lub druga strona poszła na przynajmniej niewielki kompromis w zakresie swoich głównych celów” – powiedział Chiang. „Więc rozeszliśmy się, przenosząc ciężar na portfele, aby poradziły sobie z wynikającą z tego fragmentacją”.
Deweloperzy Ethereum priorytetowo traktują odporność na cenzurę, prywatność i bezpieczeństwo, podczas gdy Base koncentruje się na skali, personalizacji i zgodności, według Chianga. Różnice ostatecznie uniemożliwiły zespołom ustalenie jednego formatu transakcji.
Plany abstrakcji kont Ethereum i Base rozdzieliły się
Decyzja pozostawia deweloperów portfeli w obliczu możliwości obsługi dwóch natywnych formatów transakcji, jeśli EIP-8141 i EIP-8130 oba wejdą do produkcji.
Chiang powiedział, że portfele mogą nadal zapewniać użytkownikom spójne doświadczenie pomimo różnic technicznych między sieciami, w zależności od tego, jak deweloperzy poradzą sobie z odrębnymi standardami.
„Jeśli wykonają to dobrze i jeśli społeczność portfeli zdoła pokonać fragmentację, możemy ostatecznie uzyskać najlepszy możliwy UX dla użytkowników końcowych” – powiedział.
Wynik zmienia kierunek, o którym deweloperzy dyskutowali zaledwie kilka dni wcześniej. 7 września crypto.news wcześniej informował, że deweloperzy EIP-8141 badali zgodność z EIP-8130, pracując nad sposobami utrzymania programowalności transakcji przy jednoczesnym ułatwieniu dostawcom infrastruktury inspekcji wymagań uwierzytelniania.
Na tym etapie Chiang powiedział, że EIP-8130 mógłby zapewnić zdefiniowane struktury wokół ram EIP-8141. Proponowane rozwiązanie miało na celu zachowanie programowalnego charakteru ram przy jednoczesnym zapewnieniu portfelom i sieciom o wysokiej przepustowości jaśniejszego formatu transakcji.
EIP-8130 wykorzystuje łańcuchowy magazyn kluczy, w którym konta mogą rejestrować zatwierdzone podmioty i kontrakty uwierzytelniające. Transakcje identyfikują metodę uwierzytelniania, której używają, pozwalając sieci określić wymagany proces walidacji przed wykonaniem kodu portfela.
EIP-8141 obiera inną drogę, strukturyzując transakcje jako programowalne wywołania kontraktów zwane ramami. Ramy mogą pełnić różne funkcje w ramach tej samej transakcji, w tym walidację, zatwierdzanie gazu i wykonanie.
Zespoły porzuciły teraz wysiłki mające na celu przekształcenie tych podejść w jeden standard.
EIP-8141 stał się propozycją Ethereum, która musi zostać wdrożona
Ethereum kontynuuje prace nad EIP-8141, czyli Frame Transactions, w ramach planowanej aktualizacji Hegotá.
Klaster Protokołu Fundacji Ethereum umieścił tę propozycję w kategorii „must-ship” na początku tego miesiąca, a materiał źródłowy stwierdza, że propozycja ma na celu uczynienie abstrakcji kont natywną dla Ethereum oraz poprawę bezpieczeństwa i gotowości post-kwantowej.
Frame Transactions dzielą transakcję na sekwencję programowalnych ramek. Jedna ramka może zweryfikować nadawcę, inna może autoryzować konto odpowiedzialne za gas, a kolejne ramki mogą wykonać działania żądane przez użytkownika.
Model ten pozwoliłby, aby konto inicjujące działanie i konto płacące za nie były różne.
Deweloperzy Ethereum już zaplanowali EIP-8141 dla Hegotá do 7 września. Główni deweloperzy przenieśli propozycję z „Considered for Inclusion” do „Scheduled for Inclusion” podczas rozmowy All Core Developers Execution 27 sierpnia, nadając Frame Transactions formalną pozycję w planowanej aktualizacji na 2027 rok, podczas gdy jej specyfikacja pozostawała w formie roboczej.
W proponowanym systemie aplikacja mogłaby pokryć opłatę transakcyjną użytkownika lub zorganizować, aby użytkownik zapłacił za pomocą innego aktywa, podczas gdy walidatorzy Ethereum nadal otrzymywaliby opłatę sieciową w ETH.
Struktura ta mogłaby usunąć powszechny wymóg portfela, zgodnie z którym użytkownicy posiadający stablecoiny lub inne tokeny nadal potrzebują ETH, zanim będą mogli dokonać transakcji.
Ramki mogą być również używane do grupowania transakcji. Powiązane działania mogłyby być zgrupowane tak, aby wszystkie zakończyły się sukcesem razem lub zostały odwrócone, gdy jedno z nich zawiedzie.
Na przykład handel tokenami może obecnie wymagać oddzielnej zgody pozwalającej aplikacji wydać tokeny przed wykonaniem samego handlu. Frame Transactions mogłyby umieścić powiązane działania w tej samej programowalnej strukturze transakcji.
Programowalne ramki rozszerzają kontrolę nad kontami Ethereum
EIP-8141 ma na celu przeniesienie większej części logiki walidacji konta do programowalnego kodu, zamiast wymagania, aby konwencjonalne konta Ethereum polegały na stałym procesie uwierzytelniania.
Propozycja opisuje swój stan końcowy jako taki, w którym „konto po prostu staje się adresem z kodem”.
Vitalik Buterin, współautor EIP-8141, opisał tę propozycję w lutym jako „omnibus, który podsumowuje i rozwiązuje każdy pozostały problem, który AA miał rozwiązać”.
5 września Buterin powiedział, że propozycja poczyniła „wiele ważnych postępów” w ciągu poprzednich miesięcy i zbliżała się do „optimum”.
Następnie deweloperzy odkryli, że kilka funkcji transakcji można wyrazić poprzez programowalne ramki EIP-8141 zamiast wielokrotnego rozszerzania koperty transakcji Ethereum.
Raport crypto.news z 7 września stwierdzał, że podejście to mogłoby obsłużyć wygaśnięcie transakcji, agregację podpisów, dowody prywatności i asercje po transakcji jako programowalne wywołania kontraktów. Frame Transactions nadal wymagałyby zmian w regułach konsensusu Ethereum, ale poszczególne funkcje mogłyby być budowane poprzez cele ramek i wzorce wywołań.
Programowalna walidacja mogłaby dać kontom większą kontrolę nad uwierzytelnianiem. EIP-8141 ma na celu obsługę funkcji, w tym alternatywnych systemów podpisów, sponsorowanych płatności za gas, grupowania transakcji i rotacji kluczy.
Ta sama architektura mogłaby pomóc kontom Ethereum odejść od zależności od systemu podpisów używanego przez konwencjonalne konta zewnętrznie posiadane. Użytkownik mógłby potencjalnie zmienić metodę uwierzytelniania kontrolującą konto bez przenoszenia aktywów na nowy adres.
Badacze Ethereum rozważali Frame Transactions dla Hegotá, zanim propozycja została formalnie zaplanowana. W sierpniu deweloperzy porównywali EIP-8141 z EIP-8130 jako konkurencyjne podejścia do natywnej abstrakcji kont, jednocześnie zawężając zakres aktualizacji na 2027 rok.
W tym czasie propozycje były częścią większego procesu selekcji dla Hegotá, obejmującego odporność na cenzurę, prywatność, wycenę gas, ekonomię walidatorów i skalowanie warstwy 1.
Badacze Ethereum niezależnie analizowali, w jaki sposób Frame Transactions mogą wspierać aplikacje skoncentrowane na prywatności. W sierpniowej propozycji omówiono samofinansujące się pule prywatności, w których programowalne płatności za opłaty mogłyby pozwolić puli prywatności na pokrycie własnego gazu zamiast polegać na zewnętrznym relayerze.
Praca ta łączyła Frame Transactions z innymi proponowanymi zmianami, w tym Keyed Nonces, Recent Roots i Transaction Assertions. Propozycja puli prywatności pozostała preferowanym pakietem badacza, a nie ostateczną decyzją głównych deweloperów Ethereum w tamtym czasie.
Base będzie kontynuować z EIP-8130
EIP-8130 sieci Base będzie teraz postępować oddzielnie od propozycji Frame Transactions Ethereum.
Projekt autorstwa Base łączy nowy typ transakcji z onchainowym „Keystore”, który rejestruje zatwierdzonych sygnatariuszy i authenticatorów dla konta. Ma on na celu obsługę niestandardowego uwierzytelniania, grupowania wywołań i sponsorowania gazu.
Chociaż obie propozycje dzielą kilka celów abstrakcji konta, ich struktury techniczne dają ich odpowiednim sieciom różne poziomy kontroli nad tym, jak transakcje są uwierzytelniane i przetwarzane.
Zanim zespoły się rozdzieliły, deweloperzy Ethereum próbowali ustalić, czy strukturalny system uwierzytelniania EIP-8130 można połączyć z programowalnymi ramkami EIP-8141 bez zmuszania sieci Layer 1 lub Layer 2 do rezygnacji z preferowanych właściwości.
Ethlabs wcześniej umieściło Frame Transactions wśród swoich głównych priorytetów dla aktualizacji Hegotá, wymieniając natywną abstrakcję konta obok odporności na cenzurę, szybszych bloków i ciągłego skalowania Layer 1.
Ponieważ wspólny wysiłek został teraz zakończony, EIP-8141 pozostaje planowaną przez Ethereum natywną ścieżką abstrakcji konta dla Hegotá, podczas gdy Base będzie kontynuować rozwój EIP-8130 wokół swojego odrębnego typu transakcji i onchainowego keystore.
