Using Rust is an option too

Some initial thoughts after starting the work on this:

• We have some guidelines that were shared with us with regards to key management (Key Management Scripts Guidelines) that need to be followed.
  • Among other things, it recommends a flow for offline transaction signing, which we should also support.
    • It's doable, I'll make sure we have support for that on program initializations and program upgrades. Solana doesn't support offline signing for the initial deployment, therefore, this flow needs to happen online even for Mainnet.
    • We need to use Solana's durable nonces.
    • We need to package the binaries necessary for offline signing (full and partial signing).
• Just copying what we have is not enough, although it's a starting point.
• For ITS, besides initialization, we need to provide a script/function/command to add and remove trusted chains. We need to check if similar functionality is required for other programs.
• For some flows (initial deployment and upgrades, for instance) we should use the Solana CLI directly. We might be able to leverage it for the offline signing, I'm looking into it.

You can reference the contract deployments repo to see the various scripts for contract functionality.

For ITS, since Solana will connect to the ITS hub, it would be useful to look at other amplifier chains like Sui and Stellar.

Take a look at the Gateway, Gas Service, Operators and GMP scripts as well.

I wanted to write an update here about this:

For some flows (initial deployment and upgrades, for instance) we should use the Solana CLI directly. We might be able to leverage it for the offline signing, I'm looking into it.

The offline flow is not supported by the CLI, thus, I had to start working on a tool to support the offline signing flow. I have it in a stage that works and therefore I will start working on implementing the functionality for interacting with each contract on Monday.

What I already have in place:

• General code to send transactions.
  • Implemented only gateway initialization so far.
• Code to generate a transaction and save it, unsigned, to the filesystem.
  • Can only generate gateway initialization so far.
• Code to sign the transaction using a keypair or hardware wallet.
  • Can be signed by multiple parties, one at a time, each signature is saved to a file.
  • ⚠️ I don't have a hardware wallet, not sure how to test it, thus also not sure if what I have really works atm.
• Code to combine the signatures with the unsigned transaction and output a signed transaction to the filesystem.
• Code to load a transaction from the file system and broadcast it.

What is still pending:

• I have to go through what is implemented for the other chains and implement that as well. From what I could see initially, we have to add client scripts/CLI for most of (if not all) our programs interfaces (instructions). Some things I know I'll need to implement for sure are:
  • Initialization of all of our programs.
  • Operator related instructions.
• The user interface is fairly difficult to use at the moment due to the amount of arguments required.
  • I likely need to read some of them from the JSON file with the details of the Axelar deployments (e.g.: devnet-amplifier.json, testnet.json etc).
• I think we might need to update the JSON file as well with the details of the deployed Solana programs. In our case, this should be done after the initialization command is ran.

I'm having issues with offline signing. @AttissNgo is going to confirm, but according to the Key Management Scripts Guidelines document, this is only a requirement for mainnet. Therefore, I'll skip fixing these issues now and will focus on implementing the required interface for the programs instead, such that we can deploy on testnet before offline signing works.

Edit: Just to clarify, the issue I have is related to packaging and not signing itself. I cannot compile the tool using vendored dependencies due to errors that happen on the evm-gateway (MultisigProver dependency) on invocations of the abigen macro. We need the MultisigProver as dependency because we need to query it when initializing the gateway.

@frenzox - I can confirm that hardware wallet signing is not a blocker for testnet.

Opened a draft PR in case anyone wants to follow the progress: eigerco/axelar-contract-deployments#1

This is what I have so far:

• ITS: All native instructions (There's quite a few, so I'm not listing)
• Governance: All native Governance instructions (Init, ExecuteProposal and ExecuteOperatorProposal)
• Gateway: Init, CallContract and TransferOperatorship
• GasService: Init
• Updating the appropriate chain info json with the data of the initialization
• A command to generate and serialize transactions to the filesystem, so they can be signed offline
• A command to sign the transactions offline
• A command to load and combine transaction signatures and unsigned transaction into a signed transaction and save it to the filesystem
• A command to load a signed transaction from the filesystem and broadcast it

Here's what I think is still missing:

