Współzałożyciel Ethereum, Vitalik Buterin, przedstawił 6 września długoterminowy model transakcyjny, który mógłby pozwolić sieci na przetwarzanie części prac walidacyjnych równolegle.
Podsumowanie
- Buterin zaproponował rozdzielenie akcji transakcyjnych od zależności, aby Ethereum mogło później optymalizować każdy komponent niezależnie.
- Zależności obejmują podpisy, dowody stanu i warunki ważności, które transakcje muszą spełnić przed rozpoczęciem wykonania.
- Czyste zależności mogłyby być sprawdzane raz przez mempool, a następnie kompresowane do rekurencyjnych dowodów STARK.
- EIP-8141 proponuje transakcje ramowe z programowalną walidacją, wykonaniem i płatnością gazu w jednym formacie transakcyjnym.
- Deweloperzy Ethereum nie zatwierdzili jeszcze EIP-8141 do aktualizacji mainnetu ani nie opublikowali dat wdrożenia.
Jego propozycja rozdziela efekty wywoływane przez transakcje od warunków, które muszą być spełnione, zanim te efekty mogą wystąpić.
Buterin opisał te dwa komponenty jako „akcje” i „zależności” w szczegółowym poście. Akcje zmieniają stan Ethereum, takie jak przesyłanie ETH lub wywoływanie kontraktu. Zależności obejmują informacje wymagane do ustalenia, że transakcja jest ważna.
Podpis cyfrowy jest jednym z przykładów zależności. Inne przykłady to dowody Merkle'a pokazujące, że niewydany wynik istnieje, dowody z wiedzą zerową oraz warunki stanu, które muszą pozostać prawdziwe, gdy transakcja wchodzi do bloku.
Buterin argumentował, że uczynienie tego rozróżnienia jawnym mogłoby pomóc Ethereum skalować się bez porzucania jego elastycznego środowiska wykonawczego. Jednak propozycja pozostaje częścią trwających badań protokołu. Deweloperzy Ethereum nie zatwierdzili pełnego projektu do wdrożenia.
Ethereum mogłoby przetwarzać zależności transakcyjne równolegle
Transakcje Ethereum obecnie łączą autoryzację, płatność opłat i wykonanie we wspólnym przepływie przetwarzania. Węzły sprawdzają, czy transakcja jest poprawnie podpisana, czy nadawca może za nią zapłacić i czy jej instrukcje wykonują się pomyślnie.
Niektóre z tych kontroli nie zależą od końcowych zmian stanu transakcji. Buterin powiedział, że takie zależności mogłyby być przetwarzane osobno i w wielu przypadkach jednocześnie.
Na przykład walidator może potrzebować potwierdzić podpis przed zaakceptowaniem transakcji. Ta weryfikacja nie musi czekać na niepowiązane podpisy dołączone do innych transakcji. Jeśli wiele niezależnych kontroli jest znanych z góry, klienci mogą rozdzielić pracę między dostępne zasoby przetwarzania.
Kontrole zależne od stanu wymagają większej ostrożności. Warunek związany z saldem konta lub slotem pamięci może stać się nieważny, jeśli wcześniejsza transakcja zmieni ten sam stan. Buterin powiedział, że mempooly mogłyby skuteczniej rozumować o tych warunkach, gdy transakcje deklarują, do których części stanu uzyskują dostęp.
To podejście nagradzałoby przewidywalne transakcje. Operacje, które jasno określają swoje zależności, mogłyby otrzymać niższe koszty gazu, ponieważ klienci mogliby je weryfikować wydajniej. Transakcje wymagające dynamicznych wywołań i nieprzewidywalnego dostępu do stanu pozostałyby możliwe, ale mogłyby kosztować więcej.
Buterin oszacował, że ponad 90% aktywności Ethereum pod względem wolumenu nie wymaga pełnego poziomu dynamicznej elastyczności sieci. Ta liczba jest jego oceną, a nie opublikowanym pomiarem sieci w poście. Szerszy argument jest taki, że typowe transfery i rutynowe interakcje z kontraktami mogłyby używać bardziej restrykcyjnych formatów bez ograniczania specjalistycznych aplikacji.
Proponowany model zachowałby elastyczny system kont Ethereum dla transakcji, które go potrzebują. Bardziej przewidywalna aktywność mogłaby używać statycznie analizowalnych struktur przypominających części modelu transakcyjnego Bitcoina.
Bitcoin używa modelu niewydanych wyników transakcji, w którym transakcja identyfikuje wyniki, które zamierza wydać. Ethereum zwykle używa kont z saldami, nonce i programowalnym magazynem kontraktów. Buterin nie proponuje, aby Ethereum zastąpiło swój model kont architekturą Bitcoina. Opisał spektrum łączące pomysły z obu systemów.
EIP-8141 zapewnia ogólne ramy transakcyjne
EIP-8141 to projekt propozycji ulepszenia Ethereum dla nowego typu transakcji znanego jako transakcja ramowa. Dzieli transakcję na ramki wywołań kontraktów, które mogą weryfikować uprawnienia, zatwierdzać płatność za gaz i wykonywać operacje użytkownika.
Oficjalna propozycja mówi, że ważność transakcji i płatność opłat nie będą już zależeć wyłącznie od standardowego podpisu dołączonego do zewnętrznej transakcji. Kod konta mógłby zamiast tego definiować niezbędne zasady autoryzacji i płatności.
Transakcje ramowe mogłyby wspierać opłaty sponsorowane, płatności w tokenach innych niż ETH, rotację kluczy i grupowanie transakcji. Mogłyby również pozwolić kontom zewnętrznym na korzystanie z funkcji abstrakcji kont bez polegania na tym samym wdrożeniu kontraktu w każdej kompatybilnej sieci.
W ramach proponowanej struktury ramki weryfikacyjne określałyby, czy nadawca autoryzował transakcję. Osobne ramki mogłyby ustalać, kto płaci opłaty, a następnie wykonywać żądane operacje.
Ta struktura jest zgodna z podziałem Buterina na zależności i działania. Ramki weryfikacyjne obsługują warunki, które muszą być spełnione. Ramki nadawcy obsługują operacje, które zmieniają stan.
Format mógłby również poprawić interoperacyjność między sieciami maszyny wirtualnej Ethereum. Różne łańcuchy mogłyby obsługiwać tę samą minimalną strukturę transakcji, stosując własne narzędzia weryfikacyjne, prekompilacje lub funkcje kont.
Buterin opisał potencjalny format jako podstawową listę wywołań z flagami identyfikującymi ich funkcję. Wywołanie mogłoby być oznaczone jako czysta zależność, weryfikacja zależna od stanu lub działanie. Transakcja zawierałaby również standardowe informacje, takie jak jej pochodzenie i nonce.
EIP-8141 pozostaje sklasyfikowany jako projekt propozycji Core. Jego obecna specyfikacja zawiera szczegółowe zasady przyjmowania do mempool, wykonywania ramek, pokwitowań, podpisów, rozliczania gazu i propagacji transakcji. Te szczegóły mogą się zmienić podczas przeglądu.
Deweloperzy Ethereum dyskutowali również nad kwestiami technicznymi. Obejmują one ryzyko ataków typu denial-of-service, zasady zastępowania transakcji, zmiany narzędzi, limity oczekujących transakcji oraz ograniczenia nałożone na ramki weryfikacyjne.
Jedna z dyskusji zauważyła, że proponowany publiczny mempool normalnie przechowywałby tylko jedną oczekującą transakcję ramową dla każdego nadawcy. Deweloperzy kwestionowali, jak ta zasada wpłynie na konta, które regularnie przesyłają kilka transakcji w jednym bloku.
Inni uczestnicy badali, czy format wprowadza dodatkową złożoność dla portfeli, budowniczych bloków i interfejsów zdalnego wywoływania procedur Ethereum. Te pytania muszą zostać rozwiązane, zanim zespoły klienckie będą mogły wdrożyć stabilną specyfikację.
Rekurencyjne STARK-i mogłyby wyeliminować powtarzalną weryfikację
Długoterminowy model Buterina wykracza poza EIP-8141. Zasugerował, że zależności niewymagające dostępu do stanu mogłyby być sprawdzane raz na poziomie mempool zamiast być powtarzane przez każdego walidatora.
Czysta zależność może obejmować podpis kryptograficzny lub dowód, którego ważność nie zmienia się wraz ze stanem Ethereum. Po sprawdzeniu sieć mogłaby zastąpić wiele fragmentów pracy weryfikacyjnej rekurencyjnym STARK-iem potwierdzającym, że wszystkie kontrole zostały wykonane poprawnie.
STARK to dowód kryptograficzny, który pozwala jednej stronie wykazać, że obliczenia zostały wykonane poprawnie. Rekurencyjne dowody mogą weryfikować inne dowody, umożliwiając połączenie wielu kontroli w mniejsze zadanie weryfikacyjne.
Proponowany mempool mógłby agregować podpisy transakcji, dowody ważności i inne zależności przed wykonaniem bloku. Walidatorzy weryfikowaliby następnie zagregowany dowód zamiast niezależnie powtarzać każde oryginalne obliczenie.
Buterin zasugerował, że to podejście mogłoby również zmniejszyć ilość danych weryfikacyjnych umieszczanych w łańcuchu. Jeśli rekurencyjny dowód ustali, że wszystkie zależności były ważne, niektóre oryginalne dane mogłyby potencjalnie zostać pominięte.
Ten wynik nie jest częścią obecnej specyfikacji EIP-8141. Wymagałby dodatkowych badań obejmujących generowanie dowodów, koordynację mempool, dostępność danych i ochronę przed nieprawidłową agregacją.
Projekt ma również związek z przygotowaniami Ethereum do kryptografii postkwantowej. Podpisy odporne na ataki kwantowe są zazwyczaj większe i droższe w weryfikacji niż podpisy ECDSA używane przez zwykłe konta Ethereum.
EIP-8141 mógłby pozwolić kontom na definiowanie nowych schematów autoryzacji bez czekania, aż Ethereum zastąpi pojedynczy stały standard podpisów. Rekurencyjna agregacja dowodów mogłaby następnie obniżyć koszt weryfikacji dużych podpisów postkwantowych.
EIP-8141 mógłby pomóc kontom Ethereum w przyjęciu autoryzacji postkwantowej, jeśli praktyczne systemy podpisów staną się dostępne. To pozostaje długoterminową ścieżką bezpieczeństwa, a nie natychmiastową odpowiedzią na aktywne zagrożenie kwantowe.
Kluczowe nonce mogą usunąć wąskie gardła transakcji
Konta Ethereum używają sekwencyjnych nonce, aby zapobiegać powtarzaniu transakcji. Jeśli konto przesyła transakcje o numerach 10, 11 i 12, sieć zwykle przetwarza je w tej kolejności.
Sekwencja może tworzyć wąskie gardło. Jeśli transakcja 10 utknie lub będzie nieprawidłowa, późniejsze transakcje z tego samego konta mogą również czekać, nawet jeśli ich operacje są niezwiązane.
Kluczowe nonce dałyby kontu kilka niezależnych sekwencji nonce. Transakcje przypisane do różnych kluczy mogłyby przebiegać bez czekania na postęp innej sekwencji.
To mogłoby pomóc inteligentnym kontom, systemom prywatności i aplikacjom, które przesyłają kilka niezależnych operacji jednocześnie. Każdy przepływ pracy mógłby otrzymać własną domenę nonce, zachowując ochronę przed powtórzeniem.
Crypto.news wcześniej donosiło, że kluczowe nonce mogłyby zapobiec blokowaniu się niezależnych prywatnych transakcji. Ta funkcja jest częścią szerszych wysiłków na rzecz poprawy prywatnych transakcji, elastycznych kont i odporności na cenzurę.
Buterin powiązał również prace nad transakcjami z alternatywnymi modelami stanu, w tym natywnymi projektami UTXO i strukturami stanu opartymi na dowodach. Projekty te badają, czy niektóre aktywa lub operacje mogą używać przewidywalnych reguł stanu, podczas gdy złożone kontrakty zachowują istniejącą elastyczność Ethereum.
Takie podejście mogłoby stworzyć kilka poziomów przetwarzania. Proste, zadeklarowane operacje byłyby łatwiejsze do analizy i mogłyby otrzymywać niższe opłaty. Dynamiczne wywołania kontraktów działałyby nadal, ale zużywałyby więcej zasobów, ponieważ klienci nie mogą przygotować ich wykonania w ten sam sposób.
Takie zróżnicowane ceny miałyby na celu dostosowanie opłat do rzeczywistych ograniczeń skalowania tworzonych przez każdą transakcję. Nie gwarantowałyby niższych opłat dla każdego użytkownika lub aplikacji.
EIP-8141 nadal wymaga zatwierdzenia i testów przez programistów
EIP-8141 musi przejść kilka etapów, zanim będzie mógł wpłynąć na użytkowników Ethereum. Podstawowi programiści muszą najpierw zgodzić się, że Frame Transactions oferują lepszą ścieżkę niż konkurencyjne projekty abstrakcji kont.
Propozycja wymagałaby następnie implementacji klienckich, sieci deweloperskich, testów interoperacyjności, wsparcia portfeli i przeglądu bezpieczeństwa. Programiści musieliby również przetestować, jak Frame Transactions współdziałają z budowniczymi bloków, mempoolami, rynkami opłat i istniejącymi inteligentnymi kontraktami.
Wcześniejsze dyskusje programistów rozważały EIP-8141 dla przyszłego ulepszenia Ethereum Hegotá. Jednak crypto.news donosiło, że Frame Transactions pozostają w fazie rozważań, a nie formalnie zaplanowane.
FOCIL, osobna propozycja mająca na celu poprawę odporności na cenzurę poprzez listy włączania transakcji, była również omawiana obok EIP-8141. Obie propozycje dotyczą różnych problemów. Frame Transactions dotyczą struktury autoryzacji i wykonania, podczas gdy FOCIL dotyczy włączania kwalifikujących się transakcji do bloków.
Programiści argumentowali, że użycie ich razem mogłoby zapewnić natywną abstrakcję kont z silniejszą odpornością na cenzurę. Ta kombinacja jest nadal proponowanym pakietem, a nie zatwierdzonym zobowiązaniem w roadmapie Ethereum.
Komentarze Buterina z 6 września opisują zatem możliwy kierunek projektowania transakcji Ethereum. Nie ogłaszają ukończonego ulepszenia, daty aktywacji ani potwierdzonej zmiany opłat za gaz w mainnecie.
Kolejne weryfikowalne kamienie milowe to formalne wsparcie programistów, włączenie do zakresu ulepszenia i działające implementacje w sieciach deweloperskich. Do tego czasu EIP-8141 i rekurencyjne mempooly STARK pozostają aktywnymi propozycjami badawczymi i inżynieryjnymi.
Najczęściej zadawane pytania
Czym jest EIP-8141?
EIP-8141 proponuje transakcje ramowe, które dzielą walidację, zatwierdzanie opłat i wykonanie na osobne ramki wywołań kontraktów.
Jest to obecnie projekt propozycji Core. Deweloperzy Ethereum mogą nadal zmienić lub odrzucić jego specyfikację.
Jaka jest różnica między akcją a zależnością?
Akcja zmienia stan Ethereum, na przykład wysyłając ETH lub wywołując kontrakt. Zależność to warunek, który musi być spełniony, taki jak podpis lub dowód stanu.
Rozdzielenie ich mogłoby pozwolić na jednoczesne przetwarzanie niezależnych zależności przed wykonaniem operacji zmieniających stan.
Czy EIP-8141 obniży opłaty transakcyjne Ethereum?
Może sprawić, że przewidywalne transakcje będą tańsze w przetwarzaniu, jeśli deweloperzy przyjmą wycenę gazu, która nagradza operacje statycznie analizowalne.
Żadna obniżka opłat nie jest potwierdzona. Koszty zależałyby od ostatecznej specyfikacji, implementacji klienta i przyszłych decyzji dotyczących aktualizacji.






