Wykorzystanie współdzielonego bezpieczeństwa w celu zapewnienia bezpiecznej interoperacyjności między łańcuchami

Biorąc pod uwagę, że ataki na mosty blockchain prowadzą do strat rzędu miliardów dolarów, nie dziwi fakt, że dyskusje na temat bezpieczeństwa międzyłańcuchowego często wywołują intensywne debaty. Wierzymy jednak w bardziej pragmatyczne podejście — takie, które obejmuje analizę problemu bezpiecznej interoperacyjności od podstaw i projektowanie mechanizmów zwiększających gwarancje bezpieczeństwa dla aplikacji międzyłańcuchowych i ich użytkowników.

W tym artykule przyjrzymy się koncepcji współdzielonego bezpieczeństwa i wyjaśnimy, w jaki sposób współdzielone projekty bezpieczeństwa (takie jak Lagrange State Committees) mogą obniżyć koszty bootstrappingu znaczących właściwości bezpieczeństwa dla protokołów interoperacyjności. Podczas gdy skupiamy się na współdzielonym bezpieczeństwie dla protokołów komunikacji międzyłańcuchowej, każda zdecentralizowana aplikacja — niezależnie od przypadku użycia — może wykorzystać tę nową technologię, aby osiągnąć wystarczającą decentralizację i minimalizację zaufania bez ponoszenia nadmiernych kosztów operacyjnych.

Nieformalne wprowadzenie do współdzielonego bezpieczeństwa

„Współdzielone bezpieczeństwo” odnosi się do bezpieczeństwa, które protokół czerpie z zewnętrznego źródła. W schemacie współdzielonego bezpieczeństwa zasoby zgromadzone przez uczestników jednego protokołu (np. kapitał lub moc obliczeniowa) są wykorzystywane do tworzenia bezpieczeństwa ekonomicznego dla innego protokołu. Współdzielone bezpieczeństwo różni się od standardowego modelu, w którym każda sieć odpowiada za swoje bezpieczeństwo.

Publiczne blockchainy, takie jak Bitcoin i Ethereum, łączą algorytmy konsensusu z mechanizmami odporności na Sybil — takimi jak Proof of Work lub Proof of Stake — aby zagwarantować żywotność i jednocześnie zwiększyć koszt ataków przeciwnika (np. ataków Sybil , ataków dalekiego zasięgu , ataków Eclipse , ataków typu time-bandit i ataków korupcyjnych ).

Choć systemy współdzielonego bezpieczeństwa działają inaczej, ich cele zwykle skupiają się wokół dwóch zadań:

• Zwiększenie efektywności kapitałowej w sieciach blockchain bez tworzenia dodatkowego ryzyka (kumulowanie ryzyka) lub wprowadzania dodatkowych założeń dotyczących bezpieczeństwa.
• Poprawa wydajności sieci blockchain (szczególnie nowych protokołów) w celu obrony przed nieprawidłowymi przejściami stanów, reorganizacjami, odpornością na cenzurę i innymi atakami na żywotność i bezpieczeństwo protokołu.

Wspólne bezpieczeństwo nie jest dokładnie nową koncepcją; na przykład merge-mining został wprowadzony w 2011 r., umożliwiając górnikom korzystanie z tego samego kryptograficznego Proof-of-Work (PoW) do tworzenia bloków na dwóch (lub więcej) różnych łańcuchach PoW implementujących konsensus Nakamoto . Pozwoliło to nowszym protokołom opartym na PoW (takim jak Namecoin i Rootstock), których natywne tokeny nie zyskały wystarczającej wartości, aby przyciągnąć znaczące zainteresowanie górników, na dzielenie się bezpieczeństwem poprzez ponowne wykorzystanie zasobów obliczeniowych przeznaczonych do zabezpieczania sieci Bitcoin w celu zwiększenia trudności bloków w nowym protokole.

To powiedziawszy, merge mining jest uważany za słabą formę bezpieczeństwa ekonomicznego dla zdecentralizowanych sieci ze względu na brak rozliczalnego bezpieczeństwa. W literaturze akademickiej rozliczalne bezpieczeństwo odzwierciedla zdolność protokołu do wykrywania węzłów, które (można udowodnić) naruszają zasady protokołu i karania złośliwych zachowań. Na przykład protokoły oparte na Proof of Stake wymagają, aby węzły blokowały zabezpieczenia (poprzez obstawianie natywnego tokena protokołu) przed uczestnictwem w konsensusie i mogą zniszczyć/zamrozić („pociąć”) te zabezpieczenia, jeśli pojawią się dowody niewłaściwego zachowania walidatora.

W przypadku merge mining, węzły, które celowo akceptują nieprawidłowe bloki w merge-mined chain, nie mogą być wiarygodnie wykryte. Co więcej, nie można ukarać wspomnianych węzłów (nawet jeśli byłoby możliwe ich zidentyfikowanie), ponieważ wymagałoby to drastycznych środków, takich jak spalenie lub zniszczenie sprzętu górniczego. Podczas gdy groźba utraty wartości tokena merge-mined chain z powodu ataków na jego bezpieczeństwo może wydawać się wystarczająca, aby zniechęcić do zachowań bizantyjskich, złośliwi górnicy mają mniej do stracenia, ponieważ wartość oryginalnego łańcucha (np. Bitcoin) prawdopodobnie nie zostanie naruszona.

Nowoczesne pojęcia współdzielonego bezpieczeństwa nie tylko ewoluowały, aby uwzględnić odpowiedzialne bezpieczeństwo, ale także przeszły na używanie innej jednostki inwestycyjnej — kapitału — jako podstawy współdzielonego bezpieczeństwa. W tym projekcie istnieje protokół bazowy, który zapewnia bezpieczeństwo dla innych protokołów PoS zbudowanych na nim; węzły najpierw dołączają do sieci podstawowej (poprzez zablokowanie natywnego tokena sieci jako stawki), zanim wezmą udział w zabezpieczaniu sieci drugorzędnej.

Projekt ten może przybierać różne formy:

• Walidatorzy uczestniczą jednocześnie w sieci podstawowej i sieci pomocniczej
• Podzbiór walidatorów (z sieci głównej) jest losowo wybierany w celu walidacji i zabezpieczenia sieci pomocniczej
• Sieć wtórna jest zabezpieczona przez niezależny zestaw walidatorów połączonych z siecią pierwotną
• Walidatorzy z sieci głównej ponownie delegują zainwestowany kapitał do walidatorów z sieci drugorzędnej

Niezależnie od szczegółów implementacji, kluczowym szczegółem dla współdzielonych schematów bezpieczeństwa opisanych powyżej jest to, że protokół bazowy musi mieć środki karania walidatorów, którzy działają złośliwie w sieci wtórnej. Ponieważ jest mniej kapitału zabezpieczającego sieć wtórną, możliwość złośliwego przejęcia protokołu przez superwiększość jest prawdziwym zmartwieniem.

Rozwiązaniem jest zapewnienie, że jeden lub więcej uczciwych uczestników (tworzących mniejszość) może pociągnąć większość do odpowiedzialności poprzez zainicjowanie sporu i opublikowanie dowodów zachowania naruszającego protokół w warstwie bazowej. Jeśli protokół bazowy (działający jako „sędzia”) zaakceptuje te dowody, nieuczciwe strony mogą zostać ukarane poprzez obniżenie zabezpieczenia (przedstawionego jako obligacja) w sieci głównej. Co ważne, warstwa bazowa musi jedynie zweryfikować dostarczone dowody i nie musi wykonywać dodatkowego konsensusu przed rozstrzygnięciem sporów — zmniejszając narzut koordynacyjny.

Bardziej subtelnym punktem jest to, że niewłaściwe zachowanie musi być przypisane jakiejś stronie, aby mechanizmy cięcia były skuteczne. W sieciach opartych na PoS walidatorzy muszą wygenerować parę kluczy publicznych i prywatnych, która służy jako unikalna tożsamość kryptograficzna w ramach protokołu konsensusu. Podczas rutynowych obowiązków, takich jak proponowanie bloków lub poświadczanie (ważności) bloków, walidator podpisuje dane bloku swoim kluczem prywatnym — skutecznie wiążąc je z tym wyborem.

Dzięki temu możliwe jest ukaranie walidatora za różne działania, które mogłyby zostać uznane za atak na bezpieczeństwo lub żywotność protokołu (lub jedno i drugie w niektórych przypadkach):

• Podpisanie dwóch sprzecznych bloków w tym samym okresie (formalnie znane jako „ekwiwokacja”)
• Podpisanie nieważnej blokady (niezależnie od tego, czy w trakcie składania wniosku, czy poświadczenia)
• Cenzurowanie jednej lub większej liczby transakcji
• Ukrywanie części lub całości danych bloku

Podczas gdy pierwsze dwa przestępstwa można wykryć w ten sam sposób (poprzez odzyskanie klucza publicznego walidatora z jego podpisu), dwa ostatnie wymagają innych mechanizmów, takich jak listy inkluzji i kody kasowania . We wszystkich przypadkach wykorzystanie kryptografii umożliwia niezawodne wykrywanie i karanie złośliwych zachowań, które mogłyby obniżyć pewne pożądane właściwości bezpieczeństwa w protokole — takie jak odporność na cenzurę i ważność transakcji. Zapewnia to pewien kontekst dotyczący znaczenia „bezpieczeństwa kryptoekonomicznego”, które obejmuje łączenie mechanizmów kryptograficznych z zachętami ekonomicznymi w celu zabezpieczenia zdecentralizowanych sieci.

Możemy zilustrować tę ideę — i porównać ją do merge-miningu — na przykładzie nowego blockchaina PoS, który dzieli bezpieczeństwo Ethereum. Nasz protokół zabawkowy ma następujące właściwości (zauważ, że jest to zbyt uproszczony przykład użyty w celach ilustracyjnych):

• Operatorzy węzłów są zobowiązani do zdeponowania określonej liczby tokenów ETH jako zabezpieczenia w inteligentnym kontrakcie Ethereum przed zarejestrowaniem się jako walidatorzy w sieci PoS
• W ciągu epok proponujący bloki w protokole PoS przesyłają skróty nagłówków bloków (zawierające podpisy walidatorów) do Ethereum, przechowując je w inteligentnym kontrakcie
• Bezpieczeństwo opiera się na dowodach oszustwa — łańcuch nadrzędny (Ethereum) nie weryfikuje przejść stanu, ale może zweryfikować kontrprzykład pokazujący, że określone przejście stanu jest nieprawidłowe
• Mechanizm cięcia w łańcuchu jest aktywowany, jeśli jedna lub więcej stron kwestionuje konkretną zmianę stanu

Teraz załóżmy, że złośliwa większość węzłów w sieci wtórnej zmówi się, aby sfinalizować nieprawidłowy blok w celu kradzieży środków zdeponowanych w kontrakcie mostowym. W tym scenariuszu uczciwy walidator uruchomiłby mechanizm cięcia łańcucha w Ethereum, publikując dowód oszustwa i identyfikując walidatorów naruszających protokół. Jeśli zasady protokołu pozwalają na cięcie całego udziału walidatora, wówczas koszt uszkodzenia łańcucha PoS jest proporcjonalny do kwoty zakładu postawionego przez większość walidatorów.

Ten przykład pokazuje, jak odpowiedzialne bezpieczeństwo wspiera wspólne projekty bezpieczeństwa i skutecznie pozwala na zabezpieczenie mniejszych sieci przez większe protokoły, które mają bootstrapping znaczącego bezpieczeństwa ekonomicznego i mogą pochwalić się wyższymi poziomami decentralizacji i braku zaufania. Możemy również zauważyć, że mechanizmy Proof-of-Stake prowadzą do wspólnych projektów bezpieczeństwa z silniejszymi pojęciami bezpieczeństwa w porównaniu z merge-mining (który wykorzystuje moc obliczeniową jako podstawę bezpieczeństwa ekonomicznego).

Ponadto wprowadza pomysł nowego protokołu wykorzystującego token innej sieci do stakingu w celu złagodzenia „problemu bootstrappingu” (gdzie nowy protokół blockchain ma niskie bezpieczeństwo ekonomiczne, ponieważ jego token nie uzyskał wystarczającej wartości). Podczas gdy problem bootstrappingu można rozwiązać za pomocą podejść — takich jak merge-mining — które wykorzystują inwestycje sprzętowe jako jednostkę bezpieczeństwa ekonomicznego, ten typ współdzielonego bezpieczeństwa jest suboptymalny z pewnych powodów (niektóre z nich zidentyfikowaliśmy wcześniej):

• Inwestycje kapitałowe — które mają nakładać znaczne koszty na złośliwe zachowania w celu walidacji węzłów — są ukryte i trudne do wykorzystania w celu zapewnienia bezpieczeństwa ekonomicznego. Ujawnienie inwestycji kapitałowych w przypadku scalania PoW wymagałoby drastycznych środków, takich jak zniszczenie sprzętu górniczego w przypadku prawdopodobnie złośliwego zachowania, co jest nierealne w rzeczywistych sytuacjach i trudne do wykorzystania.
• Merge-mining (lub jakikolwiek współdzielony projekt bezpieczeństwa, w którym udział w konsensusie jest powiązany z działającą infrastrukturą) jest trudny do skalowania. Na przykład istnieje górna granica liczby łańcuchów PoW, które można jednocześnie merge-minować, zanim ROI górnika zacznie spadać.

Natomiast systemy współdzielonego bezpieczeństwa oparte na PoS, w których inwestycje kapitałowe stanowią jednostkę inwestycji, mają pewne właściwości przydatne przy efektywnym i skutecznym rozwiązywaniu problemu bootstrappingu nowych sieci:

• Inwestycje kapitałowe są wyraźne (uczestnicy inwestują kapitał w zakup tokenów, aby spełnić wymagania dotyczące zabezpieczenia) i mogą być wykorzystywane do silnych i konkretnych gwarancji bezpieczeństwa ekonomicznego. Na przykład łatwo sobie wyobrazić, że protokół prawdopodobnie będzie bezpieczniejszy, gdy ma stawkę o wartości 1 ETH zabezpieczającą transakcje o wartości 0,9 ETH niż gdy stawka o wartości 0,9 ETH zabezpiecza transakcje o wartości 1 ETH.
• Ponieważ udział w konsensusie jest powiązany z „czystą” inwestycją kapitałową, łatwiej jest skalować bezpieczeństwo ekonomiczne i zlecać walidatorom zabezpieczanie wielu protokołów bez ponoszenia nadmiernych kosztów koordynacji (szczególnie gdy wymagania sprzętowe są niskie).

Niemniej jednak każde podejście będzie miało wady i shared-security-via-staking nie jest wyjątkiem; na przykład określenie, ile zabezpieczeń walidatorzy powinni umieścić w protokole PoS, jest trudnym problemem do rozwiązania. Umieścimy to w kontekście, rozważając to stwierdzenie z poprzedniego akapitu: „ Łatwo sobie wyobrazić, że protokół prawdopodobnie będzie bezpieczniejszy, gdy ma stawkę o wartości 1 ETH zabezpieczającą transakcje o wartości 0,9 ETH, niż gdy stawka o wartości 0,9 ETH zabezpiecza transakcje o wartości 1 ETH”.

Choć stwierdzenie to wydaje się rozsądne, głębsza analiza ujawnia trudności w wyborze optymalnego wymogu dotyczącego obligacji:

• Wymaganie od walidatorów wpłaty 1 ETH w celu zabezpieczenia aktywów o wartości 0,9 ETH zmniejsza efektywność kapitału i skutkuje nadzabezpieczeniem.
• Zabezpieczenie transakcji o wartości 2 ETH przy udziale o wartości 1 ETH zmniejsza ekonomiczną przepustowość (lub „dźwignię”) w blockchainie PoS i skutkuje niedostatecznym zabezpieczeniem.

W idealnym scenariuszu projektant protokołu wolałby mieć 1 ETH stawki zabezpieczającej transakcje o wartości 1 ETH. Jednak takie równowagi są trudne do osiągnięcia w warunkach rzeczywistych z różnych powodów; na przykład ilość kapitału do zabezpieczenia na jednostkę czasu (funkcja wartości marginalnej transakcji na blok/epokę) jest dynamiczna. To sprawia, że ustalenie idealnej obligacji w systemie PoS jest bardzo trudnym problemem mechanizmu i ważnym czynnikiem dla schematów współdzielonych zabezpieczeń opartych na stawkach, takich jak ponowne obstawianie (które omawiamy w następnej sekcji).

Wspólne bezpieczeństwo dzięki ponownemu zajmowaniu i punktom kontrolnym

Ponowne obsadzanie

Restaking ma swoje korzenie w rehypothecation — praktyce w tradycyjnych finansach, w której pożyczkodawca wykorzystuje aktywa (wcześniej zastawione jako zabezpieczenie przez pożyczkobiorcę) jako zabezpieczenie nowej pożyczki. W tym przypadku nowy kontrahent przejmuje prawa do pierwotnego aktywa zabezpieczającego, tak że jeśli podmiot, który zaciągnął nową pożyczkę, nie spłaci jej, może wystawić aktywa na aukcję, aby odzyskać fundusze.

Jeśli zostanie wdrożone prawidłowo, rehipothecation może być przydatne. Na początek umożliwia wyższą efektywność kapitałową i płynność poprzez ponowne wykorzystanie aktywów — które w przeciwnym razie pozostałyby uśpione — w celu zabezpieczenia krótkoterminowego finansowania na działalność generującą zysk. Jeśli zysk z zaciągnięcia pożyczki przekroczy wartość rehipothecation collateral, wszystkie zaangażowane strony (pierwotny pożyczkobiorca, pożyczkodawca i pożyczkodawca pożyczkodawcy) odnoszą korzyści.

Rehypothecation wiąże się z dużym ryzykiem (część powodów, dla których praktyka ta w dużej mierze wyszła z łask wśród instytucji TradFi), zwłaszcza dla pierwotnego pożyczkobiorcy, który może stracić prawa do swojego majątku, gdy nastąpi likwidacja. Pożyczkodawca ponownie wykorzystujący zabezpieczenie również ponosi ryzyko, tym bardziej, jeśli jest zobowiązany do spłaty pożyczkobiorcom po tym, jak nowy kontrahent skonfiskuje zdeponowane zabezpieczenie z powodu niespłacenia pożyczki.

Innym ryzykiem jest to, które krótko opisaliśmy wcześniej i dotyczy kompromisu między nadmiernym zabezpieczeniem a niedostatecznym zabezpieczeniem. W przykładzie przedstawionym wcześniej, jeśli Bank B (bank Johna) wejdzie w nadmiernie lewarowaną pozycję — gdzie pożycza więcej niż wartość zabezpieczenia Johna — i poniesie stratę, trudno będzie spłacić pożyczkę od Banku B (lub zwrócić aktywa Johna). Bank B może zabezpieczyć się przed tym skrajnym przypadkiem, prosząc Bank A (bank Johna) o pożyczenie kwoty mniejszej niż wartość zabezpieczenia Johna; jednak zwiększa to nieefektywność kapitałową Banku A i zmniejsza zyski z ponownego zastawu zabezpieczenia Johna na samym początku.

Ten sam zestaw zalet i wad dotyczy również restakingu. Zanim przejdziemy dalej, ważne jest wyjaśnienie ważnego szczegółu: stawka restaker'a zawsze najpierw przechodzi przez protokół bazowy. Na przykład restaker na Ethereum będzie musiał albo zdeponować 32 ETH w kontrakcie Beacon Chain, albo delegować ETH do walidatora obsługiwanego przez usługę stakingu — w zależności od tego, czy zostanie użyte natywne restaking , czy liquid restaking .

Ogólnie rzecz biorąc, restaking w przypadku Ethereum obejmuje następujące elementy:

#1: Nadanie protokołowi ponownego stakowania praw własności (lub roszczenia) do stakowanych ETH

W natywnym restakingu walidator musi zmienić swój adres wypłaty na inteligentny kontrakt zarządzany przez protokół restakingu. W ten sposób zamiast środków trafiających bezpośrednio do walidatora po wyjściu z Beacon Chain, stawka przechodzi najpierw przez protokół restakingu, zanim trafi do walidatora (wkrótce zobaczymy, dlaczego tak się dzieje).

Możliwe jest również zdeponowanie wymiennych reprezentacji (pochodnych) stakowanych ETH w inteligentnych kontraktach protokołu ponownego stakowania (płynne ponowne stakowanie). Takie tokeny, nazywane „płynnymi tokenami stakowanymi”, są wydawane przez operatorów staking-as-service (np. RocketPool, Lido, Coinbase itp.) i reprezentują roszczenie do części ETH stakowanych przez walidatora (w tym dochód z nagród) i mogą być wymieniane w stosunku 1:1 na natywne tokeny ETH.

#2: Wyrażenie zgody na dodatkowe warunki cięcia narzucone przez protokół ponownego obstawiania

Protokół restakingu zazwyczaj działa jako „middleware”, do którego różne zdecentralizowane sieci i aplikacje mogą się podłączyć w celu zapewnienia bezpieczeństwa ekonomicznego. Zazwyczaj obejmują one protokoły, które wymagają pewnej formy walidacji przez zestaw stron — na przykład sieć Oracle — ale których natywny token nie zgromadził wystarczającej wartości, aby można go było wykorzystać w ustawieniu Proof of Stake.

Zamiast budować nowy zestaw walidatorów od podstaw, takie aplikacje mogą korzystać z usług istniejących walidatorów za pośrednictwem protokołu ponownego stawiania. Usługi mogą określać unikalne warunki cięcia w odniesieniu do ponownie zastawionego zabezpieczenia walidatora — które protokół ponownego stawiania może wymusić, ponieważ teraz kontroluje wycofanie walidatora — obniżając barierę bezpieczeństwa ekonomicznego.

Ważna uwaga: warunki cięcia AVS są niezależne od warunków cięcia egzekwowanych przez konsensus Beacon Chain Ethereum, więc stawka ETH walidatora może zostać obniżona, nawet jeśli nie popełnił przestępstwa, które można by obciąć na samym Ethereum. Może to prowadzić do tego, co opisujemy jako „układanie ryzyka”: w zamian za wyższą efektywność kapitałową sieć podstawowa dziedziczy dodatkowe ryzyko niż w innym przypadku. (Układanie ryzyka ma również implikacje dla samego protokołu EigenLayer, jak zobaczymy później).

#3: Otrzymywanie dodatkowych nagród

Restaking wymaga podjęcia znacznego ryzyka (np. ponownie stakowany walidator może zostać przypadkowo zredukowany z powodu błędu w mechanizmie redukcji w łańcuchu). Jednak podobnie jak rehypothecation odblokowuje płynność w TradFi, restaking może poprawić efektywność kapitału w ekosystemach PoS i wygenerować wyższy niż przeciętny zysk dla stakerów.

Opiera się to na fakcie, że usługi, które wykorzystały kapitał ponownie zajęty na bezpieczeństwo, muszą nagradzać walidatorów za ich usługi. Na przykład walidator ponownie zajęty uczestniczący w sieci Oracle otrzyma opłaty za walidację aktualizacji Oracle — a płatność będzie pochodzić z innych aplikacji stron trzecich, które polegają na usługach Oracle. Ponieważ walidatorzy nadal otrzymują nagrody z Beacon Chain, ponowne zajęcie umożliwia zarabianie dochodów z wielu protokołów PoS bez konieczności ponownego wdrażania świeżego kapitału w nowym ekosystemie.

Chociaż w tym przykładzie skupiamy się na restakingu Ethereum, inne protokoły Proof of Stake również zaimplementowały warianty restakingu, aby osiągnąć podobne cele (zmniejszenie kosztów uruchamiania nowych protokołów/aplikacji, poprawa efektywności kapitałowej i skalowanie bezpieczeństwa ekonomicznego). W rzeczywistości następna sekcja omawia EigenLayer — wiodący protokół restakingu Ethereum — zanim przejdziemy do omówienia restakingu w innych ekosystemach:

Warstwa własna

EigenLayer to protokół restakingu stworzony w celu rozszerzenia bezpieczeństwa ekonomicznego Ethereum w celu zabezpieczenia nowych rozproszonych aplikacji, sieci i protokołów (które zbiorczo opisuje jako „Actively Validated Services” lub w skrócie AVS). Jeśli przeczytałeś poprzednią sekcję opisującą przykład restakingu na Ethereum, to już rozumiesz działanie EigenLayer na wysokim poziomie; jednak dodamy nieco więcej szczegółów dla kontekstu.

Po ponownym zajęciu ETH (poprzez wskazanie poświadczeń wypłaty powiązanych z walidatorem na inteligentne kontrakty kontrolowane przez EigenLayer) walidator musi wykonać zadania określone przez AVS, którym chce operować. Na przykład, jeśli AVS jest łańcuchem bocznym, ponownie zajęty walidator musi uruchomić oprogramowanie klienckie dla łańcucha bocznego, aby wykonywać transakcje i weryfikować bloki, jednocześnie zdobywając nagrody za prawidłowe wykonywanie tych zadań. Bardziej ogólnie, zadania mogą się różnić w zależności od charakteru AVS:

• Przechowywanie danych w sieci dostępności danych

• Zatwierdzanie transakcji wpłat i wypłat dla mostu międzyłańcuchowego lub zatwierdzanie wiadomości dla protokołu przesyłania wiadomości międzyłańcuchowych

• Generowanie i weryfikowanie dowodów zerowej wiedzy dla aplikacji nastawionych na prywatność lub chronionej sieci płatności

• Przechowywanie i weryfikowanie nagłówków bloków oraz uruchamianie przekaźników/wyroczni dla protokołów interoperacyjności międzyłańcuchowej

  
  

Spostrzegawczy czytelnicy zauważą dwie rzeczy: (a) zadania określone przez AVS mogą być całkiem dowolne (b) różne zadania określone przez AVS wymagają różnych poziomów inwestycji i wysiłku. Aby zilustrować ten ostatni punkt, można sobie wyobrazić, że przechowywanie nagłówków bloków w protokole międzyłańcuchowym będzie wymagało mniej miejsca na dysku/pamięci w porównaniu do przechowywania i dostarczania danych w sieci dostępności danych (nawet jeśli techniki takie jak próbkowanie dostępności danych zmniejszają obciążenie pamięci masowej na poszczególnych węzłach).

To jeden z powodów, dla których EigenLayer pozwala walidatorom, którzy dokonali ponownego zaliczenia, delegować wykonywanie zadań określonych przez AVS innej stronie (operatorowi), która dzieli się nagrodami zarobionymi z AVS z walidatorem. To podejście wiąże się z różnymi poziomami ryzyka dla walidatorów, którzy dokonali ponownego zaliczenia, w zależności od stopnia, w jakim ciężar cięcia — który może się zdarzyć, jeśli operator nie wykona poprawnie zadań AVS — jest dzielony między walidatora, który dokonał ponownego zaliczenia, a operatora zewnętrznego.

Każdy AVS określa zestaw warunków, w których udział restaker'a EigenLayer może zostać obniżony. Na przykład sieć dostępności danych implementująca mechanizmy Proof of Space/Storage może obniżyć udział operatorów, którzy nie przechowują danych przez uzgodniony czas. Obcięcie powoduje zamrożenie operatora w EigenLayer — uniemożliwiając dalszy udział w jednej lub większej liczbie aktywnie walidowanych usług — i ostatecznie redukcję salda ETH walidatora.

Aby doszło do slashingu, przestępstwo musi być udowodnione — co pozwala protokołowi bazowemu (w tym przypadku Ethereum) — rozstrzygać spory i karać nieuczciwą stronę. Obecna konstrukcja Ethereum pozwala na slashing do 50% udziału walidatora (16 ETH), co daje EigenLayer prawo do slashingu pozostałych 50% (16 ETH) w przypadku, gdy operator złamie zasady określone przez AVS podczas wykonywania zadań.

Mechanika cięcia EigenLayer sugeruje również subtelne ryzyko ponownego zajmowania: cięcie przez jedną usługę zmniejsza ogólne saldo walidatora w inteligentnych kontraktach EigenLayer i łańcuchu Beacon Ethereum. Co ważne, scenariusz skrajny pojawia się jednak, gdy cięcie następuje z powodu błędu w logice cięcia konkretnego AVS, a nie w wyniku udowodnionego przestępstwa. W tym przypadku utrata nagród za walidację głównego łańcucha Ethereum — zakładana jako wyższa niż nagrody za walidację AVS — sprawiłaby, że zwrot z inwestycji z ponownego zajmowania byłby suboptymalny z perspektywy walidatora.

Innym ryzykiem związanym z ponownym zastawem w stylu EigenLayer jest ryzyko nadmiernego zabezpieczenia i niedostatecznego zabezpieczenia przez walidatora oraz koncepcja kumulacji ryzyka. Z poprzedniego przykładu rehipothecation wynika, że strona rehipothecająca zabezpieczenie może być jednocześnie zadłużona u pierwszego pożyczkobiorcy (którego zabezpieczenie jest wykorzystywane do zaciągnięcia nowej pożyczki) i u ostatniego pożyczkodawcy w łańcuchu (który ma roszczenie do zabezpieczenia zastawionego przez pierwotnego pożyczkobiorcę).

Podobna dynamika może mieć miejsce w konstrukcjach restakingowych, takich jak EigenLayer, jeśli restakingowy walidator (umyślnie lub celowo) jednocześnie popełnia przestępstwa slashable w Beacon Chain Ethereum i jednym lub większej liczbie AVS. W zależności od tego, gdzie nastąpi pierwsze slashing, inne AVS mogą nie mieć już żadnych udziałów do slashingu — co skutecznie umożliwia atak bez ryzyka na aplikacje zabezpieczone przez EigenLayer.

Zespół EigenLayer uznał ten wektor ataku (patrz Załącznik B: Analiza ryzyka kryptoekonomicznego białej księgi EigenLayer ) i podjął szereg kroków w celu rozwiązania tego ryzyka. Obejmuje to zapewnienie formalnej heurystyki do oceny niedostatecznego zabezpieczenia i nadmiernego zabezpieczenia stakerów w AVS oraz wskazanie planów dostarczania informacji doradczych deweloperom AVS za pośrednictwem pulpitu zarządzania ryzykiem podczas uruchamiania.

Polkadot Parachains

Chociaż Polkadot jest znany głównie z umożliwiania interoperacyjności między heterogenicznymi blockchainami, w dużej mierze opiera się na współdzielonym bezpieczeństwie. W rzeczywistości współdzielone bezpieczeństwo jest powodem, dla którego różne łańcuchy w ekosystemie Polkadot mogą wymieniać wiadomości bez wprowadzania założeń zaufania lub narażania się na ryzyko bezpieczeństwa.

W Polkadot podzbiory walidatorów (mających postawione tokeny DOT w łańcuchu przekaźnikowym) są losowo przypisywane do parachainów (pomyśl o „łańcuchach podrzędnych”) w celu weryfikacji bloków — i powiązanego dowodu ważności (PoV) — generowanych przez collatora każdego parachaina. Collator to węzeł odpowiedzialny za wykonywanie transakcji parachaina i tworzy „parablok” wysyłany do grupy walidatorów parachaina w celu weryfikacji.

Ponieważ weryfikacja PoV bloku jest obliczeniowo intensywna, para-walidatory (nazwa walidatorów przypisanych do parałańcucha) otrzymują dodatkowe nagrody za ten obowiązek. Bloki zatwierdzone przez para-walidatory — lub dokładniej, kryptograficzne zobowiązania do tych bloków — są wysyłane w celu włączenia do Relay Chain (pomyśl o „łańcuchu nadrzędnym”). Blok parałańcucha staje się ostateczny, jeśli blok odwołujący się do niego zostanie zatwierdzony przez większość pozostałego zestawu walidatorów w Relay Chain.

Ostatni punkt jest dość istotny: ponieważ liczba walidatorów w każdym parachainie jest niska (około pięciu walidatorów na shard), koszt uszkodzenia poszczególnych shardów jest niski. Aby bronić się przed takimi atakami, protokół Polkadot wymaga, aby para-bloki przeszły wtórną kontrolę przez inną grupę losowo wybranych węzłów.

Jeśli okaże się, że blok jest nieprawidłowy lub niedostępny (tj. brakuje części danych), uczciwe węzły mogą zainicjować spór w głównym łańcuchu przekaźnikowym, w którym wszyscy walidatorzy łańcucha przekaźnikowego muszą ponownie wykonać sporny blok. Spór kończy się po zagłosowaniu ⅔ superwiększości walidatorów za jedną ze stron sporu, przy czym winni walidatorzy są usuwani w łańcuchu, jeśli ponowne wykonanie potwierdza roszczenie o usunięcie.

Mechanizm ten zapewnia, że wszystkie parachainy w protokole Polkadot mają ten sam poziom bezpieczeństwa, niezależnie od rozmiaru walidatora ustawionego na każdym fragmencie. Ponadto parachainy czerpią bezpieczeństwo z tego samego źródła (wszystkie parabloki są zatwierdzane przez Relay Chain), mogą ufać ważności wiadomości pochodzących ze zdalnego fragmentu (nie znając koniecznie szczegółów konsensusu lub stanu tego ostatniego).

Bezpieczeństwo międzyłańcuchowe

Bezpieczeństwo międzyłańcuchowe zostało opisane jako odpowiedź Cosmos na restaking i jest podobne do współdzielonego modelu bezpieczeństwa Polkadot. Podobnie jak w przypadku relacji między łańcuchem przekaźnikowym a parachainami w Polkadot, Cosmos przyjmuje model hub-and-spoke, w którym wiele łańcuchów („strefy Cosmos”) łączy się z głównym łańcuchem („Cosmos Hub”) i czerpie z niego bezpieczeństwo. Uzasadnienie jest również podobne do Polkadot: umożliwienie nowym łańcuchom zachowania bezpieczeństwa bez konieczności uruchamiania niezawodnego zestawu walidatorów od podstaw (dość trudne zadanie), a zamiast tego dzielenie się bezpieczeństwem ekonomicznym — połączonym na jednej warstwie — z innymi łańcuchami.

W obecnej wersji zabezpieczenia międzyłańcuchowe wymagają walidatora (posiadającego tokeny ATOM) do walidacji zarówno Cosmos Hub, jak i wszystkich łańcuchów konsumenckich z nim połączonych. Walidator działający złośliwie w łańcuchu konsumenckim ryzykuje utratą swojego udziału w łańcuchu dostawcy (w tym przypadku Cosmos Hub) na rzecz cięcia.

Zniszczenie naruszającego zasady walidatora zazwyczaj wymaga przekazania pakietu zawierającego dowody zachowań nadających się do zniszczenia za pośrednictwem kanału IBC (Inter-Blockchain Communication) między łańcuchem dostawcy a łańcuchem konsumenta. W ten sposób bezpieczeństwo międzyłańcuchowe można postrzegać jako formę ponownego zajęcia; ponadto osiąga ono kluczowy cel: ułatwia uruchamianie specyficznych dla aplikacji blockchainów w ekosystemie Cosmos.

Wcześniej projekty próbujące tworzyć suwerenne blockchainy musiały stworzyć natywny token do stakingu i przyciągnąć wystarczającą liczbę walidatorów, aby zapewnić nowym użytkownikom minimalne gwarancje bezpieczeństwa. Jednak bezpieczeństwo międzyłańcuchowe zapewnia, że bezpieczeństwo Cosmos Hub (zabezpieczone stawką ~2,5 mld USD w momencie pisania) można skalować, aby zabezpieczyć nowsze łańcuchy o niskiej wartości bez konieczności rozszerzania rozmiaru istniejącego zestawu walidatorów Cosmo.

Uwaga : Obecna wersja Interchain Security firmy Cosmos wyłącza slashing wyłącznie na podstawie pakietów przekazywanych przez łańcuchy konsumenckie ze względu na ryzyko, że złośliwy kod w łańcuchu konsumenckim wywoła transmisję fałszywych pakietów slash i slashing uczciwych walidatorów — zamiast tego przestępstwa takie jak podwójne głosowanie (podpisywanie dwóch bloków na tej samej wysokości) podlegają społecznemu slashingowi za pośrednictwem zarządzania. Społeczne slashing wiąże się jednak z własnymi ryzykami, jak widać w niedawnej debacie na temat slashingu walidatorów za podwójne podpisywanie w łańcuchu konsumenckim (co również sugeruje pewne zawiłości tworzenia współdzielonych protokołów bezpieczeństwa) .

Bezpieczeństwo sieciowe jest alternatywą dla bezpieczeństwa międzyłańcuchowego i ma na celu poprawę niektórych niedociągnięć tego ostatniego. Zamiast uruchamiać oprogramowanie zarówno dla łańcuchów dostawców, jak i konsumentów, walidator stakingowy w łańcuchu dostawców może delegować stake walidatorowi w łańcuchu konsumentów. To zdejmuje ciężar walidacji dwóch łańcuchów jednocześnie — uczestnicząc w zarządzaniu i konsensusie — i zmniejsza narzut dla ponownie stakowanych walidatorów (np. zmniejszając wymagania sprzętowe).

Podobnie jak EigenLayer (gdzie walidator Ethereum może mieć operatora, który waliduje jeden lub więcej protokołów drugorzędnych (AVS) w jego imieniu), walidator delegata nie musi stawiać żadnych stawek weryfikujących łańcuch konsumenta. Jeśli walidator delegata nie wykona prawidłowo swoich obowiązków (np. dozna przestoju lub utworzy/zagłosuje za nieprawidłowymi blokami), delegat zostaje odcięty od łańcucha konsumenta zgodnie z zasadami protokołu.

Bezpieczeństwo sieciowe różni się również od bezpieczeństwa międzyłańcuchowego, ponieważ pozwala łańcuchom konsumenckim na dzierżawę bezpieczeństwa od wielu łańcuchów dostawców (zamiast ograniczać się do Cosmos Hub) i pozwala walidatorom wybierać łańcuchy, do których delegują udziały. Podczas gdy ta druga funkcja jest planowana jako część wdrożenia ICS v2, pierwsza prawdopodobnie nie zostanie wdrożona (choć można argumentować, że jest bardziej przekonująca).

Komitet synchronizacji Ethereum

Komitet Sync Ethereum to grupa 512 walidatorów odpowiedzialnych za podpisywanie sfinalizowanych nagłówków bloków Beacon. Nowy Komitet Sync jest rekonstytuowany co 256 epok (około 27 godzin), a jego członkowie są wybierani z istniejącego zestawu walidatorów łańcucha Beacon. Należy pamiętać, że członkowie powinni kontynuować regularne obowiązki walidatorów (w tym atestację i propozycje bloków) podczas uczestnictwa w Komitecie Sync.

Komitet Sync został po raz pierwszy wdrożony podczas rozwidlenia Altair łańcucha Beacon, aby umożliwić klientom light weryfikację nowych bloków (bez znajomości pełnego zestawu walidatorów) i śledzenie zmian w stanie Ethereum. Ponieważ uczestnictwo w komitecie Sync wymaga większego wysiłku niż po prostu udział w konsensusie łańcucha Beacon, członkowie otrzymują niewielką nagrodę (oprócz regularnych nagród za wykonywanie obowiązków łańcucha Beacon).

Jednak członkowie, którzy podpisują się pod nieprawidłowymi nagłówkami bloków, nie podlegają cięciu — w przeciwieństwie do Beacon Chain. Główni deweloperzy Ethereum bronili tego projektu, mówiąc, że cięcie złośliwych członków Sync Committee wprowadziłoby więcej złożoności, podczas gdy inni zasugerowali trudność zmowy wśród ⅔ superwiększości członków Sync Committee (co byłoby potrzebne, aby oszukać lekkich klientów, aby zaakceptowali zły nagłówek bloku).

Jednak w przypadku aplikacji o wysokiej wartości — takich jak protokoły komunikacji międzyłańcuchowej — polegających na klientach light w celu śledzenia stanu Ethereum, temat cięcia komitetów synchronizacji za podpisywanie nieprawidłowych nagłówków bloków wzbudził odnowione zainteresowanie (por. trwająca propozycja zespołu klienta Nimbus ). Jeśli zostanie wdrożone, cięcie zamieni udział w komitecie synchronizacji w formę ponownego zajmowania, w ramach którego walidatorzy zdecydują się na dodatkowe warunki cięcia i otrzymają dodatkowe nagrody za drugorzędną usługę podpisywania nagłówków bloków.

