Tytuł oryginalny: „Bedrock Wyjaśnienie”

Napisał: Urzędnik optymizmu

Opracowane przez: Frank, Foresight News

Bedrock to nazwa pierwszej w historii oficjalnej wersji OP Stack, zestawu darmowych i modułowych komponentów typu open source, zaprojektowanych w celu wspierania rozwoju Optymizmu.

Podsumowanie ulepszeń

Bedrock udoskonala swojego poprzednika, w tym:

  • Zmniejsz opłaty transakcyjne, korzystając ze zoptymalizowanej kompresji transakcji wsadowych i Ethereum jako warstwy dostępności danych;

  • Zmniejszone opóźnienia w pakowaniu transakcji L1 w pakiety zbiorcze dzięki lepszej obsłudze reorganizacji L1;

  • Włącz modułowe systemy sprawdzające poprzez ponowne wykorzystanie kodu;

  • Popraw wydajność węzła, eliminując dług projektowy.

niższe opłaty

Bedrock wykorzystuje zoptymalizowaną strategię kompresji danych, aby zminimalizować koszty danych. Obecnie porównujemy wpływ tej zmiany, ale spodziewamy się, że znacząco obniży ona opłaty.

Bedrock eliminuje także wszelkie koszty gazu związane z wykonaniem EVM przy przesyłaniu danych do L1, co obniży koszty o dodatkowe 10% w porównaniu do poprzednich wersji protokołu.

Krótszy czas kredytowania depozytu

Bedrock wprowadził w oprogramowaniu węzła obsługę reorganizacji L1, co znacząco skraca czas oczekiwania użytkowników na zaksięgowanie wpłat.

We wcześniejszych wersjach protokołu potwierdzenie wpłaty mogło zająć do 10 minut, natomiast w przypadku Bedrock oczekujemy, że wpłata zostanie potwierdzona w ciągu 3 minut.

Ulepszony dowód modułowy

Bedrock wyodrębnia system dowodowy ze stosu OP, dzięki czemu pakiet zbiorczy może używać dowodów niepowodzenia lub dowodów ważności (takich jak zk-SNARK), aby udowodnić prawidłowe wykonanie po wprowadzeniu danych do pakietu zbiorczego. Ta abstrakcja pozwoli również na użycie Cannona do udowodnienia awaria systemu.

Poprawiona wydajność węzła

Wydajność oprogramowania węzła została znacznie poprawiona poprzez wykonanie wielu transakcji w jednym „bloku” zbiorczym zamiast modelu „jednej transakcji na blok” z poprzednich wersji.

Umożliwia to rozłożenie kosztów aktualizacji Merkle Trie na wiele transakcji, co przy bieżącym wolumenie transakcji zmniejsza przyrost danych stanu o około 15 GB rocznie.

Wydajność węzła została również jeszcze bardziej poprawiona poprzez wyeliminowanie długów technicznych z poprzednich wersji protokołu, w tym wyeliminowanie potrzeby tworzenia oddzielnego węzła „warstwy transportu danych” do indeksowania L1 i aktualizację oprogramowania węzła w celu wydajnego wysyłania zapytań o transakcje na podstawie danych L1.

Ulepszona równoważność Ethereum

Bedrock od początku był projektowany tak, aby był jak najbardziej „spójny” z Ethereum, a wiele odstępstw od Ethereum w poprzednich wersjach protokołu zostało wyeliminowanych, m.in.:

  • Model „Jedna transakcja na blok”;

  • Dostosuj kod operacji, aby uzyskać informacje o bloku L1;

  • Oddzielne pola opłat L1/L2 w API JSON-RPC;

  • Niestandardowa reprezentacja sald ETH w formacie ERC20.

Bedrock dodał także obsługę EIP-1559, reorganizację blockchain i inne funkcje Ethereum obecne na L1.

Zasady projektowania

Bedrock jest zbudowany tak, aby był modułowy i skalowalny, przy jednoczesnym ponownym wykorzystaniu istniejącego kodu z Ethereum i dążeniu do osiągnięcia 100% równoważności Ethereum tam, gdzie to możliwe.

Modułowy

Używając dobrze zdefiniowanych interfejsów i schematów wersjonowania, Bedrock może z łatwością zastępować różne komponenty w stosie OP i dodawać nowe funkcjonalności.

Pozwala to na dostosowanie się do przyszłego rozwoju ekosystemu Ethereum dzięki elastycznej architekturze, takiej jak:

  • Węzeł zbiorczy jest oddzielony od klienta wykonawczego;

  • Modułowa, odporna na awarie konstrukcja.

ponowne wykorzystanie kodu

Bedrock wykorzystuje istniejącą architekturę i infrastrukturę Ethereum, gdy tylko jest to możliwe. Takie podejście pozwala OP Stack odziedziczyć zalety bezpieczeństwa i efektu Lindy z przetestowanej w boju bazy kodu używanej przez sieć główną Ethereum.

Przykłady tego znajdziesz w całym projekcie, w tym:

  • minimalnie zmodyfikowany klient wykonawczy;

  • Kontrakty EVM zamiast prekompilowanego kodu klienta.

Równoważność Ethereum

Bedrock został zaprojektowany tak, aby był maksymalnie kompatybilny z istniejącymi doświadczeniami programistów Ethereum, ale istnieją pewne wyjątki ze względu na zasadnicze różnice między L1 a pakietem zbiorczym: różne modele opłat, krótsze czasy blokowania (2 sekundy zamiast 12 sekund) i specjalne typy transakcji, w tym transakcje depozytowe L1.

Wyjątki te obejmują:

  • Zabezpieczanie przed awariami klientów wykonawczych Ethereum, zaprojektowane w celu wykazania minimalnych modyfikacji;

  • Ethereum umożliwia ponowne wykorzystanie kodu po stronie klienta do wykorzystania przez węzły i zleceniodawców w sieci L2.

protokół

Pakiety zbiorcze opierają się na dostępności danych (zwykle jest to łańcuch bloków L1, taki jak Ethereum). W najczęstszej konfiguracji protokół zbiorczy wywodzi „kanoniczny łańcuch L2” z dwóch głównych źródeł informacji:

  • Dane transakcyjne są publikowane w L1 przez sekwencer;

  • Transakcje depozytowe są przekazywane przez rachunki i inteligentne kontrakty do kontraktu pomostowego na L1.

Poniżej przedstawiono podstawowe elementy umowy:

  • Poprzez bezpośrednią interakcję z inteligentnym kontraktem na poziomie L1 depozyt jest zapisywany w „standardowym łańcuchu L2”;

  • Wypłaty są zapisywane w „kanonicznym łańcuchu L2” i pośrednio uruchamiają interakcje z inteligentnymi kontraktami i kontami na L1;

  • Partie to zapisy danych odpowiadające partiom podczas zestawienia;

  • Wyprowadzenie blokowe polega na interpretacji odczytów danych na L1 w celu zrozumienia „kanonicznego łańcucha L2”;

  • System dowodowy określa ostateczność pierwiastków wyjściowych opublikowanych na L1, aby można je było wykonać (np. wykonać wypłaty).

depozyt

Depozyt jest transakcją na L1 i zostanie uwzględniony w rollupie. Z definicji gwarantuje się, że depozyty zostaną włączone do „kanonicznego łańcucha L2” w celu zapobiegania cenzurze lub kontroli L2.

Dowolna wiadomość dostarczona z L1

Transakcje depozytowe to transakcje typu rollup realizowane w ramach lokaty. Dzięki Bedrock depozyty są w pełni uniwersalnymi transakcjami Ethereum, takimi jak konta w Ethereum lub inteligentne kontrakty mogą tworzyć umowy „depozytowe”.

Bedrock definiuje kontrakt depozytowy dostępny na L1: jest to inteligentny kontrakt, z którym konta L1 i inteligentne kontrakty mogą wchodzić w interakcję, aby zapisywać je w L2. Transakcje depozytowe na L2 pochodzą z transakcji zawartych w ramach tej umowy depozytowej i obejmują oczekiwane parametry, takie jak od, do i dane.

Aby uzyskać szczegółowe informacje, zobacz sekcję Specyfikacje umowy depozytowej.

Kup gwarantowany gaz L2 na L1

Bedrock wyjaśnił także mechanizm spalania gazu i rynek opłat depozytowych. Gaz wydany na L2 w transakcjach depozytowych jest kupowany na L1 w drodze spalania gazu.

Gaz ten jest kupowany specjalnie na rynku opłat i istnieje sztywny limit całkowitej ilości Gazu dostarczanej do wszystkich transakcji depozytowych w jednym bloku L1. Mechanizm ten służy do zapobiegania możliwym atakom typu „odmowa usługi” (DoS). Podczas zapisywania transakcji z L1 do L2, ponieważ transakcje te zużywają dużo gazu na L2, ale są bardzo tanie na L1.

Gaz dostarczany do transakcji depozytowych nazywany jest czasami „gazem gwarantowanym”. Gwarancja gazu jest wyjątkowa, ponieważ jest opłacana poprzez spalanie gazu na L1 i dlatego nie podlega zwrotowi.

Całkowita ilość gazu L1 wymagana do spalenia na jednostkę gwarantowanego gazu L2 zależy od ceny gazu L2 zgłaszanej przez mechanizm ładowania typu EIP-1559. Dodatkowo użytkownicy otrzymują dynamiczny dodatek za gaz na podstawie ilości wydanego gazu L1, naliczając aktualizacje mechanizmu opłat.

Aby uzyskać bardziej szczegółowe wyjaśnienia, przeczytaj specyfikacje protokołu w sekcji dotyczącej depozytów.

Wypłacić pieniądze

Wypłaty to transakcje wielowarstwowe inicjowane na poziomie L2 i zakończone transakcjami realizowanymi na poziomie L1. Warto zaznaczyć, że konta L2 mogą wykorzystywać wypłaty do wywoływania kontraktów L1 lub przelewania ETH z kont L2 na konta L1.

Wycofanie jest inicjowane poprzez wywołanie wcześniej wdrożonej umowy Message Passer na L2, która rejestruje ważne właściwości wiadomości w jej pamięci, a następnie wycofanie jest zakończone na L1 poprzez wywołanie umowy OptimismPortal w celu udowodnienia włączenia tej wiadomości o wycofaniu.

W ten sposób wypłaty i wpłaty różnią się: transakcje wypłat muszą zostać zrealizowane przy użyciu inteligentnych kontraktów na L1, a nie polegać na informacjach pochodzących z bloków.

Dwuetapowy proces wypłaty

Błędy podczas sprawdzania dowodu wypłaty były główną przyczyną wielu włamań do mostów między łańcuchami w ciągu ostatnich kilku lat. Wersja Bedrock wprowadza dodatkowy krok w procesie wycofywania poprzednich wersji, mający na celu zapewnienie dodatkowej ochrony przed tego typu błędami.

W dwuetapowym procesie odstąpienia od umowy przy każdym wycofaniu należy przedstawić dowód Merkle odpowiadający odstąpieniu na 7 dni przed ostatecznym wyjściem. Ten nowy mechanizm bezpieczeństwa daje narzędziom monitorującym pełne 7 dni na znalezienie i wykrycie nieważności dowodu odstąpienia.

Jeżeli w tym okresie okaże się, że certyfikat wypłaty jest nieważny, można wdrożyć naprawy inteligentnych kontraktów, zanim środki zostaną utracone, co znacznie zmniejsza ryzyko naruszenia bezpieczeństwa mostu między łańcuchami.

Szczegółowe informacje można znaleźć w sekcji Specyfikacje umowy o wystąpieniu.

Partie

W Bedrock zdefiniowany jest format przewodowy dla przesyłania komunikatów między L1 i L2 (tj. L2 wyprowadza bloki z L1, L2 zapisuje transakcje w L1). Ten przewodowy format ma na celu zmniejszenie kosztów zapisu do L1 i złożoności oprogramowania do minimum.

Zoptymalizuj kompresję danych

Aby zoptymalizować kompresję danych, listy transakcji L2 (zwane partiami sekwencera) są zorganizowane w grupy obiektów (zwane kanałami). Maksymalny rozmiar każdego kanału można zdefiniować w konfigurowalnym parametrze, który początkowo będzie ustawiony na 9,5 M. Te kanały To jest. oczekuje się, że zostanie skompresowany przy użyciu funkcji kompresji i przesłany do L1.

wsadowe przesyłanie równoległe

Aby zrównoleglić komunikaty z sekwencerów przesyłających skompresowane dane kanału do L1, kanały są dalej rozkładane na „ramki kanału”, które są fragmentami skompresowanych danych kanału, które można zmieścić w pojedynczej transakcji L1.

Zakładając, że „ramki kanałów” są od siebie niezależne i kolejność jest znana, transakcje Ethereum wysyłane do L1 przez sekwencer mogą być wysyłane równolegle, minimalizując w ten sposób złożoność oprogramowania sekwencera i umożliwiając wypełnienie całej dostępnej przestrzeni danych na L1.

Minimalizowanie gazu Ethereum

Bedrock usuwa cały gaz wykonawczy używany przez system L1 do przesyłania danych kanału do L1 w transakcjach zwanych „transakcjami wsadowymi”. Cała logika weryfikacji, która wcześniej występowała w inteligentnych kontraktach L1, została przeniesiona do logiki blokowania wyprowadzania. Zamiast tego „transakcje wsadowe” są wysyłane na pojedynczy adres EOA w Ethereum, zwany „adresem zbiorczej skrzynki odbiorczej”.

Partie nadal podlegają kontroli ważności (tj. muszą być poprawnie zakodowane), podobnie jak poszczególne transakcje w ramach paczki (np. podpisy muszą być ważne), nieważne partie i nieważne pojedyncze transakcje w ramach ważnych paczek są uznawane za odrzucone i nieistotne dla systemu.

Uwaga: Ethereum wkrótce zostanie zaktualizowane do nowej wersji, która będzie zawierać EIP-4844, który wprowadza oddzielny rynek opłat za zapis danych i zwiększa górny limit ilości danych, które protokół Ethereum jest skłonny przechowywać. Oczekuje się, że ta zmiana ulegnie dalszemu zmniejszeniu liczba Kosztów związanych z publikacją do L1.

Bardziej szczegółowe wyjaśnienia można znaleźć w specyfikacji formatu kabla.

Zablokuj widelec

W Bedrock protokół zaprojektowano tak, aby zapewnić powiązanie czasu depozytów na L1 z wyprowadzeniem blokowym „kanonicznego łańcucha L2”. To, co robi, jest czystą funkcją zapisywania danych do L1 poprzez właściwości sekwencera, depozytu i bloku L1.

Aby to osiągnąć, protokół określa strategie gwarantowania depozytów, obsługi znaczników czasu L1 i L2 oraz obsługi okien zamówień w kanale w celu zapewnienia prawidłowego zamawiania.

Gwarantowana kaucja pod uwagę

Cele protokołu wyprowadzania bloków są zdefiniowane w następujący sposób:

Po upływie każdego „interwału bloku L2” musi nastąpić blok L2, a znacznik czasu bloku L2 jest zsynchronizowany ze znacznikiem czasu bloku L1 (tj. zapewniając uwzględnienie depozytów w logicznym porządku chronologicznym).

W Bedrock wprowadzono koncepcję „epoki sekwencjonowania”: jest to zakres bloków L2 pochodzących z serii bloków L1. Każda epoka jest identyfikowana za pomocą „numeru epoki”, który jest równy liczbie w oknie sortowania. Numer kolejny bloku pierwszego bloku L1. Rozmiar epok może się różnić, z zastrzeżeniem pewnych ograniczeń.

Kanał wyprowadzany wsadowo traktuje znacznik czasu bloku L1 powiązany z „numerem epoki” jako kotwicę do określania kolejności transakcji w warstwie L2. Protokół gwarantuje, że pierwszy blok L2 epoki nigdy nie będzie opóźniony w stosunku do znacznika czasu bloku L1 pasującej epoki. Pierwszy blok epoki musi zawierać depozyty na L1, aby zagwarantować, że depozyt zostanie przetworzony.

Należy pamiętać, że w wersji Bedrock docelowy interwał blokowy na L2 jest skonfigurowany na 2 sekundy.

