Merkalized Abstract Syntax Tree (deel 2)

In een eerder artikel zijn we ingegaan op de basis van MAST. In dit artikel zullen enkele voordelen van deze ontwikkeling worden belicht.

Een voorbeeld van MAST

We nemen de casus uit het vorige artikel (die met Alice, Bob en Charlie) en splitsen het probleem op in aparte sub-scripts voor elk van de twee uitkomsten:

1. Alice kan haar bitcoins op elk gewenst moment uitgeven (linksonder in de onderstaande afbeelding)
2. Na drie maanden waarin Alice haar bitcoins niet zijn uitgegeven, kunnen Bob en Charlie samen beslissen waar Alice haar bitcoins aan uitgegeven dienen te worden (rechtsonder in de onderstaande afbeelding)

De merkle tree op basis van de uitkomsten ziet er als volgt uit:

De merkle root voor deze tree identificeert de volledige encumbrances in slechts 32 bytes. Vervolgens dient er een merkle proof getoond te worden door eenieder die de bitcoins wilt uitgeven. De merkle proof koppelt de merkle root en de scripts waarbij de encumbrances van de scripts 'correct' zullen moeten teruggeven. Alleen hierna kan worden bewezen dat de initiator het sub-script uit zou mogen voeren.

De merkle proof met het sub-script zou gevisualiseerd kunnen worden afhankelijk van welk sub-script er gebruikt moet worden:

Voordeel 1: kleinere transacties

Een van de voordelen van MAST is de mogelijkheid om bepaalde transacties kleiner te maken. In het voorbeeld hierboven gingen we uit van twee sub-scripts; Alice verstuurt haar bitcoins, of Bob en Charlie bepalen waar de bitcoins van Alice heen mogen. Als we deze mogelijkheid nog verder toepassen, dan zouden Daan en Ella de maand daarop weer samen bepalen waar de bitcoins aan besteed worden, gevolgd door Fred en Gert die dat weer een maand later kunnen.

Deze functionaliteiten zouden een enorme hoeveelheid data met zich meebrengen. Elke voorwaarde dient immers opgenomen te worden in de transactie, ook al is de kans groot dat veel van de latere voorwaarden niet gebruikt zullen worden.

Onderstaand een grafiek waarin de grootte van het script met en zonder MAST wordt aangegeven, bij een toenemend aantal sub-scripts.

Dezelfde grafiek op logaritmische schaal:

Zoals te zien op bovenstaande grafiek start de MAST transactie iets groter en dus duurder dan de transactie die geen gebruik maakt van MAST. Echter schaalt de niet-MAST-transactie lineair waarbij de MAST transactie logaritmisch schaalt. Dit betekent dat de MAST transactie exponentieel efficiënter wordt naarmate er meer sub-scripts worden gebruikt, ten opzichte van de gewone transactie.

Als het sparen van data in een transactie het hoofddoel is, kan dit nog verder worden geoptimaliseerd. Bij de meeste encumbrances zullen verzenders vaker een bepaalde voorwaarde gebruiken dan een andere.

Een voorbeeld: Alice gaat er vanuit dat ze nog lang te leven heeft. Ze zorgt er daarom voor dat de voorwaarde waarin zij zelf de bitcoins mag uitgeven bovenaan de merkle tree staat. Eventuele latere voorwaarden hoeven niet te worden aangeroepen zolang Alice nog leeft, hierdoor bevat de transactie dus ook niet elke keer de extra data van de latere voorwaarden.

Hierdoor hebben de MAST merkle proofs twee verschillende grootten. Een van de transacties wanneer Alice leeft en als enige de bitcoins kan versturen, de ander in de gevallen waarbij Alice niet meer leeft (of een lange tijd geen teken van leven heeft getoond) waardoor Bob en Charlie de bitcoins mogen verzenden. Op basis van de eerdere grafiek over de grootte van de MAST- en niet-MAST-transacties is de onderstaande grafiek van toepassing op deze casus.

In de best case scenario is te zien dat Alice altijd hetzelfde aantal bytes gebruikt voor de transactie, onafhankelijk van het aantal extra begunstigden die er in de encumbrance worden meegenomen. Eventuele latere verzenders, zoals Bob en Charlie, hoeven slechts enkele bytes extra aan de transactie toe te voegen wanneer zij de bitcoins willen verzenden.

Hoe Alice het ook regelt met de begunstigden die mogelijk later de bitcoins zouden kunnen versturen, de besparing per toegevoegd sub-script blijkt significant.

Voordeel 2: meer privacy

Omdat we het hele verhaal van Alice uitvoerig hebben behandeld, ken je als het goed is alle details van de encumbrance. Stel je nu voor dat alleen de data die daadwerkelijk nodig is voor de te versturen transactie aan de blockchain wordt toegevoegd wanneer Alice haar bitcoins verzendt (het voorbeeld linksonder), zonder alle volgende voorwaarden:

Met alleen deze informatie zou je niet weten of iemand anders dan Alice toegang zou hebben tot de bitcoins of welke voorwaarden hun uitgaven zouden kunnen beperken. Je zou kunnen raden aan de hand van de MAST dat er andere voorwaarden bestaan, maar dat zou alleen maar een gok zijn; Alice zou net kunnen doen alsof ze zelf aan meerdere voorwaarden dient te voldoen om haar eigen bitcoins te kunnen versturen.

