Taproot komt naar Bitcoin: hoe het werkt, zijn geschiedenis en implicaties

De handtekeningen van Taproot en Schnorr gaan live op Bitcoin bij blok 709,632. Dit wordt een enorme fundamentele prestatie waar we in de toekomst op kunnen voortbouwen. Het is vier jaar geleden dat Segregated Witness live ging op het netwerk, onze laatste grote protocolupgrade. Dat is net zo lang als een halveringscyclus!

Denk daar eens over na. Vier jaar vanaf de livegang van SegWit tot de livegang van Taproot. Langzaam, methodisch geduld, zoals het hoort. Maar de geschiedenis van Taproot/Schnorr gaat veel verder terug dan dat.

De geschiedenis van penwortel

Sommigen die hier al een tijdje zijn, vinden dit misschien ironisch, maar de eerste vermelding van Schnorr-handtekeningen waar ik me van bewust ben, was eigenlijk van de voormalige Bitcoin Core-ontwikkelaar die zakelijke blockchain-bouwer Mike Hearn werd. In 2012 heeft hij opgevoed het idee van een nieuwe cryptografische curve met betrekking tot de batchverificatie van handtekeningen om knooppuntvalidatie rekenkundig minder duur te maken. Uiteindelijk was het plan dat hij voorstelde afhankelijk van de handtekeningen van Schnorr.

Adam Back had het over naïef regelingen om multisig-adressen te maken die eruitzagen als singlesig-adressen in 2014, met behulp van Schnorr-handtekeningen. Zelfs Gavin Andresen was erbij Schnorr in plaats van ECDSA op zijn verlanglijstje met veranderingen die hij in Bitcoin zou aanbrengen als hij met een toverstaf kon zwaaien.

Sinds vrijwel het allereerste begin van Bitcoin hebben de meeste ontwikkelaars die actief betrokken zijn bij Bitcoin Core Schnorr-handtekeningen gewild, en er is altijd een behoorlijk solide consensus geweest over hun superioriteit ten opzichte van ECDSA-handtekeningen. Je zou in feite kunnen stellen dat ECDSA specifiek in het leven is geroepen omdat het Schnorr-handtekeningenschema gepatenteerd was, en er een enorme behoefte bestond aan een open-source cryptografisch handtekeningschema dat niet gehinderd werd door patenten.

Schnorr is veel efficiënter en gemakkelijker te manipuleren (dingen kunnen worden toegevoegd, afgetrokken, enz. Van handtekeningen, en als het correct wordt gedaan, kunnen gebruikers nog steeds geldige handtekeningen achterlaten wanneer ze die zouden moeten hebben) dan ECDSA. Het gebruik van ECDSA was in de meeste cryptografische toepassingen door de jaren heen eerder een kwestie van noodzaak dan van wens.

Merkelized Abstract Syntax Trees (MAST), de Taproot-helft van deze komende Taproot-upgrade, heeft een vergelijkbare lange geschiedenis. Ik kan het citaat niet vinden, maar ik herinner me heel duidelijk dat ik die zin rond 2013 of 2014 rond XNUMX of XNUMX zag rondgegooid door mensen als Peter Todd op Bitcointalk.org.

De oorspronkelijke BIP voor MAST werd in 2016 voorgesteld door Johnson Lau. Dit voorstel kende ook enige activiteit rond 2017 toen Mark Friedenbach, BTCDrak en Kalle Alm het opsplitsten in twee afzonderlijke BIP's (116 en 117) en breidde het oorspronkelijke voorstel van Lau uit.

MAST zat het komende jaar een beetje in het ongewisse totdat Greg Maxwell met het oorspronkelijke Taproot-idee op de proppen kwam gepubliceerde naar de bitcoin-dev mailinglijst. Zijn belangrijkste inzicht was dat in elk contractgeval tussen meerdere deelnemers dat hij kon bedenken, er een ‘optimale uitkomst’ was waarbij het contract kon worden afgehandeld doordat iedereen gewoon de juiste uitkomst ondertekende, in plaats van de uitkomst af te dwingen met geavanceerdere scripts en transacties. Dit is de fundamentele bewering waarop Taproot is gebaseerd, dat wil zeggen het aanpassen van de MAST-boom tot een reguliere sleutel op het hoogste niveau die kan worden uitgegeven zonder te onthullen of er überhaupt een Merkle-boom met andere bestedingsvoorwaarden bestaat.

Het laatste stukje van deze geschiedenisles begint met de aankondiging van Pieter Wiulle ontwerp-BIP's voor Schnorr en Taproot, samen met de mailinglijst op 6 mei 2019. In januari 2020 werd dit formeel afgerond in GIP's 340, 341 en 342. Vanaf dit punt was het slechts een kwestie van veel kleine details verfijnen op implementatieniveau, een periode van evaluatie, en dan de langgerekte strijd om activeringsmechanismen. Dat leidt ons naar nu, gewoon verlegen voor activering.

Het belang van Schnorr-handtekeningen

Dus, wat is het probleem met de handtekeningen van Schnorr? Om te beginnen maken ze transacties kleiner. Een ECDSA-handtekening is doorgaans ongeveer 72 bytes groot voor een enkele handtekening in een transactie. Schnorr-handtekeningen klokken in op maximaal 64 bytes per handtekening. Dat is een besparing van ongeveer 12% vergeleken met ECDSA voor elke Schnorr-handtekening. Dit is zowel een direct voordeel voor de persoon die Schnorr gebruikt, die minder aan kosten zal betalen dan een ECDSA-gebruiker, maar het is ook een direct voordeel voor mensen die Schnorr niet gebruiken, omdat er iets minder gegevens in de blockchain moeten worden opgeslagen om de Schnorr van iemand anders te verwerken en te valideren. handtekeningen.

Minder gegevens opslaan is altijd goed, maar nog beter is het verhogen van de efficiëntie van het valideren van de gegevens die u moet opslaan. Een van de mooie eigenschappen van Schnorr, de lineariteit van de wiskunde erachter, zorgt ook voor een mooie eigenschap die je in Bitcoin-gegevens wilt: batchvalidatie. Wanneer uw knooppunt een blok van het netwerk ontvangt, analyseert het elke afzonderlijke transactie en valideert elke handtekening één voor één.

Dit is een groot deel van de reden waarom het valideren van blokken veel CPU-kracht verbruikt. Schnorr-handtekeningen kunnen allemaal in een batch worden samengevoegd en wiskundig in één keer worden gevalideerd, alsof je ze samenvoegt en één wiskundige bewerking uitvoert in plaats van een aantal afzonderlijke. Dus hoe meer Schnorr-handtekeningen er zijn, hoe groter de rekenbesparingen. Dit is een enorme schaalwinst voor het netwerk.

Een andere enorme verbetering die Schnorr met zich meebrengt, betreft scripts met meerdere handtekeningen. Elk multisig-adres moet tijdens het besteden van tijd expliciet alle individuele openbare sleutels onthullen die betrokken zijn bij een multisig-script, en er moet een handtekening worden verstrekt voor elke sleutel die betrokken is bij het bestedingsproces. Met de wiskundige eigenschappen van Schnorr gaat de deur open voor MuSig, een standaard met meerdere handtekeningen. Je kunt gewoon sleutels bij elkaar voegen en eindigen met één enkele openbare sleutel waarvoor de gedeelde privésleutels van iedereen kunnen ondertekenen met behulp van nieuwe handtekeningprotocollen. Jonas Nick van Blockstream gebenchmarkt MuSig2 heeft er twee minuten voor nodig een miljoen deelnemers aan een multisig-adres om te ondertekenen. De schaalverbetering van scripts met meerdere handtekeningen kan niet worden onderschat.

Deze enorme sprong voorwaarts voor scripts met meerdere handtekeningen heeft ook enorme gevolgen voor het privacyprofiel en de kosten van talloze applicaties die bovenop Bitcoin zijn gebouwd. Op MuSig gebaseerde Lightning-kanalen kunnen nu opgaan in de volledige anonimiteitsset van Schnorr/Taproot UTXO's in de keten, omdat niemand meer het feit zal kunnen onderscheiden dat ze een twee-van-twee multisig-uitvoer zijn.

Ze zullen opgaan in het geheel en er uitzien als één enkel handtekeningscript. Hetzelfde geldt voor elke multisig UTXO in het algemeen. Dit zal veel gevolgen hebben voor mensen die multisignature-scripts gebruiken om hun koude opslag beter te beschermen met een robuuster beveiligings- en herstelmodel dan een enkel handtekeningscript.

Ten eerste zal het niet duidelijk zijn dat ze een multisig-opstelling gebruiken door naar de blockchain te kijken, dus dit zal, net als in het geval van Lightning, ervoor zorgen dat ze opgaan in al het andere. Een belangrijke overwinning ligt echter op het gebied van de economie: het gebruik van multisignature vereist nu een aparte handtekening voor elke sleutel die betrokken is bij het uiteindelijk uitgeven van een UTXO. Met Schnorr/MuSig zullen de zaken worden gecomprimeerd in een enkele handtekening voor de enkele gecombineerde publieke sleutel, wat betekent dat het uitgeven van multisig UTXO's met behulp van MuSig veel goedkoper zal worden omdat er minder gegevens naar de blockchain worden gestuurd.

