Autor: Chakra Překladač: 0xjs@金财经

Tento článek je částí III ze série článků o škálovatelnosti bitcoinů publikovaných společností Chakra.

První část najdete v předchozím článku Golden Finance „Recenze nativního plánu expanze bitcoinu: SegWit a Taproot“,

Pro druhou část si přečtěte předchozí článek Golden Finance „Škálovatelnost bitcoinů: Analýza řešení na vrstvě 2 a souvisejících projektů“.

Třetí částí je tento článek, takto:

Přehled

Ve srovnání s Turingově kompletními blockchainy, jako je Ethereum, jsou bitcoinové skripty považovány za extrémně omezující a mohou provádět pouze základní operace a nepodporují ani násobení a dělení. Ještě důležitější je, že data samotného blockchainu jsou pro skripty téměř nepřístupná, což má za následek vážný nedostatek flexibility a programovatelnosti. Proto byly snahy učinit bitcoinové skripty introspektivními.

Introspekce se týká schopnosti bitcoinových skriptů kontrolovat a omezovat transakční data. To umožňuje skriptům řídit využití finančních prostředků na základě konkrétních podrobností transakce, což umožňuje komplexnější funkce. V současné době většina bitcoinových operačních kódů buď vkládá data dodaná uživatelem do zásobníku, nebo manipuluje s existujícími daty v zásobníku. Operační kód introspekce však může přenést data aktuální transakce (jako je časové razítko, částka, txid atd.) do zásobníku, což umožňuje podrobnější kontrolu nad výdaji UTXO.

V současné době podporují introspekci v bitcoinovém skriptu pouze tři hlavní operační kódy: CHECKLOCKTIMEVERIFY, CHECKEQUENCEVERIFY a CHECKSIG a jejich varianty CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG a CHECKMULTISIGVERIFY.

Covenant (také přeloženo jako „omezení“), jednoduše řečeno, odkazuje na omezení metod převodu měn, což uživatelům umožňuje určit způsob distribuce UTXO. Mnoho smluv je implementováno prostřednictvím introspekčních opcodes a diskuse o introspekci byla nyní odsunuta na téma Bitcoin Optech Contracts.

Bitcoin má v současné době dvě smlouvy, CSV (CheckSequenceVerify) a CLTV (CheckLockTimeVerify). Obě smlouvy jsou časově založené a jsou základem mnoha rozšiřujících řešení (například Lightning Network). To ilustruje, že řešení škálování bitcoinů silně spoléhá na introspekci a smlouvy.

Jak přidáme podmínky k převodu tokenů? Ve světě kryptoměn to nejběžnějším způsobem děláme prostřednictvím slibů, obvykle pomocí hashů. Aby se prokázalo, že jsou splněny požadavky na přenos, je pro ověření vyžadován také podpisový mechanismus. Proto je ve smlouvě mnoho úprav hashů a podpisů.

Níže popisujeme široce diskutovaný návrh operačního kódu Covenant.

CTV（CheckTemplateVerify）BIP-119

CTV (CheckTemplateVerify) je návrh na upgrade bitcoinů v BIP-119, který přitáhl širokou pozornost komunity. CTV umožňuje výstupním skriptům specifikovat šablony pro výplaty prostředků v transakcích, včetně nVersion, nLockTime, scriptSig hash, vstupní počet, sekvenční hash, výstupní počet, výstupní hash, vstupní index a další pole. Tato omezení šablony jsou implementována prostřednictvím hash slibů, a když jsou prostředky utraceny, skript zkontroluje, zda hash zadaného pole ve výdajové transakci odpovídá hash ve vstupním skriptu. To efektivně omezuje čas, způsob a množství budoucích transakcí pro toto UTXO.

Stojí za zmínku, že vstupní TXID je z tohoto hashe vyloučeno. Toto vyloučení je nutné, protože v tradičních a SegWit transakcích při použití výchozího typu podpisu SIGHASH_ALL závisí TXID na hodnotě v scriptPubKey. Zahrnutí TXID způsobí kruhovou závislost v hash slibu, což znemožňuje sestavení.

Metoda introspekce CTV spočívá v tom, že přímo vytáhne zadané transakční informace, hashuje je a poté je porovná s přísliby v zásobníku. Tato metoda introspekce má nižší požadavky na prostor řetězce, ale postrádá určitou flexibilitu.

Základem řešení druhé vrstvy bitcoinu, jako je Lightning Network, jsou předem podepsané transakce. Předběžné podepisování obvykle znamená generování a podepisování transakcí předem, ale jejich vysílání, dokud nejsou splněny určité podmínky. CTV v podstatě implementuje restriktivnější formu předběžného podepisování, zveřejňuje předem podepsané závazky v řetězci a omezuje je na předem definované šablony.

CTV bylo původně navrženo ke zmírnění přetížení bitcoinů, které lze také nazvat kontrolou přetížení. Když je přetížení vážné, CTV se může zavázat k několika budoucím transakcím v jediné transakci, čímž se vyhne vysílání více transakcí ve špičce a dokončení skutečné transakce, když se přetížení uvolní. To může být užitečné zejména během výměnného běhu. Šablonu lze navíc použít k implementaci Vault na ochranu před útoky hackerů. Vzhledem k tomu, že tok finančních prostředků je předem určen, hackeři nemohou používat skripty CTV k nasměrování UTXO na jejich vlastní adresy.

CTV může výrazně zlepšit sítě druhé vrstvy. Například v Lightning Network může CTV vytvářet stromy časových limitů a továrny na kanály rozšířením jednoho UTXO do stromu CTV, což umožňuje otevření více stavových kanálů pouze jednou transakcí a jedním potvrzením. CTV navíc podporuje atomové transakce v protokolu Ark prostřednictvím ATLC.

APO（SIGHASH_ANYPREVOUT）BIP-118

BIP-118 zavádí nový podepsaný hash flag pro tapscript navržený tak, aby usnadnil flexibilnější logiku výdajů, nazvaný SIGHASH_ANYPREVOUT. APO a CTV mají mnoho podobností. Přístup APO k řešení problému smyčky mezi scriptPubKeys a TXID spočívá ve vyloučení relevantních vstupních informací a podepsání pouze výstupu, což umožňuje, aby transakce byly dynamicky vázány na různé UTXO.

Operace ověření podpisu OP_CHECKSIG (a její varianty) logicky provádí tři funkce:

1. Sestavte různé části nákladové transakce.

2. Hash je.

3. Ověřte, že hash byl podepsán daným klíčem.

V konkrétních detailech podpisu je velká flexibilita, přičemž příznak SIGHASH určuje, která pole transakce jsou podepsána. Podle definice podpisového operačního kódu v BIP 342 je příznak SIGHASH rozdělen na SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE a SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY ovládá vstup, zatímco ostatní ovládají výstup.

SIGHASH_ALL je výchozí příznak SIGHASH, podepisuje všechny výstupy SIGHASH_NONE nepodepisuje žádný výstup; SIGHASH_ANYONECANPAY lze nastavit společně s prvními třemi příznaky SIGHASH. Pokud je nastaveno SIGHASH_ANYONECANPAY, je podepsán pouze zadaný vstup, jinak musí být podepsán celý vstup.

Je zřejmé, že tyto příznaky SIGHASH nezruší dopad vstupu, dokonce ani SIGHASH_ANYONECANPAY, který vyžaduje potvrzení vstupu.

Proto BIP 118 navrhuje SIGHASH_ANYPREVOUT. Podpisy APO nevyžadují, aby byl potvrzen utracený vstup UTXO (nazývaný PREVOUT), ale pouze výstup, což poskytuje větší flexibilitu pro kontrolu bitcoinů. Předkonstruováním transakce a vytvořením odpovídajícího jednorázového podpisu a veřejného klíče musí být aktiva odeslaná na tuto adresu veřejného klíče použita prostřednictvím předem vytvořené transakce, čímž je smlouva splněna. Flexibilitu APO lze také využít pro opravu transakcí, pokud se transakce zasekne v řetězci, protože poplatek je příliš nízký, lze snadno vytvořit další transakci pro zvýšení poplatku bez nutnosti nového podpisu. U peněženek s více podpisy navíc nespoléhání na vynaložené vstupy dělá operace pohodlnějšími.

