Autor: Janos Nick, Blockstream

Opracowane przez: Bai Ding i Faust, Geek Web3

Streszczenie: Ten artykuł zwięźle, ale na temat wskazuje, jak sprawić, by Bitcoin obsługiwał funkcję weryfikacji ZK. Konkretne omówione tematy obejmują defekty funkcjonalne Bitcoin UTXO i skryptów, koncepcje takie jak Taproot i OP_CAT oraz BitVM i Chain State Proof. Ogólnie treść. W artykule przedstawiono stosunkowo jasny punkt widzenia:

Wprowadzenie ZK do protokołu Bitcoin jest nieuniknionym trendem. Istnieją dwie drogi ku temu: jedna polega na umożliwieniu skryptom Bitcoin bezpośredniej obsługi weryfikacji SNARK, co wymaga użycia kodu operacyjnego OP_CAT, a prawdopodobieństwo ostatecznego przejścia OP_CAT wynosi. bardzo wysoka; druga trasa opiera się na BitVM, konieczne jest wprowadzenie metody odpornej na oszustwa, a zespół ZeroSync zaproponował również Chain State Proofs, aby obniżyć koszty weryfikacji danych historycznych przez klienta węzła.

Tekst: Aby głębiej zrozumieć Bitcoin, najlepiej potraktować go jako system społeczny. Kiedy Bitcoin został uruchomiony na początku, programiści określili programy, które węzły Bitcoin musiały uruchomić, podobnie jak określili zestaw zasad, których powinien przestrzegać system społecznościowy. Powodem, dla którego system społeczny Bitcoina może działać stabilnie, jest to, że wszyscy mają pewien konsensus w kluczowych kwestiach, takich jak „jaka jest istota Bitcoina” i „czym powinien być”. Oczywiście osiągnięcie konsensusu nie jest łatwe, a w obliczu powyższych kwestii nadal istnieją powszechne i ewoluujące różnice.

To sięga do historycznego pochodzenia Bitcoina. Kiedy Satoshi Nakamoto opublikował białą księgę dotyczącą Bitcoina, powiedział: „Pracuję nad zupełnie nowym systemem płatności elektronicznych. Ten system jest całkowicie P2P i nie musi polegać na żadnej stronie trzeciej”. Fragment ten został opublikowany na liście mailingowej Cypherpunks (e-mailowej grupie dyskusyjnej założonej w 1992 roku, składającej się z grupy kryptografów i entuzjastów technologii zainteresowanych ochroną prywatności i technologią kryptograficzną).

Jednak Bitcoin ogranicza przepustowość danych na poziomie projektu produktu. Liczba transakcji, które może przetworzyć w jednostce czasu, jest ograniczona. Jeśli liczba transakcji do przetworzenia szybko wzrośnie, użytkownicy wszcząją wojnę cenową, aby szybko zakończyć transakcję, szybko zwiększając uiszczane opłaty manipulacyjne. Pojedyncza transakcja z najwyższą opłatą manipulacyjną w sieci Bitcoin miała miejsce po zmniejszeniu nagrody za blok o połowę w 2024 r., a opłata manipulacyjna za transakcję o średnim priorytecie w łańcuchu osiągnęła 150 USD. Można powiedzieć, że problemem stały się wysokie opłaty transakcyjne sieci Bitcoin.

Aby rozwiązać problem opłat transakcyjnych, ludzie zainwestowali wiele zasobów w rozwój Lightning Network. Jednak według artykułu opublikowanego w 2016 r. Lightning Network może w praktyce obsługiwać jedynie dziesiątki milionów użytkowników i nie może zrealizować swojej wizji globalnego systemu płatności.

Oprócz tego, że opłaty transakcyjne są zbyt wysokie, istnieje również problem, że Bitcoin nigdy nie był w stanie osiągnąć zakładanej anonimowości. Satoshi Nakamoto zwrócił uwagę w cypherpunkowej grupie dyskusyjnej e-mail, że Bitcoin ma funkcję ochrony prywatności, a inicjator transakcji może być całkowicie anonimowy. Jednakże, chociaż inicjator transakcji nie wymaga KYC, dane transakcyjne w łańcuchu Bitcoin powodują wyciek wielu informacji, w dużym stopniu narażając prywatność użytkownika.

Chociaż istnieją klienci portfeli z funkcjami prywatności, którzy w pewnym stopniu rozwiązują powyższe problemy, twórcy tych klientów portfeli stają w obliczu zagrożeń o różnej skali. Na przykład twórca portfela Samourai CoinJoin został aresztowany przez FBI w kwietniu 2024 r., a tydzień później twórca portfela Wasabi zamknął komponent koordynujący CoinJoin. Oczywiście te tak zwane portfele prywatne nie są w pełni godne zaufania użytkowników.

Podsumowując, wiele koncepcji Bitcoina jest do dziś dalekich od realizacji, a technologie z nimi związane są wciąż w fazie ciągłego rozwoju. Mimo to wiele osób w społeczności Bitcoin uważa, że ​​projekt protokołu Bitcoin powinien pozostać niezmieniony, ale jest też wiele osób, takich jak ja, które pasjonują się wprowadzaniem ulepszeń w Bitcoinie. Zatem w jakim kierunku Bitcoin powinien się rozwijać?

W odpowiedzi na powyższe problemy w społeczności Bitcoina pojawia się wiele propozycji, a te z najlepszym efektem teoretycznym należy wiązać z ZK i SNARK. Dzięki ZK i SNARK można osiągnąć następujące funkcje:

1. Znacząco popraw prywatność: użyj homomorficznego Petersona, aby zatwierdzić kwotę transakcji i Range Proof, aby znacznie poprawić prywatność użytkowników (tak jak to zrobiono w łańcuchu bocznym Element Blockstream); ukryj ślady transakcji za pomocą podpisów, które można połączyć (takich jak Monero); Zcasha).

2. Popraw przepustowość transakcji

W rzeczywistości istnieje wiele środków technicznych, które mogą rozwiązać problemy istniejące w Bitcoinie, ale dlaczego technologie te nie zostały dodane do protokołu Bitcoin aż do dzisiaj? Dzieje się tak dlatego, że protokół Bitcoin jest trudny do modyfikacji. W ekosystemie Bitcoin nie ma organizacji podobnej do Fundacji Ethereum. Jakakolwiek modyfikacja protokołu wymaga wysokiego stopnia konsensusu społeczności. Wiąże się to z wieloma grami oraz kontrolą i balansem mocy, więc w przeciwieństwie do Ethereum, w każdym przypadku będą dostępne kody operacyjne EVM. roku Od czasu jego powstania wprowadzono bardzo niewiele aktualizacji protokołu Bitcoin.

Tak naprawdę to dobrze, że protokół jest trudny do modyfikacji w pewnym stopniu. Jeśli modyfikowanie protokołu Bitcoin jest łatwe, łatwo będzie także dokonać złośliwych zmian i ataków. Nasuwa się pytanie: czy istnieją sposoby na poprawę wydajności Bitcoina bez zmiany projektu protokołu Bitcoin?

Aby odpowiedzieć na to pytanie, musimy najpierw przejrzeć to, co wiemy o Bitcoinie. Jeśli chcemy przekazać Bitcoin komuś innemu, musimy utworzyć transakcję i rozesłać ją do sieci Bitcoin. Dane wyjściowe transakcji wskażą kwotę przesłanego BTC, a odbiorca BTC może utworzyć nową transakcję, aby wydać otrzymane BTC. Następnie ta nowa transakcja wygeneruje nowe dane wyjściowe i wyśle ​​​​BTC do innych.

Należy tutaj zauważyć, że Bitcoin nie ma stanu globalnego jak Ethereum, zwłaszcza stanu bez kont, a jedynie dane wyjściowe transakcji. Dane wyjściowe każdej transakcji mają dwa stany: wydane przez odbiorcę lub niewydane. Niewydane dane wyjściowe transakcji to znany format UTXO.

Oczywiście oprócz powiązanej kwoty BTC, każda transakcja ma dodatkowy program napisany w języku zwanym Bitcoin Script. Każdy, kto może dostarczyć poprawny dowód na obecność tego programu, może wydać wynik tej transakcji (UTXO). Sam skrypt Bitcoin jest językiem programowania opartym na stosie, który zawiera szereg kodów operacji. Wspomniane dodatki UTXO często składają się z wielu kodów operacji. Wykonują obliczenia w oparciu o stos i umieszczają wyniki z powrotem na stosie.

Istnieje wiele typów popularnych skryptów Bitcoin, które istnieją od początków istnienia Bitcoina. Na przykład najpopularniejszy skrypt w Bitcoin składa się z klucza publicznego + kodu operacyjnego, który sprawdza podpis cyfrowy. Ten kod operacji stanowi, że aby wydać/odblokować UTXO, należy przedstawić podpis cyfrowy odpowiedniego klucza publicznego.

Tutaj podsumowujemy funkcjonalność Bitcoin Script. Po pierwsze, co może zrobić Bitcoin Script?

• Można zmieniać układ stosu, sprawdzać równość (za pomocą sprawdzania równości w celu sprawdzenia, czy spełnione są określone warunki, zapewniając w ten sposób bezpieczeństwo i ważność transakcji) oraz wykonywać operacje rozgałęziające podobne do operacji if-else.

• Na liczbach 32-bitowych można wykonywać ograniczone operacje arytmetyczne, a mianowicie dodawanie i odejmowanie.

• Dane można szyfrować oraz sprawdzać podpisy ECDSA i Schnorr.

Czego nie potrafi Bitcoin Script?

• Nie ma tu żadnych pętli, skoków i rekurencji, czyli nie jest to kompletny Turing, a możliwości programowania są bardzo ograniczone.

• Operacje bitowe nie są możliwe.

• Brak rozkazów do mnożenia i dzielenia.

• Nie można łączyć elementów na stosie.

• Prawie nie ma możliwości odczytania i sprawdzenia danych transakcji w łańcuchu. Skrypty Bitcoin nie mają bezpośredniego dostępu do kwoty każdej transakcji i nie ma możliwości przekazania statusu (UTXO są jednorazowe, a stare są niszczone i przy każdym przelewie generowane są nowe).

We wczesnych wersjach Bitcoina niektórych rzeczy „nie da się zrobić” w powyższych skryptach faktycznie można było zrobić, ale niektóre funkcje zostały później wyłączone przez Satoshiego Nakamoto, ponieważ Satoshi Nakamoto odkrył, że w tych rozkazach są luki. Na przykład kod operacji OP_CAT, który może połączyć dwa elementy stosu, może zostać użyty do zdalnego ataku na węzeł Bitcoin, aby spowodować jego zawalenie. Satoshi Nakamoto przez ostrożność wyłączył OP_CAT, a niektóre inne rozkazy również zostały wyłączone.

Czy skrypt Bitcoin może zweryfikować SNARK? Chociaż skrypt Bitcoin nie jest teoretycznie kompletny w technologii Turinga, jego podstawowe operacje wystarczą do zweryfikowania wszelkich obliczeń, jednak w praktyce weryfikacja SNARK jest nadal nieosiągalna, ponieważ rozmiar programu wymagany do etapu weryfikacji przekracza maksymalny limit bloku Bitcoin wynoszący 4 MB.

Być może moglibyśmy spróbować wykonać operacje arytmetyczne na dużych, skończonych polach, ale koszt jest bardzo wysoki. Na przykład pomnożenie dwóch 254-bitowych liczb całkowitych zaimplementowanych przez BitVM powoduje, że związany z tym rozmiar skryptu Bitcoin osiąga prawie 8KB.

Co więcej, weryfikacja dowodów Merkle'a bez OP_CAT jest również kosztowna, ponieważ wymaga operacji podobnych do pętli for.