Obsługa znaczników czasu L1 i L2

Bedrock próbuje rozwiązać problem uzgadniania znaczników czasu na L2 ze znacznikami czasu na L1, które istnieją w transakcjach depozytowych.

Czyni to poprzez umożliwienie krótkiego okna czasowego sortowania w celu swobodnego stosowania znaczników czasu w transakcjach L2 pomiędzy epokami.

Okno sekwencjonowania to sekwencja bloków L1, z której można wyprowadzić epoki. W oknie sortowania pierwszy blok L1 o numerze N zawiera „transakcje wsadowe” danej epoki.​

Okno sortowania zawiera bloki, których wielkość zależy od wielkości okna sortowania: stały parametr konfiguracyjny poziomu zwijania musi wynosić co najmniej 2, zwiększenie go da sekwencerowi więcej możliwości sortowania transakcji L2 na depozytach, obniżając go na potrzeby sekwencjonowania. Im bardziej rygorystyczny czas okno wprowadzone przez serwer do przesyłania „transakcji wsadowych”. Jest to kompromis pomiędzy tworzeniem możliwości MEV a zwiększaniem złożoności oprogramowania.

Stała protokołu zwana „maksymalnym dryfem sekwencera” kontroluje maksymalny znacznik czasu, jaki może mieć blok w swojej epoce. W przypadku tego dryfu sekwencer może mieć tymczasowe problemy z połączeniem się z L1.

Zablokuj rurociąg widełkowy

„Kanoniczny łańcuch L2” można przetwarzać od początku, zaczynając od stanu genezy L2, ustawiając początek łańcucha L2 na pierwszą epokę, a następnie przetwarzając wszystkie okna sortowania w celu określenia partii sekwencera zgodnie z następującą uproszczoną kolejnością i poprawną sekwencją do osadzania rur:

Dowód niepowodzenia

Gdy sekwencer przetworzy jeden lub więcej bloków L2, wyniki obliczeń transakcji wykonanych w tych blokach będą musiały zostać zapisane w L1, aby umożliwić bez zaufania wykonywanie komunikatów L2 do L1, takich jak wypłaty itp.

W Bedrock dane wyjściowe są haszowane w formie struktury drzewiastej, co minimalizuje koszt sprawdzania dowolnego fragmentu danych przechwyconych przez dane wyjściowe. Proponenci okresowo przesyłają korzenie wyjściowe do L1, które służą jako pierwiastki Merkle dla całego „kanonicznego łańcucha L2”.

Przyszłe aktualizacje stosu OP powinny obejmować specyfikację wariantu odpornego na awarie z powiązaniami zachęcającymi wnioskodawców do proponowania prawidłowych pierwiastków wyjściowych.

Aby uzyskać szczegółowe informacje, przeczytaj specyfikację protokołu w sekcji Propozycja głównego wyjścia L2.

wprowadzić w życie

W Bedrock stos OP musi w dużym stopniu polegać na określonym przez Ethereum oddzieleniu problemów technicznych, odzwierciedlając rozdział między warstwą wykonawczą Ethereum a warstwą konsensusu.

Dlatego Bedrock w ten sam sposób wprowadził separację klientów wykonawczych i węzłów zbiorczych.

Wykonaj klienta

Klienci wykonujący to systemy uruchamiane przez sekwencery i innych typów operatorów węzłów w celu określenia stanu kanonicznego łańcucha L2. Realizuje także inne funkcje, takie jak obsługa transakcji przychodzących i komunikacji peer-to-peer, a także przetwarzanie stanu systemu w celu obsługi zapytań skierowanych przeciwko niemu.

Dzięki Bedrock OP Stack ma na celu ponowne wykorzystanie własnej specyfikacji klienta wykonawczego Ethereum i wielu jego operacji wykonawczych. W tej wersji Bedrock zademonstrował niezwykle ograniczoną modyfikację klienta Ethereum go-ethereum, z różnicą mniejszą niż 2000 linii kodu.

Istnieją dwie podstawowe przyczyny tej różnicy: przetwarzanie transakcji depozytowych i pobieranie opłat transakcyjnych.

Przetwarzaj transakcje depozytowe

