By Bitcoin Tidskrift - 6 månader sedan - Läsningstid: 6 minuter
Innan de var coola: Covenants In Production Nn Liquid
Ända sedan Bitcoin gemenskapen inledde diskussioner kring optimering av förbund, det har funnits ett växande intresse för att lära sig mer om deras kompromisser och de förbund som redan har implementerats på Flytande nätverk.
I ljuset av detta förnyade intresse och för att uppmuntra till ytterligare diskussion, låt oss granska några av Liquids nuvarande erbjudanden och jämföra dem med de ledande förslagen om Bitcoin och undersöka deras respektive användningsfall.
Historik om förbund om vätska
Covenants on Liquid kan spåras tillbaka till implementeringen av den första Elements sidokedjan, alfa. Denna sidokedja introducerade opkoderna OP_CHECKSIGFROMSTACK (CSFS) och OP_DETERMINISTICRANDOM tillsammans med ett antal andra till Elements. Alpha aktiverade även fasta versioner av opcodes inaktiverade i början Bitcoin, Såsom OP_CAT—en opkod många väljer att återkomma till i den växande dialogen över sociala medier. Dessa nya opkoder förbättrade ytterligare uttrycksförmågan hos versionen av Bitcoin Skript tillgängligt i Elements och ett proof-of-concept Möser-Eyal-Sirer valv utvecklades med hjälp av CSFS för att illustrera de nya möjligheterna.
En av lärdomarna från att implementera CSFS var att det gör covenants mer komplexa genom att kräva att transaktionsdata skjuts på stapeln när man utför en covenant-utgift. Det observerades också från utvecklares erfarenhet att med CSFS-överenskommelser måste transaktionsdata som utgör signaturhashen rekonstrueras på stacken, vilket potentiellt tvingar utvecklare att pusha data som är irrelevanta för de transaktionsingångar/utgångar de är intresserade av.
För att förenkla förbundskonstruktionen anropades mer än 30 nya opkoder introspektion opcodes introducerades i Liquid's Taproot uppgradera för ett mer modulärt tillvägagångssätt. Introspektionsopkoder med CSFS, till exempel, möjliggör inspektion av mer granulära delar av transaktionen under en spendering genom att placera den på stacken. Detta minskar ansvaret för att sammanställa partiella transaktionsdata via vittnet och därför signaturhashen på stacken.
Ledande konventionsförslag
För närvarande är den Bitcoin communityn diskuterar en tvättlista med potentiella avtalsförslag, inklusive SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, MATT-opkoden OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT och OP_CHECKTEMPLATEVERIFY (CTV). Enkelhet, ett nästa generations skriptspråk som skulle kunna implementera funktionalitet som liknar många förbund på en lägre nivå, är också en potentiell väg för Bitcoin (vi kommer att återkomma till detta senare).
Det har pratats mycket om VAULT opcode, som skapades för att möta behovet av enklare sätt att säkra bitcoin för användare. Denna op-kod skulle tillåta att mynt låses i en adress som bara kan spenderas på två adresser: en het plånbok efter ett tidslås eller omedelbart till en kall plånbok. Flera andra variantsystem har föreslagits, men de är beroende av att först anta CTV.
CTV är en op-kod som läser en hash från stacken och jämför den med en hash av en specificerad delmängd av utgiftstransaktionens data. Dess flexibilitet lovar att möjliggöra en mångsidig uppsättning applikationer inklusive men inte begränsat till: överbelastningskontroll, valv och rudimentära betalningspooler.
Förutom opcodes har det funnits förslag på suckar för att möjliggöra förbund. De två mest populära förslagen för detta ändamål är APO och SIGHASH_GROUP. APO är en vidareutveckling av opkoden SIGHASH_NOINPUT, som är allmänt erkänd som en förutsättning för implementering eltoo. En av de många förbättringar som gjorts möjliga med eltoo är elimineringen av straffmekanismen som tvingar den andra parten att förlora pengar när den sänder en föråldrad kanalstat. Detta möjliggör ett mer användarvänligt och effektivt Lightning-nätverk.
Uppnå liknande funktionalitet med flytande opkoder
Även om Liquid inte har opkoderna CTV och VAULT, har den CSFS och KATT för förbund. Genom att använda dessa mer snävt definierade opkoder med de ovan nämnda introspektionsopkoderna har utvecklare öppnat upp nya ekonomiska möjligheter med funktionalitet som liknar CTV och VAULT för att utöka sidokedjan.
For example, Burak, a seasoned Liquid developer and creator of the layer-2 protocol Ark, has demonstrated an emulering av VAULT använda Liquid covenant-opkoder i en diskussion med James O'Beirne på X.
På samma sätt gjordes ett sätt att uppnå APO-funktionalitet möjligt med CSFS. Detta demo använde olika opkoder som skulle möjliggöra lager-2-protokoll som eltoo på Liquid idag men lider av ökad komplexitet och en större transaktionsstorlek jämfört med den föreslagna användningen av avtalet av APO-typ. Dessutom gäller konstruktionen inte för Taproot-transaktioner, vilket skulle introducera sin egen form av extra komplexitet.
Flytande opkoder i aktion
Many applications have already taken advantage of covenant opcodes on Liquid. Steven Roose, a covenant proponent who recently definierade en specifikation för den tidigare tänkta OP_TXHASH, har utvecklat en ansökan för trohetsobligationer på Liquid. Detta förbund läggs på medel som skulle brännas om bevis på en dubbel utgift presenteras i vittnet.
Fuji pengar's Fuji USD (FUSD), ett algoritmiskt stabilt mynt utvecklat av Vulpem Ventures är ett annat anmärkningsvärt exempel. Den förlitar sig enbart på orakelinformation för att behålla sin peg och kan utfärdas på ett decentraliserat sätt. Den använder en kombination av signaturverifieringar och op-koder för introspektion för att åstadkomma detta, och den viktigaste delen är att allt kan granskas i kedjan.
Andra tillämpningar av covenants på Liquid inkluderar optionskontrakt och konfidentiella tillgångsbaserade lån. The Blockstream Research team released a vitt papper förra året (se medföljande blogginlägg) om det förra, som förklarar hur ett sådant optionskontrakt skulle kunna konstrueras med den nya uppsättningen introspektiva opkoder. Dessa nya opkoder tillåter användare att trolöst skapa tokens som representerar båda sidor av ett täckt köpoptionskontrakt och sälja den motsatta positionen de vill ta. Kontrakt gjorda på detta sätt stöder också partiella fyllningar, vilket innebär att användaren som skapade kontraktet kan sälja positioner som representerar en multipel av ett användarspecificerat minimibelopp av säkerhetstillgången, kallad "kontraktsstorleken".
Varför inte på Liquid First?
Som Bitcoin ekosystemet fortsätter att ha en hälsosam debatt om covenant-opkoder, Liquid erbjuder sin egen uppsättning verktyg, som tillgodoser liknande mål men med distinkta implementeringar. När dialogen utvecklas kommer det att bli spännande att se samspelet mellan dem Bitcoins inbyggda förslag och Liquids redan konkreta och levande förbundsrelaterade funktioner och emulering av Bitcoin förbundsförslag implementerade med hjälp av Elements Script.
En annan ny teknik i horisonten är Enkelhet, ett verifierbart programmeringsspråk för blockchain. The Simplicity language is defined by operations with very narrow semantics that can make expressive programs when composed together. The language is also verifiable, which means methods can be established to mathematically prove assertions made on Simplicity programs.
Enkelhetens uttrycksfulla karaktär gör att förbundsopkoder från Script kan porteras sömlöst, vilket säkerställer större tillförlitlighet och färre oväntade beteenden. Bitcoin forskaren Sanket Kanjalkar har redan gjort detta arbete för CTV. Använder sig av slang, en mer läsbar Bitcoin-centriskt programmeringsspråk som kompilerar ner till Simplicity, kunde han replikera semantiken i ett fungerande proof-of-concept tillgängligt för alla att prova idag.
Bitcoin utvecklare kommer snart att ha möjlighet att använda s-lang i en verklig miljö tack vare Liquids integration av Simplicity, riktad till Q2 2024. s-lang kommer att ta konstruktionen av mer komplexa applikationer till Liquid, såsom valv och delegering. Utkastet till PR finns tillgängligt för granskning på följande länk.
Med en lång historia av Liquid som en tidig användare av idéer som senare har överförts till Bitcoin, ett förslag för de som vill visa upp hållbarheten i sina förslag är att prova live på Liquid för att validera idéer först – eftersom flera förbundsrelaterade opkoder har visat sig kunna emuleras med befintliga Liquid covenant och introspektionsopkoder.
Så nästa gång någon föreslår ett nytt förbund är det värt att fråga: varför inte prova det på Liquid först?
Detta är ett gästpost av Randy Naar. Åsikter som uttrycks är helt egna och återspeglar inte nödvändigtvis de från BTC Inc eller Bitcoin Tidskrift.
Ursprunglig källa: Bitcoin magazine