Taproot: gewortelde smart contracts

Bitcoingebruikers kunnen in de nabije toekomst gebruik maken van een truc genaamd Taproot. Geopperd door Bitcoin Core ontwikkelaar Gregory Maxwell, zou Taproot de smart contracts binnen Bitcoin zowel uit kunnen breiden als flexibeler maken, terwijl alles ten goede komt aan de privacy. De meest complexe smart contracts zouden, wanneer verstuurd via het bitcoinnetwerk, niet te onderscheiden zijn van gewone eenvoudige transacties.

Inmiddels is deze mogelijke verbetering aan het protocol niet louter theorie. Achter de schermen wordt er al hard aan gewerkt. Ontwikkelaars als Pieter Wuille, Anthony Towns, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Ruffing, Rusty Russell en ook Gregory Maxwell zelf zijn bezig met een plan om Taproot, verpakt in een al omvattende Schnorr update, uit te werken.

Maar wat is Taproot, en hoe werkt het?

P2SH

Alle bitcoins zitten als het ware 'vast' in scripts: een paar regels code die worden meegegeven met een transactie, welke definiëren hoe de bitcoins vanuit het ontvangende adres weer verzonden zouden mogen worden. Deze zogenoemde voorwaarden houden vaak slechts het digitaal ondertekenen van een bitcointransactie in. Hiermee bewijs je dat jij de bitcoins uit mag geven. Andere voorwaarden zijn bijvoorbeeld lock times waarbij bitcoins pas na een bepaalde blockhoogte of tijdstip uitgegeven kunnen worden, of multisig waarbij er meerdere handtekeningen nodig zijn voor een uitgave.

Verschillende voorwaarden kunnen door en met elkaar gebruikt worden. Een voorbeeld van zo'n contract is een bitcoin die uitgegeven kan worden wanneer Alice en Bob allebei de transactie ondertekenen, Alice alleen hoeft te ondertekenen als een week is gepasseerd of als Bob de transactie ondertekent inclusief een geheim benodigd nummer. Het maakt niet uit aan welke voorwaarde wordt voldaan. De eerste voldane voorwaarde maakt het mogelijk om de bitcoins uit te geven.

De script voorwaarden zijn vaak nog niet zichtbaar voor de buitenwereld. Alleen de nieuwe eigenaar van de bitcoins weet hoe ze uiteindelijk uitgegeven dienen te worden. Dit gebeurt op basis van P2SH: pay to script hash. Wanneer een transactie wordt verzonden, wordt alleen een hash van het script opgenomen in de transactie en dus de blockchain, en niet het hele script zelf. Wanneer de nieuwe eigenaar de bitcoins wilt uitgeven toont hij het hele script, alsmede de benodigde voorwaarde van het script zelf. Doordat de hash van het script wel publiekelijk bekend was, kan men controleren of de hash inderdaad toebehoort aan de zojuist getoonde script. Klopt de hash? Dan is het juiste script getoond en mogen de bitcoins worden uitgegeven.

Bij het tonen van het script dienen ook alle niet vervulde voorwaarden getoond te worden. Dit heeft twee nadelen. Aan de ene kant zorgt dit voor meer data in een transactie, wat de transactie duurder maakt en de blockchain extra belast. Hoe meer voorwaarden er vooraf werden gedefinieerd, hoe groter de hoeveelheid data. Aan de andere kant is het slecht voor de privacy; iedereen krijgt te zien hoe bepaalde bitcoins uitgegeven konden worden, en dus niet alleen hoe ze daadwerkelijk uitgegeven werden. Zo zou achterhaald kunnen worden welk soort wallet wordt gebruikt, of welke partijen toegang konden krijgen tot de bitcoins.

MAST

MAST (Merkelized Abstract Syntax Tree) is een geopperde toevoeging aan het bitcoinprotocol welke zorgt voor een kleinere transactiegrootte, verbeterde privacy en de mogelijkheid tot grotere smart contracts. Het maakt gebruik van het al decennia oude principe van Merkle trees. Merkle trees bestaan uit afzonderlijke hashes van alle voorwaarden die worden gesteld aan het mogen uitgeven van bitcoins. Deze hashes maken deel uit van de Merkle tree, vergelijkbaar met een stamboom. Als je deze stamboom omhoog volgt, kom je uiteindelijk bij de stamoudste uit. Dit wordt de Merkle root genoemd. Een soort 'opper-hash' van alle andere onderstaande hashes. Met deze Merkle root worden de bitcoins vastgezet.

Het voordeel hiervan is dat wanneer men informatie uit de Merkle tree publiek maakt, de Merkle tree en wat meta data (Merkle path genaamd) gebruikt kan worden om te controleren of de gepubliceerde data daadwerkelijk deel uitmaakte van de Merkle tree. Je hoeft hierbij alleen de path te controleren waarin de voorwaarden stonden opgenomen. Alle andere zijtakken kunnen dus verborgen blijven. Dit maakt MAST data zuiniger en beter voor de privacy dan P2SH.

In combinatie met Schnorr kan Taproot nog beter uit de voeten: een transactie kan verborgen houden dat het überhaupt bestond uit een MAST structuur.

Schnorr

Het handtekeningen mechanisme van Schnorr staat al lang op het verlanglijstje van vele Bitcoin ontwikkelaars, en is op dit moment dus in ontwikkeling om als softfork toegevoegd te kunnen worden aan het bitcoinprotocol. Naast de hoge mate van juistheid van de handtekeningen, zijn ook de snelheid van verificatie van de handtekeningen en het ontbreken van transaction malleability een grote stap voorwaarts.

Schnorr maakt het mogelijk om handtekeningen samen te kunnen voegen. Zo kunnen bijvoorbeeld handtekeningen van multisig adressen, waarbij er meerdere handtekeningen vereist zijn voor uitgave, samengevoegd worden tot één alomvattende threshold handtekening. Hierdoor kan niet achterhaald worden of het om een ordinaire bitcointransactie ging, of dat er gebruik gemaakt werd van multisig.

Het handtekeningen mechanisme kan voor nog iets interessants gebruikt worden. Het maakt mogelijk om zowel privé sleutels als publieke sleutels aan te passen. Simpel gezegd kan een privé sleutel behorende tot een publieke sleutel aangepast worden door deze beiden maal twee te doen. 'Privé sleutel x 2' en 'publieke sleutel x 2' komen ook na de vermenigvuldiging nog met elkaar overeen. Men kan dus nog steeds berichten ondertekenen met 'privé sleutel x 2' en deze verifiëren met 'publieke sleutel x 2'. Wanneer men er niet van op de hoogte is dat de sleutels vermenigvuldigd zijn, is dit ook niet te achterhalen. Zowel vóór als ná de vermenigvuldiging lijken de sleutelparen op normale sleutels.

En deze ontwikkelingen maken Taproot mogelijk.

Taproot

Taproot komt voort uit de volgende realisatie: onafhankelijk van hoe complex een MAST constructie is, deze altijd een voorwaarde moet bevatten die alle participerende partijen een transactie moet kunnen laten ondertekenen wanneer dit gewenst is, zonder dat er gewacht dient te worden op andere aflopende voorwaarden. In het eerdere voorbeeld met Alice en Bob, waarbij Bob weet dat Alice na een week hoe dan ook de bitcoins kan claimen, zou hij ook vóór die tijd al mee kunnen werken aan de uitkomst.

Taproot toont hierin gelijkenis met MAST en stopt altijd een voorwaarde in het contract waarbij men vroegtijdig de bitcoins zou kunnen uitgeven: de coöperatieve sluiting. De transactie die uitgevoerd kan worden als alle participerende partijen het ermee eens zijn, onafhankelijk van alle andere voorwaarden.

Dit idee wordt interessant doorgebruik te maken van Schnorr.

Als eerste zorgt Schnorr er voor dat ook deze coöperatieve sluiting niet opvalt. Het zal er door het samenvoegen van de sleutels uitzien als een normale transactie, bestaande uit de threshold publieke sleutels. Doordat vervolgens alle handtekeningen ook samen worden gevoegd, kan met deze threshold handtekening de transactie geldig worden ondertekend.

Tot zo ver kan men dus speciale transacties verhullen alsof het gewone transacties zijn. Nog geen MAST-achtige constructies. Daar zorgt een ander Schnorr trucje voor.

Alle andere voorwaarden waarbij de bitcoins uitgegeven zouden kunnen worden — de niet-coöperatieve uitkomsten — worden nu gecombineerd in een apart script. Dit aparte script wordt gehasht en vervolgend gebruikt om de threshold publieke sleutel aan te passen. Waar we eerder het vermenigvuldigde sleutel voorbeeld gebruikten, ontstaat dus nu de 'publieke sleutel x script'. Deze komt uiteraard weer overeen met de samengevoegde 'handtekeningen x script'.

Als men besluit samen te werken om de transactie uit te geven, dan gebruiken alle participanten hun handtekeningen om samen de threshold handtekening te maken. Vervolgens passen ze deze aan met het script, waarna ze een geldige transactie kunnen creëren om de bitcoins uit te geven. En zoals eerder aangegeven, alles wat hier achter de schermen gebeurt, lijkt voor de buitenwereld op een ordinaire bitcointransactie.

Als de coöperatieve sluiting niet mogelijk blijkt, om wat voor reden dan ook, kan men de publieke threshold sleutel openbaar maken. Het wordt dan duidelijk dat dit een aangepaste, samengevoegde sleutel is.

In zo'n situatie maakt men dus zowel de threshold publieke sleutel als het bijbehorende script openbaar. Dit bewijst dat de 'threshold publieke key x script' inderdaad is aangepast door het getoonde script. Hiermee is dus te controleren onder welke condities de transactie uitgegeven zou mogen worden. Net als bij P2SH, kunnen de bitcoins vervolgens ook direct worden uitgegeven wanneer aan de gestelde voorwaarde(n) wordt voldaan.

Anderzijds, in plaats van de threshold sleutel aan te passen met het script, kan de threshold sleutel ook worden aangepast met de Merkle root van de Merkle tree waarin alle voorwaarden staan opgenomen. Er wordt dan dus gebruik gemaakt van de MAST structuur. Als de bitcoins uitgegeven dienen te worden, hoef je alleen de voorwaarde te tonen die voldaan wordt, en dus niet het hele script met alle voorwaarden.

Taproot biedt dus alle voordelen van MAST, terwijl niemand door heeft wat er zich onder de motorkap allemaal afspeelt.

Dit artikel is geschreven op basis van Aaron van Wirdum zijn artikel voor Bitcoin Magazine. Aaron van Wirdum is geïnteresseerd in gedecentraliseerde consensus, FOSS, privacy in het digitale tijdperk, censuur resistente betalingen en andere stereotyperende Bitcoin onderwerpen.