Aby reprezentować zdeponowane transakcje w zestawie, wprowadzono dodatkowy typ transakcji. Implementacja klientów wdrażających ten nowy typ transakcji opiera się na standardzie transakcji typu EIP-2718.

Pobieraj opłaty transakcyjne

Rollupy zasadniczo wiążą się z dwoma rodzajami opłat transakcyjnych:

Jednym z nich jest opłata za sekwencer. Koszt obsługi sekwensera jest obliczany przy użyciu tej samej tabeli gazów i tego samego algorytmu EIP-1559 co w przypadku Ethereum. Opłaty te są wykorzystywane w protokole do obsługi sekwensera i zmieniają się w czasie w zależności od przeciążenia sieci.

Kolejna opłata za dostępność danych. Koszty dostępności danych są związane z zapisywaniem transakcji wsadowych do L1 i mają na celu pokrycie opłat sekwencera za przesyłanie transakcji wsadowych do L1.

W Bedrock część opłaty za dostępność danych jest ustalana na podstawie informacji zawartych w inteligentnym kontrakcie systemu zbiorczego o nazwie GasPriceOracle, który opiera się na atrybutach bloku L1 wstawianych na początku każdej epoki podczas procesu wyprowadzania bloku jest zaktualizowane.

Bedrock określa, że ​​oba koszty są dodawane do jednego pola podczas korzystania z JSON-RPC.

węzeł zbiorczy

W przeciwieństwie do Ethereum, Bedrock nie ma konsensusu PoS. Natomiast konsensus „kanonicznego łańcucha L2” definiuje się poprzez wyprowadzanie blokowe. Klient wykonawczy OP Stack komunikuje się z nowym komponentem, który implementuje rozwidlanie bloków zwanym węzłem zbiorczym, który komunikuje się z klientem wykonawczym przy użyciu dokładnie tego samego interfejsu API silnika co Ethereum.

Węzeł rollup jest bezstanowym komponentem odpowiedzialnym za wyprowadzanie stanu systemu poprzez odczytywanie danych i depozytów na L1. W Bedrock węzły zbiorcze mogą być używane do sekwencjonowania transakcji przychodzących od użytkowników lub innych węzłów zbiorczych lub do sprawdzania potwierdzonych transakcji opublikowanych na L1, opierając się wyłącznie na L1.

Poniżej podsumowano różne zastosowania węzłów zestawień:

Zweryfikuj „kanoniczny łańcuch L2”

Najprostszym sposobem uruchamiania węzłów zbiorczych jest po prostu podążanie za „kanonicznym łańcuchem L2”. W tym trybie węzeł zbiorczy nie ma partnerów i jest wyłącznie używany do odczytu danych z L1 i interpretacji danych zgodnie z zasadami protokołu wyprowadzania bloków.

Jednym z celów takiego węzła jest sprawdzenie, czy wszelkie korzenie wyjściowe wspólne dla innych węzłów lub opublikowane na L1 są poprawne, zgodnie z definicją protokołu. Dodatkowo wnioskodawcy, którzy zamierzają przesłać pierwiastki wyjściowe do L1, mogą sami użyć optimism_outputAtBlock do wygenerowania potrzebnych pierwiastków wyjściowych i zwrócić 32-bajtowy skrót odpowiadający pierwiastkowi wyjściowemu L2.

Aby to zrobić, węzły powinny jedynie podążać za „sfinalizowanym” nagłówkiem bloku. Termin „sfinalizowany” odnosi się do konsensusu Ethereum PoS (tj. kanonicznego i prawie nieodwracalnego), a „sfinalizowany” nagłówek bloku L2 to obszar „kanonicznego łańcucha L2” wywodzący się dopiero z „sfinalizowanego” bloku L1 Big głowa.

Weź udział w sieci L2

Najbardziej powszechnym sposobem wykorzystania węzła zbiorczego jest uczestnictwo w sieci innych węzłów zbiorczych, śledzenie procesów i stanu L2. W tym trybie węzeł rollup jednocześnie odczytuje dane i deponuje zaobserwowane dane z L1, interpretuje je w bloki i akceptuje transakcje przychodzące od użytkowników i równorzędnych użytkowników w sieci innych węzłów rollup.

