Skip to content

feat: backend mechanics for OVM self-upgrades#682

Closed
ben-chain wants to merge 6 commits intov0.4.0-rcfrom
v0.3.0-ovm_su
Closed

feat: backend mechanics for OVM self-upgrades#682
ben-chain wants to merge 6 commits intov0.4.0-rcfrom
v0.3.0-ovm_su

Conversation

@ben-chain
Copy link
Collaborator

@ben-chain ben-chain commented Apr 28, 2021

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

  • Builds on the 0.3.0-rc.
  • Does not yet have authentication for the OVM_UpgradeExecutor.
  • Most pressing next steps I see:
    • Add integration test which interacts with/uses the new storage and code to make sure we're not just persisting these updates at the eth_getCode/eth_getStorageAt RPC level.
    • Add integration test for upgrading the EM (how to do this? Can I just upgrade to something with a constant return value? This would brick the chain but it's harder to validate/access a "different" EM whose version we can check)

@changeset-bot
Copy link

changeset-bot bot commented Apr 28, 2021

⚠️ No Changeset found

Latest commit: ae262be

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

)
override
external
onlyCallableBy(0x420000000000000000000000000000000000000A)
Copy link
Collaborator Author

@ben-chain ben-chain Apr 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think you forgot to finish the sentence :D chugsplash-ified -> what does this mean?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe better to refactor the address to a constant?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edited -- TLDR: it will be moved to storage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use storage in the execution manager? If not, I think we should just make it a constant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or an immutable.

@gakonst
Copy link
Contributor

gakonst commented Apr 29, 2021

Tests are failing due to the gas cost changing.

)
override
external
onlyCallableBy(0x420000000000000000000000000000000000000A)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use storage in the execution manager? If not, I think we should just make it a constant.

)
override
public
authenticated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maurelian Can you make a quick little issue for this? Think it should be dealt with in a separate PR.

_value
);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't there be some access control on each of these functions?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is just a placeholder for the sake of integration testing. I'll add a comment to make this clearer.

@smartcontracts
Copy link
Contributor

This PR is now the base of the v0.4.0 branch. I'm going to update #653 to point to that branch.

@smartcontracts
Copy link
Contributor

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.

@smartcontracts smartcontracts reopened this May 4, 2021
@smartcontracts smartcontracts changed the base branch from v0.3.0-rc to v0.4.0-rc May 4, 2021 18:09
@smartcontracts
Copy link
Contributor

As per conversation with @ben-chain, @snario, and @karlfloersch, we're going to reopen this PR and try to merge it into v0.4.0-rc.

}

// save the block number and address with modified key if it's not an eth_call
if evm.Context.EthCallSender == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ben-chain
Copy link
Collaborator Author

I have rebased and renamed this branch to reflect intended release version. Closing this one and will re-open there.

@ben-chain ben-chain closed this May 6, 2021
@ben-chain ben-chain deleted the v0.3.0-ovm_su branch May 6, 2021 19:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C-feature Category: features

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

Comments