Integration with Zilliqa Fails Due to Address Format Validation

[youssefea]

Issue Description: When attempting to integrate the Zilliqa blockchain with SubQuery, the operation fails during the yarn dev command. The log indicates that the issue is due to the address format that Zilliqa uses, which is not recognized as a valid Ethereum address by the SubQuery configuration.

Log Output: zilliqa-starter-postgres-1 | 2023-09-04 14:43:01.034 UTC [1] LOG: database system is ready to accept connections zilliqa-starter-subquery-node-1 | 2023-09-04T14:43:03.938Z <subql-node> INFO Current @subql/node-ethereum version is 2.12.3 zilliqa-starter-subquery-node-1 | 2023-09-04T14:43:03.940Z <subql-node> INFO Current @subql/node-ethereum version is 2.12.3 zilliqa-starter-subquery-node-1 | 2023-09-04T14:43:04.114Z <configure> ERROR Create Subquery project from given path failed! Error: failed to parse project.yaml. zilliqa-starter-subquery-node-1 | An instance of DeploymentV1_0_0 has failed the validation: zilliqa-starter-subquery-node-1 | - property dataSources[0].options.address has failed the following constraints: isEthereumAddress zilliqa-starter-subquery-node-1 | dependency failed to start: container zilliqa-starter-subquery-node-1 is unhealthy error Command failed with exit code 1. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Error Context: This error is directly related to the unique address format that Zilliqa uses (e.g., zil1aftudda4gagsw6ytcu92hm7a2dfdp0ksdx8kwy), which doesn't match the typical Ethereum address format. This is critical for integrating any blockchain that has an EVM-compatible layer but utilizes a different address format.

Expected Behavior: The SubQuery project should be able to recognize and work with non-Ethereum address formats for EVM-compatible chains like Zilliqa.

Steps to Reproduce:

• Set up a SubQuery EVM project.
• Attempt to integrate Zilliqa and index some token like ZWAP.
• Run yarn devand observe the error in the log.

Suggested Solution: Update the address validation logic to accommodate for different types of blockchain addresses, not just Ethereum.

Additional Context: This issue could potentially impact other chains with EVM-compatible sides but different address formats.

[deverka]

Is this sth we want to prioritise or not necessarily? @jamesbayly

[stwiname]

We can add a new validation type for their address format and we can support the union type of both