Dla przykładu, walidator może zostać odcięty — do maksymalnego salda — jeśli naruszy zasady protokołu podczas uczestnictwa w Sync Committee, nawet jeśli działa uczciwie, uczestnicząc w konsensusie Beacon Chain. Możemy również porównać Sync Committee do systemu parachain Polkadot i innych form współdzielonego bezpieczeństwa, które losowo pobierają próbki z podzbioru węzłów, aby zweryfikować podprotokół w ramach większej sieci blockchain (np. Lagrange State Committees, Avalanche's Subnets i protokół State Proofs Algorand).

Punkt kontrolny

Wspólne schematy bezpieczeństwa oparte na punktach kontrolnych często obejmują łańcuch pochłaniający bezpieczeństwo, który w określonych odstępach czasu publikuje zobowiązania kryptograficzne do swojego najnowszego stanu w łańcuchu zapewniającym bezpieczeństwo . Na przykład, proponujący blok może być zobowiązany do opublikowania skrótu najnowszego nagłówka bloku w łańcuchu nadrzędnym przed jego sfinalizowaniem.

Zobowiązania te są określane jako „punkty kontrolne”, ponieważ łańcuch nadrzędny gwarantuje nieodwracalność historii łańcucha podrzędnego prowadzącej do tego punktu. Innymi słowy, łańcuch nadrzędny gwarantuje i wymusza (kanoniczne) uporządkowanie czasowe łańcucha podrzędnego, chroniąc go przed próbami reorganizacji bloków i tworzenia konfliktowego rozwidlenia (np. w celu przywrócenia starych transakcji i wykonania podwójnego wydatku).

Łańcuch nadrzędny może również gwarantować ważność łańcucha podrzędnego, zwłaszcza gdy nagłówki bloków zawierają informacje o tym, kto poświadczył/wyprodukował konkretny blok. Jeśli blok okaże się nieważny, uczciwy węzeł może rozpocząć wyzwanie w łańcuchu nadrzędnym (z łańcuchem nadrzędnym rozstrzygającym spór) i wywołać wycofanie stanu łańcucha podrzędnego.

Ponadto, jeśli mechanizm zarządzania stawkami walidatorów (taki jak inteligentny kontrakt) zostanie zaimplementowany w łańcuchu nadrzędnym, możliwe stanie się wyegzekwowanie odpowiedzialnego bezpieczeństwa poprzez cięcie walidatorów naruszających protokół po zaakceptowaniu ważnego dowodu oszustwa w łańcuchu. Ważne jest, aby łańcuch nadrzędny gwarantował kanoniczną historię łańcucha podrzędnego, ponieważ zapobiega to przepisywania historii przez węzły (poprzez usuwanie bloków) w celu ukrycia dowodów złośliwego zachowania.

Łańcuchy boczne commit (Polygon PoS), optimium (Arbitrum Nova/Metis), rollupy i łańcuchy zintegrowane z protokołami punktów kontrolnych, takimi jak Babylon, implementują tę formę współdzielonego bezpieczeństwa. We wszystkich przypadkach protokół czerpie swoje bezpieczeństwo ekonomiczne z zewnętrznego łańcucha blockchain, używając go jako warstwy rozliczeniowej (odpowiedzialnej za finalizowanie bloków). Dla kontekstu, Polygon PoS i Arbitrum Nova/Metis przechowują nagłówki w kontrakcie łańcuchowym na Ethereum, podczas gdy Babylon przesyła strumieniowo nagłówki z połączonych stref Cosmos do Bitcoin.

Rollupy warstwy 2 (L2) wykorzystują podobny mechanizm (publikowanie bloków źródłowych w blockchainie warstwy 1), z jedną zasadniczą różnicą: dane wymagane do odtworzenia bloków rollupu są również publikowane w warstwie rozliczeniowej. Oznacza to, że warstwa rozliczeniowa w pełni gwarantuje bezpieczeństwo rollupu (ostatecznie). Natomiast dane wymagane do odtworzenia stanu sidechaina zatwierdzenia lub optymistycznego łańcucha mogą być niedostępne — szczególnie w przypadku złośliwego sekwencera lub zestawu walidatorów wykonujących ataki polegające na wstrzymywaniu danych.

Wspólne zabezpieczenia dla protokołów interoperacyjności międzyłańcuchowej

Po przedstawieniu obszernego tła na temat znaczenia i ewolucji współdzielonego bezpieczeństwa możemy teraz zagłębić się w nowe granice w projektach współdzielonego bezpieczeństwa. Jednym z takich obszarów badań jest współdzielone bezpieczeństwo dla protokołów międzyłańcuchowych , które ma na celu udoskonalenie obecnych podejść do przesyłania wiadomości i łączenia między blockchainami poprzez wykorzystanie korzyści wspólnego (ekonomicznego) bezpieczeństwa.

Definicja ta może wywołać u czytelnika pytania, takie jak:

• Dlaczego tak wyraźnie skupiono się na protokołach interoperacyjności?

• Jakie korzyści protokół interoperacyjności czerpie z integracji ze współdzieloną technologią zabezpieczeń?

  
  

Lagrange Labs buduje Lagrange State Committees — wspólne rozwiązanie bezpieczeństwa dla protokołów, które wymagają dostępu do dowodów stanów międzyłańcuchowych o zminimalizowanym zaufaniu. (State Committees łączą system dowodów ZK Big Data firmy Lagrange i infrastrukturę ponownego zajmowania EigenLayer, aby utworzyć wspólną strefę bezpieczeństwa dla protokołów interoperacyjności międzyłańcuchowej). W związku z tym czujemy się zobowiązani do przeanalizowania każdego z poprzednich pytań i przy okazji przedstawienia argumentów na rzecz integracji aplikacji pomostowych, indeksujących i komunikacyjnych z infrastrukturą State Committee.

Krótki wstęp dotyczący protokołów interoperacyjności

W Interoperability For Modular Blockchains: The Lagrange Thesis wyjaśniliśmy, że protokoły interoperacyjności są kluczowe dla łączenia odizolowanych blockchainów i łagodzenia problemów związanych z fragmentacją płynności i stanu dla aplikacji blockchain (i ich użytkowników). Niektóre kluczowe przykłady wymienione w tym artykule obejmują:

• Mosty wdrażające mechanizmy blokowania i tworzenia monet lub spalania i tworzenia monet, umożliwiające przesyłanie aktywów z natywnego łańcucha bloków (gdzie zostały wydane) w celu wykorzystania w nienatywnym łańcuchu bloków

• Protokół komunikacyjny umożliwiający użytkownikom bezpieczne przekazywanie informacji (za pośrednictwem pakietów danych) między blockchainami, które nie mają jednego źródła prawdy i nie są w stanie wzajemnie weryfikować swoich stanów

  
  

Podkreśliliśmy również wartość różnych typów rozwiązań interoperacyjności blockchain . Na przykład mosty umożliwiają użytkownikom płynne poruszanie się między różnymi ekosystemami, uzyskanie dostępu do większej liczby aplikacji i zwiększenie efektywności aktywów (poprzez wykorzystanie możliwości generowania zysków, które istnieją w innych blockchainach). Protokoły komunikacyjne odblokowują również bardziej zaawansowane przypadki użycia, takie jak pożyczki międzyłańcuchowe, arbitraż międzyłańcuchowy oraz marże międzyłańcuchowe i międzyłańcuchowe, które polegają na przesyłaniu informacji (np. pozycji i profili zadłużenia) między różnymi domenami.

Choć zaprojektowane do różnych celów, wszystkie różne rozwiązania interoperacyjne mają pewne podstawowe właściwości. Najważniejszym z nich jest mechanizm weryfikacji, czy pewne informacje o blockchainie (blockchainach) zaangażowanym w transakcję/operację międzyłańcuchową — dostarczone przez użytkownika lub aplikację — są prawdziwe. Zazwyczaj jest to stwierdzenie, że istnieje określony stan (np. wartości przechowywane w magazynie inteligentnego kontraktu, saldo konta lub ostatnio sfinalizowany blok) lub że transakcja miała miejsce w innym łańcuchu.

Weźmy za przykład most między Ethereum i NEAR; operator mostu będzie musiał zweryfikować następujące informacje o stanie każdego łańcucha, gdy użytkownik łączy się z zasobem (np. DAI):

• Przed wybiciem tokenów nearDAI na adres NEAR użytkownika operator mostu potrzebuje dowodu, że wspomniany użytkownik zdeponował DAI na kontrakcie mostu na Ethereum
• Przed zwolnieniem pierwotnego depozytu DAI (podczas łączenia z NEAR do Ethereum) operator mostu potrzebuje dowodu, że dany użytkownik spalił tokeny nearDAI w NEAR i wysłał wymagane potwierdzenie „dowodu spalenia” do kontraktu mostu w NEAR

Protokół komunikatów między wyżej wymienionymi łańcuchami będzie miał podobne, ale nieco inne wymagania. Jeśli użytkownik Ethereum zażąda wykonania transakcji międzyłańcuchowej („wywołaj kontrakt X na NEAR”), protokół musi zweryfikować, czy żądanie komunikatu zostało pierwotnie złożone w Ethereum (zwykle poprzez wywołanie kontraktu w łańcuchu).

Prostym sposobem na sprawdzenie twierdzeń dotyczących transakcji międzyłańcuchowych jest uruchomienie pełnego węzła dla danego łańcucha. Pełne węzły, które pobierają transakcje z każdego bloku i ponownie wykonują przed zsynchronizowaniem najnowszego stanu łańcucha, są zazwyczaj najbardziej niewiarygodnym sposobem weryfikacji przejść stanu w dowolnym łańcuchu bloków. Jednak uruchomienie pełnego węzła jest zarówno żmudne, jak i niepotrzebne; żmudne, ponieważ pełne węzły wymagają wysokich wymagań sprzętowych, i niepotrzebne, ponieważ protokół międzyłańcuchowy potrzebuje tylko informacji istotnych dla niektórych zestawów transakcji i kontraktów.

Na szczęście klienci light zapewniają łatwy/skuteczny sposób śledzenia zdarzeń i zmian stanu bez konieczności uruchamiania pełnego węzła. Pod warunkiem, że ufamy projektowi klienta light, możemy po prostu pobrać nagłówki bloków, aby zweryfikować określone informacje, takie jak występowanie depozytów/wypłat w moście i status żądań wiadomości/wykonania w protokole przesyłania wiadomości.

Aby umożliwić komunikację między dwoma łańcuchami — które nazwiemy łańcuchem A i łańcuchem B — protokół interoperacyjności uruchomiłby lekkiego klienta łańcucha A na łańcuchu B, który przechowuje nagłówki bloków łańcucha B (i odwrotnie). Umożliwia to weryfikację różnych dowodów stanu/przechowywania (nagłówki bloków, dowody Merkle'a itp.) przekazywanych przez użytkowników (lub dowolną stronę trzecią) z aplikacji w łańcuchu źródłowym do innej aplikacji w łańcuchu docelowym. Lekki klient działa jako źródło informacji („wyrocznia”) o stanach dwóch łańcuchów bloków, jak pokazano na poniższym obrazku:

Jednak takie podejście do weryfikacji ważności stanów międzyłańcuchowych napotyka na problem zaufania. Artykuł Vitalika Buterina Trust Models podaje zwięzłą definicję zaufania: „ Zaufanie to wykorzystanie wszelkich założeń dotyczących zachowania innych osób”. W artykule zdefiniowano również pojęcie braku zaufania (z zastrzeżeniem):

Jedną z najcenniejszych właściwości wielu aplikacji blockchain jest brak zaufania: zdolność aplikacji do kontynuowania działania w oczekiwany sposób bez konieczności polegania na konkretnym aktorze, który będzie zachowywał się w określony sposób, nawet jeśli jego interesy mogą się zmienić i skłonić go do działania w inny, nieoczekiwany sposób w przyszłości. Aplikacje blockchain nigdy nie są całkowicie pozbawione zaufania, ale niektóre aplikacje są znacznie bliższe braku zaufania niż inne. — Vitalik Buterin

W naszym kontekście (interoperacyjność łańcucha bloków) zaufanie staje się nieuniknione, gdy stan dwóch lub więcej łańcuchów jest sprawdzany niezależnie od siebie. Rozważmy scenariusz, w którym aplikacja Boba w łańcuchu A otrzymuje dowód, że Alicja zainicjowała wiadomość („zablokuj 5 ETH w łańcuchu B i wydobądź 5 Wrapped ETH (WETH) w łańcuchu A”). Dowód wiadomości to dowód Merkle’a pokazujący uwzględnienie transakcji Alicji w bloku, który Bob — ponieważ uruchamia lekkiego klienta on-chain dla łańcucha B — może zweryfikować, porównując dowód z korzeniem Merkle’a transakcji uzyskanym z nagłówka prawidłowego bloku łańcucha B.

Jednakże „ważny” w kontekście bloku może oznaczać różne rzeczy: (a) „Nagłówek bloku należy do bloku zatwierdzonego przez większość walidatorów łańcucha źródłowego”. (b) „Nagłówek bloku należy do bloku, którego transakcje są ważne zgodnie z zasadami ważności transakcji łańcucha źródłowego”.

Bob może traktować #1 jako konkretny dowód ważności bloku, ale opiera się to na założeniach dotyczących walidatorów w łańcuchu źródłowym:

• „ Większość walidatorów w łańcuchu A jest uczciwa i nie zatwierdziłaby bloku z jedną lub większą liczbą nieprawidłowych transakcji”.
• „ Większość walidatorów w łańcuchu A to aktorzy kierujący się racjonalnym podejściem ekonomicznym, którzy mają niewielkie bodźce do zatwierdzania bloku z nieprawidłowymi transakcjami”.

Tutaj łatwo zobaczyć, gdzie jedno (lub oba) z tych założeń może się nie sprawdzić — na przykład, jeśli kwota stawki < wartość transakcji w łańcuchu A (np. kwota, która może zostać skradziona z mostu za pośrednictwem oszukańczych transakcji), walidatorzy mają motywację do sfinalizowania nieprawidłowego bloku — nawet jeśli oznacza to utratę środków — ponieważ zysk z ataku przewyższa koszty.

Ogólnie rzecz biorąc, każdy mechanizm weryfikacji stanów międzyłańcuchowych podlega założeniom zaufania (niektóre z tych założeń zaufania omówimy szczegółowo). Kluczowym celem — a jest to temat, który powtarza się w całym artykule — jest to, że chcemy zminimalizować zaufanie w komunikacji międzyłańcuchowej do poziomu, na którym różne założenia zaufania nie stanowią dużego ryzyka bezpieczeństwa dla aplikacji zorientowanych na interoperacyjność.

To ważny cel, ponieważ, jak się okazuje, gdy budujesz protokół interoperacyjności, aby połączyć różne blockchainy, a aplikacja działająca po jednej stronie podziału akceptuje fałszywe twierdzenie, że jakieś dowolne zdarzenie miało miejsce po drugiej stronie, mogą się zdarzyć złe rzeczy — naprawdę złe rzeczy. Na przykład, eksploity mostów zdarzały się, ponieważ błąd umożliwiał sprytnym hakerom pomyślne przesyłanie (fałszywych) dowodów nieistniejących żądań wiadomości i tworzenie tokenów w łańcuchu docelowym bez deponowania zabezpieczenia w łańcuchu źródłowym.

Analiza istniejących mechanizmów bezpieczeństwa międzyłańcuchowego

Projektanci protokołów od tego czasu opracowali rozwiązania problemu walidacji informacji w komunikacji międzyłańcuchowej; najczęstszym jest wykorzystanie strony trzeciej do weryfikacji istnienia/ważności transakcji międzyłańcuchowej. Uzasadnienie jest proste: aplikacja w łańcuchu A może nie być w stanie zweryfikować stanu łańcucha B, ale możemy zlecić jej sprawdzenie, czy grupa osób (którym ufamy lub oczekujemy, że będą uczciwi za pomocą jakiegoś mechanizmu) zweryfikowała część informacji (lub twierdzenie) odnoszącą się do stanu łańcucha B.

Nazywa się to „weryfikacją zewnętrzną”, ponieważ inna strona zewnętrzna względem łańcucha bloków działa jako źródło prawdy dla zdarzeń w łańcuchu i (zwykle) obejmuje jednego lub więcej weryfikatorów wykonujących podpisy na nagłówkach bloków z łańcucha źródłowego. Gdy aplikacja w łańcuchu docelowym otrzyma ten podpisany nagłówek, może następnie zweryfikować różne dowody stanu dostarczone przez użytkownika (salda, zdarzenia, depozyty/wypłaty itp.) względem niego.

Aby ustanowić pewien poziom tolerancji błędów, niektóre protokoły interoperacyjności używają schematu podpisywania progowego, który wymaga minimalnej liczby kluczy prywatnych do wykonania podpisu dla ważności (typowymi przykładami są portfele multisignature i multiparty (MPC)). Jednak posiadanie mnogości ( k z n ) lub weryfikatorów poświadczających stany międzyłańcuchowe nie jest dokładnie panaceum na bezpieczeństwo, szczególnie w przypadku małych zestawów weryfikatorów.

Na przykład ktoś może narazić na szwank wystarczającą liczbę sygnatariuszy w schemacie multisig i przystąpić do autoryzowania oszukańczych wypłat z mostu międzyłańcuchowego. Konfiguracja MPC jest nieco bezpieczniejsza (próg zatwierdzenia można zmienić, a udostępniane klucze można częściej wymieniać), ale nadal jest podatna na ataki (szczególnie w przypadkach, gdy jedna strona kontroluje większość udostępnianych kluczy).

Stawianie

Jednym ze sposobów na zmniejszenie założeń zaufania dla protokołów interoperacyjności i zwiększenie bezpieczeństwa komunikacji międzyłańcuchowej jest, aby zewnętrzni weryfikatorzy stawiali zabezpieczenie jako obligację przed przyjęciem obowiązków weryfikacyjnych. Staking tworzy bezpieczeństwo dla zewnętrznie weryfikowanych systemów, szczególnie, że zabezpieczone zabezpieczenie może zostać obcięte, jeśli węzeł weryfikatora wykona podpis na nieprawidłowym nagłówku bloku lub zatwierdzi nieprawidłową transakcję międzyłańcuchową).

Ale nawet to podejście wiąże się z problemami w zależności od tego, czy staking jest dozwolony czy niedozwolony. System dozwolony (gdzie walidatorzy muszą być na białej liście) jest często ograniczony do kilku wcześniej zatwierdzonych podmiotów i jest łatwiejszy do opracowania — nie ma potrzeby inwestowania w rozbudowany projekt zachęt, szczególnie gdy walidatorzy są publicznie znani i mają motywację do uczciwego działania w celu zachowania swojej reputacji. Jest również wydajny, ponieważ komunikacja — niezbędna do osiągnięcia konsensusu — odbywa się między kilkoma stronami, które już się znają.

Oczywiście, posiadanie systemu z uprawnieniami i identyfikowalnymi uczestnikami otwiera drzwi dla ataków wrogich; na przykład atakujący może skutecznie podszyć się pod lub przekupić niektórych z tych walidatorów i w ten sposób przejąć kontrolę większościową. Co gorsza, system Proof of Authority (PoA), w którym walidatorzy nie są faktycznie obsadzeni (a są po prostu mianowani), zmniejsza koszt ataku na system do zera (atakujący mogą po prostu narazić walidatorów PoA na szwank za pomocą schematów inżynierii społecznej i przejąć kontrolę nad systemem, na przykład).

System stakingu bez uprawnień zwiększa koszt zepsucia systemu, pozwalając każdej zainteresowanej stronie (z odpowiednią ilością kapitału) rozpocząć walidację operacji międzyłańcuchowych. W połączeniu z protokołem konsensusu, który wymaga ≥ ⅔ większości do poświadczenia nagłówków bloków, koszt zepsucia systemu będzie skutecznie równy minimalnej kwocie wymaganej do zepsucia większości weryfikatorów w systemie. Ponadto użytkownicy mają mniej założeń zaufania (walidatorów można ograniczyć), a dynamiczny zestaw weryfikatorów zwiększa trudność włamania się do określonych węzłów za pomocą technik takich jak inżynieria społeczna.

Co mogłoby pójść nie tak? Wiele, naprawdę. Na początek, kwota udziału w zabezpieczeniu systemu musi być równa lub wyższa od całkowitej wartości zagrożonych aktywów, jeśli wystąpi incydent bezpieczeństwa (pogarszający bezpieczeństwo lub żywotność protokołu interoperacyjności). Jeśli jest odwrotnie ( całkowita stawka zabezpieczająca system < całkowita wartość zagrożona ), to nawet groźba cięcia staje się nieskuteczna w zagwarantowaniu bezpieczeństwa, ponieważ zysk z uszkodzenia systemu przewyższa koszt jego uszkodzenia.

Ponadto próba wdrożenia wyżej wymienionej właściwości bezpieczeństwa prawdopodobnie wymagałaby ustalenia wyższych wymagań dotyczących udziału dla potencjalnych walidatorów. To z kolei wprowadza problem nieefektywności kapitału — ponieważ bezpieczeństwo opiera się na węzłach walidatorów wykonujących dwie rzeczy:

• Złożenie dużej kwoty pieniędzy z góry (jako stawki) przed przystąpieniem do obowiązków walidacyjnych

• Pozostawienie pieniędzy niewykorzystanych przez długi okres (ze względów bezpieczeństwa protokoły PoS nakładają długie opóźnienia na wypłaty — niektóre trwające nawet tygodnie lub miesiące — aby zapobiec skrajnym przypadkom, w których walidator dopuszcza się przestępstwa podlegającego obniżce i próbuje natychmiast wypłacić środki, aby uniknąć utraty środków z powodu obniżki)

  
  

Inną rzeczą, o której nie wspomnieliśmy, jest obciążenie deweloperów, którzy muszą teraz rozumować o zachętach kryptoekonomicznych, aby zniechęcić do nieuczciwego zachowania i zaprojektować złożoną funkcjonalność stakingu dla tokena protokołu. Oprócz odciągania uwagi od ważniejszych działań — takich jak rozwój produktu i zaangażowanie społeczności — zwiększa to również złożoność i narzut poznawczy cyklu rozwoju dla zespołów budujących infrastrukturę interoperacyjności.

Weryfikacja optymistyczna

„Optymistyczna weryfikacja” to inne podejście do problemu bezpieczeństwa międzyłańcuchowego: zamiast prosić zaufaną stronę lub grupę o poświadczenie stanu międzyłańcuchowego, pozwalamy każdemu to zrobić. Co najważniejsze, strona składająca oświadczenia o stanach międzyłańcuchowych do aplikacji interoperacyjności klienta (zwykle nazywanej „przekaźnikiem”) nie musi dostarczać dowodu, że poświadczony stan jest ważny. Wynika to z „optymistycznego” założenia, że przekaźniki będą działać uczciwie i składać tylko ważne oświadczenia o stanach międzyłańcuchowych.

Ale oczywiście w pełni spodziewamy się, że jeden lub dwóch (lub więcej) przekaźników stanie się nieuczciwych, dlatego optymistycznie zweryfikowane systemy wymagają od przekaźników wpłacenia niewielkiej kaucji przed przesłaniem dowodów stanu. Wykonywanie transakcji — tych, które odwołują się do stanów międzyłańcuchowych zgłoszonych przez przekaźnik — jest również opóźniane, aby dać każdemu obserwującemu system wystarczająco dużo czasu na zakwestionowanie nieważnych roszczeń w okresie kwestionowania . Jeśli roszczenie przekaźnika okaże się nieważne, wpłacona kaucja zostaje obcięta — a część z niej trafia do kwestionującego.

Weryfikacja optymistyczna zmienia problem konieczności zaufania wielu ( k z n ) lub większości ( m z n ) weryfikatorów w problem zaufania jednemu weryfikatorowi ( 1 z n ), że będzie działał uczciwie. Aby optymistycznie zweryfikowane protokoły pozostały bezpieczne, wystarczy mieć jednego aktora, który ma wystarczająco dużo danych o stanie, aby ponownie wykonać transakcje i stworzyć dowody oszustwa , aby zakwestionować oszukańcze transakcje w okresie opóźnienia (stąd założenie bezpieczeństwa 1 of n ).

Zmniejsza to obciążenie, ponieważ system może działać poprawnie z jednym przekaźnikiem (choć możemy potrzebować dwóch lub więcej, aby zapewnić żywotność). Zmniejsza to również ilość stawki wymaganej do zabezpieczenia i zachęca do ustawienia szybszego czasu odłączenia stawki (zabezpieczenie zabezpieczone można wycofać po upływie okresu opóźnienia).

Ponadto protokoły interoperacyjności oparte na optymistycznej weryfikacji są opisywane jako „dziedziczące bezpieczeństwo bazowego blockchaina”; opiera się to na idei, że jeśli bazowy blockchain jest aktywny i nie cenzuruje dowodów oszustwa, złośliwy retransmiter nie może ujść na sucho z nieuczciwym zachowaniem. Co więcej, atakowanie protokołu wymagałoby ataku na sam blockchain, ponieważ cenzurowanie transakcji przez dłuższy okres wymaga kontrolowania większości węzłów — a co za tym idzie, mocy udziału/kopania — w sieci.

Ale nawet optymistyczna weryfikacja ma swoje unikalne wady. Na przykład narzucanie opóźnienia na finalizację i wykonanie transakcji pomostowych lub żądań wiadomości zwiększa opóźnienie i pogarsza ogólne wrażenia użytkownika. Ten typ bezpieczeństwa międzyłańcuchowego ma również kilka subtelnych „haczyków” mających implikacje dla bezpieczeństwa, takich jak możliwość, że złośliwa strona zakwestionuje prawidłowe transakcje, aby „smucić” uczciwych przekaźników i wykonać rodzaj ataku DDoS.

Ponieważ dowody oszustwa są (w większości) interaktywne z natury, nieważne wyzwanie spowodowałoby, że uczciwi retransmiterzy zmarnowaliby zasoby — w tym fundusze wydane na opłaty za gaz dla transakcji w łańcuchu. W rezultacie uczciwi retransmiterzy mogą stracić motywację do przekazywania informacji międzyłańcuchowych, potencjalnie dając nieuczciwym retransmiterom okazję do przekazywania informacji międzyłańcuchowych. Wymaganie od kontrkandydatów wpłaty minimalnego depozytu mogłoby zniechęcić griefing, ale wysoki minimalny depozyt mógłby zniechęcić uczciwych obserwatorów (którzy nie mają kapitału) do kwestionowania nieprawidłowych aktualizacji stanu.

Niektóre protokoły obchodzą ten problem, ograniczając wyzwania do uprawnionego zestawu obserwatorów, ale to sprowadza nas z powrotem do pierwotnego problemu posiadania małego zestawu (zaufanych) uczestników w celu zabezpieczenia systemu. To podejście może również powodować kilka niezamierzonych konsekwencji, takich jak zmniejszenie bariery zmowy między węzłami obserwatorów i zwiększenie szans atakującego na uszkodzenie większości węzłów obserwujących system.

Weryfikacja kryptograficzna

Ostatnie podejście do zabezpieczania protokołów interoperacyjności międzyłańcuchowej, które rozważymy, pochodzi z dziedziny dowodów kryptograficznych. Pomysł jest prosty: zamiast ufać ludziom weryfikującym stany międzyłańcuchowe (które w poprzednich sekcjach okazały się niebezpieczne w pewnych przypadkach), możemy zamiast tego użyć mechanizmów weryfikacji kryptograficznej — redukując założenia zaufania do minimum.

Tutaj jeden lub więcej aktorów generuje dowody SNARK (Succinct Non-Interactive Argument of Knowledge) stanu (ważnego) łańcucha do wykorzystania w ramach aplikacji interoperacyjnej. Dowody te są weryfikowalne : możemy wziąć kryptograficzny dowód stanu międzyłańcuchowego, taki jak dowód pochodzący z nagłówka bloku, i potwierdzić jego ważność. Są one również nieinteraktywne : dowód wygenerowany przez jedną stronę może zostać zweryfikowany przez n różnych stron bez konieczności komunikowania się z kimkolwiek (w przeciwieństwie do interaktywnych dowodów oszustwa). Protokoły interoperacyjności zaprojektowane w ten sposób często mają najniższe założenia zaufania, o ile podstawowy system dowodowy jest solidny (tj. przeciwnik nie może stworzyć ważnych dowodów dla nieważnych roszczeń, z wyjątkiem pomijalnego prawdopodobieństwa).

Takie protokoły różnią się również od systemów weryfikowanych zewnętrznie, zwłaszcza gdy dowody kryptograficzne weryfikują, że każdy blok jest poprawny zgodnie z protokołem konsensusu łańcucha. W związku z tym przeciwnik musiałby kontrolować superwiększość zestawu walidatorów łańcucha źródłowego — wymaganą do finalizowania nieprawidłowych bloków — aby uszkodzić protokół interoperacyjności za pomocą dowodów kryptograficznych stanu międzyłańcuchowego.

Łatwo też zauważyć, że takie podejście eliminuje niektóre wady związane z niektórymi mechanizmami bezpieczeństwa międzyłańcuchowego omówionymi wcześniej:

1. Zerowa nieefektywność kapitałowa : Użycie zkSNARKs do weryfikacji stanów międzyłańcuchowych eliminuje potrzebę mechanizmu stakingu/bondingu i związaną z tym nieefektywność poddawania tokenów okresowi blokady. Podobnie, retransmiterzy nie muszą umieszczać obligacji (w przeciwieństwie do optymistycznej weryfikacji) przed składaniem oświadczeń o transakcjach międzyłańcuchowych, ponieważ towarzyszący dowód zwięźle weryfikuje oświadczenie.
2. Niskie opóźnienie : Bez konieczności implementacji okresu opóźnienia — w celu umożliwienia terminowych dowodów oszustwa — protokół interoperacyjności może wykonać komunikat międzyłańcuchowy lub operację pomostową po zweryfikowaniu dowodu SNARK zabezpieczającego go. To powiedziawszy, generowanie dowodów jest zazwyczaj obliczeniowo intensywne, więc zewnętrznie zweryfikowany system może być bardziej wydajny w porównaniu z protokołem interoperacyjności opartym na SNARK.

Oceniając bezpieczeństwo „kryptograficznie zweryfikowanego” rozwiązania interoperacyjności, ważne jest, aby dokładnie przyjrzeć się informacjom o stanach międzyłańcuchowych, które są faktycznie udowadniane i weryfikowane. Dowody zerowej wiedzy stały się modnym słowem, którego wiele protokołów się uczepiło, aby zaciemnić rzeczywiste założenia zaufania, które leżą u podstaw ich protokołów.

Na przykład, ponieważ weryfikacja wszystkich podpisów w zestawie walidatorów Ethereum ( ponad 925 000 walidatorów na bieżące liczby ) w obwodzie zkSNARK może być kosztowna, niektóre protokoły historycznie przyjęły inne sposoby wyprowadzania dowodów stanu Ethereum. Przykładem jest most „ Ethereum to X ” (gdzie X może być dowolnym blockchainem), który generuje dowód, że nagłówki bloku zostały podpisane przez większość Komitetu Sync Ethereum (który przedstawiliśmy wcześniej).

To bardziej wykonalne podejście (w porównaniu do weryfikacji kluczy publicznych tysięcy walidatorów, którzy poświadczyli blok). Ale jak wyjaśniono wcześniej, walidatorzy w Sync Committee nie są karani za podpisywanie się na nieprawidłowych nagłówkach bloku — pozostawiając niezaniedbywalne prawdopodobieństwo, że większość członków Sync Committee może zmówić się lub zostać przekupiona, aby oszukać lekkich klientów i skutecznie zagrozić bezpieczeństwu mostów/protokołów komunikacyjnych polegających na Sync Committee w kwestii informacji.

Ponadto, jak wyjaśniono w oryginalnym artykule wprowadzającym Lagrange State Committees , wyjaśniliśmy, że w idealnym świecie, w którym złośliwy Sync Committee byłby podatny na cięcia, bezpieczeństwo ekonomiczne byłoby ograniczone do maksymalnej kwoty cięcia. Oto kilka fragmentów z tego posta dla kontekstu:

Bezpieczeństwo mostów klienckich light, mostów ZK i dowodów komitetu synchronizacji opiera się na weryfikacji podpisów komitetu synchronizacji light klienta Ethereum. Ponieważ wielkość komitetu synchronizacji jest stała, bezpieczeństwo ekonomiczne, które go wspiera, jest również ograniczone w ciągu 27-godzinnego okna. Po ostatecznym wdrożeniu cięć dla komitetów synchronizacji Ethereum bezpieczeństwo ekonomiczne będzie ograniczone w następujący sposób:

• Bezpieczeństwo ekonomiczne Komitetu Sync = 512 węzłów * 32 Eth * 1650 USD/ETH = 27 033 600 USD
• Próg kompromisu dla Komitetu Synchronizacji = 27 033 600 USD * 2/3 = 18 022 400 USD

Podczas gdy mosty klienckie light i mosty klienckie light ZK są uważane za złoty standard interoperacyjności międzyłańcuchowej, ilość aktywów, które mogą zabezpieczyć za pomocą losowych komitetów synchronizacji, jest poważnie ograniczona. Jak pokazano wcześniej, ilość zabezpieczenia, które węzły w zmowie musiałyby spalić, aby jednocześnie narazić na szwank wszystkie mosty klienckie light Ethereum i mosty klienckie light ZK, jest ograniczona do 18 mln USD.

Rozważmy sytuację, w której suma wartości wszystkich aktywów zabezpieczonych przez wszystkich lekkich klientów i mosty lekkich klientów ZK wynosi k. Gdy k < 18 mln USD, wszystkie aktywa zabezpieczone przez mosty są bezpieczne, ponieważ atak nie jest ekonomicznie opłacalny. Gdy k rośnie tak, że k > 27 mln USD, staje się opłacalne dla grupy złych aktorów w komitecie synchronizacji poświadczanie złośliwych blokad w celu naruszenia zabezpieczonych aktywów.

Zachęcamy do przeczytania całego artykułu, szczególnie sekcji o ograniczeniach mostów klienckich Ethereum light , aby uzyskać więcej kontekstu na temat problemów związanych z poleganiem na komitetach randomizowanej synchronizacji w celu wyprowadzenia dowodów stanów międzyłańcuchowych. Sugerujemy również śledzenie wysiłków Polyhedra Network w celu udowodnienia pełnego konsensusu Ethereum PoS w obwodzie ZK .

Komitety stanowe Lagrange’a: Współdzielone bezpieczeństwo jako usługa dla protokołów komunikacji międzyłańcuchowej

Ponieważ większa część wprowadzenia do tego artykułu dotyczy współdzielonego bezpieczeństwa, wypadałoby przedstawić rozwiązanie współdzielonego bezpieczeństwa, nad którym pracowaliśmy w Lagrange Labs: Lagrange State Committees . W tej sekcji przyjrzymy się wewnętrznym działaniom sieci Lagrange State Committee i zrozumiemy jej powiązanie ze stosem ZK Big Data Lagrange'a oraz celowi tworzenia narzędzi umożliwiających bezpieczny i ekspresyjny dostęp do stanu w łańcuchach i między łańcuchami.

Czym są Komitety Stanowe Lagrange'a?

Sieć Lagrange State Committee (LSC) to prosty i wydajny protokół klienta lekkiego ZK dla optymistycznych rollupów (ORU), które osiadają na Ethereum (np. Optimism, Arbitrum, Base i Mantle). LSC są koncepcyjnie podobne do Sync Committee Ethereum i obsługują lekkie aplikacje oparte na kliencie — takie jak mosty i warstwy komunikatów międzyłańcuchowych — które chcą używać stanu optymistycznego rollupu bez przyjmowania nadmiernych założeń zaufania.

Lagrange State Committee to grupa węzłów klienckich, które ponownie postawiły zabezpieczenie o wartości 32 ETH na Ethereum za pośrednictwem EigenLayer. Innymi słowy, sieć Lagrange State Committee to AVS lub Actively Validated Service . Każdy Lagrange State Committee poświadcza ostateczność bloków dla danego optymistycznego zestawienia, gdy powiązane partie transakcji zostaną sfinalizowane na warstwie dostępności danych (DA). Te poświadczenia są następnie wykorzystywane do generowania dowodów stanu, które aplikacje mogą traktować jako źródło prawdy dla stanu tego konkretnego optymistycznego zestawienia.

Podczas gdy Sync Committee Ethereum jest ograniczony do 512 węzłów, każda sieć Lagrange State Committee obsługuje nieograniczony zestaw węzłów. Dzięki temu bezpieczeństwo ekonomiczne nie jest sztucznie ograniczone, a liczba węzłów poświadczających stan optymistycznego roll-upu może się skalować, co dynamicznie zwiększa bezpieczeństwo ekonomiczne dowodów stanu Lagrange'a.

Jak działa sieć Komitetu Stanowego Lagrange’a?

Dwa kluczowe komponenty protokołu Lagrange State Committee to sekwencer i węzły klienckie („węzły klienckie” to inna nazwa dla walidatorów zarejestrowanych w Lagrange State Committee). Sekwencer jest centralnym podmiotem odpowiedzialnym za koordynację poświadczeń w sieci Lagrange State Committee i dostarczanie poświadczeń dowodzącym, którzy produkują dowody stanowe. Węzeł sekwencera jest w rzeczywistości kombinacją trzech modułów o różnych funkcjach: Sequencer , Consensus i Governance .

W określonych odstępach czasu moduł Sequencer żąda od węzłów klienckich poświadczeń bloków rollup wynikających z wykonania partii transakcji zapisanych do warstwy DA. Zamiast wykonywać tę procedurę dla każdego optymistycznego bloku rollup, my Poniżej znajduje się krótka analiza każdego elementu w komunikacie bloku:

(1). Block_header : Nagłówek sfinalizowanego bloku optymistycznego rollup (ORU). „Finalność” oznacza tutaj blok wyprowadzony przez węzły rollup z danych transakcji sfinalizowanych na danej warstwie DA. Na przykład finalność jest definiowana przez bezpieczną nagłówkę L2 dla rollupów stosu Optimism/OP i blok L2 z równoważną finalnością Ethereum dla łańcuchów Arbitrum i Arbitrum Orbit. (Dowiedz się więcej o finalności rollupu w tym artykule .)

(2). current_committee : Kryptograficzne zobowiązanie do zestawu kluczy publicznych skojarzonych z węzłami klienckimi uprawnionymi do podpisywania bloku b. Oczekuje się, że węzeł kliencki zbuduje drzewo Merkle'a, w którym liście będą reprezentować klucze publiczne wszystkich aktywnych członków komitetu, i podpisze korzeń drzewa Merkle'a swoim kluczem BLS12–381.

(3). next_committee : Kryptograficzne zobowiązanie do zestawu kluczy publicznych powiązanych z węzłami uprawnionymi do podpisywania następnego bloku (b+1). Węzły, które chcą opuścić komitet stanowy, muszą przesłać transakcję pod koniec okresu atestacji do kontraktu Lagrange Service na Ethereum, który zajmuje się rejestracją i wyrejestrowywaniem operatorów w AVS komitetu stanowego.

Pod koniec każdego okresu atestacji zbiór węzłów komitetu może zostać zmieniony, jeśli operatorzy poproszą o opuszczenie lub dołączenie przed rozpoczęciem kolejnego okresu atestacji. Oczekuje się, że węzły klienckie zbudują drzewo Merkle'a next_committee , pobierając bieżący zbiór węzłów zarejestrowanych w każdym komitecie z kontraktu Lagrange Service Contract.

ELI5: Czym są dowody państwowe?

Dowód stanu to kryptograficzny dowód stanu łańcucha bloków: dowód nagłówka bloku z łańcucha źródłowego (łańcuch A), który może być użyty do udowodnienia łańcuchowi docelowemu istnienia stanu w łańcuchu źródłowym, takiego jak konkretna transakcja. Innymi słowy, dowód stanu reprezentuje dowód stanu łańcucha źródłowego na określonej wysokości bloku.

Aby zilustrować to poprzednim przykładem: nagłówek bloku z łańcucha źródłowego (łańcuch A), którego aplikacja Boba w łańcuchu docelowym (łańcuch B) używa do weryfikacji istnienia transakcji pomostowej Alicji, jest dowodem stanu. Reprezentuje podsumowanie modyfikacji stanu łańcucha źródłowego między poprzednim blokiem a bieżącym blokiem. Jeśli dowód Merkle'a Alicji weryfikuje się względem korzenia drzewa transakcji przechowywanego w nagłówku bloku łańcucha A, Bob może pewnie zatwierdzić transakcję pomostową w łańcuchu B (łańcuch docelowy), ponieważ dowód stanu potwierdza wykonanie żądania wiadomości Alicji w łańcuchu źródłowym.

Sieć Lagrange State Committee została zaprojektowana w celu generowania dowodów stanu dla optymistycznych rollupów zabezpieczonych przez Ethereum. Dowody stanu są generowane przez agregację podpisów BL12–381 na krotce opisanej wcześniej ( block_header , prev_committee i next_committee ) z co najmniej dwóch trzecich węzłów w komitecie stanowym. Dowód stanu jest następnie generowany przez obwód SNARK w oparciu o zbiorczą wagę podpisów poświadczających dany nagłówek bloku.

Podejście wymagające od atestatorów zobowiązania się do bieżących i następnych komitetów stanowych jest podobne do protokołu Ethereum Sync Committee i osiąga podobny cel: umożliwienie klientom lekkim skutecznej i bezpiecznej weryfikacji ważności optymistycznego nagłówka bloku rollup. Każdy dowód stanu jest kryptograficznie powiązany przez serię zobowiązań next_committee wskazujących, które węzły powinny podpisać następny blok. Wystarczy zatem zweryfikować dowód SNARK, który udowadnia następujące rekurencyjne właściwości w obiekcie bloku podpisanym przez węzły atestujące:

• Co najmniej ⅔ z n węzłów w komitecie stanowym podpisało nagłówek bloku b.

• current_committee bloku b jest równy drzewu next_committee bloku b-1.

• Blok b-1 jest albo blokiem genezy, albo jest poprawny w odniesieniu do tych trzech warunków.

  
  

Protokół interoperacyjności i inne aplikacje wymagające bezpiecznego optymistycznego stanu rollup z szybką finalnością (np. mosty międzyłańcuchowe i protokoły komunikacyjne) mogą wykorzystywać dowody stanu z komitetów stanowych Lagrange'a z minimalnymi założeniami zaufania. Co ważne, sieć komitetów stanowych Lagrange'a jest w stanie zagwarantować bezpieczeństwo dowodów stanu poprzez wdrożenie deterministycznego cięcia złośliwych atestatorów i indukcyjnych dowodów ważności .

W jaki sposób sieć Lagrange State Committee współpracuje ze stosem ZK Big Data?

W pierwszym poście z serii o pakiecie produktów Lagrange'a podkreśliliśmy związek między różnymi częściami ZK Big Data Stack : Lagrange State Committees, Recproofs, zkMapReduce i Lagrange Coprocessor. Każdy z tych komponentów, gdy jest połączony, zapewnia bezpieczny, wydajny dostęp do stanu i ekspresyjne, dynamiczne obliczenia na danych stanu:

#1. Sieć Lagrange State Committee integruje się z innymi komponentami ZK Big Data Stack w celu zapewnienia lepszej wydajności

Używamy Recproofs i zkMapReduce do tworzenia aktualizowalnych dowodów zagregowanego klucza publicznego (APK) dla komisji stanowych, co pozwala nam uniknąć kosztownego i czasochłonnego procesu deagregacji i ponownej agregacji kluczy publicznych osób niebędących sygnatariuszami za każdym razem, gdy konieczne jest utworzenie nowego podpisu zagregowanego.

Efektywna agregacja kluczy publicznych BLS operatorów w komitetach stanowych Lagrange'a AVS ułatwia wyższe wskaźniki uczestnictwa w AVS bez zwiększania kosztów obliczeniowych weryfikacji poświadczeń z węzłów komitetów stanowych. Dlatego komitety stanowe Lagrange'a są w stanie obsługiwać potencjalnie nieograniczony zestaw węzłów i wykazywać superliniowe bezpieczeństwo, ponieważ więcej kapitału jest gromadzone w komitetach stanowych. Możesz dowiedzieć się więcej o tej właściwości w naszym poście na temat skalowania programowalnego zaufania na EigenLayer z ZK Big Data .

Zintegrowanie Lagrange State Committees ze stosem ZK Big Data ma również bardziej bezpośrednie korzyści dla aplikacji klienckich wykorzystujących dowody stanu Lagrange'a. Na przykład możemy użyć funkcji zkMapReduce koprocesora Lagrange'a, aby połączyć wiele dowodów stanu z n optymistycznych łańcuchów rollup w jeden wielołańcuchowy dowód stanu . Umożliwia to „zagnieżdżoną weryfikację”, w której pojedyncza transakcja w łańcuchu jednocześnie weryfikuje stan wielu optymistycznych rollupów i zmniejsza koszty weryfikacji dla usług klienckich.

#2: Koprocesor Lagrange’a integruje się z siecią Komitetu Stanowego Lagrange’a, aby umożliwić wykonywanie obliczeń poza łańcuchem bez konieczności zaufania

Koprocesor Lagrange'a — który szczegółowo przeanalizujemy w kolejnym poście — obsługuje tanie i skalowalne obliczenia na danych w łańcuchu, wykonując obliczenia poza łańcuchem. Protokoły interoperacyjności między łańcuchami, które integrują się z Komitetami Stanowymi Lagrange'a, mogą również integrować się z koprocesorem Lagrange'a, aby ułatwić rozszerzenie ich ofert między łańcuchami o weryfikowalne obliczenia.

Na przykład, deweloper tworzący aplikację pożyczkową multi-chain może chcieć obliczyć sumę zabezpieczeń zdeponowanych przez użytkownika w n różnych zestawieniach. Nasz przyjazny deweloper może wykorzystać koprocesor Lagrange'a do obliczenia tej wartości, używając dowolnego źródła nagłówka bloku, na którym protokół cross-chain już polega.

Dlaczego sieć komitetów stanowych Lagrange’a zmienia zasady gry w zakresie interoperacyjności w optymistycznych podsumowaniach

Współdzielone, superliniowe zabezpieczenia dla optymistycznych klientów rollup light

Obecnie protokoły interoperacyjności, które obsługują mostkowanie między optymistycznymi łańcuchami rollup, są niezależnie odpowiedzialne za weryfikację stanu łańcuchów źródłowych. Bezpieczeństwo tych protokołów interoperacyjności zależy od mechanizmu weryfikującego poprawność nagłówka bloku.

Niektóre protokoły komunikacji międzyłańcuchowej próbują zmniejszyć założenia dotyczące zaufania, wdrażając natywne staking i prosząc zestaw weryfikatorów o zabezpieczenie przed poświadczeniem nagłówków bloków łańcuchów źródłowych. Jednak powoduje to fragmentację bezpieczeństwa ekonomicznego w różnych protokołach międzyłańcuchowych, ponieważ koszt uszkodzenia podzbioru ( k z n ) zestawu walidatorów każdego protokołu jest niższy.

W przeciwieństwie do tego, Lagrange State Committees zezwala wielu protokołom międzyłańcuchowym na wywodzenie zabezpieczeń z pojedynczego , dynamicznego zestawu walidatorów, który może skalować się do nieograniczonego rozmiaru. Zmienia to status quo — gdzie każdy protokół interoperacyjności jest niezależnie odpowiedzialny za weryfikację dokładności stanów międzyłańcuchowych — na taki, w którym wiele aplikacji może pobierać stan międzyłańcuchowy z jednego źródła.

W przeciwieństwie do innych protokołów lekkiego klienta, sieć State Committee Lagrange'a obsługuje dynamiczny, nieograniczony zestaw węzłów poświadczających. Ekonomiczna waga podpisów zabezpieczających każde poświadczenie może zatem skalować się dynamicznie, gdy więcej udziałów jest gromadzonych w komisjach stanowych — umożliwiając superliniowy wzrost bezpieczeństwa i zwiększając trudność atakowania zintegrowanych protokołów międzyłańcuchowych w izolacji.

To skutecznie czyni Lagrange State Committee „wspólną strefą bezpieczeństwa”, do której może podłączyć się każdy protokół międzyłańcuchowy (niezależnie od jego rozmiaru), aby zapewnić maksymalne bezpieczeństwo — podobnie jak Relay Chain w Polkadot i Cosmos Hub w Cosmos zabezpieczają sieci drugorzędne w ekosystemie wielołańcuchowym. Ponadto integracja z oprogramowaniem pośredniczącym restaking firmy EigenLayer umożliwia sieci Lagrange State Committee rozszerzenie bezpieczeństwa ekonomicznego Ethereum w celu zabezpieczenia dowolnej liczby protokołów komunikacji międzyłańcuchowej w dół.

Zmniejszone koszty ogólne dla zespołów zajmujących się rozwojem produktów międzyłańcuchowych

Deweloper tworzący dziś protokół interoperacyjności międzyłańcuchowej musi opracować infrastrukturę do niezależnego uruchamiania obserwatorów w celu weryfikacji stanu każdego optymistycznego rollupu, który obsługują. Wraz ze wzrostem liczby zintegrowanych optymistycznych rollupów, zwiększa się narzut infrastrukturalny związany z zarządzaniem bezpieczeństwem w każdym łańcuchu źródłowym.

Integracja z Lagrange State Committee pozwala deweloperowi na outsourcing zabezpieczeń i zamiast tego skupienie zasobów na optymalizacji funkcji produktu. Aby to ująć w kontekście: każdy dowód stanu Lagrange'a jest wystarczająco lekki, aby można go było skutecznie zweryfikować w dowolnym łańcuchu zgodnym z EVM.

Dodatkowe zabezpieczenia dla istniejących protokołów interoperacyjności

Dowody stanu Lagrange'a są agnostyczne względem warstwy transportowej używanej do ich transportu do jednego lub większej liczby łańcuchów docelowych, co pozwala aplikacjom interoperacyjnym na bezproblemowe układanie dowodów stanu Lagrange'a z istniejącymi mechanizmami bezpieczeństwa. Na przykład międzyłańcuchowy oracle lub międzyłańcuchowy protokół komunikacyjny z niezależnym zestawem weryfikatorów może zweryfikować dowód stanu Lagrange'a jako dodatkowy środek bezpieczeństwa przed przekazaniem międzyłańcuchowych żądań wiadomości z optymistycznych rollupów.

Co więcej, istniejący protokół interoperacyjności — po zintegrowaniu z siecią Lagrange State Committee — może dodać obsługę optymistycznych rollupów bez konieczności zwiększania przez walidatorów liczby monitorowanych łańcuchów. Dzięki wykorzystaniu dowodów stanu z sieci Lagrange State Committee walidatorzy muszą jedynie przekazywać żądania wiadomości między rollupami. Kontrakt bramy w łańcuchu docelowym może następnie zweryfikować istnienie wiadomości przekazywanych przez retransmitery poprzez weryfikację dowodu stanu Lagrange'a.

Jak sieć Komitetu Stanowego Lagrange’a wypada w porównaniu z innymi mechanizmami bezpieczeństwa międzyłańcuchowego?

Komitety stanowe Lagrange'a wypadają korzystnie w porównaniu z istniejącą infrastrukturą interoperacyjności, która wykorzystuje bonded staking/slashing, permissioned validation i optymistyczne mechanizmy weryfikacji (między innymi) w celu zwiększenia bezpieczeństwa dowodów stanu międzyłańcuchowego. Poniżej przedstawiono kilka porównań:

Weryfikacja zewnętrzna przez walidatorów bez uprawnień

Model ponownego zajmowania Lagrange'a łagodzi kluczowy problem w mechanizmach bezpieczeństwa międzyłańcuchowego, które wdrażają czyste staking PoS dla bezpieczeństwa: układanie ryzyka . Weźmy na przykład protokół międzyłańcuchowy, który wymaga od walidatorów kupowania i blokowania natywnego tokena protokołu na okres wiązania. Wraz ze zmianą popularności natywnego tokena protokołu międzyłańcuchowego zmienność ceny aktywów wpływa na całkowite bezpieczeństwo ekonomiczne sieci.

Zmienność cen stanowi mniejszy problem dla sieci Lagrange State Committee, ponieważ bezpieczeństwo węzłów komitetu opiera się na ponownie postawionych zabezpieczeniach za pośrednictwem EigenLayer. Ponadto ponownie postawiona ochrona zmniejszyła koszty alternatywne dla potencjalnych walidatorów, co oznacza większy udział w komitetach stanowych i wyższy poziom bezpieczeństwa ekonomicznego dla protokołów interoperacyjności. Dla użytkowników oznacza to niższe opłaty i większe bezpieczeństwo w porównaniu z protokołami interoperacyjności, które niezależnie bootstrapują swoje bezpieczeństwo.

Zauważamy również, że protokoły konsensusu stosowane w tradycyjnym Proof-of-Stake nakładają ograniczenia na liczbę walidatorów (np. Tendermint BFT ogranicza uczestnictwo do 100-200 walidatorów) i uniemożliwiają tradycyjnym protokołom PoS skalowanie bezpieczeństwa ekonomicznego tak często, jak to konieczne. Z kolei sieć Lagrange State Committee wykorzystuje mechanizm atestacji, który obsługuje potencjalnie nieograniczony zestaw węzłów uczestniczących w konsensusie. Zapewnia to, że sieć może dynamicznie zwiększać liczbę atestatorów, a co za tym idzie, zapewniać bardziej solidne gwarancje bezpieczeństwa ekonomicznego dla aplikacji klienckich.

Weryfikacja zewnętrzna przez uprawnionych walidatorów

Protokóły międzyłańcuchowe oparte na Proof-of-Authority (PoA) polegają na atestach, aby blokować nagłówki z małego zestawu węzłów z uprawnieniami. Te podejścia historycznie okazały się niebezpieczne w przypadku głośnych incydentów, w tym ataku na Ronin (5 z 7 walidatorów zostało naruszonych) i ataku na most Harmony One (2 z 5 walidatorów zostało naruszonych).

Korzystanie z systemu walidowanego bez uprawnień, takiego jak sieć Lagrange State Committee, zmniejsza wydajność w porównaniu do scentralizowanego operatora lub zestawu walidatorów podpisujących nagłówki. Jednak biorąc pod uwagę ryzyko, uważamy to za rozsądny kompromis. Systemy walidowane bez uprawnień zmniejszają również powierzchnię ataku dla firm, które najczęściej mogą skończyć na uruchamianiu większości walidatorów w systemie z uprawnieniami.

Mostkowanie kanoniczne

Sieć Lagrange State Committee eliminuje opóźnienie wysyłania wiadomości międzyłańcuchowych z optymistycznych rollupów. Każdy LSC działa jako „szybki tryb” dla mostów i protokołów komunikacyjnych, których użytkownicy chcieliby połączyć się z optymistycznego rollupu bez czekania na koniec okna wyzwania. Optymistyczne rollupy również bezpośrednio korzystają z właściwości szybkiej finalności LSC, ponieważ rozwiązują kluczowy problem UX dla użytkowników L2.

Gwarancja ta wynika z obserwacji, że: (a) mechanizm cięcia jest zaprojektowany w celu podniesienia kosztów działań przeciwnika oraz (b) cięcie węzłów współpracujących w LSC może odbywać się w łańcuchu w trybie powolnym , ponieważ istnieje zmienne opóźnienie czasowe przy wycofywaniu udziału. Podsumowując, uczestnicy LSC zawsze mają motywację do poświadczania prawidłowych stanów międzyłańcuchowych — co umożliwia aplikacjom międzyłańcuchowym natychmiastowe używanie dowodów stanu z LSC i przy minimalnych założeniach zaufania popartych kanonicznym mostem rollupu.

Wniosek

W tym artykule poruszono całkiem sporo kwestii i mamy nadzieję, że jego lektura była edukacyjna — jeśli nie wartościowa — dla twórców, inwestorów, entuzjastów i użytkowników w obszarze interoperacyjności. W trakcie tego artykułu zbadaliśmy definicję współdzielonego bezpieczeństwa, co oznacza ono dla projektowania bezpiecznych protokołów i w jaki sposób interoperacyjność międzyłańcuchowa może skorzystać na integracji ze współdzieloną infrastrukturą bezpieczeństwa.

Przyjrzeliśmy się również Lagrange State Committees: naszemu wspólnemu rozwiązaniu security-as-a-service zaprojektowanemu z myślą o protokołach komunikacji międzyłańcuchowej. Lagrange State Committees jest częścią naszej wizji umożliwiającej bezpieczną, minimalizującą zaufanie i wydajną interoperacyjność i będzie częścią większego stosu umożliwiającego deweloperom tworzenie wydajnych aplikacji międzyłańcuchowych dla użytkowników.

Przyszłość multichain jest nieunikniona i ważne jest, aby użytkownicy mogli przejść z używania jednego łańcucha do 10000 łańcuchów bez doświadczania znaczącej utraty bezpieczeństwa. Rozwiązania takie jak Lagrange State Committees (wraz z innymi postępami w zakresie bezpieczeństwa międzyłańcuchowego) są kluczowe dla tego celu. Ponieważ interoperacyjność otrzymuje więcej uwagi niż kiedykolwiek, świat, w którym poruszanie się między łańcuchami jest bezpieczne i wydajne, jest w zasięgu użytkowników kryptowalut na całym świecie.

Podziękowanie

Emmanuel Awosika ( 2077 Research ), Omar Yehia ( Lagrange Labs ), Ismael Hishon-Rezaizadeh ( Lagrange Labs ) i Amir Rezaizadeh ( Lagrange Labs ) przyczynili się do powstania tego artykułu. Emmanuel został zatrudniony przez Lagrange Labs w celu wsparcia pisania tego artykułu.

Wersja tego artykułu została wcześniej opublikowana tutaj .