From 8c328b8ce3ad77ca8f0933b656d01b2decdfffbb Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 11 Feb 2023 13:16:44 +0100 Subject: [PATCH 1/3] Fix: typos --- docs/tutorials/go-built-in.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/tutorials/go-built-in.md b/docs/tutorials/go-built-in.md index 778de575989..580a8bbba64 100644 --- a/docs/tutorials/go-built-in.md +++ b/docs/tutorials/go-built-in.md @@ -225,7 +225,7 @@ Our application will need to write its state out to persistent storage so that i can stop and start without losing all of its data. For this tutorial, we will use [BadgerDB](https://github.com/dgraph-io/badger), a -a fast embedded key-value store. +fast embedded key-value store. First, add Badger as a dependency of your go module using the `go get` command: @@ -309,7 +309,7 @@ its validation checks. The specific value of the code is meaningless to CometBFT Non-zero codes are logged by CometBFT so applications can provide more specific information on why the transaction was rejected. -Note that `CheckTx` does not execute the transaction, it only verifies that that the transaction could be executed. We do not know yet if the rest of the network has agreed to accept this transaction into a block. +Note that `CheckTx` does not execute the transaction, it only verifies that the transaction could be executed. We do not know yet if the rest of the network has agreed to accept this transaction into a block. Finally, make sure to add the bytes package to the `import` stanza at the top of `app.go`: @@ -333,7 +333,7 @@ application over three ABCI method calls: `BeginBlock`, `DeliverTx`, and `EndBlo receive a block. - `DeliverTx` is called repeatedly, once for each application transaction that was included in the block. - `EndBlock` is called once to indicate to the application that no more transactions -will be delivered to the application in within this block. +will be delivered to the application within this block. Note that, to implement these calls in our application we're going to make use of Badger's transaction mechanism. We will always refer to these as Badger transactions, not to From 02f35588adf049b73f302131cb940222fa5f887d Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 11 Feb 2023 13:20:24 +0100 Subject: [PATCH 2/3] Fix: typos --- docs/introduction/what-is-cometbft.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/introduction/what-is-cometbft.md b/docs/introduction/what-is-cometbft.md index c18206b2a23..abd98556faf 100644 --- a/docs/introduction/what-is-cometbft.md +++ b/docs/introduction/what-is-cometbft.md @@ -91,7 +91,7 @@ Since then, CometBFT has evolved to be a general purpose blockchain consensus engine that can host arbitrary application states. That means it can be used as a plug-and-play replacement for the consensus engines of other blockchain software. So one can take the current Ethereum code -base, whether in Rust, or Go, or Haskell, and run it as a ABCI +base, whether in Rust, or Go, or Haskell, and run it as an ABCI application using CometBFT. Indeed, [we did that with Ethereum](https://github.com/cosmos/ethermint). And we plan to do the same for Bitcoin, ZCash, and various other deterministic @@ -162,7 +162,7 @@ protocol. "consensus engine", communicates with the application via a socket protocol that satisfies the ABCI, the CometBFT Socket Protocol. -To draw an analogy, lets talk about a well-known cryptocurrency, +To draw an analogy, let's talk about a well-known cryptocurrency, Bitcoin. Bitcoin is a cryptocurrency blockchain where each node maintains a fully audited Unspent Transaction Output (UTXO) database. If one wanted to create a Bitcoin-like system on top of ABCI, CometBFT From 7ca85b9ad645fc60e0a99c02a7a2f7993a1ee20b Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Sat, 11 Feb 2023 13:21:41 +0100 Subject: [PATCH 3/3] Fix: typo --- docs/core/block-sync.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/block-sync.md b/docs/core/block-sync.md index e18756b694a..487ce7c73ba 100644 --- a/docs/core/block-sync.md +++ b/docs/core/block-sync.md @@ -26,7 +26,7 @@ In this mode, the CometBFT daemon will sync hundreds of times faster than if it used the real-time consensus process. Once caught up, the daemon will switch out of Block Sync and into the normal consensus mode. After running for some time, the node is considered `caught up` if it -has at least one peer and it's height is at least as high as the max +has at least one peer and its height is at least as high as the max reported peer height. See [the IsCaughtUp method](https://github.com/cometbft/cometbft/blob/main/blocksync/pool.go#L168).