Set JD Mode from config

[Shourya742]

closes: #179

[GitGab19]

Why are we setting the mode in the handle_setup_connection_success?

JDC should get the mode from config at bootstrap, and then use its value to properly set the DECLARE_TX_DATA flag in the SetupConnection to be sent to the JDS.

Ref: https://github.com/stratum-mining/sv2-spec/blob/main/06-Job-Declaration-Protocol.md#641-setupconnection-flags-for-job-declaration-protocol

[Shourya742]

This is subtle. I also recollected this while looking into the code, I had kind of forgotten how the fallback and upstream + JDS invariants work. Let me explain.

If we look at the construction of the SetupMessage for the JobDeclarator, we can see the inclusion of self.mode in the message constructor:

sv2-apps/miner-apps/jd-client/src/lib/job_declarator/mod.rs

Line 208 in 8592ebe

let setup_connection = get_setup_connection_message_jds(&self.socket_address, &self.mode);

. This mode comes from the config. The JdMode we are seeing in the SetupConnection.Success handler is the runtime mode in which the JDC is currently running.

During its execution lifetime, the JDC can have two possible mode values:

1. The one it gets from the config
2. and, solo mining.

The SetupConnection.Success from the JDS is the last message in the upstream connection or fallback flow, after which we consider that the upstream is not malicious and is fit for processing. That’s the reason why we set JDMode here. Earlier, we were setting JDMode based on the flag received in the success message. In contrast, now it is being set based on self.mode, which is the mode we get from the config.

[GitGab19]

Why can't we set the value to this JDMODE during the initial bootstrapping, but we have to set it in the handler here?

[Shourya742]

Because JDMode is a runtime value, it drives the control flow of the JDC. Its value can transition from SoloMining → FullTemplate / CoinbaseOnly → … and so on, and may change again if a fallback happens at any point in between. I recall that we discussed this behavior while developing the JDC.

[GitGab19]

But why can't we start JDC by setting its JDMODE with the value coming from config, instead of starting it from SoloMining mode?

Now I don't remember the old discussions about this.

[Shourya742]

The rationale is that JDMode should always be in a valid state. Until the mode specified in the config is confirmed (by successfully connecting to the upstream), the JDC should not operate in a partially initialized or inconsistent mode.

[GitGab19]

IMO we should start JDC in the mode which is set in the config, without starting it in SoloMining mode besides of the mode.

Then if we cannot connect to the upstream, or we get an error from it, we trigger fallback.

In the future we could eventually add SoloMining as a new mode variant, which can be used by users who want to do solo-mining using JDC.