To jest wprowadzenie do asynchronicznego wykonania: jak udało nam się to zrealizować w Monad, dlaczego EIP-7702 to zepsuł i jak to naprawić. Dla kontekstu, asynchroniczne wykonanie jest w Monad od momentu, gdy klienci konsensusu i wykonania zostały ze sobą połączone. Asynchroniczne wykonanie pozwala na opóźnienie wykonania względem konsensusu o stałą liczbę bloków z perspektywy interakcji. Większość blockchainów ma przeplatany konsensus. To znaczy, że wykonanie odbywa się przed konsensusem, co oznacza, że wykonanie musi zmieścić się w budżecie czasowym, który jest małą częścią czasu bloku (reszta jest zajęta przez komunikację na całym świecie, znaną jako konsensus). To z natury ogranicza ilość gazu na sekundę w systemie. L2 omijają to, nie mając w ogóle konsensusu. Ale chcemy zachowania rozproszonego, zdecentralizowanego L1, które utrzymuje wysoką wydajność. Asynchroniczne wykonanie pozwala nam uniknąć tego problemu, przenosząc wykonanie z gorącej ścieżki konsensusu. Zamiast tego, konsensus i wykonanie odbywają się równolegle w oddzielnych torach. Konsensus dla bloku 2 zachodzi, podczas gdy wykonanie bloku 1 odbywa się równolegle. Nadal musi istnieć zgoda między konsensusem a wykonaniem. Konkretnie, ta zgoda polega na tym, że wykonanie może opóźnić się względem konsensusu o maksymalnie k bloków, ponieważ propozycje bloków zawierają opóźniony korzeń merkle'a. Ponadto, konsensus buduje bloki z opóźnionym widokiem stanu (opóźnionym o k bloków). Oznacza to, że istnieje niebezpieczeństwo, że konsensus uwzględni transakcję od nadawcy, który, w momencie wykonania, okazuje się mieć pusty bilans. Byłoby źle, gdyby protokół na to pozwalał, ponieważ otworzyłoby to wektor Denial-of-Service (DOS). Dlatego, aby rozwiązać ten problem i bezpiecznie umożliwić asynchroniczne wykonanie, klient konsensusu Monad oblicza maksymalny debet MON każdej transakcji jako MON_spent = gas_bid * gas_limit + value. Klient konsensusu prowadzi bieżącą listę dostępnych sald kont dla każdego nadawcy po odliczeniu MON_spent dla każdej transakcji, którą wysłali. Na podstawie tego bieżącego salda, klient konsensusu uwzględnia transakcje tylko wtedy, gdy może być pewny, że transakcja może być opłacona. To jest pesymistyczne podejście do budowania bloków, ponieważ nie uwzględnia możliwości, że jakiekolwiek konta mogą zyskać na saldzie z transferu. Pozwól, że wyjaśnię, co mam na myśli na przykładzie. Załóżmy, że konto Alice ma 100 MON. Następnie, następujące 3 transakcje są uwzględnione w bloku 1000: Tx 1: Alice wysyła 20 MON do Boba, kosztując 1 MON w opłatach. Tx 2: Alice wydaje 70 MON na zakup memecoina, kosztując 1 MON w opłatach....