Póki co mit dobrobytu w kręgu walutowym/branży blockchain trwa, a kolejnym ważnym obszarem „tworzenia bogactwa” jest skupienie się na „ścieżce gry”. Projekt XAI organizuje wydarzenie Odyseja. Jeśli jesteś zainteresowany, przeczytaj mój artykuł na placu: XAI Game Public Chain Odyssey Event Zero-Cost Przewodnik dla początkujących

W tym artykule szczegółowo wyjaśnię węzeł Sentry w publicznym łańcuchu gier XAI! Ten artykuł jest stosunkowo techniczny, więc jeśli jesteś zainteresowany zarabianiem pieniędzy, musisz go uważnie przeczytać. Bo tylko jeśli sam zrozumiesz „logikę” i poprawisz swoje poznanie, możesz mieć szansę na zarobienie pieniędzy!

Jeśli chcesz dowiedzieć się bezpośrednio o węźle Sentry, przeczytaj bezpośrednio pierwszą część, bez czytania później; jeśli chcesz mieć logiczną zamkniętą pętlę, musisz przeczytać drugą, trzecią i czwartą część!

Co chcę podkreślić, to to, że Xai otrzymuje bezpośrednie wsparcie techniczne od Offchain Labs. Tego rodzaju wsparcie jest niewyobrażalne w przypadku innych łańcuchów Orbit! i jest kluczowym elementem strategicznego planu gry Xai w ekosystemie Arbitrum.

Część 1: Wyjaśnienie węzła wartowniczego

Węzeł Sentry to węzeł obserwacyjny, który monitoruje protokół zbiorczy Xai i jeśli zaproponowany zostanie zły blok, wygeneruje sygnał dźwiękowy (w dowolny sposób wybrany przez operatora), aby inni mogli interweniować. Celem węzła wartowniczego jest rozwiązanie dylematu weryfikatora (szczegóły na temat dylematu weryfikatora można znaleźć w Części IV).

Kliknij tutaj, aby obejrzeć film promocyjny:

Promocja wideo węzła wartowniczego

Uruchom węzły Xai i zdobądź tokeny Xai jednym kliknięciem!

Węzły Sentinel mogą działać na laptopach, komputerach stacjonarnych, a nawet instancjach w chmurze członków społeczności. Dopóki węzeł działa, istnieje algorytm probabilistyczny, który określa, czy operator węzła zostanie nagrodzony tokenami esXai z sieci. Stawiając Xai, zwiększasz prawdopodobieństwo algorytmu. Jeśli nie wiesz o esXai, proszę weź udział w moim artykule na placu: Interpretacja „Ekonomii Tokena” projektu XAI

1. Zasada działania węzła wartowniczego

Protokół Attention Challenge v2 obejmuje wielu uczestników, w tym łańcuch Xai, łańcuch nadrzędny (Arbitrum One), zaufanego pretendenta, strażników Xai i ich klucze licencyjne oraz umowę sędziego (sędziego). Osoba pretendująca tworzy parę kluczy BLS, rejestruje klucz publiczny do umowy z sędzią i podpisuje oświadczenia złożone przez walidatora w protokole rollup Xai na Arbitrum One. Podpisy te są weryfikowane przez umowę sędziego i rejestrowane jako sprzeciwy związane z roszczeniem.

Xai Sentinels może zarejestrować się w umowie referencyjnej, kupując klucz licencyjny Sentinel, aby móc publikować oświadczenia dotyczące roszczeń. Otrzymują korzeń stanu prawidłowej instrukcji, która będzie następcą instrukcji wydającej. Jeżeli zostanie spełniony określony warunek, wydają oświadczenie w sprawie oświadczenia, powołując się na umowę sędziowską. Jeśli zostanie sporządzone i potwierdzone kolejne oświadczenie, a Sentinel wystawi prawidłowe oświadczenie, Sentinel skontaktuje się z umową referencyjną w celu wystawienia transakcji wykupu. Przed wypłaceniem nagrody Strażnikowi sędzia zweryfikuje kilka warunków.

Ten protokół zapewnia, że ​​każde roszczenie musi w pełni wykorzystać wiadomości w skrzynce odbiorczej, które istniały w momencie tworzenia jego poprzednika. Oznacza to, że po utworzeniu roszczenia pierwiastki stanu jego kolejnych poprawnych roszczeń są w pełni określone i mogą zostać obliczone przez dowolny węzeł. Zachęca to każdego strażnika do określenia prawidłowego korzenia następnego stanu. Nagroda Strażnika jest określana na podstawie identyfikatora pozwolenia stanu Strażnika, kolejnego stanu głównego i wartości wyzwania, która staje się znana dopiero po pełnym określeniu kolejnego stanu głównego.

2. Kto może uruchomić węzeł?

Każdy może obsługiwać Sentinel, pobierając oprogramowanie, instalując je i uruchamiając. Aby jednak otrzymać nagrody w formie tokenów, należy zakupić co najmniej jeden klucz licencyjny Sentinel.

Kupujący muszą pomyślnie przejść kontrolę KYC, aby upewnić się, że:

• nie w Stanach Zjednoczonych

• Nie podlega żadnym sankcjom USA OFAC (OFAC jest odzwierciedlony na liście sankcji USA)

Te węzły Sentinel, które nie działają lub nie mają odpowiednich środków na uiszczenie opłat za gaz (GAS), nie będą gromadzić nagród, nawet z kluczem licencyjnym. Dlatego operatorzy będą chcieli mieć pewność, że ich węzły są finansowane, online i działają.

3. Umowa sędziowska (sędzia).

Referee to inteligentny kontrakt zaprojektowany w celu egzekwowania zgodności z wcześniej zdefiniowanymi zasadami, weryfikowania pochodzenia zgłoszeń i dystrybucji nagród wśród zwycięzców w systemie. Inteligentny kontrakt referencyjny to kluczowy element ekosystemu Xai, odpowiedzialny za zarządzanie i weryfikację roszczeń zgłaszanych przez węzły wartownicze w sieci. Umowa spełnia kilka kluczowych funkcji:

3.1 Złożenie oświadczenia

Umowa sędziowska umożliwia węzłom wartowniczym zgłaszanie roszczeń do wyzwań. Funkcję tę może wywołać wyłącznie właściciel klucza licencyjnego Sentinel lub adres zatwierdzony w niniejszej umowie. Ta funkcja sprawdza, czy wyzwanie jest nadal otwarte do przesłania i czy dla tego wyzwania została już złożona licencja NodeLicense.

3.2 Otrzymuj nagrody

Umowa zawiera funkcję, która pozwala użytkownikom ubiegać się o nagrody za pomyślnie zakończone roszczenia. Ta funkcja sprawdza, czy wyzwanie zostało zamknięte do przesłania i sprawdza, czy właściciel klucza węzła ukończył KYC. Jeśli te warunki zostaną spełnione i roszczenie będzie kwalifikowało się do wypłaty, nagroda zostanie wysłana do użytkownika.

3.3 Utwórz skrót roszczenia i sprawdź płatność.

Kontrakt zawiera funkcję, która tworzy skrót identyfikatora uprawnienia wartownika, identyfikatora wyzwania, challengerSignedHash w wyzwaniu i kolejnego stanu głównego. Następnie sprawdza, czy skrót jest poniżej określonego progu, który jest obliczany na podstawie całkowitej liczby wydanych licencji Sentinel. Jeśli hash jest poniżej progu, roszczenie kwalifikuje się do wypłaty.

Umowa referencyjna zapewnia integralność sieci Xai poprzez weryfikację roszczeń i nagradzanie udanych, motywując w ten sposób węzły wartownicze do dokładnego i sumiennego monitorowania sieci.

4. Komponent Challengera

Pretendent to zaufana jednostka w ekosystemie Xai. Tworzy parę kluczy BLS i rejestruje klucz publiczny do umowy referencyjnej. Kiedy walidator zgłasza roszczenie w protokole zbiorczym Xai, osoba kwestionująca podpisuje roszczenie przy użyciu swojego klucza prywatnego i przesyła podpis sędziemu. Sędzia weryfikuje podpis i zapisuje go jako wyzwanie powiązane z oświadczeniem. Proces ten zapewnia integralność oświadczeń zawartych w protokole zbiorczym Xai.

5. Klucz (pozwolenie na klucz węzła Sentinel, oparte na NFT)

Klucz licencyjny Sentinel to unikalny, niezmienny token (NFT), który jest wymagany do obsługi węzła Sentinel w sieci Xai. Licencje Sentinel służą jako dowód, że węzły kwalifikują się do zgłaszania roszczeń i otrzymywania nagród. Wybija się go poprzez przesłanie odpowiedniej ilości ETH, a cenę wybicia określa system rosnących progów.

Licencjonowanie węzła odgrywa kluczową rolę w umowie z sędzią. Gdy węzeł chce zgłosić roszczenie do wyzwania, musi podać swój identyfikator uprawnienia Sentinel. Umowa referencyjna sprawdza, czy licencja Sentinel jest ważna i czy węzeł jest właścicielem licencji Sentinel lub zatwierdzonym operatorem (sekcja KYC powyżej). Jeśli te warunki zostaną spełnione, roszczenie węzła zostanie poddane pod rozpatrzenie.

Uprawnienia Strażnika mają również znaczenie przy ubieganiu się o nagrody za udane roszczenia. Umowa referencyjna sprawdza, czy właściciel licencji Sentinel ukończył KYC i czy oświadczenie kwalifikuje się do zapłaty. Jeśli te warunki zostaną spełnione, nagroda zostanie wysłana do właściciela licencji Sentinel.

Podsumowując, zezwolenie Sentinel jest kluczowym elementem w sieci Xai, który reguluje działanie węzłów Sentinel, składanie roszczeń i dystrybucję nagród.

6. Pobieranie i uruchamianie węzła

Aby uruchomić węzeł wartowniczy, użytkownicy muszą jedynie pobrać określony pakiet oprogramowania. Tego pakietu można używać w aplikacji komputerowej lub jako narzędzia wiersza poleceń na komputerze. Mówiąc najprościej, te aplikacje to narzędzia ułatwiające obsługę oprogramowania Sentinel. Celem tego pakietu jest automatyzacja wszystkich operacji wymaganych do uruchomienia Sentinel, dzięki czemu jego konfiguracja i obsługa są bardzo proste, nawet jeśli nie masz doświadczenia technicznego.

Pakiet ten pomaga użytkownikom w wykonywaniu takich zadań, jak konfiguracja, zarządzanie i interakcja z innymi częściami, a także posiada łatwy w użyciu interfejs, który umożliwia użytkownikom łatwe przeglądanie i dostosowywanie ustawień. Korzystając z tego pakietu, użytkownicy mogą bardziej skoncentrować się na tym, jak biegać lepiej i zdobywać więcej nagród w postaci tokenów. Użytkownicy mogą uruchomić ten pakiet za pomocą aplikacji komputerowej lub narzędzia wiersza poleceń, oba są bardzo łatwe w użyciu i sprawiają, że proces operacji jest bardzo płynny.

7. Funkcja portfela Sentinel

W ekosystemie Xai portfel Sentinel odgrywa kluczową rolę w interakcji między węzłami Sentinel a inteligentnymi kontraktami. Sentinel Wallet pełni rolę agenta pośredniczącego i jest odpowiedzialny za składanie oświadczeń sędziemu w imieniu odpowiednich Sentinels. Osiąga się to poprzez określone funkcje w umowie referencyjnej, z których może skorzystać wyłącznie właściciel klucza licencyjnego Sentinel lub jego zatwierdzony adres w tej umowie.

