Merge pull request #22 from chainbound/docs/fiber-boost

FiberBoost docs

docs/usage/fiber-boost.mdx

@@ -0,0 +1,91 @@
+---
+sidebar_position: 4
+title: FiberBoost
+---
+
+import Tabs from "@theme/Tabs";
+import TabItem from "@theme/TabItem";
+
+FiberBoost is a service that broadcasts ("boosts") blocks through the Fiber Network for faster global propagation, resulting in a reduced probability of missed slots due to [proposer boost & honest reorgs](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus#proposer-boost--honest-reorgs). FiberBoost provides multiple interfaces to boost blocks:
+
+## gRPC API
+The most straightforward and performant way to publish a block to Fiber is through the gRPC API. The `PublishBlock` endpoint is a bi-directional gRPC stream that accepts **SSZ encoded, signed beacon blocks**. The blocks can optionally be compressed with gzip.
+
+Both [`fiber-go >= v1.8.0`](https://github.com/chainbound/fiber-go/releases/tag/v1.8.0) and [`fiber-rs >= v0.5.1`](https://github.com/chainbound/fiber-rs/releases/tag/v0.5.1) provide an implementation of this method with gzip compression:
+
+<Tabs>
+<TabItem value="go" label="Golang">
+
+```go
+import (
+	"context"
+	"fmt"
+	"log"
+	"time"
+
+    fiber "github.com/chainbound/fiber-go"
+)
+
+
+func main() {
+    // Connection process omitted
+    ...
+
+    // SSZ encoded, signed beacon block
+    beaconBlock := []byte{...}
+
+    ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
+	defer cancel()
+
+	// Returns the slot, root, and timestamp of the block, or a potential error
+    slot, root, timestamp, err := client.SubmitBlock(ctx, beaconBlock)
+    if err != nil {
+    	log.Fatal(err)
+    }
+
+    fmt.Println("Submitted block", slot, root, timestamp)
+}
+```
+
+</TabItem>
+
+<TabItem value="rs" label="Rust">
+
+```rust
+use bytes::Bytes;
+use fiber::{Client, api::BlockSubmissionResponse};
+
+#[tokio::main]
+async fn main() {
+    // Connection process omitted
+    // ....
+
+    // SSZ encoded, signed beacon block
+    let beacon_block = vec![...];
+
+    let result: BlockSubmissionResponse = client.publish_block(beacon_block).await.unwrap();
+
+    println!("Submitted block: {} {:#x} {}", block.slot, block.root, block.timestamp);
+}
+```
+
+</TabItem>
+</Tabs>
+
+## MEV-Boost
+Chainbound maintains an open-source, modified version of the [MEV-Boost](https://boost.flashbots.net) validator sidecar at [this repository](https://github.com/chainbound/mev-boost). The fork has a very minimal diff with the upstream Flashbots repository and follows the same release schedule. Track the diff [here](https://github.com/chainbound/mev-boost/pull/1).
+
+### How it works
+The following interaction diagram depicts the block proposal process using the modified MEV-Boost:
+![](/img/fiber-boost.png)
+**The main difference with normal MEV-Boost is that when it receives a `Payload` from the relay, it will reconstruct the full signed beacon block, SSZ encode it and publish it to Fiber.**
+
+If you're a validator running MEV-Boost, this is the easiest way to start using FiberBoost.
+
+### Running it
+Coming soon!
+
+## Direct Peering
+Just like with [FiberGuard](./fiber-guard), we offer a direct peering connection on the consensus layer for boosting blocks. This will mean that all blocks we receive on said connection will be boosted on our network.
+
+The requirements and setup procedure are the same as with FiberGuard, you can read them [here](./fiber-guard#requirements).

docs/usage/fiber-guard.mdx

@@ -13,7 +13,7 @@ This can result in a significant latency decrease compared to the standard P2P n
 
 ## Requirements
 :::note
-We assume that you've signed up for the FiberGuard plan and we have your peer ID and ENR registered in our system.
+We assume that you've signed up for the FiberGuard plan and we have your ENR registered in our system.
 To get this information about your node, you can query the following endpoint: `http://<beacon_node_api>/eth/v1/node/identity`.
 :::
 
@@ -88,7 +88,7 @@ With Prysm, you can add a trusted, static peer with the following flag:
 </TabItem>
 <TabItem value="teku" label="Teku">
 
-Teku provides multiple ways to add a static, trusted peer: https://docs.teku.consensys.net/development/reference/cli#p2p-static-peers. 
+Teku provides multiple ways to add a static, trusted peer: https://docs.teku.consensys.net/development/reference/cli#p2p-static-peers.
 
 The easiest way is to add the following CLI flag to the startup command:
 ```
@@ -127,4 +127,4 @@ The response should indicate a `connected` state like in the example response be
     "direction": "outbound"
   }
 }
-```
+```

docs/usage/fiber-inject.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 4
+sidebar_position: 6
 title: Mempool Injector
 ---
 
@@ -65,6 +65,10 @@ Fetch `enode` from output:
 14:51:44.811 INF [DEVP2P] Starting devp2p server               enode=enode://6e45ab02bc08b03da9527ef42e07e12d144eea3365b102b3d7f3b7a3f4ae0aed24a039d346af3a7e0e3c84257458af076e55e8860e262f551dab9d4e472f0fe3@127.0.0.1:30303?discport=0
 ```
 
+:::info
+Note that the injector's enode is hardcoded and will always be the same.
+:::
+
 #### 3. Add `enode` to your local node's trusted peerset
 
 :::info

docs/usage/streams_sub.mdx → docs/usage/subscriptions.mdx

@@ -6,7 +6,7 @@ title: Subscribing to Streams
 import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 
-## Transactions - `subscribeNewTxs`
+## Transactions
 
 :::note
 This method opens a subscription in the form of a gRPC stream
@@ -270,14 +270,14 @@ There's currently a limit of 16 filter elements or "nodes" in the filter tree.
 :::
 
 
-## Block Headers - `subscribeNewExecutionHeaders`
+## Block Headers
 
-`ExecutionHeaders` are the headers of the blocks that are part of the execution layer (eth1). 
+`ExecutionHeaders` are the headers of the blocks that are part of the execution layer (eth1).
 These contain the traditional [block header](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#executionpayloadheader).
 In contrast with the `ExecutionPayloads`, headers **do not contain the full list of transactions**.
 
 :::caution
-Blocks streamed are not **finalized**, meaning that the data is not guaranteed to be part of the canonical chain. 
+Blocks streamed are not **finalized**, meaning that the data is not guaranteed to be part of the canonical chain.
 Recent blocks can always be [reorged](https://www.paradigm.xyz/2021/07/ethereum-reorgs-after-the-merge).
 :::
 
@@ -366,7 +366,7 @@ print("error subscribing", e)
 </TabItem>
 </Tabs>
 
-## Block Payloads - `subscribeNewExecutionPayloads`
+## Block Payloads
 
 Execution Payloads are the traditional Blocks broadcasted on the execution layer (eth1).
 These contain the traditional [block header](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#executionpayloadheader)
@@ -462,10 +462,10 @@ print("error subscribing", e)
 </TabItem>
 </Tabs>
 
-## Beacon Blocks - `subscribeNewBeaconBlocks`
+## Beacon Blocks
 
-Beacon Blocks are the blocks broadcasted on the beacon chain (eth2), which contain the canonical [consensus info](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#executionpayloadheader). 
-We currently strip out the execution payload from this stream, as to keep the stream as light and fast as possible. 
+Beacon Blocks are the blocks broadcasted on the beacon chain (eth2), which contain the canonical [consensus info](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#executionpayloadheader).
+We currently strip out the execution payload from this stream, as to keep the stream as light and fast as possible.
 If you also need the execution payload, please use the `subscribeNewExecutionPayloads` stream.
 
 :::caution

docs/use-cases.md

@@ -18,7 +18,7 @@ In this [article](https://fiber.chainbound.io/blog/fiber-vs-bloxroute) we outlin
 ## 1. Searchers & Builders
 
 ### 1.1 MEV Capturing
-Low latency access to mempool data gives **searchers** and **builders** a latency and reliability advantage 
+Low latency access to mempool data gives **searchers** and **builders** a latency and reliability advantage
 over the competition.
 
 On the Execution Layer (EL), Fiber provides the `NewTransactions` stream, which returns new transactions that are propagated across the Ethereum mempool.
@@ -37,7 +37,7 @@ Order Flow (POF). Given `NewTransactions` has proven to be the fastest and most
 :::
 
 ### 1.2 Transaction Inclusion Receipts
-Fiber can also be leveraged by **Builders** and **Searchers** that are looking to confirm the inclusion of their transactions in the most recent block 
+Fiber can also be leveraged by **Builders** and **Searchers** that are looking to confirm the inclusion of their transactions in the most recent block
 as fast as possible.
 On the Consensus Layer, Fiber provides the `NewExecutionPayloads` stream, which abstracts the payload from `BeaconBlockBody` and returns it as a separate stream.
 
@@ -51,7 +51,7 @@ To note, some applications include:
 Via the `sendTransaction` API endpoint, searchers are able to **submit transactions** to the Ethereum network via Fiber.
 This has many use-cases, including:
 * **Redundancy in transaction submission** - Fiber can be used as a backup to their main transaction submission service, which can be private or public.
-* **Censorship resistance** - Fiber can be used to submit transactions to the Ethereum network in a way that is resistant to censorship. 
+* **Censorship resistance** - Fiber can be used to submit transactions to the Ethereum network in a way that is resistant to censorship.
 
 :::warning
 Fiber is not integrated with any Private Order Flow (POF) provider, therefore users should be mindful of the usual dangers of submitting to the public mempool (front-running, sandwiching attacks).
@@ -67,26 +67,36 @@ With Fiber's stream, protocols and applications can track events in real-time to
 * Real-time **anomaly detection** in smart contracts deployments and transactions
 
 ## 3. Validators
-### 3.1 FiberGuard
-Validators can optimize their performance and minimize their p2p latency with the implementation of FiberGuard, 
+### 3.1 FiberBoost
+FiberBoost is a service that allows proposers (and relays) to broadcast blocks through Fiber Network, resulting in fast, global block propagation. Blocks are broadcast internally over our high-speed links, as well as to all the consensus P2P peers Fiber is connected to. In practice, **FiberBoost will reduce the probability of missed slots due to [proposer boost & honest reorgs](https://www.paradigm.xyz/2023/04/mev-boost-ethereum-consensus#proposer-boost--honest-reorgs)**.
+
+FiberBoost can boost blocks through the following 3 interfaces:
+- API
+- Modified MEV-Boost
+- Direct P2P peering
+
+Click [here](./usage/fiber-boost) to get started.
+
+### 3.2 FiberGuard
+Validators can optimize their performance and minimize their p2p latency with the implementation of FiberGuard,
 an advanced technology designed to enhance their operations.
 
 FiberGuard provides validators with a reliable and low-latency `NewBeaconBlocks` stream, which is crucial for
-promptly receiving new blocks. This capability enables validators to **efficiently generate attestations** and 
+promptly receiving new blocks. This capability enables validators to **efficiently generate attestations** and
 **produce new blocks**, improving their overall performance.
 
 By adopting FiberGuard, validators can achieve the following benefits:
 
-1. **Reduced Streaming Latency:** With FiberGuard, validators can experience significantly reduced streaming 
-latency of `BeaconBlock`. This improvement can lead to up to **1-second reduction in latency** when compared to a 
+1. **Reduced Streaming Latency:** With FiberGuard, validators can experience significantly reduced streaming
+latency of `BeaconBlock`. This improvement can lead to up to **1-second reduction in latency** when compared to a
 single node setup and a remarkable **50-200 milliseconds** reduction compared to other existing services.
 
-2. **Enhanced Reliability and Uptime:** Leveraging the distributed nature of the Fiber network, 
-validators can **increase the reliability and uptime of their operations**. This means that validators are 
+2. **Enhanced Reliability and Uptime:** Leveraging the distributed nature of the Fiber network,
+validators can **increase the reliability and uptime of their operations**. This means that validators are
 less prone to downtime or interruptions, resulting in a more dependable validation process.
 
-3. **Lower Operating Costs:** One of the key advantages of utilizing FiberGuard is the cost reduction 
-it offers to running a validator. By mitigating the **risks of reorgs, missed attestations, or inactivity penalties**, 
+3. **Lower Operating Costs:** One of the key advantages of utilizing FiberGuard is the cost reduction
+it offers to running a validator. By mitigating the **risks of reorgs, missed attestations, or inactivity penalties**,
 validators can avoid potential financial losses and optimize their profitability.
 
 :::note