By Bitcoin Tijdschrift - 6 maanden geleden - Leestijd: 6 minuten
Voordat ze cool waren: overeenkomsten in productie Nn vloeistof
Sinds de Bitcoin gemeenschap begonnen met discussies rond de optimalisatie van convenanten, is er een groeiende belangstelling om meer te leren over hun afwegingen en de convenanten die al zijn ingezet op de Vloeibaar netwerk.
Laten we, in het licht van deze hernieuwde belangstelling en om verdere discussie aan te moedigen, enkele van de huidige convenantenaanbiedingen van Liquid bekijken en deze vergelijken met de belangrijkste voorstellen over Bitcoin en het onderzoeken van hun respectievelijke gebruiksscenario's.
Geschiedenis van overeenkomsten over vloeistoffen
Covenants on Liquid zijn terug te voeren op de inzet van de eerste Elements-zijketen, Alpha. Deze zijketen introduceerde de opcodes OP_CHECKSIGFROMSTACK (CSFS) en OP_DETERMINISTICRANDOM samen met een aantal andere in Elements. Alpha maakte ook vaste versies mogelijk van opcodes die vroegtijdig waren uitgeschakeld Bitcoin, zoals OP_CAT– een opcode die velen kiezen om opnieuw te bezoeken in de groeiende dialoog op sociale media. Deze nieuwe opcodes verbeterden de expressiviteit van de versie van Bitcoin Script beschikbaar in Elements en een proof-of-concept Möser-Eyal-Sirer-kluis is ontwikkeld met behulp van CSFS om de nieuwe mogelijkheden te illustreren.
Een van de lessen uit de implementatie van CSFS was dat het convenanten complexer maakt doordat transactiegegevens op de stapel moeten worden gepusht bij het uitvoeren van convenantuitgaven. Uit ervaring van ontwikkelaars is ook gebleken dat met CSFS-convenanten de transactiegegevens waaruit de handtekeninghash bestaat, op de stapel moeten worden gereconstrueerd, waardoor ontwikkelaars mogelijk worden gedwongen gegevens te pushen die niet relevant zijn voor de transactie-invoer/uitvoer waarin zij geïnteresseerd zijn.
Om de constructie van convenanten te vereenvoudigen, zijn er meer dan 30 nieuwe opcodes aangeroepen introspectie opcodes werden geïntroduceerd in Liquid's Taproot upgrade voor een meer modulaire aanpak. Introspectie-opcodes met CSFS maken bijvoorbeeld de inspectie van meer gedetailleerde delen van de transactie tijdens een uitgave mogelijk door deze op de stapel te plaatsen. Dit verlicht de verantwoordelijkheid van het verzamelen van gedeeltelijke transactiegegevens via de getuige en dus de handtekeninghash op de stapel.
Toonaangevende convenantvoorstellen
Momenteel is de Bitcoin gemeenschap bespreekt een waslijst met potentiële convenantvoorstellen, waaronder SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, de MATT-opcode OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT en OP_CHECKTEMPLATEVERIFY (CTV). Eenvoud, een scripttaal van de volgende generatie die functionaliteit kan implementeren die vergelijkbaar is met veel convenanten op een lager niveau, is ook een potentiële route voor Bitcoin (we komen hier later op terug).
Er is veel gesproken over de VAULT-opcode, die is gemaakt om tegemoet te komen aan de behoefte aan eenvoudigere manieren om te beveiligen bitcoin voor gebruikers. Met deze opcode kunnen munten worden vergrendeld op een adres dat slechts aan twee adressen kan worden uitgegeven: een warme portemonnee na een tijdslot of onmiddellijk naar een koude portemonnee. Er zijn verschillende andere variantschema's voorgesteld, maar deze zijn afhankelijk van de eerste invoering van CTV.
CTV is een opcode die een hash van de stapel leest en deze vergelijkt met een hash van een gespecificeerde subset van de gegevens van de bestedingstransactie. De flexibiliteit belooft een gevarieerde reeks toepassingen mogelijk te maken, waaronder maar niet beperkt tot: congestiecontrole, kluizen en rudimentaire betalingspools.
Naast opcodes zijn er voorstellen gedaan voor sighashes om convenanten mogelijk te maken. De twee meest populaire voorstellen voor dit doel zijn APO en SIGHASH_GROUP. APO is een evolutie van de SIGHASH_NOINPUT opcode, die algemeen wordt erkend als een voorwaarde voor implementatie elto. Een van de vele verbeteringen die mogelijk zijn gemaakt met eltoo is de eliminatie van het boetemechanisme dat de andere partij dwingt geld te verspelen bij het uitzenden van een verouderde zenderstatus. Dit zorgt voor een gebruiksvriendelijker en efficiënter Lightning Network.
Vergelijkbare functionaliteit bereiken met Liquid Opcodes
Hoewel Liquid de CTV- en VAULT-opcodes niet heeft, heeft het wel CSFS en KAT voor convenanten. Door deze nauwer gedefinieerde opcodes te gebruiken met de bovengenoemde introspectie-opcodes, hebben ontwikkelaars nieuwe financiële mogelijkheden geopend met functionaliteit vergelijkbaar met CTV en VAULT om de zijketen uit te breiden.
Burak, een doorgewinterde Liquid-ontwikkelaar en maker van het laag-2-protocol Ark, heeft bijvoorbeeld een emulatie van VAULT het gebruik van Liquid Covenant-opcodes in een gesprek met James O'Beirne op X.
Op dezelfde manier werd een manier om APO-functionaliteit te bereiken mogelijk gemaakt met CSFS. Dit demonstratie maakte gebruik van verschillende opcodes die tegenwoordig laag-2-protocollen zoals eltoo op Liquid mogelijk zouden maken, maar lijdt aan extra complexiteit en een grotere transactieomvang vergeleken met het voorgestelde gebruik van het APO-type convenant. Bovendien is de constructie niet van toepassing op Taproot-transacties, wat een eigen vorm van extra complexiteit zou introduceren.
Vloeibare opcodes in actie
Veel toepassingen hebben al gebruik gemaakt van convenant-opcodes op Liquid. Steven Roose, een voorstander van het convenant die onlangs gedefinieerd een specificatie voor de eerder bedachte OP_TXHASH, heeft een toepassing voor getrouwheidsobligaties op Liquid. Dit verbond is van toepassing op fondsen die zouden worden verbrand als er in de getuige bewijs van dubbele uitgaven wordt gepresenteerd.
Fuji-geldFuji USD (FUSD), een algoritmische stablecoin ontwikkeld door Vulpem Ventures, is een ander opmerkelijk voorbeeld. Het vertrouwt puur op orakelinformatie om zijn koppeling te behouden en kan op een gedecentraliseerde manier worden uitgegeven. Het maakt gebruik van een combinatie van van handtekeningverificaties en introspectie-opcodes om dit te bereiken, en het belangrijkste is dat het allemaal in de keten controleerbaar is.
Andere toepassingen van convenanten op Liquid zijn onder meer optiecontracten en vertrouwelijke, op activa gebaseerde leningen. Het Blockstream Research-team heeft een whitepaper vorig jaar (zie bijgevoegd blogpost) over het eerste, waarin wordt uitgelegd hoe een dergelijk optiecontract kan worden opgebouwd met behulp van de nieuwe reeks introspectieve opcodes. Met deze nieuwe opcodes kunnen gebruikers op een betrouwbare manier tokens creëren die beide zijden van een gedekt calloptiecontract vertegenwoordigen en de tegenovergestelde positie verkopen die ze willen innemen. Contracten die op deze manier worden gemaakt, ondersteunen ook gedeeltelijke vullingen, wat betekent dat de gebruiker die het contract heeft gemaakt posities kan verkopen die een veelvoud vertegenwoordigen van een door de gebruiker opgegeven minimumbedrag van het onderpand, de zogenaamde 'contractgrootte'.
Waarom niet eerst op Liquid?
Aangezien de Bitcoin ecosysteem nog steeds een gezond debat voert over convenant-opcodes, biedt Liquid zijn eigen set tools, die zich richten op vergelijkbare doelstellingen, maar met verschillende implementaties. Naarmate de dialoog zich ontwikkelt, zal het intrigerend zijn om getuige te zijn van de wisselwerking tussen de twee Bitcoin's oorspronkelijke voorstellen en Liquid's reeds concrete en live-verbondsgerelateerde kenmerken en emulatie ervan Bitcoin convenantvoorstellen geïmplementeerd met behulp van Elements Script.
Een andere nieuwe technologie aan de horizon is Eenvoud, een verifieerbare programmeertaal voor de blockchain. De Simplicity-taal wordt gedefinieerd door bewerkingen met een zeer smalle semantiek die expressieve programma's kunnen maken als ze samen worden samengesteld. De taal is ook verifieerbaar, wat betekent dat er methoden kunnen worden ontwikkeld om beweringen in Simplicity-programma's wiskundig te bewijzen.
Dankzij het expressieve karakter van Simplicity kunnen convenant-opcodes van Script naadloos worden geporteerd, wat een grotere betrouwbaarheid en minder onverwacht gedrag garandeert. Bitcoin onderzoeker Sanket Kanjalkar heeft dit werk al gedaan voor CTV. Gebruik makend van s-lang, een beter leesbaar Bitcoin-centrische programmeertaal die tot eenvoud compileert, was hij in staat de semantiek te repliceren in een werkbaar proof-of-concept dat iedereen vandaag de dag kan uitproberen.
Bitcoin ontwikkelaars zullen binnenkort de mogelijkheid hebben om s-lang in een echte omgeving te gebruiken dankzij Liquid's integratie van Simplicity, gericht op het tweede kwartaal van 2. s-lang zal de constructie van complexere applicaties naar Liquid brengen, zoals kluizen en delegatie. Het concept-PR ligt ter inzage op het volgende adres link.
Met een lange geschiedenis van Liquid als een early adopter van ideeën waarnaar later is geporteerd Bitcoin, een suggestie voor degenen die de levensvatbaarheid van hun voorstellen willen laten zien, is om het live op Liquid te proberen om eerst ideeën te valideren – aangezien is aangetoond dat meerdere convenantgerelateerde opcodes emuleerbaar zijn met behulp van bestaande Liquid convenant- en introspectie-opcodes.
Dus de volgende keer dat iemand een nieuw convenant voorstelt, is het de moeite waard om te vragen: waarom probeer je het niet eerst op Liquid?
Dit is een gast bericht door Randy Naar De geuite meningen zijn geheel hun eigen meningen en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Tijdschrift.
Originele bron: Bitcoin Magazine