By Bitcoin Magasin - 6 måneder siden - Lesetid: 6 minutter
Før de var kule: Covenants In Production Nn Liquid
Helt siden Bitcoin fellesskapet begynte på diskusjoner rundt optimalisering av pakter, har det vært en økende interesse for å lære mer om deres avveininger og paktene som allerede er distribuert på Flytende nettverk.
I lys av denne fornyede interessen og for å oppmuntre til videre diskusjon, la oss se gjennom noen av Liquids nåværende avtaletilbud, og sammenligne dem med de ledende forslagene om Bitcoin og undersøke deres respektive brukstilfeller.
Historien om pakter om væske
Covenants on Liquid kan spores tilbake til utplasseringen av den første Elements-sidekjeden, Alpha. Denne sidekjeden introduserte op-kodene OP_CHECKSIGFROMSTACK (CSFS) og OP_DETERMINISTICRANDOM sammen med en rekke andre til Elements. Alpha aktivert også faste versjoner av opcodes deaktivert tidlig Bitcoin, Eksempel OP_CAT—en op-kode mange velger å se igjen i den økende dialogen på tvers av sosiale medier. Disse nye opkodene forbedret uttrykksevnen til versjonen av Bitcoin Skript tilgjengelig i Elements, og et proof-of-concept Möser-Eyal-Sirer hvelv ble utviklet ved å bruke CSFS for å illustrere de nye mulighetene.
En av lærdommene fra implementering av CSFS var at det gjør avtaler mer komplekse ved å kreve at transaksjonsdata skyves på stabelen når du utfører et avtaleutgifter. Det ble også observert fra erfaring fra utviklere at med CSFS-avtaler, må transaksjonsdataene som utgjør signaturhashen rekonstrueres på stabelen, noe som potensielt tvinger utviklere til å presse data som er irrelevante for transaksjonsinngangene/-utgangene de er interessert i.
For å forenkle paktkonstruksjonen ringte mer enn 30 nye opkoder op-koder for introspeksjon ble introdusert i Liquid's Taproot oppgradering for en mer modulær tilnærming. Introspeksjonskoder med CSFS, for eksempel, muliggjør inspeksjon av mer granulære deler av transaksjonen under et forbruk ved å plassere den på stabelen. Dette letter ansvaret for å samle delvise transaksjonsdata via vitnet og dermed signaturhashen på stabelen.
Ledende avtaleforslag
Foreløpig Bitcoin fellesskapet diskuterer en vaskeriliste over potensielle avtaleforslag, inkludert SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, MATT-opkoden OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT og OP_CHECKTEMPLATEVERIFY (CTV). Enkelhet, et neste generasjons skriptspråk som kan implementere funksjonalitet som ligner på mange pakter på et lavere nivå, er også en potensiell rute for Bitcoin (vi kommer tilbake til dette senere).
Det har vært mye snakk om VAULT opcode, som ble opprettet for å møte behovet for enklere måter å sikre bitcoin for brukere. Denne opkoden vil tillate at mynter låses i en adresse som bare kan brukes til to adresser: en varm lommebok etter en tidslås eller umiddelbart til en kald lommebok. Flere andre variantordninger er foreslått, men de er avhengige av å ta i bruk CTV først.
CTV er en opkode som leser en hash fra stabelen og sammenligner den med en hash av et spesifisert undersett av forbrukstransaksjonens data. Dens fleksibilitet lover å muliggjøre et mangfoldig sett med applikasjoner, inkludert men ikke begrenset til: overbelastningskontroll, hvelv og rudimentære betalingspuljer.
Bortsett fra opcodes, har det vært forslag til sukk for å muliggjøre pakter. De to mest populære forslagene for dette formålet er APO og SIGHASH_GROUP. APO er en videreutvikling av SIGHASH_NOINPUT opcode, som er allment anerkjent som en forutsetning for implementering eltoo. En av de mange forbedringene som er mulig med eltoo, er elimineringen av straffemekanismen som tvinger den andre parten til å miste midler når de kringkaster en utdatert kanalstat. Dette gir et mer brukervennlig og effektivt Lightning-nettverk.
Oppnå lignende funksjonalitet med flytende opkoder
Selv om Liquid ikke har CTV- og VAULT-opkodene, har den CSFS og CAT for pakter. Ved å bruke disse mer snevert definerte op-kodene med de nevnte introspeksjons-op-kodene, har utviklere åpnet for nye økonomiske muligheter med funksjonalitet som ligner på CTV og VAULT for å utvide sidekjeden.
For eksempel har Burak, en erfaren Liquid-utvikler og skaper av lag-2-protokollen Ark, demonstrert en emulering av VALT ved å bruke Liquid Covenant-opkoder i en diskusjon med James O'Beirne på X.
På samme måte ble en måte å oppnå APO-funksjonalitet gjort mulig med CSFS. Dette demo benyttet forskjellige opkoder som ville muliggjøre lag-2-protokoller som eltoo på Liquid i dag, men lider av ekstra kompleksitet og en større transaksjonsstørrelse sammenlignet med den foreslåtte bruken av avtalen av APO-type. Dessuten gjelder ikke konstruksjonen for Taproot-transaksjoner, som vil introdusere sin egen form for ekstra kompleksitet.
Flytende opkoder i aksjon
Mange applikasjoner har allerede benyttet seg av covenant opcodes på Liquid. Steven Roose, en paktsforkjemper som nylig definert en spesifikasjon for den tidligere tenkte OP_TXHASH, har utviklet en søknad for troskapsobligasjoner på Liquid. Denne pakten er plassert på midler som ville bli brent hvis bevis på dobbeltforbruk blir presentert i vitnet.
Fuji penger's Fuji USD (FUSD), en algoritmisk stabil mynt utviklet av Vulpem Ventures er et annet bemerkelsesverdig eksempel. Den er utelukkende avhengig av orakelinformasjon for å opprettholde koblingen og kan utstedes på en desentralisert måte. Den bruker en kombinasjon av signaturverifikasjoner og introspeksjonskoder for å oppnå dette, og den viktigste delen er at alt kan kontrolleres i kjeden.
Andre anvendelser av covenants på Liquid inkluderer opsjonskontrakter og konfidensielle aktivabaserte lån. Blockstream Research-teamet ga ut en whitepaper i fjor (se vedlagte blogginnlegg) om førstnevnte, og forklarer hvordan en slik opsjonskontrakt kan konstrueres ved å bruke det nye settet med introspektive opkoder. Disse nye opkodene lar brukere trygt lage tokens som representerer begge sider av en dekket kjøpsopsjonskontrakt og selge den motsatte posisjonen de ønsker å ta. Kontrakter laget på denne måten støtter også delvis fyllinger, noe som betyr at brukeren som opprettet kontrakten kan selge posisjoner som representerer et multiplum av et brukerspesifisert minimumsbeløp for sikkerheten, kalt "kontraktstørrelsen".
Hvorfor ikke på Liquid First?
Som Bitcoin økosystemet fortsetter å ha en sunn debatt angående paktens opkoder, Liquid tilbyr sitt eget sett med verktøy, som passer til lignende mål, men med distinkte implementeringer. Etter hvert som dialogen utvikler seg, vil det være spennende å se samspillet mellom Bitcoinsine opprinnelige forslag og Liquids allerede konkrete og live paktrelaterte funksjoner og emulering av Bitcoin paktsforslag implementert ved hjelp av Elements Script.
En annen ny teknologi i horisonten er Enkelhet, et verifiserbart programmeringsspråk for blockchain. Simplicity-språket er definert av operasjoner med veldig snever semantikk som kan lage uttrykksfulle programmer når de komponeres sammen. Språket er også verifiserbart, noe som betyr at metoder kan etableres for matematisk å bevise påstander gjort på Simplicity-programmer.
Enkelhetens uttrykksfulle natur gjør at paktens opkoder fra Script kan overføres sømløst, noe som sikrer større pålitelighet og færre uventet oppførsel. Bitcoin forsker Sanket Kanjalkar har allerede gjort dette arbeidet for CTV. Ved hjelp av s-lang, en mer lesbar Bitcoin-sentrisk programmeringsspråk som kompilerer ned til Simplicity, var han i stand til å replikere semantikken i et brukbart proof-of-concept tilgjengelig for alle å prøve i dag.
Bitcoin utviklere vil snart få muligheten til å bruke s-lang i et virkelig miljø takket være Liquids integrasjon av Simplicity, målrettet mot Q2 2024. s-lang vil bringe konstruksjonen av mer komplekse applikasjoner til Liquid, som hvelv og delegering. PR-utkastet er tilgjengelig for gjennomgang på følgende link.
Med en lang historie av Liquid som en tidlig bruker av ideer som senere har blitt overført til Bitcoin, et forslag for de som ønsker å vise frem levedyktigheten til forslagene deres er å prøve det live på Liquid for å validere ideer først – ettersom flere paktrelaterte opkoder har vist seg å være emulerbare ved å bruke eksisterende Liquid-avtale og introspeksjons-opkoder.
Så neste gang noen foreslår en ny pakt, er det verdt å spørre: hvorfor ikke prøve det på Liquid først?
Dette er et gjestepost av Randy Naar. Meninger som er uttrykt er helt sine egne og gjenspeiler ikke nødvendigvis de fra BTC Inc eller Bitcoin Blad.
Opprinnelig kilde: Bitcoin magazine