Increase portability for v0.10
dr-orlovsky opened this issue · comments
I plan to dramatically increase portability of the new release, including support for WASM builds, by reducing number of dependencies - and getting rid of all C-libraries downstream. Specifically, I plan to:
- Remove any dependencies on
rust-miniscript, since this consensus library must not touch anything wallet-related - Remove
secp256k1dependency, since this library doesn't do anything to public or private keys outside of bulletproffs/pedenrsen commitments, which anyway are not a part ofsecp256k1 - In order to do that we would also need to abandon
rust-bitcoinlibrary (which requires secp256k1), but this is nice, since again, only a very few structures from rust-bitcoin are used in RGB core and in single-use-seals and they can be replaced with local vatiants. We do not use transactions, keys etc - just txids and output numbers, which is highly trivial and for sure shouldn't requirerust-bitcoindependency tree. - We also can get rid of
descriptor-walletdependency here, since again RGB Core has nothing to do with any wallet-level stuff. - I plan to revisit and remove any other possible dependencies on lightning-related and generic things, which shouldn't belong here;
- The most problematic part is to remove
secp256k1-zkpfork which requires C lib, breaks WASM compillation and is needed for bulletproofs. But I think this is also possible and I am opening a separate issue to discuss on the best way of achieving that (UPD: #130).
All these changes should significantly speed up compilation time - and also allow us to have a good progress toward ossification and v1.0 release: without rust-bitcoin family of dependencies we would not need to re-factor everything each new release and do a new version. RGB Core would become pure consensus library not requiring regular releases - and the release cycle of RGB standard library, RGB Node and LN-/wallet-related stuff can become fully independent (and much shorter) with that. I.e. version v0.10 of RGB Core should become the last version for at least this year (unless a major bugs are discovered); after which we can move to v1.0 of it.
I think this is a good decision; since we're using BDK for wallet stuff, it's often difficult to upgrade RGB due to the mutual rust-bitcoin dependency. All three had to be updated at once.
As for bulletproofs, have you received any updates from the Blockstream folks? Is there anything @fedsten or @Gigi3d at DIBA can do to help that along from the business side?
This also would help RGB Core to become no-std and be able to run on hardware wallets.
My expectation that the proposal would allow to go from this list of consensus-level libraries (plus their upstream dependencies):
- secp256k1 (C-based)
- bitcoin_hashes
- rust-bitcoin
- rust-miniscript
- rust-electrum
- amplify
- lnpbp_secp256k1zkp (C-based, non-WASM)
- strict_encoding
- stens
- aluvm
- commit_verify
- single_use_seals
- client_side_validation
- bitcoin_blockchain
- bitcoin_scripts
- bitcoin_hd
- descriptors
- bitcoin_online
- psbt
- descriptor-wallet
- lnpbp_bech32
- lnpbp_chain
- bp-dbc
- bp-seals
- rgb-core
to this list:
- amplify
- strict_encoding
- strict_types
- aluvm
- commit_verify
- single_use_seals
- bitcoin_scripts
- bp-dbc
- bp-seals
- rgb-core
25 vs 10 libraries; and in 25 libs there were 6 which are not maintained by LNP/BP + 2 C libs, including one WASM-compatible. Wit this proposal we are getting rid of all those external legacy
Much better! This will also streamline review, publishing, and a security audit, in addition to the portability improvements.
Also, I Just ran into a case today where I could've made use of this, since there are data structures returned from RGB like rgb_std::Disclosure that we can't really decode in WASM right now, see:
So we basically have to return double-encoded (unparsable) JSON, which is ugly and useless.
where I could've made use of this
Sorry, not clear, use of what?
where I could've made use of this
Sorry, not clear, use of what?
RGB structs that can compile to WASM so I can deserialize them on the frontend.
But why some of RGB structs can't compile to wasm? Because they depend/contain bulletproof data? Or any other reason?
The crates I get them from (like rgb_std) depend on stuff like Amplify; I forget if you were able to fix that, but if you did, maybe the latest version isn't being used by the 0.9 rc crates we're using.
Amplify was fixed, but probably v0.9 are not on the latest version, yes.