feat: chain watcher

[mfw78]

Description

As we are removing Tenderly, we need to handle our own run loops for watching blocks / transaction logs.

Changes

• Add warmUp to initialise state from genesis, or last processed block.
• Used rebuild logic from feat: state rebuilder #29 for warmUp
• Once warmUp is complete, flag as inSync, and commence block watching.
• Implemented all in ChainWatcher, which runs per-chain, but we can handle many RPCs
• All chains watched from the same instance.

How to test

No unit tests available, however can observe functionality, such as with:

yarn ts-node ./src/watchtower.ts run --rpc http://erigon.dappnode:8545 --rpc http://nethermind-xdai.dappnode:8545 --deployment-block 17883049 --deployment-block 29389123 --page-size 0

NOTE: Substitute the above RPCs with the RPCs of your choice for the chains.

Observe synchronising of state. If Ctrl+C, observe SIGINT is caught, database is saved. Restart, and node resumes from last known synced block.

Todo

• Check for TODOs / dead code.

Related Issues

Closes #46

[anxolin]

in my oppinion here the logic is inverted. The model should not receive a DB and persist itself. The model should expose plain data and the persistance layer persist it

Otherwise you couple the model to the persistance layer

[mfw78]

I think this is a little strange as I show:

  public static async create(url: string): Promise<ChainContext> {
    const provider = new ethers.providers.JsonRpcProvider(url);
    const chainId = (await provider.getNetwork()).chainId;
    return new ChainContext(provider, apiUrl(chainId), chainId);
  }

Around this function. Nonetheless, can be added in a later PR to get over the waterfall 🐃

[anxolin]

Worked great