Portfel Sentinel może złożyć oświadczenie na wyzwanie, wywołując funkcję SubmitAssertionToChallenge w umowie referencyjnej. Ta funkcja sprawdza, czy wyzwanie jest nadal otwarte do przesłania i czy klucz węzła został już przesłany do tego wyzwania.

Portfel Sentry może także ubiegać się o nagrody za pomyślnie zakończone roszczenia, wywołując funkcję ClaimReward w umowie referencyjnej. Ta funkcja sprawdza, czy wyzwanie zostało zamknięte do przesłania i sprawdza, czy właściciel licencji Sentinel ukończył test „KYC”. Jeśli te warunki zostaną spełnione i roszczenie będzie kwalifikowało się do wypłaty, nagroda zostanie wysłana do właściciela Sentinela.

Podsumowując, Sentinel Wallet pełni rolę komunikatora, ułatwiając interakcję pomiędzy węzłami a refererami, zapewniając tym samym sprawne działanie sieci Xai.

8. Licencja

Zależność pomiędzy liczbą licencji a możliwościami składania węzła jest fundamentalna. Chociaż z węzłem może być powiązanych wiele licencji, należy pamiętać, że liczba licencji wpływa bezpośrednio na zdolność węzła do zatwierdzania. Zasadniczo, aby zapewnić sprawiedliwe limity zatwierdzeń, stosunek licencji do instancji węzłów utrzymuje się na poziomie 1:1. Stosując się do powyższych zasad, system ustanawia ustrukturyzowane podejście do licencjonowania, zgłaszania praw i ogólnego działania węzłów w ekosystemie.

9. Wymagania dotyczące oprogramowania i sprzętu węzła wartowniczego

Oprogramowanie węzła Sentinel obsługuje komputery stacjonarne z systemami Windows, Mac i Linux (wymaga wersji 64-bitowej). Poniżej przedstawiono aktualne zasoby wymagane do uruchomienia oprogramowania węzła Sentinel dla maksymalnie 100 kluczy licencyjnych:

• 4 GB RAM-u

• 2 rdzenie procesora

• 60 GB miejsca na dysku

• Procesor x86/X64 (obsługuje procesor ARM, taki jak układ Apple M1/M2)

• Stabilne połączenie internetowe

W idealnym przypadku, gdy do węzła dodawane są dodatkowe klucze, możliwości sprzętowe powinny odpowiednio wzrosnąć. Przypisanie osobnej maszyny do każdego klawisza nie jest jednak obowiązkowe. Oczekuje się, że system będzie skalowalny, aby pomieścić dziesiątki kluczy na jednej maszynie, a być może i więcej.

Uwaga: te wymagania sprzętowe mogą ulec zmianie.

10. Szacunkowe nagrody z sieci węzłów wartowniczych

Model ekonomiczny tokena XAI, proszę zapoznać się z: Interpretacja „Ekonomii tokena” projektu XAI

Oto trzy scenariusze szacowania nagród Xai, które możesz zdobyć za prowadzenie węzła Wartownik. Te trzy scenariusze opierają się na następujących założeniach:

• Suma XAI i esXAI nigdy nie przekroczy 2 500 000 000. Biorąc pod uwagę, że ekosystem Xai jest dynamiczny, niemożliwe jest dokładne przewidzenie miesięcznych nagród w postaci tokenów za każdy klucz Sentry.

• Spala się 100% GAS-u, więc nie ma gwarancji, że podaż zawsze będzie inflacyjna, może to być deflacja.

• Fundacja Xai nie sprzeda więcej niż 50 000 kluczy Sentry (węzeł może załadować wiele kluczy). Oczekuje się, że zajmie to 2-3 lata. Klucze strażnicze z biegiem czasu stają się coraz droższe.

• Miesięczna kwota esXAI na klucz Sentry może również się zmieniać w zależności od liczby uczestników stakujących w ekosystemie.

Znaczenie poniższych trzech tabel jest takie, że przy różnym obiegu tokenów XAI i esXAI liczba kluczy węzłów aktywowanych w sieci i odpowiadające im oczekiwane miesięczne nagrody za tokeny na klucz:

Szacunkowy scenariusz A: Jeśli w obiegu znajduje się łącznie 750 000 tokenów XAI i esXAI, wówczas każdy klucz Sentry otrzyma nagrody esXAI zgodnie z poniższą tabelą:

Scenariusz B Oszacowanie: Jeśli w obiegu znajduje się łącznie 1 250 000 000 tokenów XAI i esXAI, wówczas każdy klucz Sentry otrzyma nagrody esXAI zgodnie z poniższą tabelą:

Szacunkowy scenariusz C: Jeśli w obiegu znajduje się łącznie 2 187 500 000 tokenów XAI i esXAI, wówczas każdy klucz Sentry otrzyma nagrody esXAI zgodnie z poniższą tabelą:

Część 2: XAI jest rozwijany i utrzymywany przez Arbitrum (ARB), dlatego musimy rzucić trochę światła na architekturę Arbitrum:

1. Decyzja o nitro

Wszystkie łańcuchy Arbitrum są zbudowane na Arbitrum Nitro, który jest podstawową technologią dla wszystkich łańcuchów w ekosystemie. Nitro uruchamia rozwidloną wersję Geth i wykorzystuje WebAssembly jako odporną na oszustwa podstawową maszynę wirtualną.

2. Jakakolwiek decyzja o zaufaniu

