Autor: Chakra; Tłumaczenie: 0xjs@金财经

Istnieje wiele ścieżek do skalowania Bitcoina. W pierwszej części naszego cyklu artykułów opisano już jedną ze ścieżek „Natywne rozwiązania skalujące Bitcoin”. Druga ścieżka polega na zbudowaniu dodatkowej warstwy protokołu na bazie Bitcoina, zwanej Warstwa 2 najbardziej krytycznym aspektem rozwiązania 2-warstwowego jest bezpieczny dwukierunkowy most i dziedziczenie bezpieczeństwa konsensusu Bitcoin.

łańcuch boczny

Koncepcja sidechainów sięga 2014 roku, kiedy Blockstream przedstawił projekt „Włączanie innowacji Blockchain za pomocą Pegged Sidechains”. Reprezentuje stosunkowo podstawową metodę skalowania.

Jak działa łańcuch boczny?

Łańcuch boczny to łańcuch bloków, który działa niezależnie od łańcucha głównego, ma swój własny protokół konsensusu i może służyć jako poligon doświadczalny dla innowacji w łańcuchu głównym. Kiedy niekorzystne zdarzenie wystąpi w łańcuchu bocznym, uszkodzenie jest całkowicie ograniczone do samego łańcucha bocznego, bez żadnego wpływu na łańcuch główny. Sidechains mogą przyjmować protokoły konsensusu z wyższym TPS (transakcjami na sekundę), poprawiać programowalność w łańcuchu i ułatwiać zwiększoną funkcjonalność BTC.

Sidechains mogą realizować transfer Bitcoinów pomiędzy różnymi łańcuchami bloków za pomocą kołków dwukierunkowych lub kołków jednokierunkowych. Ale w rzeczywistości BTC może znajdować się tylko w głównej sieci Bitcoin, więc potrzebny jest mechanizm zakotwiczający, aby połączyć BTC w łańcuchu bocznym z BTC w głównej sieci Bitcoin.

Kołki jednokierunkowe wymagają od użytkowników wysłania BTC z sieci głównej na niedostępny adres w celu zniszczenia, a następnie wybicia równoważnej ilości BTC w łańcuchu bocznym, ale proces ten jest nieodwracalny. Pegi dwukierunkowe stanowią ulepszenie kołków jednokierunkowych, umożliwiając BTC poruszanie się tam i z powrotem pomiędzy łańcuchem głównym a łańcuchami bocznymi. Zamiast zostać zniszczonym przez wysłanie na niedostępny adres, dwukierunkowy kołek blokuje BTC za pomocą wielu podpisów lub innych skryptów kontrolnych, tworząc nowe BTC w łańcuchu bocznym. Gdy użytkownik będzie chciał wrócić do sieci głównej, BTC w łańcuchu bocznym zostanie zniszczony, a pierwotnie zablokowany BTC zostanie uwolniony w sieci głównej.

Implementacja kołka jednokierunkowego jest znacznie prostsza niż kołka dwukierunkowego, ponieważ nie wymaga zarządzania odpowiednim stanem w sieci głównej Bitcoin. Jednakże aktywa sidechain utworzone za pomocą kołków jednokierunkowych mogą być bezwartościowe, ponieważ brakuje im mechanizmu odwrotnego kołka.

Istnieją różne schematy i poziomy bezpieczeństwa weryfikacji transakcji blokujących w łańcuchu głównym i transakcji spalania w łańcuchu bocznym. Najprostszą metodą jest weryfikacja zewnętrzna poprzez uczestników posiadających wiele podpisów, ale wiąże się to z dużym ryzykiem centralizacji. Lepszą opcją jest użycie dowodów SPV do zdecentralizowanej weryfikacji. Ponieważ jednak w sieci głównej Bitcoin brakuje niezbędnych możliwości programowania do przeprowadzenia weryfikacji SPV, należy zastosować inne metody, zwykle depozyt z wieloma podpisami.

Problemy i metody

Główne krytyczne uwagi dotyczące łańcuchów bocznych obejmują:

1. Aktywa międzyłańcuchowe opierają się na weryfikatorach: Ponieważ sieć główna Bitcoin nadal nie jest w stanie wdrożyć inteligentnych kontraktów, transferami aktywów między łańcuchami nie można zarządzać za pomocą logiki kontraktów pozbawionych zaufania. Zwrot aktywów z łańcucha bocznego do Bitcoin opiera się na zestawie walidatorów, wprowadzających założenia zaufania i ryzyko oszustwa.

2. Łańcuchy boczne nie mogą dziedziczyć bezpieczeństwa łańcucha głównego: Ponieważ łańcuchy boczne działają całkowicie niezależnie od sieci głównej, nie mogą dziedziczyć bezpieczeństwa sieci głównej, co może prowadzić do złośliwej reorganizacji bloków.

