Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

To Do: May 3 #1

Open
PulpSpy opened this issue May 3, 2021 · 3 comments
Open

To Do: May 3 #1

PulpSpy opened this issue May 3, 2021 · 3 comments

Comments

@PulpSpy
Copy link
Member

PulpSpy commented May 3, 2021

Add security discussion

  • Vulnerabilities with different methods
  • How upgradability helps recover from security incidents
  • Can you update a contract without broadcasting the fact that there is a problem (front-running resistant)

Add evaluation framework

  • Frequency
  • Decentralizatin
  • Foreknowledge of changes
  • Wholesale changes
  • Efficiency: gas for those uninformed about upgrades
  • Efficiency: gas for those informed about upgrades

Sample code

  • Simple contract implemented each way
@GreatSoshiant
Copy link
Collaborator

Some Ideas:

  • Time delay between changes
  • Period between a change proposal and have it on chain
  • GEV

@GreatSoshiant
Copy link
Collaborator

Check OpenZepplin upgrade patterns and find out the structure, events, and function names it used

@GreatSoshiant
Copy link
Collaborator

  1. In addresses that the "Upgraded" event fired before, we can find the new version's code using the implementation address and check the amount of change on the code using some code diff algorithms.
  2. In addresses that the "AdminChanged" event fired before, we can check if it changed from EOA to Multi-sig or another EOA or a governance structure.
  3. Don't forget to check for Pauseability and TimeLock and other stuff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants