chore: blobstream updates

.vitepress/config.ts

@@ -401,13 +401,9 @@ function sidebarHome() {
             },
             { text: "Consensus", link: "/nodes/consensus-node" },
             {
-              text: "Blobstream ",
+              text: "Blobstream for validators",
               collapsed: true,
               items: [
-                {
-                  text: "Intro to Blobstream",
-                  link: "/nodes/blobstream-intro",
-                },
                 {
                   text: "Install the binary",
                   link: "/nodes/blobstream-binary",
@@ -422,6 +418,10 @@ function sidebarHome() {
                   text: "Deploy the contract",
                   link: "/nodes/blobstream-deploy",
                 },
+                {
+                  text: "Bootstrapper",
+                  link: "/nodes/blobstream-bootstrapper",
+                },
               ],
             },
           ],

.vitepress/constants/constants.js

@@ -12,7 +12,7 @@ const constants = Object.freeze({
   mochaRollkitVersion: "v0.10.5",
   mainnetRollkitVersion: "v0.10.5",
   localCelestiaDevnetVersion: "v0.8.2",
-  golangBlobstream: "1.20.2",
+  golangBlobstream: "1.20.1",
   orchrelayVersion: "v1.0.0-rc7",
   mochaRpcUrl: "https://rpc-mocha.pops.one/",
   mochaRestUrl: "https://api-mocha.pops.one/",

developers/blobstream.md

@@ -15,21 +15,120 @@ developers to build high-throughput L2s using Celestia's optimised DA layer,
 the first with Data Availability Sampling (DAS).
 
 The following docs go over how developers can integrate Blobstream.
-There are also docs on how to run a [Blobstream orchestrator](../nodes/blobstream-intro.md)
+There are also docs on how to run a [Blobstream orchestrator](../nodes/blobstream-binary.md)
 as a Celestia validator which won't be covered in the following sections
 aimed at developers.
 
+## Overview
+
+Blobstream,
+consists of two components: an [orchestrator](../nodes/blobstream-orchestrator.md)
+and a [relayer](../nodes/blobstream-relayer.md).
+
+In the following diagram, we show how a layer 2 (L2) would post data to
+Celestia and then verify that it was published in the target EVM chain.
+
+![Blobstream-Architecture](/img/blobstream/Blobstream.png)
+
+Data will first be attested to by the Celestia validator set, _i.e._
+signing commitments committing to the data. Then, these signatures will be
+relayed to the target EVM chain (in this case, Ethereum). Finally,
+the L2, or any party, will be able to verify that the data was published
+to Celestia directly on the EVM chain on the Blobstream smart contract. You can
+reference [the Blobstream smart contract](https://github.com/celestiaorg/blobstream-contracts/blob/master/src/Blobstream.sol).
+
+The **orchestrator** is part of the validator setup and works as follows:
+
+- celestia-app creates an attestation on the state machine level that needs to
+  be signed
+- The orchestrator queries the attestation, signs it, then submits the signature
+  to the Blobstream P2P network
+
+The **relayer** submits the attestations' signatures from the Blobstream
+P2P network to the target EVM chain.
+
+:::tip NOTE
+If the contract is still not deployed, then it needs to be
+deployed before its used by the relayer. Check the
+[deployment documentation](../nodes/blobstream-deploy.md) for more details.
+:::
+
+## How Blobstream works
+
+Blobstream allows Celestia block header data roots to be relayed in one
+direction, from Celestia to an EVM chain. It does not support bridging
+assets such as fungible or non-fungible tokens directly, and cannot send
+messages from the EVM chain back to Celestia.
+
+It works by relying on a set of signers to attest to some event on Celestia:
+the Celestia validator set. Blobstream contract keeps track of the
+Celestia validator set by updating its view of the validator set with
+`updateValidatorSet()`. More than 2/3 of the voting power of the current
+view of the validator set must sign off on new relayed events, submitted with
+`submitDataRootTupleRoot()`. Each event is a batch of `DataRootTuple`s, with
+each tuple representing a single
+[data root (i.e. block header)](https://celestiaorg.github.io/celestia-app/specs/data_structures.html#header).
+Relayed tuples are in the same order as Celestia block headers.
+
+### Events and messages relayed
+
+**Validator sets**:
+The relayer informs the Blobstream contract who are the current
+validators and their power.
+This results in an execution of the `updateValidatorSet` function.
+
+**Batches**:
+The relayer informs the Blobstream contract of new data root tuple roots.
+This results in an execution of the `submitDataRootTupleRoot` function.
+
+## How to integrate
+
 Integrating your L2 with Blobstream requires two components: your onchain smart
-contract logic, and your offchain client logic.
+contract logic, and your offchain client logic. The next three sections cover these
+topics:
 
 - [Integrate with Blobstream contracts](./blobstream-contracts.md)
 - [Integrate with Blobstream client](./blobstream-offchain.md)
 - [Querying the Blobstream proofs](./blobstream-proof-queries.md)
 
+### Deployed contracts
+
 You can interact with the Blobstream contracts today on testnet. The Blobstream Solidity
 smart contracts are currently deployed on the following Ethereum testnet:
 
 - [Blobstream on Sepolia](https://sepolia.etherscan.io/address/0xf148a9a767f19edcf9a7d125fe143db1b5792ad6)
-  - Which attests to the data published on the Arabica devnet
+  - Which attests to the data published on the Mocha testnet
 - [Blobstream X on Goerli](https://goerli.etherscan.io/address/0x67ea962864cdad3f2202118dc6f65ff510f7bb4d)
   - Which attests to the data published on the Mocha testnet
+
+## Blobstream vs. data availability committees (DACs)
+
+### Decentralization and security
+
+Blobstream is built on Celestia, which uses a CometBFT-based proof-of-stake
+system. An incorrect data availability attestation in this system will
+ultimately be penalized (currently not implemented), ensuring validators
+act in good faith. Thus, Blobstream shares the same security assumptions
+as Celestia. In contrast, data availability committees (DACs), are typically
+centralized or semi-centralized, relying on a specific set of entities or
+individuals to vouch for data availability.
+
+### Mechanism of verification
+
+Blobstream uses data availability attestations, which are Merkle roots of
+the batched L2 data, to confirm that the necessary data is present on Celestia.
+The L2 contract on Ethereum can check directly with Blobstream if the data
+is published on Celestia. Similarly, a DAC would rely on
+attestations or confirmations from its permissioned members.
+
+### Flexibility and scalability
+
+Blobstream is designed to offer high-throughput data availability for Ethereum L2s,
+aiming to strike a balance between scalability and security. It operates
+independently of Ethereum's gas costs, as Celestia's resource pricing is more
+byte-focused rather than computation-centric. On the other hand, the scalability
+and flexibility of a DAC would depend on its specific design and implementation.
+
+In summary, both Blobstream and DACs aim to ensure offchain data availability,
+but Blobstream offers a more decentralized, secure, and scalable solution
+compared to the potential centralized nature of DACs.

importBlobstream.mjs

@@ -18,6 +18,10 @@ const filesToImport = [
     url: 'https://raw.githubusercontent.com/celestiaorg/orchestrator-relayer/main/docs/relayer.md',
     fileName: 'blobstream-relayer.md',
   },
+  {
+    url: 'https://raw.githubusercontent.com/celestiaorg/orchestrator-relayer/main/docs/bootstrapper.md',
+    fileName: 'blobstream-bootstrapper.md',
+  }
 ];
 
 async function importMarkdown(file) {

nodes/blobstream-binary.md

@@ -2,18 +2,36 @@
 description: This guide shows you how to install the Blobstream binary.
 ---
 
-# Install the Blobstream binary
+# Blobstream for validators
+
+[Blobstream](https://blog.celestia.org/introducing-blobstream/)
+allows Ethereum developers to build high-throughput L2s using Celestia,
+the first data availability layer with Data Availability Sampling.
+
+This page and following tutorials will go over Blobstream and how validators
+on Celestia can run it.
+
+If you're looking to learn more, you can view
+[the `orchestrator-relayer` repository](https://github.com/celestiaorg/orchestrator-relayer)
+or [read more about how Blobstream works](../developers/blobstream.md#overview).
+
+## Install the Blobstream binary
 
 <!-- markdownlint-disable MD033 -->
 <script setup>
 import constants from '/.vitepress/constants/constants.js'
 </script>
 
 The [orchestrator](./blobstream-orchestrator.md) is the software that signs the
-Blobstream attestations, and the [relayer](./blobstream-relayer.md) is the one that
-relays them to the target EVM chain.
+Blobstream attestations, and the [relayer](./blobstream-relayer.md) is the
+software that relays them to the target EVM chain.
+
+The following sections in this category presume you have the following setup:
 
-## Install
+- A celestia-app
+  [validator node](./consensus-node.md#optional-setting-up-a-validator) running
+
+### Install
 
 1. [Install Go](https://go.dev/doc/install) {{constants.golangBlobstream}}
 
@@ -31,52 +49,35 @@ relays them to the target EVM chain.
    make install
    ```
 
-## Usage
+### Usage
 
 ```sh
 # Print help
 blobstream --help
 ```
 
-## How to run
-
-If you are a Celestia-app validator, all you need to do is run the
-orchestrator. Check out
-[the Blobstream orchestrator page](./blobstream-orchestrator.md) for more details.
-
-If you want to post commitments on an EVM chain, you will need to deploy
-a new Blobstream contract and run a relayer. Check out
-[the Blobstream relayer page](./blobstream-relayer.md) for
-relayer docs and [the Blobstream deployment page](./blobstream-deploy.md) for
-how to deploy a new Blobstream contract.
-
-Note: the Blobstream P2P network is a separate network than the consensus or
+### Next steps
+
+1. If you are a Celestia validator, all you need to do is run the
+   orchestrator. Check out
+   [the Blobstream orchestrator page](./blobstream-orchestrator.md) for more details.
+2. [Learn about key management](./blobstream-keys.md)
+3. Optional: If you want to post commitments on an EVM chain, you will need to deploy
+   a new Blobstream contract and run a relayer. Check out
+   [the Blobstream relayer page](./blobstream-relayer.md) for
+   relayer docs and [the Blobstream deployment page](./blobstream-deploy.md) for
+   how to deploy a new Blobstream contract.
+4. Optional: [Learn how to run a Blobstream bootstrapper node](./blobstream-bootstrapper.md)
+
+:::tip
+The Blobstream P2P network is a separate network than the consensus or
 the data availability one. Thus, you will need its specific
 bootstrappers to be able to connect to it.
+:::
 
-## Contributing
-
-### Tools
-
-1. Install [golangci-lint](https://golangci-lint.run/usage/install/)
-2. Install [markdownlint](https://github.com/DavidAnson/markdownlint)
-
-### Helpful Commands
-
-```sh
-# Build a new orchestrator-relayer binary and output to build/blobstream
-make build
-
-# Run tests
-make test
-
-# Format code with linters (this assumes golangci-lint and markdownlint are installed)
-make fmt
-```
-
-## Useful links
+### Useful links
 
-The smart contract implementation is in [blobstream](https://github.com/celestiaorg/blobstream-contracts/).
+The smart contract implementation is in [blobstream-contracts](https://github.com/celestiaorg/blobstream-contracts/).
 
 The state machine implementation is in [x/blobstream](https://github.com/celestiaorg/celestia-app/tree/main/x/blobstream).
 

nodes/blobstream-bootstrapper.md

@@ -0,0 +1,74 @@
+# Blobstream bootstrapper
+
+To bootstrap the Blobstream P2P network, we use the bootstrapper Blobstream
+node type to accept connections from freshly created orchestrators/relayers
+and share its peer table with them.
+
+## How to run
+
+### Install the Blobstream binary
+
+Make sure to have the Blobstream binary installed. Check
+[the Blobstream binary page](https://docs.celestia.org/nodes/blobstream-binary)
+for more details.
+
+### Init the store
+
+Before starting the bootstrapper, we will need to init the store:
+
+```sh
+blobstream bootstrapper init
+```
+
+By default, the store will be created un `~/.bootstrapper`. However,
+if you want to specify a custom location, you can use the `--home` flag.
+Or, you can use the following environment variable:
+
+<!-- markdownlint-disable MD013 -->
+
+| Variable            | Explanation                         | Default value     | Required |
+| ------------------- | ----------------------------------- | ----------------- | -------- |
+| `BOOTSTRAPPER_HOME` | Home directory for the bootstrapper | `~/.bootstrapper` | Optional |
+
+### Add keys
+
+The P2P private key is optional, and a new one will be generated automatically
+on the start if none is provided.
+
+The `p2p` sub-command will help you set up this key if you want to use a specific
+one:
+
+```sh
+blobstream bootstrapper p2p  --help
+```
+
+### Start the bootstrapper
+
+Now that we have the store initialized, we can start the bootstrapper:
+
+```shell
+blobstream bootstrapper
+
+Blobstream P2P network bootstrapper command
+
+Usage:
+  blobstream bootstrapper [command]
+
+Aliases:
+  bootstrapper, bs
+
+Flags:
+  -h, --help   help for bootstrapper
+
+Use "blobstream bootstrapper [command] --help" for more information about a command.
+```
+
+### Open the P2P port
+
+In order for the bootstrapper node to work, you will need to expose the P2P
+port, which is by default `30000`.
+
+#### Systemd service
+
+An example of a systemd service that can be used for bootstrappers can be
+found in the orchestrator documentation.