Protože je eliminována smyčka mezi scriptPubKeys a vstupním TXID, může APO provádět introspekci přidáním výstupních dat do Witness, i když to stále vyžaduje další spotřebu místa Witness.

U off-chain protokolů, jako je Lightning Network a Vaults, APO snižuje potřebu ukládat přechodný stav, čímž výrazně snižuje požadavky na úložiště a složitost. Nejokamžitějším případem použití pro APO je Eltoo, které v mnoha ohledech zvyšuje výkon Lightning Network zjednodušením továren na kanály, budováním lehkých a levných strážních věží a umožněním jednostranných výstupů bez zanechání chybových stavů. APO lze také použít k emulaci funkcí CTV, ačkoli to vyžaduje, aby jednotlivci ukládali podepsané a předem podepsané transakce, což je dražší a méně efektivní než CTV.

Hlavní kritika APO se soustředí na skutečnost, že vyžaduje novou klíčovou verzi, které nelze dosáhnout jednoduchou zpětnou kompatibilitou. Navíc nové typy hash signatur mohou představovat potenciální riziko dvojího utrácení. Po rozsáhlé diskuzi v komunitě APO získalo kód BIP-118 přidáním pravidelných podpisů nad původní podpisový mechanismus, aby se zmírnily obavy o bezpečnost.

OP_VAULT BIP-345

BIP-345 navrhuje přidání dvou nových operačních kódů, OP_VAULT a OP_VAULT_RECOVER, které v kombinaci s CTV umožňují specializované smlouvy, které uživatelům umožňují vynutit si odklad konkrétní měny. Během tohoto zpoždění mohou být dříve provedené transakce „vráceny zpět“ prostřednictvím cesty obnovení.

Uživatelé mohou vytvořit Vault vytvořením specifické Taproot adresy, která musí obsahovat alespoň dva skripty ve svém MAST: jeden s operačním kódem OP_VAULT pro usnadnění očekávaného procesu stažení a druhý s operačním kódem OP_VAULT_RECOVER, který zajistí, že bude možné obnovit tokeny výběru. kdykoli před dokončením platby.

OP_VAULT Jak implementovat přerušitelné časované uzamčené výběry? OP_VAULT to dělá tak, že nahradí použitý skript OP_VAULT zadaným skriptem, čímž efektivně aktualizuje jeden list MAST, zatímco zbývající Taproot listové uzly zůstanou nezměněny. Tento design je podobný TLUV, kromě toho, že OP_VAULT nepodporuje aktualizace interních klíčů.

Platby lze omezit zavedením šablon během aktualizací skriptů. Parametr časového zámku je specifikován OP_VAULT a šablona pro operační kód CTV omezuje sadu výstupů, které lze použít prostřednictvím této cesty skriptu.

BIP-345 je navržen speciálně pro Vaulty, využívá OP_VAULT a OP_VAULT_RECOVER, aby uživatelům poskytl bezpečnou metodu úschovy u třetí osoby pomocí vysoce bezpečných klíčů (jako jsou papírové peněženky nebo distribuované multi-podpisy) jako cesty obnovy při konfiguraci určitých zpoždění pro opakované platby. Zařízení uživatele nepřetržitě monitoruje útratu trezoru, a pokud dojde k neočekávanému převodu, uživatel může zahájit obnovu.

Implementace Vault prostřednictvím BIP-345 přichází s úvahami o nákladech, zejména při obnově transakcí. Možná řešení zahrnují CPFP (dítě platí za rodiče), dočasné kotvy a nový podepsaný hash příznak SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Řešení TLUV je postaveno na Taproot a jeho cílem je efektivně vyřešit problém sdíleného výstupu UTXO. Zásadou je, že když je spotřebován výstup Taproot, mohou být interní klíče a MAST (tapscript trie) částečně aktualizovány pomocí kryptografických transformací a vnitřní struktury adresy Taproot, jak je popsáno ve skriptu TLUV. To umožňuje implementaci funkce Covenant.

Koncept schématu TLUV spočívá ve vytvoření nové Taproot adresy na základě aktuálního výdajového vstupu zavedením nového operačního kódu TAPLEAF_UPDATE_VERIFY. Toho lze dosáhnout provedením jednoho nebo více z následujících:

• Aktualizujte interní veřejný klíč

• Ořízněte Merkle cesty

• Odstraňte aktuálně spuštěný skript

• Přidejte nový krok na konec cesty Merkle

Konkrétně TLUV přijímá tři vstupy:

• Určuje, jak aktualizovat interní veřejný klíč.

• Způsob, jak určit nový krok pro cestu Merkle.

• Určuje, zda se má odstranit aktuální skript a/nebo kolik kroků cesty Merkle oříznout.

Operační kód TLUV vypočítá aktualizovaný scriptPubKey a ověří, zda je výstup odpovídající aktuálnímu vstupu vynaložen na tento scriptPubKey.

TLUV je inspirován konceptem CoinPool. Dnes lze federované fondy vytvářet pouze s předem podepsanými transakcemi, ale pokud má být dosaženo ukončení bez oprávnění, bude potřeba vytvořit exponenciálně větší počet podpisů. TLUV na druhé straně umožňuje bez povolení výjezd bez jakéhokoli předběžného podepisování. Například skupina partnerů může shromáždit své finanční prostředky pomocí Taproot k vytvoření sdílených UTXO. Mohou používat Taproot klíče k internímu přesunu finančních prostředků nebo spolupodepisování k externímu inicializaci plateb. Jednotlivci mohou kdykoli vystoupit ze sdíleného fondu fondů a odstranit tak svou platební cestu, zatímco ostatní mohou stále provádět platby původní cestou a výběr jednotlivce nezpřístupňuje další informace o ostatních uvnitř. Tento model je efektivnější a soukromější než nesdružené transakce.

Operační kód TLUV implementuje částečná omezení výdajů aktualizací původního Taproot Trie, ale neimplementuje introspekci výstupních částek. Proto je také vyžadován nový operační kód IN_OUT_AMOUNT. Tento operační kód vloží do zásobníku dvě položky: množství UTXO tohoto vstupu a množství odpovídajícího výstupu, a poté musí osoba používající TLUV použít matematické operátory k ověření, že jsou prostředky správně uchovány v aktualizovaném scriptPubKey.

Introspekce výstupních částek zvyšuje složitost, protože částky v satoshi vyžadují k vyjádření až 51 bitů, ale skript umožňuje pouze 32bitové matematické operace. To vyžaduje předefinování chování operačních kódů pro upgrade operátoru ve skriptu nebo nahrazení IN_OUT_AMOUNT za SIGHASH_GROUP.

TLUV má potenciál být řešením pro decentralizované fondy vrstvy 2, ale jeho spolehlivost při přizpůsobení Taproot Trie je ještě třeba potvrdit.

MATT

MATT (Merkleize All The Things) si klade za cíl dosáhnout tří cílů: Merkleizace státu, Merkleizace scénáře a Merkleize předvádění, a tím realizace univerzálních smart kontraktů.

• Merkleizace stavu: To zahrnuje vybudování Merkle Trie, kde každý listový uzel představuje hash stavu a Merkle Root ztělesňuje celkový stav kontraktu.

• Merkleizing the script: Toto odkazuje na použití Tapscript k vytvoření MAST, kde každý listový uzel představuje možnou cestu přechodu stavu.

• Merkleizing the performance: Merkleizing performance prostřednictvím kryptografických závazků a mechanismů pro boj proti podvodům. Pro jakoukoli výpočetní funkci ji mohou účastníci spočítat mimo řetězec a poté vydat závazek f(x)=y. Pokud ostatní účastníci objeví nesprávný výsledek f(x)=z, mohou zahájit výzvu. Arbitráž se provádí pomocí binárního vyhledávání, podobně jako na principu Optimistic Rollup.

Implementace Merkelové

Aby bylo možné implementovat MATT, bitcoinový skriptovací jazyk musí mít následující schopnosti:

• Vynutit na výstupu konkrétní skripty (a jejich počet)

• Připojte část dat k výstupu

• Číst data z aktuálního vstupu (nebo jiného vstupu)

