Upgrade Strategy

[minghinmatthewlam]

Context and scope
Currently Teleporter is a non upgradeable contract, but in this case any bugs are found, or new features would like to be added, we would need some form of upgrade strategy.

Discussion and alternatives

1. Implementing a pass-through proxy that forwards Teleporter calls on to the correct implementation contract, where the individual implementations maintain their own state. - @minghinmatthewlam points out that this would make it difficult to handle the msg.sender value when receiving teleporter messages, since it would change with each new implementation.
2. Using the standard upgradable proxy smart contract pattern. - In this case, we would need to be careful about the contract state and variable ordering. This would mean that the proxy contract needs to be deployed to the same contract on each chain using Nick's method, and that it would be possible for different Teleporter versions to send messages to one another. This is a non-starter as Teleporter depends on knowing that the messages it receives are from the same contract deployed bytecode deployed on another chain.
3. Using a upgradable protocol registry. - Instead of using a proxy, applications will simply lookup the current address to be used from a registry. We will provide a small intuitive library that wraps the necessary calls with the proper look up.

[minghinmatthewlam]

closed with #43