Closed paberr closed 5 years ago
jgraef
commented
5 years ago I would suggest a seperate crate for the standalone application. This would handle command line argument parsing, reading configuration files and then actually running the node.
The advantage is that I can use the core as a library and write special purpose applications with it, but at the same time have a crate that actually spits out a binary that runs a normal node.
paberr
commented
5 years ago The current progress can be found in the paberr/structure branch. My plan is to finish most of the restructuring before February 1.
paberr
commented
5 years ago
chain(everything related to blocks and transactions) or should transaction get its own sub-crate?
After some consideration, I think transaction should be its own sub-crate.
I can imagine some applications that simply want to create transactions and transfer them to external parties that relay it to the network. In these cases, no knowledge of blocks etc. is needed.
EDIT: as an alternative, we could put all blockchain related data structures into a single sub-crate and introduce feature flags for the separate parts (i.e. blocks, accounts, transactions). Then, one can choose which parts to include. 👍 👎 ?
message(all messages)
For message, I am still not sure. For a different implementation of the network, it might make sense to have this in a separate crate.
~I cannot imagine a use case where I do not need the networking part, but somehow have access to messages/need to craft messages.~ Perhaps, someone building an app that only needs part of the network, e.g. to connect to a single node and push out some messages.
paberr
commented
5 years ago New structure has been established and will be merged in a few minutes into master. Thanks to @jgraef for his help!
Currently, it is very cumbersome to use/debug only parts of the implementation. The main reason for that is almost all code residing in the main project source.
I propose to make use of more sub-crates (similar to parity-bitcoin). This also helps cleaning up unwanted dependencies. Currently, for example, our consensus module has dependencies on the network module. It also speeds up compilation and testing, when only some parts were changed. Finally, it allows us to compile relevant parts of it to WebAssembly.
As there are many ways to divide the current code into sub-crates, this issue is meant for discussion about how to structure those.
My proposal would be something like:
db(database layer) ✅hash(hashes, non-key related cryptography) ✅keys(private keys, signatures, address,...) ✅primitives(Target, Coin, Compact, everything related to blocks and transactions, contracts and basic accounts,...) ✅datastructures(Accounts, Blockchain, ChainStore and other concrete db stores) ✅consensus(Consensus, ConsensusAgent, Mempool) ✅mnemonic(mnemonics) ✅key-derivation(key derivation) ✅network(all networking) ✅network-primitives(primitives used in multiple locations) ✅core(putting things together, but no binary) (currently in main folder ✅)rpc(JSON-RPC) (to be merged)utils(most utils, configurable via feature flags) ✅Note: I just quickly wrote down this as a starting point. Looking forward to your ideas. :) Those that I already created are marked with ✅. Those that are currently in progress are marked with ☑️.