diff --git a/contracts/test/invariants/handlers/SubnetRegistryHandler.sol b/contracts/test/invariants/handlers/SubnetRegistryHandler.sol index a842c2106..72b65ebb2 100644 --- a/contracts/test/invariants/handlers/SubnetRegistryHandler.sol +++ b/contracts/test/invariants/handlers/SubnetRegistryHandler.sol @@ -56,11 +56,11 @@ contract SubnetRegistryHandler is CommonBase, StdCheats, StdUtils { /// getRandomOldAddressOrNewOne returns a new random address function getRandomOldAddressOrNewOne(uint256 seed) internal view returns (address) { - uint256 lenght = ghost_owners.length(); - if (lenght == 0 || seed % 4 == 0) { + uint256 length = ghost_owners.length(); + if (length == 0 || seed % 4 == 0) { return msg.sender; } else { - return ghost_owners.values()[seed % lenght]; + return ghost_owners.values()[seed % length]; } } diff --git a/docs/fendermint/activity_rollups.md b/docs/fendermint/activity_rollups.md index 32cb53825..d99750a09 100644 --- a/docs/fendermint/activity_rollups.md +++ b/docs/fendermint/activity_rollups.md @@ -160,7 +160,7 @@ library Consensus { ValidatorData[] data; } - // The compresed representation of the activity summary for consensus-level activity suitable for embedding in a checkpoint. + // The compressed representation of the activity summary for consensus-level activity suitable for embedding in a checkpoint. struct CompressedSummary { AggregatedStats stats; /// The commitment for the validator details, so that we don't have to transmit them in full. @@ -268,7 +268,7 @@ This command takes: - the block ranges in the subnet we want to scan for eligible claims. - the address of the validator we want to claim rewards for. -The command will when scan the subnet for eligible claims within the specified block ranges, and will then submit the +The command will then scan the subnet for eligible claims within the specified block ranges, and will then submit the claim to the ancestor subnet using the batch claim method to amortize the gas cost. ```bash diff --git a/docs/fendermint/architecture.md b/docs/fendermint/architecture.md index 3e4077105..f7e6a52e6 100644 --- a/docs/fendermint/architecture.md +++ b/docs/fendermint/architecture.md @@ -17,10 +17,10 @@ The components in a nutshell: ## ABCI++ -We want make use of the ABCI++ interface to get more control over the voting process by implementing the new `PrepareProposal` and `ProcessProposal` methods. These are close to be [released](https://github.com/tendermint/tendermint/issues/9053) in the upcoming `v0.37` of Tendermint Core. +We want to make use of the ABCI++ interface to get more control over the voting process by implementing the new `PrepareProposal` and `ProcessProposal` methods. These are close to be [released](https://github.com/tendermint/tendermint/issues/9053) in the upcoming `v0.37` of Tendermint Core. The best place to look up the details of the ABCI++ spec is currently at https://github.com/tendermint/tendermint/tree/v0.37.0-rc2/spec/abci Note that the spec has previously been under the `main` branch but not any more, and that it changed recently to only contain the above two extra methods, but not _vote extensions_ for the new `FinalizeBlock` method, which was supposed to replace `BeginBlock`, `DeliverTx`, `EndBlock` and I think `Commit`. -The reason we want to be able to control voting is to evaludate the CIDs contained in blocks for data availability, before they are committed for execution. We can do this by simply not voting on any proposal that contains CIDs _for execution_ that are unavailable on the node of the validator. To make them available, we'll use a solution similar to [NC-Max](https://eprint.iacr.org/2020/1101) to propose CIDs _for resolution_ and inclusion in future blocks, thus moving data dissemination out of the critical path of consensus. +The reason we want to be able to control voting is to evaluate the CIDs contained in blocks for data availability, before they are committed for execution. We can do this by simply not voting on any proposal that contains CIDs _for execution_ that are unavailable on the node of the validator. To make them available, we'll use a solution similar to [NC-Max](https://eprint.iacr.org/2020/1101) to propose CIDs _for resolution_ and inclusion in future blocks, thus moving data dissemination out of the critical path of consensus. diff --git a/docs/fendermint/checkpointing.md b/docs/fendermint/checkpointing.md index 9c2a63fd5..5f0fc03e7 100644 --- a/docs/fendermint/checkpointing.md +++ b/docs/fendermint/checkpointing.md @@ -2,7 +2,7 @@ Bottom-up checkpoints are periodically submitted to the parent subnet, carrying: * bottom-up messages -* the next highest configuration number adopted form the validator changesets observed on the parent +* the next highest configuration number adopted from the validator changesets observed on the parent * a multi-sig from the current validator set * the identity of the checkpointed block height diff --git a/docs/fendermint/tendermint.md b/docs/fendermint/tendermint.md index 16f3964af..ce0437638 100644 --- a/docs/fendermint/tendermint.md +++ b/docs/fendermint/tendermint.md @@ -4,7 +4,7 @@ To implement the [architecture](./architecture.md) we intend to make use of the * [CometBFT](https://github.com/cometbft/cometbft): One of the successors of the generic blockchain SMR system [Tendermint Core](https://github.com/tendermint/tendermint) (others might be listed [here](https://github.com/tendermint/ecosystem)). Originally we used the upcoming [v0.37](https://github.com/tendermint/tendermint/tree/v0.37.0-rc2), but it was eventually released as part of CometBFT. This version has the required [extensions](./architecture.md#abci) to [ABCI++](https://github.com/cometbft/cometbft/tree/v0.37.1/spec/abci). * [tendermint-rs](https://github.com/informalsystems/tendermint-rs/) is a Rust library that contains Tendermint [datatypes](https://github.com/informalsystems/tendermint-rs/tree/main/tendermint); the [proto](https://github.com/informalsystems/tendermint-rs/tree/main/proto) code [generated](https://github.com/informalsystems/tendermint-rs/tree/main/tools/proto-compiler) from the Tendermint protobuf definitions; a synchronous [ABCI server](https://github.com/informalsystems/tendermint-rs/tree/main/abci) with a trait the application can implement, with a [KV-store example](https://github.com/informalsystems/tendermint-rs/blob/main/abci/src/application/kvstore/main.rs) familiar from the tutorial; and various other goodies for building docker images, integration testing the application with Tendermint, and so on. Since [this PR](https://github.com/informalsystems/tendermint-rs/pull/1193) the library supports both `v0.34` (the last stable release of Tendermint Core) and the newer `v0.37` version (the two are not wire compatible). -* [tower-abci](https://github.com/penumbra-zone/tower-abci) from Penumbra adapts the ABCI interfaces from `tendermint-rs` to be used with [tower](https://crates.io/crates/tower) and has a [server](https://github.com/penumbra-zone/tower-abci/blob/v0.7.0/src/v037/server.rs) implementation that works with the the `v0.37` wire format and uses [tokio](https://crates.io/crates/tokio). So, unlike the ABCI server in `tendermint-rs`, this is asynchronous, which we can make use of if we want to inject our own networking. +* [tower-abci](https://github.com/penumbra-zone/tower-abci) from Penumbra adapts the ABCI interfaces from `tendermint-rs` to be used with [tower](https://crates.io/crates/tower) and has a [server](https://github.com/penumbra-zone/tower-abci/blob/v0.7.0/src/v037/server.rs) implementation that works with the `v0.37` wire format and uses [tokio](https://crates.io/crates/tokio). So, unlike the ABCI server in `tendermint-rs`, this is asynchronous, which we can make use of if we want to inject our own networking. That should be enough to get us started with Tendermint. diff --git a/fendermint/rpc/src/query.rs b/fendermint/rpc/src/query.rs index e4ae6784d..61e06a008 100644 --- a/fendermint/rpc/src/query.rs +++ b/fendermint/rpc/src/query.rs @@ -45,7 +45,7 @@ pub trait QueryClient: Sync { extract_opt(res, |res| Ok(res.value)) } - /// Query the the state of an actor. + /// Query the state of an actor. async fn actor_state( &self, address: &Address, diff --git a/fendermint/testing/README.md b/fendermint/testing/README.md index 6694a2c72..2afff2242 100644 --- a/fendermint/testing/README.md +++ b/fendermint/testing/README.md @@ -11,6 +11,6 @@ The `fendermint_testing` crate (ie. the current directory) provides some reusabl Beyond this, for no other reason than code organisation, the directory has sub-projects, which contain actual tests. -For example the [smoke-test](./smoke-test/) is a a crate that uses `cargo make` to start a local stack with Tendermint and Fendermint running in Docker, and run some integration tests, which can be found in the [Makefile.toml](./smoke-test/Makefile.toml). +For example the [smoke-test](./smoke-test/) is a crate that uses `cargo make` to start a local stack with Tendermint and Fendermint running in Docker, and run some integration tests, which can be found in the [Makefile.toml](./smoke-test/Makefile.toml). To run these, either `cd` into that directory and run them from there, or run all from the root using `make e2e`, which also builds the docker images. diff --git a/fendermint/testing/contract-test/src/ipc/registry.rs b/fendermint/testing/contract-test/src/ipc/registry.rs index ffa54b000..9fedd0281 100644 --- a/fendermint/testing/contract-test/src/ipc/registry.rs +++ b/fendermint/testing/contract-test/src/ipc/registry.rs @@ -42,7 +42,7 @@ impl RegistryCaller { } impl RegistryCaller { - /// Create a new instance of the built-in subnet implemetation. + /// Create a new instance of the built-in subnet implementation. /// /// Returns the address of the deployed contract. pub fn new_subnet( diff --git a/fendermint/testing/contract-test/tests/staking/state.rs b/fendermint/testing/contract-test/tests/staking/state.rs index 9d574d625..12f67ce4b 100644 --- a/fendermint/testing/contract-test/tests/staking/state.rs +++ b/fendermint/testing/contract-test/tests/staking/state.rs @@ -250,7 +250,7 @@ impl StakingState { /// Check if checkpoints can be sent to the system. pub fn can_checkpoint(&self) -> bool { - // This is a technical thing of how the the state does transitions, it's all done in the checkpoint method. + // This is a technical thing of how the state does transitions, it's all done in the checkpoint method. if !self.activated { return true; } diff --git a/fendermint/vm/interpreter/src/fvm/state/ipc.rs b/fendermint/vm/interpreter/src/fvm/state/ipc.rs index 9a91429b3..b1836ee69 100644 --- a/fendermint/vm/interpreter/src/fvm/state/ipc.rs +++ b/fendermint/vm/interpreter/src/fvm/state/ipc.rs @@ -304,7 +304,7 @@ impl GatewayCaller { Ok(IPCParentFinality::from(r)) } - /// Get the Ethereum adresses of validators who signed a checkpoint. + /// Get the Ethereum addresses of validators who signed a checkpoint. pub fn checkpoint_signatories( &self, state: &mut FvmExecState, diff --git a/ipc/provider/src/manager/evm/manager.rs b/ipc/provider/src/manager/evm/manager.rs index eb401030c..491a2c5fc 100644 --- a/ipc/provider/src/manager/evm/manager.rs +++ b/ipc/provider/src/manager/evm/manager.rs @@ -598,7 +598,7 @@ impl SubnetManager for EthSubnetManager { let token_address = payload_to_evm_address( subnet_supply_source .token_address - .ok_or_else(|| anyhow!("zero adress not erc20"))? + .ok_or_else(|| anyhow!("zero address not erc20"))? .payload(), )?; let token_contract = IERC20::new(token_address, signer.clone()); diff --git a/ipld/resolver/docs/README.md b/ipld/resolver/docs/README.md index 4f60b78d1..0390ffbe0 100644 --- a/ipld/resolver/docs/README.md +++ b/ipld/resolver/docs/README.md @@ -63,7 +63,7 @@ The following diagram shows a typical sequence of events within the IPLD Resolve The diagrams in this directory can be rendered with `make diagrams`. -Adding the following script to `.git/hooks/pre-commit` automatically renders and checks in the images when we commit changes to the them. CI should also check that there are no uncommitted changes. +Adding the following script to `.git/hooks/pre-commit` automatically renders and checks in the images when we commit changes to them. CI should also check that there are no uncommitted changes. ```bash #!/usr/bin/env bash diff --git a/recall/iroh_manager/src/manager.rs b/recall/iroh_manager/src/manager.rs index af206e3be..64d4b8cec 100644 --- a/recall/iroh_manager/src/manager.rs +++ b/recall/iroh_manager/src/manager.rs @@ -53,7 +53,7 @@ impl IrohManager { }) } - /// Retrives a blob client, and starts the node if it has not started yet. + /// Retrieves a blob client, and starts the node if it has not started yet. pub fn blobs_client(&self) -> BlobsClient { self.client.blobs_client().boxed() } diff --git a/specs/addressing.md b/specs/addressing.md index 442ad1bff..2e9a5517b 100644 --- a/specs/addressing.md +++ b/specs/addressing.md @@ -2,7 +2,7 @@ ## IPC Actors addressing -### Filecoin adressing schemes +### Filecoin addressing schemes When the contracts described below (Gateway, Registry, Subnet) are deployed to a Filecoin network (e.g. Mainnet, Calibration), `f0`, `f2` and `f410` addresses will be assigned to them. The latter is equivalent to an Ethereum hex address. Detailed explanation of Filecoin addressing scheme is available in [the documentation](https://docs.filecoin.io/smart-contracts/filecoin-evm-runtime/address-types). diff --git a/specs/bottom-up-interaction.md b/specs/bottom-up-interaction.md index 15e42c7fe..28e4ab83c 100644 --- a/specs/bottom-up-interaction.md +++ b/specs/bottom-up-interaction.md @@ -58,7 +58,7 @@ Creating a checkpoint in the ledger is performed deterministically by every full After the checkpoint has been added to the ledger *and committed in a block*, those nodes which are currently validators broadcast transactions which add their signatures using the `broadcast_signature` function of the [`checkpoint`](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/vm/interpreter/src/fvm/checkpoint.rs) module. -The reason we wait for the the change to be committed is so that the transactions that add the signatures don’t get rejected by `check_tx` because they are referring to a non-existing checkpoint. +The reason we wait for the change to be committed is so that the transactions that add the signatures don’t get rejected by `check_tx` because they are referring to a non-existing checkpoint. The signing and sending of transactions happens in the [`broadcast`](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/vm/interpreter/src/fvm/broadcast.rs) module which fetches the current nonce of the validator, estimates the gas, performs retries, etc. Because it fetches the nonce for each submission, it cannot be used in parallel.