Aby rozwiązać te problemy, łańcuchy boczne przyjęły metody obejmujące poleganie na autorytatywnych instytucjach (federacja), bezpieczeństwo ekonomiczne (PoS), zdecentralizowane koparki Bitcoin (wydobywanie połączone) i sprzętowe moduły bezpieczeństwa (HSM). Opieką nad funduszami w Bitcoinach i produkcją bloków w sidechainach można zarządzać za pomocą różnych ról, wprowadzając bardziej złożone mechanizmy bezpieczeństwa.

studium przypadku

Płyn

Jedną z najwcześniejszych form sidechainów były federacyjne łańcuchy boczne, które opierały się na wstępnie wybranej grupie podmiotów, które pełniły rolę walidatorów odpowiedzialnych za opiekę nad zasobami w sieci głównej i generowanie bloków w łańcuchu bocznym.

Liquid jest klasycznym przykładem federacyjnego łańcucha bocznego, w którym 15 stron pełni rolę walidatorów. Zarządzanie kluczem prywatnym nie jest publiczne i weryfikacja wymaga złożenia 11 z 15 podpisów. Produkcja bloków w łańcuchu bocznym Liquid jest również obsługiwana przez tych 15 uczestników. Mniejsza liczba węzłów w tej federacji skutkuje większą liczbą transakcji na sekundę (TPS), osiągając w ten sposób cele skalowalności, a jej głównym obszarem zastosowań jest DeFi.

Jednak model stowarzyszonego łańcucha bocznego wiąże się ze znacznymi zagrożeniami bezpieczeństwa związanymi z centralizacją.

Podkładka (RSK)

RSK jest również zarządzane przez 15 węzłów odpowiedzialnych za hosting głównych funduszy sieciowych, a weryfikacja wymaga jedynie 8 podpisów. W przeciwieństwie do Liquid, wielopodpisowe klucze RSK są zarządzane przez sprzętowy moduł bezpieczeństwa (HSM), a instrukcje przechwytujące są podpisywane w oparciu o konsensus Proof-of-Work (PoW), uniemożliwiając weryfikatorom posiadającym dostęp do kluczy bezpośrednie manipulowanie środkami depozytowymi.

Jeśli chodzi o konsensus w ramach łańcucha bocznego, RSK przyjmuje wydobycie scalone i wykorzystuje moc obliczeniową głównej sieci, aby zapewnić bezpieczeństwo transakcji w ramach łańcucha bocznego. Kiedy duża część mocy obliczeniowej głównej sieci jest wykorzystywana do wydobycia scalonego, może skutecznie zapobiegać podwójnym wydatkom ataki na łańcuch boczny. RSK udoskonalił się w oparciu o scalone wydobywanie. Dzięki świadomości forków wykonuje interwencję konsensusową poza łańcuchem w sprawie zachowania forków, zapewniając w ten sposób bezpieczeństwo łańcuchów bocznych przy niskiej mocy obliczeniowej i zmniejszając możliwość ataków typu double-spend.

Jednak połączone wydobycie zmienia motywację górników, zwiększa ryzyko wartości wydobywalnej przez górników (MEV) i może zdestabilizować system. Z biegiem czasu połączone wydobycie może zwiększyć centralizację wydobycia.

Półki na książki

Stacks osiąga tę samą ostateczność co Bitcoin, zakotwiczając swoją historię łańcucha w Bitcoinie, przesyłając skróty swoich bloków sidechain do bloków Bitcoin. Forki w stosach mogą wystąpić tylko wtedy, gdy sam Bitcoin rozwidla się, co czyni go bardziej odpornym na ataki polegające na podwójnym wydatkowaniu.

sBTC wprowadza nowy model tokenów i zachęt wykorzystujący most stakingowy, który umożliwia maksymalnie 150 walidatorów sieci głównej. Walidatorzy muszą postawić tokeny STX, aby uzyskać dostęp do zatwierdzonych wpłat i wypłat. Bezpieczeństwo mostu stakingowego zależy w dużej mierze od wartości zastawionych aktywów, co stwarza ryzyko dla bezpieczeństwa międzyłańcuchowego BTC w okresach znacznych wahań cen zastawionych aktywów.

Inne propozycje sidechainów są obecnie szeroko omawiane w społeczności.

Łańcuch napędowy

Najbardziej godną uwagi z nich jest propozycja Paula Sztorca Drivechain z 2015 roku, która podzieliła kluczowe technologie na BIP 300 (mechanizm kołkowy) i BIP 301 (ślepo połączone górnictwo). BIP 300 definiuje logikę dodawania nowych łańcuchów bocznych, podobnie jak aktywacja nowych łańcuchów bocznych za pomocą sygnałów górniczych (takich jak miękkie forki). BIP 301 pozwala górnikom Bitcoin stać się producentami bloków w łańcuchach bocznych bez konieczności weryfikowania konkretnych szczegółów transakcji.

Górnicy Bitcoin są również odpowiedzialni za zatwierdzanie transakcji wypłat. Inicjują propozycję wypłaty, tworząc wyjście OP_RETURN w transakcji bazy monet dotyczącej wydobytego bloku. Inni górnicy mogą następnie głosować nad propozycją, wspierając ją lub sprzeciwiając się w każdym wydobywanym przez siebie bloku. Gdy transakcja wypłaty przekroczy próg (13 150 bloków), zostaje wykonana i potwierdzona w głównym łańcuchu Bitcoin.

W rzeczywistości górnicy mają pełną kontrolę nad funduszami na Drivechain. W przypadku kradzieży środków użytkownicy mogą się uratować jedynie poprzez aktywowane przez użytkownika miękkie forki (UASF), co do których trudno osiągnąć konsensus. Dodatkowo wyjątkowa pozycja górników w Drivechain zwiększa ryzyko MEV, co wykazano w Ethereum.

Łańcuch kosmiczny

Spacechain przyjmuje inne podejście, wykorzystując stały kołek jednokierunkowy (P1WP), w ramach którego użytkownicy niszczą BTC w celu uzyskania tokenów na Spacechain, całkowicie pomijając kwestię bezpieczeństwa funduszu. Tokeny te są używane wyłącznie do licytowania przestrzeni blokowej w Spacechain i nie posiadają żadnej funkcji przechowywania wartości.

Aby zapewnić bezpieczeństwo łańcucha bocznego, Spacechain wykorzystuje eksplorację ślepego scalania, podczas której użytkownicy publicznie licytują prawo do budowania bloków za pomocą ANYPREVOUT (APO). Górnicy Bitcoin muszą jedynie przesłać nagłówki bloków Spacechain we własnych blokach bez sprawdzania poprawności bloków sidechain. Jednakże uruchomienie Spacechain wymaga wsparcia Bitcoin dla Covenants, a społeczność Bitcoin wciąż debatuje, czy konieczny jest soft fork w celu dodania kodu operacji Covenant.

Ogólnie rzecz biorąc, Spacechain ma na celu osiągnięcie łańcucha bocznego, który jest tak samo zdecentralizowany i odporny na cenzurę jak Bitcoin, przy jednoczesnym zwiększeniu programowalności dzięki funkcji aukcji blokowej.

Miękki łańcuch

Softchain to kolejna propozycja dwukierunkowego łańcucha bocznego (2wp) autorstwa Rubena Somsena, która wykorzystuje mechanizm konsensusu PoW FP w celu zabezpieczenia łańcucha bocznego. W normalnych okolicznościach pełne węzły Bitcoin muszą jedynie pobrać nagłówek bloku Softchain, aby zweryfikować dowód pracy. Jeśli wystąpi fork, pobierają blok osierocony i odpowiadające mu zobowiązanie zestawu UTXO, aby zweryfikować ważność bloku.

W przypadku mechanizmu 2wp, po przeniesieniu powiązania, w głównym łańcuchu zostanie utworzona transakcja depozytowa, a Softchain odniesie się do tej transakcji w głównym łańcuchu w celu uzyskania środków, po przeniesieniu powiązania zostanie utworzona transakcja wypłaty na Softchain, a główny łańcuch wyceni tę transakcję, aby wycofać BTC po dłuższym okresie wyzwania. Specyficzne mechanizmy zaczepiania transferu i transferu wymagają obsługi miękkiego widelca, dlatego propozycja nosi nazwę Softchain.

Propozycja Softchain dodaje dodatkowe koszty weryfikacji do pełnych węzłów głównej sieci Bitcoin, a podział konsensusu w Softchain może wpłynąć na konsensus głównej sieci i stanowić możliwy wektor ataku dla Bitcoin.

Sieć błyskawic

Biała księga Lightning Network została opublikowana w 2015 r. i oficjalnie wprowadzona na rynek w 2018 r. Jako protokół płatności typu punkt-punkt drugiej warstwy w sieci Bitcoin, ma na celu przesyłanie dużej liczby małych transakcji o wysokiej częstotliwości do off- przetwarzanie łańcuchowe. Zawsze było uważane za najbardziej obiecującą ekspansję planu Bitcoin.

moduł podstawowy

Wdrożenie Lightning Network opiera się na kilku ważnych modułach w obrębie Bitcoina, które wspólnie zapewniają bezpieczeństwo transakcji sieciowych.

Po pierwsze, istnieją transakcje wstępnie podpisane. Transakcje te stały się bezpieczne po aktualizacji SegWit. SegWit oddziela podpisy od reszty danych transakcyjnych, rozwiązując potencjalne problemy, takie jak plastyczność transakcji, manipulowanie transakcjami przez strony trzecie i strony drugiej. Bezpieczeństwo obliczeń off-chain w Lightning Network gwarantują nieodwołalne zobowiązania kontrahentów, które realizowane są poprzez wcześniej podpisane transakcje. Gdy użytkownicy otrzymają wcześniej podpisaną transakcję od kontrahenta, mogą w dowolnym momencie przesłać ją do blockchainu, aby wypełnić swoje zobowiązanie.

Następny jest multipodpis. Częste transfery środków poza łańcuchem między dwiema stronami wymagają medium wspólnie kontrolowanego przez obie strony, co wymaga wielu podpisów, zwykle przy użyciu schematu 2 z 2. Dzięki temu transfer środków może nastąpić wyłącznie za obopólną zgodą.

Jednakże multisig 2 z 2 może prowadzić do problemów z żywotnością, w przypadku gdy jedna strona nie współpracuje, druga strona nie będzie w stanie przesłać żadnych środków z adresu multisig, co skutkuje utratą pierwotnych środków. Blokady czasowe mogą rozwiązać problem aktywności; podpisując wcześniej umowę z blokadą czasową zwrotu środków, możesz mieć pewność, że nawet jeśli jedna ze stron będzie nieaktywna, druga strona będzie nadal mogła odzyskać początkowe środki.

Wreszcie blokady skrótu służą do łączenia wielu kanałów stanu, tworząc efekt sieciowy. Zaszyfrowany obraz wstępny służy jako środek komunikacji, koordynujący prawidłowe operacje pomiędzy wieloma podmiotami.

przebieg operacji

kanał dwukierunkowy

Aby przeprowadzić transakcje za pomocą Lightning Network, obie strony muszą najpierw otworzyć dwukierunkowy kanał płatności na Bitcoinie. Mogą przeprowadzać nieograniczoną liczbę transakcji poza łańcuchem, a po zakończeniu wszystkich transakcji przesyłać najnowszy status do blockchainu Bitcoin w celu rozliczenia i zamknięcia kanału 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 muszą najpierw utworzyć adres z wieloma podpisami 2 z 2 jako blokadę środków kanału. Każda ze stron posiada klucz prywatny używany do podpisywania i udostępnia swój własny klucz publiczny.

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

3. Zaktualizuj status kanału. Dokonując płatności w ramach kanału, obie strony wymieniają wstępnie podpisane transakcje w celu aktualizacji statusu kanału. Każda aktualizacja generuje nową „transakcję zobowiązań”, która reprezentuje bieżącą alokację środków. Transakcja zaangażowania ma dwa wyjścia, odpowiadające udziałom funduszu obu stron.

4. Prześlij najnowszy status. Każda strona może w dowolnym momencie wycofać swoją część środków, transmitując najnowszą transakcję zobowiązania do łańcucha bloków. Aby zapobiec rozpowszechnianiu przez drugą stronę nieaktualnego stanu, każdej transakcji zobowiązań towarzyszy odpowiednia „transakcja karna”, która umożliwia jednej stronie odebranie wszystkich środków drugiej strony w przypadku oszustwa.

5. Zamknij kanał. Kiedy dwie strony decydują się na zamknięcie kanału, mogą współpracować w celu wygenerowania „transakcji rozliczeniowej” i transmitowania ostatecznej dystrybucji środków do blockchainu. Spowoduje to uwolnienie środków zablokowanych w adresie z wieloma podpisami z powrotem na osobiste adresy obu stron.

6. Arbitraż on-chain. Jeżeli obie strony nie mogą dojść do porozumienia w sprawie zamknięcia kanału, każda ze stron może jednostronnie opublikować najnowszą transakcję zobowiązania w celu wszczęcia postępowania arbitrażowego w łańcuchu. Jeżeli w określonym czasie (np. jednego dnia) nie będzie sporu, środki zostaną rozdzielone pomiędzy strony zgodnie z alokacją w transakcji zobowiązania.

sieć płatnicza

Korzystając z HTLC (Hash Time Lock Contract), kanały płatności można połączyć ze sobą, tworząc sieć obsługującą routing wieloprzeskokowy. HTLC wykorzystuje blokowanie skrótu jako warunek bezpośredni, a płatność z podpisem zablokowanym czasowo jako warunek zapasowy, umożliwiając użytkownikom interakcję w oparciu o zaszyfrowane obrazy wstępne przed wygaśnięciem blokady czasowej.

Jeśli między dwoma użytkownikami nie ma bezpośredniego kanału, płatności można realizować za pomocą HTLC na różnych ścieżkach. W tym procesie zaszyfrowany obraz wstępny R odgrywa kluczową rolę w zapewnieniu atomowości płatności. Dodatkowo blokady czasowe w HTLC są zmniejszane na trasie, zapewniając każdemu przeskokowi wystarczająco dużo czasu na przetworzenie i przekazanie płatności.

Problemy

Zasadniczo sieć Lightning omija założenia zaufania zewnętrznego dotyczące mostkowania zasobów za pośrednictwem kanałów stanu peer-to-peer, jednocześnie wykorzystując skrypty ograniczone czasowo, aby zapewnić najwyższą ochronę zasobów przed awarią. Umożliwia to jednostronne wyjście w przypadku, gdy kontrahent straci aktywność i przestanie współpracować. Dlatego Lightning Network jest bardzo praktyczna w scenariuszach płatności, ale ma również kilka ograniczeń, w tym:

