chore: update documentation from cosmos-sdk/docs (#242)

chore: Sync docs from cosmos-sdk/docs

Co-authored-by: tac0turtle <24299864+tac0turtle@users.noreply.github.com>

docs/build/abci/03-vote-extensions.md

@@ -120,3 +120,163 @@ func (k Keeper) BeginBlocker(ctx context.Context) error {
     return nil
 }
 ```
+
+## Vote Extensions on v2
+
+### Extend Vote
+
+In v2, the `ExtendVoteHandler` function works in the same way as it does in v1,
+but the implementation is passed as a server option when calling `cometbft.New`.
+
+```go
+serverOptions.ExtendVoteHandler = CustomExtendVoteHandler()
+
+func CustomExtendVoteHandler() handlers.ExtendVoteHandler {
+	return func(ctx context.Context, rm store.ReaderMap, evr *v1.ExtendVoteRequest) (*v1.ExtendVoteResponse, error) {
+		return &v1.ExtendVoteResponse{
+			VoteExtension: []byte("BTC=1234567.89;height=" + fmt.Sprint(evr.Height)),
+		}, nil
+	}
+}
+```
+
+### Verify Vote Extension
+
+Same as above:
+
+```go
+serverOptions.VerifyVoteExtensionHandler = CustomVerifyVoteExtensionHandler()
+
+func CustomVerifyVoteExtensionHandler]() handlers.VerifyVoteExtensionHandler {
+    return  func(context.Context, store.ReaderMap, *abci.VerifyVoteExtensionRequest) (*abci.VerifyVoteExtensionResponse, error) {
+        return &abci.VerifyVoteExtensionResponse{}, nil
+    }
+}
+
+```
+
+### Prepare and Process Proposal
+
+These are also passed in as server options when calling `cometbft.New`.
+
+```go
+serverOptions.PrepareProposalHandler = CustomPrepareProposal[T]()
+serverOptions.ProcessProposalHandler = CustomProcessProposalHandler[T]()
+```
+
+The PrepareProposal handler can be used to inject vote extensions into the block proposal
+by using the `cometbft.RawTx` util function, which allows passing in arbitrary bytes.
+
+```go
+func CustomPrepareProposal[T transaction.Tx]() handlers.PrepareHandler[T] {
+	return func(ctx context.Context, app handlers.AppManager[T], codec transaction.Codec[T], req *v1.PrepareProposalRequest, chainID string) ([]T, error) {
+		var txs []T
+		for _, tx := range req.Txs {
+			decTx, err := codec.Decode(tx)
+			if err != nil {
+				continue
+			}
+
+			txs = append(txs, decTx)
+		}
+
+		// "Process" vote extensions (we'll just inject all votes)
+		injectedTx, err := json.Marshal(req.LocalLastCommit)
+		if err != nil {
+			return nil, err
+		}
+
+		// put the injected tx into the first position
+		txs = append([]T{cometbft.RawTx(injectedTx).(T)}, txs...)
+
+		return txs, nil
+	}
+}
+```
+
+The ProcessProposal handler can be used to recover the vote extensions from the first transaction
+and perform any necessary verification on them. In the example below we also use the
+`cometbft.ValidateVoteExtensions` util to verify the signature of the vote extensions;
+this function takes a "validatorStore" function that returns the public key of a validator
+given its consensus address. In the example we use the default staking module to get the
+validators.
+
+```go
+func CustomProcessProposalHandler[T transaction.Tx]() handlers.ProcessHandler[T] {
+	return func(ctx context.Context, am handlers.AppManager[T], c transaction.Codec[T], req *v1.ProcessProposalRequest, chainID string) error {
+		// Get all vote extensions from the first tx
+
+		injectedTx := req.Txs[0]
+		var voteExts v1.ExtendedCommitInfo
+		if err := json.Unmarshal(injectedTx, &voteExts); err != nil {
+			return err
+		}
+
+		// Get validators from the staking module
+		res, err := am.Query(
+			ctx,
+			0,
+			&staking.QueryValidatorsRequest{},
+		)
+		if err != nil {
+			return err
+		}
+
+		validatorsResponse := res.(*staking.QueryValidatorsResponse)
+		consAddrToPubkey := map[string]cryptotypes.PubKey{}
+
+		for _, val := range validatorsResponse.GetValidators() {
+			cv := val.ConsensusPubkey.GetCachedValue()
+			if cv == nil {
+				return fmt.Errorf("public key cached value is nil")
+			}
+
+			cpk, ok := cv.(cryptotypes.PubKey)
+			if ok {
+				consAddrToPubkey[string(cpk.Address().Bytes())] = cpk
+			} else {
+				return fmt.Errorf("invalid public key type")
+			}
+		}
+
+		// First verify that the vote extensions injected by the proposer are correct
+		if err := cometbft.ValidateVoteExtensions(
+			ctx,
+			am,
+			chainID,
+			func(ctx context.Context, b []byte) (cryptotypes.PubKey, error) {
+				if _, ok := consAddrToPubkey[string(b)]; !ok {
+					return nil, fmt.Errorf("validator not found")
+				}
+				return consAddrToPubkey[string(b)], nil
+			},
+			voteExts,
+			req.Height,
+			&req.ProposedLastCommit,
+		); err != nil {
+			return err
+		}
+
+		// TODO: do something with the vote extensions
+
+		return nil
+	}
+}
+```
+
+
+### Preblocker
+
+In v2, the `PreBlocker` function works in the same way as it does in v1. However, it is
+is now passed in as an option to `appbuilder.Build`.
+
+```go
+app.App, err = appBuilder.Build(runtime.AppBuilderWithPreblocker(
+	func(ctx context.Context, txs []T) error {
+        // to recover the vote extension use
+        voteExtBz := txs[0].Bytes()
+        err := doSomethingWithVoteExt(voteExtBz)
+		return err
+	},
+))
+```

docs/build/architecture/adr-040-storage-and-smt-state-commitments.md

@@ -279,7 +279,7 @@ We were discussing use case where modules can use a support database, which is n
 ## References
 
 * [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
-* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15
+* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of its state v0.15
 * [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
 * [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
 * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)

docs/build/architecture/adr-045-check-delivertx-middlewares.md

@@ -18,7 +18,7 @@ This ADR replaces the current BaseApp `runTx` and antehandlers design with a mid
 
 BaseApp's implementation of ABCI `{Check,Deliver}Tx()` and its own `Simulate()` method call the `runTx` method under the hood, which first runs antehandlers, then executes `Msg`s. However, the [transaction Tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [refunding unused gas](https://github.com/cosmos/cosmos-sdk/issues/2150) use cases require custom logic to be run after the `Msg`s execution. There is currently no way to achieve this.
 
-An naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular.
+A naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular.
 
 ## Decision
 

docs/build/architecture/adr-75-v2.md

@@ -200,7 +200,7 @@ type StateTransitionFunction[T transaction.Tx] interface {
 
 The design of the node comes with a number of tradeoffs.
 
-* Maintenance cost can be the same as existing Baseapp as handling many go.mods is a overhead.
+* Maintenance cost can be the same as existing Baseapp as handling many go.mods is an overhead.
 * Modularity means different layers of abstractions, abstractions always have a cost. 
 
 ### Backwards Compatibility

docs/build/packages/README.md

@@ -50,4 +50,3 @@ For more information on SDK tooling, see the [Tooling](https://docs.cosmos.netwo
 ## Example
 
 * [SimApp v2](https://pkg.go.dev/cosmossdk.io/simapp/v2) - SimApp/v2 is **the** sample Cosmos SDK v2 chain. This package should not be imported in your application.
-* [SimApp](https://pkg.go.dev/cosmossdk.io/simapp) - SimApp is **the** sample Cosmos SDK chain. This package should not be imported in your application.

docs/build/rfc/rfc-006-handlers.md

@@ -10,7 +10,7 @@ The Cosmos SDK has a very powerful and flexible module system that has been test
 and proven to be very good in production. The design of how messages are handled
 is built around Protobuf services and gRPC. This design was proposed and implemented
 during a time when we migrated from Amino to Protocol Buffers. This design has
-fulfilled the needs of users today. While this design is useful it has caused a
+fulfilled the needs of users today. While this design is useful it has caused an
 elevated learning curve to be adopted by users. Today, these services are the
 only way to write a module. This RFC proposes a new design that simplifies the
 design and enables new use cases we are seeing today.

docs/build/spec/store/README.md

@@ -103,7 +103,7 @@ responsibility of the caller to ensure that concurrent access to the store is
 not performed. 
 
 The main issue with concurrent use is when data is written at the same time as
-it's being iterated over. Doing so will cause a irrecoverable fatal error because
+it's being iterated over. Doing so will cause an irrecoverable fatal error because
 of concurrent reads and writes to an internal map.
 
 Although it's not recommended, you can iterate through values while writing to

docs/build/tooling/README.md

@@ -20,7 +20,8 @@ This includes tools for development, operating a node, and ease of use of a Cosm
 
 ## External Tools
 
-This section highlights tools that are not maintained by the SDK team, but are useful for Cosmos SDK development.
+This section highlights tools that are not maintained by the SDK team, but are useful for Cosmos SDK operations and development.
 
+* [Blazar](https://github.com/ChorusOne/blazar)
 * [Ignite](https://docs.ignite.com)
 * [Spawn](https://github.com/rollchains/spawn)

docs/user/run-node/01-run-node.md

@@ -132,7 +132,7 @@ When running a node (not a validator!) and not wanting to run the application me
 
 ```toml
 [mempool]
-# Setting max-txs to 0 will allow for a unbounded amount of transactions in the mempool.
+# Setting max-txs to 0 will allow for an unbounded amount of transactions in the mempool.
 # Setting max_txs to negative 1 (-1) will disable transactions from being inserted into the mempool.
 # Setting max_txs to a positive number (> 0) will limit the number of transactions in the mempool, by the specified amount.
 #

versioned_docs/version-0.52/build/architecture/adr-040-storage-and-smt-state-commitments.md

@@ -279,7 +279,7 @@ We were discussing use case where modules can use a support database, which is n
 ## References
 
 * [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
-* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15
+* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of its state v0.15
 * [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
 * [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
 * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)

versioned_docs/version-0.52/build/architecture/adr-045-check-delivertx-middlewares.md

@@ -18,7 +18,7 @@ This ADR replaces the current BaseApp `runTx` and antehandlers design with a mid
 
 BaseApp's implementation of ABCI `{Check,Deliver}Tx()` and its own `Simulate()` method call the `runTx` method under the hood, which first runs antehandlers, then executes `Msg`s. However, the [transaction Tips](https://github.com/cosmos/cosmos-sdk/issues/9406) and [refunding unused gas](https://github.com/cosmos/cosmos-sdk/issues/2150) use cases require custom logic to be run after the `Msg`s execution. There is currently no way to achieve this.
 
-An naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular.
+A naive solution would be to add post-`Msg` hooks to BaseApp. However, the Cosmos SDK team thinks in parallel about the bigger picture of making app wiring simpler ([#9181](https://github.com/cosmos/cosmos-sdk/discussions/9182)), which includes making BaseApp more lightweight and modular.
 
 ## Decision
 

versioned_docs/version-0.52/build/rfc/rfc-006-handlers.md

@@ -10,7 +10,7 @@ The Cosmos SDK has a very powerful and flexible module system that has been test
 and proven to be very good in production. The design of how messages are handled
 is built around Protobuf services and gRPC. This design was proposed and implemented
 during a time when we migrated from Amino to Protocol Buffers. This design has
-fulfilled the needs of users today. While this design is useful it has caused a
+fulfilled the needs of users today. While this design is useful it has caused an
 elevated learning curve to be adopted by users. Today, these services are the
 only way to write a module. This RFC proposes a new design that simplifies the
 design and enables new use cases we are seeing today.

versioned_docs/version-0.52/build/spec/store/README.md

@@ -103,7 +103,7 @@ responsibility of the caller to ensure that concurrent access to the store is
 not performed. 
 
 The main issue with concurrent use is when data is written at the same time as
-it's being iterated over. Doing so will cause a irrecoverable fatal error because
+it's being iterated over. Doing so will cause an irrecoverable fatal error because
 of concurrent reads and writes to an internal map.
 
 Although it's not recommended, you can iterate through values while writing to

versioned_docs/version-0.52/user/run-node/01-run-node.md

@@ -132,7 +132,7 @@ When running a node (not a validator!) and not wanting to run the application me
 
 ```toml
 [mempool]
-# Setting max-txs to 0 will allow for a unbounded amount of transactions in the mempool.
+# Setting max-txs to 0 will allow for an unbounded amount of transactions in the mempool.
 # Setting max_txs to negative 1 (-1) will disable transactions from being inserted into the mempool.
 # Setting max_txs to a positive number (> 0) will limit the number of transactions in the mempool, by the specified amount.
 #