A continuation / adaption of #1132. I didn't want to lose the contents of that branch, so this is a different branch based on it, with the bridging functionality changed and restructured.
Quite a big refactor since the last time someone other than me looked at this, so let's talk about the big change, which is the introduction of the ColonyBridge contract. The intention here is that this contract is the only contract that colonyNetwork interacts with when it comes to bridging, and will do so for all time (a claim that will surely never become wrong) through an IColonyBridge interface. The intention here is to abstract out the specificities of any bridging solution we're using, and putting them all in the ColonyBridge contract.
We had briefly talked about this being subsumed in to a single contract inside ColonyNetwork, but as I continued with implementation I ended up back here because of how we would need external calls anyway from ColonyNetwork to itself, as the bridging requests are spread across multiple files. May as well have the external calls to another contract. I also wasn't keen on polluting the ColonyNetwork contract storage with bridge-specific details. Either way, the upshot is that we no longer have the before/after bytes for each type of bridging transaction, and the behaviour is much easier to understand from reading the contracts (indeed, is actually defined by the contracts).
The ColonyBridge contract gets configured with all known ColonyBridges on other chains and the colonyNetwork on the chain it is deployed to. ColonyNetwork gets configured only with the ColonyBridge contract on its chain. ColonyBridges also get configured with whatever additional details need to be provided for the bridging solution being used. In this case, it's the wormhole address, but obviously could be anything with another implementation.
To change the bridge being used, we would deploy new sets of ColonyBridges to all chains with the new functionality, and then point the colonyNetworks at them - no changes to the ColonyNetwork contract required in that scenario. It would be nice to have a test with the old AMB functionality demonstrating that e.g. using the AMB we could still control a Gnosis Safe. I have confirmed with product that they are not expecting chain<->chain gnosis safe support with the multichain deployment, and so that functionality is going to be lost.
There is an implicit assumption here that colonyNetwork will only ever want to send messages to another colonyNetwork. I think that's fine, but I could see it meriting discussion.
area
commented
4 months ago
A continuation / adaption of #1132. I didn't want to lose the contents of that branch, so this is a different branch based on it, with the bridging functionality changed and restructured.
Quite a big refactor since the last time someone other than me looked at this, so let's talk about the big change, which is the introduction of the
ColonyBridgecontract. The intention here is that this contract is the only contract thatcolonyNetworkinteracts with when it comes to bridging, and will do so for all time (a claim that will surely never become wrong) through an IColonyBridge interface. The intention here is to abstract out the specificities of any bridging solution we're using, and putting them all in the ColonyBridge contract.We had briefly talked about this being subsumed in to a single contract inside ColonyNetwork, but as I continued with implementation I ended up back here because of how we would need external calls anyway from ColonyNetwork to itself, as the bridging requests are spread across multiple files. May as well have the external calls to another contract. I also wasn't keen on polluting the ColonyNetwork contract storage with bridge-specific details. Either way, the upshot is that we no longer have the before/after bytes for each type of bridging transaction, and the behaviour is much easier to understand from reading the contracts (indeed, is actually defined by the contracts).
The ColonyBridge contract gets configured with all known ColonyBridges on other chains and the colonyNetwork on the chain it is deployed to. ColonyNetwork gets configured only with the ColonyBridge contract on its chain. ColonyBridges also get configured with whatever additional details need to be provided for the bridging solution being used. In this case, it's the wormhole address, but obviously could be anything with another implementation.
To change the bridge being used, we would deploy new sets of ColonyBridges to all chains with the new functionality, and then point the colonyNetworks at them - no changes to the ColonyNetwork contract required in that scenario. It would be nice to have a test with the old AMB functionality demonstrating that e.g. using the AMB we could still control a Gnosis Safe. I have confirmed with product that they are not expecting chain<->chain gnosis safe support with the multichain deployment, and so that functionality is going to be lost.
There is an implicit assumption here that colonyNetwork will only ever want to send messages to another colonyNetwork. I think that's fine, but I could see it meriting discussion.