1. Limit przepustowości kanału: Pojemność kanału płatniczego w sieci Lightning jest ograniczona początkowo zablokowanymi środkami i nie może obsługiwać płatności przekraczających przepustowość kanału. Może to ograniczyć niektóre przypadki użycia, takie jak handel towarami.

2. Wymogi dotyczące Internetu i synchronizacji: Aby terminowo odbierać i przekazywać płatności, węzły sieci Lightning muszą pozostać online. Jeśli węzeł jest offline przez dłuższy czas, może przegapić niektóre aktualizacje statusu kanału, co spowoduje desynchronizację. Może to stanowić wyzwanie dla użytkowników indywidualnych i urządzeń mobilnych, a także może zwiększyć koszty eksploatacji węzłów.

3. Zarządzanie płynnością: Efektywność routingu sieci Lightning zależy od dystrybucji płynności pomiędzy kanałami. Jeśli środki zostaną nierównomiernie rozdzielone, niektóre ścieżki płatności mogą stać się nieprawidłowe, co będzie miało wpływ na wygodę użytkownika. Zarządzanie saldem płynności kanału wymaga pewnych zasobów technicznych i finansowych.

4. Kwestie związane z prywatnością: Aby znaleźć wykonalne ścieżki płatności, algorytm routingu Lightning Network musi znać pewien stopień przepustowości kanału i informacje o połączeniu, które mogą naruszyć prywatność użytkowników, takie jak alokacja środków i kontrahenci. Otwieranie i zamykanie kanałów płatności może również spowodować ujawnienie informacji o uczestnikach.

RGB

Oryginalna koncepcja protokołu RGB została zainspirowana pomysłami Petera Todda dotyczącymi walidacji po stronie klienta i jednorazowego plombowania. Został zaproponowany przez Giacomo Zucco w 2016 roku jako skalowalny i chroniący prywatność protokół drugiej warstwy dla Bitcoin.

Podstawowy pomysł

Weryfikacja klienta

Proces weryfikacji w łańcuchu bloków polega na rozgłaszaniu bloków składających się z transakcji na całą sieć, umożliwiając każdemu węzłowi obliczenie i weryfikację transakcji w ramach tych bloków. To skutecznie tworzy dobro publiczne, węzły w sieci pomagają każdej osobie, która składa transakcję z weryfikacją, a użytkownicy dostarczają BTC jako opłatę transakcyjną w nagrodę za weryfikację. Walidacja po stronie klienta jest bardziej skoncentrowana na jednostce, a walidacja stanu nie jest przeprowadzana globalnie, ale przez osoby zaangażowane w określone przejścia stanu. Tylko strony generujące transakcję mogą zweryfikować zasadność tych zmian stanu, znacznie zwiększając prywatność, zmniejszając obciążenie węzła i poprawiając skalowalność.

Jednorazowa uszczelka

Zmiana stanu w trybie peer-to-peer jest ryzykowna, a bez dostępu do pełnej historii zmian stanu użytkownicy mogą być narażeni na oszustwa, co może skutkować podwójnymi wydatkami. Aby rozwiązać ten problem, zaproponowano jednorazową uszczelkę. Dzięki zastosowaniu specjalnych obiektów, których można użyć tylko raz, nie dochodzi do podwójnych wydatków, co zwiększa bezpieczeństwo. Model UTXO (Unspent Transaction Output) Bitcoina jest najodpowiedniejszą formą jednorazowego zapieczętowania, chronioną przez mechanizm konsensusu Bitcoin i moc mieszania sieci, umożliwiając zasobom RGB dziedziczenie funkcji bezpieczeństwa Bitcoin.

Obietnica kryptowalut

Jednorazowe pieczęcie należy połączyć ze zobowiązaniami kryptograficznymi, aby zapewnić użytkownikom jasne zrozumienie zmian stanu i zapobiec atakom polegającym na podwójnym wydatkowaniu. Obietnica poinformowania innych, że coś się wydarzyło i nie można tego później zmienić, bez ujawniania konkretnych szczegółów, dopóki nie będzie wymagana weryfikacja. Można to osiągnąć za pomocą funkcji skrótu. W RGB treścią zobowiązania jest zmiana stanu, która jest sygnalizowana odbiorcy zasobu RGB poprzez wydanie UTXO. Następnie odbiorca aktywów weryfikuje zobowiązanie na podstawie konkretnych danych przesłanych poza łańcuchem przez osobę wydającą aktywa.

Przepływ pracy

RGB wykorzystuje konsensus Bitcoina, aby zapewnić bezpieczeństwo przed podwójnymi wydatkami i odporność na cenzurę, podczas gdy wszystkie zadania weryfikacji zmiany stanu są delegowane poza łańcuchem i wykonywane wyłącznie przez klienta otrzymującego płatność.

W przypadku emitentów aktywów RGB utworzenie kontraktu RGB wiąże się z zainicjowaniem transakcji, w której zobowiązanie do określonych informacji jest przechowywane w skrypcie OP_RETURN w ramach warunku transakcji Taproot.

