matt-nervos

1. Instead of storing the MMR root (the hash of all current peaks), we can store an array of peaks (if there is not a peak at the position, value is null, otherwise value is merkle root of peak). This will reduce the amount of witness data required for updating the MMR and make it easier to prove values in it by scripts running on CKB. You can find (Solidity-ish) code for appending to the MMR here, and rolling it back in the Appendix. Access to all historical blocks seems important for unforseen use cases of the CKB BTC SPV client.

   1. An MMR is self describing, using the current height and index being proved, exactly which Merkle tree root in the array is needed for the proof can be discerned, as well as the L|R orientation of the hashes in the proof.

2. Only a block's transaction root hash is required for proving history, the MMR should be a list of transaction root hashes, this also reduces witness data needed for proofs. In the case of a re-org, th

matt-nervos

Compiling CKB Contracts using alternate C compilers

Unlike some other blockchains, CKB is designed to use strictly standard-compliant RISC-V ISA as its language for building smart contracts. There was a period where we have to maintain forked toolchains since RISC-V was still an immature platform back then, but the ultimate goal has always been to use standard RISC-V compilers / toolchains when building CKB smart contracts. I did some checks back in 2022, it seems some tweaks were still needed back then. Now in 2023, the software story of RISC-V has progressed tremendously over the past few years. It’s now the time to revisit the questions here:

• Can we use standard RISC-V compilers / toolchains to build CKB smart contracts?
• More specifically, there are more C compilers other than gcc alone in the ecosystem, can we use other C compilers to build CKB smart contracts?

Compiling C