Skip to content

feat: L2 Forked tests #14

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

Draft
wants to merge 8 commits into
base: sc-feat/l2-forked-test
Choose a base branch
from

Conversation

0xiamflux
Copy link

This document outlines the proposed design for an integrated L2 Forked Test suite and defines the scope of this integration.

@0xiamflux 0xiamflux self-assigned this Apr 11, 2025
@0xiamflux 0xiamflux requested review from hexshire and agusduha April 11, 2025 17:41

```solidity
interface NUTExecutor {
function execute(bytes calldata _calldata) external;

Choose a reason for hiding this comment

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

how is _calldata defined?
Do we expect that it might need to vary for different networks, or do we maybe not need it?


```solidity
contract Upgrader {
function upgrade(NUTExecutor[] memory _executors) external {

Choose a reason for hiding this comment

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

The idea here is that you can apply multiple upgrades, similar to how Forklive calls opcm.upgrade() on multiple OPCM versions?

Comment on lines +63 to +66
Once we have contracts that handle entire sets of NUTs, the transactions in the Go scripts can be replaced by two standard transactions:

1. Deploying the appropriate NUTExecutor contract for that particular upgrade
2. Calling the execute function on that contract

Choose a reason for hiding this comment

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

Where would the go scripts read the NUTExecutor bytecode from, the artifacts?


#### L2 `ProxyAdmin` Upgrade

It's possible to upgrade the L2 `ProxyAdmin` contract to allow limited delegated calls, enabling NUT scripts to execute within the `ProxyAdmin` context and perform contract upgrades. While this change would allow us to deploy new implementations and upgrade the proxies, configuration settings in these new implementations can be managed by verifying `tx.origin` rather than `msg.sender` as the Depositor Account. We consider this approach semantically correct as it still verifies that the Depositor Account is the originator of the transaction.

Choose a reason for hiding this comment

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

Hmmm, OK, I think I see what this is trying to solve.

With L1 upgrades, the ProxyAdmin owner is a Safe, so we can just delegate call the OPCM and have the upgrade logic run in the context of the ProxyAdmin owner, which results in most calls being made through the ProxyAdmin.

But on L2, NUTs have typically impersonated the zero address so that they can make upgrade calls directly to the Proxy contracts, and we don't have any way of making a delegatecall from the ProxyAdmin owner to the ProxyAdmin (do we?). It would be nice if we could have the NUTExecutor look and feel a lot like the OPCM, and maybe even reuse a lot of the underlying logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants