Merge branch 'main' into feat-fixed-celestiaorg#3078

Author: rootulp

docs/architecture/adr-018-network-upgrades.md

@@ -51,7 +51,7 @@ The height of the v1 -> v2 upgrade will initially be supplied via CLI flag (i.e.
 - Given the uncertainty in scheduling, the system must be able to handle changes to the upgrade height that most commonly would come in the form of delays. Embedding the upgrade schedule in the binary is convenient for node operators and avoids the possibility for user errors. However, binaries are static. If the community wished to push back the upgrade by two weeks there is the possibility that some nodes would not rerun the new binary thus we'd get a split between nodes running the old schedule and nodes running the new schedule. To overcome this, proposers will only propose a version change in the first round of each height, thus allowing transactions to still be committed even under circumstances where there is no consensus on upgrading. Secondly, we define a range in which nodes will attempt to upgrade the app version and failing this will continue to run the current version. Lastly, the binary will have the ability to manually specify the app version height mapping and override the built-in values either through a flag or in the `app.toml` config. This is expected to be used in testing and in emergency situations only. Another example to keep in mind is if a quorum outright rejects an upgrade. If some of the validators are for the change they should have some way to continue participating in the network. Therefore we employ a range that nodes will attempt to upgrade and afterwards will continue on normally with the new binary however running the older version.
 - The system needs to be tolerant of unexpected faults in the upgrade process. This can be:
   - The community/contributors realize there is a bug in the new version after the binary has been released. Node operators will need to downgrade back to the previous version and restart their node.
-  - There is a halting bug in the migration or in processing of the first transactions. This most likely would be in the form of an apphash mismatch. This becomes more problematic with delayed execution as the block (with v2 transactions) has already been committed. Immediate execution has the advantage of the apphash mismatch being realised before the data is committed. It's still however feasible to over come this but it involves nodes rolling back the previous state and re-exectuing the transactions using the v1 state machine (which will skip over the v2 transactions). This means node operators should be able to manually override the app version that the proposer will propose with. Lastly, if state migrations occurred between v2 and v1, a reverse migration would need to be performed which would make things especially difficult. If we are unable to fallback to the previous version and continue then the other option is to remain halted until the bug is patched and the network can update and continue
+  - There is a halting bug in the migration or in processing of the first transactions. This most likely would be in the form of an apphash mismatch. This becomes more problematic with delayed execution as the block (with v2 transactions) has already been committed. Immediate execution has the advantage of the apphash mismatch being realised before the data is committed. It's still however feasible to over come this but it involves nodes rolling back the previous state and re-executing the transactions using the v1 state machine (which will skip over the v2 transactions). This means node operators should be able to manually override the app version that the proposer will propose with. Lastly, if state migrations occurred between v2 and v1, a reverse migration would need to be performed which would make things especially difficult. If we are unable to fallback to the previous version and continue then the other option is to remain halted until the bug is patched and the network can update and continue
   - There is a bug that is detected that could halt the chain but hasn't yet. There are other things we can develop to combat such scenarios. One thing we can do is develop a circuit breaker similar to the designs proposed in [Cosmos SDK](https://github.com/cosmos/cosmos-sdk/tree/main/x/circuit). This can disable certain message types or modules either in `CheckTx` or `ProcessProposal`. This violates the consistency property between `PrepareProposal` and `ProcessProposal` but so long as a quorum are the same, will still allow the chain to progress (inconsistency here can be interpreted as byzantine).
 
 ### Future Work: Signaled Upgrade Height

proto/celestia/qgb/v1/types.proto

@@ -15,7 +15,7 @@ message BridgeValidator {
   string evm_address = 2;
 }
 
-// Valset is the EVM Bridge Multsig Set, each Blobstream validator also
+// Valset is the EVM Bridge Multisig Set, each Blobstream validator also
 // maintains an ETH key to sign messages, these are used to check signatures on
 // ETH because of the significant gas savings
 message Valset {

test/txsim/stake.go

@@ -80,7 +80,7 @@ func (s *StakeSequence) Next(ctx context.Context, querier grpc.ClientConn, rand
 						DelegatorAddress:    s.account.String(),
 						ValidatorSrcAddress: s.delegatedTo,
 						ValidatorDstAddress: val.OperatorAddress,
-						// NOTE: only the initial stake is redelgated (not the entire balance)
+						// NOTE: only the initial stake is redelegated (not the entire balance)
 						Amount: types.NewInt64Coin(appconsts.BondDenom, int64(s.initialStake)),
 					},
 				},

test/util/genesis/accounts.go

@@ -71,7 +71,7 @@ func NewDefaultValidator(name string) Validator {
 	}
 }
 
-// ValidateBasic performs stateless validation on the validitor
+// ValidateBasic performs stateless validation on the validator
 func (v *Validator) ValidateBasic() error {
 	if err := v.KeyringAccount.ValidateBasic(); err != nil {
 		return err

test/util/malicious/out_of_order_prepare.go

@@ -52,7 +52,7 @@ func (a *App) OutOfOrderPrepareProposal(req abci.RequestPrepareProposal) abci.Re
 	}
 
 	// erasure the data square which we use to create the data root. Note: this
-	// is using a modified version of nmt where the order of the namepspaces is
+	// is using a modified version of nmt where the order of the namespaces is
 	// not enforced.
 	eds, err := ExtendShares(share.ToBytes(dataSquare))
 	if err != nil {

test/util/malicious/tree.go

@@ -14,7 +14,7 @@ import (
 
 // BlindTree is a wrapper around the erasured NMT that skips verification of
 // namespace ordering when hashing and adding leaves to the tree. It does this
-// by using a custom malicious hahser and wraps using the ForceAddLeaf method
+// by using a custom malicious hasher and wraps using the ForceAddLeaf method
 // instead of the normal Push.
 type BlindTree struct {
 	*nmt.NamespacedMerkleTree