Need for Renaming and Reconsideration of verifyContractUpgrade Function due to its State-Altering Behavior

[waterflier]

The implementation of the verifyContractUpgrade function does more than just "verify state"—it actually alters the state. Should we consider renaming and/or adjusting this function to better align with its behavior?

Given the function's current implementation, I am concerned that an approved proposal (especially considering that proposals do not record old implementation addresses) could potentially be repeatedly verified and used to execute upgrade operations.

[weiqiushi]

Actually, verifyContractUpgrade can only be called by the contract to be upgraded, and the upgrade logic ensures that a proposal will only be "verified" once.

If a non-contract address calls verifyContractUpgrade, it will only get a "not found upgrade proposal" reject.

For the contract, its purpose is to verify that the upgrade is executable, the contract doesn't care what the function does internally, I think the naming indicates what the function can do from the user's point of view.

This function also does not have the problem of repeatedly validation, since it cannot provide a proposal id that has already been approved.