By Bitcoin Magazyn - 6 miesiące temu - Czas czytania: 6 minuty
Zanim stały się modne: umowy dotyczące produkcji Nn Liquid
Odkąd Bitcoin społeczność rozpoczęła dyskusje na temat optymalizacji porozumień, rośnie zainteresowanie zdobywaniem wiedzy na temat kompromisów i porozumień już wdrożonych na platformie Sieć płynna.
W świetle tego odnowionego zainteresowania i aby zachęcić do dalszej dyskusji, przejrzyjmy niektóre aktualne oferty umów Liquid, porównując je z wiodącymi propozycjami na Bitcoin i zbadanie ich odpowiednich przypadków użycia.
Historia przymierzy w płynie
Początki Covenants on Liquid sięgają wdrożenia pierwszego sidechaina Elements, Alfa. Ten łańcuch boczny wprowadził kody operacji OP_CHECKSIGFROMSTACK (CSFS) i OP_DETERMINISTICRANDOM wraz z wieloma innymi do Elements. Alpha włączyła także stałe wersje kodów operacji wyłączonych wcześniej Bitcoin, Takie jak OP_CAT— kod operacyjny, do którego wiele osób decyduje się powrócić w ramach rosnącego dialogu w mediach społecznościowych. Te nowe rozkazy dodatkowo poprawiły wyrazistość wersji Bitcoin Skrypt dostępny w Elements i dowód koncepcji Skarbiec Mösera-Eyala-Sirera został opracowany przy użyciu CSFS w celu zilustrowania nowych możliwości.
Jednym z wniosków płynących z wdrożenia CSFS było to, że sprawia to, że umowy stają się bardziej złożone, wymagając umieszczania danych transakcyjnych na stosie podczas realizacji wydatków w ramach umowy. Z doświadczenia programistów zaobserwowano również, że w przypadku ustaleń CSFS dane transakcji tworzące skrót podpisu muszą zostać zrekonstruowane na stosie, co potencjalnie zmusza programistów do wypychania danych nieistotnych dla danych wejściowych/wyjściowych transakcji, którymi są zainteresowani.
Aby uprościć konstrukcję przymierza, wprowadzono ponad 30 nowych rozkazów introspekcji kody operacyjne zostały wprowadzone w firmie Liquid’s Taproot uaktualnienie bardziej modułowego podejścia. Na przykład kody introspekcji w CSFS umożliwiają kontrolę bardziej szczegółowych części transakcji podczas wydatków poprzez umieszczenie ich na stosie. Eliminuje to odpowiedzialność za gromadzenie częściowych danych transakcji za pośrednictwem świadka, a tym samym skrótu podpisu na stosie.
Wiodące propozycje porozumień
Obecnie Bitcoin społeczność omawia listę potencjalnych propozycji przymierza, w tym SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, kod operacji MATT OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT i OP_CHECKTEMPLATEVERIFY (CTV). Prostota, język skryptowy nowej generacji, który mógłby wdrożyć funkcjonalność podobną do wielu umów na niższym poziomie, jest również potencjalną drogą do Bitcoin (powrócimy do tego później).
Wiele mówiło się o kodzie operacyjnym VAULT, który został stworzony, aby zaspokoić zapotrzebowanie na łatwiejsze sposoby zabezpieczania bitcoin dla użytkowników. Ten kod operacji umożliwiłby zablokowanie monet pod adresem, który może wydawać tylko na dwa adresy: gorący portfel po blokadzie czasowej lub natychmiast do zimnego portfela. Zaproponowano kilka innych wariantów schematów, ale zależą one od najpierw przyjęcia CTV.
CTV to kod operacji, który odczytuje skrót ze stosu i porównuje go ze skrótem określonego podzbioru danych transakcji wydatków. Jego elastyczność zapewnia możliwość zastosowania różnorodnego zestawu aplikacji, w tym między innymi: kontroli zatorów, skarbców i podstawowych pul płatniczych.
Oprócz rozkazów pojawiły się propozycje westchnień umożliwiających zawieranie przymierzy. Dwie najpopularniejsze propozycje do tego celu to APO i SIGHASH_GROUP. APO jest ewolucją kodu operacyjnego SIGHASH_NOINPUT, który jest powszechnie uznawany za warunek wstępny wdrożenia ełtożerny. Jednym z wielu ulepszeń możliwych dzięki eltoo jest wyeliminowanie mechanizmu kar, który zmusza drugą stronę do utraty środków w przypadku nadawania nieaktualnego stanu kanału. Pozwala to na stworzenie bardziej przyjaznej dla użytkownika i wydajnej sieci Lightning.
Osiąganie podobnej funkcjonalności dzięki płynnym kodom operacyjnym
Chociaż Liquid nie ma kodów CTV i VAULT, ma CSFS i CAT dla przymierzy. Używając tych węższych kodów operacji z wyżej wymienionymi kodami introspekcji, programiści otworzyli nowe możliwości finansowe z funkcjonalnością podobną do CTV i VAULT w celu rozszerzenia łańcucha bocznego.
Na przykład Burak, doświadczony programista Liquid i twórca protokołu warstwy 2 Ark, zademonstrował emulacja VAULT używając opkodów Liquid Covenant w jednej dyskusji z Jamesem O'Beirne'em X.
Podobnie sposób na osiągnięcie funkcjonalności APO stał się możliwy dzięki CSFS. Ten próbny wykorzystywał różne kody operacyjne, które umożliwiałyby korzystanie z protokołów warstwy 2, takich jak eltoo w Liquid, ale boryka się z dodatkową złożonością i większym rozmiarem transakcji w porównaniu z proponowanym wykorzystaniem porozumienia typu APO. Co więcej, konstrukcja nie dotyczy transakcji Taproot, co wprowadziłoby własną formę dodatkowej złożoności.
Płynne kody operacyjne w akcji
Wiele aplikacji skorzystało już z kodów przymierza w Liquid. Steven Roose, zwolennik przymierza, który niedawno zdefiniowane opracowano specyfikację dla wcześniej wymyślonego OP_TXHASH aplikacja dla obligacji lojalnościowych na Liquid. Umowa ta dotyczy funduszy, które zostałyby spalone, gdyby świadek przedstawił dowód podwójnego wydatku.
Fuji pieniądzeKolejnym godnym uwagi przykładem jest Fuji USD (FUSD), algorytmiczna moneta typu stablecoin opracowana przez Vulpem Ventures. Aby utrzymać swoją pozycję, opiera się wyłącznie na informacjach z Oracle i może być emitowany w sposób zdecentralizowany. Używa A połączenie weryfikacji podpisów i kodów introspekcji, aby to osiągnąć, a najważniejszą częścią jest to, że wszystko można kontrolować w łańcuchu.
Inne zastosowania umów na Liquid obejmują kontrakty opcyjne i poufne pożyczki oparte na aktywach. Zespół badawczy Blockstream opublikował plik oficjalny dokument w ubiegłym roku (patrz zał blogu) o tym pierwszym, wyjaśniając, w jaki sposób taki kontrakt na opcje mógłby zostać skonstruowany przy użyciu nowego zestawu introspektywnych rozkazów. Te nowe rozkazy pozwalają użytkownikom w sposób bezpieczny tworzyć tokeny reprezentujące obie strony objętego kontraktu opcji kupna i sprzedawać przeciwną pozycję, którą chcą zająć. Kontrakty zawarte w ten sposób umożliwiają również częściowe wypełnienie, co oznacza, że użytkownik, który utworzył kontrakt, może sprzedać pozycje stanowiące wielokrotność określonej przez użytkownika minimalnej kwoty zabezpieczenia, zwanej „wielkością kontraktu”.
Dlaczego nie najpierw na Liquid?
Jak Bitcoin w ekosystemie nadal toczy się zdrowa debata na temat kodów przymierza, Liquid oferuje własny zestaw narzędzi, obsługujących podobne cele, ale z różnymi implementacjami. W miarę rozwoju dialogu intrygujące będzie obserwowanie wzajemnego oddziaływania pomiędzy nimi Bitcoinnatywne propozycje Liquid oraz już konkretne i żywe funkcje związane z przymierzem i emulacją Liquid Bitcoin propozycje przymierzy wdrażane przy użyciu Elements Script.
Kolejna nowa technologia na horyzoncie to Prostota, weryfikowalny język programowania dla blockchain. Język Simplicity jest definiowany przez operacje o bardzo wąskiej semantyce, które po złożeniu razem mogą tworzyć wyraziste programy. Język jest również weryfikowalny, co oznacza, że można ustalić metody matematycznego udowadniania twierdzeń postawionych w programach Simplicity.
Wyrazisty charakter Simplicity pozwala na płynne przenoszenie kodów operacji ze skryptu, zapewniając większą niezawodność i mniej nieoczekiwanych zachowań. Bitcoin badacz Sanket Kanjalkar wykonał już tę pracę dla CTV. Za pomocą gwara, bardziej czytelny Bitcoin-centrycznego języka programowania, który kompiluje się do poziomu Simplicity, był w stanie odtworzyć semantykę w praktycznym dokumencie potwierdzającym słuszność koncepcji, który każdy może dziś wypróbować.
Bitcoin programiści wkrótce będą mieli możliwość używania s-lang w rzeczywistym środowisku dzięki integracji Simplicity przez Liquid, planowanej na drugi kwartał 2 r. s-lang wprowadzi do Liquid budowę bardziej złożonych aplikacji, takich jak skarbce i delegowanie. Projekt PR jest dostępny do wglądu pod poniższym adresem link.
z długa historia Liquid jako twórca pierwszych pomysłów, do których później zostały one przeniesione BitcoinSugestią dla tych, którzy chcą zaprezentować wykonalność swoich propozycji, jest wypróbowanie ich na żywo w Liquid, aby najpierw zweryfikować pomysły — ponieważ wykazano, że wiele rozkazów związanych z przymierzem można emulować przy użyciu istniejących rozkazów Liquid i introspekcji.
Zatem, gdy następnym razem ktoś zasugeruje nowe przymierze, warto zadać sobie pytanie: dlaczego nie wypróbować go najpierw na Liquid?
To jest post gościnny Randy'ego Naara. Wyrażone opinie są całkowicie ich własnymi i niekoniecznie odzwierciedlają opinie BTC Inc lub Bitcoin Czasopismo.
Pierwotnym źródłem: Bitcoin Magazyn