EIP-3074 stał się z dnia na dzień najgorętszym tematem, ponieważ został dopuszczony do włączenia do kolejnego hard forku Ethereum (Pectra/Petra). Jednak o co tyle szumu i jaki będzie to miało wpływ na Ethereum i ekosystem EVM? W tym artykule przyjrzymy się tej propozycji, odpowiemy na najczęściej zadawane pytania oraz rozwiejemy pewne mity i nieporozumienia. Zanurzmy się, dobrze?
Pobieranie rachunków Przegląd EIP/ERC
Aby lepiej zrozumieć pojęcie abstrakcji konta, musisz wiedzieć, że w 99% przypadków, gdy ktoś mówi „abstrakcja konta”, ma na myśli „konta inteligentne (kontraktowe)”, czyli wtedy, gdy konto jest oparte na kodzie umowy, a nie na pojedynczy klucz prywatny. Nadal można go uwierzytelnić za pomocą jednego klucza prywatnego, jak ma to miejsce w większości przypadków (jest to ważne później), ale może to być również portfel z wieloma podpisami, jak ma to miejsce w przypadku Bezpiecznego.
Pierwotne znaczenie „abstrakcji konta” polegało na „umożliwieniu inteligentnym kontraktom inicjowania transakcji”, ale od tego czasu zmieniono je na „wszystkie funkcje, które umożliwiają konta inteligentnych kontraktów”.
Konta oparte na inteligentnych kontraktach umożliwiają te i inne funkcje
Abstrakcja gazu: zdecentralizowane aplikacje sponsorujące gaz, użytkownik płacący za gaz w różnych tokenach ERC20 lub nawet płacący za gaz z góry, co jest świetne w przypadku wdrażania międzyłańcuchowego.
Jest to doskonałe rozwiązanie pod kątem prywatności i bezpieczeństwa operacji, ponieważ eliminuje konieczność ujawniania swoich danych osobowych poprzez proszenie znajomych o zasilenie konta za pomocą ETH MATIC, niezależnie od waluty natywnej łańcucha/konwersji, lub, co gorsza, wypłacanie środków z giełd.
Grupowanie transakcji: Lub łączenie wielu działań w jedną transakcję. Jest to fantastyczne zarówno dla bezpieczeństwa, jak i wydajności gazu.
Bezpieczeństwo: rozwiązywanie zatwierdzeń ERC-20. Jako efekt uboczny przetwarzania wsadowego możemy wykonać dokładną liczbę zatwierdzeń razem z każdą akcją, która wymaga jednego, dzięki czemu problem zatwierdzenia znika. Dlaczego? Ponieważ nie potrzebujemy nieskończonych/pozostałych zatwierdzeń i nie potrzebujemy drugiego podpisu dla zatwierdzenia.
Niestandardowa kryptografia: włączanie nowych krzywych kryptograficznych, WebAuthn, bezpieczna enklawa iOS, bezpieczeństwo kwantowe i wiele więcej.
Rotacja kluczy i odzyskiwanie konta: zmiana kluczy prywatnych dla istniejącego konta lub odzyskiwanie konta za pomocą schematów takich jak odzyskiwanie społecznościowe Argent
Czy zauważyłeś coś? Wszystkie one w jakiś sposób pomagają w bezpieczeństwie.
Powrót do ERC.
Ogólnie rzecz biorąc, wszystkie ERC związane z abstrakcją konta twierdzą, że te funkcje są ich motywacją, ale niekoniecznie je zapewniają; po prostu pomagają utorować drogę do upowszechnienia się tych funkcji.
Rozłóżmy to na czynniki pierwsze. Duże ERC rozwiązują różne problemy:
Inicjowanie transakcji: Możliwość inicjowania transakcji przez kontrakty.
Natywny: specjalny typ transakcji w protokole, który może pochodzić z inteligentnego kontraktu. Obejmuje ERC-2938, później zastąpiony przez RIP-7560
Emulated: ERC-4337 jest „emulowany” w tym sensie, że transakcje są faktycznie nadal inicjowane przez EOA. Nie oznacza to, że użytkownik musi być świadomy tego EOA. To EOA jest kontrolowane i obsługiwane przez bundler.
Konwersja istniejących użytkowników: tutaj właśnie wkracza EIP-3074 (i jego mniejszy odpowiednik, ERC-5003)
EIP-3074 umożliwia delegowanie kontroli ISTNIEJĄCEGO EOA do inteligentnego kontraktu. Inteligentny kontrakt może kontrolować to EOA i wykonywać połączenia z jego adresu, ale nie może inicjować transakcji. Jest to ważne, ponieważ nadal musimy rozwiązać problem inicjowania transakcji.
ERC-5003 umożliwia „pełną” konwersję EOA na konto inteligentnej umowy, dzięki unieważnieniu oryginalnego klucza prywatnego, który pełni funkcję klucza głównego dla tego EOA.
Podpisy: Kontrakty zazwyczaj nie mogą podpisywać podpisów. Ale w pewnym sensie mogą — mogą definiować logikę, która definiuje, co jest prawidłowym podpisem dla tego kontraktu. Na przykład portfel inteligentnego kontraktu, który jest multisig między Bobem i Alice, zdefiniuje prawidłowy podpis jako isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature). Musi to zostać zdefiniowane w kodzie kontraktu.
ERC-1271 definiuje interfejs umożliwiający realizację tej funkcji.
Norma ERC-6492 rozszerza ją o obsługę kont inteligentnych kontraktów, które nie zostały jeszcze wdrożone. Dzięki temu ten sam adres może bezproblemowo występować we wszystkich łańcuchach, a użytkownik nadal będzie mógł podpisywać wiadomości.
Aby oba rozwiązania działały, muszą zostać zaimplementowane przez zdecentralizowane aplikacje (dApps).
Aby naprawdę stworzyć doświadczenie AA, musisz rozwiązać wszystkie powyższe jednocześnie. Dlatego EIP-3074 nie konkuruje z ERC-4337, RIP-7560 ani żadnym innym abstrakcyjnym ERC konta.
Jeśli chcesz zobaczyć to wszystko wizualnie, polecamy ten slajd z wykładu na temat demistyfikacji AA ERC.
Obalanie mitów powszechnie spotykanych w EIP-3074
Zacznijmy od słonia w pokoju. Były trzy elementy FUD związane z EIP-3074:
Umożliwia złośliwym aplikacjom zdefraudowanie istniejących portfeli w jednej transakcji: To prawda, że taki podpis można wygenerować, ale nie ma powodu ani przypadku użycia, aby dostawca portfela kiedykolwiek pozwolił aplikacjom zdefraudować podpisanie takich żądań. Zabezpieczenie tego od strony portfela jest znacznie łatwiejsze niż zabezpieczenie samego klucza prywatnego, a wyciek klucza prywatnego ma ten sam efekt.
Konto zachowuje pojedynczy klucz główny (oryginalny klucz EOA). Istnieje dodatkowy klucz ERC, który rozwiązuje ten problem, EIP-5003, znany również jako AUTHUSURP, który umożliwia unieważnienie oryginalnego klucza prywatnego
EIP-3074 to plaster, który nie przynosi korzyści natywnego AA: EIP-3074 nigdy nie miał konkurować z rzeczywistymi propozycjami AA, takimi jak RIP-7560. Nie jest to plaster na AA; to ścieżka migracji. Nadal potrzebujemy natywnego AA, ponieważ, jak pamiętamy wcześniej, nie rozwiązuje on problemu inicjacji transakcji.
Zalety i wady EIP-3074
Zaleta: Tworzy bardzo prostą ścieżkę migracji dla obecnych użytkowników MetaMask, Trezor, Ledger itp., aby mogli zapoznać się z funkcjami abstrakcji konta na swoich istniejących kontach.
Wada: poświęca rotację kluczy. Podczas gdy wszystkie funkcje AA wymienione powyżej można włączyć, rotacja kluczy staje się nieco nieuchwytna, ponieważ oryginalny klucz prywatny zachowuje kontrolę nad kontem we wszystkich sieciach, które nigdy nie były używane, nawet z EIP-5003.
Ćwiczenie umysłowe
Oto ćwiczenie umysłowe, które pomoże ci zrozumieć ruchome części:
Istnieje EOA, аlice.eth (0x696969..69), w sieci głównej Ethereum. To EOA jest z definicji cross-chain, więc istnieje również we wszystkich rollupach i łańcuchach EVM.
Niniejsze EOA jest kontrolowane wyłącznie za pomocą klucza prywatnego A, należącego do Alicji.
EIP-3074 jest już dostępny.
Złośliwy dApp próbuje podszyć się pod Alice i prosi ją o podpisanie podpisu EIP-3074 AUTH, autoryzując złośliwy kontrakt. Portfel ignoruje to żądanie i rozłącza dApp, ponieważ jest dobrze zaimplementowany i nie ma przypadku użycia, aby kiedykolwiek na to zezwolić z dApp.
Alicja klika przycisk „włącz abstrakcję konta” u swojego dostawcy portfela (np. MetaMask, za pośrednictwem Snap lub Ambire, natywnie). Portfel podpisuje podpis EIP-3074 AUTH, autoryzując kontrakt utworzony przez dostawcę portfela, który pomaga w tworzeniu partii, sponsorowaniu gazu itp.
Kontrakt ten kontrolowany jest wyłącznie za pomocą klucza prywatnego A.
alice.eth jest teraz niezależnie kontrolowany przez dwa podmioty: klucz prywatny A (w trybie EOA) i nowy kontrakt, który sam w sobie jest również wyłącznie kontrolowany przez klucz prywatny A.
Alicja może teraz wykonywać operacje wsadowe, ale aby móc sponsorować gaz, dostawca portfela Alicji musi zaimplementować protokół ERC-4337 lub RIP-7560 (jeśli sieć to obsługuje) lub zastrzeżony przekaźnik, aby Alicja nie musiała używać swojego ETH (co jest ścisłym wymogiem sieci, jeśli chcesz zainicjować transakcję).
Alicja decyduje się na konwersję alice.eth na multisig, a dostawca portfela nakazuje kontraktowi unieważnienie klucza prywatnego A i autoryzację 2/2 multi-sig kluczy prywatnych BMobilePhone i BLaptop.
Jednak to nie zadziała, ponieważ klucz prywatny A nadal kontroluje Alice.eth: Zgodnie z EIP-3074 oryginalny klucz prywatny zachowuje kontrolę, mimo że został przekazany do kontraktu.
EIP-5003 zostaje uruchomiony w sieci Ethereum i umożliwia alice.eth wysłanie specjalnej instrukcji do sieci za pośrednictwem dostawcy jej portfela w celu cofnięcia kontroli nad kluczem prywatnym A.
alice.eth jest teraz pomyślnie konwertowany na multi-sig, ale tylko na Ethereum. Klucz prywatny A (należący do Alice) nadal zachowuje kontrolę nad alice.eth we wszystkich innych sieciach.
Ostatecznie dowiedzieliśmy się kilku rzeczy:
Dokonaliśmy czegoś niesamowitego, ponieważ bez EIP-3074 Alicja prawdopodobnie nigdy nie przyjęłaby abstrakcji konta.
EIP-3074 nie rozwiązuje wszystkiego. Nadal potrzebujemy ERC-4337 i RIP-7560 tak samo, jak potrzebowaliśmy wczoraj.
EIP-3074 nie współpracuje dobrze z rotacją kluczy, nawet jeśli mamy EIP-5003. Dlatego nadal potrzebujemy prawdziwych inteligentnych kont, aby ułatwić przypadki użycia, takie jak multi-sigs i rotacja kluczy.
Jako ciekawostkę dodam, że uważamy, że rotacja kluczy jest zbyt nowa dla większości i nieco zawiła w świecie międzyłańcuchowym, w którym nie ma tego samego stanu między wszystkimi rollupami i łańcuchami. Większość użytkowników wydaje się trzymać paradygmatu jeden klucz = jedno konto, szczególnie w przypadku portfeli sprzętowych, które są wystarczająco bezpieczne w większości przypadków użycia.
Często zadawane pytania
Pozostała część artykułu będzie miała formę przypominającą FAQ, co pozwoli nam lepiej odpowiedzieć na niektóre najczęstsze pytania.
Czy pomaga to MetaMask w osiągnięciu sukcesu?
Wierzymy, że firmy zajmujące się abstrakcją kont odniosą znacznie większe korzyści z łatwiejszego wdrażania UX niż firmy o ugruntowanej pozycji, które będą mogły oferować funkcje AA swoim obecnym odbiorcom.
Innymi słowy, „uwalnia” moc portfeli AA na całym rynku adresowalnym, a nie tylko na wczesnych użytkownikach chętnych do przeniesienia swoich środków na nowy adres.
Dzięki MetaMask Snaps wiele firm zajmujących się AA przejdzie na budowanie AA w oparciu o MetaMask, czyli galaktyczne pozycjonowanie mózgu, którego nikt, poza najbardziej spostrzegawczymi obserwatorami, nie przewidywał.
Czy samo przetwarzanie wsadowe jest niebezpieczne?
Absolutnie nie. Nadal widzisz, co podpisujesz. To, w połączeniu z symulacją transakcji, oznacza, że podpisywanie wielu akcji jest tak samo bezpieczne, a w większości praktycznych przypadków bezpieczniejsze, niż podpisywanie pojedynczej akcji.
Grupowanie transakcji jest jedną z najbardziej cenionych funkcji Abstrakcji Konta
Czy to pomaga dApps przyjąć AA? Czy rozwiązuje problemy ze zgodnością?
Aplikacje zdecentralizowane (dApps) działają z dowolną formą abstrakcji konta, z pewnymi wyjątkami:
Niektóre aplikacje zdecentralizowane dyskryminują konta inteligentne (kontraktowe)
Niektóre zdecentralizowane aplikacje nie obsługują standardu ERC-1271
EIP-3074 magicznie rozwiązuje oba problemy: konta pojawiają się jako EOA (nie mają kodu), więc nie można ich dyskryminować. Jeśli chodzi o podpisy, EOA z włączonym AA (za pośrednictwem 3074) nadal będą podpisywać się jako EOA, więc nie ma problemu. Magicznie zadziała ze wszystkimi aplikacjami zdecentralizowanymi kosztem utraty rotacji kluczy.
Jeśli jednak większość osób wybierze EOA z włączoną obsługą AA zamiast zwykłych kont inteligentnych, zniechęci to zdecentralizowane aplikacje do obsługi standardów ERC-1271 i ERC-6492, ale standard ERC-4337 już pomógł znacznie zwiększyć świadomość dotyczącą propozycji podpisów.
A co z unieważnieniem oryginalnego klucza?
Klucz można unieważnić za pomocą EIP-5003 (co nie jest jeszcze planowane w hard forku).
Jednym z niuansów jest to, że nie jest to idealne rozwiązanie w świecie międzyłańcuchowym. EOA zawsze będzie zaczynać się jako EOA w każdym nowym łańcuchu, którego zaczniesz używać, co oznacza, że oryginalnego klucza nigdy nie można naprawdę odwołać. Dotyczy to jednak każdej formy AA, ponieważ oryginalne uprawnienia/przywileje, z którymi utworzyłeś konto, są zawsze tymi, z którymi konto zaczyna w każdej nowej sieci.
EIP-3074 działa lepiej, wprowadzając wszystkie funkcje AA z wyjątkiem rotacji kluczy do istniejących EOA. Innymi słowy, jeśli zdecydujesz się włączyć AA dla EOA, na zawsze utkniesz z oryginalnym kluczem prywatnym za tym EOA.
Czy zabija rodzimy AA (RIP-7560)?
Nie, ponieważ nadal potrzebujesz rozwiązania, które umożliwi Ci zainicjowanie transakcji, przynajmniej jeśli chcesz zapłacić za gaz innym tokenem niż Twój natywny (lub potrzebujesz sponsora gazu).
ERC-4337 to jedno z takich rozwiązań, które nie wymaga uaktualnień protokołu (nie jest natywne), jednak natywne, wbudowane w protokół AA jest niezwykle cenne, ponieważ rozwiązuje problemy z narzutem gazowym i złożonością ERC-4337.
Ale co z EIP-7377?
EIP-7377 umożliwia konwersję EOA na inteligentne konto. Zamiast pozwalać inteligentnemu kontraktowi kontrolować EOA obok oryginalnego PK, ten EIP pozwala kontraktowi przejąć EOA w jednej transakcji.
Można go uważać za alternatywę dla EIP-3074 + EIP-5003, jednak nie zyskał aż tak dużego rozgłosu.
Myśli końcowe
EIP-3074 nie jest plastrem. Jest niezwykle optymistyczny dla przyszłości Ethereum i ekosystemu EVM, ponieważ proszenie użytkowników o nagłe porzucenie istniejących kont i przeniesienie wszystkich środków, pozycji stakingowych itp. na nowe konto (konto smart contract) znacznie podnosi barierę wejścia.
EIP-3074 zapewni nowe rozwiązanie pośrednie i stopniowe wdrażanie, a to jest dokładnie to, czego potrzebujemy, aby radykalnie poprawić UX.
Zainteresowany Ambire? Obserwuj nas:
Discord | X (Twitter) | Reddit | GitHub | Telegram | Facebook
