Napisał: Nickqiao, Faust, Shew Wang, maniak web3

Konsultant: Zespół Badawczy Bitlayer

Streszczenie: Firma Delphi Digital opublikowała niedawno raport badawczy na temat technologii drugiej warstwy powiązanych z Bitcoinem, zatytułowany „The Dawn of Bitcoin Programmability: Paving the Way for Rollups”, w którym systematycznie uporządkowano podstawowe koncepcje związane z Bitcoin Rollups, takie jak BitVM Family Bucket, OP_CAT i ograniczenia Porozumienia, ekologiczna warstwa DA Bitcoin, most i cztery główne drugie warstwy Bitcoin korzystające z BitVM, w tym Bitlayer, Citrea, Yona i Bob.

Chociaż raport z badania ogólnie przedstawia ogólny obraz technologii drugiej warstwy Bitcoina, jest on ogólnie stosunkowo ogólny i brakuje mu szczegółowego opisu, co utrudnia jego zrozumienie. Geek web3 przeprowadził szeroko zakrojone, dogłębne badania w oparciu o raport z badań Delphi, starając się umożliwić większej liczbie osób systematyczne zrozumienie BitVM i innych technologii.

Razem z zespołem badawczym Bitlayer i chińską społecznością BitVM uruchomimy serię felietonów zatytułowanych „Approaching BTC” w celu przeprowadzenia długoterminowej popularyzacji nauki wokół kluczowych tematów, takich jak mosty międzyłańcuchowe BitVM, OP_CAT i Bitcoin, i jesteśmy zaangażowani w odczarowywanie Bitcoin dla większej liczby osób Technologie związane z warstwą 2 monet pomagają utorować drogę większej liczbie entuzjastów.

Kilka miesięcy temu Robin Linus, szef ZeroSync, opublikował artykuł zatytułowany „BitVM: Compute Everything on Bitcoin”, formalnie proponując koncepcję BitVM i promując postęp technologii drugiej warstwy Bitcoina. Można powiedzieć, że jest to jedna z najbardziej rewolucyjnych innowacji w ekosystemie Bitcoin. Zdetonowała cały ekosystem Bitcoin drugiej warstwy, przyciągnęła udział gwiazdorskich projektów, takich jak Bitlayer, Citrea, BOB itp., i dodała witalności. cały rynek.

Następnie więcej badaczy wzięło udział w ulepszaniu BitVM i sukcesywnie wprowadzało różne wersje iteracyjne, takie jak BitVM1, BitVM2, BitVMX i BitSNARK. Ogólna sytuacja wygląda następująco:

  1. Biała księga dotycząca implementacji BitVM zaproponowana po raz pierwszy przez Robina Linusa w zeszłym roku dotyczy implementacji BitVM opartej na fikcyjnych obwodach bramek logicznych, zwanych BitVM0;

  2. W kilku kolejnych przemówieniach i wywiadach Robin Linus nieformalnie przedstawił rozwiązanie BitVM (zwane BitVM1) oparte na fikcyjnym procesorze, które jest podobne do systemu Cannon odpornego na oszustwa firmy Optimism. Może ono wykorzystywać skrypty Bitcoin do symulacji efektów procesora ogólnego przeznaczenia poza łańcuchem .

  3. Robin Linus zaproponował także BitVM2, jednoetapowy, nieinteraktywny protokół odporny na oszustwa, niewymagający pozwolenia.

  4. Członkowie Rootstock Labs i Fairgate Labs opublikowali białą księgę BitVMX, która, podobnie jak BitVM1, ma na celu emulację efektów procesora ogólnego przeznaczenia (poza łańcuchem) za pomocą skryptów Bitcoin.

Obecnie budowa ekosystemu deweloperskiego związanego z BitVM staje się coraz bardziej przejrzysta, gołym okiem widać także iteracyjne udoskonalanie narzędzi peryferyjnych. W porównaniu z ubiegłym rokiem dzisiejszy ekosystem BitVM stał się „niejasno widoczny” z początkowego „zamku”. in the air”, który również przyciąga coraz więcej ludzi. Coraz więcej programistów i VC wdziera się do ekosystemu Bitcoin.

