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. Tx 3: Charlie wysyła 100 MON do Alice, kosztując 1 MON w opłatach. Teraz jest blok 1001. Lider decyduje, czy uwzględnić następującą transakcję: Tx 4: Alice wysyła 40 MON do Boba, kosztując 1 MON w opłatach. Kiedy na to spojrzymy, wiemy, że byłoby bezpiecznie uwzględnić tx 4, ponieważ bilans Alice wynosi 100 - 21 - 71 + 100 = 108. Ale z powodu asynchronicznego wykonania, w momencie konsensusu, nie znamy wyniku całego wykonania, znamy tylko najgorszy możliwy bilans Alice, który wynosi 100 - 21 - 71 = 8. Stary algorytm polegał na tym pesymistycznym bieżącym saldzie, aby wykorzystać opóźniony stan w decyzjach konsensusu. Działa to całkiem dobrze, z wyjątkiem faktu, że czasami może być zbyt konserwatywne (jak widać w powyższym przykładzie, gdzie tx 4 nie może być natychmiast uwzględnione, dopóki opóźniony korzeń merkle'a nie nadrobi zaległości, aby uwzględnić blok z tx 3 w nim).

Myślę, że zespół Category Labs może właśnie znalazł sposób na to, aby asynchroniczne wykonanie działało z EIP-7702.

Właśnie uruchomiliśmy cotygodniowy newsletter z aktualizacjami na temat wszystkiego, co dzieje się wokół Monad Dziękujemy @denk_tweets i zespołowi @beehiiv, którzy ułatwili nam skalowanie tego Zapisz się tutaj: