Czy dzieje się OP_CAT? Propozycja porozumień właśnie otrzymała numer BIP nr 347. Zanim jednak zagłębimy się w szczegóły, przyjrzyjmy się, czym są przymierza i dlaczego Bitcoinerzy mogą ich chcieć.
Czy Bitcoin jest idealnym stanem cyfrowej e-gotówki, czy też chcemy więcej od naszych monet w łańcuchu?
Drapanie po powierzchni: ograniczenia skryptów Bitcoin
Aby zrozumieć propozycje porozumień, takie jak OP_CAT, ważne jest, aby zdać sobie sprawę z podstawowych ograniczeń Bitcoin Script w jego obecnej postaci. Pod maską Bitcoin umożliwia tworzenie podstawowych inteligentnych kontraktów za pomocą kodów definiujących zasady blokowania i odblokowywania środków. Jednak Bitcoin Script, jako język programowania, jest dość ograniczony do podstawowej logiki, która wchodzi w grę tylko podczas przenoszenia monet w ramach nowej transakcji.
W dzisiejszym Bitcoinie nie ma możliwości wstępnej konfiguracji ani narzucania ścieżek transakcji monetami ani szybkości przemieszczania się monet w momencie ich zablokowania (poza hackerskimi przepływami pracy wykorzystującymi PSBT, częściowo podpisanymi transakcjami bitcoinowymi, które nie mogą poprawnie zawierać opłaty transakcyjne, udowodnić usunięcie, jeśli nie są używane, lub uniemożliwić późniejszą emisję).
Ta prostota, choć stanowi rdzeń modelu bezpieczeństwa Bitcoina, wprowadza znaczne ograniczenia w zdolności języka skryptowego do obsługi nawet podstawowych inteligentnych kontraktów.
Liniowy model wykonania
Jednym z ograniczeń skryptu Bitcoin jest jego model operacyjny, w którym kody operacji są wykonywane sekwencyjnie, bez pętli.
Na tym przykładzie transakcji P2PKH można zobaczyć, jak skrypt wykonuje się liniowo: duplikując klucz publiczny, mieszając go z adresem, weryfikując hash względem skryptu blokującego i na koniec sprawdzając podpis względem klucza publicznego.
Brak pętli oznacza, że skrypty nie są kompletne w technologii Turing i na pewno się zakończą, co zapobiega problemom takim jak nieskończone pętle, które mogłyby potencjalnie zatrzymać lub znacznie spowolnić sieć. Chociaż ten wybór projektu pozwala na statyczne ograniczenie użycia zasobów, ogranicza to również zdolność skryptu do zarządzania złożonymi przepływami pracy.
Brak podstawowej arytmetyki
Bitcoin Script ma prawie 100 nietrywialnych opkodów i, co zaskakujące, nie ma możliwości mnożenia, dzielenia ani łączenia obiektów na stosie. Jak wie wielu użytkowników zainteresowanych OP_CAT, Satoshi wyłączył kilka opkodów w Bitcoinie w 2010 roku, w tym między innymi OP_OR, OP_MUL (mnożenie), OP_DIV (dzielenie) i OP_CAT (łączenie). Wyłączone kody operacyjne zostały usunięte, ponieważ ich oryginalne implementacje zawierały możliwe do wykorzystania luki, które mogły zagrozić bezpieczeństwu sieci. Jednak brak tych kodów operacji utrudnia wykonywanie podstawowych obliczeń matematycznych, co może być przydatne w prostych scenariuszach, takich jak obliczanie opłat transakcyjnych w umowie.
Brak widoczności danych transakcji
Na pozór myślę, że większość ludzi zakłada, że inteligentne kontrakty Bitcoin są w stanie zobaczyć kwoty wartości i wszelkie inne części danych transakcyjnych, ponieważ informacje te są już publicznie widoczne w łańcuchu bloków. Jednak wbrew temu założeniu kontrakty na Bitcoinie nie są w stanie ustalać warunków wydatków w oparciu o dane transakcyjne, ponieważ Bitcoin Script ma w ogóle bardzo ograniczone możliwości wglądu w dane transakcyjne.
Gdyby skrypt miał możliwość interpretowania większej liczby szczegółów danych transakcji, moglibyśmy budować znacznie solidniejsze kontrakty, które mogłyby wykonywać wszystkie zabawne rzeczy, takie jak egzekwowanie określonych warunków wydatków, tworzenie wieloetapowych transakcji i umożliwianie bardziej zaawansowanych funkcji bezpieczeństwa, takich jak skarbce.
Co z tym zrobić?
Wiemy, że Bitcoin ma te ograniczenia i przez lata omawiano wiele różnych propozycji wprowadzenia (lub w niektórych przypadkach ponownego wprowadzenia) tej funkcjonalności. Szersze eksperymenty z Bitcoin Script, takie jak Simplicity i inne, mają na celu zapewnienie alternatywy dla ograniczeń opartych na stosie. Opkody takie jak OP_MULTISHA256, OP_LESS i OP_LE32TOLE64 mają na celu ulepszenie możliwości arytmetycznych Bitcoina. Propozycje takie jak OP_CTV i OP_CAT, które dotyczą kodów introspekcji, są pogrupowane w ramach terminu kowenanty.
Jaka jest więc dokładnie różnica między inteligentnymi kontraktami a nowymi umowami terminowymi?
Inteligentne kontrakty a przymierza
Inteligentne kontrakty to samowykonujące się transakcje, które przekazują środki bez pośredników. W dzisiejszym Bitcoinie inteligentne kontrakty ograniczają się do blokowania i odblokowywania bitcoinów za pomocą Bitcoin Script. Przymierza mają na celu ulepszenie funkcjonalności inteligentnych kontraktów Bitcoin, umożliwiając użytkownikom kontrolowanie sposobu wydawania ich środków w przyszłych transakcjach.
Umożliwiając Scriptowi interpretację danych transakcyjnych, skutecznie tworzymy sposób na wykorzystanie tych danych w logice kontraktu.
To tylko niektóre z bardziej interesujących kodów introspekcji dotyczących funkcjonalności przymierzy:
OP_TXHASH: Zapewnia skrót danych wejściowych (lub wyjściowych) transakcji i daje skryptowi możliwość weryfikacji i egzekwowania warunków w oparciu o dane transakcji.
OP_CSFS + OP_CAT: Obydwa razem umożliwiają skryptom sprawdzanie podpisów pod kątem dowolnych danych, a nie tylko samej transakcji. Oznacza to, że skrypt może weryfikować warunki w oparciu o dane transakcyjne lub informacje zewnętrzne, rozszerzając możliwości walidacji w skryptach Bitcoin.
Te dwa kody operacji są celowo szerokie, umożliwiając złożone procesy walidacji i możliwości introspekcji. Inne mają węższy zakres i zostały zaprojektowane jako bardziej ograniczona forma przymierzy.
OP_CHECKTEMPLATEVERIFY (CTV): Umożliwia osadzenie w wynikach transakcji szablonu przyszłej transakcji wydatków, umożliwiając zawieranie porozumień w bardziej ograniczony sposób.
OP_VAULT: Włącza specyficzną formę umowy używaną do „przechowywania”, która pozwala użytkownikom określić miejsce docelowe transakcji, ale w rzeczywistości nie przenosi monet z wyjątkiem opóźnienia.
Następnie istnieje sam OP_CAT, który nie jest bezpośrednio kodem operacji introspekcji…
OP_CAT: Umożliwia skryptowi łączenie dwóch elementów na stosie, co jest przydatne do łączenia różnych informacji w skrypcie.
OP_CAT nie wydaje się mieć żadnych zdolności do introspekcji, więc o co tu chodzi?
OP_CAT: Odkrywanie wszystkich możliwości
Introspekcja transakcji
W 2021 roku Andrew Poelstra napisał na blogu o trikach introspekcji OP_CAT. Podał konkretne przykłady, ale zakładał, że czytelnicy mieli wcześniejszą wiedzę na temat podobnych technik. W tym miejscu postaram się uprościć to wyjaśnienie, aby zapewnić lepsze zrozumienie.
W Bitcoin Script istnieją tylko trzy podstawowe kody operacji, które pozwalają na introspekcję danych transakcji: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY i CHECKSIG. Ponadto istnieją warianty, takie jak CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG i CHECKMULTISIGVERIFY, które są zasadniczo niewielkimi odmianami CHECKSIG. Pierwsze dwa pozwalają tylko sprawdzić, czy czek został zweryfikowany, zapewniając dość wąską funkcjonalność. CHECKSIG jest podobny, ale różnica polega na tym, że pozwala pobrać podpis i klucz publiczny na stosie. Ciekawy.
Tradycyjnie myślimy o konkatenacji jako o funkcji, która łączy ze sobą dwa elementy, ale możemy jej również użyć do rozdzielenia lub podzielenia elementu, w tym przypadku — podpisu na parę (r, s).
Jak wyprowadzić funkcjonalność OP_SPLIT z OP_CAT?
„Jeśli masz jakiś duży obiekt, możesz podzielić go na dwie części, prosząc użytkownika, aby poświęcił czas na dostarczenie dwóch części. Łączysz je razem i zasadniczo sprawdzasz równość. Zawsze możesz odwrócić każdą operację w ten sposób. Za pomocą samego CAT możesz rozbijać podpisy. — Andrew Poelstra, TABConf 2021
Co tu się dzieje?
Wymagając od użytkownika podania podpisu, klucza publicznego i transakcji, możesz podzielić podpis na części składowe, a następnie sprawdzić każdą część niezależnie z danymi transakcji. Technikę tę można postrzegać jako formę dzielenia lub łączenia, ponieważ sprawdza, czy podpis i klucz publiczny rzeczywiście są składnikami ważnej transakcji.
Jak to wszystko skłania nas do introspekcji?
„W Taproot, gdzie mamy podpisy Schnorra przy użyciu OP_CAT i kodu operacyjnego weryfikacji podpisu Schnorra, okazuje się, że możliwe jest uzyskanie formy nierekursywnego porozumienia, w którym dosłownie otrzymujesz skrót transakcji. Nawet nie taki zabawny, zniekształcony skrót transakcji, ale dosłowny skrót SHA2 wszystkich danych transakcji na stosie. — Andrew Poelstra, TABConf 2021
Poelstra dalej demonstruje, w jaki sposób można uzyskać skrót SHA2 dla danych wejściowych lub wyjściowych transakcji pozostawionych na stosie. Pominiemy tutaj matematykę dotyczącą księżyca, ale implikacja jest taka, że za pomocą OP_CAT możemy ograniczyć części transakcji jako wymaganie skryptu odblokowującego. Możemy ograniczyć adres wysyłkowy lub wartość wysyłaną w ramach tej transakcji, gdzie skrót transakcji służy jako klucz do jej odblokowania.
Skarbce
Używanie tych samych technik umożliwia nam introspekcję transakcji i pozwala szybko uzyskać podstawową wersję skarbców. Kierując się logiką przedstawioną na blogu Poelstry, programista o nazwisku Rijndael udowodnił, że możemy tego dokonać za pomocą samego OP_CAT w swojej implementacji Purrfect Vaults.
„Ponowne zbudowanie identyfikatora TXID na stosie w celu introspekcji poprzednich transakcji było w rzeczywistości łatwiejsze, niż się spodziewałem”. — Rijndael
W przypadku skarbców użytkownicy określają następny adres, na który muszą trafić ich środki, zapewniając mechanizmy odzyskiwania środków w przypadku naruszenia bezpieczeństwa klucza i zmniejszając zachętę do kradzieży klucza prywatnego.
Drzewa Merkle dla scenariusza
W dzisiejszym Bitcoinie drzewa Merkle to struktura danych używana do weryfikacji danych, synchronizacji i mniej więcej „łączenia” transakcji i bloków łańcucha bloków. Kod operacji OP_CAT, który umożliwia połączenie dwóch zmiennych stosu, gdy jest używany razem z skrótami kluczy publicznych SHA256, ułatwia prosty proces weryfikacji skryptów w drzewie Merkle. Podejście to, pierwotnie zaproponowane przez Pietera Wuille’a w 2015 roku, zostało z sukcesem wdrożone w sieci Liquid.
Wyobraź sobie strukturę drzewa wypełnioną różnymi warunkami wydatków, takimi jak obrazy wstępne skrótu, blokady czasowe i klucze publiczne, zwane podpisami drzew.
Podpisy drzew
OP_CAT umożliwia tworzenie sygnatur drzew, które:
„…Dostarcz skrypt z wieloma podpisami, którego rozmiar może być logarytmiczny w liczbie kluczy publicznych i który może kodować warunki wydatków większe niż n-z-m. Na przykład transakcja o rozmiarze mniejszym niż 1 KB może obsługiwać podpisy drzewiaste z tysiącem kluczy publicznych. Umożliwia to również uogólnienie logicznych warunków wydatków.” — autor BIP Ethan Heilman, na liście mailingowej bitcoin-dev
Umożliwiłoby to weryfikację dowolnej zaszyfrowanej zawartości w drzewie, utrzymanie integralności i wiarygodności danych bez dodawania niepotrzebnej objętości lub wzdęcia do łańcucha bloków.
Co jest w tym wszystkim interesującego?
Przymierza rekurencyjne
Jeśli masz możliwość zbadania transakcji i zastosowania ograniczeń do niektórych jej części, możesz ustawić warunki, które będą obowiązywać przez wiele transakcji, skutecznie tworząc łańcuch ciągłych ograniczeń. Koncepcja ta nazywana jest umową rekurencyjną. OP_CAT to wyjątkowa propozycja, ponieważ daje nam tak dużo mocy w zaledwie 10 nowych liniach kodu. Ma możliwość rozwiązania wszystkich trzech początkowych ograniczeń, które omówiliśmy na początku postu: widoczność danych transakcji, lepsza funkcjonalność matematyczna i liniowy model wykonania.
Chociaż OP_CAT może na pierwszy rzut oka wydawać się prosty, odblokowuje znaczny potencjał, gdy zostanie twórczo wykorzystany. Służy jako element konstrukcyjny jeszcze większej funkcjonalności wykraczającej poza zakres tej dyskusji, takiej jak podpisy Post-Quantum Lamport.
Czy to jest bezpieczne?
Zanim OP_CAT został początkowo usunięty, w połączeniu z OP_DUP (duplikat) i powtarzalnym użyciu w celu zduplikowania początkowo 1-bajtowej wartości na stosie, użycie pamięci mogło eksplodować. Mogło to zostać wykorzystane jako atak typu „odmowa usługi” (DoS) w wyniku zwiększonego zużycia pamięci. Nowa propozycja w trywialny sposób zapobiega temu atakowi, nakładając limit 520 bajtów na elementy stosu.
Czy istnieje ryzyko, że umowa będzie obowiązywać wiecznie?
Jeśli przez to rozumiemy, czy OP_CAT zmienia model wykonania Skryptu w taki sposób, że nie ogranicza już statycznie wykorzystania zasobów (jako liniowa funkcja rozmiaru Skryptu)? NIE.
Czy umowy stworzyłyby rynek dla innych monet oprócz Bitcoina?
Jeśli masz umowę rekurencyjną, tak, z technicznego punktu widzenia możesz tworzyć złożone aplikacje warstwy 2, w tym NFT, zdecentralizowane giełdy i koty kwantowe. Jednak zrobienie tego nie jest trywialne. Trudno wyobrazić sobie, aby jakikolwiek poważny rynek tak postępował.
Czy możesz trwale „zabrudzić” monety za pomocą CAT?
W przypadku kolorowych monet i NFT użytkownik emitując te aktywa skutecznie „spala” satoshi, zaznaczając go w sposób oznaczający własność aktywa „warstwy 2”. Proces ten nazywany jest „zanieczyszczaniem” monet. Ale tylko właściciel monety może oznaczyć swoją monetę, a portfele Bitcoin nie będą już jej rozpoznawać (chyba że ich autorzy wyraźnie dodadzą kod, aby to umożliwić). Powstałe monety nie zostaną zaakceptowane przez portfele bitcoinowe. Prawdopodobnie zostałyby zaakceptowane przez portfele cryptocat lub coś w tym stylu, ale dla większości użytkowników bitcoinów nie ma to znaczenia.
Czy spowodowałoby to problem MEV na Bitcoinie?
Kluczowym punktem odróżniającym Bitcoin od Ethereum jest widoczność transakcji. W przeciwieństwie do Ethereum, nie wszystkie aspekty kontraktu są koniecznie przejrzyste, co oznacza, że górnicy Bitcoin nie mają takiej samej zdolności sprawdzania stanu kontraktu wewnętrznego i wyprzedzania go.
Główną troską OP_CAT przez ekonomicznie myślących Bitcoinerów jest potencjał wartości ekstrakcyjnej dla górników (MEV). Jak szerzej opisałem w moim poprzednim poście na ten temat. Wielu użytkowników obawia się, że jeśli technicznie umożliwimy kontrakty w warstwie 2, MEV stanie się nieuniknione. Ale czy to prawda? W szczególności, czy techniczna wykonalność monet warstwy 2 na Bitcoinie oznacza ich nieuniknione utworzenie i przyjęcie?
Można sobie wyobrazić budowanie prostych kontraktów swapowych lub stosunkowo nieefektywnych transakcji NFT, ale zbudowanie czegoś tak złożonego jak DEX z automatycznymi animatorami rynku wydaje się niezwykle mało prawdopodobne i nigdy nie widzieliśmy tego na Liquid, pomimo „technicznej możliwości” takiej sytuacji.
Czy zatem OP_CAT jest naprawdę doskonały?
Niewiele, daleko od tego. Niektórzy ludzie chcieliby zobaczyć rekurencyjne przymierza, podczas gdy inni po prostu nie chcą w ogóle zmian w Bitcoinie.
Frakcja Bitcoinerów, „ossyfikacjonistów”, opowiada się za zachowaniem Bitcoina w jego obecnym stanie i ze sceptycyzmem podchodzi do wszelkich aktualizacji protokołu. Są szczególnie zaniepokojeni tym, że znaczące zmiany, takie jak wprowadzenie paktów, mogą podważyć decentralizację sieci. Ich argumentacja opiera się na przekonaniu, że najlepiej trzymać się oryginalnej wizji Bitcoina. Ironia polega na tym, że OP_CAT był początkowo częścią Bitcoina, co podsyca kontrargument. Niektórzy uważają, że przywrócenie OP_CAT mogłoby faktycznie dostosować Bitcoin do pierwotnej wizji Satoshiego.
Jeśli chcesz zobaczyć niektóre funkcje bezpieczeństwa, które mogą zapewnić umowy rekurencyjne, OP_CAT byłby fajny, ale zdecydowanie nie tak ładny, jak w pełni rozwinięty język skryptowy w stylu Lispa. Problem polega na tym, że byłaby to ogromna zmiana w Bitcoinie i prawdopodobnie nie nastąpi to w najbliższym czasie.
A może jesteś po drugiej stronie i wolisz prostotę nierekurencyjną, taką jak OP_CTV lub OP_VAULT. Przymierza nierekurencyjne są prostsze i łatwiejsze do uzasadnienia, bez ryzyka utworzenia niekontrolowanego łańcucha ograniczeń.
Co by było, gdyby jakaś wersja rekurencyjnych przymierzy była nieunikniona?
Na przestrzeni lat programiści zauważyli, że do emulacji funkcjonalności OP_CAT można zastosować niemal każde rozszerzenie logiki sprawdzania transakcji.
W świecie Skryptu istnieją dwie krainy, zależne od rozmiaru elementów stosu. W przypadku elementów stosu większych niż 4 bajty można porównać pod kątem równości, zinterpretować podpis jako klucz lub go zahaszować. W przypadku elementów stosu mniejszych lub równych 4 bajtom można je traktować jako obiekty do wykonywania operacji arytmetycznych lub rozgałęzień. Dzięki procesorowi RISC-V działającemu na maszynie BitVM możesz zrobić dosłownie wszystko. Wszystko, co pozwala na emulację OP_CAT, dzielenie elementów stosu lub łączenie ich razem, łączy te dwie dziedziny, dzięki czemu możesz „zrobić wszystko” za pomocą skryptu.
Badacze tacy jak Andrew Poelstra spodziewają się, że moglibyśmy zawierać umowy rekurencyjne z praktycznie każdym nowym kodem operacyjnym. Jeśli to prawda, byłoby to uzasadnieniem poszukiwania sposobu, aby zrobić to dobrze.
Czy OP_CAT jest prawdopodobną drogą do zawarcia przymierzy?
Jeśli umowy są nie tylko interesujące, ale i nieuniknione, w jaki sposób możemy zapewnić ich wdrożenie w taki sposób, aby więcej użytkowników Bitcoinów wysyłało bez zaufania, jak pierwotnie przewidywał Satoshi? Choć zwolennicy kostnienia pozostają podzieleni, OP_CAT nadal zyskuje na popularności jako silny rywal w debacie na temat przymierzy.
OP_CAT nie jest najbardziej eleganckim dłutem, ale ma najlepszy stosunek mocy do złożoności, co umożliwi programistom stworzenie kilku niesamowitych nowych funkcji.
To jest post gościnny autorstwa Kiary Bickers. Wyrażone opinie są wyłącznie ich własnymi opiniami i niekoniecznie odzwierciedlają opinie BTC Inc lub Bitcoin Magazine.
Źródło: Magazyn Bitcoin
Post OP_CAT: Doskonałe rozwiązanie dla przymierzy? pojawił się jako pierwszy w Crypto Breaking News.