Napisał: Chakra Research

Przegląd

W porównaniu z kompletnymi łańcuchami bloków Turinga, takimi jak Ethereum, skrypty na Bitcoinie są uważane za bardzo ograniczone i mogą wykonywać tylko podstawowe operacje i nie obsługują nawet mnożenia i dzielenia. Co ważniejsze, dane samego blockchainu są prawie niemożliwe do odczytania przez skrypty, co skutkuje poważnym brakiem elastyczności i niską programowalnością. Dlatego ludzie od dawna próbują znaleźć sposoby na uczynienie skryptów Bitcoin introspekcyjnymi.

Introspekcja odnosi się do możliwości umożliwienia skryptom Bitcoin sprawdzania i ograniczania danych transakcyjnych. Pozwala to skryptom kontrolować wykorzystanie środków w oparciu o konkretne szczegóły transakcji, co pozwala na bardziej złożoną funkcjonalność. Większość obecnych kodów operacyjnych Bitcoin (kodów operacji) ma tylko dwie funkcje: wypychanie danych dostarczonych przez użytkownika na stos lub operowanie na istniejących danych na stosie. Kod operacji introspekcji może wypchnąć bieżące dane transakcji (takie jak znacznik czasu, kwota, identyfikator transakcji itp.) na stos, aby zapewnić bardziej precyzyjną kontrolę nad sposobem wydawania UTXO.

Obecnie tylko trzy główne kody operacji w Bitcoin Script obsługują introspekcję: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY i CHECKSIG; CHECKSIG ma również warianty, takie jak CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG i CHECKMULTISIGVERIFY.

Mówiąc najprościej, umowa stanowi ograniczenie sposobu przesyłania tokenów. Użytkownicy mogą określić metodę dystrybucji UTXO w ramach umowy. Wiele kontraktów jest realizowanych poprzez kody introspekcji, a introspekcja została obecnie omówiona w ramach wpisów kontraktów w Bitcoin Optech.

Bitcoin ma obecnie dwa kontrakty, CSV (CheckSequenceVerify) i CLTV (CheckLockTimeVerify), oba są kontraktami czasowymi, które stanowią podstawę wielu planów ekspansji, takich jak Lightning Network. Widzimy z tego również, że plan ekspansji Bitcoina w dużej mierze opiera się na introspekcji i kontraktach.

Jak dodać ograniczenia w transferze tokenów? W świecie szyfrowania najczęściej stosowaną metodą jest zaangażowanie, które często jest realizowane za pomocą skrótu. Aby udowodnić, że spełniamy wymogi przelewu, musimy to zweryfikować poprzez mechanizm podpisu. Dlatego w umowie istnieje wiele dostosowań do skrótów i podpisów.

Poniżej opisujemy szeroko dyskutowaną propozycję opcode kontraktu.

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify) to aktualizacja Bitcoina gorąco dyskutowana przez społeczność i zawarta w BIP-119. CTV umożliwia skryptowi wyjściowemu określenie szablonu wykorzystania środków w transakcji wydatków, w tym nVersion, nLockTime, skrótu scriptSig, liczby wejściowej, skrótu sekwencji, liczby wyjściowej, skrótu wyjściowego, indeksu wejściowego i innych pól transakcji ograniczenia są przekazywane przez skrót. Aby to osiągnąć, przyszły skrypt wydatków sprawdzi, czy wartość skrótu określonego pola w transakcji wydatków odpowiada wartości skrótu w skrypcie wejściowym. Te szablony faktycznie ograniczają czas, metodę, kwotę i inne szczegóły transakcji przyszłych wydatków UTXO.

Warto zauważyć, że wejściowy TXID jest wyłączony z obietnicy skrótu. To wykluczenie jest konieczne, czy to w transakcjach Legacy czy Segwit, w domyślnym typie podpisu SIGHASH_ALL, TXID musi zostać wygenerowany na podstawie wartości scriptPubKey. Dlatego włączenie TXID spowoduje pętlę w obietnicy skrótu, której nie można pomyślnie zbudować.

