In this post, I intended to discuss some background on MAST, what it does, and its implications. However, in doing so, I came across a phenomenal post by David Harding that accomplishes all of the above. I won’t attempt to improve upon that article and instead hope to add to the discussion by further emphasizing & summarizing a couple of points as well as discussing perspectives on higher-level design objectives of crypto networks and how MAST aligns with those objectives.
First, here’s David Harding’s post on Bitcoin Tech Talk “What is a Bitcoin Merklized Abstract Syntax Tree (MAST)?”
The tl;dr is that MAST moves a significant portion of smart contract processing and storage off-chain and, in doing so, could materially increase Bitcoin’s functionality (more complex smart contracts), privacy (fewer details of smart contract are divulged publicly), and efficiency (consumes fewer network resources in executing and verifying these contracts). Essentially, with MAST we could get more functionality and more privacy without additionally burdening the network.
The importance of Win-Win-Wins: Thoughts on Crypto Design Objectives
What’s great about MAST is that it’s a rare win-win-win in terms of what is often otherwise a tradeoff between functionality-efficiency-privacy. Typically, new functionality and improved privacy come at the expense of efficiency. A quick look at these (sometimes conflicting) objectives:
Functionality: Stated most simply, we want more people to be able to do more things with more people on the network. All else equal, people get more utility from the network when they can do more things on it — it follows that we want to increase the number of things people can do on the network. If it were as simple as that, crypto development would be a straightforward process of “MOAR features!!”.
However, all else isn’t equal and the desire to “do more” must be weighed against the second design objective to maximize potential participation.
Efficiency: We want to minimize resource requirements for network participants such as full nodes and miners that provide the critical services upon which the network depends. That means minimizing the amount of data that needs to be processed and stored on the network level.
In general, we want to avoid changes that discourage valuable network participants from providing their services. Most commonly, adding more “features” or “functionality” comes at the expense of increasing resource requirements for network participants such as “full nodes” (which keep the network honest by independently verifying transactions).
Privacy: Network privacy is desirable for a couple of reasons. First, it’s closer to current user expectations: Nobody publishes their entire bank balance and transaction history online for the whole world to see, nor do they publish all of the terms of every contract they’ve entered — nor do most people actually want to do this with crypto. Second, privacy goes hand-in-hand with fungibility — an important quality that is important to preserve.
For example, Monero specializes in privacy — which comes at the expense of efficiency (confidential transactions are much larger). Similarly, Ethereum specializes in features (more expressive programming language) — which comes at the expense of efficiency (smart contracts demand more processing and storage resources).
The friction in those tradeoffs is why it’s all the more important to find win-win-wins to improve public blockchains like Bitcoin that already exist in the wild.
Ultimately, MAST seems to fit the bill as a win-win-win: By moving a significant portion of smart contract processing and storage off-chain, MAST increases efficiency (fewer network resources needed to execute, verify, and store contracts), improves privacy (fewer details of the contract are divulged publicly), and increases functionality (more expressive smart contracts).
Indeed, minimizing on-chain usage in terms of data storage and processing is how all of the innovations discussed thus far in the series gain their efficiency, functionality, and privacy advantages including Schnorr Signatures and Scriptless Scripts.
Additional Note: While MAST itself is already a privacy improvement, there’s another proposal (via Gregory Maxwell) known as Taproot that would even further improve privacy. With Taproot, a MAST transaction would look just like any other transaction — otherwise, as currently proposed, the fact that a transaction is a MAST transaction would be publicly evident on the blockchain.
Key People and Additional Resources
· David Harding post on BitcoinTechTalk
· MAST proposal by Johnson Lau BIP 114
· Mark Friendbach (aka maaku) working on another