Druhý bod je zásadní: dynamická data znamenají, že stav lze vypočítat ze vstupních dat poskytnutých spotřebitelem, protože to umožňuje simulovat stavový automat, schopný určit další stav a další data. Schéma MATT toho dosahuje prostřednictvím OP_CHECKCONTRACTVERIFY (OP_CCV) opcode, což je sloučení dříve navržených operačních kódů OP_CHECKOUTPUTCONTRACTVERIFY a OP_CHECKINPUTCONTRACTVERIFY, pomocí dalšího parametru příznaku k určení cíle operace.

Řízení výstupního množství: Nejpřímější metodou je introspekce přímo, výstupní množství je však 64bitové číslo a vyžaduje 64bitovou aritmetiku, což přináší do bitcoinových skriptů velkou složitost. OP_CCV používá metodu zpožděné kontroly jako OP_VAULT, kde se vstupní množství všech vstupů pro stejný výstup v CCV sčítají jako dolní mez pro množství tohoto výstupu. Zpoždění je způsobeno tím, že k této kontrole dochází během transakce, nikoli během vyhodnocování vstupu skriptem.

Vzhledem k všudypřítomnosti důkazů o podvodu by některá varianta smlouvy MATT měla být schopna implementovat všechny typy inteligentních smluv nebo konstrukcí vrstvy 2, i když je třeba přesně vyhodnotit další požadavky (jako je zamykání fondů a zpoždění období výzvy). potřebné k vyhodnocení, které aplikace Program může přijímat transakce. Například použijte mechanismy pro kryptografické závazky a podvody k emulaci funkce OP_ZK_VERIFY k implementaci důvěryhodných souhrnů na bitcoiny.

V praxi k tomu již došlo. Johan Torås Halseth implementoval elftrace pomocí OP_CHECKCONTRACTVERIFY opcode v návrhu soft forku MATT, který umožňuje ověření jakéhokoli programu zkompilovaného s podporou RISC-V na bitcoinovém blockchainu, což umožňuje jedné straně smluvní dohody předat ověření smlouvy pro přístup k finančním prostředkům, překlenovací bitcoinové nativní ověření.

CSFS（OP_CHECKSIGFROMSTACK）

Od zavedení kódu operace APO víme, že OP_CHECKSIG (a související operace) je zodpovědný za sestavování transakcí, výpočty hash a ověřování podpisů. Zprávy ověřené těmito operacemi jsou však serializovány prostřednictvím transakce s operačním kódem a neumožňují zadat žádné jiné zprávy. Jednoduše řečeno, úlohou OP_CHECKSIG (a souvisejících operací) je použít podpisový mechanismus k ověření, zda je UTXO vynaložené jako transakční vstup oprávněn používat držitel podpisu, a tím chránit bezpečnost bitcoinu.

CSFS, jak název napovídá, kontroluje Signature From Stack. Operační kód CSFS přijímá ze zásobníku tři parametry: podpis, zprávu a veřejný klíč a ověřuje platnost podpisu. To znamená, že lidé mohou předat libovolnou zprávu do zásobníku prostřednictvím svědků a ověřit si ji prostřednictvím CSFS, čímž umožní některé inovace bitcoinu.

Flexibilita CSFS mu umožňuje implementovat mechanismy, jako jsou podpisy plateb, delegování, smlouvy Oracle, záruky ochrany dvojitých výdajů a co je důležitější, introspekce transakcí. Princip transakční introspekce pomocí CSFS je velmi jednoduchý: pokud je obsah transakce používaný OP_CHECKSIG odeslán do zásobníku prostřednictvím svědka a OP_CSFS i OP_CHECKSIG jsou ověřeny pomocí stejného veřejného klíče a podpisu, a pokud obě ověření projdou úspěšně, pak Obsah jakékoli zprávy pro OP_CSFS je stejný jako serializovaná nákladová transakce (a další data) implicitně používaná OP_CHECKSIG. Poté získáme ověřená data o transakcích na zásobníku, která lze použít k omezení útratových transakcí pomocí jiných operačních kódů.

CSFS je často viděn společně s OP_CAT, protože OP_CAT může zřetězit různá pole transakce k dokončení serializace, což umožňuje přesnější výběr transakčních polí požadovaných pro introspekci. Bez OP_CAT skript nemůže přepočítat hashe z dat, která lze zkontrolovat jednotlivě, takže vše, co může skutečně udělat, je zkontrolovat, zda hash odpovídá konkrétní hodnotě, což znamená, že token lze utratit pouze prostřednictvím jedné konkrétní transakce.

