Autor: 0xhhh（Twitter: @hhh69251498），Binary DAO
Redaktor: Czerwony
27 marca oficjalnie wystartowała wersja testowa sieci głównej Polygon zkEVM, a Vitalik dokonał na niej pierwszej transakcji.
Ten artykuł jest pierwszym z serii artykułów na temat Polygon zkEVM. Pokrótce wyjaśnia ogólną architekturę i proces realizacji transakcji Polygon zkEVM oraz analizuje, w jaki sposób Polygon zkEVM osiąga ekspansję obliczeniową, dziedzicząc jednocześnie bezpieczeństwo Ethereum.
Jednocześnie w kolejnych dwóch artykułach szczegółowo przedstawimy szczegóły konstrukcyjne mostka zkEVM i zkEVM firmy Polygon zkEVM, a także kolejny plan działania zdecentralizowanego sekwencera firmy Polygon zkEVM.
1. Rollup służy do zwiększenia mocy obliczeniowej Ethereum
Najpierw musimy wyjaśnić ogólną zasadę działania Rollupa. Pojawienie się Rollupu ma na celu osiągnięcie ekspansji obliczeniowej dla Ethereum. Specyficzną metodą wdrożenia jest zlecanie realizacji transakcji Rollupowi, a następnie przechowywanie transakcji i stanu po realizacji transakcji w kontrakcie Ethereum Istnieją dwa rodzaje Rollupów:
Optymistyczny Rollup optymistycznie wierzy, że transakcja Rollup wysłana do Ethereum i odpowiadający jej Stan Rollup są prawidłowe. Każdy może dokonać oszustwa w Stanie Rollup, który wciąż znajduje się w okresie wyzwania, dostarczając wyzwanie odporne na oszustwo.
RollupZK o wiedzy zerowej dostarczy certyfikat ważności transakcji Rollup wysłanej do Ethereum i odpowiadający jej stan Rollup (zweryfikowany przez umowę na Ethereum w celu udowodnienia, że stan po wykonaniu odpowiedniej transakcji Rollup jest prawidłowy).
Zapoznaj się z oficjalną definicją Ethereum: https://ethereum.org/en/developers/docs/scaling/#rollupsZero-knowledge Rollup i Optimistic Rollup Największą różnicą jest to, że ze względu na różne sposoby weryfikacji ważności stanu, czas na osiągnięcie Finality jest inny; Optymistyczny Rollup zakłada, że transakcje i status przesłane do Ethereum są prawidłowe, dlatego obowiązuje 7-dniowy okres na wyzwanie (czas na osiągnięcie Finality wynosi 7 dni. W tym okresie każdy, kto je znajdzie). odpowiedni status transakcji w Ethereum jest nieprawidłowy, może przejść. Prześlij prawidłowy status do wyzwania. Czas potrzebny na osiągnięcie Finality przez pakiet wiedzy zerowej (zk-Rollup) zależy od: czasu potrzebnego na przesłanie dowodu ważności (dowód ważności) odpowiadającego transakcji do Ethereum i zweryfikowanie. Obecnie Finality trwa prawdopodobnie około 1 godziny (ponieważ należy wziąć pod uwagę koszt gazu).
2. Proces wykonywania wielokąta zkEVM
Następnie używamy prostego procesu potwierdzania transakcji, aby zobaczyć, jak działa Polygon zkEVM, aby uzyskać szczegółowe zrozumienie całego protokołu. Cały proces można głównie podzielić na trzy etapy:
1. Sekwencer łączy wiele transakcji użytkownika w Batch i przesyła je do kontraktu L1 2. Prover generuje dowód ważności (Dowód ważności) dla każdej transakcji i agreguje dowody ważności wielu transakcji w jeden dowód ważności; dowód ważności (Validity Proof), który łączy wiele transakcji w kontrakt L1. 1. Sequencer pakuje transakcje użytkownika do pakietu wsadowego i przesyła je do kontraktu L1
1) Użytkownik wysyła transakcję do sekwencera, a sekwencer przetworzy transakcje lokalnie w kolejności szybkości (FRFS). Jeśli sekwencer pomyślnie przeprowadzi transakcję lokalnie, jeśli użytkownik uważa, że sekwencer jest uczciwy, może to zrobić. rozważ ten czas. Transakcja została sfinalizowana. Należy tutaj zauważyć, że większość Mempoolów (pul transakcyjnych) w Sequencer jest obecnie prywatna, więc dostępny na razie MEV jest stosunkowo niewielki. 2) Sekwencer spakuje wiele transakcji w partię (obecnie partia zawiera tylko jedną transakcję), a następnie po zebraniu wielu partii użyje funkcji SequenceBatch() PolygonZKEvm.sol na L1 w celu połączenia wielu partii wysłanych do Dane wywołania transakcji L1.
(Należy zauważyć, że przesłanie wielu partii na raz ma na celu maksymalne zmniejszenie zużycia gazu przez L1)
3) Gdy PolygonZkEvm.sol otrzyma partie dostarczone przez Sequencer, obliczy po kolei hash każdej partii w kontrakcie, a następnie zapisze hash poprzedniej partii w następnej partii, dzięki czemu otrzymamy następującą strukturę partii.
4) Ustalana jest także kolejność transakcji w każdej Paczce, zatem w przypadku ustalenia kolejności Paczki uważamy, że została ustalona kolejność wszystkich transakcji wchodzących w skład Paczki złożonej do kontraktu Polygon zkEVM L1.
Powyższy faktyczny proces to także praca, którą L1 musi wykonać, aby działać jako warstwa Rollup DA (w tym momencie nie ukończono żadnej kontroli stanu ani prac nad rozwojem).
2. Agregator generuje Dowód Ważności dla transakcji obejmujących wiele partii
1) Kiedy agregator wykryje, że nowe partie zostały pomyślnie przesłane do kontraktu PolyonZKEVM.sol L1, zsynchronizuje te partie z własnym węzłem, a następnie wyśle te transakcje do zkProver. 2) Po otrzymaniu tych transakcji zkProver wygeneruje dowód ważności dla każdej transakcji równolegle, a następnie zsumuje dowody ważności transakcji zawartych w wielu partiach w jeden dowód ważności. 3) zkProver wysyła Dowód Ważności, który agreguje wiele transakcji do Agregatora.
3. Agregator przekazuje dowód agregacji do kontraktu L1
Agregator prześle ten dowód ważności (dowód ważności) i odpowiedni status po wykonaniu tych partii do kontraktu Polygon zkEvm.sol L1, wywołując następującą metodę: Kontrakt wykona następnie następujące operacje w celu sprawdzenia, czy zmiana stanu została dokonana prawidłowy. Kiedy ten krok zostanie pomyślnie wykonany w umowie L1, wszystkie transakcje zawarte w tej partii rzeczywiście osiągną Ostateczność (odpowiadającą końcowi 7-dniowego okresu kwestionowania PO).
3. Rola Ethereum w Polygon-zkEVM
Zrozumieliśmy już ogólny proces Polygon zkEVM powyżej. Możemy sprawdzić, co Ethereum zrobiło dla Rollupu: W pierwszym kroku Sequencer zbiera transakcje Rollup i pakuje je w Batch, a następnie przesyła je do kontraktu L1. L1 nie tylko zapewnia funkcje warstwy DA, ale także faktycznie realizuje część funkcji sekwencjonowania transakcji; kiedy przesyłasz transakcję do Sekwencera, transakcja w rzeczywistości nie jest sekwencjonowana, ponieważ Sekwenser ma moc zmiany kolejności transakcji. transakcję według własnego uznania, jednak po włączeniu transakcji do Paczki i złożeniu jej do kontraktu L1 nikt nie ma prawa modyfikować kolejności transakcji.
W drugim kroku Agregator wymienia Dowód Ważności kontraktu L1, aby osiągnąć nowy stan. Agregator odgrywa rolę podobną do Wnioskodawcy, a umowa odgrywa rolę podobną do Weryfikatora. Agregator zapewnia Dowód Ważności do udowodnienia czy nowy stan jest poprawny, oraz Powiedz Walidatorowi, jakich partii transakcji dotyczy dostarczony przeze mnie Dowód Ważności i gdzie w L1 są one przechowywane.
Następnie Walidator wyodrębnia odpowiednią Partię z umowy i łączy ją z Dowodem Ważności w celu sprawdzenia legalności zmiany stanu. Jeżeli weryfikacja przebiegnie pomyślnie, umowa zostanie faktycznie zaktualizowana do nowego stanu odpowiadającego Dowodowi Ważności.
4. Struktura Smart Contract Rollup z perspektywy modułowej
Z modułowego punktu widzenia Polygon zkEVM należy do typu Smart Contract Rollup. Możemy spróbować zdekonstruować różne jego moduły. Z diagramu podanego przez Delphi widzimy również, że Polygon ZkEVM w rzeczywistości służy jako warstwa konsensusu Smart Contract Rollup. Warstwa DA i warstwa rozliczeniowa są w rzeczywistości połączone w kontrakcie PolygonZkEVM.sol i nie można ich dobrze rozróżnić. Ale staramy się zdekonstruować każdy moduł:
Warstwa dostępności danych: miejsce, w którym przechowywane są transakcje zbiorcze. W przypadku Polygon-zkEVM, gdy Sequencer wywołuje metodę SequenceBatch(), w rzeczywistości obejmuje to przesyłanie danych transakcji do warstwy DA.
Warstwa rozliczeniowa: W szczególności odnosi się do mechanizmu przepływu kapitału pomiędzy Rollupem a L1, a konkretnie do oficjalnego mostu Polygon-zkEVM (który zostanie szczegółowo przedstawiony w następnym artykule).
Warstwa konsensusu: Zawiera sekwencjonowanie transakcji i sposób określenia następnego legalnego stanu (wybór forku). Sekwencer kończy pracę nad sekwencjonowaniem transakcji, gdy wywołuje SequenceBatch() w kontrakcie L1, gdy agregator wywołuje TustedVerifyBatches() w kontrakcie L1). prace nad potwierdzeniem kolejnego stanu prawnego zostały zakończone.
Warstwa wykonania: Wykonaj transakcję i uzyskaj nowy stan świata. Kiedy użytkownik przesyła transakcję do sekwencera, a sekwencer kończy wykonanie, proces uzyskiwania nowego stanu (dlatego często mówimy, że Rollup jest rozwinięciem obliczeniowym, ponieważ). L1 uzyskuje transakcję wykonania. Proces nowego stanu jest zlecany firmie Rollup, a Sequencer powierza zkProver za pośrednictwem Aggregatora w celu pomocy w wygenerowaniu dowodu ważności.
5. Dlaczego mówi się, że Polygon-zkEVM dziedziczy bezpieczeństwo L1?
Sądząc po ogólnym procesie przedstawionym powyżej, Sequencer faktycznie działa podobnie do Ethereum Proposer, proponując partię transakcji jako transakcje ważne i nadając nowy status po wykonaniu tej partii transakcji oraz logikę weryfikacji kontraktu L1, It jest równoznaczne z wykonaniem wszystkich walidatorów L1 we własnym kliencie Ethereum. W rzeczywistości wszystkie walidatory Ethereum działają jako walidatory Rollup, dlatego wierzymy, że Polygon zkEVM dziedziczy bezpieczeństwo Ethereum.
Z drugiej strony, ponieważ wszystkie transakcje i stany Rollupa są przechowywane w Ethereum, nawet jeśli zespół Polygon zkEVM ucieknie, każdy nadal będzie mógł przywrócić całą sieć Rollup w oparciu o dane przechowywane w Ethereum.
6. Mechanizm motywacyjny Polygon zkEVM
Mechanizm motywacyjny Rollup odnosi się głównie do tego, jak sprawić, aby Sequencer i Agregator były opłacalne, aby utrzymać ciągłość pracy? Po pierwsze, użytkownicy muszą uiścić własne opłaty transakcyjne w ramach Rollup. Ta część opłaty jest denominowana w ETH i opłacana za pomocą Bridged ETH.
Sekwencer musi zapłacić koszt przesłania Batcha zawierającego transakcję Rollup do Calldata transakcji L1 (koszt wywołania SequenceBatch(batches())). Jednocześnie musi zapłacić pewną kwotę Matic do L1 umowy podczas przesyłania Partii do późniejszej płatności. Agregator zapewnia koszt Potwierdzenia Ważności tych Partii.
Chociaż Agregator wywołuje zaufane VerifyBatches w celu dostarczenia dowodu ważności partii w umowie L1, które nie zostały sfinalizowane, może również wycofać tokeny MATIC opłacone z góry przez Sequencer w ramach umowy jako nagrodę za dostarczenie dowodu ważności.
Dochód sekwencera = Opłata za gaz za wszystkie transakcje w ramach Rollup - sieć L1 Opłata za gaz za przesłanie partii do L1 - Opłata za dowód płacona agregatorowi (ceny MATIC).
Przychód agregatora = wynagrodzenie MATIC zapłacone przez Sequencer - Opłata za gaz przekazana do Validity Proof do L1 - Opłata sprzętowa wydana na wygenerowanie Validity Proof.
Dostosuj opłatę certyfikacyjną płaconą Agregatorowi Jednocześnie, aby uniknąć wyłączenia Sekwencera z powodu nierentowności, zapewniony jest następujący mechanizm korygujący opłatę certyfikacyjną płaconą przez Sekwencer Agregatorowi.
W umowie istnieje sposób na dostosowanie kosztu dostarczenia dowodu dla Batch:
funkcja _updateBatchFee(uint64 newLastVerifiedBatch) wewnętrzna
Spowoduje to zmianę zmiennej w umowie o nazwie BatchFee, która określa liczbę tokenów MATIC płaconych przez Sequencer za każdą Partię.
Mechanizm zmiany jest następujący:
Kontrakt utrzymuje zmienną VeryBatchTimeTarget, która oznacza, że oczekuje się, że każda partia zostanie zweryfikowana w tym czasie po przesłaniu jej do L1 przez sekwencer.
W umowie zostaną zapisane wszystkie Partie, które nie zostały zweryfikowane po przekroczeniu VeryBatchTimeTarget, a łączna liczba tych Partii zostanie zarejestrowana jako Partie Diff.
Jeśli więc niektóre partie się spóźnią, do dostosowania BatchFee zostanie zastosowana następująca formuła:
MultiplierBatchFee to liczba ograniczona do zakresu 1000~1024, którą administrator kontraktu może zmienić za pomocą funkcji setMultiplierBatchFee():
Zestaw funkcjiMultiplier BatchFee (uint16newMultiplierBatchFee) tylko publicznyAdmin
Należy zauważyć, że zastosowano tutaj MultiplierBatchFee i 10^3, aby uzyskać dokładność regulacji wynoszącą 3 miejsca po przecinku. W ten sam sposób, jeśli Partie są zaawansowane, zostanie uruchomiony odpowiedni mechanizm korekty BatchFee: DiffBatches reprezentuje liczbę Partii, które zostały wcześniej zweryfikowane. Podsumować
W tym artykule omawiamy podstawowy mechanizm Polygon zkEVM i analizujemy jego wykonalność w celu osiągnięcia ekspansji obliczeniowej Ethereum. Po zapoznaniu się z ogólnym zarysem, w następnym artykule zagłębimy się w protokół i przeanalizujemy szczegóły projektu mostu zkEVM oraz ścieżkę decentralizacji Sequencer, implementację zkProver i zasadę projektowania zkEVM.