feat: backend mechanics for OVM self-upgrades#682
feat: backend mechanics for OVM self-upgrades#682
Conversation
|
05facb6 to
9c94a18
Compare
| ) | ||
| override | ||
| external | ||
| onlyCallableBy(0x420000000000000000000000000000000000000A) |
There was a problem hiding this comment.
Resolving from the L2-compiled AM was a pain here since you need to construct an ovmCALL to the AM to load storage from the correct account. I figured since this will be chugsplash-ified and moved into a storage contract anyways, it's fine to leave for now.
There was a problem hiding this comment.
Think you forgot to finish the sentence :D chugsplash-ified -> what does this mean?
There was a problem hiding this comment.
Maybe better to refactor the address to a constant?
There was a problem hiding this comment.
Edited -- TLDR: it will be moved to storage.
There was a problem hiding this comment.
Can we use storage in the execution manager? If not, I think we should just make it a constant.
|
Tests are failing due to the gas cost changing. |
packages/contracts/contracts/optimistic-ethereum/OVM/predeploys/OVM_UpgradeExecutor.sol
Show resolved
Hide resolved
| ) | ||
| override | ||
| external | ||
| onlyCallableBy(0x420000000000000000000000000000000000000A) |
There was a problem hiding this comment.
Can we use storage in the execution manager? If not, I think we should just make it a constant.
| ) | ||
| override | ||
| public | ||
| authenticated |
There was a problem hiding this comment.
The authenticated modifier allows calls from either the EM or StateTransitioner.
I think we could reduce the attack surface, and avoid 'implicit behavior' by breaking that check into two modifiers, or perhaps a single modifier which accepts an array of authorized callers (more like the new onlyCallableBy() modifier above).
There was a problem hiding this comment.
@maurelian Can you make a quick little issue for this? Think it should be dealt with in a separate PR.
packages/contracts/contracts/optimistic-ethereum/OVM/execution/OVM_ExecutionManager.sol
Show resolved
Hide resolved
| _value | ||
| ); | ||
| } | ||
| } |
There was a problem hiding this comment.
Shouldn't there be some access control on each of these functions?
There was a problem hiding this comment.
Yeah, this is just a placeholder for the sake of integration testing. I'll add a comment to make this clearer.
|
This PR is now the base of the v0.4.0 branch. I'm going to update #653 to point to that branch. |
|
Going to close this in favor of simply having it be the base of v0.4.0. Will be fixing any remaining issues with this PR in a separate PR against that branch. |
|
As per conversation with @ben-chain, @snario, and @karlfloersch, we're going to reopen this PR and try to merge it into |
| } | ||
|
|
||
| // save the block number and address with modified key if it's not an eth_call | ||
| if evm.Context.EthCallSender == nil { |
There was a problem hiding this comment.
Note that during debug_traceTransaction the EthCallSender is nil and will hit this block. We don't have a good solution to this right now
There was a problem hiding this comment.
What is the problem you are referring to a solution of here? I added this because the diff proof should include changed accounts if we want to prove fraud on an upgrade tx.
| } | ||
| } | ||
| evm.StateDB.SetCode(address, code) | ||
| log.Debug("Put account code", "address", address.Hex(), "code", hex.EncodeToString(code)) |
There was a problem hiding this comment.
This logline can become very expensive and will pollute the logs with large amounts of code. Could we remove the second half of the logline? code + hex.EncodeToString
|
I have rebased and renamed this branch to reflect intended release version. Closing this one and will re-open there. |
Description
This PR to the 0.3.0 release candidate gives the execution manager access to directly setting account code and storage, so that versioning can be performed from within the L2 state transitions.
Additional context
0.3.0-rc.OVM_UpgradeExecutor.eth_getCode/eth_getStorageAtRPC level.