Zapytałem Justina, jak widzi rolę rollupów w tym oszczędnym świecie Ethereum? Jego odpowiedź odzwierciedla optymizm co do technologii natywnych rollupów. Oto, co @drakefjustin miał do powiedzenia na temat przyszłości rollupów w @ethereum: "Dzisiejsze rollupy mają dwa główne problemy. Pierwszym z nich jest to, że są dość skomplikowane i prawdopodobnie mają błędy. Może to potencjalnie oznaczać, że cały rollup może zostać wyczerpany. Drugim dużym problemem jest utrzymanie EVM. Większość rollupów stara się być rollupami równoważnymi EVM, co oznacza, że gdy L1 się zmienia, zmienia się EVM L1, L2 również musi zmieniać się w jedności. A aby to zrobić, potrzebujesz jakiegoś rodzaju procesu zarządzania, aby rozwijać rollup. Ale niestety, sam proces zarządzania, ścieżka aktualizacji, jest sama w sobie luką w zabezpieczeniach. Czyż nie byłoby miło, gdybyś mógł mieć rollupy, które z założenia są wolne od błędów i nie muszą być aktualizowane za każdym razem, gdy L1 jest aktualizowane? I to jest podstawowa idea natywnych rollupów, gdzie możesz zbudować rollup, którego funkcja przejścia stanu wykonania jest dokładną kopią tego, co jest dostępne w L1. Z założenia, ponieważ jest to dokładna kopia L1, jest definicyjnie poprawna. A gdy L1 się zmienia, podczas twardego forka, wszystkie rollupy automatycznie zmieniają się razem z nim. Aby wdrożyć ten prekompilowany dla natywnych rollupów, dość wygodne jest najpierw przeprowadzenie aktualizacji ZKVM EVM... ...efektywnie, to co dają nam natywne rollupy, to ⁓ nieograniczona ilość wykonania L1 przez te natywne rollupy. A jedynym prawdziwym wąskim gardłem jest warstwa dostępności danych." Posłuchaj całego odcinka, aby uzyskać więcej szczegółów.