create v0.9.6 and v0.10.0-rc2 versioned docs

Author: JasonVranek

docs/docs/developing/commit-module.md

@@ -0,0 +1,132 @@
+---
+sidebar_position: 2
+---
+
+# Commit Module
+
+While a module can be written in any language, we currently provide some utilities for Rust, with the goal of supporting more generalized APIs and simplify development in languages other than Rust.
+
+In Rust, we provide utilities to load and run modules. Simply add to your `Cargo.toml`:
+```toml
+commit-boost = { git = "https://github.com/Commit-Boost/commit-boost-client", version = "..." }
+```
+
+You will now be able to import the utils with:
+```rust
+use commit_boost::prelude::*;
+```
+
+
+## Config
+Your module will likely need a configuration for the Node Operator to customize. This will have to be in the `cb-config.toml` file, in the correct `[[module]]` section. In the module, you can define and load your config as follows.
+
+First, define all the parameters needed in a struct:
+```rust
+#[derive(Debug, Deserialize)]
+struct ExtraConfig {
+    sleep_secs: u64,
+}
+```
+then pass that struct to the `load_commit_module_config` function, which will load and parse the config. Your custom config will be under the `extra` field.
+
+```rust
+let config = load_commit_module_config::<ExtraConfig>().unwrap();
+let to_sleep = config.extra.sleep_secs;
+```
+
+The loaded `config` also has a few other useful fields:
+- the unique `id` of the module
+- chain spec
+- a `SignerClient` to call the [SignerAPI](/api), already setup with the correct JWT
+
+
+## Requesting signatures
+At its core the Signer Module simply provides a signature on a 32-byte data digest. The signatures are currently provided with either the validator keys (BLS) or a proxy key (BLS or ECDSA) for a given validator key, both on the [builder domain](https://github.com/Commit-Boost/commit-boost-client/blob/main/crates/common/src/signature.rs#L88-L96).
+
+In the example we use `TreeHash`, already used in the CL, to create the digest from a custom struct:
+```rust
+#[derive(TreeHash)]
+struct Datagram {
+    data: u64,
+}
+```
+
+Furthermore, in order to request a signature, we'd need a public key of the validator. You can get a list of available keys by calling:
+```rust
+let pubkeys = config.signer_client.get_pubkeys().await.unwrap();
+```
+
+Which will call the `get_pubkeys` endpoint of the [SignerAPI](/api), returning all the consensus pubkeys and the corresponding proxy keys, of your module.
+
+Note that the requests are authenticated using a JWT, that must be regularly refreshed as it expires after a certain time. To do so, you can call:
+```rust
+config.signer_client.refresh_token().await.unwrap();
+```
+You have the `SIGNER_JWT_EXPIRATION` constant available in the `commit-boost` crate, which is the time in seconds after which the JWT will expire.
+
+Then, we can request a signature either with a consensus key or with a proxy key:
+
+### With a consensus key
+Requesting a signature is as simple as:
+```rust
+let datagram = Datagram { data: 1 };
+let request = SignConsensusRequest::builder(pubkey).with_msg(&datagram);
+let signature = config.signer_client.request_consensus_signature(&request).await.unwrap();
+```
+
+Where `pubkey` is the validator (consensus) public key for which the signature is requested.
+
+### With a proxy key
+You'll have to first request a proxy key be generated for a given consensus key.
+We support two signature schemes for proxies: BLS or ECDSA.
+
+To request a proxy:
+```rust
+// BLS proxy
+let proxy_delegation = self.config.signer_client.generate_proxy_key_bls(pubkey).await?;
+let proxy_pubkey = proxy_delegation.message.proxy;
+
+// or ECDSA proxy
+let proxy_delegation = self.config.signer_client.generate_proxy_key_ecdsa(pubkey).await?;
+let proxy_address = proxy_delegation.message.proxy;
+```
+
+Where `pubkey` is the validator (consensus) public key for which a proxy is to be generated.
+
+Then you can use the generated proxy key to request a signature:
+```rust
+// if `proxy_pubkey` is a BLS proxy
+let datagram = Datagram { data: 1 };
+let request = SignProxyRequest::builder(proxy_pubkey).with_msg(&datagram);
+let signature = config.signer_client.request_proxy_signature_bls(&request).await.unwrap();
+
+// or for ECDSA proxy
+let datagram = Datagram { data: 1 };
+let request = SignProxyRequest::builder(proxy_address).with_msg(&datagram);
+let signature = config.signer_client.request_proxy_signature_ecdsa(&request).await.unwrap();
+```
+
+## Metrics
+We provide support for modules to record custom metrics which are automatically scraped by Prometheus. This involves three steps
+### Define metrics
+You can use the `prometheus` crate to create a custom registry and metrics, for example:
+
+```rust
+static ref MY_CUSTOM_REGISTRY: Registry = Registry::new_custom(Some("da_commit".to_string()), None).unwrap();
+static ref SIG_RECEIVED_COUNTER: IntCounter = IntCounter::new("signature_received", "successful signature requests received").unwrap();
+```
+
+### Start Metrics Provider
+When starting the module, you should register all metrics, and start the `MetricsProvider`:
+```rust
+MY_CUSTOM_REGISTRY.register(Box::new(SIG_RECEIVED_COUNTER.clone())).unwrap();
+MetricsProvider::load_and_run(MY_CUSTOM_REGISTRY.clone());
+```
+The `MetricsProvider` will load the configuration needed and start a server with a `/metrics` endpoint for Prometheus to scrape.
+
+### Record metrics
+All that is left is to use the metrics throughout your code:
+```rust
+SIG_RECEIVED_COUNTER.inc();
+```
+These will be automatically scraped by the Prometheus service running, and exposed on port `9090`. We plan to allow developers to ship pre-made dashboards together with their modules, to allow Node Operators to have an improved oversight on the modules they are running.

docs/docs/developing/custom-modules.md

@@ -0,0 +1,12 @@
+---
+sidebar_position: 1
+---
+
+# Custom Modules
+
+Commit-Boost aims to provide an open platform for developers to create and distribute commitment protocols sidecars.
+
+There are two ways to leverage Commit-Boost modularity:
+
+1. Commit Modules, which request signatures from the proposer, e.g. for preconfirmations ([example](https://github.com/Commit-Boost/commit-boost-client/tree/78bdc47bf89082f4d1ea302f9a3f86f609966b28/examples/da_commit)).
+2. PBS Modules, which tweak the default PBS Module with additional logic, e.g. verifying additional constraints in `get_header` ([example](https://github.com/Commit-Boost/commit-boost-client/tree/78bdc47bf89082f4d1ea302f9a3f86f609966b28/examples/status_api)).

docs/versioned_docs/version-0.10.0-rc2/architecture/img/architecture.png

@@ -0,0 +1,15 @@
+---
+description: Overview of the architecture of Commit-Boost
+---
+
+# Overview
+
+Below is schematic overview of Commit-Boost.
+
+Commit-Boost runs as a single sidecar composed of multiple modules:
+- Pbs Service with the [BuilderAPI](https://ethereum.github.io/builder-specs/) for [MEV Boost](https://docs.flashbots.net/flashbots-mev-boost/architecture-overview/specifications)
+- A Signer Service implementing the SignerAPI
+- Commit Modules that implement some custom commit protocol logic
+- Telemetry modules like Prometheus and Grafana
+
+![architecture](./img/architecture.png)

docs/versioned_docs/version-0.10.0-rc2/architecture/overview.md

@@ -0,0 +1,161 @@
+---
+sidebar_position: 1
+---
+
+# Commit Modules
+
+Commit-Boost provides an open platform for developers to create and distribute commitment protocol sidecars. **Commit Modules** are the primary way to add custom logic — they run as sidecar processes alongside the PBS and Signer services, and can request signatures from the proposer.
+
+> **For system context**, see the [Architecture Overview](../architecture/overview.md).
+
+## Config entry
+
+Each commit module is declared in the `cb-config.toml` file under a `[[modules]]` entry:
+
+```toml
+[[modules]]
+id = "DA_COMMIT"
+type = "commit"
+docker_image = "my-module-image"
+signing_id = "0x6a33a23ef26a4836979edff86c493a69b26ccf0b4a16491a815a13787657431b"
+```
+
+| Field | Description |
+|---|---|
+| `id` | A unique identifier for the module (used for JWT scoping and container naming). |
+| `type` | **Must be `"commit"`.** This is the only valid value. |
+| `docker_image` | The Docker image to run for this module. |
+| `signing_id` | A 32-byte identifier used to scope signatures to this module (see [Signing structure](#signing-structure)). |
+| (custom) | Additional fields are passed through as opaque config to the module's runtime. |
+
+:::warning
+Setting `type = "pbs"` in a `[[modules]]` entry is **not** a supported path. The configuration parser will reject it at parse time. If you want to extend the PBS binary itself, see [Extending PBS](./extending-pbs.md).
+:::
+
+
+
+## Rust SDK usage
+
+While a module can be written in any language, we provide Rust utilities to simplify loading and running modules. Add to your `Cargo.toml`:
+
+```toml
+commit-boost = { git = "https://github.com/Commit-Boost/commit-boost-client", version = "..." }
+```
+
+Import the prelude:
+
+```rust
+use commit_boost::prelude::*;
+```
+
+### Loading module config
+
+Your module will likely need a configuration section for the Node Operator to customize. Define it as a struct and pass it to `load_commit_module_config`:
+
+```rust
+#[derive(Debug, Deserialize)]
+struct ExtraConfig {
+    sleep_secs: u64,
+}
+
+let config = load_commit_module_config::<ExtraConfig>().unwrap();
+let to_sleep = config.extra.sleep_secs;
+```
+
+The returned `StartCommitModuleConfig` also provides:
+- `id` — unique module ID
+- `chain` — chain spec
+- `signer_client` — a pre-configured `SignerClient` to call the [SignerAPI](/api)
+
+### Requesting signatures
+
+At its core, the Signer Service provides a signature on a 32-byte data digest. Signatures are provided using either the validator keys (BLS) or a proxy key (BLS or ECDSA), both on the [Commit-Boost domain](#signing-structure).
+
+Use `TreeHash` to create a digest from a custom struct:
+
+```rust
+#[derive(TreeHash)]
+struct Datagram {
+    data: u64,
+}
+```
+
+To request a signature, you need a public key. Get available keys:
+
+```rust
+let pubkeys = config.signer_client.get_pubkeys().await.unwrap();
+```
+
+JWT tokens are created and refreshed internally by `SignerClient` — each method generates a fresh token with the correct `route`, `exp`, and `payload_hash` claims automatically. No manual token management is needed.
+
+#### Consensus key signatures
+
+```rust
+let datagram = Datagram { data: 1 };
+let request = SignConsensusRequest::builder(pubkey).with_msg(&datagram);
+let signature = config.signer_client.request_consensus_signature(&request).await.unwrap();
+```
+
+Where `pubkey` is the validator (consensus) public key.
+
+#### Proxy key signatures
+
+First, generate a proxy key for a given consensus key. We support BLS and ECDSA:
+
+```rust
+// BLS proxy
+let proxy_delegation = config.signer_client.generate_proxy_key_bls(pubkey).await?;
+let proxy_pubkey = proxy_delegation.message.proxy;
+
+// ECDSA proxy
+let proxy_delegation = config.signer_client.generate_proxy_key_ecdsa(pubkey).await?;
+let proxy_address = proxy_delegation.message.proxy;
+```
+
+Then request a signature using the proxy key:
+
+```rust
+// BLS proxy
+let datagram = Datagram { data: 1 };
+let request = SignProxyRequest::builder(proxy_pubkey).with_msg(&datagram);
+let signature = config.signer_client.request_proxy_signature_bls(&request).await.unwrap();
+
+// ECDSA proxy
+let datagram = Datagram { data: 1 };
+let request = SignProxyRequest::builder(proxy_address).with_msg(&datagram);
+let signature = config.signer_client.request_proxy_signature_ecdsa(&request).await.unwrap();
+```
+
+### Signing structure
+
+For details on the signing structure — including domain separation, nonces, SSZ Merkle tree construction, and the signing ID format — see [Requesting Proposer Commitment Signatures](./prop-commit-signing.md).
+
+## Metrics
+
+Modules can record custom metrics that are automatically scraped by Prometheus.
+
+### Define metrics
+
+Use the `prometheus` crate:
+
+```rust
+static ref MY_CUSTOM_REGISTRY: Registry = Registry::new_custom(Some("da_commit".to_string()), None).unwrap();
+static ref SIG_RECEIVED_COUNTER: IntCounter = IntCounter::new("signature_received", "successful signature requests received").unwrap();
+```
+
+### Start the metrics provider
+
+```rust
+MY_CUSTOM_REGISTRY.register(Box::new(SIG_RECEIVED_COUNTER.clone())).unwrap();
+MetricsProvider::load_and_run(MY_CUSTOM_REGISTRY.clone());
+```
+
+This starts a server with a `/metrics` endpoint on the configured port (default `9090`).
+
+### Record metrics
+
+```rust
+SIG_RECEIVED_COUNTER.inc();
+```
+
+For a full reference of available metrics, see the [Metrics catalog](../get_started/running/metrics.md) (once created; the Prometheus scrape target is already configured by the docker-init setup).

docs/versioned_docs/version-0.10.0-rc2/developing/commit-modules.md

@@ -0,0 +1,10 @@
+---
+sidebar_position: 3
+---
+# Environment setup
+
+## Dirk signer
+
+In order to test Commit-Boost with a Dirk signer, you need to have a running Dirk instance. You can find a complete step-by-step guide on how to setup one in the Dirk's docs [here](https://github.com/attestantio/dirk/blob/master/docs/distributed_key_generation.md).
+
+If you are using a custom certificate authority, don't forget to add the CA certificate to the TOML config under `signer.dirk.ca_cert_path`.