Jednak dla większości ludzi zrozumienie terminów technicznych związanych z BitVM i Bitcoin Layer 2 nie jest łatwe, ponieważ konieczne jest systematyczne zrozumienie podstawowej wiedzy na ten temat, zwłaszcza znajomości takich jak skrypty Bitcoin i wiedza Taproot. Materiały referencyjne dostępne obecnie w Internecie są albo zbyt długie i pełne nonsensów, albo wyjaśnienia nie są wystarczająco dokładne, przez co ludzie wydają się rozumieć, ale nie rozumieją. Jesteśmy zaangażowani w rozwiązywanie powyższych problemów i staramy się używać możliwie najjaśniejszego języka, aby pomóc większej liczbie osób zrozumieć otaczającą wiedzę na temat drugiej warstwy Bitcoin i ustanowić systematyczne zrozumienie systemu BitVM.

MATT i zaangażowanie: podstawowa idea BitVM

Przede wszystkim chcemy podkreślić, że podstawową ideą BitVM jest MATT, co oznacza Merkleize All The Things. Dotyczy to głównie wykorzystania drzewiastej struktury przechowywania danych, takiej jak Merkle Tree, do wyświetlania złożonego procesu wykonywania programu postaraj się, aby weryfikacja Bitcoin Native była odporna na oszustwa.

Chociaż MATT może wyrazić złożony program i ślady przetwarzania jego danych, nie opublikuje tych danych bezpośrednio w łańcuchu BTC, ponieważ ogólny rozmiar tych danych jest bardzo duży. Rozwiązanie wykorzystujące MATT przechowuje dane tylko w drzewie Merkle poza łańcuchem i publikuje w łańcuchu tylko najwyższe podsumowanie (Merkle Root) drzewa Merkle. To drzewo Merkle zawiera głównie trzy podstawowe treści:

  • Kod skryptu inteligentnej umowy

  • Dane wymagane umową

  • Ślady pozostawione podczas wykonywania kontraktu (zapisy zmian w rejestrach pamięci i procesora podczas wykonywania inteligentnych kontraktów na maszynach wirtualnych, takich jak EVM)

(Prosty diagram drzewa Merkle. Korzeń Merkle jest obliczany na podstawie 8 fragmentów danych na dole rysunku poprzez wielowarstwowe mieszanie)

W ramach schematu MATT tylko bardzo mały korzeń Merkle jest przechowywany w łańcuchu, a cały zestaw danych zawarty w drzewie Merkle jest przechowywany poza łańcuchem. Wykorzystuje to koncepcję zwaną „zaangażowaniem”. Poniżej znajduje się wyjaśnienie, czym jest „Zaangażowanie”.

Obietnica przypomina zwięzłe stwierdzenie, które możemy rozumieć jako „odcisk palca” uzyskany w wyniku skompresowania dużej ilości danych. Ogólnie rzecz biorąc, osoba wystawiająca „zobowiązanie” w łańcuchu będzie twierdziła, że ​​pewne dane przechowywane poza łańcuchem są dokładne. Te dane poza łańcuchem powinny odpowiadać zwięzłemu stwierdzeniu, a to oświadczenie stanowi „zobowiązanie”.

W pewnym momencie skrót danych może zostać użyty jako „zaangażowanie” w same dane. Inne schematy zobowiązań obejmują zobowiązanie KZG lub drzewo Merkle. W zwyczajowym, odpornym na oszustwa protokole warstwy 2 wydawca danych publikuje cały zestaw danych poza łańcuchem i zobowiązuje się do opublikowania zestawu danych w łańcuchu. Jeśli ktoś odkryje nieprawidłowe dane w zestawie danych poza łańcuchem, zobowiązanie dotyczące danych w łańcuchu zostanie zakwestionowane.

Dzięki zaangażowaniu druga warstwa może kompresować i przetwarzać duże ilości danych, a jedynie publikować swoje „zaangażowanie” w łańcuchu Bitcoin. Oczywiście konieczne jest również zapewnienie, że cały zestaw danych udostępniony poza łańcuchem będzie mógł być obserwowany przez świat zewnętrzny.

