Smart contract upgradeability design

[boolafish]

Note

As a plasma user, I want the contract to be able to upgrade smoothly, So that I don't need to go through the hassle of exit and re-join for every plasma contract upgrade.

As an engineer, I want the contract to be able to upgrade smoothly, So that I can continuously deliver changes when needed.

As an engineer, I want to have a guideline on contract upgrade. So that I can make the decision when designing and roll out a new feature or patching bug fixes.

Successful Criteria

• Have the design doc out and reviewed by the team
• The design doc should include:
  • ways to upgrade smoothly (without exit and re-join)
  • limitation of it
  • some guideline to upgrade

Out of scope

• Guideline to inform users/clients on the step to take while upgrade.

[boolafish]

Sort of work in progress already, would try to set up a meeting for the doc review. https://omisego.atlassian.net/wiki/spaces/RES/pages/21233681/Upgrade+Mechanism+Design?atlOrigin=eyJpIjoiYmNjZTVmNTk1YTIxNDdiOGEyYzc1ZDY5NTIwYzY0OTgiLCJwIjoiYyJ9

[pik694]

Testing upgraded contract by forking the mainnet

Overview

The document describes a possible solution to enabling users to test the upgraded contract before the newer code becomes valid. The proposed solution is based on creating a local, private fork of the mainnet when an upgrade of the contract starts.

Background

Having the possibility of upgrading the contract, we would also like to enable the users to test the newer version of the contract on production data before the upgraded code becomes the valid one.

Requirements

1. Tests can be done on mainnet data. This is valuable because of the difficulty of creating a good test data and also because of a quirk of delegatecall based update mechanism - data layout in the storage of the proxy contract is implicit and can be corrupted by an updated library.
2. There is full isolation between mainnet and the testnet. This means replay protection - different network id for the forked chain.

Possible solution - forking

We propose a solution that bases on forking the mainnet shortly after the next version of the contract is loaded, a long time before it becomes active. We would like to switch our, till now normally working, node into dev mode, so it's able to forward the time to the moment when the contract switches. Creating a fork means that the state of the mainnet is copied into the testnet, therefore the first requirement is met.

Accordingly to the second requirement, the switch into dev mode would mean that the node would also have to change its chain id.

The fork should also produce blocks much quicker than it happens on the mainnet, so all contract flows would take less time than on the mainnet. As long as the fork works quicker than the normal world, users can quite quickly go through the upgraded flows and decide whether they should/want to exit while still previous code is valid.

[boolafish]

@pik694 I like that idea of forking. Just curious does anyone know how easy/hard it is to do so? If possible, can we also document some high level steps to do that? I am assuming we first spin a client node and sync to main-net. After up-to-date, we remove all connection with other nodes. But how do we switch to mode that provide faster block?

[InoMurko]

Commenting from Mana's codebase:

• would nodes go back and forth between mainnet chain and fork?

• how does the Customer decide, on which chain he wants to submit a transaction?

• thinking reliability and considering the changes to a client, this would mean that we would be able to alter at most one client (lets say Mana)

  • for your testing period to still be reliable, you would need to run multiple nodes of Mana. I presume before the dev mode, they would run in background, and after the switch, take the lead. Making the orchestration quite difficult. And because you would be running one type of client alone, you would be hiding any potential buggy implementation in the client. Ethereum has many clients to mitigate that issue.

Things that would need to change or be finished on Mana:

• I don't think the client would need to change it's Chain ID. Thats because he would be the only one working on that particular chain and would also:
• Need to adapt to whom and what it's being propagated through devp2p. Kademlia would need to be swaped for a fixed set of OUR peers as we're in the consensus alone.
• Mana does not have the ability to run POA (as Parity does).
• There are a few JSON RPC methods missing.
• And TBH, Mana was not battle tested as much as other clients.

[boolafish]

wow actually Ganache have the --fork option: https://truffleframework.com/tutorials/chain-forking-exploiting-the-dao

EDIT: Tried ganache forking rinkeby using infura ganache-cli --fork https://rinkeby.infura.io/v3/[:api_key] would work! And can start using localhost:8545 as web3 provider.

[boolafish]

Copy the above Forking mechanism to a OmiseGO wiki for future reference: here

[boolafish]

I think there is enough design here, close this design story.

Summarizing the main docs:

• Upgrade Mechanism design
• Upgrade with testing phase
• Testing contract by forking the network
• Abstract Layer Design

There's a follow up POC implementation story: https://github.com/omisego/research/issues/78.