MyGit

v5.0.0

OpenZeppelin/openzeppelin-contracts

版本发布时间: 2023-10-06 02:00:59

OpenZeppelin/openzeppelin-contracts最新发布版本:v5.1.0-rc.0(2024-10-03 22:56:46)

Additions Summary

The following contracts and libraries were added:

Removals Summary

The following contracts, libraries, and functions were removed:

These removals were implemented in the following PRs: #3637, #3880, #3945, #4258, #4276, #4289

Changes by category

General

Access

Finance

Governance

Metatx

Proxy

Token

Utils

How to migrate from 4.x

ERC20, ERC721, and ERC1155

These breaking changes will require modifications to ERC20, ERC721, and ERC1155 contracts, since the _afterTokenTransfer and _beforeTokenTransfer functions were removed. Thus, any customization made through those hooks should now be done overriding the new _update function instead.

Minting and burning are implemented by _update and customizations should be done by overriding this function as well. _transfer, _mint and _burn are no longer virtual (meaning they are not overridable) to guard against possible inconsistencies.

For example, a contract using ERC20's _beforeTokenTransfer hook would have to be changed in the following way.

-function _beforeTokenTransfer(
+function _update(
   address from,
   address to,
   uint256 amount
 ) internal virtual override {
-  super._beforeTokenTransfer(from, to, amount);
   require(!condition(), "ERC20: wrong condition");
+  super._update(from, to, amount);
 }

More about ERC721

In the case of ERC721, the _update function does not include a from parameter, as the sender is implicitly the previous owner of the tokenId. The address of this previous owner is returned by the _update function, so it can be used for a posteriori checks. In addition to to and tokenId, a third parameter (auth) is present in this function. This parameter enabled an optional check that the caller/spender is approved to do the transfer. This check cannot be performed after the transfer (because the transfer resets the approval), and doing it before _update would require a duplicate call to _ownerOf.

In this logic of removing hidden SLOADs, the _isApprovedOrOwner function was removed in favor of a new _isAuthorized function. Overrides that used to target the _isApprovedOrOwner should now be performed on the _isAuthorized function. Calls to _isApprovedOrOwner that preceded a call to _transfer, _burn or _approve should be removed in favor of using the auth argument in _update and _approve. This is showcased in ERC721Burnable.burn and in ERC721Wrapper.withdrawTo.

The _exists function was removed. Calls to this function can be replaced by _ownerOf(tokenId) != address(0).

ERC165Storage

Users that were registering EIP-165 interfaces with _registerInterface from ERC165Storage should instead do so so by overriding the supportsInterface function as seen below:

function supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {
  return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId);
}

Adapting Governor modules

Custom Governor modules that override internal functions may require modifications if migrated to v5. In particular, the new internal functions _queueOperations and _executeOperations may need to be used. If assistance with this migration is needed reach out via the OpenZeppelin Support Forum.

ECDSA and MessageHashUtils

The ECDSA library is now focused on signer recovery. Previously it also included utility methods for producing digests to be used with signing or recovery. These utilities have been moved to the MessageHashUtils library and should be imported if needed:

 import {ECDSA} from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
+import {MessageHashUtils} from "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";

 contract Verifier {
   using ECDSA for bytes32;
+  using MessageHashUtils for bytes32;
 
   function _verify(bytes32 data, bytes memory signature, address account) internal pure returns (bool) {
     return data
       .toEthSignedMessageHash()
       .recover(signature) == account;
   }
 }

Interfaces and libraries in upgradeable contracts

The upgradeable version of the contracts library used to include a variant suffixed with Upgradeable for every contract. These variants, which are produced automatically, mainly include changes for dealing with storage that don't apply to libraries and interfaces.

The upgradeable library no longer includes upgradeable variants for libraries and interfaces. Projects migrating to 5.0 should replace their library and interface imports with their corresponding non-upgradeable version:

 // Libraries
-import {AddressUpgradeable} from '@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol';
+import {Address} from '@openzeppelin/contracts/utils/Address.sol';

 // Interfaces
-import {IERC20Upgradeable} from '@openzeppelin/contracts-upgradeable/interfaces/IERC20.sol';
+import {IERC20} from '@openzeppelin/contracts/interfaces/IERC20.sol';

Offchain Considerations

Some changes may affect offchain systems if they rely on assumptions that are changed along with these new breaking changes. These cases are:

Relying on revert strings for processing errors

A concrete example is AccessControl, where it was previously advised to catch revert reasons using the following regex:

/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/

Instead, contracts now revert with custom errors. Systems that interact with smart contracts outside of the network should consider reliance on revert strings and possibly support the new custom errors.

Relying on storage locations for retrieving data

After 5.0, the storage location of some variables were changed. This is the case for Initializable and all the upgradeable contracts since they now use namespaced storaged locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.

相关地址：原始地址 下载(tar) 下载(zip)

查看：2023-10-06发行的版本

微信小程序
MyGit:GitHub仓库更新&通知小工具