fix: add v53 support, remove v52, fix scripts, etc (#282)

* append to versions.json

* this works lol

* works'

* fix sidebar

* fixes

* ok

* handle special case

* add comment on special case

* sync and banners

* sync

* fixed

* re-sync

* restore v47 directory contents

Author: technicallyty

docs/build/abci/00-introduction.md

@@ -2,9 +2,9 @@
 
 ## What is ABCI?
 
-ABCI, Application Blockchain Interface is the interface between CometBFT and the application. More information about ABCI can be found in the specs [here](https://docs.cometbft.com/v1.0/spec/abci/). Within the release of ABCI 2.0 for the 0.38 CometBFT release there were additional methods introduced.
+ABC, Application Blockchain Interface is the interface between CometBFT and the application, more information about ABCI can be found [here](https://docs.cometbft.com/v0.38/spec/abci/). Within the release of ABCI 2.0 for the 0.38 CometBFT release there were additional methods introduced.
 
-The 5 methods introduced during ABCI 2.0 (compared to ABCI v0) are:
+The 5 methods introduced during ABCI 2.0 are:
 
 * `PrepareProposal`
 * `ProcessProposal`
@@ -17,11 +17,11 @@ The 5 methods introduced during ABCI 2.0 (compared to ABCI v0) are:
 
 ## PrepareProposal
 
-Based on validator voting power, CometBFT chooses a block proposer and calls `PrepareProposal` on the block proposer's application (Cosmos SDK). The selected block proposer is responsible for collecting outstanding transactions from the mempool, adhering to the application's specifications. The application can enforce custom transaction ordering and incorporate additional transactions, potentially generated from vote extensions in the previous block.
+Based on their voting power, CometBFT chooses a block proposer and calls `PrepareProposal` on the block proposer's application (Cosmos SDK). The selected block proposer is responsible for collecting outstanding transactions from the mempool, adhering to the application's specifications. The application can enforce custom transaction ordering and incorporate additional transactions, potentially generated from vote extensions in the previous block.
 
-To perform this manipulation on the application side, a custom handler must be implemented. By default, the Cosmos SDK provides `PrepareProposalHandler`, used in conjunction with an application specific mempool. A custom handler can be written by application developer, if a noop handler provided, all transactions are considered valid.
+To perform this manipulation on the application side, a custom handler must be implemented. By default, the Cosmos SDK provides `PrepareProposalHandler`, used in conjunction with an application specific mempool. A custom handler can be written by application developer, if a noop handler provided, all transactions are considered valid. Please see [this](https://github.com/fatal-fruit/abci-workshop) tutorial for more information on custom handlers.
 
-Please note that vote extensions will only be available on the following height in which vote extensions are enabled. More information about vote extensions can be found [here](https://docs.cosmos.network/main/build/abci/vote-extensions).
+Please note that vote extensions will only be available on the following height in which vote extensions are enabled. More information about vote extensions can be found [here](https://docs.cosmos.network/main/build/abci/03-vote-extensions.md).
 
 After creating the proposal, the proposer returns it to CometBFT.
 
@@ -41,11 +41,11 @@ If vote extensions are enabled, `ExtendVote` will be called on every validator a
 
 `VerifyVoteExtensions` is performed on every validator multiple times in order to verify other validators' vote extensions. This check is submitted to validate the integrity and validity of the vote extensions preventing malicious or invalid vote extensions.
 
-Additionally, applications must keep the vote extension data concise as it can degrade the performance of their chain, see testing results [here](https://docs.cometbft.com/v1.0/references/qa/cometbft-qa-38#vote-extensions-testbed).
+Additionally, applications must keep the vote extension data concise as it can degrade the performance of their chain, see testing results [here](https://docs.cometbft.com/v0.38/qa/cometbft-qa-38#vote-extensions-testbed).
 
 `VerifyVoteExtensions` MUST be deterministic.
 
 
 ## FinalizeBlock
 
-`FinalizeBlock` is then called and is responsible for updating the state of the blockchain and making the block available to users.
+`FinalizeBlock` is then called and is responsible for updating the state of the blockchain and making the block available to users

docs/build/abci/01-prepare-proposal.md

@@ -24,22 +24,22 @@ it would like the block constructed.
 
 The Cosmos SDK defines the `DefaultProposalHandler` type, which provides applications with
 `PrepareProposal` and `ProcessProposal` handlers. If you decide to implement your
-own `PrepareProposal` handler, you must ensure that the transactions
+own `PrepareProposal` handler, you must be sure to ensure that the transactions
 selected DO NOT exceed the maximum block gas (if set) and the maximum bytes provided
 by `req.MaxBytes`.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/baseapp/abci_utils.go
+https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go
 ```
 
 This default implementation can be overridden by the application developer in
-favor of a custom implementation in [`app_di.go`](https://docs.cosmos.network/main/build/building-apps/app-go-di):
+favor of a custom implementation in [`app.go`](../building-apps/01-app-go-v2.md):
 
 ```go
 prepareOpt := func(app *baseapp.BaseApp) {
-    abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
-    app.SetPrepareProposal(abciPropHandler.PrepareProposalHandler())
+abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
+app.SetPrepareProposal(abciPropHandler.PrepareProposalHandler())
 }
 
 baseAppOptions = append(baseAppOptions, prepareOpt)
-```
+```

docs/build/abci/02-process-proposal.md

@@ -2,30 +2,30 @@
 
 `ProcessProposal` handles the validation of a proposal from `PrepareProposal`,
 which also includes a block header. Meaning, that after a block has been proposed
-the other validators have the right to accept or reject that block. The validator in the
+the other validators have the right to vote on a block. The validator in the
 default implementation of `PrepareProposal` runs basic validity checks on each
 transaction.
 
 Note, `ProcessProposal` MAY NOT be non-deterministic, i.e. it must be deterministic.
 This means if `ProcessProposal` panics or fails and we reject, all honest validator
-processes should reject (i.e., prevote nil). If so, then CometBFT will start a new round with a new block proposal, and the same cycle will happen with `PrepareProposal`
-and `ProcessProposal` for the new proposal.
+processes will prevote nil and the CometBFT round will proceed again until a valid
+proposal is proposed.
 
 Here is the implementation of the default implementation:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/baseapp/abci_utils.go#L224-L231
+https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci_utils.go#L153-L159
 ```
 
 Like `PrepareProposal` this implementation is the default and can be modified by
-the application developer in [`app_di.go`](https://docs.cosmos.network/main/build/building-apps/app-go-di). If you decide to implement
-your own `ProcessProposal` handler, you must ensure that the transactions
+the application developer in [`app.go`](../building-apps/01-app-go-v2.md). If you decide to implement
+your own `ProcessProposal` handler, you must be sure to ensure that the transactions
 provided in the proposal DO NOT exceed the maximum block gas and `maxtxbytes` (if set).
 
 ```go
 processOpt := func(app *baseapp.BaseApp) {
-    abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
-    app.SetProcessProposal(abciPropHandler.ProcessProposalHandler())
+abciPropHandler := baseapp.NewDefaultProposalHandler(mempool, app)
+app.SetProcessProposal(abciPropHandler.ProcessProposalHandler())
 }
 
 baseAppOptions = append(baseAppOptions, processOpt)

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

@@ -7,49 +7,50 @@ defined in ABCI++.
 
 ## Extend Vote
 
-ABCI2.0 (colloquially called ABCI++) allows an application to extend a pre-commit vote with arbitrary data. This process does NOT have to be deterministic, and the data returned can be unique to the
-validator process. The Cosmos SDK defines [`baseapp.ExtendVoteHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/types/abci.go#L26-L27):
+ABCI++ allows an application to extend a pre-commit vote with arbitrary data. This
+process does NOT have to be deterministic, and the data returned can be unique to the
+validator process. The Cosmos SDK defines [`baseapp.ExtendVoteHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L26-L27):
 
 ```go
-type ExtendVoteHandler func(Context, *abci.ExtendVoteRequest) (*abci.ExtendVoteResponse, error)
+type ExtendVoteHandler func(Context, *abci.RequestExtendVote) (*abci.ResponseExtendVote, error)
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetExtendVoteHandler`
 `BaseApp` option function. The `sdk.ExtendVoteHandler`, if defined, is called during
 the `ExtendVote` ABCI method. Note, if an application decides to implement
 `baseapp.ExtendVoteHandler`, it MUST return a non-nil `VoteExtension`. However, the vote
-extension can be empty. See [here](https://docs.cometbft.com/v1.0/spec/abci/abci++_methods#extendvote)
+extension can be empty. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/spec/abci/abci++_methods.md#extendvote)
 for more details.
 
 There are many decentralized censorship-resistant use cases for vote extensions.
 For example, a validator may want to submit prices for a price oracle or encryption
 shares for an encrypted transaction mempool. Note, an application should be careful
 to consider the size of the vote extensions as they could increase latency in block
-production. See [here](https://docs.cometbft.com/v1.0/references/qa/cometbft-qa-38#vote-extensions-testbed)
+production. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/docs/qa/CometBFT-QA-38.md#vote-extensions-testbed)
 for more details.
 
-Click [here](https://docs.cosmos.network/main/build/abci/vote-extensions) if you would like a walkthrough of how to implement vote extensions.
+Click [here](https://docs.cosmos.network/main/user/tutorials/vote-extensions) if you would like a walkthrough of how to implement vote extensions.
 
 
 ## Verify Vote Extension
 
 Similar to extending a vote, an application can also verify vote extensions from
 other validators when validating their pre-commits. For a given vote extension,
-this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/types/abci.go#L29-L31):
+this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L29-L31):
 
 ```go
-type VerifyVoteExtensionHandler func(Context, *abci.VerifyVoteExtensionRequest) (*abci.VerifyVoteExtensionResponse, error)
+type VerifyVoteExtensionHandler func(Context, *abci.RequestVerifyVoteExtension) (*abci.ResponseVerifyVoteExtension, error)
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetVerifyVoteExtensionHandler`
 `BaseApp` option function. The `sdk.VerifyVoteExtensionHandler`, if defined, is called
 during the `VerifyVoteExtension` ABCI method. If an application defines a vote
 extension handler, it should also define a verification handler. Note, not all
 validators will share the same view of what vote extensions they verify depending
-on how votes are propagated. See [here](https://docs.cometbft.com/v1.0/spec/abci/abci++_methods#verifyvoteextension)
+on how votes are propagated. See [here](https://github.com/cometbft/cometbft/blob/v0.38.0-rc1/spec/abci/abci++_methods.md#verifyvoteextension)
 for more details.
 
-Additionally, please keep in mind that performance can be degraded if vote extensions are too big ([see vote extension testbed](https://docs.cometbft.com/v1.0/references/qa/cometbft-qa-38#vote-extensions-testbed)), so we highly recommend a size validation in `VerifyVoteExtensions`.
+Additionally, please keep in mind that performance can be degraded if vote extensions are too big (https://docs.cometbft.com/v0.38/qa/cometbft-qa-38#vote-extensions-testbed), so we highly recommend a size validation in `VerifyVoteExtensions`.
 
 
 ## Vote Extension Propagation
@@ -120,163 +121,3 @@ 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
-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/abci/04-checktx.md

@@ -20,7 +20,7 @@ https://github.com/cosmos/cosmos-sdk/blob/31c604762a434c7b676b6a89897ecbd7c4653a
 
 ## CheckTx Handler
 
-`CheckTxHandler` allows users to extend the logic of `CheckTx`. `CheckTxHandler` is called by pasding context and the transaction bytes received through ABCI. It is required that the handler returns deterministic results given the same transaction bytes. 
+`CheckTxHandler` allows users to extend the logic of `CheckTx`. `CheckTxHandler` is called by passing context and the transaction bytes received through ABCI. It is required that the handler returns deterministic results given the same transaction bytes. 
 
 :::note
 we return the raw decoded transaction here to avoid decoding it twice.