• Gateway:
  • We're missing instructions related to the RotateSigners and ApproveMessages flows.
    • We need to provide a way to run these flows in the local test env by using the local wallet to build the proof (the initialization has to be done with the local wallet in the signer set).
    • We need to also provide a way to run it by accepting a proof id from the cli, in which case we need to query the multisig prover for the proof
    • In both cases, we need to do the whole gateway flow: initialize_payload_verification_session, verify_signature, etc.
  • We need to also provide a way to upload the message payload and execute it on the destination contract passing the appropriate accounts
• Governance:
  • Still need to implement an interface to create the ExecuteProposalData, serialize and save it to filesystem, such that we can use the evm/governance.js to create a proposal.
• GasService: The other instructions besides Init .
• Still need to actually test what I have done AND write documents explaining how to use the tool.
• Fix packaging for offline signing.

@AttissNgo Is there a minimum set of features for testnet? Perhaps we could start testing by initializing the contracts and running some ITS flows.

Is there a minimum set of features for testnet?

@frenzox we should be able to send and receive GMP messages and execute all ITS functionality on the testnet connection.

Gateway: We're missing instructions related to the RotateSigners and ApproveMessages flows

Both of these need to be in place for testnet - please let me know if you're having any issues with this.

Governance: Still need to implement an interface to create the ExecuteProposalData, serialize and save it to filesystem, such that we can use the evm/governance.js to create a proposal.

This does not block the initial deployment. For now "governance" can be a single account.

GasService: The other instructions besides Init

We want to be able to test the gas service on testnet at some point, but the missing scripts do not block the initial deployment.

Here's an update on the progress:

• Implemented approve (ApproveMessage) command
• Implemented rotate (RotateSigners) command
  • Can rotate with local signers or query the multisig-prover for a new signer set
• Implemented the submit-proof, where we query the multisig-prover for a proof using the multisig-session-id and send it to the gateway.
• Implemented the execute function, which will upload the message payload to an on-chain account and call the destination program
• Added a misc command to create a Solana AxelarExecutable payload given the raw payload and the Solana accounts expected by the destination program (not required for ITS, but might be useful later).

I believe I can now create written instructions on how to deploy the contracts and use the CLI to interface with them, just like it was done for the other chains.

Created another issue to address the missing parts required before going to mainnet: #94

I wrote a README.md today for the solana-axelar-cli and, while writing it, I changed the code a bit to improve the ux. Tomorrow I'll update the code in order to account for the changes after the removal of the gateway_root_pda from most of our programs and then I'll work on filling the release template so we can open a PR on the axelar-contract-deployments repo.

I've been working on addressing the comments on the deployment scripts PR. Some of the comments are simple to address, some require code changes, namely:

• ✅ Done: Added a misc command for the user to list events and their ids from a transaction, given the transaction signature. This is required in order to manually route the messages through the Axelar network.
• ✅ Done: Updated CLI code to better handle the networks - We shouldn't support solana devnet as on Axelar we can only use testnet and mainnet according to Axelar comments. I actually added a comment to the PR to discuss this further, we should perhaps use solana devnet instead of testnet.
• 🏗️ In progress: Verify deployed contract - I'm going to open a PR soon to update the repo structure a bit, it needs to be flattened: what's within solana-axelar/solana needs to be in the root, solana-axelar (this is a requirement from the solana-verify CLI tool). I could move just the Cargo.toml and lock files to the root, but that messes a bit the xtask stuff and makes things more difficult. I think it's actually good to have it flattened. Let me know your thoughts.
• ❌ Blocked: CallContract from the CLI - I have this implemented in the CLI, but our gateway currently doesn't support. I can quickly open a PR to fix this, but I'll wait for @eloylp to check with Ackee. I personally think we could just go forward with it as the executable flag cannot be mutated. It's set as a final step during program deployment only.
• ⏸ To do: Add a misc command to the CLI to allow for the user to get the IncommingMessage account data. We mainly need to provide a way for the user to query the message status (approved or not).
• ⏸ To do: Process comments on the Solana GMP cosmwasm contracts release doc.
• 🚧 I'm also updating the docs directly to address comments where immediately possible and updating command instructions according to changes I'm making to the CLI.

Blocked: CallContract from the CLI - I have this implemented in the CLI, but our gateway currently doesn't support. I can quickly open a PR to fix this, but I'll wait for @eloylp to check with Ackee. I personally think we could just go forward with it as the executable flag cannot be mutated. It's set as a final step during program deployment only.

Let's just go for it and we will share once the PR is up 👍 - so we can better explain the change to them.