By Bitcoin Časopis - před 4 měsíci - Doba čtení: 5 minuty
Merkurová vrstva: Masivní vylepšení Statechains
CommerceBlock vychází Merkurová vrstva dnes vylepšená verze jejich variace státního řetězce. Můžete si přečíst delší vysvětlení toho, jak jejich stavové řetězce Merkur fungují zde. Upgrade na Mercury Layer představuje masivní vylepšení oproti původní implementaci stavového řetězce, avšak na rozdíl od původního vydání Mercury Wallet to není zabaleno jako peněženka plně připravená pro spotřebitele. Vydává se jako knihovna a nástroj CLI, který mohou integrovat další peněženky. Zde je rychlé shrnutí toho, jak fungují:
Statechainy jsou v podstatě analogické s platebními kanály v mnoha ohledech, tj. jsou společně sdíleným UTXO s předem podepsanou transakcí jako mechanismem poslední možnosti pro lidi k vynucení svého vlastnictví. Hlavním rozdílem mezi kanálem Lightning a státním řetězcem jsou strany zapojené do společného sdílení UTXO a způsob, jakým se vlastnictví vymahatelného nároku vůči němu převádí na jiné strany.
Na rozdíl od Lightning kanálu, který je vytvořen a sdílen mezi dvěma statickými účastníky, statechain je otevřen facilitátorem/operátorem a lze jej volně přenášet v celém rozsahu mezi libovolnými dvěma účastníky, kteří jsou ochotni důvěřovat operátorovi, že je upřímný, zcela mimo. -řetěz. Někdo, kdo si přeje načíst statechain, spolupracuje s operátorem na vytvoření jediného veřejného klíče, který tvůrce i operátor drží podíl odpovídajícího soukromého klíče, přičemž ani jeden z nich nemá úplnou kopii klíče. Odtud předem podepíší transakci, která umožní tvůrci jednostranně získat zpět své mince po časovém uzamčení.
Při převodu statechainu současný vlastník spolupracuje s příjemcem a operátorem na podepsání kryptografického důkazu se svým sdíleným klíčem, že převádějí coin, a poté příjemce a operátor vygenerují nový pár sdílených klíčů, které se sčítají se stejným soukromým klíčem a podepisují. časově zablokovaná transakce pro nového vlastníka s kratším časovým zámkem než původní (aby bylo zajištěno, že bude moci použít svůj dříve než předchozí vlastníci). Tento proces se opakuje pro každý přenos, dokud časový zámek již nelze zkrátit, v tomto okamžiku musí být stavový řetězec uzavřen na řetězci.
Vlastníci při každém přenosu přenesou celý historický řetězec minulých stavů, aby si uživatelé mohli ověřit, zda byly časové zámky správně sníženy, a operátor je opatří časovými razítky pomocí Hlavní opora, varianta Opentimestamps, kde má každý kus dat svůj vlastní jedinečný „slot“ ve stromu merkle, aby bylo zaručeno, že časovým razítkem bude označena pouze jedna verze dat. Nechte každého auditovat historii převodů státního řetězce.
V Zemi Slepých
Velká změna, kterou Mercury Layer přináší do původní verze statechains, je oslepující. Operátor služby statechain se již nebude moci dozvědět nic o tom, co se přenáší: tj. o TXID, o veřejných klíčích, dokonce ani o podpisech, které ve spolupráci s uživateli vytváří pro předem podepsané transakce nutné pro nárokování zpět. vaše finanční prostředky jednostranně.
Mercury představuje zaslepenou variantu Schnorr MuSig2 a může usnadnit proces podepisování zpětných transakcí, aniž by se dozvěděl jakékoli podrobnosti o tom, co podepisují. To vyžaduje určité konstrukční změny, aby bylo možné zohlednit skutečnost, že operátor již nemůže vidět a zveřejňovat celou historii převodů statechain. Nejsou dokonce schopni vůbec ověřit transakci, kterou podepisují.
V předchozí iteraci byla jedinečnost aktuálního vlastníka/transakční sady statechain potvrzena operátorem zveřejněním celé historie převodů statechainu s Mainstay. To zde není možné, protože v zaslepené verzi se operátor o těchto transakcích nedozví vůbec žádné podrobnosti. To vyžaduje nový způsob, jak provozovatel potvrzovat současné vlastnictví státního řetězce. Všechna tato data jsou plně přenesena do ověřovacího modelu na straně klienta. Operátor jednoduše sleduje, kolikrát něco podepsal pro jeden statechain, a sdělí toto číslo uživateli, když je o to požádán. Uživatel poté obdrží transakce minulých stavů stavového řetězce od uživatele, který mu posílá, a zcela ověří na straně klienta, že počet transakcí odpovídá tomu, co operátor tvrdil, a poté plně ověří, zda jsou všechny podpisy platné a časové zámky sníženy o příslušnou částku. pokaždé. Namísto zveřejnění úplných transakcí stavového řetězce a převodního příkazu na Mainstay, protože je navržen tak, aby neznal všechny tyto informace, zveřejňuje svůj podíl na veřejném klíči (nikoli celý agregovaný veřejný klíč) pro aktuálního uživatele pro každý stavový řetězec. uživatel. To umožňuje každému uživateli, který obdrží statechain, ověřit historii přenosu a aktuální stav je legitimní vůči transakčním datům odeslaným odesílatelem.
Operátorský server sleduje jedinečné stavové řetězce, aby mohl počítat minulé podpisy, a to tak, že každému stavovému řetězci při vytváření přiřadí náhodný identifikátor, uložený s jeho nominální hodnotou a sdíleným soukromým klíčem a veřejným klíčem (nikoli celý souhrnný veřejný klíč). Nové koordinační schéma pro sdílení a opětovné sdílení klíče se provádí způsobem, kdy server předá svůj podíl klíče uživateli a data potřebná pro nové sdílení jsou zaslepena, takže server není schopen se nikdy dozvědět o uživateli celý sdílení veřejného klíče, což umožňuje vytvořit úplný souhrnný veřejný klíč a identifikovat coin v řetězci.
Design ani neumožňuje operátorovi vědět, kdy podepsal uzavření spolupráce se současným vlastníkem, spíše než předem podepsanou transakci pro nového off-chain vlastníka; nevidí žádné podrobnosti, které by tyto dva případy od sebe odlišily. To je však bezpečné pro uživatele, kteří by mohli být napadeni někým, kdo se pokouší „zdvojnásobit“ státní řetězec mimo řetězec poskytující falešnou transakci, kterou nebylo možné vypořádat. Za prvé, tento uživatel by v řetězci viděl, že UTXO podporující tento statechain bylo utraceno. Za druhé, transakční historie, protože operátor musí podepsat všechny aktualizace stavu, by měla pouze jasné uzavření spolupráce v řetězci minulých transakcí. Obě tyto věci by uživateli umožnily odmítnout transakci s vědomím, že není legitimní.
Statechains také umožňují, aby kanály Lightning byly „umístěny na vrchol“ statechainu tím, že statechain vyplácí na multisig adresu mezi dvěma lidmi a tito dva navíc vyjednávají konvenční sadu Lightning závazkových transakcí. Před uzavřením kanálu Lightning by bylo nutné uzavřít statechain on-chain, takže by bylo nutné použít delší časové bloky pro platby Lightning, ale jinéwise bude fungovat naprosto normálně.
Celkově s masivními vylepšeními ochrany soukromí v nové iteraci statechainů a složitelností s Lightning to otevírá mnoho dveří pro ekonomickou životaschopnost a flexibilitu transakčních mechanismů druhé vrstvy na Bitcoin. Zejména ve světle nedávných radikálních změn v dynamice mempoolu az toho vyplývajícího tlaku na poplatky.
Nabízí stejný typ výhod likvidity jako Ark, tedy možnost být volně převoditelný bez nutnosti přijímat likviditu, ale na rozdíl od Ark je dnes živý a funkční. Je to nepopiratelně odlišný model důvěry než něco jako samotný Lightning, ale pro obrovské zisky v oblasti flexibility a škálovatelnosti je to rozhodně možnost prozkoumat.
Původní zdroj: Bitcoin Časopis