[SIP-7] Address and ABI distribution (RFC)

[cstrangedk]

Address and ABIs distribution

Description

Each set of smart contracts (i.e. skale-manager, IMA) exists in multiple instances and versions on multiple networks (Ethereum mainnet, Rinkeby or Kovan) and serve different needs (production, testnets, hackathons and others). It creates a problem of providing addresses of these smart contracts. Currently it's solved by the skale-network repo which contains files with desired addresses.

Address Solution

• npm package to provide an interface for javascript and typescript applications
• pypi package to provide an interface for python applications
• modify deployment scripts in all smart contracts repos to register addresses in the system right after deployment

Addresses will be provided in hierarchical logic structure application-name -> instance-name -> smart-contract-name -> address.

For example: ima -> eth-amsterdam -> DepositBoxERC20.

Example in code:

> import { ima } from "@skalenetwork/abis";

> ima.DepositBoxERC20.address // ethereum mainnet by default
'0x2a42Ccca55FdE8a9CA2D7f3C66fcddE99B4baB90'

> ima.eth_amsterdam.DepositBoxERC20.address
'0x3Fc377c4322f9d448996c3faBe1150213A434bC1'

Because IMA is deployed on many chains it requires additional level to specify SKALE chain.

Example:

> import { ima } from "@skalenetwork/abis";

> ima.eth_amsterdam.fit-solitude.MessageProxyForSchain.address
'0xd2AAa00100000000000000000000000000000000'

ABIs solution

1. resolve address of a desired smart contract
2. make rpc call to request smart contract version
3. download corresponding ABI from github releases

Steps to be done:

• add version for all smart contracts
• automatically publish ABI for all smart contracts repos to github releases
• modify packages

Example:

> import { ima } from "@skalenetwork/abis";

> ima.version // ethereum mainnet by default
'1.9.0'

> ima.DepositBoxERC20.abi
[ ... ]

[cstrangedk]

Because IMA is deployed on many chains it requires additional level to specify SKALE chain.

Suggest omitting SKALE chain name requirement as predeploy addresses are predefined across all chains.

ABI solution

Consider version parameter to select specific ABI version.

[tarasglek]

Thank you for taking on versioning of ABIs vs client libs. Please include ability check deployed skale chain version.
API described to obtain contracts would be fantastic.

Need a little few more api features to make IMA interaction smooth.

Currently initializing the ima requires name, abi, mainnet info. It should be possible to initialize from chainid/chain-name eg

let ima = await IMA.fromChainId(0x5d456c62)
console.log(ima.schain.name, ima.mainnet.chain_id)

It would also be handy to iterate chains via api ala https://mainnet.skalenodes.com/ .

Here are the types of metadata we need to collect outside of ima-js for now:

1. chainid<->name mapping
2. schain->mainnet mapping
3. block explorers for both, api endpoints
4. ABIs for schain/mainnet [this is solved by this pr]
5. tokens allowed/deployed on schain [sort of solved by this pr by extracting info from ABI?]
6. token bridging info
7. is the chain a testnet?
8. token-pricing info
9. pointer at bonus metadata owner of schain wants to include. Eg any other contracts chain owner wants to be discoverable, ways to obtain sfuel.
10. is chain version compatible

Would be handy to have these accesible via a single coherent api.

[TheGreatAxios]

Amazing! Overall solves the majority of issues when currently dealing with the multiple repo architecture. A couple of things that could be nice to add just to make the usability a bit simpler.

Automatic Provider

Potentially integrating both ethers.js and web3.js and creating a share interface that will enable a share contract usage through a provider.

import { Provider } from "@skalenetwork/abis";
const provider = new Provider(s_chain_name);
let isMTMEnabled = await provider.config_controller.isMTMEnabled();

/// Returns false

This might be unnecessary for many just a fun thought to potential aid the newer developers to the space.

Custom Flags to allow for earlier testing

Possibly adding text based flags instead of ABI version for loading ABIs (mostly for testnet). In order to allow developers to have an easier time testing out the the newest ABI versions.

import { ima } from "@skalenetwork/abis";

const IMA = new ima('stable'); // Uses Stable Version
const address = IMA.DepositBoxERC20.address // ethereum mainnet stable address
'0x2a42Ccca55FdE8a9CA2D7f3C66fcddE99B4baB90'

const IMA = new ima('latest'); // Uses Latest Development Versions
const address = IMA.DepositBoxERC20.address // ethereum rinkeby development address
'0x1b43Cdea55FdE8a9CA2D7f3C66fcddE9912315fe'

The reason for this is grabbing the abi via IMA.[s-chain-name] every time or IMA.[mainnet/testnet] etc is unnecessary when in reality you are really only working with mainnet/testnet and a SKALE chain in most circumstances. Therefore, setting that value on a new instance makes more sense. The above examples could easily flow into that category.

[TheGreatAxios]

@cstrangedk Checking for any movement here in regards to a core place to derive ABIs from without having to manually download them i.e via an API, on-chain location, etc.