Wracając do poprzedniego pytania: dlaczego nie możemy po prostu zmienić protokołu Bitcoin i dodać potężniejszych opkodów?

Jak wspomniano wcześniej, bardzo trudno jest osiągnąć konsensus większości w sprawie nowych zasad protokołu, ponieważ w ekosystemie Bitcoin nie ma scentralizowanego organu decyzyjnego. Każda propozycja ulepszenia skryptu Bitcoin budzi wiele zastrzeżeń. Stanowisko i perspektywa każdego z nas jest inna. W sieci Bitcoin nie ma dobrego sposobu na zmierzenie, czy społeczność osiągnęła konsensus większości, a wymuszenie aktualizacji w tym przypadku doprowadzi do rozwidlenia łańcucha.

Oczywiście Bitcoin nie jest całkowicie statyczny, a najnowsze aktualizacje to SegWit w 2017 r. i Taproot w 2021 r.

Aktualizacja Taproot zmieniła wiele zasad. Od teoretycznej wersji do faktycznej aktywacji minęło trzy i pół roku. Kluczowym czynnikiem umożliwiającym Taproot jest to, że nie zmienia on istniejących założeń bezpieczeństwa i stanowi wyraźne ulepszenie protokołu Bitcoin. Na przykład umożliwia użycie podpisów Schnorra zamiast ECDSA. Obydwa opierają się na założeniu logarytmu dyskretnego i wykorzystują te same krzywe eliptyczne, ale pierwsza jest bardziej wydajna i mniej wymagająca obliczeniowo niż druga.

Co więcej, ulepszenia Bitcoina wprowadzone przez Taproot dzielą się głównie na trzy następujące części:

Po pierwsze, Taproot zmniejsza koszt weryfikacji skryptów dzięki dużej liczbie selektywnych gałęzi, umożliwiając Bitcoinowi obsługę bardziej złożonych programów;

Po drugie, Taproot redukuje dane skryptu, które należy ujawnić w łańcuchu. Możesz złożyć wiele skryptów w drzewo Merkle, przy czym każdy skrypt znajduje się na innym liściu. Jeśli chcesz uruchomić określony skrypt, wystarczy go ujawnić Liść, na którym się znajduje, i dowód Merkle'a;

Po trzecie, Taproot dodał także inne projekty mechanizmów.

Powiedziawszy to, skoro Bitcoin ma precedens w dodawaniu potężniejszych funkcji, takich jak Tarpoot, dlaczego nie dodać dedykowanego kodu operacji w celu weryfikacji SNARK? Dzieje się tak, ponieważ dodanie tak zwanego kodu operacyjnego OP_SNARK bardzo różni się od aktualizacji Taproot.

Po pierwsze, istnieje wiele pomysłów projektowych dla OP_SNARK i większości ludzi trudno jest wesprzeć jedno rozwiązanie; po drugie, jeśli taka propozycja zostanie przyjęta, wszystkie węzły Bitcoin będą musiały obsługiwać to konkretne rozwiązanie OP_SNARK, co spowoduje ogromne obciążenie techniczne .

Ponadto sama złożoność OP_SNARK również jest dużym wyzwaniem. Jeśli testy nie są uwzględnione, Taproot dodaje tylko około 1600 linii kodu, co jest akceptowalne, podczas gdy OP_SNARK zawiera znacznie bardziej złożony kod.

Ponadto, kto sprawdzi, czy kod operacyjny OP_SNARK powinien zostać aktywowany? Jak osiągnąć konsensus w obrębie ekosystemu Bitcoin bez zrozumienia jego szczegółów przez kilka osób? To wszystko są pytania. Dlatego ogólnie aktualizacja OP_SNARK nie nastąpi w krótkim czasie.

Istnieją jednak inne sposoby weryfikacji SNARK w skrypcie Bitcoin. Możemy sprawić, że skrypty Bitcoin będą bardziej funkcjonalne, dodając prostsze kody operacji, umożliwiając ludziom implementację programów walidacyjnych SNARK w skryptach. Ale w rzeczywistości bardzo trudno jest napisać program weryfikacyjny SNARK w języku skryptowym Bitcoin.

