<aside> 👉

This document is written with details specific to Upgrade 16. For future upgrades it will be integrated into other documentation.

</aside>

The process of upgrading a chain built on the OP Stack presents a significant source of risk to the users and assets on that chain.

Therefore we must aim to minimize the need to trust any organization or individual providing inputs to be used in an upgrade. In particular here we are seeking to protect against the possibility of a malicious OPCM being used in an upgrade.

Fortunately, the blockchain industry has a well established pattern for minimizing trust, which is to enable anyone to verify the result of execution.

How to verify an upgrade

This document lays out the steps that must be taken, and the assumptions that must be made, in order for any person to conclude that an upgrade to an OP Stack chain will be successful.

Requirements

• The commit provided to governance has been audited for security.
• The scope of the audit includes the OPCM code and any changes to the VerifyOPCM script.

Verification process

The entire set of changes to an OP Chain which occur during an upgrade are defined by the following:

1. The calldata submitted to the OPContractsManager.
2. The address (and thus the bytecode and storage) of the OPContractsManager.

1. Verifying the calldata submitted to the OPContractsManager

The calldata submitted to the OPContractsManager’s upgrade() method contains 3 arguments.

1. ProxyAdminOwner
2. SystemConfig
3. PrestateHash

Note: that the potential consequences for an error in the calldata are relatively low compared to an error the logic of the OPCM. If either of the first two values are incorrect, the upgrade will simply fail because the ProxyAdminOwner must be authorized to upgrade the OPChain defined by the SystemConfig. If the Prestate Hash is incorrect then Dispute Games may resolve incorrectly, for which we have a well defined response plan.