Napisał: Chakra Research

Oprócz natywnego rozwiązania rozszerzającego wspomnianego w pierwszym tomie, inna ścieżka ekspansji Bitcoina wykorzystuje dodatkową warstwę protokołu na wierzchu Bitcoina, zwaną Warstwa 2. Dwa najbardziej krytyczne punkty rozwiązania warstwy 2 to bezpieczne dwukierunkowe mostkowanie i dziedziczenie bezpieczeństwa konsensusu Bitcoin.

Łańcuch boczny

Początków koncepcji sidechain można doszukiwać się w dokumencie „Enabling Blockchain Innovations with Pegged Sidechain” przedstawionym przez blockStream w 2014 roku. Jest to stosunkowo prosty plan ekspansji.

zasada działania

Łańcuch boczny to łańcuch bloków, który działa całkowicie niezależnie od łańcucha głównego. Posiada własny protokół konsensusu i może być stosowany jako pole eksperymentalne dla innowacji w łańcuchu głównym. Kiedy w łańcuchu bocznym dochodzi do złośliwego incydentu, uszkodzenie jest całkowicie ograniczone do samego łańcucha bocznego i nie ma wpływu na łańcuch główny. Łańcuch boczny może wykorzystywać wyższy protokół konsensusu TPS, aby zwiększyć możliwości programowania w łańcuchu i osiągnąć ulepszenie BTC.

Łańcuch boczny może realizować transfer Bitcoinów pomiędzy różnymi łańcuchami bloków poprzez kołek dwukierunkowy lub kołek jednokierunkowy. Oczywiście w rzeczywistości BTC może pozostać tylko w sieci Bitcoin, więc potrzebujemy mechanizmu zakotwiczającego, aby łańcuch boczny stał się The. BTC w łańcuchu jest połączone z BTC w sieci Bitcoin.

Peg jednokierunkowy wymaga od użytkowników wysłania BTC w sieci głównej na niedostępny adres w celu zniszczenia, a następnie w łańcuchu bocznym zostanie uzyskana odpowiednia liczba BTC, ale procesu nie można odwrócić. Peg dwukierunkowy to kolejne ulepszenie kołka jednokierunkowego, umożliwiające BTC poruszanie się tam i z powrotem pomiędzy łańcuchem głównym i łańcuchami bocznymi. Zamiast wysyłać go na niedostępny adres w celu zniszczenia, dwukierunkowy peg zablokuje BTC poprzez skrypty kontrolne, takie jak multipodpis i wybicie nowego BTC w łańcuchu bocznym. Gdy użytkownik będzie chciał wrócić do sieci głównej, BTC w łańcuchu bocznym zostanie spalony, a pierwotnie zablokowany BTC zostanie zwolniony w sieci głównej.

Implementacja kołka jednokierunkowego jest znacznie prostsza niż kołka dwukierunkowego, ponieważ nie ma potrzeby zarządzania odpowiednim stanem w sieci Bitcoin, ale aktywa łańcucha bocznego generowane przez kołek jednokierunkowy mogą być bezwartościowe ze względu na brak mechanizmu odwrotnego zakotwiczenia.

Istnieją różne rozwiązania i różne poziomy bezpieczeństwa weryfikacji transakcji blokujących na łańcuchu głównym i transakcji niszczenia na łańcuchu bocznym. Najprościej jest skorzystać z weryfikacji zewnętrznej przez uczestników posiadających wiele podpisów, ale ryzyko centralizacji jest wysokie. Lepszą opcją jest użycie SPV Proof w celu uzyskania zdecentralizowanej weryfikacji. Oczywiście, ponieważ sieć główna Bitcoin nie ma niezbędnych możliwości programistycznych, nie można przeprowadzić weryfikacji SPV i można wybrać jedynie inne metody, zwykle opiekę z wieloma podpisami.

Pytania i pomysły

Istnieją dwa główne problemy, za które krytykuje się łańcuchy boczne:

Zależność aktywów międzyłańcuchowych od weryfikatorów: Ponieważ główna sieć Bitcoin nie jest jeszcze w stanie wdrożyć inteligentnych kontraktów, nie jest możliwe obsłużenie transferu aktywów między łańcuchami za pomocą logiki kontraktów bez zaufania podczas powrotu z łańcucha bocznego do Bitcoin , trzeba polegać na grupie weryfikatorów. Aby zakończyć operację, zakłada się zaufanie i istnieje ryzyko oszustwa.

Łańcuch boczny nie może dziedziczyć bezpieczeństwa łańcucha głównego: Łańcuch boczny działa całkowicie niezależnie od sieci głównej i nie może dziedziczyć bezpieczeństwa sieci głównej. Mogą wystąpić zdarzenia takie jak złośliwa reorganizacja bloków.

W tym względzie koncepcje łańcuchów bocznych obejmują poleganie na władzy (rodzaj sojuszu), poleganie na bezpieczeństwie gospodarczym (PoS), poleganie na zdecentralizowanych górnikach Bitcoin (Merged Mining), poleganie na sprzętowych modułach bezpieczeństwa (HSM), przechowywanie funduszy i łańcuch boczny na Bitcoinie Za produkcję bloków w łańcuchu mogą być odpowiedzialne różne role, wprowadzając w ten sposób bardziej złożone mechanizmy bezpieczeństwa.

Wprowadzenie do sprawy

Płyn

Pierwszą formą łańcucha bocznego jest łańcuch boczny sojuszu, w którym wiele wybranych wcześniej podmiotów pełni rolę weryfikatorów i jest odpowiedzialnych za opiekę nad głównymi funduszami sieciowymi oraz produkcję bloków łańcucha bocznego.

Liquid jest przedstawicielem bocznego łańcucha sojuszu, w którym 15 uczestników pełni rolę weryfikatorów. Metoda zarządzania kluczem prywatnym nie jest ujawniona, a do weryfikacji wymagane jest 11 podpisów. Bloki w łańcuchu po stronie Liquid są również utrzymywane wspólnie przez 15 uczestników. Łańcuch sojuszu z małą liczbą węzłów może osiągnąć wyższy TPS i osiągnąć cele ekspansji. Głównym zakresem zastosowania jest DeFi.

Podejście oparte na łańcuchu bocznym sojuszu wiąże się ze znacznymi scentralizowanymi zagrożeniami bezpieczeństwa.

Podkładka (RSK)

RSK ma również 15 węzłów pełniących funkcję depozytariuszy funduszy w sieci głównej, a do weryfikacji potrzeba tylko 8 podpisów. Różnica w stosunku do Liquid polega na tym, że klucz z wieloma podpisami jest zarządzany przez sprzętowy moduł bezpieczeństwa HSM, a instrukcja peg-out jest podpisana zgodnie z konsensusem PoW, aby uniemożliwić weryfikatorowi posiadającemu klucz bezpośrednie manipulowanie środkami depozytowymi.

Jeśli chodzi o konsensus łańcucha bocznego, RSK wykorzystuje Merged Mining do wykorzystania mocy obliczeniowej głównej sieci w celu zapewnienia bezpieczeństwa transakcji w łańcuchu bocznym. Gdy udział mocy obliczeniowej połączonego wydobycia w sieci głównej jest wysoki, może lepiej zapobiegać tej stronie łańcuch przed naruszeniem Podwójny atak kwiatowy. Firma RSK wprowadziła ulepszenia w Merged Mining, aby zapewnić bezpieczeństwo łańcuchów bocznych przy niskich współczynnikach mieszania. Przyjmuje metodę uwzględniającą fork, aby przeprowadzać interwencje konsensusowe poza łańcuchem w sprawie zachowania fork i zmniejszać prawdopodobieństwo podwójnych wydatków.

Jednakże Merged Mining zmienia motywację górników i zwiększa ryzyko MEV, co może ostatecznie zdestabilizować system. W dłuższej perspektywie Merged Mining może zwiększyć centralizację górnictwa.

Półki na książki

Stacks zakotwicza historię łańcucha Stacks w Bitcoinie poprzez przesłanie skrótu bloku bocznego do bloku Bitcoin. Rozwidlenie Stacks może być spowodowane jedynie przez rozwidlenie Bitcoina oprzeć się podwójnym wydatkom.

sBTC wprowadza nowy token STX i model motywacyjny, wykorzystując metodę mostu zastawu, która umożliwia maksymalnie 150 walidatorów sieci głównej. W tak zwanym moście stakingowym walidatorzy muszą postawić tokeny STX, aby uzyskać pozwolenie na zatwierdzanie wpłat i wypłat. Bezpieczeństwo mostu zastawnego zależy w dużej mierze od wartości zastawionych aktywów. Kiedy wartość zastawionych aktywów ulega gwałtownym wahaniom, bezpieczeństwo krzyżowego łańcucha BTC może zostać łatwo zniszczone. Jeżeli wartość zastawionych aktywów jest niższa niż wartość aktywów międzyłańcuchowych, walidator ma motywację do czynienia zła.

Istnieją również propozycje sidechainów, które są szeroko omawiane w społeczności.

Łańcuch napędowy

Największą uwagę przykuł projekt Drivechain zaproponowany przez Pawła Sztorca w 2015 roku. Kluczowym technologiom w planie przypisano BIP 300 (mechanizm kołków) i BIP 301 (ślepe połączone wydobycie). BIP 300 szczegółowo definiuje logikę dodawania nowego łańcucha bocznego. Aktywacja nowego łańcucha bocznego jest podobna do aktywacji miękkiego widelca za pomocą sygnałów górniczych. BIP 301 pozwala górnikom Bitcoin stać się producentami bloków sidechain bez weryfikacji konkretnej treści transakcji.

Górnicy Bitcoin są również odpowiedzialni za zatwierdzanie transakcji wypłaty. Górnicy muszą najpierw utworzyć wynik OP_RETURN w transakcji bazy monet dla wydobytego bloku, aby zaproponować transakcję wypłaty. Następnie każdy górnik może głosować nad propozycją wydobycia każdego bloku może w dowolnym momencie głosować za lub przeciw propozycji. Gdy transakcja wypłaty przekroczy próg (13150 bloków), transakcja wypłaty zostaje oficjalnie wykonana i potwierdzona przez główny łańcuch Bitcoin.

W rzeczywistości górnicy mają pełną kontrolę nad środkami w Drivechain. W przypadku kradzieży środków użytkownicy mogą uratować się jedynie poprzez UASF (soft fork aktywowany przez użytkownika), ale bardzo trudno jest w tym przypadku osiągnąć konsensus. Co więcej, wyjątkowa pozycja górników w Drivechain zwiększa ryzyko MEV, co zostało już wykazane w Ethereum.

Łańcuch kosmiczny

Spacechain przyjął inne podejście, wykorzystując Perpetual 1 way peg (P1WP). Użytkownicy spalają BTC, aby uzyskać tokeny na Spacechain, bezpośrednio pomijając kwestię bezpieczeństwa funduszu. Tego tokena można używać wyłącznie do wystawiania na aukcji miejsca w blokach w łańcuchu kosmicznym i nie ma on żadnej funkcji przechowywania wartości.

Aby zapewnić bezpieczeństwo łańcucha bocznego, Spacechain wykorzystuje eksplorację metodą ślepego scalania. Inni użytkownicy używają ANYPREVOUT (APO) do publicznego ubiegania się o prawo do budowania bloków. Górnicy Bitcoin muszą jedynie zatwierdzić nagłówek bloku Spacechain w bloku bez weryfikacji blok boczny. Jednak uruchomienie Spacechain wymaga wsparcia Covanent, a społeczność Bitcoin wciąż dyskutuje nad potrzebą miękkiego forka, aby dodać kod operacyjny Covanent.

Ogólnie rzecz biorąc, Spacechain może zrealizować łańcuch boczny o takich samych właściwościach decentralizacji i odporności na cenzurę jak Bitcoin i większej programowalności dzięki funkcji licytowania bloków na Bitcoinie.

Miękki łańcuch

Softchain to propozycja łańcucha bocznego 2wp zaproponowana przez autora Spacechain Rubena Somsena. Wykorzystuje ona mechanizm konsensusu PoW FP w celu zapewnienia bezpieczeństwa łańcucha bocznego. W normalnych okolicznościach pełny węzeł Bitcoina musi jedynie pobrać nagłówek bloku softchaina i zweryfikować dowód działania. Kiedy nastąpi fork, pobierz blok osierocony i odpowiadające mu zobowiązanie zestawu UTXO, aby zweryfikować ważność bloku.

W przypadku mechanizmu 2wp podczas peg-in tworzona jest transakcja depozytowa w głównym łańcuchu, a transakcja w łańcuchu głównym jest odwoływana do softchain w celu uzyskania środków; podczas peg-out tworzona jest transakcja wypłaty w softchain, a transakcja jest przywoływana w głównym łańcuchu w celu odzyskania środków BTC, a proces wypłaty musi poczekać długi okres próbny, zanim będzie mógł zostać zakończony. Specyficzne mechanizmy peg-in i peg-out wymagają obsługi miękkiego widelca, dlatego rozwiązanie to nazywa się Softchain.

Rozwiązanie Softchain nakłada dodatkowe koszty weryfikacji na pełne węzły głównej sieci Bitcoin. Podział konsensusu Softchain może wpłynąć na osiągnięcie głównego konsensusu sieci i stać się możliwym środkiem ataku na główną sieć Bitcoin.

Sieć błyskawic

Lightning Network opublikowała białą księgę w 2015 r. i została oficjalnie uruchomiona w 2018 r. Jako protokół płatności p2p warstwy 2 w Bitcoinie ma na celu przeniesienie dużej liczby małych kwot i transakcji o wysokiej częstotliwości do przetwarzania poza łańcuchem przez długi czas była uważana za najbardziej zaawansowaną technologię w sieci Bitcoin.

moduł podstawowy

Wdrożenie Lightning Network jest nierozerwalnie związane z kilkoma ważnymi modułami w Bitcoinie, które wspólnie zapewniają bezpieczeństwo transakcji Lightning Network.

Pierwsza to transakcja podpisana wcześniej. Wstępnie podpisane transakcje stały się bezpieczne i dostępne dopiero po aktualizacji SegWit. SegWit oddziela podpisy od reszty danych transakcyjnych, rozwiązując problemy, takie jak potencjalne zależności cykliczne, manipulowanie transakcjami przez osoby trzecie i manipulowanie transakcjami przez strony trzecie. Bezpieczeństwo przetwarzania danych w łańcuchu Lightning Network gwarantuje nieodwołalne zobowiązanie drugiej strony, które realizowane jest poprzez wcześniej podpisane transakcje. Po otrzymaniu wcześniej podpisanej transakcji przekazanej przez drugą stronę użytkownik może w dowolnym momencie rozesłać transakcję do sieci, aby dokończyć realizację promesy.