Gdy posiadacz zasobu RGB chce go wydać, musi uzyskać odpowiednie informacje od odbiorcy zasobu, utworzyć transakcję RGB i przesłać szczegóły tej transakcji. Zobowiązanie jest następnie umieszczane w UTXO określonym przez odbiorcę zasobu i przeprowadzana jest transakcja mająca na celu wydanie pierwotnego UTXO i utworzenie nowego UTXO określonego przez odbiorcę. Kiedy odbiorca zasobu zauważy, że UTXO przechowujący zasób RGB został wydany, może zweryfikować ważność transakcji RGB poprzez zaangażowanie w transakcję Bitcoin. Gdy weryfikacja będzie ważna, mogą z całą pewnością potwierdzić odbiór zasobu RGB.

W przypadku odbiorców aktywów RGB płatnik musi przedstawić stan początkowy umowy i zasady zmiany stanu, każdą transakcję Bitcoin wykorzystaną w przekazie, transakcję RGB przedstawioną dla każdej transakcji Bitcoin oraz dowód ważności każdej transakcji Bitcoin. Klient odbiorcy wykorzystuje te dane w celu sprawdzenia ważności transakcji RGB. W tej konfiguracji UTXO Bitcoina działa jak kontener przechowujący stan kontraktu RGB. Historię transferów każdego kontraktu RGB można przedstawić w postaci skierowanego wykresu acyklicznego (DAG), a odbiorca zasobu RGB może uzyskać dostęp jedynie do historii związanej z posiadanym zasobem, a nie do jakichkolwiek innych gałęzi.

plusy i minusy

Lekka weryfikacja

W porównaniu z pełną weryfikacją wymaganą przez blockchain, protokół RGB znacznie zmniejsza koszty weryfikacji. Użytkownicy nie muszą przechodzić przez wszystkie historyczne bloki, aby uzyskać najnowszy status. Muszą jedynie synchronizować historię związaną z otrzymanymi zasobami, aby zweryfikować ważność transakcji.

Ta lekka weryfikacja ułatwia transakcje peer-to-peer i dodatkowo zmniejsza zależność od scentralizowanych dostawców usług, wzmacniając decentralizację.

Skalowalność

Protokół RGB wymaga jedynie zaangażowania skrótu, dziedziczy bezpieczeństwo Bitcoina i praktycznie nie zużywa dodatkowej przestrzeni bloków Bitcoin przy użyciu skryptów Taproot. Umożliwia to złożone programowanie aktywów. Używając UTXO jako kontenera, protokół RGB w naturalny sposób obsługuje współbieżność; zasoby RGB na różnych gałęziach transferu nie będą się wzajemnie blokować i mogą być używane w tym samym czasie.

Prywatność

W przeciwieństwie do typowych protokołów, tylko odbiorca zasobu RGB ma dostęp do historii transferu zasobu. Po użyciu nie mają dostępu do historii przyszłych przelewów, co znacznie zapewnia prywatność użytkownika. Transakcje aktywów RGB nie są powiązane z transferami Bitcoin UTXO, więc osoby z zewnątrz nie mogą śledzić transakcji RGB w łańcuchu bloków Bitcoin.

Dodatkowo RGB obsługuje ślepe wyjścia, co oznacza, że ​​płatnicy nie mogą określić, do którego UTXO zostanie zapłacony zasób RGB, co jeszcze bardziej zwiększa prywatność i odporność na cenzurę.

niedociągnięcie

Gdy zasób RGB wielokrotnie zmienia właściciela, nowy odbiorca zasobu może stanąć przed znacznym obciążeniem weryfikacyjnym w zakresie weryfikacji długiej historii przelewów, co może skutkować dłuższym czasem weryfikacji i utratą możliwości szybkiego potwierdzania transakcji. W przypadku węzłów działających w łańcuchu bloków czas wymagany do sprawdzenia zmiany stanu po otrzymaniu nowego bloku jest w rzeczywistości ograniczony, ponieważ są one zawsze synchronizowane z najnowszym stanem.

Społeczność dyskutuje nad możliwością ponownego wykorzystania obliczeń historycznych, a rekurencyjne dowody ZK mogą umożliwić weryfikację stanu w stałym czasie i rozmiarze.

Podsumowanie

Przegląd

Rollup to najlepsze rozwiązanie rozszerzające w ekosystemie Ethereum, wywodzące się z lat eksploracji od kanałów stanowych po Plazmę, a ostatecznie ewoluujące do Rollup.

Rollup to niezależny łańcuch bloków, który zbiera transakcje spoza łańcucha Bitcoin, grupuje wiele transakcji, wykonuje te transakcje i przesyła partie danych i zobowiązań stanu do głównego łańcucha. Umożliwia to przetwarzanie transakcji poza łańcuchem i aktualizację statusu. Aby zmaksymalizować skalowalność, pakiet zbiorczy zazwyczaj na tym etapie korzysta ze scentralizowanego sekwencera, aby poprawić wydajność wykonywania bez uszczerbku dla bezpieczeństwa, ponieważ bezpieczeństwo zapewnia weryfikacja przejść stanów zbiorczych przez główny łańcuch.

