The wait for more advanced bitcoin smart contracts might soon be over.
Spurred by last month’s SegWit activation, bitcoin developers are reviving a plan that would see the world’s most popular blockchain retooled with functionality long synonymous with ethereum and its more expressive code executions.
Known as Merkelized Abstract Syntax Trees (MAST), the concept has moved in fits and starts – Russell O’Connor, Pieter Wuille and Peter Todd put forward the idea, and Johnson Lau put together his own proposal last year – but the upgrade to SegWit makes the change not only possible, but possibly actionable soon.
So, Blockstream co-founder Mark Friedenbach is now breathing new life into the idea, putting forth a proposal this week that would have MAST deployed by way of soft fork (a backwards-compatible change to the blockchain’s rule set).
Should it be enacted (and in the world of bitcoin upgrades, that’s a big if), it would mean greater transaction flexibility. With it, users can require that a transaction will go through only if one of two or more things happen. For instance, a transaction could be redeemable only after a certain period of time, or only once two users give their blessing.
MAST also enables better user privacy, as it stores transaction data in a new way and doesn’t reveal unused scipts to the public blockchain. And finally, it could also allow for increased scaling potential, since it enables less data to be stored on the blockchain.
Merging features
Getting to those benefits, though, means fusing together two technical features: pay-to-script-hash (P2SH) and Merkle trees.
In an email addressing bitcoin developers, Friedenbach outlines three Bitcoin Improvement Proposals (BIPs), including the code, for adding two scripts that would make it possible for users to take advantage of MAST.
He explained what his proposed idea would enable, writing:
“These two features together are enough to enable a range of applications such as tree signatures … and a generalized MAST useful for constructing private smart contracts.”
The first BIP, “Fast Merkle Trees,” proposes a different Merkle tree structure than the one currently used by bitcoin to store transactions in blocks. The second BIP, arguably the most important one, describes the opcode – MERKLE-BRANCH-VERIFY – which is a script that would allow users to make new types of transactions.
“In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force redemption to use values selected from a pre-determined set committed to in the scriptPubKey, but without requiring revelation of unused elements in the set for both enhanced privacy and smaller script sizes,” Friedenbach wrote.
The final BIP, “Tail Call Execution Semantics,” is a pretty complex read, but – put simply – explains a new way for bitcoin smart contracts to terminate.
The road to upgrades
Despite how complicated the technology sounds, Friedenbach said in practice it’s relatively straightforward.
“I believe that the implementation of these features is simple enough, and the use cases compelling enough that we could [roll out] these features in relatively short order, perhaps before the end of the year,” he wrote.
Interestingly, though, he mentioned the change could be made one of two ways, by BIP 8 or BIP 9, two methods of making bitcoin upgrades which have had plenty of back-and-forth over the past year.
SegWit was originally proposed to deploy via BIP 9, which called for a certain percentage of miners to signal for the change before it could be deployed. Because miners didn’t signal, SegWit stalled, and some argued BIP 9 gave miners (one group in an elaborate ecosystem) too much control over the future of bitcoin.
Because of that, some users have since rallied around BIP 8 as a better upgrading mechanism because it relies on bitcoin users and businesses rather than mining pools to enforce the change.
But Friedenbach’s lack of stance regarding this upgrading mechanism raises the question: after all the drama over SegWit – which took nearly two years to activate – how will upgrades be made in the future?
The way users, companies and developers choose to go on MAST (if they decide it’s the right step), might help determine that.
