After merging separate projects to the monorepo we have duplicated configuration of the network and bridges.

Configuration for the oracle

• script to setup networks, deploy contracts and run bridges
• bridge and supplementaries configuration
• contracts configuration

Configuration for the UI

• script to setup networks, deploy contracts and run bridges
• bridge and supplementaries configuration
• contracts configuration

It seems logical that the configuration of e2e tests for UI (for example) could inherits the configuration of the e2e tests of the oracle. Otherwise if some changes of the contracts configuration happen it should be reflected in both e2e tests configuration. Similar is for the change on the oracle side - if something new appears (e.g. new configuration parameter or new worker) it will be necessary to modify both e2e tests directories.

Consider build a pipeline of e2e tests configuration in order to simplify the e2e tests maintenance.

Consider to have an option to run the TokenBridge UI in the docker container in order to minimize requirements to the system where the UI could be deployed.

As part of omni/tokenbridge-contracts#175 it was introduced an ability to work with ERC677 token deployed on the Foreign side of the bridge working in the erc20-to-erc20 mode.

It was discussed (omni/token-bridge#145) that it is necessary to extend the e2e testing to cover this scenario.

Currently they only work with with 2.2.0

Look over the monorepository to try and locate unused dependencies.

Additionally it might be worth to try and move some to devDependencies.

Related: #18

Also we might locate and update old dependencies.

There are some sections like POA General Bridge Overview in oracle README that is general enough so that it can be moved into root readme.

I think this should be done after all components are incorporated into the repository.

As part of omni/tokenbridge-contracts#117 the new functionality was introduced. It does not allow accepting the tokens relays if the amount of tokens is above the limits.

Test case for the erc20-to-native bridge mode:

1. set the daily limit for the bridge in 50 ether.
2. transfer 55 tokens from the Foreign chain to the Home chain.
   The results: the token balance of the bridge contract on the Foreign chain is increased but new coins are not minted on the Home chain. The AmountLimitExceeded event raised by the bridge contract on the Home chain.

Consider adding a new endpoint to monitor the AmountLimitExceeded event.

• Rename bridge-ui to ui
• Add linting
• Integrate in CircleCI (build, linting and test)
• Update Structure section in root readme
• Update links and foldernames pointing to old bridge-ui repository in readme
• Removing general bridge overview from readme will be done as part of #23
• Merging dotfiles like .gitignore will be done as part of #20
• Remove (or move to root readme) status badges
  • Remove travis.yml config
  • Setup coveralls.io integration (Coverage Status badge)
  • Setup david-dm.org integration (dependencies status badge)
• Remove package-lock.json since yarn.lock is used

I had to downgrade my node version to 9 in order to perform npm install in poa-bridge-contracts repo.

• Add prettier for UI
• Apply fixes on the code
• Integrate into CI (as linting)

As it was described in omni/token-bridge#126 it is very important to test behavior of the token bridge oracle with a BlockReward contract most identical to a real one.

Consider to add a special configuration similar to https://github.com/varasev/test-block-reward in e2e testing for the oracle in order to identify possible issues related to the such specific environment on the development testing stage.

Dotfiles like .eslintrc, .prettierrc in individual sub-directories should probably be merged into one in root directory.

There is a bridge_repo configuration variable in deployment/oracle which defaults to https://github.com/poanetwork/token-bridge, which should probably be updated to this monorepo.

• Rename deployment-bridge/bridge-nodejs to deployment-bridge/oracle
• Rename deployment-bridge to deployment
• General Bridge overview section will be extracted as part of #23
• Introduce ansible-lint, check linting on CI
• Update links to Github repos and folder names in deployment-bridge/bridge-nodejs/README.md
• Remove legacy deployment-bridge/upgradable-wo-parity
• Update Structure section in root readme

There is a special scenario found on xDai bridge and addressed in https://github.com/poanetwork/poa-bridge-contracts/pull/165/files when 0 tokens are sent from the Foreign to the Home side.

Consider to extend the oracle e2e testing with the corresponding tests to make sure that this and similar issues could be found in the future.

• Move audit to root dir
• Move licence, code of conduct and contributing documents to root dir
• Remove Travis badge and config
• Update token-bridge/README.md with new links to licence and contributing docs
• Update contributing doc with new links
• Move gitter to main readme

The Dockerfiles are COPYing package-lock.json when building images.
We should remove this dependency, or rely on yarn.lock instead.

The work to finish preparation of contracts working on the spuriousDragon EVM version was completed as part of omni/tokenbridge-contracts#180. These changes were required to run the token bridge on the Ethereum Classic network. Since this network contains a set of differences related to the EVM and ways how the methods of contracts are handled, it is necessary to extend e2e testing for the oracle and UI as so they worked with the home contracts run on the environment similar to the Ethereum Classic.

As part of extension of the bridge limit functionality (omni/tokenbridge-contracts#110) the situation when the bridge balance could differ in different networks due to incorrect user operation (the value outside the limits was transferred from Foreign to Home) could occur.

The monitor should use the variable in the HomeBridge contract that stores amount of tokens which was sent above the limits, the variable will help to calculate the bridge balance properly.

My understanding of the code:
https://github.com/poanetwork/bridge-ui/blob/7ddefe015a3630e38db14d04fb7feeb0c5337593/src/stores/TxStore.js#L95-L116
that UI will always wait for 8 blocks prior to get status of transaction but it is not always true.
The number of blocks configured separately for every network as part of bridge contracts deployment:

https://github.com/poanetwork/poa-bridge-contracts/blob/aa811e7223847320dd83ce0a8a46d3bcad68dc8b/contracts/upgradeable_contracts/U_HomeBridge.sol#L36
and
https://github.com/poanetwork/poa-bridge-contracts/blob/aa811e7223847320dd83ce0a8a46d3bcad68dc8b/contracts/upgradeable_contracts/U_ForeignBridge.sol#L47

So, these values could be fetched by calling requiredBlockConfirmations() from the corresponding contract:

https://github.com/poanetwork/poa-bridge-contracts/blob/aa811e7223847320dd83ce0a8a46d3bcad68dc8b/contracts/upgradeable_contracts/U_BasicBridge.sol#L39-L41

Consider to change UI to wait that number of blocks which is configured in the contracts.

As per the security audit https://hackmd.io/s/Sk6P7Uqtm#6-The-app-relies-on-smart-contract-immutability it was suggested to have use different RPC for each token bridge worker.

Consider to have an ability to specify different URLs in group_vars/<bridge_name>.yml. For example,

• COMMON_HOME_RPC_URL will allow to specify one RPC url for all token bridge workers connected to the Home side of the bridge.

• COMMON_FOREIGN_RPC_URL will allow to specify one RPC url for all token bridge workers connected to the Foreign side of the bridge.

• HOME_RPC_URL_SIGREQ will allow to specify RPC URL that will be used by watcher:signature-request if COMMON_HOME_RPC_URL is not specified.

• HOME_RPC_URL_COLSIG will allow to specify RPC URL that will be used by watcher:collected-signatures if COMMON_HOME_RPC_URL is not specified.

• FOREIGN_RPC_URL_AFREQ will allow to specify RPC URL that will be used by watcher:affirmation-request if COMMON_FOREIGN_RPC_URL is not specified.

• HOME_RPC_URL_SENDER will allow to specify RPC URL that will be used by sender:home if COMMON_HOME_RPC_URL is not specified.

• FOREIGN_RPC_URL_SENDER will allow to specify RPC URL that will be used by sender:home if COMMON_FOREIGN_RPC_URL is not specified.

As part of the initial integration to the monorepo both sets of e2e tests for the oracle (#45) and for the UI (#54) were added to CircleCI.

From the CI process point of view both e2e test environment performs the following set of actions:

• pull parity docker image
• pull redis db docker image
• pull rabbitmq docker image
• pull node.js docker image
• prepare Linux on the oracle image to resolve dependencies
• resolve dependencies to run the oracle
• install dependencies to compile contracts
• compile contracts
• install dependencies to deploy contracts
• deploy contracts

It definitely increases time of the e2e tests and cause redundant load on the testing system.

Consider to optimize the process of running e2e testing on CircleCI in order to reduce number of duplicated actions.

Turns out that the ui-e2e tests are flaky.

Failing run

• CircleCI build 836
• Output from yarn run ui-e2e: failing-836.txt

• There is a this.retries(2) which means that the tests were run 3 times in total
  • The output from mocha does not show 3 attempts, only last one but the tests are tried 3 times as I confirmed on the side with console.logs

Successful run

• CircleCI build 842
• Output from yarn run ui-e2e: passing-842.txt
• Same commit as the failing run - just hit re-run on CI

I didn't find any meaningful differences in the outputs and I don't know what might be the cause of this.

Release 2.3.0-rc0 should be used for poa-bridge-contracts.

As a final exercise of stage 1 we should perform a manual deployment on Kovan/Sokol testnet following the README's, updating the instruction along

As it was described in omni/token-bridge#126 it is important to test behavior of the token bridge oracle with parallel actions of other oracles.

Consider to configure e2e tests of the oracle as so the network contains at least 3 validators and requires 2 signatures for confirmation the transfer.

Currently they only work with with 2.1.0 2.2.0 as of #54

We need to check that docker logs of containers creeated by the deployment playbook are proerly rotated and fix if they're not.

Bridge Monitor MVP

After a few brainstorming sessions with @patitonar and @fvictorio we came up with the following proposal for a new (enhanced) version of the Bridge Monitor. We consider this to be the initial release of a much more rich, complex and easy to extend project.

Basic set of features

• Make it work by just creating the .env file and doing npm start (assuming the backing DB is on)
• Be able to see all the information that is already showing, but without having to manually go to specific URLs (a simple navbar should do the trick here).
• No real time yet, but reloading the page should show new information (meaning, no need to manually trigger anything)

Stack

• Backend: Koa. It's nicer than express for smaller projects and it's better in many aspects.
• Frontend: Koa views for now. We can consider moving to React if the UI gets complex. JSON responses will be supported as well.
• Database: Mongo. We don't exactly have relationships between data and we already have functions that process data as JSONs. Besides, we could easily save a collection of "points" in time for when we add the "history" feature.

Pages

• Home: Balances & stuck transfers, if any
• Validators: Validators
• Events: Events stats

We don't need anything fancy in the UI: just showing the data in any way that
it's not a raw JSON will be an improvement.

Data processing

Since this is an MVP and the application is small (for now), just having a worker started by the server should be enough. Meaning: we don't need to decouple the server from the worker that updates the data periodically. The server is straightforward: just serving the content in the DB. The worker is also simple: it has to do the same that the checkWorkers scripts we have now, and save it to the DB.

Tasks breakdown:

1. Server boilerplate: create endpoints that show mock data, or data from the DB that we insert manually.
2. Worker: fetch the data and save it in the proper document.

Further features

Features to be added in a later on (post-MVP stage)

• Real time updates
• Show historical data
  • Charts
  • Analytics
• Alerting system
• ...

• Rename bridge-monitor to monitor
• Remove package-lock.json since yarn.lock is used
• Remove duplicate LICENCE
• Add links to root Licence and Contributing documents in the readme
• Update Structure section in root readme
• Integrate linting with CI
• Merging dotfiles like .gitignore will be done as part of #20

• Extract bridge-ui/e2e
• Run them on CI

Add poa-bridge-contracts (branch refactor_v1) repository as a git submodule and use compiled contracts instead of contracts on abis directory

If we have on the same system both: monitor tool and bridge-ui (for testing purpose), they cannot be run together since occupy the same port.