Święty Graal sieci warstwy 2 Bitcoina: Introspekcja i pakty

cd

W porównaniu do blockchainów z kompletnym Turingiem, takich jak Ethereum, język skryptowy Bitcoina jest uważany za znacznie ograniczony, zdolny tylko do podstawowych operacji, a nawet pozbawiony funkcji mnożenia i dzielenia. Co ważniejsze, własne dane blockchaina są prawie niedostępne dla skryptów, co prowadzi do poważnych ograniczeń elastyczności i programowalności. W związku z tym ludzie od dawna szukali sposobów na umożliwienie introspekcji skryptów Bitcoin.

Introspekcja odnosi się do zdolności skryptów Bitcoin do sprawdzania i ograniczania danych transakcji. Pozwala to skryptom kontrolować wykorzystanie środków w oparciu o określone szczegóły transakcji, umożliwiając bardziej złożone funkcje. Obecnie większość kodów operacyjnych Bitcoin albo przesuwa dane dostarczone przez użytkownika na stos, albo manipuluje danymi już znajdującymi się na stosie. Opkody introspekcji mogą jednak wypychać bieżące dane transakcji (takie jak znaczniki czasu, kwoty i identyfikatory transakcji) na stos, umożliwiając bardziej szczegółową kontrolę nad wydatkami UTXO.

Obecnie istnieją tylko trzy główne kody operacyjne w skryptach Bitcoin, które obsługują introspekcję: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY i CHECKSIG. CHECKSIG ma kilka wariantów, w tym CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG i CHECKMULTISIGVERIFY.

Porozumienia to ograniczenia dotyczące sposobu przekazywania tokenów. Użytkownicy mogą określić, w jaki sposób UTXO są dystrybuowane za pośrednictwem paktów, z których wiele jest zaimplementowanych przy użyciu kodów operacyjnych introspekcji. Obecnie Bitcoin Optech kategoryzuje introspekcję pod wpisami przymierza.

Bitcoin ma obecnie dwa przymierza: CSV (CheckSequenceVerify) i CLTV (CheckLockTimeVerify), z których oba są przymierzami opartymi na czasie i stanowią podstawę wielu rozwiązań skalujących, takich jak Lightning Network. Wskazuje to, że rozwiązania skalowania Bitcoina w dużej mierze opierają się na introspekcji i paktach.

Jak dodać warunki do transferów tokenów

W świecie kryptowalut najpopularniejszą metodą jest zobowiązania, często implementowana przy użyciu hashy. Aby udowodnić, że warunki transferu są spełnione, do weryfikacji wykorzystywane są mechanizmy podpisów. W związku z tym umowy obejmują liczne dostosowania hashy i podpisów.

Poniżej znajdują się szeroko dyskutowane propozycje kodów operacyjnych przymierza:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), zawarte w BIP-119, jest wysoce dyskutowaną aktualizacją Bitcoina. CTV pozwala skryptom wyjściowym określać szablony transakcji wydatkowych, w tym pola takie jak nVersion, nLockTime, skrót scriptSig, liczba wejściowa, skrót sekwencji, liczba wyjściowa, skrót wyjściowy i indeks wejściowy. Te ograniczenia szablonów są implementowane poprzez zobowiązanie hash, a przyszłe skrypty wydatków będą sprawdzać, czy wartości hash określonych pól w transakcji wydatków są zgodne z wartościami w skrypcie wejściowym. Szablony te zasadniczo definiują czas, metodę i kwotę przyszłych transakcji UTXO.

Warto zauważyć, że wejściowy TXID jest wykluczony z zobowiązania hash. Wykluczenie to jest konieczne, ponieważ zarówno w transakcjach Legacy, jak i Segwit, TXID zależy od wartości scriptPubKey podczas korzystania z domyślnego typu podpisu SIGHASH_ALL. Uwzględnienie TXID stworzyłoby zależność kołową, uniemożliwiając skonstruowanie zobowiązania hash.

CTV osiąga introspekcję, bezpośrednio uzyskując określone informacje o transakcji za pomocą nowego kodu operacyjnego, haszując je i porównując z zobowiązaniem na stosie. Ta metoda zużywa mniej miejsca w łańcuchu, ale brakuje jej pewnej elastyczności.

Podstawą rozwiązań drugiej warstwy, takich jak Lightning Network, są wstępnie podpisane transakcje. Wstępne podpisywanie zwykle oznacza generowanie i podpisywanie transakcji z wyprzedzeniem, ale nie transmitowanie ich, dopóki nie zostaną spełnione określone warunki. Zasadniczo CTV implementuje bardziej rygorystyczną funkcję wstępnego podpisywania, publikując wstępnie podpisane zobowiązanie bezpośrednio w łańcuchu, zezwalając na transakcje tylko zgodnie ze wstępnie zdefiniowanym szablonem.

CTV został początkowo zaproponowany w celu złagodzenia zatorów Bitcoin i może być również określany jako kontrola zatorów. W okresach dużego przeciążenia, CTV może zatwierdzać wiele przyszłych transakcji za pośrednictwem pojedynczej transakcji, unikając konieczności nadawania wielu transakcji podczas przeciążenia i kończąc rzeczywiste transakcje po ustąpieniu przeciążenia. Może to znacznie pomóc podczas wymiany. Ponadto szablony mogą być używane do implementacji skarbców, zapobiegając atakom hakerów, ponieważ miejsce docelowe środków jest z góry określone, co uniemożliwia hakerom wysyłanie UTXO za pomocą skryptu CTV na ich adresy.

CTV może znacznie ulepszyć sieci drugiej warstwy. Na przykład, w sieci Lightning Network, implementacja Timeout Trees i Channel Factories przy użyciu CTV pozwala pojedynczemu UTXO rozszerzyć się do drzewa CTV, otwierając wiele kanałów stanowych z tylko jedną transakcją w łańcuchu i potwierdzeniem. Ponadto CTV obsługuje transakcje atomowe (ATLC) w protokole Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 proponuje nową flagę hash podpisu dla tapscript, zwaną SIGHASH_ANYPREVOUT, aby ułatwić pisanie bardziej elastycznej logiki wydawania. APO i CTV są podobne pod wieloma względami. Aby rozwiązać kwestię zależności kołowej między scriptPubKeys i TXID, rozwiązaniem APO jest wykluczenie odpowiednich informacji wejściowych i podpisanie tylko danych wyjściowych, umożliwiając transakcjom dynamiczne wiązanie się z różnymi UTXO.

Logicznie rzecz biorąc, operacja weryfikacji OP_CHECKSIG (i powiązane z nią kody operacyjne) ma trzy funkcje:

  1. Złóż części transakcji wydatków.
  2. Hash te części.
  3. Sprawdza, czy hash jest podpisany podanym kluczem.

Konkretna zawartość podpisu może być znacznie dostosowana, a to, które pola transakcji są podpisywane, zależy od flagi SIGHASH. Zgodnie z definicją kodów operacyjnych podpisu BIP 342, flagi SIGHASH obejmują między innymi SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE i SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY kontroluje wejście, podczas gdy pozostałe kontrolują wyjście.

SIGHASH_ALL jest domyślną flagą SIGHASH, podpisującą wszystkie wyjścia. SIGHASH_NONE nie podpisuje żadnych wyjść, a SIGHASH_SINGLE podpisuje tylko określone wyjście. SIGHASH_ANYONECANPAY może być ustawiony z pozostałymi trzema flagami, a jeśli jest ustawiony, podpisuje tylko określone wejście; w przeciwnym razie wszystkie wejścia muszą być podpisane.

Żadna z tych flag SIGHASH nie może wyeliminować wpływu danych wejściowych. Nawet SIGHASH_ANYONECANPAY wymaga zaangażowania jednego wejścia.

Dlatego BIP 118 wprowadza SIGHASH_ANYPREVOUT. Podpisy APO nie muszą zobowiązywać się do wydatkowania wejściowego UTXO (zwanego PREVOUT), podpisując jedynie wyjście, zapewniając większą elastyczność w kontroli Bitcoin. Poprzez wstępne skonstruowanie transakcji i utworzenie odpowiednich jednorazowych podpisów i kluczy publicznych, aktywa wysłane na ten adres klucza publicznego muszą zostać wydane za pośrednictwem wstępnie skonstruowanej transakcji, osiągając przymierze.

Elastyczność APO można również wykorzystać do naprawy transakcji. Jeśli transakcja utknie w łańcuchu z powodu niskich opłat, można łatwo utworzyć kolejną transakcję w celu zwiększenia opłaty bez konieczności składania nowych podpisów. Dodatkowo, w przypadku portfeli z wieloma podpisami, podpisy niezależne od wydanych danych wejściowych upraszczają operacje.

