Code Monkey home page Code Monkey logo

axelar-cgp-solidity's Introduction

Axelar cross-chain gateway protocol solidity implementation

Protocol overview

Axelar is a decentralized interoperability network connecting all blockchains, assets and apps through a universal set of protocols and APIs. It is built on top of the Cosmos SDK. Users/Applications can use Axelar network to send tokens between any Cosmos and EVM chains. They can also send arbitrary messages between EVM chains.

Axelar network's decentralized validators confirm events emitted on EVM chains (such as deposit confirmation and message send), and sign off on commands submitted (by automated services) to the gateway smart contracts (such as minting token, and approving message on the destination).

See this doc for more design info.

Build

We recommend using the latest Node.js LTS version.

npm ci

npm run build

npm run test

Pre-compiled bytecodes can be found under Releases. Furthermore, pre-compiled bytecodes and ABI are shipped in the npm package and can be imported via:

npm i @axelar-network/axelar-cgp-solidity
const IAxelarGateway = require('@axelar-network/axelar-cgp-solidity/artifacts/interfaces/IAxelarGateway.json');

const AxelarGateway = require('@axelar-network/axelar-cgp-solidity/artifacts/contracts/AxelarGateway.sol/AxelarGateway.json');

Deploying contracts

See the Axelar contract deployments repository for relevant deployment/upgrade scripts:

  1. Gateway deployment
  2. Gateway upgrade
  3. Gas service and deposit service deployment and upgrades

Live network testing

  1. Check if the contract deployments repository supports the chain you will be using. Supported chains can be found here. If the chain is not already supported, proceed to steps 2-4, otherwise you may skip to step 5.
  2. Navigate to the contract deployments repo here and clone the repository locally.
  3. Within the contract deployments repo, edit the environment specific file inside the axelar-chains-config/info folder to add the chain you'll be testing. The following values need to be provided:
{
    "chains": {
        "example": {
            "name": "Example",
            "axelarId": "example",
            "chainId": 123,
            "rpc": "PROVIDER_RPC",
            "tokenSymbol": "EXM",
            "gasOptions": {
                "gasLimit": 8000000
            },
            "confirmations": 1
        }
    }
}

gasLimit override will skip auto gas estimation (which might be unreliable on certain chains for certain txs). confirmations indicates the number of block confirmations to wait for. axelarId is the unique id used to reference the chain on Axelar.

  1. Return to the axelar-cgp-solidity repository. Once there, in the root directory of this repository, navigate to the hardhat.config.js file and modify the chains import line as shown below:
const chains = require(`/path/to/axelar-contract-deployments/axelar-chains-config/info/${env}.json`);
  1. Create a keys.json file in this repo that contains the private keys for your accounts that will be used for testing. For some tests, such as the Axelar gateway tests, you may need to provide at least two private keys (you can refer the test to find the number of accounts needed). At this point the keys.json file should resemble the example file below (chains can be left empty):
{
    "chains": {},
    "accounts": ["PRIVATE_KEY1", "PRIVATE_KEY2"]
}
  1. Ensure that your accounts corresponding to the private keys provided have sufficient gas tokens on the chain.
  2. Run
npm ci

npx hardhat test --network example
  1. To run specific tests you may modify the test scripts by adding .only to describe and/or it blocks as shown below or grep the specific test names:
describe.only();
it.only();
npx hardhat test --network example --grep 'AxelarGateway'

Debugging Steps

  • Explicitly pass getGasOptions() using utils.js file for some spceific transactions. See the code below for example
await sourceChainGateway
    .execute(
        await getSignedWeightedExecuteInput(await getTokenDeployData(false), [operatorWallet], [1], 1, [operatorWallet]),
        getGasOptions()
    )
    .then((tx) => tx.wait(network.config.confirmations));
  • Using the most up to date and fast rpc can help in tests execution runtime. Make sure the rate limit for the rpc is not exceeded.

  • Make sure that the account being used to broadcast transactions has enough native balance. The maximum gasLimit for a chain should be fetched from an explorer and set it in config file. You may also need to update the confirmations required for a transaction to be successfully included in a block in the config here depending on the network.

  • Note that certain tests can require upto 3 accounts.

  • Transactions can fail if previous transactions are not mined and picked up by the provide, therefore wait for a transaction to be mined after broadcasting. See the code below for example

await testToken.mint(userWallet.address, 1e9).then((tx) => tx.wait(network.config.confirmations));

// Or

const txExecute = await interchainGovernance.execute(commandIdGateway, governanceChain, governanceAddress, payload, getGasOptions());
const receiptExecute = await txExecute.wait(network.config.confirmations);
  • The changeEtherBalance check expects one tx in a block so change in balances might need to be tested explicitly for unit tests using changeEtherBalance.

Example flows

See Axelar examples for concrete examples.

Token transfer

  1. Setup: A wrapped version of Token A is deployed (AxelarGateway.deployToken()) on each non-native EVM chain as an ERC-20 token (BurnableMintableCappedERC20.sol).
  2. Given the destination chain and address, Axelar network generates a deposit address (the address where DepositHandler.sol is deployed, BurnableMintableCappedERC20.depositAddress()) on source EVM chain.
  3. User sends their token A at that address, and the deposit contract locks the token at the gateway (or burns them for wrapped tokens).
  4. Axelar network validators confirm the deposit Transfer event using their RPC nodes for the source chain (using majority voting).
  5. Axelar network prepares a mint command, and validators sign off on it.
  6. Signed command is now submitted (via any external relayer) to the gateway contract on destination chain AxelarGateway.execute().
  7. Gateway contract authenticates the command, and mint's the specified amount of the wrapped Token A to the destination address.

Token transfer via AxelarDepositService

  1. User wants to send wrapped token like WETH from chain A back to the chain B and to be received in native currency like Ether.
  2. The un-wrap deposit address is generated by calling AxelarDepositService.addressForNativeUnwrap().
  3. The token transfer deposit address for specific transfer is generated by calling AxelarDepositService.addressForTokenDeposit() with using the un-wrap address as a destination.
  4. User sends the wrapped token to that address on the source chain A.
  5. Axelar microservice detects the token transfer to that address and calls AxelarDepositService.sendTokenDeposit().
  6. AxelarDepositService deploys DepositReceiver to that generated address which will call AxelarGateway.sendToken().
  7. Axelar network prepares a mint command, and it gets executed on the destination chain gateway.
  8. Wrapped token gets minted to the un-wrap address on the destination chain B.
  9. Axelar microservice detects the token transfer to the un-wrap address and calls AxelarDepositService.nativeUnwrap().
  10. AxelarDepositService deploys DepositReceiver which will call IWETH9.withdraw() and transfer native currency to the recipient address.

Cross-chain smart contract call

  1. Setup:
    1. Destination contract implements the IAxelarExecutable.sol interface to receive the message.
    2. If sending a token, source contract needs to call ERC20.approve() beforehand to allow the gateway contract to transfer the specified amount on behalf of the sender/source contract.
  2. Smart contract on source chain calls AxelarGateway.callContractWithToken() with the destination chain/address, payload and token.
  3. An external service stores payload in a regular database, keyed by the hash(payload), that anyone can query by.
  4. Similar to above, Axelar validators confirm the ContractCallWithToken event.
  5. Axelar network prepares an AxelarGateway.approveContractCallWithMint() command, signed by the validators.
  6. This is submitted to the gateway contract on the destination chain, which records the approval of the payload hash and emits the event ContractCallApprovedWithMint.
  7. Any external relayer service listens to this event on the gateway contract, and calls the IAxelarExecutable.executeWithToken() on the destination contract, with the payload and other data as params.
  8. executeWithToken of the destination contract verifies that the contract call was indeed approved by calling AxelarGateway.validateContractCallAndMint() on the gateway contract.
  9. As part of this, the gateway contract records that the destination address has validated the approval, to not allow a replay.
  10. The destination contract uses the payload for its own application.

References

Network resources: https://docs.axelar.dev/resources

Deployed contracts: https://docs.axelar.dev/resources/mainnet

General Message Passing Usage: https://docs.axelar.dev/dev/gmp

Example cross-chain token swap app: https://app.squidrouter.com

EVM module of the Axelar network that prepares commands for the gateway: https://github.com/axelarnetwork/axelar-core/blob/main/x/evm/keeper/msg_server.go

axelar-cgp-solidity's People

Contributors

axelar-cicd-bot avatar blockchainguyy avatar canhtrinh avatar cgorenflo avatar deanamiel avatar deluca-mike avatar fahimahmedx avatar fish-sammy avatar foivos avatar jack0son avatar jcs47 avatar kalidax avatar milapsheth avatar npty avatar omahs avatar re1ro avatar sdaveas avatar talalashraf avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

axelar-cgp-solidity's Issues

Create methods to view admins, owners and operators

Currently the only way to read admins, owners or operators for given epoch (and their threshold values) is through reading specific eternal storage slots.

We should create methods to easily access that data. There are several ways to do this:

  1. Adding according methods to the Gateway itself (this will increate the contract size that is already close to the limit)
  2. Adding the methods to our JavaScript library so the according storage slots can be computed locally and then read from the contract
  3. Accessing that data from the Gateway event history. For each operator/ownership transfer we emit events containing required information
    event OperatorshipTransferred(
        address[] preOperators,
        uint256 prevThreshold,
        address[] newOperators,
        uint256 newThreshold
    );

The gas saving approach would be reading the data from events and JS library and eventually stop saving the list of operators to the gateway storage. Event history can be considered as such storage that is also costly. End simplifying the event structure by dropping preOperators could save gas even more as this data can be found in the previous event:

    event OperatorshipTransferred(
        uint256 newEpoch,
        address[] newOperators,
        uint256 newThreshold
    );

Gateway implementation and proxy deployment script

Since we've separated the gateway proxy and implementation deployments, core no longer can provide the exact bytecode anymore. We need a script to facilitate the deployments. Ideally, the script would be able to do the followings.

  1. Deploy gateway implementation to a configured evm chain
  2. Query a configured Axelar RPC node for that evm chain's master/secondary/external keys
  3. Deploy gateway proxy with information from step 1 and 2
  4. Output the deployed gateway proxy's address

Store a commitment to the list of owners/operators

Since we don't use the list of owners/operators except for authentication, store a hash commitment to the list instead to save on storage read/writes. execute will now take the whole list of owners/operators and verify the commitment.
A separate uint8 array can be provided to indicate the index of the validator's signature. Alternatively, a flag can be used to indicate whether an operator in the list should be included or not. The corresponding element in the signatures array can be set to all 0s as another way to indicate this.

Enforce signatures to be ordered by signer address to optimize address duplication check

The check to ensure that there are no duplicate signers present is an O(n^2) algorithm. With 50-100 signers, this might be expensive in terms of gas fees. One potential optimization is to enforce that the signatures submitted are ordered by the signer addresses. This makes checking for duplicates efficient. But this requires coordination with axelar-core or micro-services to sort the signatures beforehand. It's preferable to do this in axelar-core so that anyone can submit the signed data to the contract as-is without having to modify it.

Generate flattened contracts in a github action

To verify the contracts on the explorers, it would be convenient to generate the flattened contract representations as part of the release build.

To flatten the contracts, you can do:

npm i @poanet/solidity-flattener

For every contract that needs to be verified (Proxy, Multisig, Burnable...ERC20, DepositHandler), do

./node_modules/.bin/poa-solidity-flattener src/BurnableMintableCappedERC20.sol
npm run prettier --write 'out/*.sol'
mv out flattened

Error when trying upgradeable contracts

Is there any plan to create upgradeable versions of Axelar contracts?

I'm creating an upgradeable token contract and want it to be Axelar-enabled, so e.g. would inherit IAxelarExecutable. All inherited contracts that have a constructor need to be modified to an upgradeable version (e.g. change constructor to initializer).

It would then allow us to upgrade the token contract in future in case we ever need or want to (e.g. if vulnerabilities are found), whilst maintaining the publicly known address of the token, so upgrades would be seamless to token holders.

See: https://docs.openzeppelin.com/learn/upgrading-smart-contracts

Implement ERC20 smart contract for wrapped BTC minting and burning

The token contract should extend OpenZeppelin's implementation, and support the transaction verification functionality outlined in the asset transfer flow spec.

SC (Ethereum Smart Contract)

  • Upon creation, the contract holds 21M of some new ERC20 token, which represents the wrapped Bitcoin.
  • State variables:
    • hash
    • counter
    • master_key
  • State transition rules. Upon receiving:
    • (NEWHASH, X, counter1, counter2) signed by master_key: if hash==empty and counter==counter1, then set hash=X and counter=counter2
    • (NEWKEY, key) signed by master_key: set master_key=key
    • (TRANSACTION, tx, h) signed by anyone: if hash==H(tx||h), then process tx and set hash=h
    • (TRANSACTION, tx1, h1, tx2, h2,....., txN, hN): Treat it like applying (TRANSACTION, tx1, h1),...., (TRANSACTION, txN, hN) in order

Implement batchExecute in AxelarGateway

To implement batchExecute, the data should be decoded as following

(
    uint256 chainId,
    bytes32[] memory commandIds,
    string[] memory commands,
    bytes[] memory params
) = abi.decode(data, (uint256, bytes32[], string[], bytes[]));

Nest array isn't supported by pragma abicoder v1 but pragma abicoder v2. In order to properly use it, we should upgrade our contracts to start using solidity compiler version 0.8.*. Note that openzeppelin hasn't upgraded yet, so we either have to wait for its upgrade, or copy/paste his code into the repository.

I'm not clear how good abicoder v2 support out there is for languages such as Go and Javascript. Some investigation prior to the upgrade is recommended.

https://docs.soliditylang.org/en/v0.8.0/080-breaking-changes.html

Use a weighted multisig scheme to only require one signature per validator MSig key

For the master key multisig, validators can have differing share counts. Currently, each share of a validator corresponds to a distinct owner address and a message is signed by all shares of a validator. This is redundant since we can use a weighted multisig instead by keeping track of the share count corresponding to a single address of a validator. A validator's signature will have the weight of it's share count. If the combined weight of all signatures submitted is at least the threshold, then the command can be permitted. This optimization will require coordination with axelar-core.

Apart from reducing the number of signatures submitted for master key commands, this will also reduce the number of the owners set in storage for every epoch.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.