Roles Refactoring

[jbesraa]

• Public API

  • Design public API for all roles
  • What are the public functions
  • What is the signature of each public function
  • Should public functions be sync or async
  • Investigate which functionality is missing to implement public API
  • Implement public API

• Runtime/Threading

  • Obtain more control over the runtime by explicitly starting it and not rely on tokio::main
    • Investigate runtime setup in roles #1390
  • Use the runtime for starting async/threading jobs

• Networking

  • Remove async-channel and use tokio channels instead
    • Move away from async-channel #1389
  • Use tokio for any networking task/struct instead of std or other crates

• Mutex/Lock behavior

  • Don't lock full structs with Mutex lock
  • Lock only data that need to mutated in Mutex
  • Consider using tokio's Mutex

• Common Code

  • Maintain stratum-common crate
  • Undo bitcoin export from stratum-common, it should be exported from the crates requiring it
  • Move common structs and other code to stratum-common
  • Consider making roles-logic-sv2 and stratum-common a single crate

• Configurations

  • Roles should be configurable on start
  • Roles should be configurable while running
  • Investigate different options (RPC etc)

• Documentation

  • Document current and any new publicly available function/struct, adhering to the same roles set when protocol crates doc were written

[jbesraa]

@GitGab19 @plebhash @Shourya742 here is a start for roles code-debt, what I think should be included in refactoring. We can explain each point further, but maybe it would be best to priorities them first and then elaborate in a new issue created for any planned point from here.

[Shourya742]

1. Can we switch to clap for the CLI? Right now, we’re using basic argument parsing, which works but feels a bit clunky. clap could make things a lot better, which would make the CLI much more user-friendly.
2. Since the roles module is meant to be a library, I’m wondering how we should handle the runtime for the parent process that uses it. If we bundle our own Tokio runtime in the crate, it could cause issues, like conflicts with multiple runtimes, which Tokio doesn’t support well. I think it’d be better to expose abstractions that let the parent runtime manage the tasks we spawn. This way, we avoid conflicts and give more flexibility to whoever’s using the library.
3. About tokio::Mutex, even the Tokio team advises against using it in high-traffic paths because it can cause thread contention and slow things down.
   The rest looks great! Let me know what you think. 🚀