CSFS může implementovat operační kódy jako CLTV, CSV, CTV, APO atd., což z něj činí všestranný operační kód pro introspekci. Proto také přispívá k řešením škálovatelnosti bitcoinové vrstvy 2. Nevýhodou je, že vyžaduje přidání úplné kopie podepsané transakce do zásobníku, což může výrazně zvýšit velikost transakcí pomocí CSFS introspekce. Jednoúčelové operační kódy pro introspekci, jako jsou CLTV a CSV, mají ve srovnání s nimi malou režii, ale přidání každého nového speciálního introspekčního opcode vyžaduje změny konsensu.

TXHASH (OP_TXHASH)

OP_TXHASH je jednoduchý introspekční operační kód, který umožňuje operátorovi vybrat hash určitého pole a vložit jej do zásobníku. Konkrétně OP_TXHASH vybere příznak txhash ze zásobníku, vypočítá (tagovaný) txhash na základě tohoto příznaku a poté vloží výsledný hash zpět do zásobníku.

Kvůli podobnosti mezi TXHASH a CTV se o nich v komunitě hodně diskutovalo.

TXHASH lze považovat za obecný upgrade na CTV, který poskytuje pokročilejší šablony transakcí a umožňuje uživatelům explicitně specifikovat různé části útratové transakce, čímž řeší mnoho problémů souvisejících s transakčními poplatky. Na rozdíl od jiných operačních kódů Covenant nevyžaduje TXHASH kopii potřebných dat ve svědectví, což dále snižuje nároky na úložiště na rozdíl od CTV, TXHASH není kompatibilní s NOP a lze jej použít pouze v kombinaci TXHASH a CSFS; jako alternativy CTV a APO.

Z hlediska vytváření smluv je TXHASH vhodnější pro vytváření „aditivních smluv“, kde jsou všechny části transakčních dat, které chcete opravit, vloženy do zásobníku, společně hašovány a ověřeny, že výsledný hash odpovídá pevné hodnotě Match;CTV is lépe se hodí pro vytváření „subtraktivních kontraktů“, kde jsou všechny části transakčních dat, které chcete mít volné, vloženy do zásobníku. Poté pomocí postupných operačních kódů SHA256 začne zpracování hash z pevného přechodného stavu, který je potvrzen prefixem dat hash transakce. Volná část je hašována do tohoto přechodného stavu.

Očekává se, že pole TxFieldSelector definované ve specifikaci TXHASH bude rozšířeno na další operační kódy, jako je OP_TX.

BIP související s TXHASH je momentálně na GitHubu ve stavu Koncept a ještě mu nebylo přiděleno číslo.

OP_CAT

OP_CAT je záhadný operační kód, který původně opustil Satoshi Nakamoto z bezpečnostních důvodů, ale nedávno vyvolal vášnivé diskuse mezi vývojáři Bitcoin Core a dokonce vyvolal kulturu Meme na internetu. Nakonec byl OP_CAT schválen podle BIP-347 a byl citován jako návrh BIP, který s největší pravděpodobností v blízké budoucnosti projde.

Ve skutečnosti je chování OP_CAT velmi jednoduché: zřetězí dva prvky ze zásobníku. Jak implementuje funkcionalitu Covenant?

Ve skutečnosti schopnost propojit dva prvky odpovídá silné kryptografické datové struktuře: Merkle Trie. K sestavení Merkle Trie je zapotřebí pouze zřetězení a hašování a hašovací funkce je poskytována v Bitcoin Scriptu. Pomocí OP_CAT tedy můžeme teoreticky ověřit Merkle důkazy v bitcoinovém skriptu, což je jedna z nejběžnějších odlehčených ověřovacích metod v blockchainové technologii.

Jak již bylo zmíněno dříve, CSFS může implementovat obecné Covenant řešení s pomocí OP_CAT. Samotný OP_CAT může ve skutečnosti umožnit introspekci transakcí i bez CSFS, přičemž využívá strukturu podpisů Schnorr.

V podpisech Schnorr se zpráva, kterou je třeba podepsat, skládá z následujících polí:

Tato pole obsahují hlavní prvky transakce. Umístěním do scriptPubKey nebo Witness a použitím OP_CAT ve spojení s OP_SHA256 můžeme vytvořit Schnorrův podpis a ověřit jej pomocí OP_CHECKSIG. Pokud ověření projde, zásobník uchová data ověřené transakce, což umožní introspekci transakce. To nám umožňuje extrahovat a „prozkoumat“ různé části transakce, jako jsou její vstupy, výstupy, cílová adresa nebo množství bitcoinu.

Konkrétní principy kryptografie naleznete v článku Andrewa Poelstra „CAT and Schnorr Tricks“.

Celkově vzato, všestrannost OP_CAT umožňuje simulovat téměř jakýkoli operační kód Covenant. Mnoho operačních kódů Covenant spoléhá na funkčnost OP_CAT, což výrazně zlepšuje jeho pozici v seznamu sloučení. Teoreticky, spoléhat se pouze na OP_CAT a existující bitcoinové operační kódy, bychom mohli doufat, že vybudujeme BTC ZK Rollup s minimalizací důvěry. Starknet, Chakra a další partneři z ekosystému tento cíl aktivně prosazují.

na závěr

Když zkoumáme různé strategie pro škálování bitcoinů a vylepšení jeho programovatelnosti, je jasné, že cesta vpřed zahrnuje směs nativních vylepšení, off-chain computingu a sofistikovaných skriptovacích schopností.

Bez pružné základní vrstvy není možné postavit pružnější druhou vrstvu.

Škálování počítačů mimo řetězec je budoucnost, ale programovatelnost bitcoinu potřebuje průlom, aby lépe podporovala tuto škálovatelnost a stala se skutečně globální měnou.

Povaha počítání na bitcoinu se však zásadně liší od povahy počítání na Ethereu. Bitcoin podporuje pouze „ověření“ jako formu výpočtu a nemůže provádět obecné výpočty, zatímco Ethereum má výpočtovou povahu a ověření je vedlejším produktem výpočtu. Tento rozdíl lze vidět v jednom bodě: Ethereum si účtuje poplatek za plyn za transakce, které nelze provést, zatímco Bitcoin si jej neúčtuje.

Smlouva je forma inteligentní smlouvy, která je založena spíše na ověření než na výpočtu. S výjimkou hrstky satoshi fundamentalistů se zdá, že všichni souhlasí s tím, že smlouvy jsou dobrou volbou pro zlepšení bitcoinu. Komunita však stále zuřivě debatuje o tom, jaká metoda by měla být použita k realizaci zakázky.

APO, OP_VAULT a TLUV preferují přímou aplikaci Výběrem těchto tří metod lze realizovat konkrétní aplikace levněji a efektivněji. Nadšenci pro Lightning Network si pro implementaci LN-Symmetry zvolí APO; uživatelé, kteří chtějí implementovat Vault, nejlépe používají OP_VAULT a pro budování CoinPool může TLUV poskytnout lepší soukromí a efektivitu. OP_CAT a TXHASH jsou bohatší na funkce, méně pravděpodobné, že budou mít bezpečnostní zranitelnosti, a lze je kombinovat s jinými operačními kódy, aby se dosáhlo více případů použití, ale náklady se mohou zvýšit složitostí skriptů. CTV a CSFS upravují způsob zpracování blockchainu, CTV implementuje zpožděný výstup a CSFS implementuje zpožděný podpis. MATT vyniká svým optimistickým prováděním a strategiemi odolnými proti podvodům, využívající strukturu Merkle Trie k implementaci univerzálních chytrých kontraktů, ale funkce introspekce stále vyžaduje nové operační kódy.

Vidíme, že bitcoinová komunita aktivně diskutuje o možnosti získat Covenanty prostřednictvím soft forku. Společnost Starknet oficiálně oznámila, že se připojí k ekosystému bitcoinů a plánuje implementovat vypořádání v síti bitcoinů do šesti měsíců po sloučení OP_CAT. Chakra bude i nadále věnovat pozornost nejnovějšímu vývoji v ekosystému bitcoinů, podporovat sloučení soft forku OP_CAT a využívat programovatelnost, kterou přináší Covenants, k vybudování bezpečnější a efektivnější vrstvy vypořádání bitcoinů.