From f47c082a92430c7085566c1a7ec1f9c5e22f4b88 Mon Sep 17 00:00:00 2001 From: blockchaindevsh Date: Sat, 3 Aug 2024 17:48:47 +0800 Subject: [PATCH] update upgrade section --- specs/experimental/inbox-contract.md | 52 ++++++++++++++++++++++++++-- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git a/specs/experimental/inbox-contract.md b/specs/experimental/inbox-contract.md index ccc4ec09f..d01a9bddf 100644 --- a/specs/experimental/inbox-contract.md +++ b/specs/experimental/inbox-contract.md @@ -18,6 +18,9 @@ - [How `op-node` knows the canonical batch inbox](#how-op-node-knows-the-canonical-batch-inbox) - [How `op-batcher` knows canonical batch inbox](#how-op-batcher-knows-canonical-batch-inbox) - [Upgrade](#upgrade) + - [L1Block Deployment](#l1block-deployment) + - [L1Block Proxy Update](#l1block-proxy-update) + - [SystemConfig Upgrade](#systemconfig-upgrade) - [Security Considerations](#security-considerations) - [Inbox Sender](#inbox-sender) - [Reference Implementation](#reference-implementation) @@ -243,9 +246,52 @@ Immediately before submitting a new batch, `op-batcher` fetches the current inbo ## Upgrade -To use this feature, existing OP Stack instances must complete two steps: -1. Upgrade the `SystemConfig` and set an inbox contract on L1. -2. Upgrade the `L1Block` on L2. +The custom gas token upgrade is not yet defined to be part of a particular network upgrade, but it will be scheduled as part of a future hardfork. On the network upgrade block, a set of deposit transaction based upgrade transactions are deterministically generated by the derivation pipeline in the following order: + +- L1 Attributes Transaction calling `setL1BlockValuesEcotone` +- User deposits from L1 +- Network Upgrade Transactions + - L1Block deployment + - Update L1Block Proxy ERC-1967 Implementation Slot + +The deployment transactions MUST have a `from` value that has no code and has no known +private key. This is to guarantee it cannot be frontran and have its nonce modified. +If this was possible, then an attacker would be able to modify the address that the +implementation is deployed to because it is based on `CREATE` and not `CREATE2`. +This would then cause the proxy implementation set transactions to set an incorrect +implementation address, resulting in a bricked contract. The calldata is not generated +dynamically to enable deterministic upgrade transactions across all networks. + +The proxy upgrade transactions are from `address(0)` because the `Proxy` implementation +considers `address(0)` to be an admin. Going straight to the `Proxy` guarantees that +the upgrade will work because there is no guarantee that the `Proxy` is owned by the +`ProxyAdmin` and going through the `ProxyAdmin` would require stealing the identity +of its owner, which may be different on every chain. That would require adding L2 +RPC access to the derivation pipeline and make the upgrade transactions non deterministic. + +### L1Block Deployment + +- `from`: `0x4210000000000000000000000000000000000002` +- `to`: `null` +- `mint`: `0` +- `value`: `0` +- `gasLimit`: TODO +- `data`: TODO +- `sourceHash`: TODO + +### L1Block Proxy Update + +- `from`: `0x0000000000000000000000000000000000000000` +- `to`: `0x4200000000000000000000000000000000000015` +- `mint`: `0` +- `value`: `0` +- `gasLimit`: `50,000` +- `data`: TODO +- `sourceHash`: TODO + +### SystemConfig Upgrade + +Finally, upgrade the `SystemConfig` and set an inbox contract on L1. Note that according to the [Optimism Style Guide](https://github.com/ethereum-optimism/optimism/blob/9d31040ecf8590423adf267ad24b03bc1bf7273b/packages/contracts-bedrock/STYLE_GUIDE.md), The process for upgrading the implementation is as follows: 1. Upgrade the implementation to the `StorageSetter` contract.