Rainbow Bridge repository structure proposal

[mfornet]

Motivated by the addition of a bridge between NEAR and BSC (#604) I propose refactoring our code inside rainbow-bridge in a different way.

Tunnels

As I have emphasised in the past bridges are formed by a pair of unidirectionals tunnels. For example, original raibow-bridge is composed by a tunnel that allows moving data from NEAR to Ethereum, and a tunnel that allows moving data from Ethereum to NEAR. This two tunnels are disjoint in the sense one can exist without the other existing or working. However, full functionalities of the rainbow-bridge is only unlocked having both tunnels.

Some example of uni-directional tunnel, is from Bitcoin to NEAR, which is easy to build, but the tunnel in the other direction is hard to make given the limited capabilities for Bitcoin scripts.

With this ideas of tunnels in mind, we can instead claim that the tunnel from NEAR to Ethereum is more like a tunnel from NEAR to EVM compatible chains, and a lot of its components can be reused in this regard if a new bridge is built between NEAR and an other EVM compatible chain.

High level structure

My proposal is to change the structure of rainbow bridge repository to make emphasis on the concept of tunnels, having a folder for each tunnel with all the components designed for this tunnel. Some benefits from having a clear separation between tunnels are that adding new tunnels is easier, code can be maintained easier as well, components from a tunnel can be designed as packages that can be reused and extended in a different tunnel.

As a case of study today we have the following tunnels (with its components):

• NEAR -> Ethereum (EVM)
  • Light Client (Solidity)
  • Prover (Solidity)
  • Relayer (Typescript)
  • Watchdog (Typescript)
• Ethereum -> NEAR
  • Light Client (Rust)
  • Prover (Rust)
  • Relayer (Typescript)
  • EthHashProof (Go)
• BSC -> NEAR
  • Light Client (Rust)
  • Prover (Rust)
  • Relayer (Typescript)

The repository should look something like this (Word to is included to denote the unidirectionality of this tunnels, but can be omitted for simplicity):

rainbow-bridge/
    near-to-ethereum/...
    ethereum-to-near/...
    bsc-to-near/...
    README.md
    ...

The bridge between BSC and NEAR is reusing the NEAR -> Ethereum (EVM) so no new tunnel is required in this direction.

I'll not make any emphasis on the inner structure of each tunnel, since it is hard to predict all expected components of future tunnels, and they can be tackled one by one depending of the needs.

Motivation

While reviewing new bridge between BSC and NEAR (#604) I loved how a lot of components were reused from the existing bridge. But at the same time I don't like the way both bridges (NEAR-Ethereum, BSC-Ethereum) are mangled in the same code. It is hard to review, maintain, and most importantly this approach won't scale as more bridges are added.

Tunnel interaction

We can have a tool (inspired by current bridge-cli) that allows interacting with each bridge (tunnels). This tool should provide a way to:

1. Initialise a bridge (deploy all smart contracts)
2. Run off chain services (start relayers/watchdogs)
3. Monitor health of the bridge (run metrics)

This steps can be defined per tunnel, and there can be different configurations to interact with different versions of the same bridge (i.e if they are running in Testnet/Mainnet/etc...).