-
Notifications
You must be signed in to change notification settings - Fork 64
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
(Feature, MASTER) ValidatorMetadata upgradable and voting for change metadata addresses #65
Conversation
* add solidity syntax highlighting * Eternal storage preparation * Minor changes * Upgradable ValidatorMetadata * Fix * ValidatorMetadata and EternalStorageProxy updates * ValidatorMetadata and EternalStorageProxy fixes and tests * VOTING_START_DATE issue * Fix 2_deploy_contract.js and addition to make_flat.sh * Rename EternalStorage vars * Add voting for ValidatorMetadata address changing * Minor fix * Making tests to take into account a voting for ValidatorMetadata address changing * Additional tests for upgradable ValidatorMetadata * Tests fixes for upgradable ValidatorMetadata * Save ValidatorMetadata storage address to 2_deploy_contract.js
contracts/ValidatorMetadata.sol
Outdated
); | ||
} | ||
|
||
function initProxyAddress(address _proxyStorage) public { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no restriction, who can call this method. Let's limit to the creator of contract.
@varasev also, please process solhint errors:
|
I've removed initProxyAddress because it actually duplicates proxyAddress initialization in EternalStorageProxy constructor.
Fixes have been made. |
I've removed initProxyAddress because it actually duplicates proxyAddress initialization in EternalStorageProxy constructor. |
Also I think we could keep only EternalStorageProxy (ValidatorMetadataEternalStorage) address without it's implementation address in ProxyStorage contract because we can read implementation address from EternalStorageProxy. I'll remove |
Please take a look at OpenZeppelin/openzeppelin-labs#49 there was some interesting find. |
@rstormsf Yes, this has already been implemented from the very beginning :) Please see contracts/eternal-storage/EternalStorageProxy.sol and contracts/ValidatorMetadata.sol code. |
@rstormsf If you mean that the internal _version and _implementation variables should only be in EternalStorageProxy I think we can keep them in ValidatorMetadata too. It allows us to use version() and implementation() functions not only from EternalStorageProxy but also from ValidatorMetadata. I think it is more convenient. |
I've removed an excess ValidatorMetadata implementation address from the ProxyStorage contract. I'll repeat all of the poa-test-setup steps a bit later. |
I don't think those variables should be in the metadata contract. |
Ok, @vbaranov please express your point of view: do we need the version() and implementation() functions to be in the ValidatorMetadata contract? Or we need them only in EternalStorageProxy contract? Right now we have these functions both in ValidatorMetadata and EternalStorageProxy (see EternalStorage.sol). |
I've repeated all the steps of https://github.com/varasev/poa-test-setup - all of them are successful. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong review
|
Please don't merge this PR yet until I make another PRs for poa-dapps-voting and poa-dapps-validators related to 20fb25e commit. |
…LimitPerValidator Related to poanetwork#39
(Mandatory) Description
The purpose of these changes is to make ValidatorMetadata contract upgradable and to let the validators to vote for changing ValidatorMetadata implementation address and storage address. Changes are related to #63.
Now ValidatorMetadata will have the storage and the implementation separately.
If we need to change the implementation and to keep the storage of this contract in the future the validators will be able to do this through the Governance dApp.
This PR also includes additional tests to cover ValidatorMetadata upgradability and voting for it's addresses changing.
Also it includes the fixes described in #39, #45, #54, #55, #58, #59, #60, #62 and #64.
(Mandatory) What is it: (Fix), (Feature) or (Refactor)
(Feature)