W miarę jak rozwiązanie Rollup ekosystemu Ethereum staje się coraz bardziej dojrzałe, ekosystem Bitcoin również zaczyna eksplorować Rollupy. Jednak kluczową różnicą między Bitcoinem a Ethereum jest brak możliwości programowania w celu wykonania obliczeń wymaganych do zbudowania pakietów zbiorczych w łańcuchu. Obecnie pracujemy głównie nad wdrożeniem Sovereign Rollups i OP Rollups.

Klasyfikacja

Rollupy można podzielić na dwie główne kategorie: Rollupy Optymistyczne (Rollupy Optymistyczne) i Rollupy Ważności (Rollupy ZK). Główna różnica polega na sposobie weryfikacji przejścia stanu.

Optymistyczne zestawienie przyjmuje optymistyczną metodę weryfikacji W okresie sporu, po przesłaniu każdej partii transakcji, każdy może przeglądać dane poza łańcuchem, zgłaszać zastrzeżenia do problematycznych partii i przesyłać dowody błędów do głównego łańcucha, co powoduje karę dla Sekwencera. Jeżeli w okresie spornym nie zostanie przedstawiony żaden ważny dowód błędu, partia transakcji zostanie uznana za ważną, a aktualizacja statusu zostanie potwierdzona w głównym łańcuchu.

Pakiet Validity Rollup wykorzystuje dowód ważności do weryfikacji. Sequencer wykorzystuje algorytm dowodu o wiedzy zerowej do generowania zwięzłego dowodu ważności dla każdej partii transakcji, udowadniając, że zmiana stanu partii jest prawidłowa. Każda aktualizacja wymaga przesłania dowodu ważności paczki transakcji do głównego łańcucha, który zweryfikuje dowód i niezwłocznie potwierdzi aktualizację statusu.

Zaletą Optimistic Rollup jest to, że jest stosunkowo prosty i wymaga niewielu modyfikacji w głównym łańcuchu, wadą jest jednak dłuższy czas potwierdzenia transakcji (w zależności od okresu sporu) i wyższe wymagania dotyczące dostępności danych. Zaletą Validity Rollup jest to, że potwierdzenie transakcji jest szybkie, nie ma na nie wpływu okres sporu i może zapewnić prywatność danych transakcji, ale generowanie i weryfikacja dowodów z wiedzą zerową wymaga dużych nakładów obliczeniowych.

Celestia zaproponowała także koncepcję suwerennych zestawień, w których dane transakcyjne zbiorcze są publikowane w dedykowanym łańcuchu bloków warstwy dostępności danych (DA), który jest odpowiedzialny za dostępność danych, podczas gdy sam suwerenny pakiet zbiorczy jest odpowiedzialny za realizację i rozliczenie.

Przeglądaj i dyskutuj

Rollupy oparte na Bitcoinie są wciąż na wczesnym etapie. Ze względu na różnice w modelu księgowym i języku programowania Ethereum bezpośrednie kopiowanie Ethereum jest trudne. Społeczność Bitcoin aktywnie poszukuje innowacyjnych rozwiązań.

Pakiet suwerenności

5 marca 2023 roku ogłoszono, że Rollkit będzie pierwszym frameworkiem obsługującym pakiety zbiorcze Bitcoin Sovereign. Twórcy suwerennych Rollupów mogą używać Rollkit do publikowania danych o dostępności Bitcoina.

Rollkit jest inspirowany Ordinals i wykorzystuje transakcje Taproot do publikowania danych. Transakcje Taproot zgodne ze standardami publicznej pamięci mempool mogą zawierać do 390 KB danych, podczas gdy niestandardowe transakcje Taproot zamieszczane bezpośrednio przez górników mogą zawierać prawie 4 MB dowolnych danych.

Rollkit zasadniczo zapewnia interfejs do odczytu i zapisu danych na Bitcoinie oraz zapewnia usługę oprogramowania pośredniego do konwersji Bitcoina na warstwę DA.

Pomysł suwerennego rollupu spotkał się ze sporym sceptycyzmem. Wielu krytyków twierdzi, że suwerenny Rollup oparty na Bitcoinie wykorzystuje Bitcoin jedynie jako tablicę ogłoszeń i nie dziedziczy bezpieczeństwa Bitcoina. W rzeczywistości, gdyby tylko dane dotyczące transakcji zostały przesłane do Bitcoin, zwiększyłoby to jedynie aktywność – zapewniając wszystkim użytkownikom dostęp i weryfikację odpowiednich danych za pośrednictwem Bitcoin. Jednakże bezpieczeństwo może być określone jedynie przez sam suwerenny Rollup i nie może być dziedziczone. Ponadto miejsce na bloki jest niezwykle cenne 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 Bitcoin Layer2 twierdzi, że są pakietami ZK, są one zasadniczo bliższe pakietom OP i wykorzystują technologię Validity Proof. Jednak obecne możliwości programistyczne Bitcoina nie są wystarczające, aby wspierać bezpośrednią weryfikację dowodu ważności.

