baseline
baseline copied to clipboard
Implement EIP-2535 to make workgroup shield contract upgradeable
Overview
The "Diamond Standard" (see EIP-2535) is a pattern for upgradable smart contracts. The workgroup shield contract should be refactored to implement EIP-255, with each workflow identifier becoming an upgradable facet.
Reference
Questions
- How do existing workflows behave once they are upgraded?
Assumptions
Acceptance
Tasks
- [ ] Spike the workgroup shield contract diamond pattern
A couple of comments/thoughts/observations:
- You need all contracts to be facets in the diamond pattern, not just the shield contract
- You need the governance contract from the Diamond pattern to manage the upgrade process
- Since during the upgrade process you need to suspend processing, you need a. a transaction queue b. a mechanism that pends transactions in the queue when the upgrade is initiated
- You need a way to roll back an upgrade if a bug is found which would be most simply done through another upgrade process
- You need to be able to inform the users of a planned upgrade and you need to inform users that a transaction is pending due to upgrade -- requires additional request response for transaction submission
- Since you have shared storage e.g. workgroups etc. you need to utilize the diamond pattern where contracts share storage (separate contract instances for functional vs storage contracts)
- Who or what will be authorized to make upgrades?
@Kasshern @skosito @Ybittan @biscuitdey This discussion might be relevant for our work on the SRI. Keeping it open so that we can discuss.
Trail of Bits brought up significant security issues with EIP-2535, and the response.
More real-world use cases and a Consensys Diligence recommendation
Real-world use case and security analysis of that implementation.
Recent blog about EIP-2535 ... apparently 3 reference implementations by author have been security audited.
@ognjenkurtic @Kasshern @Ybittan @biscuitdey @kthomas
@Kasshern @skosito @Ybittan @biscuitdey This discussion might be relevant for our work on the SRI. Keeping it open so that we can discuss.
probably not so relevant for SRI to have these upgradable, but if we decide to make contracts upgradable since we will use hardhat anyways we can use proxy pattern built in hardhat https://docs.openzeppelin.com/upgrades-plugins/1.x/hardhat-upgrades