Eliminując kolistą zależność między scriptPubKeys i wejściowymi TXID, APO może osiągnąć introspekcję poprzez dodanie danych wyjściowych w świadku, choć nadal wymaga to dodatkowej przestrzeni danych świadka.

W przypadku protokołów poza łańcuchem, takich jak Lightning Network i skarbce, APO zmniejsza potrzebę przechowywania stanów pośrednich, znacznie obniżając wymagania dotyczące pamięci masowej i złożoność. Najbardziej bezpośrednim przypadkiem użycia APO jest Eltoo, upraszczając fabryki kanałów, budując lekkie i niedrogie wieże strażnicze oraz umożliwiając jednostronne wyjścia bez pozostawiania błędnych stanów, zwiększając wydajność Lightning Network. APO może symulować funkcjonalność CTV, choć wymaga osobistego przechowywania podpisów i wstępnie podpisanych transakcji, przez co jest droższe i mniej wydajne niż CTV.

Główną krytyką APO jest potrzeba nowej wersji klucza, co czyni ją niekompatybilną z istniejącymi systemami. Dodatkowo, nowy typ skrótu podpisu może wprowadzać potencjalne ryzyko podwójnych wydatków. Po szeroko zakrojonych dyskusjach społeczności, APO wymaga teraz zwykłego podpisu oprócz oryginalnego, łagodząc obawy związane z bezpieczeństwem i zdobywając numer BIP-118.

OP_VAULT BIP-345

BIP-345 proponuje dwa nowe kody operacyjne, OP_VAULT i OP_VAULT_RECOVER, do pracy z CTV i implementacji dedykowanego przymierza, które wymusza okres opóźnienia w wydawaniu określonych tokenów, podczas którego wydatki mogą zostać „odwołane” za pośrednictwem ścieżki odzyskiwania.

Użytkownicy mogą utworzyć skarbiec, konfigurując określony adres Taproot, w tym co najmniej dwa skrypty w MAST: skrypt OP_VAULT, aby ułatwić oczekiwany proces wypłaty oraz skrypt OP_VAULT_RECOVER, aby zapewnić odzyskanie monet przed zakończeniem wypłaty.

W jaki sposób OP_VAULT realizuje wypłaty z blokadą czasową?

Mówiąc prościej, kod operacyjny OP_VAULT zastępuje zużyty skrypt OP_VAULT określonym skryptem, aktualizując pojedynczy węzeł liścia w MAST, podczas gdy reszta pozostaje niezmieniona. Jest to podobne do TLUV, ale bez obsługi aktualizacji kluczy wewnętrznych.

Wprowadzenie szablonu podczas aktualizacji skryptu może ograniczyć efekty płatności. Parametr blokady czasowej jest określony przez OP_VAULT, podczas gdy szablon wprowadzony przez kod operacyjny CTV ogranicza zestaw wyjść wydanych przez tę ścieżkę skryptu.

BIP-345 jest przeznaczony do skarbców, umożliwiając użytkownikom posiadanie wysoce bezpiecznej ścieżki odzyskiwania (portfel papierowy, rozproszony podpis wielopodpisowy) przy jednoczesnym skonfigurowaniu opóźnienia wydatków dla rutynowych płatności. Urządzenie użytkownika stale monitoruje wydatki skarbca, umożliwiając odzyskanie środków w przypadku wystąpienia nieautoryzowanego transferu.

Wdrożenie skarbców z BIP-345 wymaga rozważenia kwestii opłat, zwłaszcza w przypadku transakcji odzyskiwania. Możliwe rozwiązania obejmują CPFP (Child Pays for Parent), tymczasowe kotwice i nowe flagi hash podpisu, takie jak SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Schemat TLUV jest zbudowany wokół Taproot i ma na celu rozwiązanie problemu efektywnego wyjścia ze współdzielonych UTXO. Zasadą przewodnią jest to, że gdy wyjście Taproot zostanie wydane, możemy użyć wewnętrznej struktury adresu Taproot i transformacji kryptograficznych, aby częściowo zaktualizować klucz wewnętrzny i MAST zgodnie z krokami aktualizacji opisanymi w skrypcie TLUV, osiągając w ten sposób funkcjonalność kontraktu.

Idea schematu TLUV polega na utworzeniu nowego adresu Taproot w oparciu o bieżące dane wejściowe dotyczące wydatków za pomocą nowego kodu operacyjnego TAPLEAF_UPDATE_VERIFY, który może wykonywać jedną lub więcej z następujących operacji:

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

  1. Specyfikacja sposobu aktualizacji wewnętrznego klucza publicznego
  2. Nowy węzeł liścia dla ścieżki Merkle’a
  3. Określenie, czy usunąć bieżący węzeł liścia i/lub ile węzłów liścia ścieżki Merkle’a należy usunąć.

Kod operacyjny TLUV oblicza zaktualizowany scriptPubKey i sprawdza, czy dane wyjściowe odpowiadające bieżącemu wejściu są przypisane do tego scriptPubKey.

Inspiracją dla TLUV są pule monet. Obecnie wspólne pule można tworzyć przy użyciu wstępnie podpisanych transakcji, ale jeśli chcesz osiągnąć wyjścia bez pozwolenia, musisz utworzyć wykładniczo rosnącą liczbę podpisów. TLUV umożliwia permissionless exits bez żadnych wstępnie podpisanych transakcji. Na przykład grupa partnerów używa Taproot do zbudowania wspólnego UTXO, łącząc swoje fundusze. Mogą przenosić fundusze wewnętrznie za pomocą klucza Taproot lub wspólnie podpisywać, aby dokonywać płatności zewnętrznych. Poszczególne osoby mogą opuścić wspólną pulę w dowolnym momencie, usuwając swoją ścieżkę płatności, podczas gdy inni mogą nadal dokonywać płatności za pośrednictwem oryginalnej ścieżki bez ujawniania dodatkowych informacji o pozostałych członkach. Ta metoda jest bardziej wydajna i prywatna w porównaniu z transakcjami bez puli.

Kod operacyjny TLUV osiąga częściowe ograniczenia wydatków poprzez aktualizację oryginalnego MAST. Nie zapewnia on jednak introspekcji kwot wyjściowych. W związku z tym potrzebny jest nowy opcode IN_OUT_AMOUNT, który przesuwa dwa elementy danych na stos: kwotę UTXO tego wejścia i odpowiednią kwotę wyjściową. Osoba korzystająca z TLUV powinna następnie użyć operatorów matematycznych, aby zweryfikować, czy środki zostały prawidłowo zachowane w zaktualizowanym scriptPubKey.

Introspekcja kwot wyjściowych dodaje kolejną złożoność, ponieważ kwoty Bitcoin są reprezentowane w satoshis i wymagają do 51 bitów, ale skrypty pozwalają tylko na 32-bitowe operacje matematyczne. Wymaga to aktualizacji operatorów w skrypcie poprzez przedefiniowanie zachowania opcode lub użycie SIGHASH_GROUP w celu zastąpienia IN_OUT_AMOUNT.

Oczekuje się, że TLUV zapewni rozwiązania dla zdecentralizowanych pul monet warstwy 2, chociaż niezawodność w zakresie dostosowywania kluczy publicznych Taproot wymaga dalszego potwierdzenia.

MATT

MATT (Merkleize All The Things) ma na celu osiągnięcie trzech celów: Merkleizing state, Merkleizing scripts i Merkleizing execution, osiągając w ten sposób ogólne inteligentne kontrakty.

Aby osiągnąć MATT, skrypty programistyczne Bitcoin muszą mieć następujące funkcje:

  1. Wymuszanie określonego skryptu na wyjściu (i ich ilości)
  2. Dołączanie danych do wyjścia
  3. Odczyt danych z bieżącego wejścia (lub innych wejść)

Drugi punkt jest kluczowy, ponieważ dane dynamiczne umożliwiają obliczanie stanu za pomocą danych wejściowych dostarczonych przez nadawcę, symulując maszynę stanową i decydując o następnym stanie i dołączonych danych. MATT proponuje kod operacyjny OP_CHECKCONTRACTVERIFY (OP_CCV), będący połączeniem wcześniej proponowanych kodów operacyjnych OP_CHECKOUTPUTCONTRACTVERIFY i OP_CHECKINPUTCONTRACTVERIFY, z dodatkowym parametrem flag określającym cel operacji.

Kontrola ilości wyjściowych: Najbardziej bezpośrednim sposobem jest bezpośrednia introspekcja. Kwoty wyjściowe są jednak 64-bitowymi liczbami wymagającymi 64-bitowych operacji, co zwiększa złożoność implementacji skryptu Bitcoin. CCV przyjmuje opóźnioną kontrolę podobną do OP_VAULT, sumując kwoty wejściowe dla wszystkich wejść do tego samego wyjścia z CCV jako dolną granicą tej kwoty wyjściowej. Kontrola jest opóźniona do procesu transakcji zamiast podczas oceny skryptu wejściowego.

Biorąc pod uwagę ogólność dowodów oszustwa, niektóre warianty kontraktów MATT powinny osiągnąć wszystkie typy inteligentnych kontraktów lub konstrukcje warstwy 2, chociaż dodatkowe wymagania (takie jak blokada kapitału i opóźnienia okresu wyzwania) wymagają dokładnej oceny. Konieczne są dalsze badania w celu oceny, które aplikacje są akceptowalnymi transakcjami. Na przykład, przy użyciu zobowiązań kryptograficznych i mechanizmów kwestionowania oszustw w celu symulacji funkcji OP_ZK_VERIFY, osiągając zaufane Rollupy na Bitcoinie.

W praktyce już się to dzieje. Johan Torås Halseth zaimplementował elftrace przy użyciu kodu operacyjnego OP_CHECKCONTRACTVERIFY z propozycji soft forka MATT, umożliwiając weryfikację wszystkich programów obsługiwanych przez kompilację RISC-V w łańcuchu Bitcoin, umożliwiając natywne mosty weryfikacyjne Bitcoin dla protokołów kontraktowych.

CSFS (OP_CHECKSIGFROMSTACK)

Z wprowadzenia kodu operacyjnego APO wiemy, że OP_CHECKSIG (i powiązane operacje) jest odpowiedzialny za składanie transakcji, haszowanie i weryfikację podpisu. Jednak wiadomość, którą weryfikuje, pochodzi z serializacji transakcji przy użyciu tego opcode, nie pozwalając na określenie innych wiadomości. Mówiąc prościej, OP_CHECKSIG (i powiązane operacje) służy do weryfikacji, czy UTXO jako dane wejściowe transakcji jest autoryzowane do wydania przez posiadacza podpisu, chroniąc w ten sposób bezpieczeństwo Bitcoina.

CSFS, jak sama nazwa wskazuje, sprawdza podpisy ze stosu. Kod operacyjny CSFS pobiera trzy parametry ze stosu: podpis, wiadomość i klucz publiczny, a następnie weryfikuje ważność podpisu. Oznacza to, że każda wiadomość może zostać przekazana do stosu za pośrednictwem danych świadka i zweryfikowana przez CSFS, umożliwiając pewne innowacje w Bitcoinie.

Elastyczność CSFS pozwala na implementację różnych mechanizmów, takich jak podpisy płatności, delegacja uprawnień, kontrakty wyroczni i obligacje zabezpieczające przed podwójnymi wydatkami, a co ważniejsze, introspekcja transakcji. Zasada introspekcji transakcji przy użyciu CSFS jest bardzo prosta. Jeśli treść transakcji używana przez OP_CHECKSIG jest wypychana na stos przez świadka, a ten sam klucz publiczny i podpis są używane do weryfikacji zarówno w CSFS, jak i OP_CHECKSIG, jeśli oba przejdą pomyślnie, wówczas treść dowolnej wiadomości przekazanej do CSFS jest taka sama, jak serializowana transakcja wydatków (i inne dane) domyślnie używana przez OP_CHECKSIG. Następnie uzyskujemy zweryfikowane dane transakcji na stosie, które można wykorzystać do zastosowania ograniczeń do transakcji wydatków za pomocą innych kodów operacyjnych.

CSFS często pojawia się z OP_CAT, ponieważ OP_CAT może łączyć różne pola transakcji w celu zakończenia serializacji, umożliwiając bardziej precyzyjny wybór pól transakcji do introspekcji. Bez OP_CAT skrypt nie może rekompilować skrótów z indywidualnie sprawdzanych danych, więc może sprawdzić tylko, czy skrót pasuje do określonej wartości, co oznacza, że monety można wydać tylko w ramach jednej konkretnej transakcji.