Dlatego zespół badawczy Blockstream opracowuje Simplicity, język programowania mający zastąpić Bitcoin Script. Prostota została specjalnie zaprojektowana dla systemów konsensusu blockchain i celowo nie jest kompletna w oparciu o technologię Turinga, co ułatwia analizę statyczną i formalną weryfikację.

Poniżej omówimy bardzo prostą, ale poważną propozycję, która może uczynić Bitcoin Script potężniejszym, czyli opcode OP_CAT. Wspomnieliśmy wcześniej, że OP_CAT istniał w początkowej wersji Bitcoin, ale ten kod operacji może w pewnych warunkach spowodować atak na węzły Bitcoin DOS, więc został wyłączony przez Satoshi Nakamoto. Teraz niektórzy ludzie w społeczności Bitcoin chcą go ponownie włączyć.

OP_CAT polega na umieszczeniu dwóch elementów na górze stosu, połączeniu ich i ponownym umieszczeniu na stosie. Brzmi to bardzo prosto, ale może przynieść ogromne ulepszenia funkcjonalne skryptów Bitcoin.

Na przykład skrypty Bitcoin pierwotnie nie mogły uzyskać dostępu do informacji o statusie, takich jak liczba transakcji w łańcuchu, ale dzięki OP_CAT będzie to możliwe również do weryfikacji dowodów Merkle. Krótko mówiąc, OP_CAT jest aktualizacją na podstawowym poziomie kodu operacji, z której wynika wiele nowych funkcji. Wiele osób zaproponowało efekty, które można osiągnąć za pomocą OP_CAT.

I czy OP_CAT pomaga weryfikować SNARK w skryptach? Odpowiedź jest pomocna, ponieważ wspieranie weryfikacji dowodów Merkle pomaga weryfikować SNARK oparte na FRI, a OP_CAT może to wspierać. W przeszłości skrypty biorące udział w weryfikacji SNARK mogły być zbyt duże, aby zmieścić się w bloku Bitcoin. Dzięki OP_CAT można było zmniejszyć rozmiar programu.

OP_CAT był omawiany od wielu lat i coraz więcej osób dostrzega jego rolę w kontroli transakcji (introspekcji). Zaletą OP_CAT w porównaniu do innych propozycji jest to, że istniał on już wcześniej w Bitcoin Script, dzięki czemu łatwiej jest osiągnąć konsensus w społeczności. Jednak aktywacja OP_CAT może również spowodować uszkodzenie dochodów MEV niektórych osób, więc społeczność Bitcoin nie osiągnęła jeszcze konsensusu w tej sprawie.

Podsumowując, może istnieć potencjalna ścieżka dla Bitcoina umożliwiająca weryfikację SNARK w skryptach Bitcoin poprzez włączenie prostych opkodów, takich jak OP_CAT. Warto również wspomnieć, że istnieje niedawna propozycja o nazwie „Wielkie przywracanie skryptu”, która umożliwia mnożenie kodów operacji, dzięki czemu wszystkie kody arytmetyczne działają z dowolną precyzją.

Dodatkowo, rozważając wpływ OP_CAT na sieć Bitcoin, możemy zbadać wpływ na operatorów węzłów Bitcoin po jego przejściu. Aby uczynić Bitcoin odpornym na cenzurę i zdecentralizowanym, społeczność Bitcoin chce, aby jak najwięcej osób uruchamiało węzły w celu weryfikacji danych. Jeśli Bitcoin obsługuje operację weryfikacji SNARK, koszt uruchomienia węzła Bitcoin nie wzrośnie znacząco, co nie wyrządzi dużej szkody bezpieczeństwu i odporności Bitcoina na cenzurę.

