Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation Grammar and Consistency Improvements #61

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/build-with-0g/storage-sdk.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,7 +107,7 @@ if err != nil {

### File Hash Calculation

Calculate a file's Merkle root hash before upload, this will be used for identify file from 0G storage:
Calculate a file's Merkle root hash before upload, this will be used to identify files in 0G storage:

```go
rootHash, err := core.MerkleRoot(filePath)
Expand Down
4 changes: 2 additions & 2 deletions docs/da/og-da-deep-dive.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ sidebar_position: 2
---
# 0G DA Technical Deep Dive

The Data Availability (DA) module allows users to submit a piece of data, referred to as a _**DA blob**_. This data is redundantly encoded by the client's proxy and divided into several slices, which are then sent to DA nodes. _**DA nodes**_ gain eligibility to verify the correctness of DA slices by staking. Each DA node verifies the integrity and correctness of its slice and signs it. Once more than 2/3 of the aggregated signatures are on-chain, the data behind the related hash is considered to be decentralized published.
The Data Availability (DA) module allows users to submit a piece of data, referred to as a _**DA blob**_. This data is redundantly encoded by the client's proxy and divided into several slices, which are then sent to DA nodes. _**DA nodes**_ gain eligibility to verify the correctness of DA slices by staking. Each DA node verifies the integrity and correctness of its slice and signs it. Once more than 2/3 of the aggregated signatures are on-chain, the data behind the related hash is considered to be decentrally published.

To incentivize DA nodes to store the signed data for a period, the signing process itself does not provide any rewards. Instead, rewards are distributed through a process called _**DA Sampling**_. During each DA Sample round, any DA slice within a certain time frame can generate a lottery chance for a reward. DA nodes need to actually store the corresponding slice to redeem the lottery chance and claim the reward.

Expand Down Expand Up @@ -53,7 +53,7 @@ $$\forall\, 2048\le i< 3072,\, 0\le j< 1024,\,c_{i,j}=f\left(u\cdot w^{1024j+(i-

The **erasure commitment** is the KZG commitment of $f$, defined as $f(\tau)\cdot G$, where $G$ is the starting point of BN254 G1 curve, and $\tau$ is a latent parameter from the [perpetual powers of tau trusted setup ceremony](https://github.com/privacy-scaling-explorations/perpetualpowersoftau).

The **data root** is defined as the input root by treating the 1024\*3072 32-byte elements as a continuous storage submission input. Specifically, according to the storage submission requirements, these data does not need to pad any zeros, and will be divided into a 16384-element sector array and an 8192-element sector array.
The **data root** is defined as the input root by treating the 1024\*3072 32-byte elements as a continuous storage submission input. Specifically, according to the storage submission requirements, this data does not need to pad any zeros, and will be divided into a 16384-element sector array and an 8192-element sector array.

DA nodes need to verify two parts:

Expand Down
4 changes: 2 additions & 2 deletions docs/run-a-node/validator-node.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ Running a validator node in the 0G ecosystem means actively participating in the
```bash
0gchaind config chain-id zgtendermint_16600-2
```
**3. Initialise Your Node:** by creating necessary configuration files and a validator key pair, establishing your node's identity within the 0G network.
**3. Initialize Your Node:** by creating necessary configuration files and a validator key pair, establishing your node's identity within the 0G network.

```bash
0gchaind init <your_validator_name> --chain-id zgtendermint_16600-2
Expand All @@ -54,7 +54,7 @@ Running a validator node in the 0G ecosystem means actively participating in the

## Starting Your Node

**5. Start the Testnet Node:** Start your node and it should begin the synchronisation process with the 0G testnet, downloading and verifying the blockchain's history.
**5. Start the Testnet Node:** Start your node and it should begin the synchronization process with the 0G testnet, downloading and verifying the blockchain's history.

```bash
0gchaind start
Expand Down