The proposals for a Bitcoin Cash smart contract upgrade (almost) nobody knows about

Bitcoin Cash now follows a yearly upgrade schedule to give developers more time to work on bigger upgrades and allow for more time for review and cooperation. Last hardfork, May 15th, introduced no new consensus rules and with a year until the next upgrade date there's enough time for multiple big improvements to BCH to make it for the next upgrade.

CHIPs

Towards the end of last year a process was developed to share improvement proposals for Bitcoin Cash called CHIPs (CasH Improvement Proposals) similar to Bitcoins BIPs and Ethereums EIPs. The proposals are shared and discussed on bitcoincashresearch.org. In this post we'll go over and summarize some of the most important proposals with a good chance to make it into the May 2022 upgrade. Having a great proposal is of course not enough to actually get it implemented - talented developers actually have to put the work in to realize the potential! That's why it's important to keep in mind nothing is finial yet - a drawback of being ahead on the curve! The milestones laid out in the CHIP process are also strict, so a close eye should be kept on which proposals roughly follow this milestones trajectory.

smart contract upgrade

Many of the CHIPs are focused on improving the smart contract capabilities of Bitcoin Cash. This direction was shaped in large part by General Protocols, the first company developing DeFi on BCH, under the subtitle What kind of evolution does GP want in the short term?. They outlined 5 shortcomings of the BCH scripting language that has servery limited their products or hindered development. They are:

• The lack of a multiplication opcode

• The maximum size of a contract, measured in number of operations, is small.

• The maximum size of a contract, measured in bytes, is small.

• Smart contract covenants are 2nd class citizens, requiring expensive and risky workarounds.

• 32-bit numbers are very restricting.

All five shortcomings currently have an improvement proposal to solve them! The three proposals which address them all have a proposed deployment date of the May 2022 upgrade.

CHIP-2021-05-vm-limits: Targeted Virtual Machine Limits (addresses both limits)

CHIP-2021-02: Native Introspection Opcodes

CHIP-2021-03: Bigger Script Integers (includes re-enabling OP_MUL)

Increasing the limits would allow bigger and more complex smart contracts on the network and the others would severely lower the barrier to entry for aspiring smart contract developers. This lower development cost in turn would lead to more smart contract applications, more profitable smart contract businesses and a more useful Bitcoin Cash.

Loops

The lack of the Bitcoin script to do loops was long used by Ethereum supporters and others as argument as to why it couldn't be used for complex smart contracts because this made it Turing incomplete. Well now there is a CHIP to introduce Bounded Loops to the Bitcoin Cash scripting language with a proposed deployment date of May 2022!

A 3rd transaction format

The CHIP-2021-01-PMv3: Version 3 Transaction Format would introduce a new fundamental building block called "Fixed-Size Inductive Proofs". This would enable contract validated tokens which solve SLPs requirement to validated the whole DAG to see if a token is valid and unlike a hard-coded token protocol it allows for experimentation and multiple standards to emerge -similar to the situation on Ethereum. The proposal is a general building block because it also enables a new scaling strategy for decentralized applications. The "PM" in PMv3 actually stands for Prediction markets, as this is the primary use-case the author, Jason Dreyzehner, had in mind which needed this more general building block. PMv3 would enable the same level of programmability that Ethereum has but on-top of BCH, for more details see this great blogpost PMv3: Build Decentralized Applications on Bitcoin Cash, or this article to learn more about Prediction Markets on Bitcoin Cash. The PMv3 proposal also has the proposed deployment date of the May 2022 upgrade.

With the CHIP-2021-01-RSN: Ranged Script Number Format the new transaction format would do clean-up with regards to inefficiencies in the current format which would save space for each transaction

group tokenization

There's another proposal for miner validated tokens called Group which is an older idea for a hard-coded token protocol that has gone through quite a few iterations. Now with PMv3 there's two proposals which want to do similar things so they have to be compared at the parts where they overlap. On the discussion forum it was pointed out that the two proposals are not mutually exclusive and that the area of overlap might be rather small. The term SLPv2 has also been used -somewhat prematurely- to describe the new token protocol.

Unlike the first 5 smaller upgrades to the smart contract language which everybody seems to be in agreement about, there's been mixed opinions regarding Group tokenization. There's been discussion about how big a change each of these proposals is to accurately evaluate the cost for implementing and maintaining it etc. and it seems the group tokenization and PMv3 are larger changes than the other ones so it will have to be seen if they reach sufficient-near unanimous- agreement amongst the technical people and can be implemented in time by all node teams.

Hopefully you are now better informed as to what is being worked on for the next Bitcoin Cash upgrades and how it all revolves around smart contract capabilities! If I missed anything important or got something wrong, feel free to leave it in the comments below!