feat: Added upgradeToAndCall to Spoke Pool Upgrade task #1095
Conversation
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
fusmanii
force-pushed
the
faisal/try-upgradeTo
branch
from
462340a to
4b60fdd
Compare
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
fusmanii
force-pushed
the
faisal/try-upgradeTo
branch
from
2e4e5ce to
acb0084
Compare
fusmanii
changed the title
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
fusmanii
changed the title
fusmanii
requested review from
bmzig,
mrice32,
nicholaspai and
pxrl
as code owners
Co-authored-by: nicholaspai <9457025+nicholaspai@users.noreply.github.com> Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
fusmanii
force-pushed
the
faisal/try-upgradeTo
branch
from
0d5917e to
3520c92
Compare
tasks/upgradeSpokePool.ts
Outdated
|
|
||
| // @dev Any spoke pool's interface can be used here since they all should have the same upgradeTo function signature. | ||
| const abi = ["function upgradeTo(address newImplementation) external"]; | ||
| const abi = [ |
There was a problem hiding this comment.
ooc, can we draw on the ABI via typechain?
I'm generally pretty wary of using typechain, but given that the ABI is local to this repo it feels like we should be able to source it from somewhere dynamically, rather than have to redefine it.
There was a problem hiding this comment.
@pxrl good point, I was able to get the abi directly from the artifact instead
tasks/upgradeSpokePool.ts
Outdated
|
|
||
| task("upgrade-spokepool", "Generate calldata to upgrade a SpokePool deployment") | ||
| .addParam("implementation", "New SpokePool implementation address") | ||
| .addOptionalParam("upgradeOnly", "Upgrade only, do not pause/unpause deposits") |
There was a problem hiding this comment.
Do you think there's a scenario where we wouldn't want the atomic pause/unpause?
There was a problem hiding this comment.
On EVM chains we are absolutely sure there is no difference from the L1 EVM
There was a problem hiding this comment.
I just kept it in case someone is looking for the old upgrade only behaviour. @pxrl do you think its better (and safer) to only have atomic pause/unpause option?
There was a problem hiding this comment.
Yeah; I feel like we should just keep the interface simple and omit this option, since we don't actually have any concrete scenarios where we'd want to skip it. That feels like it'd be an exceptional circumstance.
There was a problem hiding this comment.
@fusmanii This is my only remaining comment btw - OK to drop the arg and then merge it?
There was a problem hiding this comment.
@pxrl dropped the param
tasks/upgradeSpokePool.ts
Outdated
| /** | ||
| * We perform this seemingly unnecessary pause/unpause sequence because we want to ensure that the | ||
| * upgrade is successful and the new implementation gets forwarded calls by the proxy contract as expected | ||
| * | ||
| * Since the upgrade and call happens atomically, the upgrade will revert if the new implementation | ||
| * is not functioning correctly. | ||
| */ | ||
| const data = spokePool.interface.encodeFunctionData("multicall", [ | ||
| [ | ||
| spokePool.interface.encodeFunctionData("pauseDeposits", [true]), | ||
| spokePool.interface.encodeFunctionData("pauseDeposits", [false]), | ||
| ], | ||
| ]); |
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
…racts into faisal/try-upgradeTo
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
…racts into faisal/try-upgradeTo
…isal/try-upgradeTo
We want to ensure that the new implementation is working as expected by toggling
pauseDepositsfunction post upgrade