Obecnie blok Bitcoin może zawierać do 4 MB danych i oczekuje się, że blok będzie wydobywany co 10 minut, a prawie cały blok można wypełnić skryptami Bitcoin i świadkami świadków (podobnie jak podpisy cyfrowe). Obliczono, że każdy blok może obecnie zawierać do 80 000 weryfikacji podpisów. Średnio każdy blok obsługuje weryfikację podpisu od 7 000 do 10 000. Mój procesor Intel 2020 potrzebuje średnio 3,2 sekundy na weryfikację bloku Bitcoin. Oczywiście nie tylko czasochłonna weryfikacja podpisu wpływa na szybkość weryfikacji bloku.

Ponadto, jeśli transakcje Bitcoin będą w przyszłości wspierać ZK, wydaje się to nieszkodliwe, nawet jeśli czas generowania transakcji się wydłuży. W przypadku portfeli sprzętowych używanych do długoterminowego przechowywania aktywów mają one zazwyczaj ekrany i nie są duże. Ich funkcją jest przechowywanie kluczy i generowanie podpisów. Procesor portfeli sprzętowych jest generalnie stosunkowo słaby, np. dwurdzeniowy procesor 240 MHz z pewną ilością pamięci, który bardzo szybko reaguje podczas podpisywania transakcji Bitcoin.

Przeprowadziłem małą ankietę, pytając użytkowników o maksymalne opóźnienie, jakie zaakceptowaliby, aby urządzenie podpisujące wygenerowało dowód, i wiele osób nie zgodziło się na dłuższe oczekiwanie, zwłaszcza jeśli można było zyskać znaczące korzyści. Jeśli więc wprowadzimy ZK do transakcji Bitcoinem, nie wydaje się, że będzie to duży problem.

Poświęciliśmy dużo miejsca na dyskusję powyżej, jak zmienić podstawowy projekt Bitcoina, ale w rzeczywistości istnieje wiele scenariuszy zastosowań, które można wdrożyć bez zmiany Bitcoina. Tutaj chciałbym wyróżnić aplikację związaną z BitVM - Chain State Proofs, która łączy ZK w celu udowodnienia ważności skrótu bloku.

Jakie zmiany ta technologia wniosła do Bitcoina? Po pierwsze, dzięki Chain State Proofs można skompresować obciążenie związane z synchronizacją i weryfikacją danych kalendarza Bitcoin, co znacznie zmniejsza koszty funkcjonowania węzłów. Obecnie synchronizacja i weryfikacja najnowszego bloku Bitcoin z bloku Genesis na urządzeniu z dobrym sprzętem zajmuje 5 godzin i 30 minut, natomiast na urządzeniu na poziomie Raspberry Pi zajmie to kilka dni, tym razem -zużywający proces można znacznie ograniczyć. Po drugie, dowód stanu łańcucha jest ważną częścią, którą można wykorzystać z BitVM i będzie promować wdrożenie BitVM.

Zespół ZeroSync przeprowadził dogłębne badania dotyczące dowodów stanu łańcucha i stworzył lżejszy „dowód łańcucha nagłówków”. To rozwiązanie w połączeniu z ZK potwierdza jedynie ważność nagłówka bloku Bitcoin, tworząc w ten sposób „łańcuch nagłówków”, zawierający wszystkie 850 000. nagłówki bloków w historii Bitcoin i generuje 80-bajtowy skrót dla każdego nagłówka bloku.

Ten schemat wymaga podwójnych obliczeń SHA-256 na każdym nagłówku bloku Bitcoin, aby zweryfikować odpowiedni dowód PoW. ZeroSync używa STARK do wygenerowania dowodu łańcucha nagłówkowego Bitcoina. Koszt wygenerowania dowodu wynosi około 4000 dolarów, a weryfikacja dowodu w mojej przeglądarce zajmuje tylko 3 sekundy.

Ponieważ jednak nie obejmuje procesu weryfikacji zawartości transakcji w bloku, dowód łańcucha nagłówka może jedynie zakładać, że łańcuch bloków z największą liczbą dowodów POW jest ważny i domyślnie pozwala klientowi Bitcoin na synchronizację najnowszego bloku w tym łańcuchu . W tym scenariuszu, chociaż osoba atakująca może utworzyć blok zawierający nieprawidłowe transakcje, dodać więcej bloków po tym bloku i wygenerować dowód łańcucha nagłówka, aby oślepić klienta Bitcoin, który synchronizuje dane historyczne, przeprowadzenie ataku byłoby niezwykle kosztowne i byłoby zostać bezpośrednio obalone przez istniejących klientów pełnego węzła Bitcoin.

Jednak pomimo niskiego wskaźnika powodzenia tego scenariusza ataku, zabezpieczenia łańcucha nagłówkowego nie można uznać za niezawodne rozwiązanie, jeśli pozwala atakującemu ukraść ogromną ilość BTC. Jeśli chcemy udowodnić kompletny stan łańcucha, musimy bezpośrednio udowodnić, że wszystko w bloku Bitcoin jest prawidłowe, łącznie z weryfikacją podpisu ECDSA i Schnorra w oparciu o krzywą eliptyczną secp256k1.

Miesięczne bloki historyczne Bitcoina mogą zawierać 30 milionów podpisów, a historia zawiera łącznie 2,5 miliarda operacji podpisów i dużą liczbę operacji SHA-256. W ten sposób sieć Bitcoin generuje co miesiąc około 7 GB danych blokowych, a wszystkie dane historyczne łącznie obejmują ponad 650 GB. W rzeczywistych sytuacjach liczba ta może być 2 do 3 razy większa.

Teraz spójrzmy na BitVM. BitVM pozwala Bitcoinowi zweryfikować dowolne zadanie obliczeniowe i jest najlepszą ścieżką do osiągnięcia weryfikacji SNARK bez zmiany protokołu. BitVM wykorzystuje dwie techniki, aby ominąć limit rozmiaru skryptu blokowego Bitcoin. Po pierwsze, wykorzystuje strukturę skryptu Taproot MerkleTree;

Po drugie, umożliwia schemat przechowywania KV, do którego można uzyskać dostęp za pośrednictwem jednego skryptu, umożliwiając połączenia z dużą liczbą skryptów. Jednakże protokół Bitcoin nie wymusza integralności powyższego schematu przechowywania KV. BitVM musi sprawdzić złośliwego Provera pod kątem oszustwa. Jeśli Prover wyda nieprawidłowe oświadczenie lub problematyczne przechowywanie KV, inne osoby mogą zainicjować transakcję w łańcuchu Bitcoin. , wskazując, że Prover zachował się niewłaściwie i odebrał mu wcześniej zastawiony majątek.

Podsumowując, Bitcoin stoi przed poważnymi wyzwaniami i zaproponowano różne rozwiązania, aby rozwiązać te problemy, jednak propozycje te nie zostaną szybko przyjęte przez społeczność Bitcoin, a zmiany w protokole nie mogą zostać zakończone w krótkim terminie zarówno dobrą, jak i złą rzeczą, oznacza to również, że Bitcoin jest zdecentralizowany i bezpieczniejszy.

Wiele osób w społeczności Bitcoin jest podekscytowanych potencjałem SNARK/STARK. Najbardziej wykonalną metodą osiągnięcia weryfikacji SNARK w perspektywie średnio- i długoterminowej jest najprawdopodobniej BitVM, ale wymaga ona większych inwestycji w badania i rozwój, aby była skuteczna w praktyce;

Ponowne włączenie kodu operacji OP_CAT jest również pomysłem, ale należy udowodnić, że korzyści z ponownego uruchomienia kodu operacji znacznie przewyższają ryzyko i zbadać, jakie proste kody operacji mogą pozwolić na weryfikację SNARK w skryptach Bitcoin lub zbadać, jakie scenariusze są podobne do funkcji OP_CAT może osiągnąć. Bez względu na to, które rozwiązanie zostanie wybrane, ostatecznym celem społeczności Bitcoin musi być uczynienie produktu praktycznym i wspieranie scenariuszy bardziej możliwych do wdrożenia.