chore!: rename QGB to BlobStream (#222)

<!--
Please read and fill out this form before submitting your PR.

Please make sure you have reviewed our contributors guide before
submitting your
first PR.
-->

## Overview

Closes #220

## Checklist

<!-- 
Please complete the checklist to ensure that the PR is ready to be
reviewed.

IMPORTANT:
PRs should be left in Draft until the below checklist is completed.
-->

- [ ] New and updated code has appropriate documentation
- [ ] New and updated code has new and/or updated testing
- [ ] Required CI checks are passing
- [ ] Visual proof for any user facing features like CLI or
documentation updates
- [ ] Linked issues closed with keywords

Author: rach-id

Makefile

@@ -8,7 +8,7 @@ gen: solidity-wrappers
 
 SOLIDITY_DIR = .
 SOLIDITY_SRC_DIR = $(SOLIDITY_DIR)/src
-CONTRACTS = QuantumGravityBridge.sol ERC1967Proxy.sol
+CONTRACTS = Blobstream.sol ERC1967Proxy.sol
 
 fmt:
 	@echo "--> Running forge fmt"

README.md

@@ -1,13 +1,13 @@
-# Quantum Gravity Bridge
+# Blobstream-contracts
 
 <!-- markdownlint-disable MD013 MD041 -->
 
-[![GoDoc](https://img.shields.io/badge/godoc-reference-blue?style=flat-square&logo=go)](https://godoc.org/github.com/celestiaorg/quantum-gravity-bridge)
-[![Go Report Card](https://goreportcard.com/badge/github.com/celestiaorg/quantum-gravity-bridge?style=flat-square)](https://goreportcard.com/report/github.com/celestiaorg/quantum-gravity-bridge)
-[![Version](https://img.shields.io/github/tag/celestiaorg/quantum-gravity-bridge.svg?style=flat-square)](https://github.com/celestiaorg/quantum-gravity-bridge/releases/latest)
-[![License: Apache-2.0](https://img.shields.io/github/license/celestiaorg/quantum-gravity-bridge.svg?style=flat-square)](https://github.com/celestiaorg/quantum-gravity-bridge/blob/master/LICENSE)
+[![GoDoc](https://img.shields.io/badge/godoc-reference-blue?style=flat-square&logo=go)](https://godoc.org/github.com/celestiaorg/blobstream-contracts)
+[![Go Report Card](https://goreportcard.com/badge/github.com/celestiaorg/blobstream-contracts?style=flat-square)](https://goreportcard.com/report/github.com/celestiaorg/blobstream-contracts)
+[![Version](https://img.shields.io/github/tag/celestiaorg/blobstream-contracts.svg?style=flat-square)](https://github.com/celestiaorg/blobstream-contracts/releases/latest)
+[![License: Apache-2.0](https://img.shields.io/github/license/celestiaorg/blobstream-contracts.svg?style=flat-square)](https://github.com/celestiaorg/blobstream-contracts/blob/master/LICENSE)
 
-The Quantum Gravity Bridge (QGB) is a Celestia -> EVM message relay.
+Blobstream is a Celestia -> EVM message relay.
 It is based on Umee's Gravity Bridge implementation, [Peggo](https://github.com/umee-network/peggo).
 **This project is under active development and should not be used in production**.
 
@@ -75,21 +75,21 @@ Instructions [here](https://github.com/celestiaorg/celestia-app).
 
 ## How it works
 
-The QGB allows Celestia block header data roots to be relayed in one direction, from Celestia to an EVM chain.
+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.
-The QGB contract keeps track of the Celestia validator set by updating its view of the validator set with `updateValidatorSet()`.
+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 QGB contract who are the current validators and their power.
+ 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 QGB contract of new data root tuple roots.
+ The relayer informs the Blobstream contract of new data root tuple roots.
  This results in an execution of the `submitDataRootTupleRoot` function.

docs/inclusion-proofs.md

@@ -1,8 +1,8 @@
-# QGB Fraud Proofs
+# Blobstream Fraud Proofs
 
-## Celestiums Intro
+## Blobstream Intro
 
-A Celestium is a blockchain that uses Celestia for data availability but settles on any EVM chain. The QGB operates by having the Celestia validator set periodically sign over batched data commitments and validator set updates, which are relayed an EVM smart contract. The data commitments are stored in the EVM chain's state, and can be used to prove inclusion of any data historically posted to Celestia.
+A Blobstream rollup is a blockchain that uses Celestia for data availability but settles on any EVM chain. Blobstream operates by having the Celestia validator set periodically sign over batched data commitments and validator set updates, which are relayed an EVM smart contract. The data commitments are stored in the EVM chain's state, and can be used to prove inclusion of any data historically posted to Celestia.
 
 ## Fraud Proofs
 
@@ -28,7 +28,7 @@ We could prove that via creating a binary [Merkle proof](https://github.com/cele
 
 Then, we will use that information to check if the provided transaction index, in the header, is out of the square size bounds.
 
-For the data root, we will use a binary Merkle proof to prove its inclusion in a data root tuple root that was committed to by the QGB smart contract. More on this in [here](#1-data-root-inclusion-proof).
+For the data root, we will use a binary Merkle proof to prove its inclusion in a data root tuple root that was committed to by the Blobstream smart contract. More on this in [here](#1-data-root-inclusion-proof).
 
 ## Proving an Invalid State Transition
 
@@ -39,13 +39,13 @@ In order to prove an invalid transaction in the rollup, we need to prove the fol
 
 The first part, proving that the transaction was posted to Celestia, can be done in three steps:
 
-1. Prove that the data root tuple is committed to by the QGB smart contract
+1. Prove that the data root tuple is committed to by the Blobstream smart contract
 2. Verify inclusion proof of the transaction to Celestia data root
 3. Prove that the transaction is in the rollup sequence spans
 
 ### 1. Data root inclusion proof
 
-To prove the data root is committed to by the QGB smart contract, we will need to provide a Merkle proof of the data root tuple to a data root tuple root. This can be created using the [`data_root_inclusion_proof`](https://github.com/celestiaorg/celestia-core/blob/c3ab251659f6fe0f36d10e0dbd14c29a78a85352/rpc/client/http/http.go#L492-L511) query.
+To prove the data root is committed to by the Blobstream smart contract, we will need to provide a Merkle proof of the data root tuple to a data root tuple root. This can be created using the [`data_root_inclusion_proof`](https://github.com/celestiaorg/celestia-core/blob/c3ab251659f6fe0f36d10e0dbd14c29a78a85352/rpc/client/http/http.go#L492-L511) query.
 
 ### 2. Transaction inclusion proof
 

go.mod

@@ -1,4 +1,4 @@
-module github.com/celestiaorg/quantum-gravity-bridge/v2
+module github.com/celestiaorg/blobstream-contracts/v3
 
 go 1.21.1
 

package-lock.json

@@ -1,6 +1,6 @@
 {
-  "name": "quantum-gravity-bridge",
-  "version": "2.0.0",
+  "name": "blobstream-contracts",
+  "version": "3.0.0",
   "description": "Celestia -> EVM bridge",
   "main": "index.js",
   "directories": {
@@ -12,17 +12,17 @@
   },
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/celestiaorg/quantum-gravity-bridge.git"
+    "url": "git+https://github.com/celestiaorg/blobstream-contracts.git"
   },
   "keywords": [
-    "qgb"
+    "blobstream"
   ],
   "author": "",
   "license": "Apache-2.0",
   "bugs": {
-    "url": "https://github.com/celestiaorg/quantum-gravity-bridge/issues"
+    "url": "https://github.com/celestiaorg/blobstream-contracts/issues"
   },
-  "homepage": "https://github.com/celestiaorg/quantum-gravity-bridge#readme",
+  "homepage": "https://github.com/celestiaorg/blobstream-contracts#readme",
   "devDependencies": {
     "@nomicfoundation/hardhat-toolbox": "^3.0.0",
     "hardhat": "^2.17.4",

package.json

@@ -5,14 +5,14 @@
 #
 # How to use:
 # First, build the docker image using:
-#   $ docker build -t qgb-env -f Dockerfile_Environment .
+#   $ docker build -t blobstream-env -f Dockerfile_Environment .
 # Then, run the docker image:
-#   $ docker run -it qgb-env
+#   $ docker run -it blobstream-env
 # This should give you a shell inside the image where you have all the dependencies installed.
 #
 # For example, if you want to generate the wrappers for this repo, run the following inside the shell:
-#   $ git clone https://github.com/celestiaorg/quantum-gravity-bridge
-#   $ cd quantum-gravity-bridge
+#   $ git clone https://github.com/celestiaorg/blobstream-contracts
+#   $ cd blobstream-contracts
 #   $ make
 # And you will see that the wrappers are being regenerated for this repo.
 # Finally, you can push the changes to your branch using git add/commit/push.
@@ -36,4 +36,4 @@ RUN git clone --depth 1 --branch v1.12.0 https://github.com/ethereum/go-ethereum
 WORKDIR /root
 ENTRYPOINT bash
 
-# at this level, you can clone the qgb repo and build the wrappers, run the tests etc.
+# at this level, you can clone the blobstream-contracts repo and build the wrappers, run the tests etc.

scripts/Dockerfile_Environment

@@ -10,7 +10,7 @@ if (( $# < 2 )); then
     exit 1
 fi
 
-# compile the QGB contracts
+# compile the Blobstream contracts
 forge build > /dev/null
 
 # compile the proxy contracts

scripts/gen.sh

@@ -1,8 +1,8 @@
 #!/usr/bin/env bash
 
-# this script will check if the QGB contract is inheriting the correct upgradability contracts.
+# this script will check if the Blobstream contract is inheriting the correct upgradability contracts.
 
-out=$(surya inheritance src/QuantumGravityBridge.sol | grep -i "\"QuantumGravityBridge\" ->" | cut -d ">" -f 2  | sed 's/[";]//g')
+out=$(surya inheritance src/Blobstream.sol | grep -i "\"Blobstream\" ->" | cut -d ">" -f 2  | sed 's/[";]//g')
 
 required_contracts=("Initializable" "UUPSUpgradeable" "OwnableUpgradeable")
 missing_contracts=()
@@ -14,9 +14,9 @@ for field in "${required_contracts[@]}"; do
 done
 
 if [ ${#missing_contracts[@]} -eq 0 ]; then
-    echo "The QuantumGravityBridge contract is inheriting the right contracts. Exiting."
+    echo "The Blobstream contract is inheriting the right contracts. Exiting."
     exit 0
 else
-    echo "The QuantumGravityBridge contract is missing the necessary inherited contracts: ${missing_contracts[*]}"
+    echo "The Blobstream contract is missing the necessary inherited contracts: ${missing_contracts[*]}"
     exit 1
 fi

scripts/upgradability_check.sh

@@ -23,7 +23,7 @@ struct Signature {
     bytes32 s;
 }
 
-/// @title Quantum Gravity Bridge: Celestia -> EVM, Data Availability relay.
+/// @title Blobstream: Celestia -> EVM, Data Availability relay.
 /// @dev The relay relies on a set of signers to attest to some event on
 /// Celestia. These signers are the Celestia validator set, who sign over every
 /// Celestia block. Keeping track of the Celestia validator set is accomplished
@@ -36,7 +36,7 @@ struct Signature {
 /// block headers.
 /// @dev DO NOT REMOVE INHERITENCE OF THE FOLLOWING CONTRACTS: Initializable, UUPSUpgradeable and
 /// OwnableUpgradeable! They're essential for upgradability.
-contract QuantumGravityBridge is IDAOracle, Initializable, UUPSUpgradeable, OwnableUpgradeable {
+contract Blobstream is IDAOracle, Initializable, UUPSUpgradeable, OwnableUpgradeable {
     // Don't change the order of state for working upgrades AND BE AWARE OF
     // INHERITANCE VARIABLES! Inherited contracts contain storage slots and must
     // be accounted for in any upgrades. Always test an exact upgrade on testnet