Svatý grál sítě 2. vrstvy bitcoinu: Introspekce a smlouvy

cd

Ve srovnání s blockchainy, které jsou kompletní podle Turinga, jako je Ethereum, je skriptovací jazyk Bitcoinu považován za značně omezený, schopný provádět pouze základní operace, a dokonce mu chybí funkce násobení a dělení. A co je ještě důležitější, vlastní data blockchainu jsou pro skripty téměř nepřístupná, což vede k vážným omezením flexibility a programovatelnosti. V důsledku toho lidé již dlouho hledají způsoby, jak skriptům Bitcoinu umožnit introspekci.

Introspekce označuje schopnost Bitcoin skripty kontrolovat a omezovat data transakcí. To umožňuje skriptům řídit použití finančních prostředků na základě konkrétních údajů o transakci, což umožňuje složitější funkce. V současné době většina bitcoinových operačních kódů buď odesílá na zásobník uživatelem zadaná data, nebo manipuluje s daty, která již na zásobníku jsou. Introspekční opkódy však mohou na zásobník posunout aktuální data o transakcích (například časové značky, částky a ID transakcí), což umožňuje podrobnější kontrolu nad utrácením UTXO.

V současné době jsou ve skriptech Bitcoinu pouze tři hlavní opcodes, které podporují introspekci: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY a CHECKSIG. CHECKSIG má několik variant, včetně CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG a CHECKMULTISIGVERIFY.

Smlouvy existují omezení týkající se způsobu převodu tokenů. Uživatelé mohou specifikovat způsob distribuce UTXO prostřednictvím smluv, z nichž mnohé jsou implementovány pomocí introspekčních opkódů. V současné době Bitcoin Optech kategorizuje introspekci pod záznamy covenantů.

Bitcoin má v současné době dvě smlouvy: CSV (CheckSequenceVerify) a CLTV (CheckLockTimeVerify), které jsou založeny na čase a tvoří základ mnoha škálovacích řešení, jako je Lightning Network. To naznačuje, že řešení škálování Bitcoinu se do značné míry spoléhají na introspekci a kovenanty.

Jak přidat podmínky k přenosům tokenů

V kryptografickém světě se nejčastěji používá metoda závazky, často realizovaná pomocí hashů. K prokázání splnění podmínek přenosu se k ověření používají mechanismy podpisu. Proto smlouvy zahrnují četné úpravy hashů a podpisů.

Následující návrhy jsou široce diskutovány:

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify), který je součástí BIP-119, je velmi diskutovaný upgrade Bitcoinu. CTV umožňuje výstupním skriptům specifikovat šablony pro výdajové transakce, včetně polí jako nVersion, nLockTime, skriptSig hash, počet vstupů, hash sekvencí, počet výstupů, hash výstupů a vstupní index. Tato omezení šablon jsou implementována prostřednictvím závazku hash a budoucí výdajové skripty budou kontrolovat, zda hodnoty hash zadaných polí ve výdajové transakci odpovídají hodnotám ve vstupním skriptu. Tyto šablony v podstatě definují čas, způsob a částku budoucích transakcí UTXO.

Vstupní TXID je z hash závazku vyloučen. Toto vyloučení je nutné, protože při použití výchozího typu podpisu SIGHASH_ALL závisí TXID na hodnotě scriptPubKey, ať už v transakcích Legacy nebo Segwit. Zahrnutím TXID by vznikla kruhová závislost, která by znemožnila sestavení hashovacího závazku.

CTV dosahuje introspekce přímým získáním zadaných informací o transakci prostřednictvím nového opkódu, jejich hashováním a porovnáním se závazkem na zásobníku. Tato metoda spotřebovává méně místa v řetězci, ale postrádá určitou flexibilitu.

Základem řešení druhé vrstvy, 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í až po splnění určitých podmínek. CTV v podstatě implementuje přísnější funkci předběžného podepisování, zveřejňuje předem podepsaný závazek přímo v řetězci a umožňuje transakce pouze podle předem definované šablony.

CTV byl původně navržen ke zmírnění přetížení sítě Bitcoin a lze jej také označit jako řízení přetížení. Během období vysokého zahlcení může CTV prostřednictvím jediné transakce zavázat více budoucích transakcí, čímž se vyhne nutnosti vysílat více transakcí během zahlcení a dokončí skutečné transakce poté, co zahlcení poleví. To by mohlo významně pomoci během běhu výměny. Kromě toho lze šablony použít k implementaci trezorů, čímž se zabrání hackerským útokům, protože cíl prostředků je předem určen, což hackerům znemožňuje odeslat UTXO pomocí skriptu CTV na jejich adresy.

CTV může výrazně zlepšit sítě druhé vrstvy. Například v síti Lightning implementace Timeout Trees a Channel Factories pomocí CTV umožňuje jedinému UTXO rozšířit se do stromu CTV a otevřít více stavových kanálů s jedinou transakcí a potvrzením v řetězci. Kromě toho CTV podporuje atomické transakce (ATLC) v protokolu Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 navrhuje pro tapscript nový příznak hash podpisu nazvaný SIGHASH_ANYPREVOUT, který usnadňuje psaní flexibilnější logiky výdajů. APO a CTV jsou si v mnoha ohledech podobné. Řešení APO, které řeší kruhovou závislost mezi skriptPubKeys a TXID, spočívá ve vyloučení příslušných vstupních informací a podepsání pouze výstupu, což umožňuje transakcím dynamicky se vázat na různé UTXO.

Logicky má ověřovací operace OP_CHECKSIG (a s ní související opcodes) tři funkce:

  1. Sestavte části výdajové transakce.
  2. Hash tyto části.
  3. Ověří, zda je hash podepsán daným klíčem.

Konkrétní obsah podpisu lze výrazně upravit a to, která pole transakce budou podepsána, určuje příznak SIGHASH. Podle definice podpisových opkódů BIP 342 patří mezi příznaky SIGHASH mimo jiné SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE a SIGHASH_ANYONECANPAY. SIGHASH_ANYONECANPAY řídí vstup, zatímco ostatní řídí výstup.

SIGHASH_ALL je výchozí příznak SIGHASH, který podepisuje všechny výstupy. SIGHASH_NONE nepodepisuje žádné výstupy a SIGHASH_SINGLE podepisuje pouze zadaný výstup. Příznak SIGHASH_ANYONECANPAY lze nastavit spolu s ostatními třemi příznaky, a pokud je nastaven, podepisuje pouze zadaný vstup; jinak musí být podepsány všechny vstupy.

Žádný z těchto příznaků SIGHASH nemůže eliminovat vliv vstupů. Dokonce i příznak SIGHASH_ANYONECANPAY vyžaduje závazek k jednomu vstupu.

BIP 118 proto zavádí SIGHASH_ANYPREVOUT. Podpisy APO se nemusí vázat na spotřebované vstupní UTXO (nazývané PREVOUT), podepisuje se pouze výstup, což poskytuje vyšší flexibilitu při řízení bitcoinů. Předkonstruováním transakcí a vytvořením odpovídajících jednorázových podpisů a veřejných klíčů musí být aktiva zaslaná na danou adresu veřejného klíče utracena prostřednictvím předkonstruované transakce, čímž se dosáhne smlouvy.

Flexibilitu systému APO lze využít i pro opravu transakcí. Pokud se transakce zasekne v řetězci kvůli nízkým poplatkům, lze snadno vytvořit další transakci, která poplatek zvýší, aniž by bylo třeba nových podpisů. U peněženek s více podpisy navíc podpisy, které nejsou závislé na vynaloženém vstupu, zjednodušují operace.

Odstraněním kruhové závislosti mezi skriptPubKeys a vstupními TXID může APO dosáhnout introspekce přidáním výstupních dat do svědka, i když to stále vyžaduje další datový prostor pro svědka.

U protokolů mimo řetězec, jako je Lightning Network a trezory, snižuje APO potřebu ukládání mezistavů, čímž výrazně snižuje požadavky na ukládání a složitost. Nejpřímějším případem využití APO je Eltoo, zjednodušující továrny kanálů, konstruující lehké a levné strážní věže a umožňující jednostranné výstupy bez zanechání chybných stavů, což zvyšuje výkonnost Lightning Network. APO může simulovat funkce CTV, ačkoli vyžaduje osobní ukládání podpisů a předem podepsaných transakcí, takže je nákladnější a méně efektivní než CTV.

Hlavní výtkou k APO je nutnost nové verze klíče, což způsobuje nekompatibilitu se stávajícími systémy. Kromě toho by nový typ hash podpisu mohl přinést potenciální riziko dvojího použití. Po rozsáhlých komunitních diskusích nyní APO vyžaduje kromě původního podpisu i obyčejný podpis, čímž zmírňuje obavy o bezpečnost a získává své číslo BIP-118.

OP_VAULT BIP-345

BIP-345 navrhuje dva nové opkódy, OP_VAULT a OP_VAULT_RECOVER, které spolupracují s CTV a implementují vyhrazenou dohodu, která vynucuje dobu zpoždění při utrácení určených tokenů, během níž lze utrácení „odvolat“ cestou obnovy.

Uživatelé mohou vytvořit trezor nastavením konkrétní adresy Taproot a zahrnutím alespoň dvou skriptů do MAST: skriptu OP_VAULT pro usnadnění očekávaného procesu výběru a skriptu OP_VAULT_RECOVER pro zajištění obnovy mincí před dokončením výběru.

Jak OP_VAULT dosahuje přerušitelných časově omezených výběrů?

Zjednodušeně řečeno, opkód OP_VAULT nahradí použitý skript OP_VAULT zadaným skriptem, čímž aktualizuje jeden listový uzel v MAST a zbytek zůstane nezměněn. Jedná se o obdobu TLUV, ale bez podpory aktualizace vnitřního klíče.

Zavedení šablony během aktualizace skriptu může omezit účinky plateb. Parametr časového zámku je specifikován OP_VAULT, zatímco šablona vnesená opkódem CTV omezuje množinu výstupů vynaložených prostřednictvím této cesty skriptu.

BIP-345 je určen pro trezory, které uživatelům umožňují vysoce bezpečnou cestu zpětného získávání (papírová peněženka, distribuovaný vícepodpis) a zároveň konfiguraci zpoždění výdajů pro běžné platby. Zařízení uživatele nepřetržitě monitoruje výdaje trezoru a umožňuje obnovu, pokud dojde k neoprávněnému převodu.

Zavedení trezorů s BIP-345 vyžaduje zvážení problematiky poplatků, zejména u transakcí vymáhání. Mezi možná řešení patří CPFP (Child Pays for Parent), dočasné kotvy a nové příznaky hashování podpisů, jako je SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

Schéma TLUV je postaveno na systému Taproot a jeho cílem je vyřešit problém efektivního výstupu ze sdílených UTXO. Hlavní princip spočívá v tom, že když je výstup z Taprootu utracen, můžeme použít vnitřní strukturu adresy Taprootu a kryptografické transformace k částečné aktualizaci vnitřního klíče a MAST podle aktualizačních kroků popsaných skriptem TLUV, čímž dosáhneme funkčnosti smlouvy.

Myšlenkou schématu TLUV je vytvoření nové adresy Taproot na základě aktuálního vstupu výdajů prostřednictvím nového opkódu TAPLEAF_UPDATE_VERIFY, který může provádět jednu nebo více z následujících operací:

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

  1. Specifikace způsobu aktualizace interního veřejného klíče
  2. Nový listový uzel Merklovy cesty
  3. Specifikace, zda má být odstraněn aktuální listový uzel a/nebo kolik listových uzlů Merklovy cesty má být odstraněno.

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

Inspirací pro TLUV jsou mincovní pooly. Dnes lze společné pooly vytvářet pomocí předem podepsaných transakcí, ale pokud chcete dosáhnout výstupů bez povolení, musíte vytvořit exponenciálně rostoucí počet podpisů. TLUV umožňuje permissionless exity bez jakýchkoli předem podepsaných transakcí. Například skupina partnerů používá Taproot k vytvoření společného UTXO a sdružuje své prostředky. Mohou přesouvat prostředky interně pomocí klíče Taproot nebo společně podepisovat externí platby. Jednotlivci mohou ze sdíleného fondu kdykoli vystoupit, čímž odstraní svou platební cestu, zatímco ostatní mohou pokračovat v provádění plateb původní cestou, aniž by došlo k odhalení dalších informací o zbývajících členech. Tato metoda je ve srovnání s transakcemi bez sdružování efektivnější a soukromější.

Opční kód TLUV dosahuje částečného omezení výdajů aktualizací původního MAST. Nedosahuje však introspekce výstupních částek. Proto je zapotřebí nový opkód IN_OUT_AMOUNT, který na zásobník strčí dva údaje: částku UTXO tohoto vstupu a odpovídající výstupní částku. Od osoby používající TLUV se pak očekává, že pomocí matematických operátorů ověří, zda jsou prostředky správně zachovány v aktualizovaném skriptPubKey.

Introspekce výstupních částek přidává další složitost, protože částky bitcoinů jsou reprezentovány v satoši a vyžadují až 51 bitů, ale skripty umožňují pouze 32bitové matematické operace. To vyžaduje vylepšení operátorů ve skriptu předefinováním chování opkódů nebo použitím SIGHASH_GROUP, který nahradí IN_OUT_AMOUNT.

Očekává se, že TLUV poskytne řešení pro decentralizované pooly mincí 2. vrstvy, ačkoli spolehlivost, pokud jde o úpravu veřejných klíčů Taproot, je třeba dále potvrdit.

MATT

MATT (Merkleize All The Things) si klade tři cíle: Merkleizovat stav, merkleizovat skripty a merkleizovat provádění, a tím dosáhnout obecných chytrých kontraktů.

Aby bylo možné dosáhnout MATT, musí mít skripty pro programování bitcoinů následující funkce:

  1. Vynucení určitého skriptu na výstupu (a jejich množství)
  2. Připojení dat k výstupu
  3. Čtení dat z aktuálního vstupu (nebo jiných vstupů)

Druhý bod je klíčový, protože dynamická data umožňují výpočet stavu prostřednictvím vstupních dat poskytnutých zadavatelem, simulují stavový stroj a rozhodují o dalším stavu a připojených datech. MATT navrhuje opkód OP_CHECKCONTRACTVERIFY (OP_CCV), který je kombinací dříve navržených opkódů OP_CHECKOUTPUTCONTRACTVERIFY a OP_CHECKINPUTCONTRACTVERIFY s dodatečným parametrem flags pro určení cíle operace.

Kontrola množství výstupů: Nejpřímější způsob je přímá introspekce. Výstupní částky jsou však 64bitová čísla vyžadující 64bitové operace, což zvyšuje složitost implementace bitcoinového skriptu. CCV přijímá zpožděnou kontrolu podobnou kontrole OP_VAULT, která sčítá vstupní částky pro všechny vstupy na stejný výstup s CCV jako dolní hranicí této výstupní částky. Kontrola je zpožděna až do procesu transakce namísto během vyhodnocování vstupního skriptu.

Vzhledem k obecnosti důkazů podvodu by některé varianty smluv MATT měly dosáhnout všech typů inteligentních smluv nebo konstrukcí vrstvy 2, ačkoli je třeba přesně vyhodnotit další požadavky (jako je uzamčení kapitálu a zpoždění doby výzvy). K vyhodnocení toho, které aplikace jsou přijatelnými transakcemi, je zapotřebí dalšího výzkumu. Například použití kryptografických závazků a mechanismů podvodných výzev k simulaci funkcí OP_ZK_VERIFY, dosažení bezdůvěryhodných Rollupů na Bitcoinu.

V praxi se to již děje. Johan Torås Halseth implementoval elftrace pomocí opkódu OP_CHECKCONTRACTVERIFY z návrhu soft forku MATT, který umožňuje ověřit všechny programy podporované kompilací RISC-V v řetězci Bitcoin, což umožňuje nativní mosty pro ověřování smluvních protokolů Bitcoin.

CSFS (OP_CHECKSIGFROMSTACK)

Z úvodu opkódu APO víme, že OP_CHECKSIG (a související operace) je zodpovědný za sestavování transakcí, hashování a ověřování podpisu. Zpráva, kterou ověřuje, je však odvozena ze serializace transakcí pomocí tohoto opkódu, což neumožňuje specifikovat jiné zprávy. Zjednodušeně řečeno, OP_CHECKSIG (a související operace) slouží k ověření, že UTXO jako vstup transakce je oprávněn utratit držitel podpisu, čímž chrání bezpečnost Bitcoinu.

Systém CSFS, jak již jeho název napovídá, kontroluje podpisy ze zásobníku. Opční kód CSFS přebírá ze zásobníku tři parametry: podpis, zprávu a veřejný klíč a ověřuje platnost podpisu. To znamená, že jakoukoli zprávu lze předat zásobníku prostřednictvím svědeckých dat a ověřit ji pomocí CSFS, což umožňuje některé inovace v Bitcoinu.

Flexibilita systému CSFS mu umožňuje implementovat různé mechanismy, jako jsou podpisy plateb, delegování pravomocí, smlouvy oracle a dluhopisy na ochranu proti dvojímu utracení, a co je důležitější, introspekci transakcí. Princip introspekce transakcí pomocí systému CSFS je velmi jednoduchý. Pokud je obsah transakce, kterou používá OP_CHECKSIG, posunut na zásobník prostřednictvím svědka a k ověření pomocí CSFS i OP_CHECKSIG je použit stejný veřejný klíč a podpis, pokud obě projdou, pak je obsah jakékoli zprávy předané CSFS stejný jako serializovaná výdajová transakce (a další data), kterou implicitně používá OP_CHECKSIG. Na zásobníku pak získáme ověřená data transakce, která lze použít k uplatnění omezení na transakci výdajů pomocí dalších opcodes.

CSFS se často objevuje s OP_CAT, protože OP_CAT může spojovat různá pole transakce pro dokončení serializace, což umožňuje přesnější výběr polí transakce pro introspekci. Bez OP_CAT nemůže skript přepočítávat hashe z individuálně kontrolovatelných dat, takže může kontrolovat pouze to, zda hash odpovídá konkrétní hodnotě, což znamená, že mince lze utratit pouze prostřednictvím jedné konkrétní transakce.

CSFS může dosáhnout opkódů jako CLTV, CSV, CTV, APO a je obecným introspekčním opkódem, čímž také pomáhá řešením škálování na 2. vrstvě pro Bitcoin. Jeho nevýhodou je, že vyžaduje přidání kompletní kopie podepsané transakce do zásobníku, což může výrazně zvýšit velikost transakcí, které chtějí CSFS pro introspekci použít. Naproti tomu jednoúčelové opkódy introspekce, jako jsou CLTV a CSV, mají nejmenší režii, ale přidání každého nového speciálního opkódu introspekce vyžaduje změny konsensu.

TXHASH (OP_TXHASH)

OP_TXHASH je velmi jednoduchý introspekční opkód, který umožňuje operátorovi vybrat hash pole a odeslat jej na zásobník. Konkrétně OP_TXHASH vyskočí ze zásobníku příznak txhash, vypočítá (označený) txhash na základě příznaku a výsledný hash vloží na zásobník.

Vzhledem k podobnosti mezi TXHASH a CTV se o nich v komunitě vedou rozsáhlé diskuse.

TXHASH lze považovat za obecný upgrade CTV, který poskytuje pokročilejší šablonu transakce, jež umožňuje uživatelům specifikovat části výdajové transakce a řeší mnoho problémů souvisejících s transakčními poplatky. Na rozdíl od jiných opkódů smluv nevyžaduje TXHASH poskytnutí kopie potřebných dat ve svědkovi, což dále snižuje potřeby úložiště. Na rozdíl od CTV není TXHASH kompatibilní s NOP a může být implementován pouze v tapscriptu. Kombinaci TXHASH a CSFS lze považovat za alternativu k CTV a APO.

Pokud jde o konstrukci smluv, TXHASH je snazší dosáhnout „aditivních smluv“ tak, že všechny části dat transakce, které chcete opravit, vložíte na zásobník, zahašujete je dohromady a ověříte, zda výsledek odpovídá pevné hodnotě. CTV je snazší dosáhnout „subtraktivních smluv“ tím, že všechny části transakčních dat, které chcete zachovat volné, posunete na zásobník. Pak pomocí rolling OP_SHA256, počínaje pevným mezistavem, tento mezistav odevzdá prefix hash dat transakce. Volné části jsou zaheslovány do tohoto mezistavu.

Očekává se, že pole TxFieldSelector definované ve specifikaci TXHASH se rozšíří na další opcodes, například OP_TX.

BIP týkající se TXHASH je v současné době na Githubu ve stavu návrhu a zatím mu nebylo přiděleno číslo.

OP_CAT

OP_CAT je poněkud záhadný opcode, který Satoshi Nakamoto z bezpečnostních důvodů zrušil. Nedávno však vyvolal rozsáhlou diskusi mezi vývojáři jádra Bitcoinu a stal se dokonce meme v online komunitě. Nakonec byl OP_CAT schválen jako BIP-347, přičemž mnozí jej označují za nejpravděpodobnější návrh BIP, který v blízké budoucnosti projde.

Ve skutečnosti je chování OP_CAT velmi jednoduché: spojí dva prvky na zásobníku do jednoho. Jak to ale umožňuje funkčnost smlouvy?

Funkce spojování dvou prvků odpovídá výkonné kryptografické datové struktuře známé jako Merkleho trie. Konstrukce Merkleho Trie vyžaduje pouze operace spojování a hašování, které jsou ve skriptech Bitcoinu k dispozici. Pomocí OP_CAT proto můžeme teoreticky ověřovat Merkleho důkazy v bitcoinových skriptech, což je nejběžnější odlehčená metoda ověřování v blockchainech.

Jak již bylo zmíněno, systém CSFS může použít OP_CAT k dosažení obecného smluvního schématu. Ve skutečnosti i bez CSFS umožňuje struktura Schnorrových podpisů samotnému OP_CAT dosáhnout introspekce transakcí.

Při Schnorrově podpisu se podepisovaná zpráva skládá z následujících polí:

Tato pole obsahují hlavní prvky transakce. Jejich umístěním do skriptPubKey nebo witness a použitím OP_CAT a OP_SHA256 můžeme zkonstruovat Schnorrův podpis a ověřit jej pomocí OP_CHECKSIG. Pokud ověření proběhne úspěšně, zásobník uchová ověřená data transakce, což umožní její introspekci. To nám umožňuje extrahovat a „prozkoumat“ různé části transakce, například její vstupy, výstupy, cílové adresy nebo zapojené částky Bitcoinu.

Podrobnější informace o kryptografických principech naleznete v článku Andrewa Poelstry „CAT a Schnorrovy triky“.

Lze shrnout, že díky své flexibilitě je OP_CAT schopen napodobit téměř jakýkoli smluvní opkód a mnoho smluvních opkódů závisí na jeho funkčnosti. To významně posouvá jeho pozici na seznamu slučovacích kódů. Teoreticky bychom mohli pouze s OP_CAT a existujícími bitcoinovými opkódy zkonstruovat BTC ZK Rollup minimalizovaný na důvěryhodnost. Starknet, Chakra a další partneři z ekosystému aktivně pracují na tom, aby se tak stalo.

Závěr

Při zkoumání různých strategií pro rozšíření Bitcoinu a zvýšení jeho programovatelnosti je zřejmé, že cesta vpřed zahrnuje kombinaci nativních vylepšení, výpočtů mimo řetězec a komplexních funkcí skriptů.

Bez pružné základní vrstvy nelze vytvořit pružnější druhou vrstvu.

Budoucnost je ve škálovatelnosti mimo řetězec, ale programovatelnost bitcoinu musí prorazit, aby lépe podporoval škálování a stal se skutečnou světovou měnou.

Výpočet v bitcoinech se však od výpočtu v ethereu zásadně liší. Bitcoin podporuje pouze „verifikaci“ jako formu výpočtu, zatímco Ethereum je v zásadě výpočetní a verifikace je jeho vedlejším produktem. Tento rozdíl je patrný z toho, že Ethereum účtuje poplatky za plyn za neúspěšné transakce, zatímco Bitcoin nikoli.

Smlouvy jsou formou inteligentních smluv založených spíše na ověřování než na výpočtech. Pokud jde o smlouvy, kromě několika přísných Satoshiho fundamentalistů se většina lidí domnívá, že smlouvy jsou dobrou volbou pro zlepšení Bitcoinu. Komunita však neustále diskutuje o tom, jaké schéma pro implementaci kontraktů použít.

APO, OP_VAULT a TLUV se přiklánějí k přímým aplikacím. Jejich volbou lze konkrétní aplikace implementovat levněji a efektivněji. Nadšenci do Lightning Network dávají přednost APO, protože dosahuje LN-Symetrie; pokud chcete vytvořit trezor, je nejlepší použít OP_VAULT; pro vytvoření CoinPool je TLUV soukromější a efektivnější. OP_CAT a TXHASH jsou obecnější, mají méně bezpečnostních zranitelností a kombinací s jinými opcodes lze dosáhnout více případů použití, i když potenciálně za cenu složitosti skriptu. CTV a CSFS upravily přístup ke zpracování blokového řetězce: CTV implementuje zpožděné výstupy a CSFS implementuje zpožděné podpisy. MATT je poměrně unikátní, používá optimistické provádění a důkazy podvodu a spoléhá na strukturu Merkle Trie k dosažení obecných chytrých kontraktů, ačkoli stále vyžaduje nové opcodes k zajištění introspekčních schopností.

Vidíme, že komunita Bitcoinu již intenzivně diskutuje o možnosti zavedení kontraktů prostřednictvím soft forku. Společnost Starknet oficiálně oznámila svůj vstup do ekosystému Bitcoinu a plánuje zavést vypořádání v síti Bitcoin do šesti měsíců od sloučení OP_CAT. Chakra bude i nadále sledovat nejnovější vývoj v ekosystému Bitcoinu, podporovat soft fork merge OP_CAT a využívat programovatelnost, kterou přináší introspekce a kontrakty, k vytvoření bezpečnější a efektivnější vrstvy pro vypořádání Bitcoinu.

Related Articles
↑
Exit mobile version