github/reth
1
1
Fork 0
mirror of https://github.com/paradigmxyz/reth.git synced 2026-01-08 06:53:54 -05:00
Code Issues Packages Projects Releases Wiki Activity

fix: grammar in multiple files (#16403)

Browse Source
This commit is contained in:
crStiv
2025-05-22 14:10:41 +03:00
committed by GitHub
parent 70dab9f70d
commit 6389242a53
4 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
book/intro.md
View File

@@ -41,7 +41,7 @@ We also use our Ethereum libraries (including [Alloy](https://github.com/alloy-r
**3. Free for anyone to use any way they want**
Reth is free open source software, built for the community, by the community.
Reth is free open-source software, built for the community, by the community.
By licensing the software under the Apache/MIT license, we want developers to use it without being bound by business licenses, or having to think about the implications of GPL-like licenses.
@@ -71,8 +71,8 @@ Reth implements the specification of Ethereum as defined in the [ethereum/execut
1. EVM state tests are run on every [Revm Pull Request](https://github.com/bluealloy/revm/blob/main/.github/workflows/ethereum-tests.yml)
1. Hive tests are [run every 24 hours](https://github.com/paradigmxyz/reth/blob/main/.github/workflows/hive.yml) in the main Reth repository.
1. We regularly re-sync multiple nodes from scratch.
1. We operate multiple nodes at the tip of Ethereum mainnet and various testnets.
1. We regularly resync multiple nodes from scratch.
1. We operate multiple nodes at the tip of the Ethereum mainnet and various testnets.
1. We extensively unit test, fuzz test and document all our code, while also restricting PRs with aggressive lint rules.
We have completed an audit of the [Reth v1.0.0-rc.2](https://github.com/paradigmxyz/reth/releases/tag/v1.0.0-rc.2) with [Sigma Prime](https://sigmaprime.io/), the developers of [Lighthouse](https://github.com/sigp/lighthouse), the Rust Consensus Layer implementation. Find it [here](https://github.com/paradigmxyz/reth/blob/main/audit/sigma_prime_audit_v2.pdf).

4
docs/crates/db.md
View File

@@ -243,7 +243,7 @@ fn get<T: Table>(&self, key: T::Key) -> Result<Option<T::Value>, DatabaseError>;
This design pattern is very powerful and allows Reth to use the methods available to the `DbTx` and `DbTxMut` traits without having to define implementation blocks for each table within the database.
Let's take a look at a couple examples before moving on. In the snippet below, the `DbTxMut::put()` method is used to insert values into the `CanonicalHeaders`, `Headers` and `HeaderNumbers` tables.
Let's take a look at a couple of examples before moving on. In the snippet below, the `DbTxMut::put()` method is used to insert values into the `CanonicalHeaders`, `Headers` and `HeaderNumbers` tables.
[File: crates/storage/provider/src/providers/database/provider.rs](https://github.com/paradigmxyz/reth/blob/bf9cac7571f018fec581fe3647862dab527aeafb/crates/storage/provider/src/providers/database/provider.rs#L2606-L2745)
@@ -254,7 +254,7 @@ self.tx.put::<tables::HeaderNumbers>(block.hash(), block_number)?;
```
Let's take a look at the `DatabaseProviderRW<DB: Database>` struct, which is used to create a mutable transaction to interact with the database.
The `DatabaseProviderRW<DB: Database>` struct implements the `Deref` and `DerefMut` trait, which returns a reference to its first field, which is a `TxMut`. Recall that `TxMut` is a generic type on the `Database` trait, which is defined as `type TXMut: DbTxMut + DbTx + Send + Sync;`, giving it access to all of the functions available to `DbTx`, including the `DbTx::get()` function.
The `DatabaseProviderRW<DB: Database>` struct implements the `Deref` and `DerefMut` traits, which return a reference to its first field, which is a `TxMut`. Recall that `TxMut` is a generic type on the `Database` trait, which is defined as `type TXMut: DbTxMut + DbTx + Send + Sync;`, giving it access to all of the functions available to `DbTx`, including the `DbTx::get()` function.
This next example uses the `DbTx::cursor()` method to get a `Cursor`. The `Cursor` type provides a way to traverse through rows in a database table, one row at a time. A cursor enables the program to perform an operation (updating, deleting, etc) on each row in the table individually. The following code snippet gets a cursor for a few different tables in the database.

6
docs/release.md
View File

@@ -26,7 +26,7 @@ It is assumed that the commit that is being considered for release has been mark
- [ ] Tag the new commit on main with `vx.y.z` (`git tag vx.y.z SHA`)
- [ ] Push the tag (`git push origin vx.y.z`)[^1]
- [ ] Update [Homebrew Tap](https://github.com/paradigmxyz/homebrew-brew)
- [ ] Run the release commit on testing infrastructure for 1-3 days to check for inconsistencies and bugs
- [ ] Run the release commit on the testing infrastructure for 1-3 days to check for inconsistencies and bugs
- This testing infrastructure is going to sync and keep up with a live testnet, and includes monitoring of bandwidth, CPU, disk space etc.
> **Note**
@@ -43,6 +43,6 @@ The release artifacts are automatically added to the draft release. Once ready,
#### Release summaries
The release summary should include general notes on what the release contains that is important to operators. These changes can be found using the https://github.com/paradigmxyz/reth/labels/M-changelog label.
The release summary should include general notes on what the release contains that are important to operators. These changes can be found using the https://github.com/paradigmxyz/reth/labels/M-changelog label.
[^1]: It is possible to use `git push --tags`, but this is discouraged since it can be very difficult to get rid of bad tags.
[^1]: It is possible to use `git push --tags`, but this is discouraged since it can be very difficult to get rid of bad tags.

6
docs/workflow.md
View File

@@ -2,7 +2,7 @@
### Assigning issues
Before working on an issue, it should be assigned to the person who wants to work on it. For core contributors, this means assigning yourself to the issue, and for external contributors this means asking to be assigned on the issue. This is to avoid double work.
Before working on an issue, it should be assigned to the person who wants to work on it. For core contributors, this means assigning yourself to the issue, and for external contributors, this means asking to be assigned to the issue. This is to avoid double work.
### Pull requests
@@ -25,7 +25,7 @@ gitGraph
- Features and bug fixes live on feature branches off of the main branch, and they are merged onto main as well.
This means that the latest version of reth (which might be unstable) always lives on main.
- Pull requests should not be merged without the review of at least one core contributor. For larger pull requests, at least two is recommended.
- Pull requests should not be merged without the review of at least one core contributor. For larger pull requests, at least two reviewers are recommended.
- Important pull requests that should be highlighted in the changelog should be marked with the https://github.com/paradigmxyz/reth/labels/M-changelog label.
### Releases
@@ -59,4 +59,4 @@ gitGraph
- Additionally, each PR is again tested before release by being run every night on a live testnet
[clippy]: https://github.com/rust-lang/rust-clippy
[rustfmt]: https://github.com/rust-lang/rustfmt
[rustfmt]: https://github.com/rust-lang/rustfmt