CSFS może osiągać kody operacyjne, takie jak CLTV, CSV, CTV, APO i jest ogólnym kodem operacyjnym introspekcji, wspomagając w ten sposób również rozwiązania skalowania warstwy 2 dla Bitcoina. Jego wadą jest to, że wymaga dodania pełnej kopii podpisanej transakcji do stosu, co może znacznie zwiększyć rozmiar transakcji, które chcą używać CSFS do introspekcji. W przeciwieństwie do tego, jednofunkcyjne kody operacyjne introspekcji, takie jak CLTV i CSV, mają najmniejszy narzut, ale dodanie każdego nowego specjalnego kodu operacyjnego introspekcji wymaga zmian w konsensusie.

TXHASH (OP_TXHASH)

OP_TXHASH jest bardzo prostym kodem introspekcji, który pozwala operatorowi wybrać hash pola i wypchnąć go na stos. W szczególności OP_TXHASH pobiera flagę txhash ze stosu, oblicza (oflagowany) txhash na podstawie flagi i wypycha wynikowy hash na stos.

Ze względu na podobieństwo TXHASH i CTV, w społeczności toczyła się szeroka dyskusja na temat tych dwóch rozwiązań.

TXHASH można postrzegać jako ogólną aktualizację CTV, zapewniającą bardziej zaawansowany szablon transakcji, który pozwala użytkownikom określić części transakcji wydatków, rozwiązując wiele kwestii związanych z opłatami transakcyjnymi. W przeciwieństwie do innych kodów operacyjnych kontraktów, TXHASH nie wymaga dostarczania kopii niezbędnych danych w świadku, co dodatkowo zmniejsza zapotrzebowanie na pamięć masową. W przeciwieństwie do CTV, TXHASH nie jest kompatybilny z NOP i może być zaimplementowany tylko w tapscript. Połączenie TXHASH i CSFS można uznać za alternatywę dla CTV i APO.

Jeśli chodzi o konstruowanie kontraktów, TXHASH jest łatwiejszy do osiągnięcia „kontraktów addytywnych”, przesuwając wszystkie części danych transakcji, które chcesz naprawić, na stos, haszując je razem i sprawdzając, czy wynik jest zgodny z ustaloną wartością. CTV łatwiej jest osiągnąć „umowy odejmujące”, przesuwając wszystkie części danych transakcji, które mają pozostać wolne, na stos. Następnie, używając toczącego się OP_SHA256, zaczynając od stałego stanu pośredniego, ten stan pośredni zatwierdza prefiks danych skrótu transakcji. Wolne części są hashowane do tego stanu pośredniego.

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

BIP związany z TXHASH jest obecnie w wersji roboczej na Github i nie został mu jeszcze nadany numer.

OP_CAT

OP_CAT to nieco tajemniczy opcode, który został wycofany przez Satoshi Nakamoto ze względów bezpieczeństwa. Jednak ostatnio wywołał on szeroką dyskusję wśród programistów Bitcoin Core, stając się nawet memem w społeczności internetowej. Ostatecznie OP_CAT został zatwierdzony jako BIP-347, a wielu nazywa go najbardziej prawdopodobną propozycją BIP, która zostanie przyjęta w najbliższej przyszłości.

W rzeczywistości zachowanie OP_CAT jest bardzo proste: łączy dwa elementy na stosie w jeden. Ale w jaki sposób umożliwia to funkcjonalność kontraktu?

Funkcja łączenia dwóch elementów odpowiada potężnej kryptograficznej strukturze danych znanej jako Merkle Trie. Konstrukcja Merkle Trie wymaga jedynie operacji konkatenacji i haszowania, z których obie są dostępne w skryptach Bitcoin. Dlatego też dzięki OP_CAT możemy teoretycznie weryfikować Merkle Proofs w skryptach Bitcoin, co jest najczęstszą lekką metodą weryfikacji w łańcuchach bloków.

Jak wspomniano wcześniej, CSFS może wykorzystać OP_CAT do osiągnięcia ogólnego schematu kontraktowego. W rzeczywistości, nawet bez CSFS, struktura podpisów Schnorra pozwala OP_CAT na osiągnięcie introspekcji transakcji.

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

Pola te zawierają główne elementy transakcji. Umieszczając je w scriptPubKey lub witness i używając OP_CAT i OP_SHA256, możemy skonstruować podpis Schnorra i zweryfikować go za pomocą OP_CHECKSIG. Jeśli weryfikacja przebiegnie pomyślnie, stos zachowuje zweryfikowane dane transakcji, umożliwiając introspekcję transakcji. Pozwala nam to wyodrębnić i „sprawdzić” różne części transakcji, takie jak jej wejścia, wyjścia, adresy docelowe lub zaangażowane kwoty Bitcoin.

Bardziej szczegółowe zasady kryptograficzne można znaleźć w artykule Andrew Poelstry „CAT and Schnorr Tricks”.

Podsumowując, elastyczność OP_CAT sprawia, że może on naśladować prawie każdy kod operacyjny kontraktu, a wiele kodów operacyjnych kontraktu zależy od jego funkcjonalności. To znacznie poprawia jego pozycję na liście scalającej. Teoretycznie, mając tylko OP_CAT i istniejące kody operacyjne Bitcoin, moglibyśmy skonstruować zminimalizowany pod względem zaufania BTC ZK Rollup. Starknet, Chakra i inni partnerzy ekosystemu aktywnie pracują nad tym, aby tak się stało.

Wnioski

W miarę jak badamy różne strategie rozszerzania Bitcoina i zwiększania jego programowalności, staje się oczywiste, że droga naprzód obejmuje połączenie natywnych ulepszeń, obliczeń poza łańcuchem i złożonych funkcji skryptów.

Bez elastycznej warstwy bazowej niemożliwe jest zbudowanie bardziej elastycznej drugiej warstwy.

Skalowalność obliczeń poza łańcuchem jest przyszłością, ale programowalność Bitcoina musi się przebić, aby lepiej wspierać skalowanie i stać się prawdziwą światową walutą.

Jednak obliczenia Bitcoina zasadniczo różnią się od obliczeń Ethereum. Bitcoin obsługuje tylko „weryfikację” jako formę obliczeń, podczas gdy Ethereum jest zasadniczo obliczeniowe, z weryfikacją jako produktem ubocznym. Różnica ta jest widoczna w fakcie, że Ethereum pobiera opłaty gazowe za nieudane transakcje, podczas gdy Bitcoin tego nie robi.

Kontrakty są formą inteligentnych kontraktów opartych na weryfikacji, a nie na obliczeniach. Jeśli chodzi o kontrakty, poza kilkoma ścisłymi fundamentalistami Satoshi, większość ludzi uważa, że kontrakty są dobrym wyborem dla ulepszenia Bitcoina. Jednak społeczność nieustannie debatuje nad tym, jakiego schematu użyć do wdrożenia kontraktów.

APO, OP_VAULT i TLUV skłaniają się ku bezpośrednim aplikacjom. Wybierając je, można wdrożyć określone aplikacje taniej i wydajniej. Entuzjaści Lightning Network preferują APO, ponieważ osiąga symetrię LN; jeśli chcesz stworzyć skarbiec, najlepiej użyć OP_VAULT; aby zbudować CoinPool, TLUV jest bardziej prywatny i wydajny. OP_CAT i TXHASH są bardziej ogólne, mają mniej luk w zabezpieczeniach i mogą osiągnąć więcej przypadków użycia poprzez kombinacje z innymi kodami operacyjnymi, choć potencjalnie kosztem złożoności skryptu. CTV i CSFS dostosowały podejście do przetwarzania blockchain: CTV implementuje opóźnione wyjścia, a CSFS implementuje opóźnione podpisy. MATT jest stosunkowo wyjątkowy, wykorzystując optymistyczne wykonanie i dowody oszustwa, i opiera się na strukturze Merkle Trie w celu osiągnięcia ogólnych inteligentnych kontraktów, chociaż nadal wymaga nowych kodów operacyjnych, aby zapewnić możliwości introspekcji.

Widzimy, że społeczność Bitcoina już intensywnie dyskutuje o możliwości wprowadzenia kontraktów poprzez soft fork. Starknet oficjalnie ogłosił swoje wejście do ekosystemu Bitcoin, planując wdrożenie rozliczeń w sieci Bitcoin w ciągu sześciu miesięcy od fuzji OP_CAT. Chakra będzie nadal monitorować najnowsze zmiany w ekosystemie Bitcoin, promować połączenie OP_CAT i wykorzystywać programowalność wprowadzoną przez introspekcję i kontrakty w celu zbudowania bezpieczniejszej i wydajniejszej warstwy rozliczeniowej Bitcoin.

Related Articles
↑
Exit mobile version