Axelar aleo review #60

anstylian · 2025-02-12T08:56:26Z

Description

Todos

Unit tests
Manual tests
Documentation
Connect epics/issues

Convention Checklist

Each contract should have a client mod for others to interact with it.
Derive macros
- EnsurePermissions: Contract permission control
- IntoContractError: Conversion from custom contract errors to axelar_wasm_std::error::ContractError
- IntoEvent: Event serialization
- migrate_from_version: Contract version management in the migrate function
The state mod and msg mod should use separate data structures so that internal state changes do not break the contract interface. Check out the interchain-token-service for reference.
- msg.rs should never use any type from the state.rs
- Shared types must be defined in a separate exported mod. If those types have already been defined somewhere else, then they should get re-exported in the exported mod

Steps to Test

Expected Behaviour

Notes

anstylian · 2025-02-12T08:57:27Z

ampd/Cargo.toml

+aleo-gateway = { workspace = true }
+snarkvm-cosmwasm = { workspace = true }
+# aleo-parser = { path = "../../axelar-aleo/crates/aleo-parser" }
+aleo-parser = { git = "ssh://[email protected]/eigerco/axelar-aleo.git", branch = "aleo-helper-libs" }


@tilacog how to handle this? including a crate from a private repo

ping @tilacog

We can either try to publish just the aleo-parser to crates.io, if that's doable; or create a new public repo for it.

I prefer the first option because it's easier to maintain. That crate is very self-contained and don't expose our contract logic, so it should be safe to do so.

We might need to check that with @asmie first.

@tilacog the contract log is not encrypted when your contract is deployed on testnet, so there is nothing to protect when it comes to contract logic

@asmie mentioned we can give access for this repo to eigergo/axelar-aleo using GitHub tokens/secrets.

This seems like the cleanest approach to me, because wouldn’t have to deal with new repositories or crate publishing.

packages/aleo-gateway/src/string_encoder.rs

anstylian · 2025-02-12T15:17:59Z

contracts/multisig/Cargo.toml

@@ -61,12 +62,16 @@ sha3 = { workspace = true }
 signature-verifier-api = { workspace = true }
 thiserror = { workspace = true }

+rand_chacha = "0.3"


check this, or document

anstylian · 2025-02-13T18:04:55Z

packages/axelar-wasm-addresses/src/lib.rs

+}
+
+#[cfg(test)]
+mod tests {


Add a test for Aleo address

ampd/src/handlers/aleo_verify_msg.rs

vaporif · 2025-02-20T18:22:14Z

contracts/multisig-prover/src/contract/execute.rs


-            save_next_verifier_set(deps.storage, &new_verifier_set)?;
+    // let cur_verifier_set = CURRENT_VERIFIER_SET


do we need old code? it's in git anyway

Good question: I didn't remove it to be obvious that signer rotation is not implemented. Also the commented out code is the reason why I set some tests as ignore

@anstylian Yeah, I suspected it too, but better to have a simple short explanation why it's commented out

I will remove it

contracts/multisig/src/contract.rs

vaporif · 2025-02-20T18:23:47Z

contracts/voting-verifier/src/contract.rs

@@ -425,6 +453,12 @@ mod test {
                address_format: AddressFormat::Sui,
                should_fail: true,
            },
+            TestCase {
+                source_gateway_address:
+                    "aleo1q3t7cjwk9ncxcdxfm8r5ax83mzudd923gffncv5egfjyevfevuyscvcvz".to_string(),


ok to hardcode?

Thanks for spotting it. It's ok to be hardcoded here because it is the unit test setup. It is the same above for other chains.

vaporif · 2025-02-20T18:24:32Z

integration-tests/tests/bond_unbond.rs

@@ -34,6 +34,7 @@ fn verifier_should_not_unbond_while_in_active_set() {
 }

 #[test]
+#[ignore]