Anderzijds, als je alleen de andere voorwaarden zou zien (rechter voorbeeld hierboven), dan zou je niet weten dat de bitcoins voor de time-out 'na 3 maanden' konden worden besteed of dat een enkele persoon (Alice) deze kon uitgeven. Je zou dus weer kunnen raden dat er andere omstandigheden waren, maar je kunt op basis van de data in de blockchain geen zekere conclusie trekken.

De mogelijkheid om alle voorwaarden van de encumbrance onbekend te laten kan voor sommige gebruikers erg belangrijk zijn, zoals bedrijven die hun smart contracts vertrouwelijk willen houden voor mogelijke concurrenten. Dit staat in contrast met sommige altcoins die specifiek zijn ontworpen voor smart contracts, welke totaal geen privacy voor de smart contract data bieden.

Privacy kan ook een ander voordeel bieden wat van toepassing is op alle bitcoingebruikers, zelfs diegenen die zich niet druk maken om de privacy van de encumbrance zelf. Stel je voor dat Alice de enige persoon is die ooit de niet-MAST-encumbrance gebruikt. Omdat hierbij de volledige encumbrance openbaar wordt gemaakt, kan iedereen alle uitgaven van Alice volgen door slechts te zoeken naar gevallen waarin hetzelfde soort encumburance wordt gebruikt. Hierdoor wordt Alice haar privacy volledig tenietgedaan.

Alles wat het gemakkelijk maakt om bepaalde gebruikers te identificeren, maakt het ook eenvoudig om hun bitcoins anders te behandelen dan bitcoins van anderen; een gebrek aan fungibiliteit. Fungibiliteit houdt de vervangbaarheid van een voorwerp in; de ene bitcoin zou niet anders moeten zijn dan de andere. Als iemand weet hoe Alice's bezittingen eruitzien, kan hij of zij miners omkopen of dwingen die transacties niet te minen om zo te voorkomen dat Alice haar bitcoins zou kunnen uitgeven.

MAST alleen kan dit niet volledig oplossen, omdat Alice (of Bob en Charlie) nog steeds een deel van de encumbrance moet onthullen wanneer de bitcoins worden uitgegeven. Het is echter wel mogelijk dat een groot aantal complexe encumbrances wordt samengevoegd tot een kleiner aantal MAST-encumbrances.

De normale transacties van Alice zien er bijvoorbeeld uit als de normale transacties waarvoor slechts één digitale handtekening vereist is, zodat de op MAST gebaseerde transacties van Alice lijken op alle andere op MAST gebaseerde transacties met slechts één handtekening. Dit geeft de privacy van Alice terug en vergroot zowel haar fungibiliteit als de fungibiliteit van alle anderen die dezelfde transactievorm gebruiken.

Dit specifieke voordeel van MAST zal waarschijnlijk goed samengaan met andere voorgestelde functies die de privacy en fungibiliteit voor bitcoingebruikers verbeteren door bepaalde complexe encumbrances te laten voldoen aan één enkele digitale handtekening. Voorbeelden hiervan zijn de generalized threshold trees van Pieter Wuille en Gregory Maxwell, scriptless scripts van Andrew Poelstra scripts en de discrete log contracts van Thaddeus Dryja.

Maar zelfs als geen van deze ontwikkelingen ooit mogelijk wordt op het bitcoinnetwerk, biedt MAST zelf gebruikers al meer privacy en fungibiliteit voor de complexe encumbrances dan nu mogelijk is.

Voordeel 3: grotere smart contracts

Bitcoin heeft drie verschillende byte limieten die van toepassing zijn op scripts, afhankelijk van hoe een encumbrance is opgesteld: een 10.000-byte limiet voor gewone scripts, een 520-byte limiet voor P2SH (pay-to-script-hash) en een 10.000 byte limiet voor SegWit.

Onderstaande grafiek toont deze limieten op de al eerder gebruikte grafiek.

Te zien is dat MAST het mogelijk maakt om een groot aantal extra conditionele voorwaarden als script toe te voegen ten opzichte van de andere methoden.

Er zijn nog meer limieten omtrent de bitcoinscripts die MAST weet te omzeilen. Full nodes op het netwerk hoeven immers ook niet de ongebruikte sub-scripts te valideren en door te sturen over het hele netwerk. Zo blijft de hoeveelheid van alle data die de scripts behelsen vooral bij de gebruiker, en wordt het netwerk hier niet mee belast. Dit scheelt de nodes zowel bandbreedte, geheugen als rekenkracht.

Het daadwerkelijke voordeel van MAST is dus niet alleen het feit dat men uitgebreidere smart contracts kan creëeren met een verhoogde privacy, maar indien men dit doet, dit mogelijk is zonder het netwerk extra te belasten.

Dit artikel is geschreven op basis van een artikel gepubliceerd door David A. Harding. David publiceert documentatie van gratis software en is sinds 2014 gefocust op Bitcoin.