Description
Just opening an issue to document some long-standing performance issues related to Libauth's very unusual, sometimes-obsessive (😆), combinator-function-based approach to implementing virtual machines like the Bitcoin Cash VM.
I've made huge, ~100x performance improvements this year (identified by the benchmarks from the VM Limits & BigInt CHIPs 🚀), but there are still other performance issues based on how often we copy and/or re-create stack items.
It's easy to see where these issues are across the benchmarks: almost everything higher than Transaction validation benchmarks: Within BCH_2023_05 standard limits, 1-of-3 bare multisig input, 1 output (ECDSA signature, bottom slot) (nonP2SH) is spending the majority of it's time on garbage collection. For example, the worst case – y54lkh (Transaction validation benchmarks: Within BCH_2025_05 P2SH/standard, single-input limits, maximize OP_ADD operand bytes (P2SH20)):
You can see something like 75% of the time is spent on Javascript-y silliness, and if we really wanted to, we could cut that bigIntToVmNumber cost down to nearly zero by compiling BCHN's bigInt stuff to WASM. And honestly, there are probably ways to make it faster just in JS, but I haven't tried much.
Even this truly terrible case (y54lkh) is only ~2x worse than the comparably terrible vzvufa –Transaction validation benchmarks: Within BCH_2023_05 standard limits, packed 1-of-3 bare multisig inputs, 1 output (all ECDSA signatures, top slot) (nonP2SH). For that one, the root cause of terrible performance is a complete lack of simple caching behaviors: all portions of signing serialization hashing can be cached, and signature validation can be both deferred and results cached.
These have pretty straightforward optimizations, but I don't plan to work on them in the immediate future, just wanted to note that someone could, if anyone cared to make Libauth VMs even faster (they're plenty fast enough for per-keypress evaluation in Bitauth IDE, the most intense use right now). In so far as I needed to use the Libauth VM to verify the worst-case performance of various things in a naive, JS-based implementation (i.e. empirically verifying the Limits CHIP), Libauth has a great little VM, and I'm done now. 😂
Another probably better alternative, is to simply compile the BCHN virtual machine to WASM and expose it via Libauth – which I would love to do, both for testing purposes and as the basis for reasonably fast, in-browser, pruned nodes.