Een laatste cool ding dat Schnorr-handtekeningen doen, is de implementatie van adapterhandtekeningen drastisch vereenvoudigen. Denk aan een adapterhandtekening die wordt “gecodeerd” door een waarde die is opgeteld bij of afgetrokken van een geldige handtekening. Het is pas geldig als je die wiskundige bewerking ongedaan maakt, of 'decodeert' met de 'sleutel' die werd gebruikt om het te manipuleren. Dit is mogelijk met ECDSA, maar omdat de wiskunde niet-lineair is in vergelijking met Schnorr, is het relatief ingewikkeld en zijn er veel veiligheidsproblemen waarmee rekening moet worden gehouden bij de implementatie ervan.

Vanwege de lineaire eigenschappen van Schnorr is een adapterhandtekening echter net zo eenvoudig als het nemen van een enkele waarde (bijvoorbeeld het getal 9,300,030) en het aftrekken van een waarde ervan (bijvoorbeeld 30). Zodra de partij die de handtekening van de adapter bezit de afgetrokken waarde kent, kan deze deze eenvoudigweg weer optellen voila, ze hebben weer een geldige handtekening.

De gevolgen van penwortel

Zoals hierboven besproken is Taproot in werkelijkheid gewoon MAST, behalve dat het in plaats van dat het werkt als P2SH (waar je het script hasht, of in het geval van MAST de Merkle-root bovenaan de scriptboom), je een De publieke sleutel van Schnorr door de wortel van de Merkle-boom.

Tweaken werkt vanwege de lineaire eigenschappen van Schnorr: als je een publieke sleutel ‘tweakt’ met een Merkle-root (voeg die Merkle-root toe aan de publieke sleutel), dan kun je eenvoudigweg de Merkle-root toevoegen aan de originele private sleutel en de bestedingssleutel genereren voor de nieuwe aangepaste publieke sleutel. Dat wil zeggen, je voegt hetzelfde toe aan zowel de publieke als de private sleutel, en ze vormen nog steeds een geldig sleutelpaar. Dit verbergt het bestaan ​​van een MAST-boom, tenzij een tak ervan wordt gebruikt, maar in wezen is het nog steeds slechts een MAST-boom, slechts één die op een efficiëntere en persoonlijkere manier wordt gebruikt.

De mogelijkheid om zich aan verschillende bestedingsscripts in een Merkle-boom te binden en alleen het gebruikte script te onthullen, is een enorme schaalbaarheidswinst in termen van slimme contractcomplexiteit die mogelijk is om op Bitcoin voort te bouwen.

Net zoals de blokgrootte het aantal transacties per blok beperkt, is er een beperkingslimiet voor de transactiegrootte van 100 kilobytes. Het enige verschil is dat het geen consensusregel is, maar een beleidsregel. Dat betekent dat een mijnwerker een transactie groter dan 100 kilobytes kan minen, maar standaard zal niemands knooppunt op het netwerk überhaupt een transactie groter dan dat doorgeven aan de mijnwerker.

Dit beperkt inherent de grootte van het script dat wordt gebruikt om een ​​Bitcoin UTXO te vergrendelen. Zelfs met P2SH, waar de UTXO is vergrendeld op een hash van het script die pas wordt onthuld als je het uitgeeft, moet je uiteindelijk toch het volledige script onthullen tijdens de tijd die je besteedt. Taproot verhoogt deze schaalbaarheidslimiet van scripts door niet te vereisen dat u het hele script openbaar maakt wanneer u het gebruikt. In plaats van dat de totale omvang van alle manieren waarop u de UTXO kunt besteden wordt beperkt tot de limiet voor de transactiegrootte, hoeft u er alleen voor te zorgen dat elke manier waarop u een Taproot UTXO kunt besteden deze beperking respecteert.

Er zijn ook tal van privacyvoordelen verbonden aan Taproot. Een van de grote voordelen van een MAST-boom is de mogelijkheid om allerlei voorwaardelijke situaties te creëren waarin munten door andere partijen kunnen worden uitgegeven.

Stelt u zich zaken voor als erfenisregelingen waarbij uw kinderen na ongeveer een jaar uw munten kunnen uitgeven, of in het geval dat u weigert te tekenen, uw vrouw en een advocaat een mogelijke manier hebben om munten terug te krijgen. Er wordt niets over deze bestedingsvoorwaarden aan het publiek onthuld, tenzij er daadwerkelijk gebruik van wordt gemaakt. Dit tweeledige proces biedt plausibele ontkenning voor andere partijen die betrokken zijn bij verschillende uitgaventakken die u construeert, met betrekking tot hun betrokkenheid bij die UTXO, en beschermt hen ook tegen een dief of aanvaller die zich preventief op hen richt, wetende dat ze een zekere mate van controle hebben over hun activiteiten. de UTXO's van het doelwit.

Op technisch vlak is Taproot ook relatief goed ontwikkeld. Iedereen die leest en op enig diep niveau bekend is met Segregated Witness, zou bekend moeten zijn met de getuigenversie.

Toen Segregated Witness werd geïmplementeerd, creëerde het de nieuwe ‘getuige’-sectie van een transactie waar handtekeninggegevens naartoe werden verplaatst. Witness-gegevens hadden een versievlag zodat deze konden worden geüpgraded naar nieuwe functionaliteit zonder ongedefinieerde OP_CODE's op de basislaag te hoeven gebruiken voor nieuwe functies.

Dit is eigenlijk hoe Taproot/Schnorr is geïmplementeerd. Gescheiden Witness-transacties gebruiken Witness-versie nul. Wanneer Taproot/Schnorr binnenkort live gaat, zullen ze de nieuwe getuigenversie gebruiken om ze te onderscheiden van oudere Segregated Witness-transacties. Op dezelfde manier waarop SegWit getuigenversies introduceerde, introduceert Taproot een “tapleaf-versie” voor de tapscripts die worden gebruikt in de MAST-bomen voor UTXO's die Taproot gebruiken. Hierdoor kunnen niet alleen de scripts die in MAST zijn verborgen, worden geüpgraded zonder nieuwe OP_CODE's op de basislaag te gebruiken, maar ook zonder dat u getuigenversies hoeft te upgraden! Taproot is dus ontworpen om in de toekomst zo efficiënt mogelijk te kunnen upgraden zonder andere niet-gerelateerde upgrades van het protocol te beperken.

Taproot zal veel verschillende gebruiksscenario's met zich meebrengen. Om te beginnen kunnen alle niet-coöperatieve clausules in een Lightning-kanaal, zoals strafsleutels of tijdsloten om ze te gebruiken, worden begraven onder een MAST met Taproot. Niemand zal ooit weten dat ze bestaan, tenzij ze moeten worden gebruikt, waardoor verder onduidelijk wordt welke UTXO's eigenlijk Lightning-kanalen zijn of niet.

Overervingsregelingen zijn een ander gebruiksscenario. Stel je een Taproot-boom voor die zo is gestructureerd dat je hele gezin, nadat je zes maanden je geld niet hebt verplaatst, samen kan komen en de UTXO kan uitgeven zoals ze willen. Dan, zes maanden later, kan iedereen minus één persoon het uitgeven (dus stel je voor dat je je vrouw, twee kinderen en ouders als sleutelhouders hebt, stel je dan voor dat na de extra zes maanden je vrouw, één kind en ouders kunnen tekenen , of uw twee kinderen en ouders kunnen tekenen zonder uw vrouw, enzovoort).

Dan, zes maanden daarna, kan iedereen minus twee mensen het uitgeven. Uiteindelijk zou het erop kunnen neerkomen dat slechts één persoon met de hulp van een advocaat (om er zeker van te zijn dat er geen streken uit voortkomen) de UTXO kan uitgeven.

Of wat als u multisig gebruikt om uw koelopslag te beveiligen, maar u slechts één plek heeft die u als veilig en voorspelbaar op de lange termijn beschouwt? Je zou een MAST kunnen creëren waar uiteindelijk, na een paar jaar, de sleutel op die veilige locatie die munten alleen kan uitgeven, voor het geval er andere sleutels kwijtraken of vernietigd worden, maar zonder dat je munten in het heden meteen het risico lopen op diefstal. één sleutel werd aangetast.

Dit is een verbazingwekkende en veelomvattende upgrade van Bitcoin waar aantoonbaar al aan wordt gewerkt sinds bijna de geboorte van Bitcoin zelf, en niet alleen de laatste paar jaar waarin de daadwerkelijke implementatiedetails zijn uitgewerkt en geïmplementeerd.

Het is in zoveel opzichten echt een overwinning voor de schaalbaarheid en bruikbaarheid van het Bitcoin-protocol dat het moeilijk over te brengen is vanwege hoe subtiel en ‘niet-sexy’ sommige ervan zijn. Maar dat doet niets af aan de overwinning. Dus iedereen moet zich vastmaken en klaar zijn om te spelen met het nieuwe speelgoed dat we binnenkort zullen moeten gebruiken, want Taproot komt eraan!

Dit is een gastpost van Shinobi. De geuite meningen zijn geheel van henzelf en komen niet noodzakelijk overeen met die van BTC Inc of Bitcoin Magazine.

Bron: https://bitcoinmagazine.com/technical/bitcoin-taproot-explainer