A Taproot a Bitcoinhoz érkezik: Hogyan működik, története és következményei

A Taproot és a Schnorr aláírások a Bitcoinon 709,632 XNUMX blokknál jelennek meg. Ez egy hatalmas alapvető eredmény, amelyre a jövőben is építeni lehet. Négy év telt el azóta, hogy a Segregated Witness felkerült a hálózatra, ami az utolsó jelentős protokollfrissítésünk. Ez olyan hosszú, mint egy felezési ciklus!

Gondolkozzon el rajta. Négy év a SegWit élő adásától a Taproot élő adásáig. Lassú, módszeres türelem, ahogy kell. De Taproot/Schnorr története ennél sokkal régebbre nyúlik vissza.

A Taproot története

Néhányan, akik már itt vannak, ironikusnak találhatják ezt, de a Schnorr-aláírások első említése, amiről tudom, valójában az egykori Bitcoin Core fejlesztőtől, akiből lett vállalati blokklánc-építő, Mike Hearn. 2012-ben ő felhozta egy új kriptográfiai görbe ötlete az aláírások kötegelt ellenőrzésével kapcsolatban, hogy a csomópont-ellenőrzés számítási szempontból kevésbé költséges legyen. Végül az általa javasolt rendszer Schnorr aláírásaitól függött.

Adam Back naivitásról beszélt rendszerek olyan multisig címeket készíteni, amelyek 2014-ben úgy néztek ki, mint egy singlesig címek, Schnorr aláírások felhasználásával. Még Gavin Andresen is benne van Schnorr az ECDSA helyett azon változtatások kívánságlistáján, amelyeket a Bitcoinon végrehajtana, ha varázspálcát lengethetne.

A Bitcoin kezdete óta a legtöbb Bitcoin Core-ban aktívan részt vevő fejlesztő Schnorr-aláírásokat akart, és mindig is elég szilárd konszenzus alakult ki az ECDSA aláírásokkal szembeni fölényükről. Valójában vitatható, hogy az ECDSA-t kifejezetten azért hozták létre, mert a Schnorr aláírási sémát szabadalmaztatták, és óriási szükség volt egy nyílt forráskódú, szabadalmak által nem terhelt kriptográfiai aláírási rendszerre.

A Schnorr sokkal hatékonyabb és könnyebben manipulálható (az aláírásokból összeadhatók, kivonhatók stb., és ha jól csinálják, akkor is érvényes aláírásokat hagyhat a felhasználóknak, amikor kell), mint az ECDSA. Az ECDSA használata az évek során a legtöbb kriptográfiai alkalmazásban inkább szükségszerűség, mint vágy volt.

A Merkelized Abstract Syntax Trees (MAST), a Taproot fele a közelgő Taproot frissítésnek, hasonló hosszú múltra tekint vissza. Nem találom az idézetet, de teljesen tisztán emlékszem, hogy láttam ezt a kifejezést, amit Peter Toddhoz hasonlók dobtak fel a Bitcointalk.org-on 2013 vagy 2014 körül.

Az eredeti BIP a MAST-hoz Johnson Lau javasolta 2016-ban. Ez a javaslat 2017 körül is élénkült, amikor Mark Friedenbach, BTCDrak és Kalle Alm két külön határállomásra bontotta (116 és a 117), és kiterjesztette Lau eredeti javaslatát.

A MAST bizonytalanságban ült a következő évben, amíg Greg Maxwell elő nem állt a kezdeti Taproot ötlettel, és közzétett a bitcoin-dev levelezőlistára. Legfontosabb meglátása az volt, hogy minden olyan szerződéses ügyben, amelyre több résztvevő között gondolt, létezik egy „optimális eredmény”, amikor a szerződést úgy lehetett rendezni, hogy mindenki csak aláírja a megfelelő eredményt, ahelyett, hogy fejlettebb szkriptekkel és tranzakciókkal kényszerítené ki az eredményt. Ez az az alapvető állítás, amelyen a Taproot alapul, azaz a MAST-fát egy normál legfelső szintű kulcsra kell állítani, amely anélkül költhető el, hogy kiderülne, létezik-e más költési feltételek Merkle-fája.

Ennek a történelemórának az utolsó kis szakasza Pieter Wiulle bejelentésével kezdődik határállomások tervezete Schnorrnak és Taprootnak a levelezőlistán együtt 6. május 2019-án. 2020 januárjára ezt hivatalosan is véglegesítették BIP 340, 341 és 342. Innentől kezdve csak sok apró részlet finomítás volt a megvalósítás szintjén, némi felülvizsgálati időszak, majd a hosszan elhúzódó harc az aktiválási mechanizmusokért. Ez most elvezet minket, csak félünk az aktiválástól.

A Schnorr-aláírások jelentősége

Szóval, mi a nagy baj a Schnorr aláírásokkal? Nos, kezdésként kisebbre csökkentik a tranzakciókat. Egy ECDSA-aláírás általában körülbelül 72 bájt méretű egy tranzakció egyetlen aláírásához. A Schnorr aláírások aláírásonként maximum 64 bájtot érnek el. Ez nagyjából 12%-os méretmegtakarítást jelent az ECDSA-hoz képest minden Schnorr aláírás esetén. Ez egyrészt közvetlen előny a Schnorr-t használó személy számára, aki kevesebb díjat fizet, mint egy ECDSA-felhasználó, de közvetlen előny azoknak is, akik nem használják a Schnorrt, mivel valamivel kevesebb adatot kell tárolni a blokkláncban valaki más Schnorr-jának feldolgozásához és érvényesítéséhez. aláírásokat.

Kevesebb adat tárolása mindig jó, de ami még jobb, ha növeli a tárolandó adatok érvényesítésének hatékonyságát. A Schnorr egyik szép tulajdonsága, a mögötte álló matematikai linearitás, egyben egy szép tulajdonságot is lehetővé tesz a Bitcoin adatokban: a kötegelt érvényesítést. Amikor a csomópont blokkot kap a hálózattól, minden egyes tranzakciót elemzi, és egyenként érvényesíti az egyes aláírásokat.

Ez nagyban hozzájárul ahhoz, hogy a blokkok érvényesítése miért fogyaszt sok processzort. A Schnorr-aláírások mind kötegbe rakhatók, és matematikailag egyszerre érvényesíthetők, mintegy összetörve, és egyetlen matematikai műveletet hajtanak végre egy csomó különálló helyett. Tehát minél több Schnorr aláírás van, annál nagyobb a számítási megtakarítás. Ez hatalmas skálázási nyereség a hálózat számára.

A Schnorr másik jelentős fejlesztése a többaláírású szkriptek. Minden multisig címnek explicit módon fel kell fednie a multisig szkriptben szereplő összes nyilvános kulcsot a ráfordítási idő alatt, és aláírást kell adni minden, a költési folyamatban részt vevő kulcshoz. A Schnorr matematikai tulajdonságainak köszönhetően megnyílik az ajtó a MuSig, egy multisignature szabvány előtt. Csak összeadhatja a kulcsokat, és egyetlen nyilvános kulccsal zárhatja le, amelyet mindenki magánkulcs-megosztása aláírhat új aláírási protokollok használatával. Jonas Nick a Blockstream-től összehasonlított A MuSig2 két percet vesz igénybe egymillió résztvevők egy multisig címet aláírni. A többaláírású szkriptek skálázási javulását nem lehet alábecsülni.

Ez a hatalmas ugrás a többaláírású szkriptek terén nagy hatással van a Bitcoinra épülő számos alkalmazás adatvédelmi profiljára és költségeire is. A MuSig-alapú Lightning csatornák mostantól beleolvadhatnak a láncon lévő Schnorr/Taproot UTXO-k teljes anonimitási készletébe, mert többé senki sem fogja tudni megkülönböztetni, hogy ezek egy-két multisig kimenet.

Egybeolvadnak, és úgy néznek ki, mint egy aláírás szkript. Ugyanez vonatkozik minden multisig UTXO-ra általában. Ez számos hatással lesz azokra az emberekre, akik többaláírású szkripteket használnak, hogy jobban megvédjék hidegtárhelyüket egy robusztusabb biztonsági és helyreállítási modellel, mint egy aláírási szkript.

Először is, nem lesz nyilvánvaló, hogy a blokkláncot figyelve multisig beállítást használnak, így ez, mint a Lightning esetében, minden mással összeolvad. Egy kulcsfontosságú nyeremény azonban a gazdaságosság szempontjából: a több aláírás használatához jelenleg külön aláírásra van szükség minden kulcshoz, amely az UTXO végső elköltéséhez kapcsolódik. A Schnorr/MuSig segítségével a dolgokat egyetlen aláírásba tömörítik az egyetlen kombinált nyilvános kulcshoz, ami azt jelenti, hogy a MuSig használatával a multisig UTXO-k költése sokkal olcsóbb lesz, mivel kevesebb adatot továbbít a blokkláncba.

Az utolsó nagyszerű dolog, amit a Schnorr aláírások tesznek, az az, hogy drasztikusan leegyszerűsítik az adapter-aláírások megvalósítását. Gondoljon egy olyan adapter-aláírásra, amelyet egy érvényes aláíráshoz hozzáadott vagy abból kivont érték „titkosított”. Nem érvényes mindaddig, amíg meg nem fordítja a matematikai műveletet, vagy „dekódolja” azzal a „kulccsal”, amellyel manipulálta. Ez lehetséges az ECDSA-val, de mivel a matematika nem lineáris a Schnorrhoz képest, ez viszonylag bonyolult, és sok biztonsági szempontot kell figyelembe venni a megvalósítás során.

A Schnorr lineáris tulajdonságai miatt azonban az illesztőaláírás olyan egyszerű, mint egy egyes (mondjuk a 9,300,030 30 XNUMX szám) kivonása és egy érték kivonása belőle (mondjuk XNUMX). Miután az illesztőaláírást birtokló fél megtanulta a kivont értéket, egyszerűen hozzáadhatja azt íme, ismét érvényes aláírásuk van.

A Taproot következményei

Ahogy fentebb már szó volt róla, a Taproot a valóságban lényegében csak MAST, csak ahelyett, hogy úgy működne, mint a P2SH (ahol kivonatolja a szkriptet, vagy MAST esetében a szkriptfa tetejének Merkle-gyökérét), hanem egy Schnorr nyilvános kulcs a Merkle-fa gyökerénél.

A módosítás a Schnorr lineáris tulajdonságai miatt működik – amikor egy nyilvános kulcsot Merkle gyökérrel „beállít” (hozzáadja ezt a Merkle gyökeret a nyilvános kulcshoz), akkor egyszerűen hozzáadhatja a Merkle gyökerét az eredeti privát kulcshoz, és előállíthatja a költési kulcsot az új módosított nyilvános kulcs. Vagyis ugyanazt adjuk hozzá mind a nyilvános, mind a privát kulcshoz, és ezek továbbra is érvényes kulcspárok. Ez elrejti a MAST-fa létezését, hacsak nem egy ágat használunk, de alapvetően ez még mindig csak egy MAST-fa, csak egy hatékonyabb és privát módon elkötelezett.

Az a képesség, hogy elkötelezzük magunkat a Merkle-fában a különböző kiadási szkriptek mellett, és csak a használt szkriptet fedjük fel, hatalmas skálázhatósági győzelem az intelligens szerződések összetettsége szempontjából, amely Bitcoinra építhető.

Csakúgy, mint ahogy a blokkméret korlátozza a blokkonkénti tranzakciók számát, a tranzakcióméret korlátozása 100 kilobájt. Az egyetlen különbség az, hogy ahelyett, hogy konszenzusos szabály lenne, ez egy politikai szabály. Ez azt jelenti, hogy egy bányász bányászhat 100 kilobájtnál nagyobb tranzakciót, de alapértelmezés szerint a hálózaton senki sem közvetít ennél nagyobb tranzakciót a bányásznak.

Ez eredendően korlátozza a Bitcoin UTXO zárolásához használt szkript méretét. Még a P2SH esetén is, ahol az UTXO a szkript kivonatához van zárva, amely nem derül ki addig, amíg el nem költi, végül mégis fel kell fednie a teljes szkriptet az eltöltött idő alatt. A Taproot növeli a szkript méretezhetőségi korlátját azáltal, hogy nem követeli meg a teljes szkript felfedését, amikor azt használja. Ahelyett, hogy az UTXO elköltésének összes módja a tranzakciós méretkorlátra korlátozódna, csak arról kell gondoskodnia, hogy a Taproot UTXO elköltésének bármely módja tiszteletben tartsa ezt a korlátozást.

A Taproothoz számos adatvédelmi előny is társul. A MAST fa egyik nagy előnye, hogy mindenféle feltételes helyzetet képes létrehozni, ahol más felek elkölthetik az érméket.

Képzeljen el olyan dolgokat, mint például az öröklési rendszerek, ahol körülbelül egy év múlva a gyermekei elkölthetik az Ön érméit, vagy ha nem hajlandó aláírni, a felesége és egy ügyvédje lehetőséget kap az érmék visszaszerzésére. Ezekről a kiadási feltételekről semmit nem árulnak el a nyilvánosság számára, hacsak nem használják fel őket. Ez a kettős folyamat elfogadható cáfolatokat biztosít az Ön által kialakított különböző kiadási ágakban érintett többi felek számára az adott UTXO-ban való részvételüket illetően, valamint megvédi őket egy tolvajtól vagy támadótól, aki előre megtámadja őket, tudván, hogy bizonyos fokú ellenőrzést gyakorolnak a pénzük felett. célpont UTXO-jait.

Technikai szinten a Taproot is viszonylag jól megtervezett. Aki olvassa, aki bármilyen mélységben ismeri a szegregált tanút, annak ismernie kell a tanús verziót.

A Segregated Witness bevezetésekor létrehozta a tranzakció új „tanú” szakaszát, ahová az aláírási adatokat áthelyezték. A Witness adatok verziójelzővel rendelkeztek, így új funkciókra frissíthetőek voltak anélkül, hogy az alaprétegen lévő meghatározatlan OP_CODE-okat kellett volna felhasználni az új funkciókhoz.

A Taproot/Schnorr valójában így valósult meg. A szegregált Tanú-tranzakciók a tanú nulla verzióját használják. Amikor a Taproot/Schnorr hamarosan élesben indul, az új tanús verziót fogják használni, hogy megkülönböztessék őket a régebbi elkülönített tanús tranzakcióktól. Ugyanúgy, ahogy a SegWit bevezette a tanús verziókat, a Taproot bevezeti a „tapleaf verziót” a Taprootot használó UTXO-k MAST-fáiban használt tapscriptekhez. Ez nem csak azt teszi lehetővé, hogy a MAST-ba temetett szkriptek az alaprétegen lévő új OP_CODE-ok használata nélkül frissítsenek, hanem a tanúverziók frissítése nélkül is! Tehát a Taprootot úgy tervezték meg, hogy a lehető leghatékonyabb legyen a jövőbeni frissítéshez anélkül, hogy a protokoll egyéb, nem kapcsolódó frissítéseit korlátozná.

A Taproot számos különféle felhasználási esetet hoz. Először is, a Lightning csatornában lévő összes nem együttműködő kitétel, mint például a büntetőkulcsok vagy a használatukat lehetővé tevő időzárak, a Taproot-tal ellátott MAST alá temethetők. Soha senki nem fogja megtudni, hogy léteznek, hacsak nem kell őket használni, ami még jobban elfedi, hogy mely UTXO-k valójában Lightning csatornák vagy sem.

Az öröklési sémák egy másik felhasználási eset. Képzeljen el egy Taproot fát, amely úgy van felszerelve, hogy hat hónapig, amikor nem mozgatja a pénzét, az egész család összejöhet, és úgy költheti az UTXO-t, ahogy akarja. Aztán hat hónappal később egy fő leszámítva mindenki elköltheti (tehát képzelje el, ha a felesége, két gyereke és a szülei a kulcstartók, akkor képzelje el, hogy a hat hónap elteltével a felesége, egy gyereke és a szülei aláírhatják , vagy a két gyereke és a szülei aláírhatják a felesége nélkül, és így tovább).

Aztán hat hónappal ezután mindenki mínusz két ember elköltheti. Végül előfordulhat, hogy egy ügyvéd segítségével egyetlen személy tudja elkölteni az UTXO-t (hogy ne történjen semmiféle gagyi).

Vagy mi van akkor, ha multisig-et használ a hűtőkamra biztonságára, de csak egyetlen helye van, amelyet hosszú távon biztonságosnak és kiszámíthatónak tart? Létrehozhat egy MAST-ot, ahol végül néhány év elteltével a biztonságos helyen lévő kulcs egyedül költheti el ezeket az érméket, arra az esetre, ha más kulcsok elvesztek vagy megsemmisülnének, de anélkül, hogy az érméit azonnal ellopnák. az egyik kulcs veszélybe került.

Ez egy csodálatos és átfogó frissítés a Bitcoinhoz, amely vitathatatlanul szinte maga a Bitcoin születése óta folyik, nem csak az elmúlt néhány évben, amikor a tényleges megvalósítás részleteit kidolgozták és végrehajtották.

Ez valóban olyan sok szempontból győzelem a Bitcoin-protokoll méretezhetősége és hasznossága szempontjából, hogy nehéz kifejezni, mert egyesek finomak és „nem szexisek”. De ez mit sem von le a győzelemből. Szóval mindenki csattogjon és készüljön az új játékokkal, amiket hamarosan használnunk kell, mert jön a Taproot!

Ez Shinobi vendégbejegyzése. A kifejtett vélemények teljes mértékben saját véleményük, és nem feltétlenül tükrözik a BTC Inc. vagy a Bitcoin Magazine.

Forrás: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer