SNOW integration

[andrii-kl]

In the process of ICE/SNOW integration it turned out that we can't simply reuse existing BSC implementation for SNOW, because of several specifics in the go-ethereum client implementation.

To learn more about the issue, you can visit the following link. #556

I suggest the next structure the relay implementation to extend reusability of the module parts and add new integration of SNOW/ICE

1. Move all clients to a separate package to make code easier to reuse.

cmd - iconbridge - client

• common (package)
• eth_client.go
• substrate_client.go
• substrate-eth_client.go (aggregate eth + substrate)
• near_client.go
• hmny_client.go

2. Rename the bsc package to eth. Because it's not really a specific implementation of BSC, but a basic implementation of Eth.

3. Create new substrate-eth implementation.

cmd - icon - chain -

• bsc -> eth (BSC / ETH / ....) eth client
• substrate-eth (SNOW/ICE / MOONBEAM / ...) substrate-eth client
• substrate (future) substrate client
• hmny
• icon
• near

Implementation steps:

1. Run minimal but stable working version of the ICON | SNOW relay.
   Test start BTP with ICE chain #501
   Investigate the incompatibility issue between Eth(BSC) and Substrate-eth(SNOW/ICE) #556
   story(bmr): repurpose bsc chain api to fit SNOW #601
   story/601-bmr-repurpose-bsc-chain-api-to-fit-snow
   Fix transaction fee calculation for SNOW chain #607
   Run e2e tests for the final SNOW version on the testnet  #621

2. Move all clients to a separate package to make code easier to reuse.

3. Create new substrate-eth implementation

4. Update SNOW implementation with a new substrate-eth client

[andrii-kl]

@FezBox @CyrusVorwald-ICON @manishbista28 @bbist Hey guys, your opinion on the next plan is important

[CyrusVorwald]

I agree with all changes mentioned to be made regarding the client. Certainly step 1 of the implementation steps is most important before we consider refactoring.

The /common folder does not belong in this project and will eventually be moved to its own library by the goloop developers. We can move things out of it but should not add to it if possible.

Currently, most relay code exists in /cmd but this is typically reserved for executables only. The relay should be thought of as its own Golang project and it should be restructured to conform with Golang standards for project structure. In this case, I believe it should live in /relay/pkg/clients or something similar. The rest of the relay would also need to be moved to the appropriate places.

[manishbista28]

@andrii-kl
Following are few things that, in my opinion, would best be included in Step 1.
Please let us know your opinions on these.

1. Update Parameters specific to SNOW chain receiver. These include the following parameters. Please check if these values are suitable and update accordingly.

BlockInterval              = 25 * time.Second
BlockHeightPollInterval    = 60 * time.Second
BlockFinalityConfirmations = 5

2. Update snow receiver to use at least header-chain verification. This is needed to ensure that the blocks we are scanning for BTP Message forms a chain.
   BSC Verifier's logic present on this commit can be referenced for header-chain verification.

3. Add unit tests to SNOW chain API.
   If applicable, please take reference from a similar group of unit tests written for bsc chain API added to this PR

4. To deploy snow to testnet, we have been manually editing a configuration file of a deployment script originally written for icon-bsc. To be specific, we change network id and rpc endpoint on config.sh file. Do we, at this phase, need to automate this process (i.e. avoid manual edits to config.sh) ?

[andrii-kl]

Good idea

1. Update SNOW configuration parameters. #637

2. feat(bmr): Implement basic header block verification for SNOW #643

3. In my opinion It's not critical for MVP, because we just copied BSC implementation without functional changes.

4. Step 2 feat(btp): Extend deployment script functionality to support different chain configs #641