refactor[contracts]: Port OVM_ProxyEOA to use ovm-solc#545
refactor[contracts]: Port OVM_ProxyEOA to use ovm-solc#545smartcontracts merged 3 commits intomasterfrom
Conversation
🦋 Changeset detectedLatest commit: 2e405df The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
||
| this.contracts.OVM_DeployerWhitelist = DeployerWhitelist | ||
|
|
||
| this.contracts.OVM_ProxyEOA = await getContractFactory( |
There was a problem hiding this comment.
Here we deploy the reference version of the OVM_ProxyEOA which is duplicated by the OVM_ExecutionManager.
packages/contracts/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol
Show resolved
Hide resolved
karlfloersch
left a comment
There was a problem hiding this comment.
I didn't catch anything so seeeeemed to look good. However, definitely would like another set of eyes on this! Especially with raw opcode writing -- cc @ben-chain
| // PUSH1 0x00 | ||
| // CODECOPY # copy everything after prefix into memory at pos 0 | ||
| // PUSH1 0x00 | ||
| // RETURN # return the copied code |
| // PUSH1 0x00 | ||
| // RETURN # return the copied code | ||
| address proxyEOA = Lib_EthUtils.createContract(abi.encodePacked( | ||
| hex"600D380380600D6000396000f3", |
There was a problem hiding this comment.
Confirmed that this does indeed decompile to the opcodes in the comment above
There was a problem hiding this comment.
This bytestring looks good; it would also be super obvious from integration tests if it weren't looking. Since we do not have constructors, then this code could obviously also be put in place without a constructor. I assume we are going this way for ease of implementation in geth, right @smartcontracts? if so, we could use the ovmSETCODE upgrade path in the future.
There was a problem hiding this comment.
Good call on using SETCODE for this in the future
| *************/ | ||
|
|
||
| address constant DEFAULT_IMPLEMENTATION = 0x4200000000000000000000000000000000000003; | ||
| bytes32 constant IMPLEMENTATION_KEY = 0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddeaddead; |
There was a problem hiding this comment.
Maybe for a separate PR, but harping again that this should really use this EIP here.
There was a problem hiding this comment.
I agree that we should use that EIP, note that this will also break our regenesis script
https://github.com/ethereum-optimism/scripts/blob/main/scripts/state-surgery.js
Will add an issue over there
There was a problem hiding this comment.
| IMPLEMENTATION_KEY, | ||
| Lib_Bytes32Utils.fromAddress(_implementation) | ||
| ); | ||
| bytes32 addr32 = Lib_Bytes32Utils.fromAddress(_implementation); |
There was a problem hiding this comment.
I double checked the test files to make sure these are aligned correctly, looks good.
| address proxyEOA = Lib_EthUtils.createContract(abi.encodePacked( | ||
| hex"600D380380600D6000396000f3", | ||
| ovmEXTCODECOPY( | ||
| 0x4200000000000000000000000000000000000009, |
There was a problem hiding this comment.
Recommend to resolve these addresses
| // PUSH1 0x00 | ||
| // RETURN # return the copied code | ||
| address proxyEOA = Lib_EthUtils.createContract(abi.encodePacked( | ||
| hex"600D380380600D6000396000f3", |
There was a problem hiding this comment.
This bytestring looks good; it would also be super obvious from integration tests if it weren't looking. Since we do not have constructors, then this code could obviously also be put in place without a constructor. I assume we are going this way for ease of implementation in geth, right @smartcontracts? if so, we could use the ovmSETCODE upgrade path in the future.
| factory: getContractFactory('ERC1820Registry'), | ||
| }, | ||
| OVM_ProxyEOA: { | ||
| factory: getContractFactory('OVM_ProxyEOA', undefined, true), |
There was a problem hiding this comment.
What are these additional arguments? undefined is probably a provider, what is true? imo Python kwargs are handy for this kind of thing which can be replicated by making the second argument an object
There was a problem hiding this comment.
Agree that we should make these additional arguments an object. Although probably deserves its own issue.
tynes
left a comment
There was a problem hiding this comment.
Please add a changeset and is this safe to merge to master?
|
Yes, safe to merge. Will add a changeset. |
|
Changeset added. |
packages/contracts/contracts/optimistic-ethereum/OVM/accounts/OVM_ProxyEOA.sol
Show resolved
Hide resolved
* Port OVM_ProxyEOA to use ovm-solc * Remove all constructor logic from ProxyEOA * chore[contracts]: add changeset
…e` and `Safe`->`CrossSafe` (#545) Updates `SafetyLevel` variant names to match Go impl Ref ethereum-optimism/specs#717
Description
Continuation of the work started in #475. Ports
OVM_ProxyEOAto useovm-solc. This introduces an interesting problem becauseOVM_ExecutionManageruses the standardsolcand can therefore no longer referenceOVM_ProxyEOAdirectly in order to create a new version of it duringovmCREATEEOA. Instead, we deploy a template version ofOVM_ProxyEOAthat can be duplicated duringovmCREATEEOA. This is a bit less efficient, not exactly sure how much less efficient but I doubt it'll matter very much.