Anytrust to protokół Arbitrum, który zarządza dostępnością danych poprzez grupę licencjodawców zwaną Komitetem ds. Dostępności Danych (DAC). Protokół ten zmniejsza opłaty transakcyjne poprzez wprowadzenie dodatkowego założenia zaufania dotyczącego dostępności danych, zamiast korzystać z mechanizmu dostępności danych bez zaufania Ethereum.

3. Wprowadzenie do warstw Arbitrum 2, które być może znasz

Arbitrum Nova jest przykładem łańcucha AnyTrust; Arbitrum One to kolejny alternatywny łańcuch, który implementuje całkowicie pozbawiony zaufania (i zużywający więcej gazu L1) protokół Arbitrum Rollup. Obydwa łańcuchy zbudowane są na Nitro.

4.Łańcuch orbit

Arbitrum Orbit umożliwia stronom trzecim tworzenie własnych, samodzielnie zarządzanych łańcuchów Arbitrum Rollup i AnyTrust. Arbitrum oferuje technologie Rollup i AnyTrust zapewniające maksymalną elastyczność podczas budowania łańcuchów Orbit. Podobnie jak wszystkie sieci w ekosystemie Arbitrum, zarówno Arbitrum Rollups, jak i sieć Arbitrum Anytrust Orbit są zbudowane przy użyciu technologii Nitro.

5. Zrozum podstawową sytuację Xai

Rozumiemy Xai w powyższym kontekście. Xai działa jako łańcuch Arbitrum Orbit, wykorzystując technologię Anytrust w celu uzyskania maksymalnej prędkości i minimalnych kosztów. W przeciwieństwie do większości „samorządnych” sieci Orbit, Xai korzysta z bezpośredniego wsparcia technicznego ze strony Offchain Labs. Tego rodzaju wsparcie jest niewyobrażalne w przypadku innych sieci Orbit! i jest kluczowym elementem strategicznego planu gry Xai w ekosystemie Arbitrum.

Część 3: Po zapoznaniu się z powyższymi koncepcjami, przyjrzyjmy się bliżej architekturze:

1.AnyTrust: rewolucyjna infrastruktura Blockchain

W ramach AnyTrust i jako najnowocześniejszy wariant technologii Arbitrum Nitro, Offchain Labs wykorzystuje innowacje, aby rozwiązać niektóre z najpilniejszych wyzwań w przestrzeni blockchain. AnyTrust zapewnia nam nową perspektywę, przyjmując założenia o lekkim zaufaniu, znacznie redukując koszty, zapewniając jednocześnie wysoką dostępność i bezpieczeństwo danych.

2. Obniż koszty poprzez założenia zaufania

U podstaw protokołu Arbitrum wszystkie węzły Arbitrum (w tym walidatory weryfikujące poprawność łańcucha i ustalające dokładne wyniki) muszą uzyskać dostęp do danych każdej transakcji warstwy drugiej (L2) w skrzynce odbiorczej łańcucha Arbitrum. Tradycyjnie pakiet Arbitrum zapewnia dostęp do danych poprzez publikowanie danych jako danych wywoławczych w warstwie pierwszej (L1) Ethereum, co jest procesem generującym znaczne opłaty za gaz Ethereum, co stanowi główny składnik kosztów w Arbitrum.

3. Zestawy elastyczności

Ketsety odgrywają kluczową rolę w architekturze AnyTrust. Określają klucze publiczne członków komisji oraz liczbę podpisów wymaganych do weryfikacji Certyfikatu Dostępności Danych (DACert). Zestawy ketsetów zapewniają elastyczność zmiany członków komitetu i umożliwiają członkom komitetu aktualizację kluczy w razie potrzeby.

4. Certyfikaty dostępności danych (DACerts)

W AnyTrust podstawową koncepcją jest certyfikat dostępności danych (DACert). DACert składa się ze skrótu bloku danych, czasu wygaśnięcia i dowodu, że członkowie komitetu N-1 podpisali parę (hasz, czas wygaśnięcia). Dowód ten obejmuje skrót zestawu kluczy użytego do podpisu, mapę bitową wskazującą, którzy członkowie komisji się złożyli, oraz podpis zbiorczy BLS na krzywej BLS12-381, potwierdzający osobę podpisującą.

Dzięki założeniu zaufania 2 z N, DACert stanowi dowód, że dane bloku będą dostępne dla co najmniej jednego uczciwego członka komisji, aż do określonego czasu wygaśnięcia. To założenie zaufania jest podstawą niezawodności i bezpieczeństwa dostępności danych w ramach AnyTrust.

5. Podwójny mechanizm uwalniania danych

AnyTrust wprowadza podwójną metodę publikowania bloków danych na L1. Oprócz tradycyjnej metody publikowania całych bloków danych, umożliwia także wydawanie DACerts, czyli certyfikatów potwierdzających dostępność danych. Umowa skrzynki odbiorczej L1 weryfikuje ważność certyfikatów DACert, w tym odniesienie do ważnych Kesetów określonych w DACert.

Kod L2 odpowiedzialny za odczyt danych ze skrzynki odbiorczej został zaprojektowany tak, aby bezproblemowo obsługiwać oba formaty danych. W przypadku napotkania certyfikatu DACert przeprowadza kontrolę ważności, w tym sprawdza, czy liczba sygnatariuszy spełnia wymagania Ketsets, sprawdza poprawność podpisów zbiorczych i potwierdza, że ​​data wygaśnięcia przekracza bieżący znacznik czasu L2. Ważne certyfikaty DACerts zapewniają dostępność bloku danych i możliwość wykorzystania go przez kod L2.

6. Serwer dostępności danych (DAS)

Członkowie komisji obsługują serwer dostępności danych (DAS), który udostępnia dwa kluczowe interfejsy API:

(1) Sorter API: Zaprojektowany do użytku przez sorter łańcucha Arbitrum, ten interfejs JSON-RPC umożliwia sorterowi przesyłanie bloków danych do DAS w celu przechowywania.

(2) API REST: Zaprojektowany z myślą o szerszej dostępności, protokół RESTful oparty na HTTP(S) umożliwia pobieranie fragmentów danych za pomocą skrótu. Jest w pełni buforowany i można go wdrożyć w połączeniu z buforującymi serwerami proxy lub sieciami CDN w celu zwiększenia skalowalności i ochrony przed potencjalnymi atakami DoS.

7. Interakcja sortownik-komitet

Gdy sorter Arbitrum zamierza opublikować partię danych za pośrednictwem komisji, wysyła dane i datę wygaśnięcia do wszystkich członków komisji równolegle za pośrednictwem RPC. Każdy członek komitetu przechowuje dane, podpisuje parę (hasz, czas wygaśnięcia) przy użyciu swojego klucza BLS i zwraca podpis i wskaźnik sukcesu do sekwencera. Po zebraniu wystarczającej liczby podpisów sekwencer agreguje je, aby utworzyć prawidłowy certyfikat DACert dla par (hasz, czas wygaśnięcia). Ten DACert jest następnie publikowany w umowie skrzynki odbiorczej L1, dzięki czemu jest dostępny dla oprogramowania łańcucha AnyTrust L2. W przypadku, gdy sekwencer nie będzie w stanie zebrać wystarczającej liczby sygnatur w określonym przedziale czasu, przyjmuje strategię „powrotu do zbiorczego” i publikuje kompletne dane bezpośrednio w łańcuchu L1. Oprogramowanie L2 doskonale radzi sobie ze zrozumieniem obu formatów publikowania danych (za pośrednictwem DACert lub pełnych danych) i odpowiednią obsługą każdego formatu. Podsumowując, AnyTrust, jako przełomowa innowacja w ekosystemie Offchain Labs, stanowi krytyczny postęp w zakresie dostępności danych, bezpieczeństwa i opłacalności infrastruktury blockchain. Dzięki rozsądnemu założeniu zaufania i nowatorskiemu podejściu do publikowania danych, AnyTrust toruje drogę dla bardziej skalowalnych, dostępnych i bezpiecznych rozwiązań blockchain.

Część 4: Mając na uwadze powyższe koncepcje, wyjaśnijmy teraz, dlaczego węzły wartownicze są ważne: problem sprawdzania oszustów, dlaczego dylemat walidatora jest trudniejszy niż myślisz i rozwiązanie!

Autorem jest Ed Felten, główny naukowiec w Arbitrum

W systemach blockchain powszechnym wzorcem projektowym jest zlecenie jednej stronie wykonania pewnej pracy i zdeponowanie depozytu za prawidłowe zachowanie, a następnie zaproszenie innych do sprawdzenia pracy i odebrania tego depozytu, jeśli przyłapią pracownika na oszustwie. Można to nazwać wzorcem projektowym „twierdzenie-wyzwanie”. Robimy to w Arbitrum i ostatnio widzieliśmy w wiadomościach propozycje takie jak Optimistic Rollup.

Na systemy te może mieć wpływ dylemat walidatora, który w zasadzie polega na obserwacji, że nie ma sensu sprawdzać czyjejś pracy, jeśli wiesz, że nie będzie oszukiwać, ale jeśli tego nie sprawdzisz, będzie to miało motywację do oszukiwania. Jeśli jesteś projektantem, chcesz udowodnić, że Twój system jest kompatybilny z systemami motywacyjnymi, co oznacza, że ​​jeśli wszyscy będą postępować zgodnie ze swoimi zachętami, nie dojdzie do oszustw. Jest to obszar, w którym intuicja może Cię zaprowadzić w błąd. Problem ten jest znacznie trudniejszy, niż się wydaje, jak się przekonamy, gdy rozpakujemy zachęty stron poniżej.

Super prosty model

Zaczynamy od zbudowania najprostszego modelu, jaki możemy. Załóżmy, że jest dwóch graczy. Osoba twierdząca składa oświadczenie, które może być prawdziwe lub fałszywe. Osoba sprawdzająca może sprawdzić twierdzenie osoby twierdzącej lub może zdecydować się nie robić nic, przypuszczalnie zakładając, że osoba twierdząca prawdopodobnie mówi prawdę. Zakładamy, że koszt sprawdzania wynosi C. Jeśli sprawdzający sprawdzi i stwierdzi, że sprawdzający oszukał, otrzyma nagrodę w wysokości R. (R obejmuje wszystkie korzyści naliczone przez egzaminatora w wyniku wyłapania oszukiwania. Obejmuje to korzyści zrealizowane „poza systemem”, a także wszelkie korzyści uzyskane dzięki zwiększeniu zaufania do systemu.) Jeśli osoba stwierdzająca nie zostanie złapana, Under oszukiwanie , sprawdzający traci L, na przykład dlatego, że osoba oszukująca może w oszukańczy sposób odebrać sprawdzającemu cenne przedmioty.

Teraz musimy się martwić dwoma zagrożeniami: przekupstwem i lenistwem. Przekupstwo to możliwość, że osoba stwierdzająca może przekupić sprawdzającego, aby nie sprawdzał, umożliwiając w ten sposób osobie stwierdzającej oszukiwanie bez wykrycia. Możemy temu zapobiec, upewniając się, że osoba asercyjna zdeponuje bardzo duży depozyt, który jest większy niż całkowita wartość w systemie i zapłaci weryfikatorowi w przypadku wykrycia oszustwa, tak że osoba asercyjna nie będzie chciała zapłacić kwoty wyższej niż nagroda weryfikatora Łapówka R . Zapobiegnie to przekupstwu, ale wymaga pełnego zabezpieczenia systemu, co może być bardzo kosztowne.

Kolejnym zagrożeniem jest lenistwo, ryzyko, że sprawdzający zdecyduje się nie sprawdzać pracy asertora. (Pamiętaj, że warcaby mogą udawać, że sprawdzają, ale tak naprawdę tego nie robią.) Przyjrzyjmy się zachętom dla warcabów, aby przekonać się, czy jest to rozsądna strategia.

Załóżmy, że osoba twierdząca oszukuje z prawdopodobieństwem X. Teraz narzędzie inspektora wygląda następująco:

• Jeśli recenzent sprawdzi: RX-C

• Jeżeli sprawdzający nie sprawdzi: -XL

Sprawdzanie ma sens tylko wtedy, gdy użyteczność sprawdzania jest większa niż użyteczność nie sprawdzania, czyli jeśli X > C/(R+L). Oto zła wiadomość: osoba stwierdzająca może losowo oszukiwać, z prawdopodobieństwem mniejszym niż C/(R+L), racjonalny sprawdzający nigdy tego nie sprawdzi, więc osoba twierdząca nigdy nie zostanie przyłapana na oszukiwaniu.

Podstawmy kilka liczb. Jeśli koszt sprawdzenia każdej transakcji wynosi 0,10 dolara, a osoba sprawdzająca otrzymuje nagrodę w wysokości 75 dolarów, jeśli wykryje oszustwo, ale traci 25 dolarów, jeśli nie wykryje oszustwa, wówczas osoba stwierdzająca może bezkarnie oszukiwać tysiąc razy. Jeśli chcemy, żeby ten system obsługiwał tysiące transakcji, to mamy duży problem. Oczywiście w tym modelu nie możemy nic zrobić, aby zmniejszyć prawdopodobieństwo oszustwa do zera. Możemy jedynie mieć nadzieję na system nadzabezpieczenia, w wyniku którego mianownik C/(R+L) stanie się większy.

To zaskakująco solidny wynik – w złym tego słowa znaczeniu. Nie zależy to wcale od bodźców osoby twierdzącej. Dopóki osoba twierdząca uzyska niezerową przewagę w wyniku udanego oszustwa, może to zrobić z pewnym prawdopodobieństwem, wiedząc, że sprawdzanie nie jest warte wysiłku sprawdzającego. Wynik ten nie zależy też od tego, ile czasu dajemy inspektorowi na wykonanie pracy ani od tego, czy płacimy za (rzekomego) inspektora. Być może teraz myślisz, że problem polega na tym, że jest tylko jeden inspektor. Czy dodanie większej liczby pionków zmniejszyłoby prawdopodobieństwo oszukiwania? Co zaskakujące, tak nie jest.

Dodanie cenzorów nie pomaga zapobiegać oszustwom

Ponownie sformułujmy najprostszy model. Obecnie jest dwóch inspektorów działających niezależnie. Każdy sprawdzający płaci C, jeśli sprawdza, a jeśli ktoś sprawdzi i przyłapie osobę potwierdzającą na oszustwie, nagroda w wysokości R zostanie wypłacona zwycięskiemu sprawdzającemu lub jeśli obaj sprawdzili, nagroda zostanie równo podzielona między nich. (Jeśli chcesz, możesz dać jednemu z nich losową pełną nagrodę R w przypadku, gdy wszyscy sprawdzą. Nie ma to wpływu na niczyją strategię ani wyniki.) Tak jak poprzednio, każdy sprawdzający straci L, jeśli osoba twierdząca oszukuje bez uzyskania złapany.

Pozostaje faktem, że jeśli osoba stwierdzająca oszukuje w danym momencie mniej niż C/(R+L), wówczas sprawdzającemu nie opłaca się sprawdzać, ponieważ użyteczność sprawdzania jest mniejsza niż użyteczność niesprawdzania. W rzeczywistości problem z motywacją jest większy niż poprzednio, ponieważ koszt sprawdzenia na sprawdzającego nadal wynosi C, ale oczekiwana nagroda za pomyślnego wyłapania oszustwa przez sprawdzającego jest mniejsza niż R, ponieważ czasami trzeba podzielić nagrodę – oczekiwana nagroda będzie być w R/2 i R. Jeśli oczekiwaną nagrodą jest bR, gdzie b mieści się w przedziale od 0,5 do 1, wówczas osoba twierdząca może oszukiwać do C/(bR+L) w danym momencie – jest to oszustwo bardziej niewykryte, niż gdyby był tylko jeden sprawdzający! (Matematyka staje się nieco skomplikowana, ponieważ wartość b zależy od strategii sprawdzającego, a jego strategia zależy od b, ale powinno być jasne, że czasami będzie musiał podzielić nagrodę. Zmniejsza się także efektywna wartość L , ponieważ nikt tego nie robi. Warcaby nie mogą stracić L za sprawdzenie przez innych warcabów).

Jednym z miejsc, w którym dodanie cenzorów naprawdę pomogłoby, jest zapobieganie przekupstwu. Mając dwa pionki, asercjator musi zapłacić łapówkę w wysokości większej niż R każdemu asertorowi, co powoduje, że łapówka jest dwukrotnie droższa, co pozwala na 50% stawki zamiast pełnej stawki. Ale kompromisem jest to, że ilość oszustw wzrasta.

Nie będę tu wdawał się w całą matematykę, ale przy rozsądnych założeniach zwiększenie liczby pionków z jednego pionka do dwóch może skutkować 50% wzrostem liczby niewykrytych oszustw.

Dodanie cenzorów pogarsza sytuację!

Możesz dodać więcej warcabów, a sytuacja się pogorszy. Wraz ze wzrostem liczby sprawdzających, sprawdzający musi się bardziej martwić, że nagroda zostanie podzielona na wiele sposobów, więc oczekiwana nagroda za każdego pomyślnego sprawdzania stopniowo maleje, powodując stopniowy wzrost prawdopodobieństwa, że ​​osoba twierdząca bezpiecznie oszuka. Z tej perspektywy najgorszy scenariusz jest taki, że cenzorem może zostać każdy na świecie. Nie jest to nieskończenie złe, ponieważ sytuacja się pogarsza w miarę dodawania kolejnych cenzorów, ale z pewnością nie pomoże to w zapobieganiu oszustwom, nawet jeśli skutecznie wyeliminuje ryzyko przekupstwa.

Czy jesteś pewien, że Twój system jest kompatybilny z systemem motywacyjnym?

Jeśli masz system, który pasuje do tego typu modelu i uważasz, że jest zgodny z systemami motywacyjnymi, musisz dokładnie przemyśleć, dlaczego. W szczególności musisz wyjaśnić, dlaczego sprawdzający miałby wykonać zadanie sprawdzenia, nawet jeśli uważa, że ​​osoba stwierdzająca raczej nie oszuka. Samo nałożenie dużej kary za oszustwo nie wystarczy. Samo posiadanie nagrody za łapanie oszustów nie wystarczy. Samo posiadanie wielu warcabów nie wystarczy – w rzeczywistości może pogorszyć sytuację. Dlaczego Twój system jest odporny?

To wyzwanie dotyczy systemów takich jak Optimistic Rollup. Kiedy mówimy o Arbitrum, dotyczy to również nas.

W związku z powyższym tradycyjne metody sprawdzania zachęt nie dają pożądanych rezultatów – istnieje bazowy wskaźnik oszustw, poniżej którego sprawdzający uznają sprawdzenie za nieopłacalne. Podsumowując:

Jest dwóch graczy: osoba twierdząca, która formułuje twierdzenie, czy jest ono prawdziwe, czy fałszywe, oraz osoba sprawdzająca, która może sprawdzić twierdzenie pewnym kosztem obliczeniowym. Jeśli sprawdzający sprawdza, jego użyteczność wynosi RX-C, jeśli nie sprawdza, jego użyteczność wynosi -XL, gdzie R to nagroda za wyłapanie oszustwa, C to koszt sprawdzenia, a L to strata sprawdzającego z powodu niewykrycia oszustwa , X to prawdopodobieństwo, że osoba twierdząca oszukuje (wybrane przez osobę twierdzącą). Niektóre algebry pokazują, że jeśli

Aby rozwiązać ten problem i stworzyć sytuację, w której recenzent kierowany motywacją zawsze będzie sprawdzał, musimy zmienić motywację recenzenta. Podstawowy problem polega na tym, że w pierwotnym modelu wszystkie pozytywne zachęty dla warcabów do sprawdzania są proporcjonalne Jeśli chcemy zachęty do sprawdzenia, która działa niezależnie, musimy stworzyć zachętę do sprawdzenia lub zachętę do niesprawdzania, niezależną od działań osoby stwierdzającej.

TrueBit próbuje to zrobić, dodając celowo fałszywe twierdzenia do zestawu twierdzeń, zasadniczo zastępując X X plus stała. Z tym podejściem wiążą się pewne problemy. (Oryginalny artykuł Arbitrum zawiera sekcję poświęconą kwestiom motywacyjnym TrueBit.)

Skoncentruj się na wyzwaniach

Stosujemy inne podejście, które nazywamy koncentracją na wyzwaniu. Pomysł jest taki, że jeśli asercja oblicza wartość f(x), najpierw wystawia x i wyzwanie kryptograficzne. Aby poprawnie odpowiedzieć na wyzwanie, egzaminator musi znać f(x). Dopiero po wystąpieniu wyzwania osoba stwierdzająca publikuje f(x) — w tym momencie osoba sprawdzająca wykonała już ciężką pracę polegającą na obliczeniu f(x), więc nie ma motywacji do lenistwa. (Więcej szczegółów umowy poniżej.)

Aby zmniejszyć liczbę wymaganych transakcji w łańcuchu, ustalimy wszystko w taki sposób, aby prawidłową reakcją na wyzwanie sprawdzającego było zwykle milczenie. Jednak w rzadkich przypadkach kontroler musi opublikować bardzo małą transakcję w łańcuchu. Jeżeli sprawdzający udzieli błędnej odpowiedzi – cisza, kiedy należy puścić, lub cisza, kiedy należy puścić – straci niewielką kaucję.

Dostosujmy oryginalny model motywacyjny, aby uwzględnić wyzwania związane z uwagą. Potrzebujemy dwóch nowych parametrów (oba możemy wybrać): P, procent czasu, w jakim publikowana jest poprawna odpowiedź sprawdzającego, oraz A, kara, jeśli sprawdzający udzieli błędnej odpowiedzi. Teraz narzędziem inspektora jest:

Jeśli zaznaczone: RX-C

Jeśli nie, sprawdź: -LX-PA

Kluczową obserwacją jest to, że dopóki PA > C, optymalną strategią jest sprawdzanie, niezależnie od tego, jakie jest X (prawdopodobieństwo oszukiwania).

Bardzo niski koszt

Aby ocenić koszt, spójrzmy na konkretny przykład. Załóżmy, że co pięć minut następuje potwierdzenie, a koszt sprawdzenia wynosi 0,001 USD. Jeśli ustawimy prawdopodobieństwo P na 0,3%, sprawdzający będzie musiał wpłacić depozyt w wysokości 3 dolarów. Koszt jednej asercji weryfikatora wynosi 0,0003 dolara opłaty za benzynę (opłata za gaz w wysokości 0,10 dolara za przesłanie niecichej odpowiedzi pomnożona przez prawdopodobieństwo wysłania 0,3% przez sprawdzającego) plus około 0,0003 dolara za zablokowanie zakładu o wartości 3 dolarów na pięć minut. koszt odsetek wynosi 0,0006 USD za stwierdzenie.

Rozszerzenie dla wielu inspektorów

Wyzwanie skupienia uwagi dobrze sprawdza się w przypadku wielu egzaminatorów. Protokół stwarza wyzwanie, które wpływa na każdy kontroler w różny sposób, zmuszając każdy kontroler do samodzielnego obliczenia f(x). Koszt każdego sprawdzającego będzie taki sam (w naszym przypadku 0,0006 USD za asercję).

W systemie otwartym każdy może sprawdzić obliczenia i możesz pozwolić każdemu na zarejestrowanie się jako sprawdzający i złożenie wymaganej niewielkiej wpłaty. Dzięki temu będą mogli otrzymać wyzwania związane z uwagą i potencjalnie otrzymać wynagrodzenie od twórców dapp. Każdy może zakwestionować błędne twierdzenia osoby twierdzącej, ale tylko zarejestrowani egzaminatorzy stają w obliczu wyzwań związanych z uwagą.

Szczegóły techniczne umowy

Teraz, gdy rozumiemy, co może dla nas zrobić skupienie się na wyzwaniach, przyjrzyjmy się technicznym szczegółom ich działania.

Każdy sprawdzacz posiada klucz prywatny k i odpowiadający mu klucz publiczny gᵏ, zdefiniowany w odpowiedniej grupie. Klucz publiczny każdego kontrolera jest znany każdemu. Będziemy także polegać na odpowiedniej funkcji skrótu H.

Aby rzucić wyzwanie obliczeniu f(x), gdy funkcja f jest znana z góry, osoba twierdząca generuje losową wartość r, a następnie podaje (x, gʳ) jako wyzwanie.

Sprawdzający posiadający klucz prywatny k powinien odpowiedzieć na wyzwanie publikując małą transakcję tylko wtedy, gdy H(gʳᵏ, f(x)) < T, gdzie T jest odpowiednio wybranym progiem. Zauważ, że tylko osoba twierdząca (znająca r) i ten konkretny sprawdzający (znający swój klucz prywatny k) mogą obliczyć skrót, ponieważ tylko oni mogą obliczyć gʳᵏ. Należy również pamiętać, że obliczenie skrótu wymaga znajomości f(x).

Gdy sprawdzający będą mieli trochę czasu na opublikowanie swoich odpowiedzi na wyzwanie, osoba stwierdzająca może opublikować swoje f(x) i jeśli którykolwiek sprawdzający się z tym nie zgodzi, zostanie zakwestionowane w zwykły sposób. W tym momencie osoba stwierdzająca może oskarżyć dowolnego sprawdzającego o nieprawidłowe odpowiedzi; osoba stwierdzająca musi wydać r, aby uzasadnić swoje oskarżenie. Górnik lub kontraktor może sprawdzić, czy oskarżenie jest słuszne i ukarać sprawcę naruszenia, ale jeśli twierdzenie osoby twierdzącej dotyczące f(x) nie zostanie ostatecznie zaakceptowane jako prawidłowe, oskarżenie zostanie zignorowane. Jeżeli którykolwiek z sprawdzających zostanie ukarany grzywną, atakujący otrzyma połowę utraconych środków, a druga połowa zostanie zniszczona.

Takie podejście zapewnia egzaminatorowi odpowiednie zachęty. Wiedza o tym, jak sprawdzający powinien odpowiedzieć na wyzwanie, wymaga znajomości klucza prywatnego sprawdzającego i f(x), więc każdy sprawdzający będzie chciał obliczyć f(x). Jeśli moduł sprawdzający sam nie obliczy f(x), nie może bezpiecznie wymusić stosowania protokołu. Odpowiedzi innych kontrolerów nie są przydatne przy określaniu f(x), ponieważ opierają się na kluczach prywatnych tych kontrolerów. Jeśli sprawdzający polega na tym, że ktoś inny mówi mu f(x), nie ma możliwości sprawdzenia deklarowanej wartości (poza obliczeniem samego f(x)), a sprawdzający ryzykuje karę, jeśli się myli. Istnieje nawet zachęta dla jednej strony, aby próbowała wprowadzić sprawdzającego w błąd co do f(x) - jest to osoba twierdząca, która czerpie korzyści z błędu sprawdzającego i może wykorzystać te zyski do przekupywania „przyjaciół” sprawdzającego w celu dostarczenia sprawdzającemu informacji Błędne informacja.

Optymalizacja i wnioski

Istnieje kilka sztuczek, dzięki którym ten protokół będzie bardziej skuteczny. Na przykład możemy połączyć asercję z kolejnym wyzwaniem w transakcję w łańcuchu, tak aby wyzwanie nie zwiększało liczby transakcji. Jeśli P jest małe (np. 0,3% w naszym przykładzie), a liczba warcabów nie jest zbyt duża, wówczas warcaby rzadko muszą zapisywać transakcje w łańcuchu, więc ogólny wpływ protokołu na liczbę transakcji w łańcuchu będzie być najmniejszy.

Dzięki sprytnej implementacji koszt tego protokołu powinien być bardzo niski w porównaniu z początkowym kosztem wydawania potwierdzeń w łańcuchu. W naszym przypadku dodanie wyzwań związanych z uwagą do istniejącego protokołu potwierdzania i kwestionowania zwiększa całkowity koszt o mniej niż 1%.

A korzyści są znaczne – otrzymujemy protokół sprawdzania zgodny z motywacją, który jest odporny na dylemat walidatora. Dopóki przynajmniej jeden sprawdzający będzie racjonalny, twierdzenia osoby twierdzącej będą zawsze sprawdzane.

Pozostałe informacje na temat projektu można znaleźć w: Publiczny łańcuch gier Xai: baza danych Binance Square

Proszę podać następujące dane: