MAST Contract Paths - The EVM Killer

Overview

Traditionally, EVM-based networks and UTXO-based networks can be considered to offer significantly different trade-offs, with EVM-based networks sacrificing scalability or security in favour of programmability, whereas UTXO-based chains tend to have higher scalability but low programmability.

Nexa employs the only known solution to solving the famous blockchain trilemma by simultaneously retaining the features of security, decentralisation and scalability and it does so all on layer-1. But Nexa doesn't just aim to be a P2P payment system like Bitcoin, it aims to compete with the entire financial system and offer complex, decentralised financial services. To achieve this it must solve the trilemma and offer a high level of programmability. How can we achieve this?

Covenants

Covenants are a smart-contract architecture that get their name from an analogous concept from the legal world. In the legal world, a 'covenant' is a type of property legal construct which puts legal constraints onto the deeds to a property (or the modern digital equivalent) which require that the constraint is passed on to each further owner of that property in perpetuity. Smart-contract covenants are a very similar concept.

A smart-contract that enforces a covenant architecture sets a constraint on some or all of the outputs that are allowed to be produced from that contract, such that the constraint is passed down to child UTXOs, and they pass the constraints down to their children ad-infinitum (or until another contract exit clause can be executed).

This is an important architecture for UTXO-based smart-contracts because it started to enable more complex code paths and properties that resemble loops, with each transaction, and therefore consumption of a UTXO, acting like one loop. Except this is a more like a helix as opposed to a loop.

MAST

MAST (Merklized Abstract Syntax Trees or Merklized Alternative Script Trees) is technology that has been discussed for over 7 years in Bitcoin. So what is MAST? MAST is a method of enabling much larger and more complex smart-contracts to be used in UTXO-based smart-contracts/transactions.

MAST uses something called 'Merkle Trees' to prove the inclusion of a piece of data within a data set. The proof that a piece of data is included in a dataset that has been put into a Merkle Tree is called a 'Merkle Proof'. The larger the dataset the more compression is achieved with the proof. As the dataset grows exponentially the Merkle Proof only grows linearly.

Have a read of this article for a clearer overview of Merkle Trees. Merkle trees are used in a number of places already in Nexa as they are an incredibly simple and efficient method of proving data is contained within a set.

Ok, so how does this relate to smart-contracts in Nexa? Nexa uses a low-level smart-contract similar to Bitcoin called 'Script'. Script allows transactions to be constrained in clever ways such that they can only be spent under highly specific circumstances. The powers of the consensus mechanism and cryptography enforce this system.

One of the early innovations Bitcoin by Gavin Andresen was a new transaction format to lock a transaction to a specific hash and constrain it such that it is only valid if the data associated with that hash can be provided. But the magic in this transaction type was that this data is in fact a script and is executed as script by the virtual machine after it has checked it matches the hash, If this script also executes as valid then the entire transaction is valid.

This transaction type is called P2SH (Pay To Script Hash) and opened up some of the potential for smart-contracts on Bitcoin. This transaction type only allows a single script to be executed by one UTXO though. This is where MAST brings something new and significant to the table.

Merkle Trees can be applied to Script by constraining smart-contracts to only execute if one hash (and associated data) within the set of hashes from the Merkle Tree is included as an argument in the transaction. Just like the P2SH transaction type a MAST script architecture then executes the data associated with that hash as script, and if that script executes correctly the transaction is valid. Using this structure, you can see that MAST opens the possibility for a single UTXO to have many different scripts that can be executed in a valid way. In fact, 'many' is an understatement. Due to the enormous compression achieved by a MAST architecture, a single smart-contract could run thousands, even millions of different scripts.

Aside from the huge efficiency and contract complexity gains, MAST also adds a significant degree of privacy as contracts only need to execute the section of script that is actually needed. For P2SH contracts to simulate the execution of different functions within a script, sections of script must be included that are simply ignored in execution, which is of course wasteful, but it also exposes the full contract publicly. MAST allows users to only expose the section of script that is needed to satisfy the constraints on it.

But there's more...

MCPs

Ok, so let's bring this all together. So we have the MAST architecture that enables much larger scripts to be built and executed (as long as the section of script that is being executed fits within the network limits), and we have Covenants which allow smart-contracts to constrain their offspring. By this point you should already be having an 'Ahhh!' moment and putting it together in your head.

It's possible to build smart-contacts that are constrained to MASTs and that those MAST scripts constrain the outputs with covenants and that those covenant scripts can also be MASTs ad infinitum. This is what I call MCPs (MAST Contract Paths), and yes I was trying to be clever and include an acronym within an acronym analogous to the concept itself!

This means that a smart-contract of just a single UTXO can constrain a limitless number of transactions with a limitless amount of code complexity.

But what do MCPs enable?

Unlocking the Future of UTXO Smart-contracts

Everything. The MCP smart-contract architecture enables essentially limitless programmability. Well, almost. But I am pretty sure this architecture makes Nexa functionally turing complete. An individual transaction cannot be turing complete of course, but I am quite sure that an MCP can be, as loops can be achieve through multiple transactions.

The MCP architecture allows developers to compress any level of smart-contract complexity into a UTXO-based smart-contract. It enables things like highly complex DAOs, and Constant Product Market Maker's like Uniswap, stablecoins via entities like MakerDAO, or even algorithmic stablecoins. Say hello to full DeFi on Nexa! And the best bit...it is possible right now with no upgrades to the network at all. In fact, I have already written the MAST script architecture (Bitcoin is yet to implement it even after 7 years of discussion), and the covenant architecture is well understood.

Developers can write a contract that not only allows almost endless optionality for the contract executed in a single transaction or UTXO, and not only can a smart-contract constrain its offspring UTXOs with its own (or similar) contract, but now a contract can construct code paths of limitless complexity.

What's Next?

The MCP architecture can be added to NexScript after the initial release so that developers can make use of it from a high-level smart-contract language. After some initial research it seems that from a language perspective this should be fairly easy to add to NexScript.

I am already using this architecture in concept to work though building Otoplo’s initial DAO smart-contract template which will be used in the DAO Builder tool we aim to release towards the end of the year. In my opinion, this architecture for multi-UTXO smart-contracts is a game-changer and will really show-off what is possible on the most scalable blockchain network ever built.

Summary

This, plus a few other pieces of the puzzle will make Nexa an Ethereum killer. Not only will Nexa have unparalleled scalability of over 100,000 transactions per second capacity, but it does so while also offering EVM-levels of programmability. This will allow any kind of DeFi application to be built on the network without having to worry about censorship, high fees, slow confirmation times or network outages. Let’s get building!