My Quick Guide to MAST

In a previous article, I discussed how Segwit enables exciting technology like the Lightning Network. Another tech that is coming for Segwit enabled coins is MAST. Here’s a quick rundown of what it is:

What does MAST stand for?

Merkelized Abstract Syntax Trees.

How will it affect Bitcoin, Litecoin, and other Segwit enabled coins?

It’ll increase their speed, scalability, and privacy.

What will it do exactly?

MAST will allow nodes to interact with “Merkle Trees” created within the BTC/LTC blockchain. Below is a recreation from Jeremy Rubin’s paper (referenced in the source section) of what a Merkle Tree is:

Nodes read the top of the Merkle Tree along with the Merkle Root. They can check to see if the specific data that’s being requested is actually somewhere in the Merkle Tree. In other words, the Merkle Root “z” allows you to see that the transaction (ABz) occurred. The cool thing about Merkle Trees is that it ONLY reveals that specific information. It does not reveal that (CDz) was also part of the Merkle Tree. This is the increased privacy that MAST provides.

What’s a Merkle Root?

Before we talk about the Merkle Root, let’s talk about what a hash is:

“A hash is data that is scrambled and condensed into a short and seemingly random string of numbers. This string of numbers can’t be used to reproduce the original script. But if you have the original script, the hash can be reproduced.” -Aaron van Wirdum

If this sounds familiar, it should. This is what Pay to Script Hash (P2SH or multisig wallets) use. Therefore, a Merkle Tree is a data structure that has reduced different datasets into a single and compact hash called the Merkle Root. This root can’t recreate the data in the Merkle Tree, however it does verify that the requested data exists somewhere in the Merkle Tree.

Why Is This Relevant?

MAST allows for complicated smart contracts (midlayer stuff in the diagram above) to be created on the BTC/LTC blockchain without clogging it up. Normally all smart contracts would be readily visible on the blockchain and it would take up a lot of space. MAST allows for privacy by only revealing the smart contracts that have been completed and also saves space on the chain because nodes will only read the top layer of the Merkle Tree.

Here is one application of MAST to consider in regards to multisig contracts from the github:

“With MAST, large and complex multi-signature constructs could be flattened to many simple CHECKMULTISIGVERIFY conditions. For example, a 3-of-2000 multi-signature scheme could be expressed as 1,331,334,000 3-of-3 CHECKMULTISIGVERIFY, which forms a 31-level MAST. The scriptPubKey still maintains a fixed size of 34 bytes, and the redemption witness will be very compact, with less than 1,500 bytes.”

Tying It All Together

Let’s say Alice decides to deposit 1 BTC/LTC into a multisig address with MAST. She can create several spending conditions (smart contracts) to be executed:

Alice signs the transaction.
Barry and Chels both sign it.
If 5 hours pass and Chels signs it, it is valid.

All of these spending conditions are hashed (turned into a Merkle Root) and combined into a Merkle Tree. Now let’s say scenario 1 is executed. Only Scenario 1 will be included in the blockchain, not Scenario 2 or 3.

Ramifications

You will now be able to write and execute detailed smart contracts on the BTC/LTC blockchain.
BTC/LTC will be faster, avoids further scalability issues, and brings increased privacy to its users.
Furthermore, increased privacy will facilitate anonymity for settled transactions. For example, right now LN transactions are easily identifiable because of the P2SH hash they use. In light of this, nodes are capable of censoring LN transactions should they choose to. MAST would be able to hide LN transactions by making them indistinguishable from other blockchain transactions.