-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
feat(protocol): Add setter to IAddressManager of AddressResolver #13799
feat(protocol): Add setter to IAddressManager of AddressResolver #13799
Conversation
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.
This pull request adds a setter to the IAddressManager.
- The commit message is clear and concise.
- The code changes are well-formatted and easy to read.
- The code is properly indented.
- The function
setIAddressManager
is a valid setter for the IAddressManager contract address. - The function has proper input validation to check if the address is a valid one.
- There is an event emitted when the address changes.
- It would be good to add an extra check to make sure that the new address manager is actually an instance of the IAddressManager contract.
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.
I think this makes sense in general.
Co-authored-by: Brecht Devos <[email protected]>
Co-authored-by: Brecht Devos <[email protected]>
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.
Overall, the changes look good. Here are a few points to consider:
- In patch 1/4, it looks like the event IAddressManagerChanged is missing the I prefix.
- In patch 3/4, the function setIAddressManager should be renamed to setAddressManager to match the event name in patch 1/4.
- In patch 4/4, there is a typo in the comment for the newAddressManager parameter. It should be "Sets a new AddressManager's address" instead of "Sets a new address manager contract address".
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.
Overall, this pull request looks good. Here are a few comments on the code changes:
- In Patch 1/4, the event
IAddressManagerChanged
was added. It should be namedAddressManagerChanged
to be consistent with other naming conventions in the codebase. - In Patch 3/4, the event name was changed from
IAddressManagerChanged
toAddressManagerChanged
. - In Patch 4/4, the function name was changed from
setIAddressManager
tosetAddressManager
. This is consistent with the change in Patch 3/4.
This comment was marked as resolved.
This comment was marked as resolved.
@dantaik this function is not setting the lookup addresses, it is setting the address of the AddressManager. Currently each and every contract which inherits from |
Exactly this is what it solves. Currently you cannot do anything to separate it (after the 2 contracts deployed) - only by deploying a new proxy as well OR upgrading with a proxy to have this setter which i'm adding here. |
Adding a setter to IAddressManager.
Because contracts connected to AddressManager (be it static or not) via an interface, a setter is necessary.
See issue : #13798
Also I feel there is a need for the setter, because both @dantaik and @Brechtpd indicated, that each contract (i.e. ProofVerifier, TaikoL1, Bridge) shall have it's own AddressResolver (= IAddressManager interface) - tho currently the TaikoL1, Bridge, TaikoToken sharing the same AddressManager (as we can see within the tests and also within the deployment script).
There could be situations (as described in discord convo) which implies security issues for not having a setter OR we indeed need separate instances for those contracts. For an example like: TaikoL1 needs BridgeV2, although TaikoNFTBridge still needs BridgeV1, therefore TaikoL1 and TaikoNFTBridge cannot share the same.