From aad015b45075dfdc5f3d5944a78c8af8eb9c2857 Mon Sep 17 00:00:00 2001 From: Christian Gorenflo Date: Mon, 4 Mar 2024 12:13:25 -0500 Subject: [PATCH] chore: fix typos across the repo (#286) --- .github/actions/release/action.yaml | 2 +- .github/workflows/release.yaml | 2 +- README.md | 29 ++++++-- ampd/src/config.rs | 2 +- contracts/aggregate-verifier/Cargo.toml | 6 +- contracts/connection-router/Cargo.toml | 6 +- contracts/gateway/Cargo.toml | 6 +- contracts/multisig-prover/Cargo.toml | 6 +- contracts/multisig-prover/src/encoding/bcs.rs | 2 +- contracts/multisig/Cargo.toml | 6 +- contracts/multisig/src/events.rs | 2 +- contracts/multisig/src/msg.rs | 2 +- contracts/rewards/Cargo.toml | 6 +- contracts/rewards/src/contract.rs | 2 +- contracts/rewards/src/contract/execute.rs | 4 +- contracts/rewards/src/state.rs | 4 +- contracts/service-registry/Cargo.toml | 6 +- contracts/service-registry/src/state.rs | 2 +- contracts/service-registry/tests/tests.rs | 2 +- contracts/voting-verifier/Cargo.toml | 6 +- contracts/voting-verifier/src/contract.rs | 2 +- contracts/voting-verifier/src/events.rs | 2 +- doc/README.md | 5 +- doc/src/SUMMARY.md | 20 +++--- doc/src/contracts/multisig.md | 25 +++++-- doc/src/contracts/multisig_prover.md | 32 ++++++--- doc/src/contracts/service_registry.md | 33 +++++----- doc/src/contracts/voting_verifier.md | 15 ++--- doc/src/contributing/documentation.md | 10 ++- doc/src/overview.md | 66 +++++++++++++------ integration-tests/Cargo.toml | 6 +- integration-tests/tests/test_utils/mod.rs | 2 +- packages/axelar-wasm-std/Cargo.toml | 6 +- packages/axelar-wasm-std/src/voting.rs | 4 +- packages/connection-router-api/src/msg.rs | 4 +- .../connection-router-api/src/primitives.rs | 2 +- packages/report/src/loggable.rs | 2 +- 37 files changed, 202 insertions(+), 137 deletions(-) diff --git a/.github/actions/release/action.yaml b/.github/actions/release/action.yaml index 39bf1355b..2796ba234 100644 --- a/.github/actions/release/action.yaml +++ b/.github/actions/release/action.yaml @@ -88,7 +88,7 @@ runs: Please check the tags and use the patch commit as the base for the new release. - Retreive the latest patch commit from the tag: + Retrieve the latest patch commit from the tag: git tag --list ${{inputs.binary-to-release}}-v* Checkout the tag: diff --git a/.github/workflows/release.yaml b/.github/workflows/release.yaml index 56dd24f6d..b07e12117 100644 --- a/.github/workflows/release.yaml +++ b/.github/workflows/release.yaml @@ -8,7 +8,7 @@ on: type: choice options: - ampd - - agggregate-verifier + - aggregate-verifier - connection-router - gateway - multisig diff --git a/README.md b/README.md index 5eadb3390..788c1f9d4 100644 --- a/README.md +++ b/README.md @@ -1,22 +1,37 @@ # Axelar Amplifier -The Interchain Amplifier enables developers to permissionlessly set up connections to the Axelar network. Developers gain access to Axelar's interconnected network of chains and can "amplify" their resources by paying the cost equivalent to developing only one connection. They can establish connections between new ecosystems or existing chains to add new network properties, such as improved security or better delivery and availability. +The Interchain Amplifier enables developers to permissionlessly set up connections to the Axelar network. Developers +gain access to Axelar's interconnected network of chains and can "amplify" their resources by paying the cost equivalent +to developing only one connection. They can establish connections between new ecosystems or existing chains to add new +network properties, such as improved security or better delivery and availability. ### Documentation High level documentation and diagrams can be found in the [doc](doc/README.md) directory. ### Contract Json Schemas -Json schemas for types used in the contract apis can be generated by navigating to the `./contracts/{contract_name}` directory and running `cargo schema`. This will generate a `./contracts/{contract_name}/schema` directory containing the json schemas for types used to instantiate, execute, query etc. +Json schemas for types used in the contract apis can be generated by navigating to the `./contracts/{contract_name}` +directory and running `cargo schema`. This will generate a `./contracts/{contract_name}/schema` directory containing the +json schemas for types used to instantiate, execute, query etc. ### Development and Testing -When developing contracts to integrate with amplifier, the `cw-multi-test` crate can be used to create a simulated blockchain environment, where different contracts can deployed and interacted with, and contracts can interact with each other. See the [integration-tests](integration-tests) package for examples, as well as reusable helper functions. +When developing contracts to integrate with amplifier, the `cw-multi-test` crate can be used to create a simulated +blockchain environment, where different contracts can be deployed and interacted with, and contracts can interact with +each other. See the [integration-tests](integration-tests) package for examples, as well as reusable helper functions. ### Versioning -The semver for new releases is calculated automatically based on the commit messages and the folders where changes were made. The configuration for each piece of software released (e.g ampd, gateway...) can be seen in the release.yaml file. You can perform a dry-run using the release action to be sure that the next version is what you intend it to be. The basic rules are as follows: - - a commit with a message that does not include any associated tag (e.g major-contracts) for release will be considered a patch release - - a commit with a message with minor tag e.g `feat(minor-ampd):...` will be considered a minor release, and the same logic applies to major releases - - if no changes are detected in the watched directories, the release will not bump the version. For example, if since last release for the gateway contract no changes were made in the `contracts/gateway` or `packages/` directory. A new release will not bump the version. +The semver for new releases is calculated automatically based on the commit messages and the folders where changes were +made. The configuration for each piece of software released (e.g. ampd, gateway...) can be seen in the release.yaml +file. You can perform a dry-run using the release action to be sure that the next version is what you intend it to be. +The basic rules are as follows: + +- a commit with a message that does not include any associated tag (e.g. major-contracts) for release will be considered + a patch release +- a commit with a message with minor tag e.g. `feat(minor-ampd):...` will be considered a minor release, and the same + logic applies to major releases +- if no changes are detected in the watched directories, the release will not bump the version. For example, if since + last release for the gateway contract no changes were made in the `contracts/gateway` or `packages/` directory. A new + release will not bump the version. diff --git a/ampd/src/config.rs b/ampd/src/config.rs index 392b17b39..9b5e1b798 100644 --- a/ampd/src/config.rs +++ b/ampd/src/config.rs @@ -170,7 +170,7 @@ mod tests { } #[test] - fn deserialize_handlers_more_then_one_for_mulsitig_signer() { + fn deserialize_handlers_more_then_one_for_multisig_signer() { let config_str = format!( " [[handlers]] diff --git a/contracts/aggregate-verifier/Cargo.toml b/contracts/aggregate-verifier/Cargo.toml index 4a8796215..93b91163f 100644 --- a/contracts/aggregate-verifier/Cargo.toml +++ b/contracts/aggregate-verifier/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Aggregate verifier contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/connection-router/Cargo.toml b/contracts/connection-router/Cargo.toml index 323ee2692..0145b92bc 100644 --- a/contracts/connection-router/Cargo.toml +++ b/contracts/connection-router/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Connection router contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/gateway/Cargo.toml b/contracts/gateway/Cargo.toml index 5e665bab3..3b3025370 100644 --- a/contracts/gateway/Cargo.toml +++ b/contracts/gateway/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Gateway contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/multisig-prover/Cargo.toml b/contracts/multisig-prover/Cargo.toml index 38363fda9..cd242ccb4 100644 --- a/contracts/multisig-prover/Cargo.toml +++ b/contracts/multisig-prover/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Multisig prover contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/multisig-prover/src/encoding/bcs.rs b/contracts/multisig-prover/src/encoding/bcs.rs index f16dc8e26..3b17c8fa2 100644 --- a/contracts/multisig-prover/src/encoding/bcs.rs +++ b/contracts/multisig-prover/src/encoding/bcs.rs @@ -144,7 +144,7 @@ pub fn encode(data: &Data) -> HexBinary { pub fn msg_digest(command_batch: &CommandBatch) -> HexBinary { // Sui is just mimicking EVM here let unsigned = [ - "\x19Sui Signed Message:\n".as_bytes(), // Keccek256 hash length = 32 + "\x19Sui Signed Message:\n".as_bytes(), // Keccak256 hash length = 32 encode(&command_batch.data).as_slice(), ] .concat(); diff --git a/contracts/multisig/Cargo.toml b/contracts/multisig/Cargo.toml index f797a879b..653eb805c 100644 --- a/contracts/multisig/Cargo.toml +++ b/contracts/multisig/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Multisig contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/multisig/src/events.rs b/contracts/multisig/src/events.rs index 23218e235..dcc8696dc 100644 --- a/contracts/multisig/src/events.rs +++ b/contracts/multisig/src/events.rs @@ -19,7 +19,7 @@ pub enum Event { chain_name: ChainName, expires_at: u64, }, - // Emitted when a participants submits a signature + // Emitted when a participant submits a signature SignatureSubmitted { session_id: Uint64, participant: Addr, diff --git a/contracts/multisig/src/msg.rs b/contracts/multisig/src/msg.rs index d5baeff1a..6c500aa1e 100644 --- a/contracts/multisig/src/msg.rs +++ b/contracts/multisig/src/msg.rs @@ -48,7 +48,7 @@ pub enum ExecuteMsg { AuthorizeCaller { contract_address: Addr, }, - // Unauthorizes a contract so it can no longer call StartSigningSession. + // Unauthorizes a contract, so it can no longer call StartSigningSession. UnauthorizeCaller { contract_address: Addr, }, diff --git a/contracts/rewards/Cargo.toml b/contracts/rewards/Cargo.toml index 4bac85b6d..e14fce376 100644 --- a/contracts/rewards/Cargo.toml +++ b/contracts/rewards/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Validator rewards contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/rewards/src/contract.rs b/contracts/rewards/src/contract.rs index e6ac590f0..e449adfa5 100644 --- a/contracts/rewards/src/contract.rs +++ b/contracts/rewards/src/contract.rs @@ -232,7 +232,7 @@ mod tests { ); assert!(res.is_ok()); - // need to change the block height so we can claim rewards + // need to change the block height, so we can claim rewards let old_height = app.block_info().height; app.set_block(BlockInfo { height: old_height + u64::from(initial_params.epoch_duration) * 2, diff --git a/contracts/rewards/src/contract/execute.rs b/contracts/rewards/src/contract/execute.rs index 55d0edcaf..ae4229276 100644 --- a/contracts/rewards/src/contract/execute.rs +++ b/contracts/rewards/src/contract/execute.rs @@ -298,7 +298,7 @@ mod test { .is_err()); } - /// Tests that the current epoch is computed correctly when the expected epoch is different than the stored epoch + /// Tests that the current epoch is computed correctly when the expected epoch is different from the stored epoch #[test] fn current_epoch_different_epoch() { let cur_epoch_num = 1u64; @@ -896,7 +896,7 @@ mod test { } // we add 2 epochs worth of rewards. There were 2 epochs of participation, but only 2 epochs where rewards should be given out - // This tests we are accounting correctly, and only removing from the pool when we actually give out rewards + // These tests we are accounting correctly, and only removing from the pool when we actually give out rewards let rewards_added = 2 * rewards_per_epoch; let _ = contract.add_rewards( pool_id.clone(), diff --git a/contracts/rewards/src/state.rs b/contracts/rewards/src/state.rs index 8139ad0e4..cd020786b 100644 --- a/contracts/rewards/src/state.rs +++ b/contracts/rewards/src/state.rs @@ -513,7 +513,7 @@ mod test { assert!(loaded.is_ok()); assert!(loaded.unwrap().is_none()); - // save the first water mark + // save the first watermark let res = store.save_rewards_watermark(pool_id.clone(), epoch.epoch_num); assert!(res.is_ok()); @@ -541,7 +541,7 @@ mod test { assert!(loaded.is_ok()); assert!(loaded.unwrap().is_none()); - // save the first water mark for this contract + // save the first watermark for this contract let res = store.save_rewards_watermark(diff_pool_id.clone(), epoch.epoch_num + 7); assert!(res.is_ok()); diff --git a/contracts/service-registry/Cargo.toml b/contracts/service-registry/Cargo.toml index 6b9535257..e59d9d7e5 100644 --- a/contracts/service-registry/Cargo.toml +++ b/contracts/service-registry/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Contract handling the service registrations" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/service-registry/src/state.rs b/contracts/service-registry/src/state.rs index aafc68ded..bda65eee3 100644 --- a/contracts/service-registry/src/state.rs +++ b/contracts/service-registry/src/state.rs @@ -44,7 +44,7 @@ impl TryFrom for Participant { match worker.bonding_state { BondingState::Bonded { amount: _ } => Ok(Self { address: worker.address, - // Weight is set to one to ensure all workers have same weight. In future it should be derived from amount bonded + // Weight is set to one to ensure all workers have same weight. In the future, it should be derived from amount bonded // If the weight is changed to a non-constant value, the signing session completed event from multisig and the signature // optimization during proof construction may require re-evaluation, so that relayers could take advantage of late // signatures to get a more optimized version of the proof. diff --git a/contracts/service-registry/tests/tests.rs b/contracts/service-registry/tests/tests.rs index abb864373..42e8f1933 100644 --- a/contracts/service-registry/tests/tests.rs +++ b/contracts/service-registry/tests/tests.rs @@ -811,7 +811,7 @@ fn deregister_previously_unsupported_single_chain() { assert_eq!(workers, vec![]) } -/// If a unbonded but authorized worker deregisters support for a chain they previously registered support for, +/// If an unbonded but authorized worker deregisters support for a chain they previously registered support for, /// that worker should not be part of the active worker set for that chain. #[test] fn register_and_deregister_support_for_single_chain_unbonded() { diff --git a/contracts/voting-verifier/Cargo.toml b/contracts/voting-verifier/Cargo.toml index 0357098f3..a5e35774d 100644 --- a/contracts/voting-verifier/Cargo.toml +++ b/contracts/voting-verifier/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Voting verifier contract" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/contracts/voting-verifier/src/contract.rs b/contracts/voting-verifier/src/contract.rs index f3470fc5e..ed7567aa9 100644 --- a/contracts/voting-verifier/src/contract.rs +++ b/contracts/voting-verifier/src/contract.rs @@ -426,7 +426,7 @@ mod test { ); // 3. Retry verification. From the three messages that reached consensus, only the first two have a - // status considered final (SucceddedOnChan or FailedOnChain), so the last two are retried + // status considered final (SucceededOnChan or FailedOnChain), so the last two are retried let res = execute( deps.as_mut(), diff --git a/contracts/voting-verifier/src/events.rs b/contracts/voting-verifier/src/events.rs index aed668bd1..44119d3bb 100644 --- a/contracts/voting-verifier/src/events.rs +++ b/contracts/voting-verifier/src/events.rs @@ -135,7 +135,7 @@ pub struct TxEventConfirmation { pub destination_chain: ChainName, pub source_address: Address, /// for better user experience, the payload hash gets encoded into hex at the edges (input/output), - /// but internally, we treat it as raw bytes to enforce it's format. + /// but internally, we treat it as raw bytes to enforce its format. #[serde(with = "axelar_wasm_std::hex")] #[schemars(with = "String")] // necessary attribute in conjunction with #[serde(with ...)] pub payload_hash: [u8; 32], diff --git a/doc/README.md b/doc/README.md index 57c04fa3c..88a313bee 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,6 +1,6 @@ ## How to read the docs -You can directly navigate through the markdown files [here](./src) or build the book locally using `mdbook`. +You can directly navigate through the markdown files [here](src) or build the book locally using `mdbook`. ## Prerequisites to build book @@ -32,4 +32,5 @@ mdbook serve doc --open ## Contributing -Information about how to contribute to the documentation can be found in the documentation chapter [here](http://localhost:3000/contributing/documentation.html) +Information about how to contribute to the documentation can be found in the documentation +chapter [here](http://localhost:3000/contributing/documentation.html) diff --git a/doc/src/SUMMARY.md b/doc/src/SUMMARY.md index 9aef70d06..6a2c54a54 100644 --- a/doc/src/SUMMARY.md +++ b/doc/src/SUMMARY.md @@ -1,18 +1,18 @@ # Summary -[Overview](./overview.md) +[Overview](overview.md) # Contracts -- [Service Registry](./contracts/service_registry.md) -- [Connection Router](./contracts/connection_router.md) -- [Multisig](./contracts/multisig.md) -- [Gateway](./contracts/gateway.md) -- [Aggregate Verifier](./contracts/aggregate_verifier.md) -- [Voting Verifier](./contracts/voting_verifier.md) -- [Multisig Prover](./contracts/multisig_prover.md) -- [Rewards](./contracts/rewards.md) +- [Service Registry](contracts/service_registry.md) +- [Connection Router](contracts/connection_router.md) +- [Multisig](contracts/multisig.md) +- [Gateway](contracts/gateway.md) +- [Aggregate Verifier](contracts/aggregate_verifier.md) +- [Voting Verifier](contracts/voting_verifier.md) +- [Multisig Prover](contracts/multisig_prover.md) +- [Rewards](contracts/rewards.md) # Contributing -- [Documentation](./contributing/documentation.md) +- [Documentation](contributing/documentation.md) diff --git a/doc/src/contracts/multisig.md b/doc/src/contracts/multisig.md index 0c29c776e..3f27445e8 100644 --- a/doc/src/contracts/multisig.md +++ b/doc/src/contracts/multisig.md @@ -1,6 +1,7 @@ # Multisig contract -This contract is used by the prover contract during proof construction to start a signing session and collect signatures from participants. +This contract is used by the prover contract during proof construction to start a signing session and collect signatures +from participants. ```mermaid flowchart TD @@ -15,9 +16,15 @@ s--SubmitSignature-->m b--GetSigningSession-->m ``` -- **StartSigningSession**: The multisig contract receives a binary message from the prover contract. It uses the current active set of keys to link to a new signing session and then emits an event to notify signers that a message is pending signature. -- **SubmitSignature**: Each signer will sign the message using their own private key and then submit the signature to the multisig contract. This process validates that the signer is a participant in the snapshot associated with the active key that was set for the multisig session. -- **GetSigningSession**: Query called by the prover contract to retrieve the current state of the session, collected signatures so far and the snapshot with participants information. The proof is generated by the prover contract if the multisig was completed. +- **StartSigningSession**: The multisig contract receives a binary message from the prover contract. It uses the current + active set of keys to link to a new signing session and then emits an event to notify signers that a message is + pending signature. +- **SubmitSignature**: Each signer will sign the message using their own private key and then submit the signature to + the multisig contract. This process validates that the signer is a participant in the snapshot associated with the + active key that was set for the multisig session. +- **GetSigningSession**: Query called by the prover contract to retrieve the current state of the session, collected + signatures so far and the snapshot with participants information. The proof is generated by the prover contract if the + multisig was completed.
@@ -52,7 +59,9 @@ Prover-->>-Relayer: returns data and proof ## Custom signature verification -If the multisig contract doesn't natively support the required signature verification, the `sig_verifier` parameter in `ExecuteMsg::StartSigningSession` can be set by the prover to specify a custom signature verification contract. The custom contract must implement the following interface defined in `packges/signature-verifier-api`: +If the multisig contract doesn't natively support the required signature verification, the `sig_verifier` parameter +in `ExecuteMsg::StartSigningSession` can be set by the prover to specify a custom signature verification contract. The +custom contract must implement the following interface defined in `packages/signature-verifier-api`: ```Rust pub enum QueryMsg { @@ -67,7 +76,9 @@ pub enum QueryMsg { } ``` -In case a custom verification contract is specified, when a signature is submitted, the multisig contract will call the `VerifySignature` query on the custom contract to verify the signature, which in turn should return `true` if the signature is valid or `false` otherwise. +In case a custom verification contract is specified, when a signature is submitted, the multisig contract will call +the `VerifySignature` query on the custom contract to verify the signature, which in turn should return `true` if the +signature is valid or `false` otherwise. ```mermaid sequenceDiagram @@ -134,7 +145,7 @@ pub enum Event { pub_keys: HashMap, msg: MsgToSign, }, - // Emitted when a participants submits a signature + // Emitted when a participant submits a signature SignatureSubmitted { session_id: Uint64, participant: Addr, diff --git a/doc/src/contracts/multisig_prover.md b/doc/src/contracts/multisig_prover.md index 771afdd56..d30aa41c7 100644 --- a/doc/src/contracts/multisig_prover.md +++ b/doc/src/contracts/multisig_prover.md @@ -1,6 +1,8 @@ # Multisig prover contract -The prover contract is responsible for transforming gateway messages into a command batch that is ready to be sent to the destination gateway. It calls the multisig contract to generate the signature proof and finally encodes both the data and proof so that relayers can take it and send it to the destination chain gateway. +The prover contract is responsible for transforming gateway messages into a command batch that is ready to be sent to +the destination gateway. It calls the multisig contract to generate the signature proof and finally encodes both the +data and proof so that relayers can take it and send it to the destination chain gateway. ## Interface @@ -111,19 +113,25 @@ Prover-->>-Relayer: returns GetProofResponse 1. Relayer asks Prover contract to construct proof providing a list of messages IDs 2. If no batch for the given messages was previously created, it queries the gateway for the messages to construct it -3. With the retrieved messages, the Prover contract transforms them into a batch of commands and generates the binary message that needs to be signed by the multisig. -4. If a newer `WorkerSet` was found, a `TransferOperatorship` command is added to the batch. The new `WorkerSet` is stored as the next `WorkerSet`. -5. If previous batch was found for the given messages IDs, the Prover retrieves it from storage instead of querying the gateway and build it again. +3. With the retrieved messages, the Prover contract transforms them into a batch of commands and generates the binary + message that needs to be signed by the multisig. +4. If a newer `WorkerSet` was found, a `TransferOperatorship` command is added to the batch. The new `WorkerSet` is + stored as the next `WorkerSet`. +5. If previous batch was found for the given messages IDs, the Prover retrieves it from storage instead of querying the + gateway and build it again. 6. The Multisig contract is called asking to sign the binary message 7. Multisig emits event `SigningStarted` indicating a new multisig session has started -8. Multisig triggers a reply in Prover returning the newly created session ID which is then stored with the batch for reference +8. Multisig triggers a reply in Prover returning the newly created session ID which is then stored with the batch for + reference 9. Prover contract emits event `ProofUnderConstruction` which includes the ID of the proof being constructed. 10. Signers submit their signatures until threshold is reached 11. Multisig emits event indicating the multisig session has been completed 12. Relayer queries Prover for the proof, using the proof ID 13. Prover queries Multisig for the multisig session, using the session ID 14. Multisig replies with the multisig state, the list of collected signatures so far and the snapshot of participants. -15. If the Multisig state is `Completed`, the Prover finalizes constructing the proof and returns the `GetProofResponse` struct which includes the proof itself and the data to be sent to the destination gateway. If the state is not completed, the Prover returns the `GetProofResponse` struct with the `status` field set to `Pending`. +15. If the Multisig state is `Completed`, the Prover finalizes constructing the proof and returns the `GetProofResponse` + struct which includes the proof itself and the data to be sent to the destination gateway. If the state is not + completed, the Prover returns the `GetProofResponse` struct with the `status` field set to `Pending`. ## Update and confirm WorkerSet graph @@ -185,15 +193,19 @@ Prover->>+Multisig: ExecuteMsg::RegisterWorkerSet 1. The Relayer calls Prover to update the `WorkerSet`. 2. The Prover calls Service Registry to get a `WorkerSet` -3. If a newer `WorkerSet` was found, the new `WorkerSet` is stored as the next `WorkerSet`. A `TransferOperatorship` command is added to the batch. +3. If a newer `WorkerSet` was found, the new `WorkerSet` is stored as the next `WorkerSet`. A `TransferOperatorship` + command is added to the batch. 4. The Multisig contract is called asking to sign the binary message 5. Signers submit their signatures until threshold is reached 6. Relayer queries Prover for the proof, using the proof ID -7. If the Multisig state is `Completed`, the Prover finalizes constructing the proof and returns the `GetProofResponse` struct which includes the proof itself and the data to be sent to the External Chain's gateway. If the state is not completed, the Prover returns the `GetProofResponse` struct with the `status` field set to `Pending`. +7. If the Multisig state is `Completed`, the Prover finalizes constructing the proof and returns the `GetProofResponse` + struct which includes the proof itself and the data to be sent to the External Chain's gateway. If the state is not + completed, the Prover returns the `GetProofResponse` struct with the `status` field set to `Pending`. 8. Relayer sends proof and data to the External Gateway. -9. The gateway on the External Gateway proccesses the commands in the data and emits event `OperatorshipTransferred`. +9. The gateway on the External Gateway processes the commands in the data and emits event `OperatorshipTransferred`. 10. The event `OperatorshipTransferred` picked up by the Relayer, the Relayer calls Voting Verifier to create a poll. -11. The Workers see the `PollStarted` event and lookup `OperatorshipTransferred`` event on the External Gateway and verify event matches worker set in poll. +11. The Workers see the `PollStarted` event and lookup `OperatorshipTransferred`` event on the External Gateway and + verify event matches worker set in poll. 12. The Workers then vote on whether the event matches the workers or not. 13. The Relayer calls the Voting Verifier to end the poll and emit `PollEnded` event. 14. Once the poll is completed, the Relayer calls the Prover to confirm if the `WorkerSet` was updated. diff --git a/doc/src/contracts/service_registry.md b/doc/src/contracts/service_registry.md index 5e3dad592..742ad242a 100644 --- a/doc/src/contracts/service_registry.md +++ b/doc/src/contracts/service_registry.md @@ -1,26 +1,22 @@ # Service Registry The service registry keeps track of the pool of workers that vote and sign for each chain. -The core functionalities, such as registering a new service, worker authorization and un-authorization can only be called -from a governance address. Worker bonding and unbonding, as well as registering support for specific chains, are called by the worker themselves. +The core functionalities, such as registering a new service, worker authorization and un-authorization can only be +called +from a governance address. Worker bonding and unbonding, as well as registering support for specific chains, are called +by the worker themselves. To become active and be eligible to participate in voting for a specific chain, each worker should first be authorized and bond enough stake, and then register support for that chain. Service registry is used by ampd, verifier, and multisig prover. -The term `service` refers to an upper-level entity that includes several -`chains`. The difference is in how they are related to each other, which is -hierarchical; a service is like an umbrella that regulates the activities of -several chains that fall under its purview. The service defines common -parameters, such as worker requirements, bonding details, and unbonding periods, which are applicable to all associated chains. +The term `service` refers to an upper-level entity that includes several +`chains`. The difference is in how they are related to each other, which is +hierarchical; a service is like an umbrella that regulates the activities of +several chains that fall under its purview. The service defines common +parameters, such as worker requirements, bonding details, and unbonding periods, which are applicable to all associated +chains. Thus, we use a single instance of service registry to organize and coordinate activities across all chains. - - - - - - - ## Interface ```Rust @@ -75,6 +71,7 @@ pub enum ExecuteMsg { ``` ## Service Registry graph + ```mermaid flowchart TD subgraph Axelar @@ -89,7 +86,6 @@ OC -- "Un/BondWorker" --> R OC -- "ClaimStake" --> R ``` - ## Service Registry sequence diagram ```mermaid @@ -111,10 +107,11 @@ Worker->>+Service Registry: Register Chain Support 1. The Governance registers a new service by providing the necessary parameters for the service. 2. Governance is also responsible for authorizing workers to join the service by sending an `Authorize Workers` message. -3. Workers bond to the service, providing stake, by sending a `Bond Worker` message with appropriate funds denominator. Note that authorizing and bonding can be done in any order. +3. Workers bond to the service, providing stake, by sending a `Bond Worker` message with appropriate funds included. + Note that authorizing and bonding can be done in any order. 4. Workers register support for specific chains within the service by specifying service name and chain names. - ### Notes + 1. For the process of signing, workers need to register their public key in advance to be able to participate, - the details of which are available in [`multisig documentation`](multisig.md). + the details of which are available in [`multisig documentation`](multisig.md). diff --git a/doc/src/contracts/voting_verifier.md b/doc/src/contracts/voting_verifier.md index 2c9200b97..469b652f1 100644 --- a/doc/src/contracts/voting_verifier.md +++ b/doc/src/contracts/voting_verifier.md @@ -1,17 +1,19 @@ # Voting Verifier -The voting verifier verifies batches of messages via RPC voting. Polls are created and votes are cast via a generic voting module, +The voting verifier verifies batches of messages via RPC voting. Polls are created and votes are cast via a generic +voting module, which the voting verifier uses. The generic voting module does not know the meaning of the Polls, and simply returns a Poll ID to the voting verifier. The voting verifier internally maps a Poll ID to the messages in the Poll, to be able to call back to the verifier and propagate the result back to the gateway. -There are two types of polls: messages polls and worker set polls. Messages polls are used to verify incoming messages, while worker set polls are used to verify that the external gateway has updated it's stored worker set. Worker set polls are a necessary component of the worker set update flow. See [`update and confirm WorkerSet sequence diagram`](multisig_prover.md) +There are two types of polls: messages polls and worker set polls. Messages polls are used to verify incoming messages, +while worker set polls are used to verify that the external gateway has updated it's stored worker set. Worker set polls +are a necessary component of the worker set update flow. +See [`update and confirm WorkerSet sequence diagram`](multisig_prover.md) for more details. - - -## Verfier graph +## Verifier graph ```mermaid flowchart TD @@ -32,11 +34,8 @@ Vr--"MessagesVerified([M,M',M''])"-->V ``` - - ## Message Verification Sequence Diagram - ```mermaid sequenceDiagram participant Verifier diff --git a/doc/src/contributing/documentation.md b/doc/src/contributing/documentation.md index 48a4590ac..5c54da680 100644 --- a/doc/src/contributing/documentation.md +++ b/doc/src/contributing/documentation.md @@ -1,10 +1,13 @@ # Contributing to documentation -Amplifier documentation uses the tool [mdbook](https://rust-lang.github.io/mdBook/) to generate this book from `.md` files. Documentation files can be found under the `doc` directory in the [project root](https://github.com/axelarnetwork/axelar-amplifier) +Amplifier documentation uses the tool [mdbook](https://rust-lang.github.io/mdBook/) to generate this book from `.md` +files. Documentation files can be found under the `doc` directory in +the [project root](https://github.com/axelarnetwork/axelar-amplifier) ## Reference code snippets with ANCHOR -Use `ANCHOR: ` and `ANCHOR_END: ` to label code snippets in rust files. Make sure to not use triple slashes `///` for anchors in the code snippets or they will be interpreted as part of the struct documentation +Use `ANCHOR: ` and `ANCHOR_END: ` to label code snippets in rust files. Make sure to not use triple +slashes `///` for anchors in the code snippets, or they will be interpreted as part of the struct documentation ```rust // ANCHOR: events @@ -22,7 +25,8 @@ Then reference the code snippet in the book with `\{{#include :M # Event Flow In the below diagram, the blue box represents the protocol. All messages flowing into, out of or within the blue box -are part of the protocol. All components within the blue box are on chain. All components outside of the blue box are off chain. +are part of the protocol. All components within the blue box are on chain. All components outside the blue box are off +chain. ## Voting Contract Flows @@ -147,26 +150,49 @@ query the service registry for an updated snapshot. ### Connection Router -[`connection-router`](./contracts/connection_router.md) is the way messages are passed between different gateways. The router has methods for registering new chains and gateways, updating the address of the registered gateway, and freezing chains (preventing message flow). These methods are only callable by the router admin. Messages are passed to the router from registered gateways, and the router passes those messages to the appropriate gateway based on each message's destination chain. +[`connection-router`](contracts/connection_router.md) is the way messages are passed between different gateways. The +router has methods for registering new chains and gateways, updating the address of the registered gateway, and freezing +chains (preventing message flow). These methods are only callable by the router admin. Messages are passed to the router +from registered gateways, and the router passes those messages to the appropriate gateway based on each message's +destination chain. ### Gateway -[`gateway`](./contracts/gateway.md) is the entry point for incoming messages. Each gateway corresponds to a single connected external chain. Messages are passed to the gateway in a permissionless manner. For each message passed to the gateway, the gateway checks whether the message has been verified by calling into a linked verifier contract. For each verified message, the gateway passes the message to the router. +[`gateway`](contracts/gateway.md) is the entry point for incoming messages. Each gateway corresponds to a single +connected external chain. Messages are passed to the gateway in a permissionless manner. For each message passed to the +gateway, the gateway checks whether the message has been verified by calling into a linked verifier contract. For each +verified message, the gateway passes the message to the router. -The gateway also accepts messages from the router. These are messages sent from other chains. The gateway trusts that any message being sent from the router was originally sent from the correct source gateway, and verified appropriately by the source verifier. The gateway stores these received messages, which can be later added to a proof, to be relayed to an external chain. +The gateway also accepts messages from the router. These are messages sent from other chains. The gateway trusts that +any message being sent from the router was originally sent from the correct source gateway, and verified appropriately +by the source verifier. The gateway stores these received messages, which can be later added to a proof, to be relayed +to an external chain. ### Verifier -The verifier contracts are responsible for verifying whether a given message or batch of messages has occurred on a connected external chain. The verifier can take many different forms, such as a [`voting-verifier`](./contracts/voting_verifier.md) that conducts stake weighted polls for batches of messages, a light client that accepts block headers and merkle tree proofs, a zk proof verifier, etc. The verifier can also be an [`aggregate-verifier`](./contracts/aggregate_verifier.md), that is linked to 1 or more other verifiers, and defines a security policy such as 2 out of 3 linked verification methods need to report a message as verified. +The verifier contracts are responsible for verifying whether a given message or batch of messages has occurred on a +connected external chain. The verifier can take many different forms, such as +a [`voting-verifier`](contracts/voting_verifier.md) that conducts stake weighted polls for batches of messages, a light +client that accepts block headers and merkle tree proofs, a zk proof verifier, etc. The verifier can also be +an [`aggregate-verifier`](contracts/aggregate_verifier.md), that is linked to 1 or more other verifiers, and defines a +security policy such as 2 out of 3 linked verification methods need to report a message as verified. ### Prover -The prover contract is responsible for constructing proofs of routed messages, to be passed to external chains. The most common example of this is the [`multisig-prover`](./contracts/multisig_prover.md) that constructs signed batches of routed messages, which are then relayed (permissionlessly) to an external chain. In this example, the prover fetches the messages from the gateway, and interacts with the multisig contract to conduct the signing. +The prover contract is responsible for constructing proofs of routed messages, to be passed to external chains. The most +common example of this is the [`multisig-prover`](contracts/multisig_prover.md) that constructs signed batches of routed +messages, which are then relayed (permissionlessly) to an external chain. In this example, the prover fetches the +messages from the gateway, and interacts with the multisig contract to conduct the signing. ### Multisig Contract -[`multisig`](./contracts/multisig.md) is responsible for signing arbitrary blobs of data. Contracts register with the multisig contract to generate a key id, and then use that key id to initiate signing sessions. Off chain workers associated with the key id sign messages when new signing sessions are created. +[`multisig`](contracts/multisig.md) is responsible for signing arbitrary blobs of data. Contracts register with the +multisig contract to generate a key id, and then use that key id to initiate signing sessions. Off chain workers +associated with the key id sign messages when new signing sessions are created. ### Service Registry -[`service-registry`](./contracts/service_registry.md) is responsible for tracking workers associated with specific services. Two example services are voting and sigining. Workers must be authorized to join a service via governance vote. Once authorized, workers must also bond a sufficient amount of stake before becoming active in the service. Services query the service registry to create weighted snapshots of the active worker set. +[`service-registry`](contracts/service_registry.md) is responsible for tracking workers associated with specific +services. Two example services are voting and signing. Workers must be authorized to join a service via governance +vote. Once authorized, workers must also bond a sufficient amount of stake before becoming active in the service. +Services query the service registry to create weighted snapshots of the active worker set. diff --git a/integration-tests/Cargo.toml b/integration-tests/Cargo.toml index b5c7706db..0cf916950 100644 --- a/integration-tests/Cargo.toml +++ b/integration-tests/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Amplifier Integration Tests" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/integration-tests/tests/test_utils/mod.rs b/integration-tests/tests/test_utils/mod.rs index 207c3ee5c..7176f9ef6 100644 --- a/integration-tests/tests/test_utils/mod.rs +++ b/integration-tests/tests/test_utils/mod.rs @@ -932,7 +932,7 @@ pub fn instantiate_multisig_prover( contract_addr.unwrap() } -// Creates an instance of Axelar Amplifier with an initial workerset registered, and returns the instance, the chains, the workers, and the minimum worker bond. +// Creates an instance of Axelar Amplifier with an initial worker set registered, and returns the instance, the chains, the workers, and the minimum worker bond. pub fn setup_test_case() -> (Protocol, Chain, Chain, Vec, Uint128) { let mut protocol = setup_protocol("validators".to_string().try_into().unwrap()); let chains = vec![ diff --git a/packages/axelar-wasm-std/Cargo.toml b/packages/axelar-wasm-std/Cargo.toml index f12b6a2fa..c0a128cfb 100644 --- a/packages/axelar-wasm-std/Cargo.toml +++ b/packages/axelar-wasm-std/Cargo.toml @@ -6,9 +6,9 @@ edition = "2021" description = "Axelar cosmwasm standard library crate" exclude = [ - # Those files are rust-optimizer artifacts. You might want to commit them for convenience but they should not be part of the source code publication. - "contract.wasm", - "hash.txt", + # Those files are rust-optimizer artifacts. You might want to commit them for convenience, but they should not be part of the source code publication. + "contract.wasm", + "hash.txt", ] # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html diff --git a/packages/axelar-wasm-std/src/voting.rs b/packages/axelar-wasm-std/src/voting.rs index d9f5e9ef7..b7b49fb29 100644 --- a/packages/axelar-wasm-std/src/voting.rs +++ b/packages/axelar-wasm-std/src/voting.rs @@ -11,7 +11,7 @@ to the list of messages in the poll. Participants vote on the validity of the transactions via cast_vote. Once everyone has voted, the contract calls tally_results to get the results of the poll. The contract then processes the results and takes appropriate action for each transaction, depending - on whether or not the transaction was successfully verified. + on whether the transaction was successfully verified. */ use std::array::TryFromSliceError; use std::collections::BTreeMap; @@ -219,7 +219,7 @@ pub struct WeightedPoll { impl WeightedPoll { pub fn new(poll_id: PollId, snapshot: Snapshot, expiry: u64, poll_size: usize) -> Self { - // initialize the map with all possible voters so it always have the same size and therefore + // initialize the map with all possible voters, so it always have the same size and therefore // all voters will use roughly the same amount of gas when casting a vote. let participation = snapshot .participants diff --git a/packages/connection-router-api/src/msg.rs b/packages/connection-router-api/src/msg.rs index bcccbbb68..6ea3259b1 100644 --- a/packages/connection-router-api/src/msg.rs +++ b/packages/connection-router-api/src/msg.rs @@ -6,7 +6,7 @@ use crate::primitives::*; pub enum ExecuteMsg { /* * Governance Methods - * All of the below messages should only be called by governance + * All the below messages should only be called by governance */ // Registers a new chain with the router RegisterChain { @@ -21,7 +21,7 @@ pub enum ExecuteMsg { /* * Router Admin Methods - * All of the below messages should only be called by the router admin + * All the below messages should only be called by the router admin */ // Freezes a chain, in the specified direction. FreezeChain { diff --git a/packages/connection-router-api/src/primitives.rs b/packages/connection-router-api/src/primitives.rs index ffa645d43..e501d2653 100644 --- a/packages/connection-router-api/src/primitives.rs +++ b/packages/connection-router-api/src/primitives.rs @@ -25,7 +25,7 @@ pub struct Message { pub destination_chain: ChainName, pub destination_address: Address, /// for better user experience, the payload hash gets encoded into hex at the edges (input/output), - /// but internally, we treat it as raw bytes to enforce it's format. + /// but internally, we treat it as raw bytes to enforce its format. #[serde(with = "axelar_wasm_std::hex")] #[schemars(with = "String")] // necessary attribute in conjunction with #[serde(with ...)] pub payload_hash: [u8; 32], diff --git a/packages/report/src/loggable.rs b/packages/report/src/loggable.rs index b7270feec..35578938d 100644 --- a/packages/report/src/loggable.rs +++ b/packages/report/src/loggable.rs @@ -65,7 +65,7 @@ impl From<&Report> for LoggableError { // context of error i-1 // ... // - // so a context frame denotes the end of one error and we can break to create the next + // so a context frame denotes the end of one error, and we can break to create the next match FrameType::from(f) { FrameType::Context(c) => { error.msg = c.to_string();