feat: github pages with MD docs, swagger UI for Signer API

Author: Mihail Kirov

docs/architecture-core-commit-boost.md

@@ -0,0 +1,6 @@
+# Core Commit-Boost
+Below is a schematic of Commit-Boost. This proposed architecture allows proposers to run one sidecar, but still retain the ability to opt into a network of proposer commitment modules. More specifically, with this middleware, the proposer will only need to (in the case of delegation) run one sidecar and limits their responsibilities to only selecting which module / proposer commitment protocol they would like to subscribe to.
+
+It is important to note that the below depiction contains just a few examples of proposer commitment modules that can run on Commit-Boost. The design space for modules is completely open / not gated by the Commit-Boost software. The Commit-Boost software also does not come with modules (these are developed by teams outside of the Commit-Boost software), proposers will be responsible for opting into the commitments they wish to subscribe to (i.e., a proposer is responsible for which modules they will subscribe to).
+![architecture](commit-boost.png)
+Using this as a middleware instead of direct modification to the consensus client or running a sidecar per commitment will allow for each component to be sustained independently and will provide for cross proposer commitment compatibility.

docs/architecture.md

@@ -0,0 +1,4 @@
+# Architecture
+The following are schematics and details around Commit-Boost.
+1. [Core Commit-Boost](architecture-core-commit-boost.md)
+2. [Terminology](terminology.md)

docs/architecture.png

@@ -0,0 +1,7 @@
+# Background
+- Proposer commitments have been an important part of Ethereum’s history and could continue to be a powerful unlock for Ethereum
+- Today, we already see the power of commitments where nearly 90% of validators currently make a wholesale commitment that outsources block building to a sophisticated actor called a block builder (facilitated by a software called MEV-Boost)
+- However, a wholesale commitment gives away the proposer’s autonomy over the block. Many are starting to realize that if proposers could make more granular commitments, there is a significant design space and opportunity for Ethereum and its validators
+- On the surface, all the efforts around proposer commitments are a unlock for Ethereum, with most starting to agree on a common denominator: in the future, validators will face a broader set of options of what they may “commit" to
+- While this all seems great, the challenge is that this already is and will continue to drive fragmentation and risks for Ethereum and proposers
+- Commit-Boost is aimed to standardize proposer commitment protocols communication with the proposer with unification behind one sidecar helping to reduce the risk of fragmentation

docs/background.md

@@ -0,0 +1,53 @@
+# Communicating with the Signer Module
+The core of any commitment module is its interaction with the signer API. 
+Note:  Below examples will show snippets in Rust, however any language that allows for instantiation of an http client will work.
+Note: A more complete example of the Signer Module usage can be found here
+## Authentication 
+Communication between the proposer commitment module and Commit-Boost is authenticated with a JWT token. This token will be provided as `CB_JWT_<MODULE_NAME>` by the Commit-Boost launcher at initialization time.
+To discover which pubkeys a commitment can be made for call `/signer/v1/get_pubkeys`:
+```use serde::Deserialize;
+
+#[derive(Deserialize)]
+pub struct GetPubkeysResponse {
+    pub consensus: Vec<BlsPublicKey>,
+    pub proxy: Vec<BlsPublicKey>,
+}
+
+let url = format!("{}/signer/v1/get_pubkeys", COMMIT_BOOST_HOST);
+
+let pubkeys = reqwest::get(url)
+    .await
+    .unwrap()
+    .json::<GetPubkeysResponse>()
+    .unwrap()
+    .consensus;```
+Once you'd like to receive a signature to create a commitment, you'd create the request like so:
+```use serde_json::json;
+use alloy_rpc_types_beacon::BlsSignature
+
+#[derive(Debug, Clone, Serialize, Deserialize)]
+pub struct SignRequest {
+    pub id: String,
+    pub pubkey: BlsPublicKey,
+    pub is_proxy: bool,
+    pub object_root: [u8; 32],
+}
+
+let sign_request_body = json!({
+	    "id": "0",
+	    "pubkey": "0xa02ccf2b03d2ec87f4b2b2d0335cf010bf41b1be29ee1659e0f0aca4d167db7e2ca1bf1d15ce12c1fac5a60901fd41db",
+	    "is_proxy": false,
+	    "object_root": "your32commitmentbyteshere0000000"
+	});
+
+let url = format!("{}/signer/v1/request_signature", COMMIT_BOOST_HOST);
+let client = reqwest::Client::new();
+let res = client
+	.post(url)
+	.json(sign_request_body)
+	.send()
+	.await
+	.unwrap();
+	
+let signature_bytes = res.bytes().await.unwrap();
+let signature = BlsSignature::from_slice(&signature_bytes);```

docs/commit-boost.png

@@ -0,0 +1,3 @@
+1. [Setting up a lean custom module in Rust](setup-module.md)
+1. [Set up metrics reporting in custom module](metrics-reporting.md)
+2. [Communicating with the Signer Module](communicating-with-signer.md)

docs/communicating-with-signer.md

@@ -0,0 +1,16 @@
+html {
+    box-sizing: border-box;
+    overflow: -moz-scrollbars-vertical;
+    overflow-y: scroll;
+}
+
+*,
+*:before,
+*:after {
+    box-sizing: inherit;
+}
+
+body {
+    margin: 0;
+    background: #fafafa;
+}