aspect
commented
6 months ago This has been discussed in-depth. There are a number of crates that are not a part of the main daemon and framework pipeline, so they don't affect stability or security of the core daemon.
WASM bindings are an integral part of the framework as they expose internal consensus functionality. It is not possible to move them out of the project due to reference dependencies. In fact to address this problem we had to scatter WASM bindings across all respective modules. (kind of hard to explain, but feel free to ping me on discord if u want a more detailed explanation).
KOS and CLI are internal tools used for testing, especially in the context of the framework functioning in the native and in the web+NodeJS environments.
Wallet framework is complimentary to the consensus layer. Due to performance considerations Rusty Kaspa is unable to provide certain information such as transaction information. It only provides UTXO information. The wallet framework provides tools that re-integrate this information within a context of the client. (I.e. unlike base layer that provides UTXO changes, the wallet framework provides transaction data - you receive not UTXOs but transactions made up of UTXOs). Send yourself a transaction made out of multiple UTXOs and you will see the issue I am describing. Most of the wallets treat UTXOs as transactions, which is not correct. Also the wallet framework provides Transaction Generator module that automates transaction creation for any number of UTXOs, which is difficult for anyone to do properly.
Last, but not least, within the context of a single workspace, all changes to the framework, consensus and RPC are reflective. Meaning that if developers make any changes to any data structures the workspace fails to compile as a whole, allowing us to address changes that would otherwise be isolated and will be cascading in nature, meaning that changes made in consensus framework could render dependency projects inoperable until they are fixed. I have a number of external crates and changes to the framework result in them breaking on regular basis.
There is no miner in the framework. The PoW-related functions are integral to consensus.
If you have any specific issues or concerns regarding the reasons you are asking about this, please be more specific. Security and stability of the framework as a whole is extremely important, however it is also important to understand that there are layers to the framework where the consensus layer is an isolate in these regards (at the same time these considerations apply to the framework as a whole). There are two key elements to the repository: the workspace and crates within this workspace. Daemon and consensus crates albeit located in the same workspace do not interact with other framework crates, but rather use them as dependencies.
Keeping the main codebase clean as much as possible could be good for security and stability reasons.