Mapa drogowa Interop „przyspiesza”: po aktualizacji Fusaka interoperacyjność Ethereum może osiągnąć kluczowy etap

Chainfeeds Wprowadzenie:

Bez natychmiastowego ZK, trudno mówić o naprawdę użytecznym Interop UX.

Źródło artykułu:

Autor artykułu:

imToken Labs

Poglądy:

imToken Labs: 4 grudnia, aktualizacja Fusaka Ethereum została oficjalnie aktywowana na mainnecie, choć nie była tak głośna jak niegdyś aktualizacja Dencun, a światła reflektorów rynku skupiły się głównie na Blob scaling i PeerDAS, z entuzjazmem komentując dalsze obniżenie kosztów danych L2. Jednak poza tym zgiełkiem, istnieje jeszcze jedna niepozorna propozycja EIP-7825, która usuwa największą przeszkodę dla wdrożenia L1 zkEVM i natychmiastowego dowodzenia na Ethereum, a nawet można powiedzieć, że po cichu toruje drogę do końcowego etapu Interop. W tej aktualizacji Fusaka, uwaga wszystkich niemal całkowicie skupiła się na skalowaniu: pojemność Blob została zwiększona 8-krotnie, a w połączeniu z losową weryfikacją próbkowania PeerDAS, narracja o kosztach w sektorze DA (dostępność danych) przeszła do historii. Rzeczywiście, tańsze L2 to dobra wiadomość, ale dla długoterminowej mapy drogowej ZK Ethereum, to właśnie EIP-7825 jest prawdziwym zmieniaczem zasad gry, ponieważ ustawia limit Gas dla pojedynczej transakcji na Ethereum (około 16,78 miliona Gas). Jak powszechnie wiadomo, w tym roku limit Gas bloku Ethereum został już podniesiony do 60 milionów, ale nawet jeśli limit będzie nadal podnoszony, teoretycznie, jeśli ktoś będzie chciał zapłacić bardzo wysoką cenę za Gas, nadal może wysłać bardzo złożoną „mega-transakcję”, która zajmie całe 60 milionów Gas w bloku, blokując cały blok. Dlaczego więc ograniczać rozmiar pojedynczej transakcji? W rzeczywistości ta zmiana nie ma żadnego wpływu na zwykłych użytkowników dokonujących przelewów, ale dla ZK Prover (generatora dowodów) to kwestia życia i śmierci, co jest ściśle związane ze sposobem generowania dowodów przez systemy ZK. Dla prostego przykładu, przed EIP-7825, jeśli w bloku znalazła się „mega-transakcja” zużywająca 60 milionów Gas, ZK Prover musiałby przetworzyć tę niezwykle złożoną transakcję sekwencyjnie, bez możliwości podziału czy równoległego przetwarzania — to jak jednokierunkowa autostrada, na której przed wszystkimi samochodami jedzie powolna ciężarówka, a wszystkie inne pojazdy (inne transakcje) muszą czekać, aż ona przejedzie. To bezpośrednio oznaczało śmierć „natychmiastowego dowodzenia” — ponieważ czas generowania dowodu był całkowicie nieprzewidywalny, mógł trwać dziesiątki minut lub dłużej. Po EIP-7825, nawet jeśli w przyszłości pojemność bloku wzrośnie do 100 milionów Gas, ponieważ każda transakcja jest ograniczona do 16,78 miliona Gas, każdy blok zostaje podzielony na przewidywalne, ograniczone i możliwe do równoległego przetwarzania „małe jednostki zadań”, co oznacza, że generowanie dowodów na Ethereum zmienia się z trudnego „problemu logicznego” w czysto „problem mocy obliczeniowej (Money Problem)”: jeśli tylko zainwestujemy wystarczająco dużo równoległej mocy obliczeniowej, możemy w bardzo krótkim czasie przetworzyć te podzielone małe zadania, generując ZK proof dla ogromnych bloków. Jednak EIP-7825, choć poprzez ograniczenie rozmiaru pojedynczej transakcji toruje fizyczną drogę do natychmiastowego dowodzenia (możliwość równoleglenia), to jest tylko jedna strona medalu, druga dotyczy tego, jak sam mainnet Ethereum wykorzysta tę zdolność? To prowadzi do najtwardszej narracji w mapie drogowej Ethereum — L1 zkEVM. Przez długi czas zkEVM był postrzegany jako „święty Graal” skalowania Ethereum, nie tylko dlatego, że rozwiązuje problem wydajności, ale także dlatego, że redefiniuje mechanizm zaufania blockchaina. Jego główną ideą jest umożliwienie mainnetowi Ethereum generowania i weryfikowania ZK proofów. Innymi słowy, w przyszłości po wykonaniu każdego bloku Ethereum, będzie można wygenerować weryfikowalny matematyczny dowód, dzięki czemu inne węzły (zwłaszcza lekkie węzły i L2) będą mogły potwierdzić poprawność wyniku bez konieczności powtarzania obliczeń — jeśli zdolność generowania ZK proofów zostanie bezpośrednio wpisana w warstwę protokołu Ethereum (L1), to za każdym razem, gdy proposer pakuje blok i generuje ZK proof, węzły weryfikujące nie będą musiały ponownie wykonywać transakcji, a jedynie zweryfikować ten niewielki matematyczny dowód.