Autor: Shijunjun
Przedmowa
Artykuł ten jest podzielony na dwa główne moduły:
W pierwszej połowie, począwszy od pierwszej propozycji AA w 2015 r., będziemy systematycznie porządkować główną treść dotychczasowych propozycji EIP. Mamy nadzieję poznać historię historycznych propozycji AA i kompleksowo ocenić zalety i wady każdego planu.
W drugiej połowie skupiamy się na porównaniu opinii na temat pogorszenia koniunktury na rynku, przed którym stanął EIP4337 po jego zaproponowaniu, a następnie przeprowadziliśmy dogłębną analizę EIP7702, która wkrótce zostanie uwzględniona w kolejnej wersji aktualizacji Ethereum wniosek zostanie połączony, całkowicie zmieni to formularz wniosku w łańcuchu.
EIP-7702 zawiera epokowe zmiany. Zapraszamy do zapoznania się ze szczegółowym wyjaśnieniem pana Shishi
1. Abstrakcyjne tło konta
1.1 Znaczenie abstrakcji konta
Vitalik, założyciel Ethereum, pod koniec 2023 roku po raz kolejny zaktualizował mapę drogową rozwoju ETH, ale ustawienia abstrakcji kont nie uległy zmianie. Dzisiejszy mainstreamowy model również wszedł w kolejny etap z EIP-4337, VoluntaryEOA Conversion (dobrowolna konwersja konta EOA).
https://x.com/VitalikButerin/status/1741190491578810445
Ponad rok od premiery EIP4337 (1 marca 2023 na WalletCon w Denver oficjalnie ogłoszono, że podstawowy kontrakt ERC-4337 zaprojektowany i wdrożony przez deweloperów Ethereum Foundation przeszedł audyt OpenZeppelin i jest uważany za oficjalne uruchomienie węzła historii).
Zawsze cieszył się powszechnym uznaniem wśród użytkowników, ale nie był powszechnie stosowany w tak sprzecznym otoczeniu rynkowym, postęp EIP-7702 był bardzo zaawansowany i potwierdzono nawet, że zostanie on uwzględniony w następnej aktualizacji.
1.2 Aktualny stan rynku abstrakcji kont
Bez zbędnych ceregieli, spójrzmy tylko na dane.
Po półtora roku rozwoju EIP4337 ma tylko 12 milionów adresów w zbiorze kont sieci głównego nurtu. Najbardziej zaskakujące jest to, że w sieci głównej Ethereum są tylko 6764 aktywne adresy. Może coś jest nie tak z wymiarem statystycznym , ale przynajmniej Istnieje ogromna różnica pomiędzy liczbą adresów w EOA i CA. Musisz wiedzieć, że liczba niezależnych adresów w sieci głównej Ethereum sięgnęła 270 milionów (źródło danych: https://etherscan.io/chart/. adres).
Można powiedzieć, że EIP4337 nie ma istotnego rozwoju w sieci głównej.
(Źródło danych wykresu: https://dune.com/niftytable/account-abstraction)
Nie przyćmiewa to jednak istotnej wartości AA, ponieważ od samego początku projektowania EIP4337 było przeznaczone, że nie będzie on dobrze sobie radził w obliczu poważnych problemów z kompatybilnością w przód w sieci głównej, więc wraz z rozwojem różnych Łańcuchy warstwy L2 Powszechnie osadzone w natywnym AA, liczba adresów EIP4337 eksplodowała na L2. Miesięczna liczba aktywnych użytkowników łańcuchów podstawowych i wielokątnych w lipcu wyniosła odpowiednio 1 milion i 3 miliony, co jest dość imponujące.
Nie jest więc tak, że projekt EIP4337 jest błędny. Ma on wiele zalet. Za chwilę będziemy to systematycznie podsumowywać. Obecna sytuacja wynika z różnic pomiędzy siecią główną a L2. Trzeba zastosować własne, odpowiednie rozwiązania .
2. Jaka jest abstrakcja konta?
Abstrakcja konta brzmi zagmatwana, ale w istocie rozwiązuje problem rozdziału praw majątkowych.
W architekturze EVM istnieją dwa rodzaje kont (tj. maszyna wirtualna Ethereum), konto zewnętrzne (EOA) i konto kontraktowe (konto kontraktowe). Prawa własności i podpisu konta zewnętrznego są w rzeczywistości własnością tej samej osoby jednostka. Osoba posiadająca klucz prywatny ma nie tylko „własność” konta, ale ma również prawo „podpisać i przenieść wszystkie aktywa”.
Decyduje o tym struktura transakcji konta Ethereum
Jak widać ze struktury na poniższym rysunku, w standardowych transakcjach Ethereum nie ma strony Od. Zatem jaki adres konkretnie pochłonął środki? W rzeczywistości adres From jest dekodowany poprzez jego parametr VRS (tj. podpis użytkownika).
Obejmuje to szyfrowanie asymetryczne, takie jak ECDSA, jednokierunkową funkcję progową i inne koncepcje. Krótko mówiąc, kryptografia służy do zapewnienia bezpieczeństwa. Oczywiście spowodowało to również dylemat adresowy EOA w zakresie obecnych praw własności połączenie.
Podstawowym efektem EIP4337 jest dodanie pola Adres nadawcy do pola transakcji, oddzielając w ten sposób klucz prywatny od obsługiwanego adresu.
Dlaczego więc rozdział praw własności jest tak ważny?
Ponieważ projekt konta zewnętrznego (EOA) spowoduje więcej problemów:
Klucze prywatne są trudne do ochrony: utrata kluczy prywatnych przez użytkowników (utrata, atak hakerski, złamanie szyfrowania) oznacza utratę całego majątku.
Niewiele algorytmów podpisów: Protokół natywny może używać wyłącznie algorytmów podpisu ECDSA i weryfikacji podpisu do weryfikacji transakcji.
Wysoki autorytet podpisu: nie ma natywnego multipodpisu (wielopodpis może współpracować tylko za pośrednictwem inteligentnych kontraktów), a każdą operację można wykonać za pomocą jednego podpisu.
Opłaty transakcyjne można uiszczać wyłącznie za pośrednictwem ETH, a transakcje zbiorcze nie są obsługiwane.
Wyciek prywatności transakcji: transakcje indywidualne ułatwiają analizę prywatnych informacji posiadacza konta.
Ograniczenia atrakcyjności utrudniają zwykłym użytkownikom korzystanie z Ethereum:
Po pierwsze, aby korzystać z dowolnej aplikacji na Ethereum, użytkownicy muszą posiadać Ethereum (i ponosić ryzyko wahań cen Ethereum).
Po drugie, użytkownicy muszą radzić sobie ze złożoną logiką kosztów. Pojęcia ceny gazu, limitu gazu i blokowania transakcji (zamówienie jednorazowe) są dla użytkowników zbyt skomplikowane.
Wreszcie, chociaż wiele portfeli lub aplikacji typu blockchain próbuje poprawić komfort użytkownika poprzez optymalizację produktu, ich rzeczywiste efekty są minimalne.
Dlatego sposobem na przełamanie tej sytuacji jest wdrożenie abstrakcji konta i oddzielenie praw własności (Właściciel) od praw do podpisu (Signer), tak aby powyższe problemy można było rozwiązać jeden po drugim.
Tak naprawdę planów historycznych jest wiele i docelowo zbiegną się one w dwie trasy.
3. Przejrzyj historię propozycji AA
Wydaje się, że istnieje wiele propozycji rozwiązania tego problemu w ramach EIP, ale w ostatecznym rozrachunku istnieją dwie główne koncepcje. Dlatego też kwestie rozpatrywane w każdym EIP, które nie zostały zatwierdzone w przeszłości, złożyły się na rozwiązanie obecnego planu.
3.1 Pierwsza metoda polega na zmianie adresu EOA na adres CA
Już 15 listopada 2015 r. w związku z EIP-101 Vitalik zaproponował nową strukturę wykorzystującą umowy jako konta. Zmień adres na tylko kod i miejsce do przechowywania, zmień opłatę manipulacyjną, aby obsługiwać płatność przez ERC20, zmień natywny token na podobny do ERC20, aby zaoszczędzić saldo poprzez wstępnie skompilowaną umowę (może mieć funkcje takie jak autoryzacja wstrzymania), usprawnij pola transakcji tylko do, gazu startowego, danych i kodu.
Teraz wydaje się, że jest to po prostu zmiana w stylu Wielkiego Skoku, która znacząco zmieni podstawowy projekt, tak aby każdy adres konta miał własną logikę „kodu” (w rzeczywistości właśnie to próbuje teraz osiągnąć EIP-7702 ).
Można również wyprowadzić inne funkcje, np
Pozwól, aby transakcje korzystały z większej liczby algorytmów szyfrowania, a sposób weryfikacji podpisu może być określony przez wewnętrzny kod każdego adresu.
Jest odporny na ataki kwantowe, ponieważ kod ma cechy aktualizacji.
Niech Ethereum będzie miało te same cechy funkcjonalne co kontrakt ERC20, a głównym efektem będzie autoryzacja pobierania podatku, dzięki czemu nie będzie potrzeby tracić rodzimej waluty.
Ulepsz przestrzeń dostosowywania konta, kompatybilną z odzyskiwaniem społecznościowym, obsługą sbt, odzyskiwaniem kluczy itp.
Powód braku dalszego rozwoju jest również bardzo prosty. Jest oczywiste, że tempo jest zbyt duże. Jeśli chodzi o bieżący problem konfliktu hash transakcji i zagrożenia bezpieczeństwa, zostało ono odłożone na półkę z powodu niewystarczającego rozważenia koncepcji każdej korzyści stała się jedną z podstawowych funkcji kolejnych modeli EIP4337 i EIP7702.
Później pojawiło się szereg EIP próbujących ulepszyć tę logikę.
EIP-859: Abstrakcja konta głównego łańcucha – 30.01.2018
Próbując rozwiązać problem wdrożenia Kodu, podstawową funkcją jest to, że jeśli umowa strony transakcji nie zostanie wdrożona, parametry kodu dołączone do transakcji są wykorzystywane do wdrożenia portfela kontraktu. Po drugie, proponowany jest również nowy kod operacji PAYGAS. Oprócz płacenia za gaz staje się także transakcją. Separator pomiędzy częścią weryfikacyjną a częścią wykonawczą parametrów transakcji.
Chociaż wówczas zakończyło się to daremnie, stało się teraz jedną z podstawowych logiki EIP7702. Każda transakcja EIP7702 jest połączona ze specjalną strukturą transakcji i może towarzyszyć jej określony kod, dzięki czemu adres EOA ma możliwości kontraktowe. tę transakcję.
EIP-7702: Ustaw kod konta EOA 2024-05-07
Jest to również rdzeń EIP mechanizmu omawianego w dalszej części tego artykułu. EIP-7702 został opublikowany przez firmę Vitalik jako alternatywa dla EIP-3074 (2024-05-07). Dlatego EIP-3074 został porzucony i zdecydowano, że EIP-7702 zostanie włączony do nadchodzącego hard forku ETH Praga/Electra (Pectra). Poniżej rozwiniemy szczegóły.
3.2 Druga metoda polega na tym, aby adres EOA sterował adresem urzędu certyfikacji
EIP-3074: Dodaj kody operacji AUTH i AUTHCALL — 15.10.2020
Dodaj dwa nowe OpCodesAUTH i AUTHCALL do EVM, umożliwiając EOA wywoływanie innych kontraktów za pośrednictwem tych dwóch umów autoryzacji opcode zamiast tożsamości EOA.
Podsumowując, w połączeniu z poniższym rysunkiem EOA może wysłać podpisany komunikat (transakcję) do kontraktu, któremu ufa (zwanego Invokerem). Ten kontrakt Invoker może używać kodów operacji AUTH i AUTHCALL w celu zastąpienia tego EOA i wysłania tej transakcji.
EIP-4337: Używanie puli pamięci transakcyjnej do implementacji abstrakcji kont — 29.09.2021
Krótko mówiąc, jego projekt został zainspirowany MEV, a jego podstawową wartością jest to, że można całkowicie uniknąć zmian w protokołach warstwy konsensusu.
eip4337 zaproponował nowy obiekt transakcji UserOperation. Użytkownik wysyła ten obiekt do puli pamięci, a pakiety pakują i dostarczają kontrakt partiami z wymiaru górnika w celu wykonania transakcji. Zasadniczo podstawowe operacje na transakcjach i kontach są ściągane do poziom kontraktu do wykonania.
EIP-5189: Obsługa rachunków abstrakcyjnych za pośrednictwem indosantów — 29.06.2022 r
Można to uznać za optymalizację logiki EIP4337. W obliczu złośliwego Bundlera ustanawia on mechanizm zatwierdzania kar finansowych, aby zapobiec atakom blokującym DoS.
3.3 Inne propozycje wsparcia AA
EIP-2718: Zawijanie kopert dla nowych typów transakcji — 2020-06-13
Jest to ostateczna propozycja, która definiuje nowy typ transakcji jako kopertę dla nowych typów transakcji w przyszłości.
Efektem netto jest to, że po wprowadzeniu nowego typu transakcji stosowane jest specjalne kodowanie w celu rozróżnienia, jaki to jest typ transakcji, tak że wymagana jest jedynie kompatybilność wsteczna, a nie kompatybilność w przód. Najczęstszym przykładem jest EIP1559, który różnicuje opłaty transakcyjne i wykorzystuje nowe kody typów transakcji bez wpływu na pierwotny, dotychczasowy typ transakcji.
EIP-3607: Wyłącz adresy EOA na potrzeby wdrożenia kontraktu — 2021-06-10
Jest to rozwiązanie uzupełniające na ścieżce AA, mające na celu zapobieganie konfliktom między adresami wdrożenia kontraktu a adresami EOA. Będzie kontrolował sposób generowania kontraktu, aby system nie pozwolił na wdrożenie kodu pod adresem, który jest już adresem EOA. Ryzyko to jest w rzeczywistości bardzo małe. W końcu adres Ethereum ma długość 160 bitów. Chociaż istnieje metoda wykorzystania klucza prywatnego do kolizji z kluczem prywatnym określonego adresu kontraktu, w przypadku pełnego adresu zajmie to jeszcze rok. moc obliczeniowa Bitcoina.
3.4 Jak rozumieć proces rozwoju abstrakcji kont?
Najpierw musisz zrozumieć wartość konwersji na CA
Zasadniczo jest to rzeczywisty efekt EIP-4337, może to osiągnąć
Jednak podstawową wadą EIP-4337 jest to, że narusza zasady ludzkiej motywacji.
Wydaje się, że jest lepiej, ale popadło w niekończący się cykl rozwoju rynku. Wiele Dappów nie jest kompatybilnych, więc użytkownicy nie chcą używać adresów CA, a nawet korzystanie z CA wiąże się z wyższymi kosztami transakcji (zwykłe scenariusze transferu będą również wiązać się z opłatami transakcyjnymi). double), a także w zbyt dużym stopniu opiera się na kompatybilności samego Dapp.
Dlatego też nie został on dotychczas spopularyzowany w głównej sieci Ethereum.
Koszt jest najważniejszym kryterium dla użytkowników i należy je redukować.
Jednak aby naprawdę zredukować GAS, samo Ethereum musi przeprowadzić aktualizację soft fork, zmodyfikować obliczenia GAS lub zmodyfikować zużycie GAS przez kod operacyjny i inne moduły. Jednakże, skoro wymagany jest soft fork, dlaczego nie rozważyć bezpośrednio EIP-7702?
4. Kompleksowa analiza EIP-7702
4.1 Co to jest EIP-7702
Wyróżnia się nowymi rodzajami transakcji, co pozwala EOA tymczasowo pełnić funkcję inteligentnego kontraktu w pojedynczej transakcji, wspierając tym samym transakcje wsadowe, transakcje bezgazowe, zarządzanie uprawnieniami celnymi itp. w biznesie, bez konieczności wprowadzania nowy opCode EVM (wpływający na kompatybilność w przód).
Pozwala użytkownikom uzyskać większość możliwości AA bez wdrażania inteligentnych kontraktów, a nawet może zapewnić stronie trzeciej możliwość inicjowania transakcji w imieniu użytkowników. Nie wymaga od użytkowników podawania kluczy prywatnych, a jedynie informacji autoryzacyjnych podpisu.
4.2 Struktura danych
Zdefiniował nowy typ transakcji 0x04. TransactionPayload tego typu transakcji jest wynikiem serializacji kodowania RLP następującej treści
rlp([
chain_id, //Identyfikator łańcucha, używany do zapobiegania atakom polegającym na powtarzaniu.
nonce, // Licznik transakcji zapewniający niepowtarzalność transakcji.
max_priority_fee_per_gas, //1559 opłata transakcyjna
max_fee_per_gas, //1559 opłata transakcyjna
limit_gazu,
miejsce docelowe, //Adres docelowy transakcji
wartość,
dane,
access_list, //Lista dostępu używana do optymalizacji gazu w EIP-2929.
lista_autoryzacji,
podpis_y_parity, // 3 parametry podpisu, służące do weryfikacji podpisu transakcji.
podpis_r,
podpis_s
])
Ważne jest to, że dodany obiektauthorization_list przechowuje w swoim EOA kod, który podpisujący chce wykonać. Gdy użytkownik podpisuje transakcję, podpisuje także kod umowy do wykonania. Istnieje on w postaci dwuwymiarowej listy. wskazując, że wiele informacji o operacjach może być przechowywanych w partiach, wykonaj operacje wsadowe.
authorization_list = [[chain_id, adres, nonce, y_parity, r, s], ...]
4.3 Cykl życia transakcji
4.3.1 Faza weryfikacji
Na początku realizacji transakcji dla każdej [chain_id, adres, nonce, y_parity, r, s] krotki listy autoryzacji:
Użyj ecrecover, aby odzyskać adres podpisującego z podpisów r i s (zwróć uwagę, że jest to mechanizm samego Ethereum, więc ten EIP nie zmienia algorytmu podpisu). autorytet = ecrecover(keccak(MAGIC || rlp([chain_id, adres, nonce])), y_parity, r, s] (Podobnie jak w przypadku poprzedniego deszyfrowania podpisu w celu uzyskania adresu nadawcy, tutaj uzyskiwany jest podpis lokalny adres tej listy)
Zweryfikuj identyfikator łańcucha (powtórka łańcucha zapobiegająca rozwidleniu).
Sprawdź, czy kod urzędu podpisującego jest pusty lub został delegowany (sprawdź, czy transakcja jest prawidłową transakcją 7702, a mechanizm delegowania zostanie wykorzystany do późniejszej realizacji transakcji).
Sprawdź wartość jednorazową osoby podpisującej uprawnienia (aby zapobiec ponownemu odtwarzaniu podpisu urzędu).
Ustaw kod podpisującego urzędu na adres 0xef0100 || (używany do ominięcia polityki antykolizyjnej EIP3607).
Zwiększ wartość jednorazową osoby podpisującej (aby zapobiec częściowemu odtworzeniu podpisu).
Dodaj konto osoby podpisującej władzę do listy odwiedzanych adresów (przenieś gorące adresy, aby zmniejszyć opłaty za gaz za przechowywanie zapytań)
4.3.2 Faza operacji wykonania
Gdzie należy wykonać kod kontraktu i instrukcje operacyjne?
„Nowa” wersja zmienia jedynie zachowanie dotyczące wdrażania kodu.
Zamiast ustawiać kod konta na kod_kontraktu, pobiera adres kodu z listy_autoryzacji i ustawia ten kod jako kod konta.
Zatem, gdy konieczne jest wykonanie kodu autoryzacyjnego, kod jest ładowany z adresu podanego w polu adresowym listy_autoryzacji i wykonywany w kontekście konta osoby podpisującej.
Oznacza to, że kod umowy użytkownika jest faktycznie przechowywany pod określonym adresem w łańcuchu, a nie bezpośrednio uwzględniany w transakcji.
Instrukcje operacyjne i powiązane parametry są przechowywane w polu danych obciążenia transakcyjnego.
4.4 Jaka jest wartość EIP-7702?
Nastąpią zmiany w całym łączu portfela Web3, a doświadczenie użytkownika również ulegnie radykalnej zmianie, ponieważ zwykłe transakcje inicjowane przez EOA mogą również wykonywać różnorodne logiki podobne do umów, takie jak przelewy zbiorcze. W przypadku scenariuszy CeFi będzie to miało wpływ na identyfikację transakcji i opłaty za pobieranie wypłat.
Dzięki jego pojawieniu się przełamano wiele dotychczasowych stereotypów, jak np.:
Przerywa niezmiennik mówiący, że saldo konta może zostać zmniejszone jedynie przez transakcje pochodzące z tego rachunku.
Przerywa niezmiennik, zgodnie z którym wartość jednorazowa EOA wzrasta o 1 po rozpoczęciu wykonywania transakcji (możliwe zwiększenie wielu wartości jednocześnie).
Logika ochrony porównania tx.origin i msg.sender jest zepsuta, a wiele wcześniejszych umów jest zagrożonych.
Łamie status quo fakt, że EOA sama nie może wydawać zdarzeń. Konieczne może być zwrócenie uwagi na identyfikację i monitorowanie niektórych zdarzeń w łańcuchu.
Łamie status quo, zgodnie z którym adresy EOA muszą pomyślnie zaakceptować ERC20, 721, 1155 i inne zasoby (może to się nie powieść ze względu na mechanizm wywołania zwrotnego)
4.5 Porównanie EIP-7702 i EIP-4337
1. Zalety EIP-7702
Gaz jest niższy, ponieważ nie ma potrzeby przechodzenia przez moduł punktu wejścia, co ogranicza liczbę operacji w łańcuchu.
Koszty migracji użytkowników są niższe i nie ma potrzeby wcześniejszego wdrażania kontraktów on-chain jako przedmiotu.
W porównaniu z Eip4337 nastąpi również wykonanie delegacji kodu i będą również dwie metody:
Pełna delegacja
Pełna delegacja oznacza delegowanie wszystkich uprawnień do operacji na konkretny adres. Na przykład użytkownicy mogą delegować prawa do zarządzania wszystkimi tokenami ERC-20 na adres inteligentnego kontraktu, dzięki czemu ten inteligentny kontrakt będzie mógł wykonywać wszystkie powiązane operacje w imieniu użytkownika.
Delegacja chroniona
Delegacja chroniona odnosi się do dodania pewnych ograniczeń i środków ochronnych podczas procesu delegowania w celu zapewnienia bezpieczeństwa i możliwości kontrolowania operacji delegowania.
Na przykład użytkownicy mogą przekazać inteligentnemu kontraktowi zarządzanie tylko częścią tokenów ERC-20 lub ustawić pewne ograniczenia (takie jak wydawanie maksymalnie 1% całkowitego salda dziennie).
2. Wady EIP-7702
Jego podstawową wadą jest to, że jest to aktualizacja typu soft fork, która wymaga zgody wszystkich, aby ją promować, a zmiany są ogromne, co będzie miało szeroki wpływ na ekologię łańcucha. Na podstawie wstępnej oceny Czternastego Króla są następujące wyzwania, ale wyzwania te są także szansami rynkowymi:
Stopień swobody jest niezwykle wysoki i trudno go kontrolować. Użytkownicy będą potrzebować bardziej niezawodnych portfeli, aby zapewnić ochronę.
Oryginalna struktura uległa zbyt dużym zmianom, mimo że wyróżnia się różnymi rodzajami transakcji, wielu infrastruktur, zwłaszcza niezmiennych kontraktów w łańcuchu, nie można bezpośrednio dostosować.
Możliwości kontraktowe są dostępne dla adresów EOA, ale nie można zachować odpowiadającej im przestrzeni dyskowej.
Koszt oddzielnej transakcji jest nieco wyższy, ponieważ część danych połączeń zostanie znacznie zwiększona. Szacowany całkowity koszt połączenia wyniesie 16 (gaz) * 15 (bajty) = 240 (gaz) koszt danych połączenia plus koszt EIP-. 3860 2 * 15 = 30 plus przybliżony koszt czasu działania wynoszący 150. Dlatego samo przygotowanie konta, nawet jeśli nic nie zrobisz, zwiększy gaz o 500.
„Jeśli odbiorca podpisze kod bez otrzymania funkcjonalności, nadawca może spotkać się z DoS podczas próby wysłania zasobu”. Zobacz przypadek. Problem polega na tym, że EOA A podpisało coś, czego nie powinno - odtwarzalny plik z niewłaściwą konfiguracją implementacji (brak funkcji odbierania ()).
Logika wypłat w łańcuchu może być niespójna. Na przykład podczas przesyłania tokenów ERC-20, jeśli konto odbiorcy ma kod, umowa tokena wywoła onERC20Received dla konta odbiorcy. Jeśli onERC20Received przywróci lub zwróci niepoprawną wartość, transfer tokenu zostanie przywrócony.
Ponadto, jeśli EOA może emitować zdarzenia, czy pojawią się jakieś problemy? Niektóre elementy infrastruktury mogą wymagać uwagi.
To tylko niektóre niedociągnięcia podsumowane przez Shishijun na podstawie aktualnej treści propozycji EIP7702 i odpowiadających jej oficjalnych dyskusji na forum. Ostatecznie należy to w pełni przeanalizować w oparciu o ostateczny kod implementacyjny.
Odniesienie jest następujące:
https://eips.ethereum.org/EIPS/eip-7702
https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923
https://github.com/ethereum/EIPs/pull/8527
5. Pełne podsumowanie tekstu
Ten artykuł wydaje się być bardzo długi, ale w rzeczywistości jego zawartość wynosi tylko około 6 tys. słów. Wiele wcześniejszych interpretacji EIP z nim związanych można rozszerzyć za pomocą linków w artykule, więc nie będę do niego wracać.
Obecnie abstrakcję konta można rzeczywiście umieścić tylko w szóstym module, który ma wszystko naprawić, czyli jest już w końcu wdrażany. Teraz, gdy postęp EIP7702 został znacznie przyspieszony, przyniesie to więcej wyzwań dla bezpieczeństwa systemu. Można się spodziewać, że w końcu zda sobie z tego sprawę. Przecież mogą nastąpić przełomowe wydarzenia, takie jak fuzja Ethereum i modyfikacja algorytmu konsensusu, więc co z nowymi rodzajami transakcji?
Ale tym razem było za dużo subwersji, złamanie niemożliwych, ukrytych zasad w wielu łańcuchach i złamanie logiki aplikacji większości Dappów. Jednak zdecydowanie skupiono się na sednie, czyli niższych kosztach dla użytkowników. Rozumiem! W porównaniu z prawie dwukrotnie większym kosztem transakcji w przypadku EIP4337.
Sam użytkownik nadal jest adresem EOA i steruje logiką CA i korzysta z niej tylko wtedy, gdy jest to potrzebne, więc koszt utrzymania jest niski. Nie ma potrzeby konwertowania tożsamości urzędu certyfikacji w łańcuchu przed wykonaniem operacji, co oznacza, że użytkownicy nie muszą się rejestrować.
Użytkownicy mogą z łatwością korzystać z EOA w celu jednoczesnej realizacji wielu transakcji, np. autoryzacji potrącenia i realizacji potrącenia w jednym, co zmniejsza koszty transakcji dla użytkowników. W przypadku Dapps, szczególnie tych, które wymagają zarządzania stronami projektu na poziomie przedsiębiorstwa w łańcuchu, takich jak giełdy , dokonali przełomowych optymalizacji. Po zrealizowaniu agregacji partii w pierwotnej ekologii, podstawowy koszt wymiany można w jednej chwili obniżyć o ponad połowę, co ostatecznie może przynieść korzyści użytkownikom.
Dlatego też, choć wiele się zmieniło, wymiar kosztów jest wart zbadania i adaptacji przez wszystkich Dappów, bo tym razem użytkownicy muszą stanąć po stronie EIP7702.