Set the development environment up for Proxy Colonies

[area]

Description

This PR updates the CDapp dev environment to a place where the development of proxy colonies using Wormhole could begin to take place on it.

Testing

NB These instructions are liable to change, especially as the development of the contracts continue. If they don't appear to be working for you, reach out to Alex or Daniel

npm run dev

The dev environment will spin up as normal, with new additions:

• Two new network containers, called network-remote and network-remote-2. These have the same contracts deployed to them (i.e. the bridging contracts required, the ProxyColonyNetwork with the ProxyColony resolver deployed, and even a test gnosis safe (if that becomes relevant again)). They have chain Ids of 265669101 and 265669102. The difference between them is an operational one - on the one with chain ID 265669101, the relayer will pay gas fees for the bridging transactions. The same is not true on the chain with chain ID 265669102. Their providers are bound to ports 8546 and 8547.
• A wormhole-relayer container. This monitors the bridging contracts on all relevant chains, and passes messages between them as appropriate.

You can deploy a proxy colony by running npm run hardhat and executing the following:

cn = await ethers.getContractAt("IColonyNetwork", "0x777760996135F0791E2e1a74aFAa060711197777")
c = await ethers.getContractAt("IMetaColony", (await cn.getMetaColony()))
f = cn.filters.ColonyAdded()
f.fromBlock = 1
e = await ethers.provider.getLogs(f)
salt = await cn.getColonyCreationSalt({blockTag:e[0].blockNumber})
await c.createProxyColony(265669101, salt, {gasLimit:1000000})

You will see output looking something like the following in the window where you ran npm run dev:

wormhole-relayer  | debug: Received VAA through spy
wormhole-relayer  | destinationEvmChainId BigNumber { _hex: '0x0fd5c9ed', _isBigNumber: true }
wormhole-relayer  | destinationAddress 0x777760996135F0791E2e1a74aFAa060711197777
wormhole-relayer  | payload 0xe28fd9e9777760996135f0791e2e1a74afaa060711197777007292a6e2ba7a311f6f5032
wormhole-relayer  | Got a VAA with sequence: 0 from with txhash: undefined
wormhole-relayer  | bridged with txhash0xd2dc75056e15c056d16de1947920de470549c0ff201a51305ff8ee9dc402fa25

You will have have a proxy colony on that chain at the same address as the metacolony.

If you instead:

await c.createProxyColony(265669102, salt, {gasLimit:1000000})

You will get:

wormhole-relayer  | debug: Received VAA through spy
wormhole-relayer  | destinationEvmChainId BigNumber { _hex: '0x0fd5c9ee', _isBigNumber: true }
wormhole-relayer  | destinationAddress 0x777760996135F0791E2e1a74aFAa060711197777
wormhole-relayer  | payload 0xe28fd9e9777760996135f0791e2e1a74afaa060711197777007292a6e2ba7a311f6f5032
wormhole-relayer  | Got a VAA with sequence: 0 from with txhash: undefined
wormhole-relayer  | We do not pay for gas on destination chain. Skipping

The VAA is signed, but the relayer is not broadcasting the transaction. In practice, we will get the signed VAA ourselves from some API and broadcast it ourselves on the correct chain; hopefully by the time we wish to implement that I will be able to provide an endpoint that can be used; if that has not happened by the time you're thinking about implementing that flow, again, go should at me or Daniel to get on it.

The current state of the contracts in the network hash provided here lets you:

• Claim tokens on remote chains
• Pay out tokens on remote chains
• Deploy proxy colonies on remote chains
• Make arbitrary transactions on remote chains

Go have a look at the relevant Network PR for more details. Hopefully the changes to IColony.sol in conjunction with the tests will answer most questions you have.

Generally speaking, any function that took a tokenAddress before should now take a chainId and a tokenAddress in that order - so for example, moving funds between pots or setting expenditure payouts. Yes, that is a lot of functions, but there's no way around it - a tokenAddress is no longer a unique identifier for a contract.

This doesn't need merging anytime soon - no need for people to be running more containers than they need to be. Indeed, I could see this being a separate dev command, similar to the :all that already exists, but for now, this is sufficient.