Drugi to multipodpis. Częste transfery środków poza łańcuchem pomiędzy dwiema stronami wymagają od przewoźnika, aby obie strony zachowały określone uprawnienia kontrolne, dlatego wymagane są wielokrotne podpisy. Generalnie stosuje się wielokrotny podpis 2/2, który zapewnia transfer środków musi nastąpić za obopólną zgodą obu stron.

Jednak multipodpis 2/2 spowoduje problemy z żywotnością, to znaczy, jeśli druga strona nie będzie współpracować, użytkownik nie będzie mógł przenieść żadnych aktywów z adresu multipodpisu, co spowoduje utratę pierwotnych środków. Blokady czasowe mogą rozwiązać problem żywotności. Podpisując wcześniej umowę z blokadą czasową zwrotu środków, można zapewnić, że nawet jeśli jedna ze stron stanie się nieaktywna, druga strona będzie mogła odzyskać początkowe środki.

Wreszcie istnieje blokada skrótu, która może łączyć wiele kanałów statusu i budować sieć. Oryginalny obraz skrótu będzie używany jako medium komunikacyjne do koordynowania prawidłowego działania wielu podmiotów.

Uruchom proces

kanał dwukierunkowy

Obie strony korzystające z Lightning Network do przeprowadzania transakcji muszą najpierw otworzyć dwukierunkowy kanał płatności na Bitcoinie. Obie strony mogą przeprowadzić dowolną liczbę transakcji poza łańcuchem. Po zakończeniu wszystkich transakcji najnowszy status zostanie przesłany do łańcucha Bitcoin aby dokończyć rozliczenie i zamknąć przejście do płatności.

W szczególności wdrożenie kanałów płatności obejmuje następujące kluczowe kroki:

1. Utwórz adres z wieloma podpisami. Obie strony kanału muszą najpierw utworzyć adres z wieloma podpisami 2 z 2 jako adres blokady środków kanału. Każda ze stron posiada klucz prywatny podpisu i zapewnia własny klucz publiczny.

2. Zainicjuj kanał. Obie strony transmitują transakcję w łańcuchu i blokują pewną ilość Bitcoinów na adresie z wieloma podpisami jako początkowe środki kanału. Transakcja ta nazywana jest transakcją „kotwicy” kanału.

3. Zaktualizuj stan kanału. Dokonując płatności w ramach kanału, obie strony aktualizują status kanału poprzez wymianę wcześniej podpisanych transakcji. Każda aktualizacja wygeneruje nową „transakcję zobowiązań”, reprezentującą aktualny stan alokacji środków. Transakcja zaangażowania ma dwa wyjścia, odpowiadające udziałom funduszu obu stron.

4. Prześlij najnowszy status. Każda ze stron kanału może w dowolnym momencie opublikować najnowszą transakcję zobowiązania w łańcuchu bloków, aby wycofać swoją część środków. Aby zapobiec rozgłaszaniu przez drugą stronę starego statusu, każdej transakcji zobowiązania odpowiada „transakcja karna”. Jeśli druga strona oszukuje, możesz przejąć wszystkie środki drugiej strony.

5. Zamknij kanał. Kiedy dwie strony decydują się na zamknięcie kanału, mogą współpracować w celu wygenerowania „transakcji rozliczeniowej”, która transmituje ostateczny status dystrybucji środków do blockchainu. W ten sposób środki zablokowane na adresie multipodpisowym zostaną uwolnione z powrotem na osobiste adresy obu stron.

6. Arbitraż w łańcuchu. Jeżeli obie strony nie mogą dojść do porozumienia przy zamykaniu kanału, każda ze stron może jednostronnie opublikować ostatnią transakcję zobowiązań i rozpocząć proces arbitrażu w łańcuchu. Jeżeli w określonym czasie (np. 1 dzień) nie będzie sprzeciwu, środki zostaną przesłane obu stronom zgodnie z alokacją zatwierdzonej transakcji.

sieć płatnicza

Kanały płatnicze można ze sobą łączyć, tworząc sieć obsługującą routing wieloprzeskokowy, realizowany za pośrednictwem HTLC. HTLC wykorzystuje blokadę skrótu jako warunek bezpośredni, a płatność podpisem z blokadą czasową jako warunek zapasowy. Użytkownicy mogą wchodzić w interakcję z oryginalnym obrazem zaszyfrowanym przed wygaśnięciem blokady czasowej.

Gdy pomiędzy dwoma użytkownikami nie ma bezpośredniego kanału, płatność można zrealizować za pomocą HTLC pomiędzy routerami. Hash Preimage R odgrywa kluczową rolę w całym procesie, zapewniając atomowość płatności. Jednocześnie blokada czasowa HTLC ma się zmniejszać, zapewniając każdemu przeskokowi wystarczającą ilość czasu na przetworzenie i przekazanie płatności.

Problemy

Zasadniczo sieć Lightning omija założenie zewnętrznego zaufania dotyczące mostkowania zasobów za pośrednictwem kanałów stanu p2p, korzystając jednocześnie ze skryptów blokady czasowej w celu zapewnienia ostatecznej gwarancji zasobów i ochrony przed awariami. Kiedy druga strona straci aktywność i nie będzie współpracować, możliwe będzie jednostronne wycofanie się. Dlatego Lightning Network ma dużą wartość w scenariuszach płatności, ale ma również wiele ograniczeń, w tym:

• Limit przepustowości kanału. Pojemność kanału płatniczego w Lightning Network jest ograniczona początkowo zablokowanymi środkami i nie może obsługiwać dużych płatności przekraczających przepustowość kanału. Może to ograniczać niektóre scenariusze zastosowań, takie jak handel towarami.

• Online i zsynchronizowane. Aby terminowo odbierać i przekazywać płatności, węzły Lightning Network muszą pozostać online. Jeśli węzeł jest w trybie offline przez długi czas, może przegapić niektóre aktualizacje statusu kanału, co powoduje brak synchronizacji statusu. Może to stanowić wyzwanie dla użytkowników indywidualnych i urządzeń mobilnych, a także zwiększa koszty funkcjonowania węzła.

• Zarządzanie płynnością. Efektywność routingu w Lightning Network zależy od dystrybucji płynności kanałów. Jeśli środki zostaną rozdzielone nierównomiernie, niektóre ścieżki płatności mogą zawieść, co wpłynie na wygodę użytkownika. Zarządzanie saldem płynności kanału wymaga pewnych kosztów technicznych i kapitałowych.

• Naruszenie prywatności. Aby znaleźć dostępne ścieżki płatności, algorytm routingu Lightning Network wymaga pewnego poziomu wiedzy na temat przepustowości kanału i informacji o łączności. Może to ujawnić prywatność niektórych użytkowników, np. dystrybucję funduszy, kontrahentów itp. Otwieranie i zamykanie kanałów płatności może również spowodować ujawnienie informacji o odpowiednich uczestnikach.

RGB

Oryginalna idea protokołu RGB została zainspirowana koncepcjami weryfikacji po stronie klienta i jednorazowego uszczelnienia zaproponowanymi przez Petera Todda. Został on zaproponowany przez Giacomo Zucco w 2016 roku. Jest to skalowalny i chroniący prywatność protokół drugiej warstwy Bitcoin. .

główny pomysł

Weryfikacja klienta

Proces weryfikacji łańcucha bloków polega na rozgłaszaniu wszystkim bloków złożonych z transakcji, umożliwiając każdemu węzłowi obliczenie transakcji w bloku i dokończenie weryfikacji. W rzeczywistości tworzy to dobro publiczne, to znaczy węzły w sieci pomagają każdej osobie, która przesyła transakcję, przejść weryfikację, a użytkownicy zapewniają BTC jako opłatę manipulacyjną jako zachętę do pomocy w weryfikacji. Weryfikacja po stronie klienta jest bardziej skoncentrowana na osobie. Weryfikacja stanu nie jest przeprowadzana globalnie, ale jest weryfikowana przez osoby uczestniczące w określonych zmianach stanu. Tylko strony generujące transakcję weryfikują ważność zmiany stanu. To znacznie poprawia prywatność, a także zmniejsza obciążenie węzłów i poprawia skalowalność.

Jednorazowa uszczelka

Zmiana stanu z punktu na punkt wiąże się z ukrytym niebezpieczeństwem. Jeśli użytkownicy nie będą w stanie zebrać pełnej historii zmian stanu, mogą zostać oszukani i dokonać podwójnych wydatków. Aby rozwiązać ten problem, zaproponowano jednorazowe plombowanie. Wykorzystuje ono specjalny przedmiot, którego można użyć tylko raz, aby zapobiec podwójnym wydatkom i poprawić bezpieczeństwo. Bitcoin UTXO to najodpowiedniejszy jednorazowy obiekt zapieczętowany, gwarantowany przez mechanizm konsensusu Bitcoin i moc obliczeniową całej sieci, dzięki czemu aktywa RGB mogą odziedziczyć bezpieczeństwo Bitcoina.

Obietnica kryptowalut

Jednorazowe uszczelnienie należy połączyć z zobowiązaniem do szyfrowania, aby mieć pewność, że użytkownik zna zmianę stanu i uniknąć wystąpienia ataków polegających na podwójnym wydatkowaniu. Tzw. zobowiązanie polega na informowaniu innych, że coś się wydarzyło i nie można go później zmodyfikować, ale nie ma potrzeby ujawniania konkretnych zdarzeń do momentu, gdy wymagana będzie weryfikacja. Do zaciągnięcia zobowiązania możemy posłużyć się funkcją skrótu. W RGB treścią zobowiązania jest zmiana stanu. Po wydaniu UTXO odbiorca zasobu RGB otrzyma sygnał zmiany stanu, a następnie zweryfikuje zobowiązanie pod kątem konkretnych danych przesłanych poza łańcuchem przez osobę wydającą. aktywa.

proces roboczy

RGB wykorzystuje konsensus Bitcoina, aby zapewnić bezpieczeństwo przed podwójnymi wydatkami i odporność na cenzurę, a wszelka weryfikacja transferów stanu jest przesyłana poza łańcuchem i jest weryfikowana wyłącznie przez klienta akceptującego płatność.

W przypadku wystawcy aktywów RGB należy utworzyć kontrakt RGB poprzez inicjowanie transakcji, a zobowiązanie określonych informacji zostanie zapisane w skrypcie OP_RETURN określonego warunku wydatkowania w transakcji Taproot.

Kiedy posiadacz zasobu RGB chce wydać, musi uzyskać odpowiednie informacje od odbiorcy zasobu, utworzyć transakcję RGB, zatwierdzić szczegóły transakcji RGB i umieścić wartość zobowiązania w UTXO określonym przez odbiorcę zasobu . i wygeneruj transakcję, która zużywa oryginalne UTXO i tworzy UTXO określone przez odbiorcę. Kiedy odbiorca zasobu zauważy, że UTXO, w którym pierwotnie przechowywany był zasób RGB, został wyczerpany, może zweryfikować ważność transakcji RGB poprzez zaangażowanie w transakcję Bitcoin. Gdy weryfikacja będzie ważna, wierzy, że rzeczywiście otrzymał Zasób RGB.

W przypadku odbiorcy aktywów RGB płatnik musi przedstawić stan początkowy i zasady zmiany stanu umowy, transakcje Bitcoin wykorzystywane do każdego przelewu, transakcje RGB realizowane przez każdą giełdę Bitcoin oraz ważność każdej transakcji Bitcoin. weryfikowana przez klienta odbiorcy na podstawie tych danych, weryfikuje ważność transakcji RGB. Wśród nich UTXO Bitcoina służy jako pojemnik do zapisywania stanu kontraktu RGB. Historię transferu każdego kontraktu RGB można wyrazić jako skierowany wykres acykliczny. Odbiorca zasobu RGB może uzyskać jedynie informacje związane z RGB posiada historię aktywów i nie ma dostępu do innych oddziałów.

Zalety i wady

Lekka weryfikacja

W porównaniu z pełną weryfikacją blockchain, protokół RGB znacznie zmniejsza koszty weryfikacji. Użytkownicy nie muszą przechodzić przez wszystkie bloki historyczne, aby uzyskać najnowszy status, a jedynie synchronizują zapisy historyczne związane z aktywami, które otrzymują do weryfikacji. skuteczność transakcji.

Ta lekka weryfikacja ułatwia transakcje peer-to-peer, dodatkowo eliminując potrzebę scentralizowanych dostawców usług i zwiększając poziom decentralizacji.

Skalowalność

Protokół RGB dziedziczy bezpieczeństwo Bitcoina jedynie poprzez zaangażowanie skrótu. Dzięki skryptom Taproot prawie nie zużywa się dodatkowej przestrzeni w łańcuchu Bitcoin, co umożliwia złożone programowanie zasobów. Ze względu na wykorzystanie UTXO jako kontenera, protokół RGB charakteryzuje się naturalną współbieżnością. Zasoby RGB na różnych gałęziach transferu nie będą się wzajemnie blokować i mogą być wykorzystywane w tym samym czasie.

Prywatność

W odróżnieniu od protokołów ogólnych, tylko odbiorca zasobów RGB może uzyskać historyczny status transferu zasobów RGB. Po zakończeniu wydatków nie można uzyskać przyszłego statusu transferu, co znacząco gwarantuje prywatność użytkownika. Nie ma korelacji pomiędzy transakcją aktywów RGB a transferem Bitcoin UTXO, a inni nie mogą uzyskać śladów transakcji RGB w łańcuchu Bitcoin.

Ponadto RGB obsługuje również wydatki w ciemno, a płatnik nie może wiedzieć, do którego UTXO zostaną wpłacone aktywa RGB, co jeszcze bardziej poprawia prywatność i zwiększa odporność na cenzurę.

niewystarczający

Gdy zasoby RGB wielokrotnie zmieniają właścicieli, nowi użytkownicy otrzymujący zasoby będą zmuszeni zweryfikować długą historię transferów, co spowoduje większe obciążenie weryfikacyjne, czas weryfikacji może się wydłużyć i utracona zostanie możliwość szybkiego potwierdzenia. W przypadku węzłów, które pozostają uruchomione w łańcuchu bloków, ponieważ najnowszy status jest zawsze synchronizowany, czas otrzymania szybkiej weryfikacji statusu nowej strefy jest za każdym razem ograniczony.

Społeczność dyskutuje nad możliwością ponownego wykorzystania obliczeń historycznych, a rekursywny ZK Proof ma możliwość osiągnięcia stałej weryfikacji stanu czasu i rozmiaru.

Podsumowanie

Przegląd

Rollup to najlepsze rozwiązanie ekspansji, do jakiego doszło po latach eksploracji ekosystemu Ethereum, od kanałów stanowych po Plazmę i wreszcie Rollup.

Rollup to niezależny łańcuch bloków, który zbiera transakcje poza łańcuchem Bitcoin, pakuje wiele transakcji w partię i wykonuje ją, a następnie przesyła dane i zobowiązania dotyczące statusu tej partii do głównego łańcucha, realizując przetwarzanie transakcji poza łańcuchem i aktualizacje statusu. Aby osiągnąć maksymalną rozbudowę, Rollup zwykle na tym etapie korzysta ze scentralizowanego sekwencera, aby poprawić wydajność wykonywania bez utraty bezpieczeństwa, ponieważ bezpieczeństwo gwarantuje weryfikacja przejść stanów Rollup w głównym łańcuchu.

W miarę dojrzewania rozwiązania Rollup ekosystemu Ethereum, ekosystem Bitcoin również zaczął eksperymentować z Rollupem. Jednak najbardziej krytyczną różnicą pomiędzy Bitcoinem a Ethereum jest brak możliwości programowania i niemożność wykonania obliczeń wymaganych do zbudowania Rollupu w łańcuchu. To sprawia, że ​​ludzie obecnie próbują jedynie wdrażać suwerenne Rollupy i OP Rollupy.

Klasyfikacja

Ze względu na różne metody weryfikacji przeniesienia stanu, Rollup można podzielić na dwie główne kategorie: Rollup Optymistyczny i Rollup Ważnościowy (ZK Rollup).

Optymistyczne zestawienie przyjmuje optymistyczną metodę weryfikacji W okresie sporu po przesłaniu każdej partii transakcji każdy może sprawdzić dane poza łańcuchem, zgłosić zastrzeżenia do problematycznych partii transakcji, przedstawić dowód oszustwa w głównym łańcuchu i utracić sekwencer. Jeżeli po okresie sporu nie będzie ważnego dowodu na oszustwo, partia transakcji zostanie uznana za ważną, a aktualizacja statusu zostanie potwierdzona w głównym łańcuchu.

Validity Rollup wykorzystuje Validity Proof do zakończenia weryfikacji, a Sequencer wykorzystuje algorytm dowodu o zerowej wiedzy do wygenerowania zwięzłego dowodu ważności dla każdej partii transakcji, potwierdzając, że przeniesienie stanu partii jest prawidłowe. Każda aktualizacja wymaga przesłania partii transakcji główny łańcuch Dowód ważności, główny łańcuch weryfikuje dowód, a następnie rozumie i potwierdza aktualizację statusu.

Zaletą Optimistic Rollup jest to, że jest stosunkowo prosty we wdrożeniu i wymaga mniej modyfikacji w głównym łańcuchu. Jednak potwierdzenie transakcji trwa dłużej (w zależności od okresu sprzeciwu) i wymaga większej dostępności danych. Transakcje Validity Rollup są potwierdzane szybko, nie wymagają okresów sprzeciwu, a dane transakcyjne mogą pozostać prywatne, ale generowanie i weryfikacja dowodów z zerową wiedzą wymaga dużego narzutu obliczeniowego.

Celestia zaproponowała także koncepcję suwerennego rollupu. Dane transakcyjne z rollupu są publikowane w dedykowanym blockchainie warstwy DA, który odpowiada za dostępność danych, a sam suwerenny rollup odpowiada za realizację i rozliczenie.

Przeglądaj i dyskutuj

Rollup na Bitcoinie jest wciąż na wczesnym etapie. Ze względu na różnice pomiędzy modelem księgowym i językiem programowania a Ethereum, trudno jest bezpośrednio skopiować praktyczne doświadczenie Ethereum. Społeczność Bitcoin aktywnie poszukuje innowacyjnych rozwiązań.

Pakiet suwerenności

5 marca 2023 r. ogłoszono, że Rollkit będzie pierwszą platformą obsługującą suwerenne pakiety zbiorcze Bitcoin. Twórcy suwerennych pakietów zbiorczych mogą publikować dane o dostępności Bitcoina za pośrednictwem Rollkit.

Rollkit jest inspirowany Ordinals i publikuje dane za pośrednictwem transakcji Taproot. Standardowa transakcja Taproot za pośrednictwem publicznej pamięci może zawierać do 390 KB danych, a niestandardowa transakcja Taproot wystawiona bezpośrednio przez górnika może zawierać prawie 4 MB dowolnych danych.

Rzeczywistym zadaniem Rollkita jest zapewnienie interfejsu dla suwerennego Rollupa do odczytu i zapisu danych w Bitcoin, dostarczania klientom usług oprogramowania pośredniego i przekształcania Bitcoina w warstwę DA.

Pomysł suwerennego rollupu spotkał się z dużym sceptycyzmem, a wielu przeciwników twierdziło, że suwerenny rollup na Bitcoinie to nic innego jak używanie Bitcoina jako tablicy ogłoszeń i całkowita niemożność przejęcia bezpieczeństwa Bitcoina. W rzeczywistości, jeśli przesyłasz tylko dane transakcyjne do Bitcoin, możesz jedynie poprawić żywotność, to znaczy wszyscy użytkownicy mogą uzyskać odpowiednie dane do weryfikacji za pośrednictwem Bitcoin, ale bezpieczeństwo może określić jedynie sam suwerenny Rollup i nie może być dziedziczone. Ponadto przestrzeń blokowa jest na wagę złota w przypadku Bitcoina, a przesłanie pełnych danych transakcji może nie być dobrą decyzją.

