I wrote a proof-of-concept contract for Bitcoin Cash in archive/rps-demo/contract-manual.bch.
There are many challenges to targeting Bitcoin Cash:
We have to stand up yet another infrastructure.
We don't count GAS, we count opcodes; there are no backjumps and no loops in code fragments, no calls. "Function calls" are inlined.
As a rule, no data item can exceed 520 bytes. Each continuation must be explicitly included as data with its code in extenso (whereas data can be replaced by a 20-byte cryptographic commitment rather than necessarily included in extenso). Thus, each code fragment must be 500 bytes or fewer. Additionally, there is also a 201 limit on non-push opcode, whether executed or not. There is also a limit of only up to 25 fragments that can be chained in a given 10-minute block. Administrative costs will dominate.
Just currying data onto a continuation is already almost 100 bytes, 60% of it code.
Native arithmetic is 31-signed only, with no MIN_INT. To do more, we have to propagate carries manually on 24-bit additions or 12-bit multiplications, etc., but that is code-intensive and code is at a premium. Supporting this kind of arithmetic will probably force us to have some kind of size-based or interval-based types for integers, maybe even parametrized such types to work on multiple blockchains.
In simple cases, especially as far as payouts are concerned, we can precompute all possibilities of data before the first transaction and cryptographically commit to them, but this strategy doesn't resist combinatorial explosion, while requiring extra logic in our compiler.
There is quite a decent chance that if we demonstrate value, we can convince BCH hackers to lift some of the limitations currently in place; but even if true, that will take many months.
We can probably learn a lot from spedn, a language for BCH "covenants", and maybe even use it as target language.
My opinion is that the arithmetic situation by itself is a huge mess that we need to overcome for a complete system, but not for a proof-of-concept based on which we could attract funding from BCH whales. Meanwhile the rest is a SMOP, but will still take us back several weeks.
Optimizations:
Eliminating code duplication becomes very important, due to the constraints.
One optimization I manually did was to consider that in some cases, the poster gets all the money in the contract, at which point we do NOT need to verify the output (and actually, do not even need to have a checkdatasig'able preimage as input, which would be another optimization).
Instead of emulating 51-bit arithmetics for the full range of bitcoin amounts (which could be 24+27 bit for a decomposition in two operations with easy carry), I cheated and trivialized arithmetics by doing native 31-bit arithmetics in units of 256 satoshi (shifted one byte), reaching a range of ~2.4M$ max with .0019$ increment. This is a human decision that makes sense in terms of what the amounts mean at this time, but isn't easily automatable.
An optimization I did NOT do is that when the continuation fits in the current fragment's code, it might be better to include it in extenso rather than refer to it through a hash. More generally, code and data should be inlined when there is space, or refered to if there isn't.
I wrote a proof-of-concept contract for Bitcoin Cash in
archive/rps-demo/contract-manual.bch.There are many challenges to targeting Bitcoin Cash:
We can probably learn a lot from spedn, a language for BCH "covenants", and maybe even use it as target language.
My opinion is that the arithmetic situation by itself is a huge mess that we need to overcome for a complete system, but not for a proof-of-concept based on which we could attract funding from BCH whales. Meanwhile the rest is a SMOP, but will still take us back several weeks.
Optimizations: