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. But to achieve this it must not only solve the trilemma but also offer a high level of programmability. How can we achieve this?
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 (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 linearly 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.