Pakiet zbiorczy OP i pakiet zbiorczy ważności

Chociaż wiele projektów drugiej warstwy Bitcoin nazywa się ZK Rollup, co jest zasadniczo bliższe OP Rollup, ale wykorzystuje w tym procesie technologię Validity Proof, możliwości programistyczne Bitcoina nie są jeszcze wystarczające, aby wspierać bezpośrednią weryfikację Validity Proof.

Obecnie zestaw kodów operacji Bitcoin jest bardzo ograniczony i nie można nawet bezpośrednio obliczyć mnożenia. Weryfikacja dowodu ważności wymaga rozszerzenia opkodów, a także w dużym stopniu opiera się na implementacji kontraktów rekurencyjnych. Te, które są obecnie omawiane w społeczności, obejmują OP_CAT, OP_CHECKSIG,. OP_TXHASH itp. Oczywiście, gdybyśmy mogli bezpośrednio dodać OP_VERIFY_ZKP, być może nie potrzebowalibyśmy żadnych innych modyfikacji, ale jest to oczywiście mało prawdopodobne. Ponadto ograniczenia rozmiaru stosu również utrudniają wysiłki mające na celu weryfikację dowodu ważności w skryptach Bitcoin, przy czym bada się wiele prób.

Jak zatem działa dowód ważności? Większość projektów publikuje oświadczenie i dowód ważności partii transakcji na Bitcoin w formie napisów i wykorzystuje BitVM do optymistycznej weryfikacji. BitVM Bridge zastępuje tutaj tradycyjne rozwiązanie z wieloma podpisami. Operator Bridge utworzy sojusz składający się z N osób w celu planowania wpłat użytkowników. Zanim użytkownicy dokonają wpłaty, sojusz będzie zobowiązany do wstępnego podpisania UTXO, który zostanie wygenerowany, aby mieć pewność, że depozyt może zostać legalnie pobrany wyłącznie przez Operatora. Po uzyskaniu podpisu wstępnego BTC zostanie zablokowany na adresie Taproot z wieloma podpisami N/N.

Kiedy użytkownik wystawi żądanie wypłaty, Rollup wyśle ​​dowód ważności z rootem wypłaty do łańcucha Bitcoin. Operator najpierw zaspokoi potrzeby użytkownika w zakresie wypłat z własnej kieszeni, a następnie zweryfikuje ważność poprzez umowę BitVM. Jeżeli każdy Operator uzna, że ​​certyfikat jest ważny, Operator otrzyma zwrot kosztów w drodze złożenia wielu podpisów, o ile ktokolwiek uzna, że ​​doszło do oszustwa, zostanie przeprowadzony proces kwestionowania, a niewłaściwa strona zostanie obciążona;

Ten proces jest w rzeczywistości taki sam jak OP Rollup. Założenie zaufania wynosi 1/N, jeśli jeden weryfikator jest uczciwy, protokół jest bezpieczny.

Mogą jednak wystąpić trudności w technicznej realizacji tego rozwiązania. W projekcie OP Rollup Ethereum Arbitrum był rozwijany przez wiele lat, a obecny Fraud Proof jest nadal przesyłany przez uprawnione węzły; Optimism dopiero niedawno ogłosił, że obsługuje Fraud Proof, co pokazuje, jak trudne jest jego wdrożenie.

Jeśli chodzi o wstępnie podpisaną operację w moście BitVM, przy wsparciu Bitcoin Covanent, można ją wdrożyć wydajniej, co wciąż czeka na konsensus społeczności.

Jeśli chodzi o atrybuty bezpieczeństwa, przesyłając skrót bloku Rollup do Bitcoin, uzyskuje się odporność na reorganizację i podwójne wydatki, a użycie mostu optymistycznego zapewnia założenie bezpieczeństwa 1/N. Jednak odporność mostu na cenzurę nadal może czekać na dalszy rozwój.

Wniosek: Warstwa 2 nie jest panaceum

Patrząc na tak wiele rozwiązań warstwy 2, możemy łatwo stwierdzić, że każde rozwiązanie ma ograniczone zadania, które może wykonać. Przy pewnych założeniach zaufania efekty, jakie może osiągnąć warstwa 2, w dużej mierze zależą od warstwy 1 – czyli natywnych możliwości Bitcoina.

Bez aktualizacji SegWit i blokad czasowych nie można pomyślnie zbudować sieci Lightning; bez aktualizacji Taproot nie można pomyślnie przesłać zobowiązań RGB; bez OP_CAT i innych Covanent, nie można pomyślnie zbudować pakietu walidacyjnego na Bitcoinie…

Wielu Bitcoin Maxi uważa, że ​​Bitcoin nigdy nie powinien być zmieniany i nie należy dodawać nowych funkcji. Wszystkie defekty powinny zostać usunięte przez warstwę 2. Warstwa 2 nie jest panaceum. Potrzebujemy mocniejszej warstwy 1, aby zbudować bezpieczniejszą, wydajniejszą i skalowalną warstwę 2.

W następnym artykule przedstawimy próby poprawy programowalności Bitcoina, więc bądź na bieżąco.