Chore: created a diff of the zkSync contract changes #593
Conversation
| if (setUpgradePermission) { | ||
| bytes32 tokenUpgradePermission = GovernanceERC20Upgradeable(token) | ||
| .UPGRADE_GOVERNANCE_ERC20_PERMISSION_ID(); | ||
| permissions[permissions.length - 1] = PermissionLib.MultiTargetPermission( |
There was a problem hiding this comment.
Please think carefully about this: I believe the UPGRADE permission will always be the final permission in the array if it is needed, but we won't know if it is at index 4 or 5 at compile time. This depends on the token being address(0) or not.
Can this break? Can this be exploited?
| /// @author Aragon Association | ||
| /// @notice An [OpenZeppelin `Votes`](https://docs.openzeppelin.com/contracts/4.x/api/governance#Votes) compatible [ERC-20](https://eips.ethereum.org/EIPS/eip-20) token that can be used for voting and is managed by a DAO. | ||
| contract GovernanceERC20 is | ||
| contract GovernanceERC20Upgradeable is |
There was a problem hiding this comment.
Upgradeable tokens are a red flag. External parties could use official Aragon OSx tokens on zkSync to rugpull consumers.
To add to this, they are often not permitted on exchanges - are we 100% sure that this is acceptable in the case of zkSync Era?
Please rethink this and confirm this decision with leadership @Rekard0.
| /// @author Aragon Association | ||
| /// @notice Wraps an existing [ERC-20](https://eips.ethereum.org/EIPS/eip-20) token by inheriting from `ERC20WrapperUpgradeable` and allows to use it for voting by inheriting from `ERC20VotesUpgradeable`. The latter is compatible with [OpenZeppelin's `Votes`](https://docs.openzeppelin.com/contracts/4.x/api/governance#Votes) interface. | ||
| /// The contract also supports meta transactions. To use an `amount` of underlying tokens for voting, the token owner has to | ||
| /// 1. call `approve` for the tokens to be used by this contract | ||
| /// 2. call `depositFor` to wrap them, which safely transfers the underlying [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens to the contract and mints wrapped [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens. | ||
| /// To get the [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens back, the owner of the wrapped tokens can call `withdrawFor`, which burns the wrapped [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens and safely transfers the underlying tokens back to the owner. | ||
| /// @dev This contract intentionally has no public mint functionality because this is the responsibility of the underlying [ERC-20](https://eips.ethereum.org/EIPS/eip-20) token contract. | ||
| contract GovernanceWrappedERC20 is | ||
| contract GovernanceWrappedERC20Upgradeable is |
| /// @title PluginSetupProcessor | ||
| /// @author Aragon Association - 2022-2023 | ||
| /// @notice This contract processes the preparation and application of plugin setups (installation, update, uninstallation) on behalf of a requesting DAO. | ||
| /// @dev This contract is temporarily granted the `ROOT_PERMISSION_ID` permission on the applying DAO and therefore is highly security critical. | ||
| contract PluginSetupProcessor { | ||
| contract PluginSetupProcessorUpgradeable is UUPSUpgradeable, DaoAuthorizableUpgradeable { |
There was a problem hiding this comment.
Is this acceptable? The PSP gets ROOT_PERMISSION_ID temporarily during each setup application.
What's happening in case the PSP gets compromised? What are the worst-case implications for DAOs? I would like to see an analysis here.
| { | ||
| /// @notice The ID of the permission required to call the `_authorizeUpgrade` function. | ||
| bytes32 public constant UPGRADE_GOVERNANCE_ERC20_PERMISSION_ID = | ||
| keccak256("UPGRADE_GOVERNANCE_ERC20_PERMISSION"); |
There was a problem hiding this comment.
Should we change the permission string so it will have a diffrent hash compared to the GovernanceERC20 permission, or this is done on purpose?
There was a problem hiding this comment.
These need to be standardized as part of the setup workflow: we grant the same permission regardless of whether we deploy a wrapped token
| @@ -117,4 +123,10 @@ contract GovernanceERC20 is | |||
| _delegate(to, to); | |||
| } | |||
| } | |||
|
|
|||
| /// @notice Internal method authorizing the upgrade of the contract via the [upgradeability mechanism for UUPS proxies](https://docs.openzeppelin.com/contracts/4.x/api/proxy#UUPSUpgradeable) (see [ERC-1822](https://eips.ethereum.org/EIPS/eip-1822)). | |||
| /// @dev The caller must have the `UPGRADE_DAO_PERMISSION_ID` permission. | |||
There was a problem hiding this comment.
| /// @dev The caller must have the `UPGRADE_DAO_PERMISSION_ID` permission. | |
| /// @dev The caller must have the `UPGRADE_GOVERNANCE_ERC20_PERMISSION_ID ` permission. |
There was a problem hiding this comment.
@novaknole good suggestion
| @@ -123,4 +135,10 @@ contract GovernanceWrappedERC20 is | |||
| ) internal override(ERC20VotesUpgradeable, ERC20Upgradeable) { | |||
| super._burn(account, amount); | |||
| } | |||
|
|
|||
| /// @notice Internal method authorizing the upgrade of the contract via the [upgradeability mechanism for UUPS proxies](https://docs.openzeppelin.com/contracts/4.x/api/proxy#UUPSUpgradeable) (see [ERC-1822](https://eips.ethereum.org/EIPS/eip-1822)). | |||
| /// @dev The caller must have the `UPGRADE_DAO_PERMISSION_ID` permission. | |||
There was a problem hiding this comment.
| /// @dev The caller must have the `UPGRADE_DAO_PERMISSION_ID` permission. | |
| /// @dev The caller must have the `UPGRADE_GOVERNANCE_ERC20_PERMISSION_ID ` permission. |
There was a problem hiding this comment.
the same happens on the other contracts' comment on the same func
Description
Task ID: OS-?
Type of change
See the framework lifecycle in
packages/contracts/docs/framework-lifecycleto decide what kind of change this pull request is.Checklist:
CHANGELOG.mdfile in the root folder.DEPLOYMENT_CHECKLISTfile in the root folder.UPDATE_CHECKLISTfile in the root folder.