Obecnie kilka głównych rozwiązań BitVM, takich jak BitVM0, BitVM1, BitVM2 i BitVMX, zasadniczo przyjmuje podobne abstrakcyjne struktury:

1. Dekompozycja i zaangażowanie programu: Najpierw rozłóż złożony program na dużą liczbę podstawowych kodów operacji (kompilacja), a następnie zapisz ślady wygenerowane przez te kody operacji podczas konkretnego wykonywania (mówiąc dosadnie, program działa na procesorze i Kiedy są w pamięci, rejestrowane są całe zmiany stanu, co nazywa się Trace). Następnie organizujemy wszystkie dane, w tym ślady i kody operacji, w zbiór danych, a następnie generujemy zobowiązanie dla tego zbioru danych.

Konkretne schematy zobowiązań mogą przybierać różne formy, takie jak: drzewa Merkle, PIOP (różne algorytmy ZK), funkcje skrótu

2. Zastaw aktywów i wstępne podpisanie: Wydawcy danych i weryfikatorzy muszą zablokować pewną liczbę aktywów w łańcuchu poprzez wstępne podpisanie, co spowoduje wprowadzenie ograniczeń. Warunki te zostaną uruchomione specjalnie w sytuacjach, które mogą wystąpić w przyszłości. Jeśli wydawca danych dopuści się zła, weryfikator może przedstawić certyfikat umożliwiający odebranie mu aktywów.

3. Publikowanie danych i zobowiązań: Wydawca danych publikuje zobowiązanie w łańcuchu, kompletny zestaw danych jest publikowany poza łańcuchem, a weryfikator pobiera zbiór danych i sprawdza, czy nie ma w nim błędów. Każda część zbioru danych poza łańcuchem ma korelację z zaangażowaniem w łańcuchu.

4. Wyzwania i kary: Gdy weryfikator odkryje, że w danych dostarczonych przez wydawcę danych występuje błąd, przekaże tę część danych do łańcucha w celu bezpośredniej weryfikacji (tę część danych należy najpierw bardzo dokładnie wyciąć Taka jest logika dowodu na oszustwo. Jeżeli wyniki weryfikacji wykażą, że wydawca danych rzeczywiście dostarczył nieprawidłowe dane poza łańcuchem, jego aktywa zostaną odebrane przez walidatora, który go kwestionuje.

Podsumowując, wydawca danych Alice ujawnia wszystkie ślady wygenerowane podczas realizacji transakcji drugiej warstwy poza łańcuchem i publikuje odpowiadające im zobowiązania w łańcuchu. Jeśli chcesz udowodnić, że pewna część danych jest błędna, najpierw udowodnij węzłowi Bitcoin, że ta część danych ma związek z zaangażowaniem w łańcuchu, czyli udowodnij, że dane zostały ujawnione przez samą Alicję, oraz następnie pozwól węzłowi Bitcoin potwierdzić, że ta część danych jest błędna.

Teraz z grubsza rozumiemy ogólną ideę BitVM, a wszystkie warianty BitVM są w zasadzie nierozerwalnie związane z powyższym paradygmatem. Następnie zacznijmy uczyć się i rozumieć niektóre ważne technologie stosowane w powyższym procesie, zaczynając od najbardziej podstawowych skryptów Bitcoin i Taproot oraz wstępnego podpisu.

Co to jest skrypt Bitcoin?

Wiedza związana z Bitcoinem jest trudniejsza do zrozumienia niż Ethereum. Nawet najbardziej podstawowe zachowanie związane z transferem obejmuje szereg koncepcji, w tym UTXO (niewydane dane wyjściowe transakcji), skrypt blokujący (znany również jako ScriptPubKey) i skrypt odblokowujący (znany również jako ScriptSig). Najpierw wyjaśnijmy te główne pojęcia.

(Przykład kodu skryptu Bitcoin składającego się z kodów niższego poziomu niż język wysokiego poziomu)

Sposób wyrażania aktywów w Ethereum przypomina bardziej Alipay lub WeChat. Każdy przelew po prostu dodaje i odejmuje salda różnych kont. Ta metoda koncentruje się na koncie, a saldo aktywów to tylko liczba pod nazwą konta; Wyrażenie bardziej przypomina złoto. Każda sztuka złota (UTXO) zostanie oznaczona swoim właścicielem. Transfer faktycznie niszczy stare UTXO i generuje nowe UTXO (właściciel się zmieni).

Bitcoin UTXO zawiera dwa kluczowe pola:

  • Kwota w „satoshi” (sto milionów satoshi to jeden BTC);

  • Skrypt blokujący, znany również jako „ScriptPubKey”, definiuje warunki odblokowania UTXO.

Należy zauważyć, że własność Bitcoin UTXO jest wyrażana poprzez skrypt blokujący. Jeśli chcesz przenieść swoje UTXO do Sama, możesz zainicjować transakcję w celu zniszczenia jednego z Twoich UTXO i zapisać warunki odblokowania nowo wygenerowanego UTXO jako „. Tylko Sam może je odblokować.”

Następnie, jeśli Sam chce używać tych Bitcoinów, musi przesłać skrypt odblokowujący (ScriptSig). W tym skrypcie odblokowującym Sam musi przedstawić swój podpis cyfrowy, aby udowodnić, że jest Samem. Jeśli skrypt odblokowujący pasuje do wyżej wymienionego skryptu blokującego, Sam może odblokować i przekazać bitcoiny innym osobom.

(Skrypt odblokowujący musi odpowiadać skryptowi blokującemu)

Z punktu widzenia ekspresji każda transakcja w łańcuchu Bitcoin odpowiada wielu Wejściom i Wyjściom. Każde Wejście musi zadeklarować określone UTXO, które chce odblokować, i przesłać skrypt odblokowujący, aby odblokować i zniszczyć Wyjście UTXO. Nowo wygenerowana informacja UTXO; zostanie wyświetlony, a zawartość skryptu blokującego zostanie ujawniona światu zewnętrznemu.

Na przykład, wprowadzając transakcję, udowadniasz, że jesteś Samem, odblokowujesz wiele UTXO otrzymanych od innych, niszczysz je w jednolity sposób, generujesz wiele nowych UTXO i deklarujesz, że xxx zostanie odblokowane w przyszłości.

W szczególności w danych wejściowych transakcji musisz zadeklarować, które UTXO chcesz odblokować i wskazać „miejsce przechowywania” tych danych UTXO. Należy tutaj zauważyć, że Bitcoin i Ethereum są całkowicie różne. Ethereum zapewnia dwa konta, konta kontraktowe i konta EOA, do przechowywania danych. Saldo aktywów jest rejestrowane jako liczba pod nazwą konta kontraktowego lub konta EOA i jest umieszczane w ujednoliconej bazie danych „Państwa Świata” podczas przesyłania pieniędzy określone konta można modyfikować bezpośrednio z poziomu „Państwa Świata”, aby ułatwić zlokalizowanie miejsca przechowywania danych;

Bitcoin nie ma projektu stanu świata, a dane o aktywach są rozproszone i przechowywane w poprzednich blokach (to znaczy odblokowane dane UTXO są przechowywane osobno w OutPut każdej transakcji).

Jeśli chcesz odblokować UTXO, musisz wskazać, dla której transakcji dane wyjściowe informacje UTXO istnieją w przeszłości, pokazać identyfikator transakcji (który jest jej skrótem) i pozwolić węzłowi Bitcoin poszukać go w zapisach historii. Jeśli chcesz sprawdzić saldo Bitcoinów pod określonym adresem, musisz przejść wszystkie bloki od początku i znaleźć odblokowane UTXO powiązane z adresem xx.

Kiedy zwykle korzystasz z portfela Bitcoin, możesz szybko sprawdzić saldo Bitcoinów należące do określonego adresu. Dzieje się tak często dlatego, że usługa portfela sama indeksuje wszystkie adresy poprzez skanowanie bloków, co ułatwia nam szybkie wysyłanie zapytań.

(Kiedy generujesz zestawienie transakcji, aby przekazać swoje UTXO innym, musisz zaznaczyć pozycję UTXO w historii Bitcoin na podstawie skrótu/identyfikatora transakcji, do którego należą te UTXO)

Co ciekawe, wyniki transakcji Bitcoin są obliczane poza łańcuchem. Kiedy użytkownicy generują transakcje na swoich urządzeniach lokalnych, muszą bezpośrednio utworzyć zarówno dane wejściowe, jak i wyjściowe, co jest równoznaczne z obliczeniem wyników wyjściowych transakcji. Transakcje są transmitowane do sieci Bitcoin i weryfikowane przez węzły przed umieszczeniem w łańcuchu. Ten model „weryfikacji obliczeń poza łańcuchem” różni się całkowicie od modelu Ethereum. W Ethereum wystarczy podać parametry wejściowe transakcji, a wyniki transakcji są obliczane i wysyłane przez węzeł Ethereum.

Ponadto można dostosować skrypt blokujący UTXO (skrypt blokujący). Można ustawić UTXO tak, aby był „odblokowywany przez właściciela określonego adresu Bitcoin”. Właściciel adresu musi podać podpis cyfrowy i klucz publiczny (P2PKH ). W przypadku transakcji typu Pay-to-Script-Hash (P2SH) możesz dodać Script Hash w skrypcie blokującym UTXO. Kto może przesłać oryginalny obraz skryptu odpowiadający temu Hashowi i spełnić ustalone warunki w oryginalnym obrazie skryptu? możesz odblokować UTXO. Skrypt Taproot, na którym opiera się BitVM, wykorzystuje funkcje podobne do P2SH.

Jak uruchomić skrypt Bitcoin

Tutaj najpierw użyjemy P2PKH jako przykładu, aby przedstawić metodę wyzwalania skryptu Bitcoin. Tylko poprzez zrozumienie jego metody wyzwalania możemy zrozumieć bardziej złożone Taproot i BitVM. Pełna nazwa P2PKH to „Pay to Public Key Hash”. W tym schemacie skrót klucza publicznego zostanie ustawiony w skrypcie blokującym UTXO, a klucz publiczny odpowiadający temu skrótowi musi zostać przesłany podczas odblokowywania taki sam jak konwencjonalny pomysł na transfer Bitcoin.

W tym momencie węzeł Bitcoin musi potwierdzić, że klucz publiczny w skrypcie odblokowującym jest zgodny ze skrótem klucza publicznego określonym w skrypcie blokującym. Innymi słowy, musi potwierdzić, że „klucz” przesłany przez moduł odblokowujący i ustawienie wstępne „blokady”. przez UTXO pasują do siebie.

Ponadto w schemacie P2PKH po otrzymaniu transakcji węzeł Bitcoin splei podany przez użytkownika skrypt odblokowujący ScriptSig ze skryptem blokującym ScriptPubkey UTXO, które ma zostać odblokowane, i wykona je w środowisku wykonawczym skryptu BTC. Poniższy rysunek przedstawia wyniki splotu przed wykonaniem:

Być może czytelnicy nie znają środowiska wykonywania skryptów BTC, dlatego tutaj pokrótce je przedstawimy. Po pierwsze, skrypt BTC zawiera dwa elementy:

dane i kody operacyjne. Te dane i kody operacji zostaną umieszczone na stosie w kolejności od lewej do prawej i wykonane zgodnie z określoną logiką, aby uzyskać końcowy wynik (szczegóły tego, czym jest stos, nie będą tutaj opracowywane, czytelnicy mogą sami porozmawiać).

Biorąc powyższe zdjęcie jako przykład, po lewej stronie znajduje się skrypt odblokowujący ScriptSig przesłany przez kogoś, zawierający jego podpis cyfrowy i klucz publiczny, natomiast skrypt blokujący ScriptPubkey po prawej stronie zawiera kod operacji i dane ustawione przez twórcę UTXO podczas generowania UTXO (nie musimy tutaj rozumieć znaczenia każdego kodu operacji, wystarczy przybliżone zrozumienie).

Kody DUP, HASH160, EQUALVERIFY i inne kody operacji w skrypcie blokującym po prawej stronie na powyższym rysunku są odpowiedzialne za mieszanie klucza publicznego zawartego w skrypcie odblokowującym po lewej stronie i porównywanie go z ustawionym skrótem klucza publicznego w skrypcie blokującym. Jeśli oba są równe, oznacza to, że klucz publiczny przesłany w skrypcie odblokowującym odpowiada ustawionemu skrótowi klucza publicznego w skrypcie blokującym i pierwsza weryfikacja została zakończona pomyślnie.

Istnieje jednak problem. Treść skryptu blokującego UTXO jest w rzeczywistości publiczna w łańcuchu. Każdy może zobaczyć zawarty w nim skrót klucza publicznego. Każdy może przesłać odpowiedni klucz publiczny i fałszywie twierdzić, że to on był „. mianowany przez cesarza”. ” osoba. Dlatego po weryfikacji klucza publicznego i skrótu klucza publicznego należy także sprawdzić, czy inicjator transakcji jest rzeczywiście faktycznym administratorem klucza publicznego, co wymaga weryfikacji podpisu cyfrowego. Za weryfikację podpisu cyfrowego odpowiada kod operacji CHECKSIG w skrypcie blokującym.

Podsumowując, w schemacie P2PKH skrypt odblokowujący przesłany przez inicjatora transakcji zawiera klucz publiczny i podpis cyfrowy. Klucz publiczny musi odpowiadać skrótowi klucza publicznego określonego w skrypcie blokującym, a podpis cyfrowy transakcji jest wyłącznie prawidłowy gdy te warunki zostaną spełnione, można płynnie odblokować UTXO.

(Ten obraz jest dynamiczny: schematyczny diagram skryptu odblokowującego Bitcoin w schemacie P2PKH

Źródło: https://learnmeabitcoin.com/technical/script)

Oczywiście sieć Bitcoin obsługuje wiele typów transakcji, nie tylko Pay to public key/hash klucza publicznego, ale także P2SH (hash Pay to Script) itp. Wszystko zależy od tego, jak ustawiony jest niestandardowy skrypt blokujący podczas tworzenia UTXO. .

Należy tutaj zaznaczyć, że w schemacie P2SH w skrypcie blokującym można ustawić Hash Skryptu, a skrypt odblokowujący musi przesłać pełną treść skryptu odpowiadającą Skryptowi Hash. Węzły Bitcoin mogą wykonać ten skrypt Jeśli w tym skrypcie zdefiniowana zostanie logika weryfikacji z wieloma podpisami, można uzyskać efekt portfela z wieloma podpisami w łańcuchu Bitcoin.

Oczywiście w ramach schematu P2SH twórca UTXO musi wcześniej poinformować osobę, która odblokuje UTXO, o zawartości skryptu odpowiadającej Skryptowi Hashowi. O ile obie strony znają treść tego Skryptu, możemy go wdrożyć bardziej złożona logika biznesowa niż wielokrotne podpisywanie.

Należy tutaj zauważyć, że łańcuch Bitcoin (blok) nie rejestruje bezpośrednio, które UTXO są powiązane z jakimi adresami. Rejestruje jedynie, który skrót klucza publicznego/który skrót skryptu można odblokować, ale używamy skrótu/skryptu klucza publicznego. aby go odblokować, Hash może szybko obliczyć odpowiedni adres (sekcja wyświetlana w interfejsie portfela wygląda jak zniekształcone znaki).

Powodem, dla którego widzimy xx ilości Bitcoinów pod adresem xx w eksploratorze bloków i interfejsie portfela, jest to, że eksplorator bloków i projekt portfela pomagają analizować dane, skanować wszystkie bloki i blokować skrypt zgodnie z hashem klucza publicznego/hashem skryptu zadeklarowany w, oblicza odpowiedni „adres”, a następnie wyświetla, ile Bitcoinów znajduje się pod nazwą adresu xx.

Oddzielny świadek i świadek

Gdy zrozumiemy ideę P2SH, jesteśmy o krok bliżej do Taproot, na którym opiera się BitVM. Ale wcześniej musimy zrozumieć ważne pojęcie: świadek i świadek segregowany.

Przeglądając wspomniany wcześniej skrypt odblokowujący i skrypt blokujący, a także proces odblokowywania UTXO, natkniesz się na problem: cyfrowy podpis transakcji zawarty jest w skrypcie odblokowującym, a skrypt odblokowujący nie może zostać nadpisany podczas generowania podpisu (tzw. parametry użyte do wygenerowania podpisu nie mogą być uwzględnione w samym podpisie), zatem podpis cyfrowy może obejmować jedynie część inną niż skrypt odblokowujący, czyli może być powiązany tylko z główną częścią danych transakcyjnych i nie może obejmować całości transakcji dane.

Dzięki temu nawet jeśli skrypt odblokowujący transakcję zostanie nieco zmanipulowany przez pośrednika, nie wpłynie to na wynik weryfikacji podpisu. Na przykład węzły Bitcoin lub pule wydobywcze mogą wstawić inne dane do skryptu odblokowującego transakcji, powodując subtelne zmiany w danych transakcji bez wpływu na weryfikację podpisu i wyniki transakcji. Ostateczny obliczony skrót/identyfikator transakcji również ulegnie zmianie. Nazywa się to problemem plastyczności transakcji.

Wadą tego jest to, że jeśli planujesz inicjować wiele transakcji kolejno i istnieją zależności sekwencyjne (na przykład transakcja 3 odnosi się do wyników transakcji 2, a transakcja 2 odnosi się do wyników transakcji 1), to kolejne transakcje Należy podać identyfikator (hash) poprzedniej transakcji. Każdy pośrednik taki jak basen wydobywczy czy węzeł Bitcoin może doprecyzować zawartość skryptu odblokowującego tak, aby hash po przesłaniu transakcji był z nim niezgodny. spodziewałeś się, że wiele transakcji, które utworzyłeś wcześniej, będzie zawierało transakcje powiązane sekwencyjnie, staną się nieważne.

Tak naprawdę w rozwiązaniach mostu DLC i BitVM2 transakcje z korelacją sekwencyjną będą konstruowane partiami, zatem wspomniany powyżej scenariusz nie jest rzadkością.

Mówiąc najprościej, problem skalowalności transakcji polega na tym, że identyfikator/hasz transakcji będzie uwzględniał podczas jej obliczania dane skryptu odblokowującego, a pośrednicy, tacy jak węzły Bitcoin, mogą dostroić treść skryptu odblokowującego, powodując, że identyfikator transakcji będzie różni się od tego, czego oczekiwał użytkownik, jest niezgodny. W rzeczywistości jest to historyczny bagaż pozostawiony przez złe uwzględnienie Bitcoina we wczesnym projekcie.

Późniejsza aktualizacja Segregated Witness/SegWit faktycznie całkowicie oddziela identyfikator transakcji od skryptu odblokowującego. Nie ma potrzeby uwzględniania danych skryptu odblokowującego podczas obliczania skrótu transakcji. Skrypt blokujący UTXO, który następuje po aktualizacji SegWit, domyślnie ustawi kod operacji o nazwie „OP_0”, który służy jako znak, a nazwa odpowiedniego skryptu odblokowującego została zmieniona z SigScript na Witness.

Po zastosowaniu się do zasad SegWit problem skalowalności transakcji zostanie poprawnie rozwiązany i nie będziesz musiał martwić się o dopracowanie danych transakcyjnych przesyłanych do węzła Bitcoin. Oczywiście nie musimy myśleć zbyt skomplikowanie. Funkcje P2WSH nie różnią się zasadniczo od wspomnianego wcześniej P2SH. Możesz ustawić skrót skryptu w skrypcie blokującym UTXO i poczekać, aż osoba przesyłająca skrypt odblokowujący prześle treść skryptu odpowiadająca skrótowi do łańcucha i wykonywana.

Jeśli jednak treść skryptu, który chcesz zaimplementować, jest szczególnie duża i zawiera dużo kodu, pełnego skryptu nie można przesłać do łańcucha Bitcoin konwencjonalnymi metodami (każdy blok ma limit rozmiaru). Co robić? Wymaga to użycia Taproot w celu usprawnienia zawartości skryptów w łańcuchu, a BitVM jest złożonym rozwiązaniem zbudowanym w oparciu o Taproot.

W kolejnym artykule „Approaching BTC” przeprowadzimy szczegółową popularyzację Taproot, pre-signing i innych bardziej złożonych technologii związanych z BitVM, więc bądźcie czujni!