The current chain start (found in main.go) independently creates the chains from the config, it would be much cleaner if it iteratively created them all.

Things to do:

1. Add a flag --gethdev. This is used incase someone uses geth --dev, which uses the default Clique settings (found here) basically triggers every hardfork at block 0
2. If the --gethdev flag is passed on this line use:

signer: ethtypes.MakeSigner(ethparams.AllCliqueProtocolChanges, ethparams.AllCliqueProtocolChanges.HomesteadBlock),

3. if --geth is not passed use mainnet config
4. call the rpc method to get the chain id and override the chain ID accordingly

• use receiver and emitter packages in the initialization of the Ethereum chain
• set the Ethereum writer to use the receiver bindings; set listener to use emitter bindings
• will need to re-generate go bindings upon any contract changes.

Right now we make use of a single ChainConfig Which is found in core/chain.go we should refactor this out for chain specific configs

Lets change these to source and destination?

Currently a the bridge starts fromthe current block, in reality it should start from the block when the contract was deployed.

The end result should be that any event emitted before the bridge booted up should be processed.

This can be done by either:

• having it a param in the config (less ideal)
• starting from block 0 (more ideal)

Currently SubmitTx is a stub method that just panics in the centrifuge connection.

Please add to readme.

Goal: Provide reproducible keys for testing (go tests and testing environment).

Case 1:
Inside a test we want to use keys that are easy to manage and update as necessary.

Case 2:
When we run two or more instances, we need to have multiple validator identities, we want this to be easy to configure on the fly.

Proposed Solution:

• Add 5 identities to the Go code
  • Alice, Bob, Charlie, Dave, Eve
  • These keys also need to be added to the Javascript side (just secp)
  • They should match the keys used by substrate
  • Each identity will have an associated secp, sr25519 and ed25519 keypair
• Provide a way to access these keys within Go code
  • eg. TestKeystore.Alice.PublicKey()
• Provide flags to start bridge using a specific identity
  • eg --Alice, --Eve

Producing Keys
We want to use the name (eg "bob") as the private key. We will need to represent this as bytes and should verify that we are producing the same keys as substrate (ideally).

Proposed Structure
We should implement this as a separate package that contains the go code to access these keys, likely keystore/keyring.

We also need to modify the keystore to have the option of using these keys. This will remove the need for our existing test keystore (need to update the tests using it as well).

We need an event emitted from the Centrifuge chain so we can capture it on the bridge and tranfer it to Ethereum

https://github.com/centrifuge/go-substrate-rpc-client

Note: we may want to reuse parts of this for other Polkadot chains

Further tests for Emitter.sol focusing on the locking mechanism of the Safe.sol

Refer to #118 for epic information.

The main goal is to prevent a bridge validator from submitting a transaction (that will revert/fail) because the deposit has already been finalized (VoteStatus.finalized).

The check should probably occur in the writer and skip the current write if that proposal is already finalized.

Needs to pass messages from a Listener to the correct Writer based on the protocol/message ID.

The writers and listeners need to share a connection to their respective network. Before implementing the adapters we should establish connection components for each network that provide:

• setting listeners for events
• submitting txs (state changing or otherwise)

These also need to be configurable, so we can specify the node, what keys to use etc.

• Receiver contract
• Emitter contract

Chains will store their respective Connection, Listener, and Pusher as well as source and destination addrs and their chain identifier.

In order to handle Ethermint connections we need the option of using HTTP RPC with ethereum chains.

This simply requires we use a different rpc client. rpc.DialHttp() will give us an HTTP connection instead of WS. We should provide an optional config option to use HTTP instead of WS. It is anticipated that this will required no additional changes to how we are using the client.

https://github.com/ChainSafe/ChainBridgeV2/blob/ccc38b2c9a4db9105508ee5cc5ae9252c95a5e8c/chains/ethereum/connection.go#L46-L60

Both releaseErc and releaseNFT in Safe.sol have the function modifier onlyOwner. Because Emitter.sol constructs Safe.sol with address(this) (making it the owner of Safe.sol), and Emitter.sol has no methods to call releaseErc or releaseNFT, these methods are uncallable once contracts are deployed.

In the branch wyatt/evm-tests there is a test that currently fails because of this issue.

Refer to #118 for epic information.

The main goal is to prevent a bridge validator from submitting a transaction (that will revert/fail) because the vote has already been made. The required check is to ensure the current relayer has not already voted on a specific proposal.

The check should probably occur in the writer and skip the current write if that person has already voted

The current mnemonic is scrambled across two spots(I think):

• The test scripts have it hard coded: start_ganahce.sh
• The test scripts for solidity have the private keys outright exposed: deploy_local.js

We should instead:

1. Make an ENV variable in the makefile
2. pass the ENV variable to the different commands as they need them

Special case for deploy_local.js:

• We need to derive the wallets into the correct public/private keys, and maintain the current array structure (to reduce re-writing everything). Ping me if this becomes tricky, ive done it a lot.

Presently all chains have the same fields in the config file. It would be nice to be able to provide arbitrary config options to allow for chain-specific options. Perhaps this can take the form of an opts field, which can then take key/values that are later interpreted by that chains listener/writer. We should also replace id with type to specify which chain type we want.
An example case is the contract addresses required for ethereum.

Current toml lib: https://github.com/naoina/toml

Refer to #118 for epic information.

The main goal is to prevent a bridge validator from submitting a transaction (that will revert/fail) because the deposit has already been made.

The check should probably occur in the writer and skip the current write if that proposal already exists on chain

Currently CI builds have a linter failing

It would be very useful if we could import existing keystore files. We can start with ethereum keystores and look at adding other support later.

We can utilize geth to be able to import the key format, then we just need to create a new keystore file for the bridge with the same private key.

Importing a key will look something like: chainbridge accounts --import --ethereum /path/to/key....

Currently start_eth accepts a value of --silent to be passed in as an argument. we should change it to be an env variable so that we can do SILENT=true make_start eth. This allows us to use make start_eth in the CI runs.

All the listeners and writers need a common interface. We should define these first and adapt as needed.

We need to define Connection, Listener and Pusher interfaces based on todays discussions.

The chainID should be an optional flag and configuration file option. Currently we have gethDev and kovan which need to be removed.

Some things to consider:

• makeSigner uses chainConfig but only actually takes the ChainID parameter, so we should make use of the underlying function to build the signerObject.
• we may also want to add a block number parameter, this is for the second parameter in the makeSigner object (it may not be needed) otherwise default should be instanbulBlock

We need to configure the bridge contract addresses and the node connections (ws/http). It might make sense to use the chain identifiers here, which are also used with the system to distinguish destination chains.

Once #112 gets merged, we'll run into problems because our validators are currently not smart. If a deposit happens on chain A, a validator will see that event and create a proposal on chain B. Another validator would also see that event, and try to make a proposal, it will fail, and the validator will lose some gas from the failed transaction.

We need a suit of functions to help make our validators smarter. All of these functions should return booleans and not be integrated into the bridge logic yet (we will integrate them later, but compartmentalizing them will make testing easier). These functions are linked below:

• Create proposal check
• Vote proposal check
• Execute proposal check

An example would be:

func proposalExists(chainId, depositId) boolean {
  value := queryChainForDeposit()
  if value return true
  else return false
}

We should utilize a keystore to provide easy & secure access to signing keys. For example, we could have a master password that encrypts all private keys for every network.

This should also make it easier to pass around keys. If adapters can interact with the keystore they could sign and verify for their own network as well as the destination/source if required.

This can also be used in the deployment infrastructure to establish new keys and load them into the bridge,