Węzły uczestniczące w sieci mogą używać bezpiecznych i niezabezpieczonych nagłówków bloków L2, z którymi się synchronizują.

  • Bezpieczne nagłówki bloków L2 reprezentują pakiety zbiorcze, które można skonstruować, w których każdy blok (w tym nagłówki) można w pełni wyprowadzić z referencyjnego łańcucha L1, zanim L1 będzie musiał zostać „sfinalizowany” (tj. reorganizacja może nadal nastąpić na L1);

  • Niebezpieczne nagłówki bloków L2 obejmują niebezpieczne bloki, które nie zostały wyprowadzone z L1. Bloki te pochodzą albo z działania węzła zbiorczego jako sekwencera, albo z niepewnej synchronizacji z sekwencerem. Nazywa się to także „najnowszym” nagłówkiem bloku. W przypadku braku porozumienia zawsze wybieraj bezpieczny nagłówek bloku L2 zamiast niebezpiecznego nagłówka bloku L2. Kiedy dojdzie do nieporozumienia, niezabezpieczona część łańcucha ulegnie reorganizacji;

W większości przypadków w przypadku aplikacji użytkownika końcowego węzły zbiorcze w sieci L2 będą odwoływać się do niezabezpieczonych nagłówków bloków L2.

Sortowanie transakcji

Trzecim sposobem wykorzystania węzłów zbiorczych jest zlecanie transakcji. W tym trybie węzły zbiorcze utworzą nowe bloki na niezabezpieczonych nagłówkach bloków L2. Obecnie na każdą sieć OP Stack przypada tylko jeden sekwencer.

Sekwencer jest również odpowiedzialny za publikowanie partii transakcji w L1, aby inne węzły w sieci mogły się z nim synchronizować.

Dozownik

Rolą sekwencera jest tworzenie partii transakcji. W tym celu sekwencery mogą uruchamiać węzły podsumowujące i mieć oddzielne procesy, które wykonują partie poprzez odczyt z zaufanych węzłów podsumowujących, na których działają.

Zapewnia to, że dodatkowy komponent stosu OP, zwany modułem obsługi transakcji wsadowych, odczytuje dane transakcji z węzła zbiorczego i interpretuje je w transakcję wsadową, która ma zostać zapisana w L1. Komponent wsadowy jest odpowiedzialny za odczyt i uruchomienie przez sekwencer Węzeł zwija niezabezpieczony nagłówek bloku L2, tworzy transakcje wsadowe i zapisuje je w L1.

Standardowa umowa mostowa

Bedrock obejmuje również parę kontraktów pomostowych dla najpopularniejszych typów złóż, zwanych Standardowymi Kontraktami Pomostowymi. Umowy te obejmują umowy wpłat i wypłat, zapewniając prosty interfejs dla wpłat i wypłat tokenów ETH i ERC-20.

Te kontrakty pomostowe są zaprojektowane w taki sposób, że jedna strona mostu międzyłańcuchowego ma token natywny, a druga strona zawiera token opakowany, który może zarządzać biciem i spalaniem. Mostkowanie tokenu natywnego polega na zablokowaniu tokena natywnego w umowie, a następnie zablokowaniu token natywny w moście międzyłańcuchowym Druga strona wybija taką samą liczbę zamkniętych tokenów.

Aby uzyskać więcej informacji, zobacz sekcję Specyfikacja protokołu standardowego mostu międzyłańcuchowego.

Armata

Chociaż w Cannon zaimplementowano niezawodne budowanie i weryfikację, specyfikacja odpornej na awarie gry i integracja wyjściowego głównego pretendenta z węzłem podsumowującym stanowią część kolejnych kamieni milowych specyfikacji.

Dalsza lektura

Specyfikacja protokołu

Specyfikacja protokołu określa szczegóły techniczne stosu OP i jest najbardziej aktualnym źródłem prawdy o wewnętrznym funkcjonowaniu protokołu.

Różnica w podłożu

Aby uzyskać szczegółowe informacje na temat różnic między Bedrock a poprzednimi wersjami, zobacz Czym różni się Bedrock.