Fiendish & Friends episode is dead on Twitter but still available here on RSS for anyone like me who wants to review it.
1 Like
Regarding relocation of function references. The fact that the Functions CHIP moved away from having function references be integers (0-999) to instead allowing arbitrary byte strings (0 to 7 bytes in size) makes relocation much less likely to be needed. The VM only allows for one thousand functions, but the set of valid function identifiers is massive. This allows for name spacing. So a ZK verifier library (brought in via read-only inputs) could have all its functions prefixed with “zk” (reflected in its internal self references) and that way avoid conflict with function names in contracts using it.
2 Likes
I deployed a Proof of Concept for “external libraries as read-only inputs” on Chipnet:
-
TX that deploys the libraries and the contract:
- 9d4e2a4c0bc0a958352b397869a1c3ea6c5214a5ab515b9908f68637fe51cd21
-
TX that spends the funds in the contract:
- dd2896bfcbdab85422ffc388aa6fd6dfe4a8c1c771e25f090c4753cc5b291d8b
The contract uses functions that it imports from the library UTXOs. Since we don’t have read-only inputs on Chipnet the library UTXOs do get consumed. But this illustrates the concept.
More details here: AlbaDsl & albaVm: Haskell based DSL and VM for Bitcoin Cash 2025 contract programming - #34 by albaDsl
4 Likes
One thing which I would also like to see in a new transaction version (tx v5) is support for natively buying compute budget, without the need for empty byte padding to the transaction. I assume this would have to be a native field in the transaction structure for this.
I believe @bitcoincashautist has also brought it up that it is silly that densely compute-packed scripts need to bloat the tx size, which affects bandwith usage and storage, for no benefit to anyone.
We’d need to introduce the concept of “virtual bytes” which would be included in the compute budget calculation.
On verifier.cash, the benchmarking for BCH native Groth16 verifiers, i see that the zero-byte padding is currently 25% of the tx size for BN254 and 19% for Groth16 BLS12-381
note that these are the most simple ZKP constructions, this would be a floor measure for advanced contracts
5 Likes
Yeah buying additional bytespace instead of padding transactions seems like such a clear and obvious upgrade now that the VM limits have been set and people are using more advanced scripts with all the fresh OP_codes.