Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JD Client README file retouched #800

Merged
merged 15 commits into from
Apr 5, 2024
46 changes: 21 additions & 25 deletions roles/jd-client/README.md
Original file line number Diff line number Diff line change
@@ -1,38 +1,34 @@
# JD Client
The JD Client is a Sv2 proxy that support one extended channel upstream and one extended channel
dowstream, and do job declaration. On start it will:

* connect to the jd-server
* connect to the template-provider
* listen for and `OpenExtendedChannel` from downstream
The JD Client receives custom block templates from a Template Provider and declares use of the template with the pool using the Job Declaration Protocol. Further distributes the jobs to Mining Proxy (or Proxies) using the Job Distribution Protocol. ```
* transparently relay the `OpenExtendedChannel` to upstream
After the setup phase it will start to negotiate jobs with upstream and send the negotiated job
downstream, so that everything that is dowstream do not need to know that job is negotiated.

## Setup

### Configuration File
The `proxy-config-example.toml` is a configuration example.

The configuration file contains the following information:

1. The Upstream connection information which includes the SV2 Pool authority public key
(`upstream_authority_pubkey`) and the SV2 Pool connection address (`upstream_address`) and port
(`upstream_port`).
2. The maximum and minimum SV2 versions (`max_supported_version` and `min_supported_version`)
3. The Job Declarator information which includes the Pool JD connection address (`jd_address`) and the Template Provider connection address to which to connect (`tp_address`).
4. Optionally, you may want to verify that your TP connection is authentic. You may get `tp_authority_public_key` from the logs of your TP, for example:
```
1. The downstream socket information, which includes the listening IP address (`downstream_address`) and port (`downstream_port`).
2. The maximum and minimum SRI versions (`max_supported_version` and `min_supported_version`) with size as (`min_extranonce2_size`)
3. The authentication keys for the downstream connection (`authority_public_key`, `authority_secret_key`)
4. A `retry` parameter which tells JDC the number of times to reinitialize itself after a failure.
6. The Template Provider address (`tp_address`).
7. Optionally, you may want to verify that your TP connection is authentic. You may get `tp_authority_public_key` from the logs of your TP, for example:
plebhash marked this conversation as resolved.
Show resolved Hide resolved

plebhash marked this conversation as resolved.
Show resolved Hide resolved
# 2024-02-13T14:59:24Z Template Provider authority key: EguTM8URcZDQVeEBsM4B5vg9weqEUnufA8pm85fG4bZd
```

### Run
1. Copy the `jdc-config-example.toml` into `conf/` directory.
2. Edit it with custom desired configuration and rename it `jdc-config.toml`
3. Point the SV1 Downstream Mining Device(s) to the Translator Proxy IP address and port.
4. Run the Translator Proxy:

```
cd roles/translator
```
```
cargo run -p translator_sv2 -- -c conf/jdc-config.toml
```

Run the Job Declarator Client (JDC):
There are two files when you cd into roles/jd-client/config-examples/

1. `jdc-config-hosted-example.toml` connects to the community-hosted roles.
2. `jdc-config-local-example.toml` connects to self-hosted Job Declarator Client (JDC) and Translator Proxy

``` bash
cd roles/jd-client/config-examples/
cargo run -- -c jdc-config-hosted-example.toml
```
Loading