Obecny zestaw kodów operacji Bitcoina jest tak ograniczony, że nie jest w stanie nawet bezpośrednio obliczyć mnożenia, a weryfikacja dowodów ważności wymaga rozszerzenia opkodów, co w dużej mierze zależy od implementacji kontraktów rekurencyjnych. Społeczność aktywnie omawia opcje, w tym OP_CAT, OP_CHECKSIG, OP_TXHASH itp. W idealnym przypadku dodanie OP_VERIFY_ZKP mogłoby rozwiązać problem bez żadnych innych modyfikacji, ale jest to mało prawdopodobne. Co więcej, ograniczenia rozmiaru stosu utrudniają również wysiłki mające na celu weryfikację dowodów ważności w skryptach Bitcoin, a wiele badań jest w toku.

Jak zatem działa dowód ważności? Większość projektów publikuje rozbieżności w oświadczeniach i dowody ważności transakcji wsadowych na Bitcoin w formacie zapisu i wykorzystuje BitVM do optymistycznej weryfikacji. W tym schemacie operator mostu działa na zasadzie federacji, zarządzając depozytami użytkowników. Zanim użytkownik dokona wpłaty, federacja wstępnie podpisuje UTXO, aby mieć pewność, że o depozyt może ubiegać się wyłącznie operator. Po wstępnym podpisaniu BTC jest blokowany na adresie Taproot z wieloma podpisami N/N.

Kiedy użytkownik zażąda wypłaty, Rollup wysyła katalog główny wypłaty wraz z dowodem ważności do łańcucha Bitcoin. Operator początkowo płaci z własnej kieszeni, aby zaspokoić potrzeby użytkowników w zakresie wypłat, a następnie umowa BitVM weryfikuje ważność. Jeśli każdy operator uzna, że ​​dowód jest ważny, zwróci operatorowi pieniądze poprzez złożenie wielu podpisów; jeśli ktoś uzna, że ​​doszło do oszustwa, zostanie wszczęty proces kwestionowania, a niewłaściwa strona zostanie ukarana.

Proces ten jest zasadniczo taki sam jak OP Rollup, gdzie założenie zaufania wynosi 1/N - dopóki jeden walidator jest uczciwy, protokół jest bezpieczny. Jeśli chodzi o dowód ważności, celem nie jest ułatwienie weryfikacji w sieci Bitcoin, ale ułatwienie weryfikacji dla poszczególnych węzłów.

Jednak techniczne wdrożenie tego rozwiązania może napotkać wyzwania. W projekcie OP Rollup Ethereum Arbitrum rozwija się od wielu lat, ale jego dowód na oszustwo jest nadal przesyłany przez uprawnione węzły Optymizm nadal nie obsługuje zabezpieczenia przed oszustwami, co pokazuje trudność realizacja.

Dzięki wsparciu Bitcoin Covenant operacje wstępnego podpisania w moście BitVM mogą być wykonywane wydajniej, do czego społeczność pozostaje jeszcze nieosiągalna.

Z punktu widzenia atrybutów bezpieczeństwa, przesyłając skrót bloku Rollup do Bitcoin, Bitcoin zyskuje odporność na reorganizację i podwójne wydatki, podczas gdy Most Optymistyczny zapewnia założenie bezpieczeństwa 1/N. Oczekuje się, że odporność Optimistic Bridge na cenzurę również ulegnie dalszej poprawie.

Wniosek: Warstwa 2 nie jest panaceum

Gdy przyjrzeliśmy się różnym rozwiązaniom dwupoziomowym, stało się jasne, że każde rozwiązanie ma swoje ograniczenia. Skuteczność warstwy 2 zależy w dużej mierze od możliwości warstwy 1 (tj. Bitcoina) przy pewnych założeniach zaufania.

Pomyślne utworzenie sieci Lightning nie byłoby możliwe bez aktualizacji SegWit i blokad czasowych; wydajne zatwierdzanie w RGB nie byłoby możliwe bez aktualizacji Taproot; Zestawienia ważności na Bitcoinie nie byłyby możliwe bez OP_CAT i innych Covenants…

Wielu maksymalistów Bitcoina wierzy, że Bitcoin nigdy nie powinien się zmieniać, nie należy dodawać żadnych nowych funkcji, a wszystkie wady należy naprawić za pomocą rozwiązania warstwy 2. Nie jest to jednak możliwe; warstwa 2 nie jest panaceum. Potrzebujemy silniejszej warstwy 1, aby zbudować bezpieczniejszą, wydajniejszą i bardziej skalowalną warstwę 2.

W naszym następnym artykule przyjrzymy się próbom ulepszenia programowalności Bitcoina.