Sposób, w jaki CTV implementuje introspekcję, polega na bezpośrednim uzyskaniu określonych informacji o transakcji poprzez nowy kod operacji, zaszyfrowaniu ich i porównaniu z zaangażowaniem na stosie. Ta metoda introspekcji zajmuje mniej miejsca w łańcuchu, ale brakuje jej pewnej elastyczności.

Podstawą rozwiązań drugiej warstwy Bitcoin, takich jak Lightning Network, są transakcje z podpisem wstępnym. Podpisywanie wstępne zwykle oznacza generowanie i podpisywanie transakcji z wyprzedzeniem, ale nie publikowanie ich w sieci, dopóki nie zostaną spełnione określone warunki. Zasadniczo CTV wdraża bardziej rygorystyczną funkcję wstępnego podpisu, publikując wcześniej podpisane zobowiązanie bezpośrednio w łańcuchu, a transakcje można przeprowadzać wyłącznie według wstępnego szablonu.

Pierwotnie zaproponowano CTV, aby złagodzić zatory Bitcoin, co można również nazwać kontrolą zatorów. Gdy Bitcoin jest stosunkowo przeciążony, CTV można wykorzystać do zatwierdzenia wielu przyszłych transakcji w ramach pojedynczej transakcji bez konieczności rozgłaszania wielu transakcji w czasie przeciążenia, a następnie dokończyć rzeczywistą transakcję po zmniejszeniu przeciążenia bloku. Kontrola zatorów może być bardzo pomocna, gdy giełda doświadcza runu. Ponadto szablony można również wykorzystać do wdrożenia skarbców w celu zapobiegania atakom hakerów. Ponieważ miejsce docelowe środków jest określone, haker nie może wysłać UTXO za pomocą skryptu CTV na swój własny adres.

CTV może przynieść ogromne ulepszenia w sieciach warstwy 2. Na przykład, w celu wdrożenia drzew Timeout i fabryk kanałów w sieci Lightning Network, za pośrednictwem CTV pojedynczy UTXO można rozszerzyć do drzewa CTV i jednocześnie otworzyć wiele kanałów stanu, podczas gdy jest tylko jedna transakcja i jedno potwierdzenie na łańcuchu. Ponadto CTV zapewnia także obsługę transakcji atomowych ATLC w protokole Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 proponuje nowy typ podpisanej flagi skrótu dla tapscriptu, aby ułatwić pisanie bardziej elastycznej logiki wydatków, zwany SIGHASH_ANYPREVOUT. APO i CTV są podobne pod wieloma względami. W obliczu problemu pętli pomiędzy scriptPubKeys i TXID, rozwiązaniem APO jest wykluczenie informacji związanych z danymi wejściowymi i podpisanie jedynie danych wyjściowych, tak aby transakcje mogły być dynamicznie powiązane z różnymi UTXO.

Logicznie podzielona operacja weryfikacji podpisu OP_CHECKSIG (i podobne kody operacji) ma trzy funkcje:

1. Składanie różnych części transakcji wydatków

2. Hashuj to.

3. Sprawdź, czy skrót został podpisany podanym kluczem.

Specyficzna treść podpisu daje duże możliwości dostosowania. To, które pola transakcji są zestawiane do podpisu, określa flaga SIGHASH. Zgodnie z definicją kodu operacji sygnatury BIP 342, flagi SIGHASH są podzielone na SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY itd., spośród których SIGHASH_ANYONECANPAY steruje wejściem, a resztą steruje wyjściem.

SIGHASH_ALL jest domyślną flagą SIGHASH, która podpisuje wszystkie wyjścia; SIGHASH_NONE nie podpisuje żadnego wyjścia; SIGHASH_ANYONECANPAY można ustawić razem z pierwszymi trzema flagami SIGHASH. Jeśli ustawiona jest SIGHASH_ANYONECANPAY, tylko określone wejście zostanie podpisane, w przeciwnym razie wszystkie wejścia będą musiały zostać podpisane.

Oczywiście żadna z tych flag SIGHASH nie może wyeliminować wpływu danych wejściowych. Nawet SIGHASH_ANYONECANPAY wymaga zaangażowania na wejściu.

Dlatego BIP 118 proponuje SIGHASH_ANYPREVOUT. Podpisy APO nie wymagają wydania wejściowego UTXO (zwanego PREVOUT), ale jedynie wyjściowego, zapewniając większą elastyczność kontroli Bitcoin. Dzięki wstępnemu skonstruowaniu transakcji i skonstruowaniu odpowiedniego podpisu jednorazowego użytku oraz klucza publicznego, aktywa wysłane na adres klucza publicznego muszą zostać wydane w ramach wstępnie skonstruowanej transakcji w celu wdrożenia kontraktu. Elastyczność APO można również wykorzystać do naprawy transakcji. Jeśli transakcja utknie w łańcuchu ze względu na niskie opłaty, można łatwo utworzyć kolejną transakcję z wyższymi opłatami, bez konieczności składania nowych podpisów. Ponadto w przypadku portfeli z wieloma podpisami podpisy nie opierają się na wydanych danych wejściowych, co ułatwia obsługę.

Ponieważ pętla pomiędzy scriptPubKeys i wejściowym TXID została wyeliminowana. APO może wdrożyć introspekcję poprzez dodanie danych wyjściowych do świadka (Świadek). Oczywiście nadal wymaga to dodatkowego wykorzystania przestrzeni danych świadka.

W przypadku protokołów poza łańcuchem, takich jak Lightning Network i Vault, APO zmniejsza stan pośredni, który należy zapisać, znacznie zmniejszając wymagania dotyczące pamięci masowej i złożoność. Najbardziej bezpośrednim przypadkiem użycia APO jest Eltoo, które upraszcza fabrykę kanałów, buduje lekką i tanią wieżę obserwacyjną oraz umożliwia jednostronne wyjście bez pozostawiania stanu błędu, poprawiając wydajność sieci Lightning Network pod każdym względem. APO można również wykorzystać do symulacji funkcji CTV, ale wymaga to przechowywania podpisów i wstępnie podpisanych transakcji przez poszczególne osoby, co jest droższe i mniej wydajne niż CTV.

Główną krytyką APO jest to, że wymaga nowej wersji klucza, czego nie można osiągnąć poprzez czystą kompatybilność wsteczną. Ponadto nowe typy skrótów podpisów mogą powodować potencjalne ryzyko podwójnych wydatków. Po szeroko zakrojonej dyskusji w społeczeństwie APO zażądało dodania wspólnego podpisu do oryginalnego podpisu. Rozwiązano problemy związane z bezpieczeństwem i dlatego APO otrzymało numer BIP-118.

OP_VAULT BIP-345

BIP-345 proponuje dodanie dwóch nowych kodów operacji, OP_VAULT i OP_VAULT_RECOVER, do połączenia z CTV w celu wdrożenia dedykowanej umowy, która pozwala użytkownikom wymusić okres opóźnienia w wydawaniu określonych tokenów. W okresie opóźnienia można przywrócić poprzednie dane poprzez ścieżkę odzyskiwania, wybierz opcję „Cofnij”.

Użytkownicy mogą zbudować skarbiec, tworząc konkretny adres Taproot. MAST musi zawierać co najmniej dwa skrypty, skrypt OP_VAULT ułatwiający oczekiwany proces wypłaty i kolejny skrypt OP_VAULT_RECOVER zapewniający, że w dowolnym momencie przed zakończeniem wypłaty monety będą mogły być dostępne. zostać przywrócony.

OP_VAULT Jak wdrożyć wypłaty przerywane blokowane czasowo? Mówiąc najprościej, kod operacji OP_VAULT realizuje jedną rzecz: zastępuje zużyty skrypt OP_VAULT określonym skryptem, faktycznie kończąc aktualizację pojedynczego węzła liścia MAST, pozostawiając pozostałe węzły liści niezmienione. Konstrukcja jest podobna do TLUV, z tą różnicą, że OP_VAULT nie obsługuje wewnętrznych aktualizacji kluczy.

Wprowadzenie szablonów podczas procesu aktualizacji skryptu może osiągnąć efekt ograniczenia płatności. Wśród nich parametr blokady czasowej jest określony przez OP_VAULT, a szablon dostarczony przez kod operacji CTV ogranicza zestaw wyników wydawanych przez tę ścieżkę skryptu.

BIP-345 powstał dla skarbców Dzięki OP_VAULT i OP_VAULT_RECOVER użytkownicy mogą mieć bezpieczną metodę depozytu z wysoce bezpiecznym kluczem (portfel papierowy, rozproszony multipodpis) jako ścieżką odzyskiwania i resztą codziennej konfiguracji płatności. Niektóre wydatki są opóźniony. Urządzenie użytkownika na bieżąco monitoruje wydatki skarbca, a w przypadku nieoczekiwanego przelewu użytkownik może je przywrócić.

BIP-345 wymaga uwzględnienia kosztów podczas wdrażania skarbców, zwłaszcza przywracania transakcji. Możliwe rozwiązania obejmują CPFP, tymczasowe kotwice i nowe flagi skrótu podpisu, takie jak SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Rozwiązanie TLUV zbudowane jest wokół Taproot i ma na celu rozwiązanie problemu efektywnego wyjścia ze współdzielonego UTXO. Przewodnią ideą jest to, że kiedy wydawane są dane wyjściowe Taproot, możemy częściowo zaktualizować klucz wewnętrzny i MAST, korzystając z wewnętrznej struktury i transformacji kryptograficznej adresu Taproot zgodnie z etapami aktualizacji opisanymi w skrypcie TLUV, realizując w ten sposób funkcję kontraktu. .

Ideą rozwiązania TLUV jest to, że za pomocą nowego kodu operacji TAPLEAF_UPDATE_VERIFY można utworzyć nowy adres Taproot w oparciu o bieżące zużycie energii, wykonując jedną lub więcej z następujących operacji:

• Zaktualizuj wewnętrzny klucz publiczny

• przycinanie ścieżki Merkle'a

• Usuń aktualnie wykonywany węzeł liścia

• Dodaj nowy węzeł liścia na końcu ścieżki Merkle

W szczególności TLUV otrzymuje trzy dane wejściowe:

• Jeden określa sposób aktualizacji wewnętrznego klucza publicznego

• Jeden określa nowy węzeł liścia dla ścieżki Merkle

• Jeden określa, czy usunąć bieżący węzeł liścia i/lub liczbę węzłów liści ścieżki Merkle'a do usunięcia

Kod operacji TLUV oblicza zaktualizowany skryptPubKey i sprawdza, czy dane wyjściowe odpowiadające bieżącemu wejściu zużywają ten skryptPubKey.

Inspirującym scenariuszem TLUV jest CoinPool. Obecnie możliwe jest utworzenie stowarzyszonej puli przy użyciu wyłącznie transakcji z podpisem wstępnym, ale jeśli chcesz osiągnąć wyjście bez pozwolenia, musisz utworzyć wykładniczo większą liczbę podpisów, podczas gdy TLUV umożliwia wyjście bez pozwolenia bez żadnego wstępnego podpisu. Na przykład grupa partnerów wykorzystała Taproot do zbudowania wspólnego UTXO, które łączyło wzajemne fundusze. Mogą używać kluczy Taproot do wewnętrznego przenoszenia środków, a także mogą podpisywać się w celu inicjowania płatności na zewnątrz. Osoby fizyczne mogą w dowolnym momencie wycofać się ze wspólnej puli środków i usunąć własną ścieżkę płatności. Inni mogą nadal realizować płatności pierwotną ścieżką. Jednocześnie wypłata danej osoby nie spowoduje ujawnienia dodatkowych informacji o innych osobach znajdujących się w jej obrębie. W porównaniu z transakcjami niepołączonymi ta metoda jest bardziej wydajna i prywatna.

Kod operacji TLUV implementuje częściowe ograniczenia wydatków poprzez aktualizację oryginalnego MAST, ale nie implementuje introspekcji kwoty wyjściowej. Trzeba więc także dołączyć nowy kod operacji IN_OUT_AMOUNT, który wypycha na stos dwie części danych: ilość tego wejściowego UTXO i ilość odpowiadającego wyjścia, a następnie oczekuje, że osoba korzystająca z TLUV użyje operatorów matematycznych w celu sprawdzenia, czy środki są odpowiednio zarezerwowane w zaktualizowanym scriptPubKey.

Introspekcja kwoty wyjściowej dodaje kolejną warstwę złożoności, ponieważ ilość Bitcoina wymaga do 51 bitów do przedstawienia w satoshi, ale skrypt pozwala tylko na 32-bitowe operacje matematyczne i wymaga aktualizacji w skrypcie poprzez ponowne zdefiniowanie operatora zachowania opcode lub użyj SIGHASH_GROUP zamiast IN_OUT_AMOUNT.

Oczekuje się, że TLUV zapewni rozwiązanie dla zdecentralizowanych pul funduszy warstwy 2. Oczywiście niezawodność poprawek klucza publicznego Taproot nie została jeszcze potwierdzona.

MAT

MATT (Merkleize All The Things) stara się osiągnąć trzy cele: państwo oparte na Merkle, skrypty oparte na Merkle i wykonanie oparte na Merkle, a następnie realizować uniwersalne inteligentne kontrakty.

Stan Merkle: Skonstruuj próbę Merkle, w której każdy węzeł liścia jest wartością skrótu stanu, a korzeń Merkle reprezentuje stan całego kontraktu.

Skrypt Merkle: to znaczy MAST złożony z Tapscript. Każdy węzeł liścia jest możliwą ścieżką przejścia stanu.

Wykonanie Merkle: Wykonanie Merkle osiąga się poprzez szyfrowane zobowiązania i mechanizmy wykrywania oszustw. W przypadku dowolnej funkcji obliczeniowej uczestnicy mogą obliczyć poza łańcuchem, a następnie zwolnić zobowiązanie, f(x)=y, a inni uczestnicy stwierdzą, że wynik obliczenia jest błędny f. (x)= z, możesz kwestionować i rozstrzygać za pomocą metody dychotomii, która jest tą samą zasadą, co Optymistyczne Rollup.

Wyzwania związane z oszustwami wspieranymi przez Merkle

Aby zaimplementować MATT, skrypty programistyczne Bitcoin muszą mieć następującą funkcjonalność:

1. Wymuszanie na wyjściu określonych skryptów (i ich ilości)

2. Dołącz fragment danych do wyniku

3. Odczyt danych z bieżącego wejścia (lub innego wejścia)

Drugi punkt jest bardzo ważny, dane dynamiczne oznaczają, że stan można obliczyć na podstawie danych wejściowych dostarczonych przez konsumenta, ponieważ zapewnia to symulację maszyny stanu i może określić kolejny stan za pomocą dodatkowych danych. Rozwiązanie MATT zostało zaimplementowane poprzez zaproponowanie kodu operacji OP_CHECKCONTRACTVERIFY (OP_CCV), który jest połączeniem pierwotnie zaproponowanych kodów OP_CHECKOUTPUTCONTRACTVERIFY i OP_CHECKINPUTCONTRACTVERIFY i wykorzystuje dodatkowy parametr flags do określenia obiektu operacji.

Kontrola kwoty wyjściowej: Najbardziej bezpośrednią metodą jest bezpośrednia introspekcja. Jednakże kwota wyjściowa jest liczbą 64-bitową i wymaga operacji 64-bitowych, co jest bardzo złożone w przypadku implementacji skryptów Bitcoin. CCV przyjmuje metodę opóźnionego sprawdzania, podobną do OP_VAULT. Wartości wejściowe wszystkich wejść z CCV na tym samym wyjściu są sumowane jako dolna granica wielkości wyjściowej. Opóźnienie wynika z faktu, że sprawdzenie odbywa się podczas transakcji, a nie podczas oceny wprowadzonego skryptu.

Biorąc pod uwagę powszechność zabezpieczenia przed oszustwami, pewien wariant kontraktu MATT powinien umożliwiać wszystkie typy inteligentnych kontraktów lub kompilacje drugiej warstwy, chociaż konieczna jest dokładna ocena dodatkowych wymagań (takich jak blokowanie kapitału i opóźnienia w okresie kwestionowania). aby ocenić, która Aplikacja jest akceptowalną transakcją. Na przykład mechanizm zaangażowania kryptograficznego i wyzwania przed oszustwem służy do symulacji funkcji OP_ZK_VERIFY w celu wdrożenia bezzaufanego Rollupu na Bitcoinie.

Właściwie to już się dzieje. Johan Torås Halseth wdrożył elftrace przy użyciu kodu operacyjnego OP_CHECKCONTRACTVERIFY w propozycji miękkiego widelca MATT, który może zweryfikować wszystkie programy obsługujące kompilację RISC-V w łańcuchu Bitcoin, umożliwiając jednej stronie umowy otrzymanie środków poprzez kontrakt, osiągając most A do natywnej weryfikacji Bitcoina.

CSFS (OP_CHECKSIGFROMSTACK)

Od wprowadzenia kodu operacji APO dowiedzieliśmy się, że OP_CHECKSIG (i powiązane z nim operacje) jest odpowiedzialny za składanie transakcji, mieszanie i weryfikację podpisów. Jednakże wiadomość, którą sprawdza, jest uzyskiwana poprzez serializację transakcji przy użyciu tego kodu operacji i nie można określić żadnych innych komunikatów. Mówiąc najprościej, OP_CHECKSIG (i powiązane z nim operacje) działają poprzez mechanizm podpisu w celu sprawdzenia, czy UTXO użyte jako dane wejściowe transakcji jest autoryzowane do wydania przez posiadacza podpisu, chroniąc w ten sposób bezpieczeństwo Bitcoin.

CSFS, jak sama nazwa wskazuje, sprawdza podpisy na stosie. Kod operacji CSFS otrzymuje trzy parametry ze stosu: podpis, komunikat i klucz publiczny i weryfikuje ważność podpisu. Oznacza to, że można przekazywać dowolne komunikaty na stos za pośrednictwem danych monitorujących i zlecić ich weryfikację przez CSFS. co sprawia, że ​​bit Możliwe są pewne innowacje w walucie.

Elastyczna charakterystyka CSFS umożliwia wdrożenie wielu mechanizmów, takich jak podpisy płatnicze, delegowanie uprawnień, kontrakty Oracle, obligacje zabezpieczające przed podwójnymi wydatkami itp., a co ważniejsze, może realizować introspekcję transakcji. Zasada używania CSFS do introspekcji transakcji jest bardzo prosta. Jeśli treść transakcji używana przez OP_CHECKSIG jest wypychana na stos przez świadka, ten sam klucz publiczny i podpis są używane do weryfikacji treści zarówno za pomocą CSFS, jak i OP_CHECKSIG. Jeśli oba przejdą pomyślnie , wówczas treść dowolnej wiadomości przekazywanej do CSFS jest taka sama, jak serializowana transakcja wydatków (i inne dane) domyślnie używana dla OP_CHECKSIG. Sprawdziliśmy dane transakcji na stosie i możemy zastosować inne kody operacji do limitu transakcji.

CSFS zwykle pojawia się razem z OP_CAT, ponieważ OP_CAT może łączyć różne pola transakcji w celu zakończenia serializacji i może dokładniej wybierać pola transakcji, które wymagają introspekcji. Bez OP_CAT skrypt nie może przeliczyć skrótu na podstawie danych, które można sprawdzić indywidualnie, więc jedyne, co może zrobić, to sprawdzić, czy skrót jest równy określonej wartości, co oznacza, że ​​monetę można wydać tylko w ramach jednej konkretnej transakcji.

CSFS może implementować kody operacyjne CLTV, CSV, CTV, APO i inne. Jest to ogólny kod operacji introspekcji, więc może również pomóc w planie rozbudowy Bitcoin Layer 2. Wadą jest to, że trzeba dodać do stosu pełną kopię podpisanej transakcji, co może znacznie zwiększyć rozmiar transakcji, które chcesz introspekcji za pomocą CSFS. Dla porównania, jednofunkcyjne kody operacji introspekcji, takie jak CLTV i CSV, wymagają minimalnego narzutu, ale dodanie każdego nowego specjalnego kodu operacji introspekcji wymaga zmiany konsensusu.

TXHASH (OP_TXHASH)

OP_TXHASH to bardzo prosty kod operacji introspekcji, który pozwala operatorowi wybrać skrót pola do umieszczenia na stosie. W szczególności OP_TXHASH zdejmie flagę txhash ze stosu, obliczy (oznaczony) txhash na podstawie tej flagi i wypchnie wynikowy skrót na stos.

Ze względu na podobieństwa pomiędzy TXHASH i CTV, w społeczności toczyło się wiele dyskusji na temat tych dwóch programów.

TXHASH można postrzegać jako ogólne uaktualnienie CTV, zapewniające bardziej zaawansowany szablon transakcji, który pozwala użytkownikom jawnie wydać część transakcji, co rozwiązuje wiele problemów związanych z opłatami transakcyjnymi. W porównaniu z innymi kodami operacji, TXHASH nie musi dostarczać kopii wymaganych danych do świadka, co dodatkowo zmniejsza potrzebę przechowywania; w przeciwieństwie do CTV, TXHASH nie jest kompatybilny z NOP i może być zaimplementowany jedynie w kombinacji TXHASH i CSFS można uznać za alternatywę dla CTV i APO.

Z punktu widzenia sposobu budowy kontraktu TXHASH ułatwia wdrożenie „kontraktu addytywnego”, umieszczając na stosie wszystkie części danych transakcji, które chcesz naprawić, mieszając je wszystkie razem i weryfikując, czy powstały skrót odpowiada ustalonej wartości; CTV Łatwiej jest wdrożyć „kontrakty subtraktywne”, wypychając na stos wszystkie części danych transakcji, które chcesz zachować. Następnie użyj kroczącego OP_SHA256, aby rozpocząć od stałego stanu pośredniego, który zatwierdza przedrostek danych skrótu transakcji. Wolna część jest mieszana do tego stanu pośredniego.

Oczekuje się, że pole TxFieldSelector zdefiniowane w specyfikacji TXHASH zostanie rozszerzone na inne kody operacji, takie jak OP_TX.

BIP związany z TXHASH ma obecnie status wersji roboczej na Githubie i nie został jeszcze ponumerowany.

OP_CAT

OP_CAT to dość tajemniczy kod operacyjny. Został porzucony przez Satoshi Nakamoto ze względów bezpieczeństwa. Wywołał ostatnio wiele dyskusji wśród twórców rdzenia Bitcoin, a nawet wywołał kulturę memów w Internecie BIP-347 i był przez wiele osób nazywany propozycją BIP, która najprawdopodobniej zostanie przyjęta w najbliższej przyszłości.

W rzeczywistości OP_CAT zachowuje się bardzo prosto, łącząc dwa elementy na stosie w jeden. Jak zaimplementować funkcję kontraktu?

W rzeczywistości funkcja łączenia dwóch elementów odpowiada potężnej kryptograficznej strukturze danych, Merkle Trie. Proces budowy Merkle Trie wymaga jedynie dwóch operacji: splicingu i hashowania, a w skryptach Bitcoin dostępne są funkcje skrótu. Dlatego za pomocą OP_CAT możemy teoretycznie zweryfikować Merkle Proof w skrypcie Bitcoin, który jest najczęściej stosowaną lekką metodą weryfikacji w blockchainie.

Jak wspomniano wcześniej, CSFS przy pomocy OP_CAT jest w stanie wdrożyć wspólny schemat kontraktów. W rzeczywistości OP_CAT sam może wdrożyć introspekcję transakcji bez CSFS, wykorzystując strukturę podpisów Schnorra.

W podpisie Schnorra wiadomość wymagająca podpisu składa się z następujących pól:

Pola te zawierają główne elementy transakcji Umieszczając je w scriptPubKey lub świadku, używając OP_CAT i OP_SHA256, możemy zbudować podpis Schnorra i sprawdzić go za pomocą OP_CHECKSIG. Jeśli weryfikacja przebiegnie pomyślnie, zweryfikowane dane transakcji pozostają na stosie, umożliwiając introspekcję transakcji, z możliwością wyodrębnienia i „zbadania” różnych części transakcji, takich jak jej dane wejściowe, wyjściowe, adres docelowy czy ilość Bitcoinów zaangażowany.

Szczegółowe zasady kryptografii można znaleźć w artykule CAT i Schnorr Tricks opublikowanym przez Andrew Poelstrę.

Podsumowując, elastyczność OP_CAT pozwala mu emulować prawie każdy kod operacji kontraktu, a duża liczba opkodów kontraktu opiera się na funkcjonalności OP_CAT, co stawia go znacząco na czele listy scalonych. Teoretycznie, opierając się wyłącznie na OP_CAT i istniejących kodach operacji Bitcoin, możemy mieć nadzieję na zbudowanie BTC ZK Rollup o minimalnym zaufaniu, a Starknet, Chakra i inni partnerzy ekologiczni aktywnie to promują.

Wniosek

Kiedy badamy wiele strategii skalowania Bitcoina i zwiększania jego programowalności, staje się jasne, że droga naprzód obejmuje kombinację natywnych ulepszeń, obliczeń poza łańcuchem i wyrafinowanych możliwości tworzenia skryptów.

Bez elastycznej warstwy bazowej nie da się zbudować bardziej elastycznej drugiej warstwy.

Ekspansja obliczeń poza łańcuchem jest przyszłością, ale musi nastąpić przełom w programowaniu Bitcoina, aby lepiej wspierać ekspansję i stać się prawdziwą walutą świata.

Jednak obliczenia Bitcoina i Ethereum są w rzeczywistości zasadniczo różne. Bitcoin obsługuje jedynie „weryfikację” jako formę obliczeń i nie może wykonywać ogólnych obliczeń, podczas gdy Ethereum ma charakter obliczeniowy, a weryfikacja jest produktem ubocznym obliczeń. Różnicę tę widać z jednego punktu: Ethereum pobiera opłatę w postaci gazu za nieudane transakcje, podczas gdy Bitcoin nie.

Kontrakt implementuje formę inteligentnej umowy opartej na weryfikacji, a nie na obliczeniach. Jeśli chodzi o kontrakty, wszyscy z wyjątkiem garstki fundamentalistów Satoshi wydają się uważać kontrakty za dobrą opcję ulepszenia Bitcoina. Jednakże społeczność nadal debatuje nad tym, jaką metodę zastosować w celu realizacji kontraktu.

APO, OP_VAULT i TLUV są bardziej nastawione na aplikacje bezpośrednie, a wybranie ich umożliwia wdrożenie określonych aplikacji w tańszy i bardziej wydajny sposób. Entuzjaści Lightning Network będą preferować APO, ponieważ może wdrożyć LN-Symmetry; jeśli chcesz wdrożyć skarbiec, najlepiej użyć OP_VAULT do zbudowania CoinPool, użyj TLUV dla większej prywatności i wydajności. OP_CAT i TXHASH są bardziej wszechstronne i rzadziej zawierają luki w zabezpieczeniach. Łącząc z innymi kodami operacji, można osiągnąć więcej przypadków użycia, choć oczywiście może być konieczne opłacenie złożoności skryptu. CTV i CSFS wprowadziły zmiany w procesie przetwarzania blockchain. CTV wdrożyło opóźnione wyjście, a CSFS wdrożyło opóźnione podpisy. MATT jest stosunkowo wyjątkowy, wykorzystuje idee optymistycznego wykonania i zabezpieczenia przed oszustwami oraz wykorzystuje strukturę Merkle Trie do wdrażania uniwersalnych inteligentnych kontraktów, ale nadal potrzebuje nowych opkodów, aby zapewnić funkcje introspekcji.

Widzieliśmy, że społeczność Bitcoin już intensywnie dyskutuje nad możliwością umożliwienia Bitcoinowi pozyskiwania kontraktów poprzez miękkie forki. Starknet oficjalnie ogłosił swoje wejście do ekosystemu Bitcoin i planuje wdrożyć rozliczenia w sieci Bitcoin w ciągu sześciu miesięcy od fuzji OP_CAT. Chakra będzie w dalszym ciągu zwracać uwagę na najnowsze trendy w ekosystemie Bitcoin, promować fuzję miękkich forków OP_CAT i wykorzystywać programowalność, jaką zapewnia introspekcja i kontrakty, do budowy bezpieczniejszej i wydajniejszej warstwy rozliczeniowej Bitcoin.

Dziękujemy Jeffreyowi, Benowi, Mutourendowi i Lynndellowi za recenzję i sugestie dotyczące tego artykułu