概述
读者可前往我的博客获得更好的阅读体验。
本文主要介绍标准NFT实现的一个变体,即ERC721A
合约实现的相关细节。ERC721A
是由著名NFT系列Azuki提出,该系列NFT是著名的蓝筹NFT。本文主要聚焦于Azuki
提出的ERC721A
合约的代码细节分析。
与传统的ERC721
实现相比,ERC721A
在批量铸造(batch mint)方面具有显著的gas
优势,这得益于ERC721A
的惰性初始化方面的设计。关于ERC721A
与普通ERC721
实现的对比,我们将会在下文展开说明。
本文要求读者具有基础的solidity
知识,希望读者对标准ERC721
有所了解。
读者可在阅读本文前,酌情阅读以下参考材料:
ERC721A 官网ERC721A 官方仓库Azuki ERC721A 介绍
本文基于目前的最新版本(4.2.3
)合约代码进行分析。
ERC721实现
由于下文涉及到ERC721A
与ERC721
的技术对比,考虑到部分读者可以对ERC721
合约实现并不清楚,本节简要的介绍ERC721
正常实现的铸造功能,本节主要基于solmate的实现版本。
solmate
实现都较为短小精悍且经过gas
优化,我个人较为推崇。solmate
的ERC721
实现仅有 231 行,读者可自行阅读。
在solmate
合约中,我们可以看到核心数据结构为:
mapping(uint256 => address) internal _ownerOf;mapping(address => uint256) internal _balanceOf;
其中,各映射功能如下:
_ownerOf
记录 tokenId 与持有者的关系_balanceOf
记录持有人所持有的 NFT 数量
其铸造方法定义如下:
function _mint(address to, uint256 id) internal virtual {require(to != address(0), "INVALID_RECIPIENT");require(_ownerOf[id] == address(0), "ALREADY_MINTED");// Counter overflow is incredibly unrealistic.unchecked {_balanceOf[to]++;}_ownerOf[id] = to;emit Transfer(address(0), to, id);}
通过此函数,我们更新了_ownerOf
和_balanceOf
实现用户铸造 NFT 的功能。我们可以发现用户每次铸造NFT都需要更新_ownerOf
和_balanceOf
映射。众所周知,在操作码gas
消耗中,更新存储需要消耗大量gas
。如果用户批量铸造,会在此过程中消耗大量gas
。
根据数据(PDF警告),在ETH价格为 1500 美元时,更新存储的价格为 7.5 美元,而写入存储的价格为 30 美元。这意味着仅在
mint
过程中,更新映射会浪费大量资产。
转账函数定义如下:
function transferFrom(address from,address to,uint256 id) public virtual {require(from == _ownerOf[id], "WRONG_FROM");require(to != address(0), "INVALID_RECIPIENT");require(msg.sender == from || isApprovedForAll[from][msg.sender] || msg.sender == getApproved[id],"NOT_AUTHORIZED");// Underflow of the sender's balance is impossible because we check for// ownership above and the recipient's balance can't realistically overflow.unchecked {_balanceOf[from]--;_balanceOf[to]++;}_ownerOf[id] = to;delete getApproved[id];emit Transfer(from, to, id);}
由于对于每个tokenId
都维护有一个mapping
映射,所以转账逻辑实现也较为简单。
总体来看,对于每一个NFT,在solmate
实现的智能合约中,都维持有以下两个映射:
mapping(uint256 => address) internal _ownerOf;
标识NFT的拥有者mapping(uint256 => address) public getApproved;
记录NFT的授权情况
优势
在上一节中,我们介绍了常规NFT实现的基本情况,正如上文所述,常规实现在批量mint
铸造阶段会消耗大量gas
。为了解决这一问题,ERC721A
引入惰性初始化机制。简单来说,在批量铸造时,不再记录tokenId
与用户地址的映射关系,而是记录起始tokenId
和数量与用户的映射关系。在本节中,我们不对此实现的技术细节进行分析,我们会在本文稍后部分对此进行讨论。
在批量铸造阶段,ERC721A
与OpenZeppelin
实现的对比如下:
如果读者对于此处的
gas
计算的细节感兴趣,可以阅读以太坊机制详解:Gas Price计算。我们在此处不详细讨论计算方式。我们可以注意到铸造阶段的Base fee
较高,这考虑到了NFT铸造导致的网络拥堵情况。
显然,惰性初始化机制对于批量铸造阶段的gas
节省是具有明显优势的,但惰性加载将初始化的成本转移到了转账部分,我们可以看到在转移NFT时的成本有所上升。但需要注意,第一次转账后由于彻底完成了初始化,所有后续转账的成本会降低,如下:
通过表格可以看出,除第一次转账消耗的gas
明显增多,但随后转账的价格与常规的NFT转账并无区别。
总结来说,ERC721A
实现了低成本的批量铸造,但将部分成本转移到了第一次转账中。这种设计充分考虑到了铸造阶段可能出现的以太坊网络拥堵而造成gas
价格飙升的情况,而用户后期转账是偶发的且不会导致网络拥堵的。通过这种特殊的成本转嫁机制,ERC721A
降低用户的总成本。
换言之,如果您认为您的NFT项目不存在批量铸造的情况或不会导致以太坊网络拥堵,可以选择常规NFT实现。
具体实现
在讨论了ERC721A
的基本内容后,为进一步增加我们对ERC721A
的理解,我们将对其合约进行阅读分析。ERC721A
的开源仓库位于github。此处,我们仅讨论ERC721A
的主合约,而暂不讨论extensions
部分。
对于NFT合约的分析,存储数据结构和_mint
函数是一个很好的入手点。我们首先关注存储数据结构。
在NFT数据存储中,我们可以看到solmate
等常规实现都使用了mapping(uint256 => address) internal _ownerOf
将单个tokenId
与持有者对应。但ERC721A
是对批量铸造进行特殊优化的,开发者认为在批量铸造过程中,用户持有的NFT的tokenId
往往是连续的,如下图:
基本数据结构
在批量铸造过程中,用户铸造连续的NFT是极其常见的。为了实现连续分配tokenID
以降低gas
消耗的目的,我们需要一些更加复杂的数据结构设计,具体代码设计如下:
// The next token ID to be minted.uint256 private _currentIndex;// The number of tokens burned.uint256 private _burnCounter;// Token namestring private _name;// Token symbolstring private _symbol;// Mapping from token ID to ownership details// An empty struct value does not necessarily mean the token is unowned.// See {_packedOwnershipOf} implementation for details.//// Bits Layout:// - [0..159] `addr`// - [160..223] `startTimestamp`// - [224]`burned`// - [225]`nextInitialized`// - [232..255] `extraData`mapping(uint256 => uint256) private _packedOwnerships;// Mapping owner address to address data.//// Bits Layout:// - [0..63] `balance`// - [64..127] `numberMinted`// - [128..191] `numberBurned`// - [192..255] `aux`mapping(address => uint256) private _packedAddressData;// Mapping from token ID to approved address.mapping(uint256 => TokenApprovalRef) private _tokenApprovals;// Mapping from owner to operator approvalsmapping(address => mapping(address => bool)) private _operatorApprovals;
与其他简单参数相比,我们主要关注复杂的参数:
_packedOwnerships
类似常规NFT实现中的_ownerOf
,我们通过此映射查询某tokenID
的拥有者,但此结构是打包方式的,即我们并不指定每一个 tokenID 对应的拥有者而是仅记录开头_packedAddressData
类似常规NFT实现中的_balanceOf
,用于查询某一用户所拥有的NFT的相关数据。此处的aux
是指附加信息,比如用户当前使用的NFT铸造白名单数量,请根据自身项目酌情修改
此处,我们简单介绍数据读取的部分函数,关于在uint256
压缩数据结构内进行数据读取的具体方法,我们已在 深入解析AAVE智能合约:存款 介绍过类似的uint256
压缩数据提取方法。简单来说,就是使用&
操作的特性实现数据提取。我们给出balanceOf
的代码实现:
function balanceOf(address owner) public view virtual override returns (uint256) {if (owner == address(0)) _revert(BalanceQueryForZeroAddress.selector);return _packedAddressData[owner] & _BITMASK_ADDRESS_DATA_ENTRY;}
基于1 & 1 = 1
、0 & 1 = 0
和0 & 0 = 0
,我们可以通过将待提取位数(此处为0至63位置为 1 即可)。此处的_BITMASK_ADDRESS_DATA_ENTRY
与我们设想的类似:
uint256 private constant _BITMASK_ADDRESS_DATA_ENTRY = (1 << 64) - 1;
根据我们的设想,此处应填写
0xffffffffffffffff
(总计 16 个f
),正好为 0-63 位均为 1 。但ERC721A
开发者团队使用了位移方法表示,事实上是一致的
对于其他并不是从 0 开始的元素提取,我们需要使用位移以移除不必要数据,此处以提取numberMinted
为例进行分析:
function _numberMinted(address owner) internal view returns (uint256) {return (_packedAddressData[owner] >> _BITPOS_NUMBER_MINTED) & _BITMASK_ADDRESS_DATA_ENTRY;}
首先将数据右移 64 位(即_BITPOS_NUMBER_MINTED
)使balance
占用的数据因溢出而移除,而后使用&
操作符提取对应的数据,此处也需要提取 64 位数据,所以仍使用了_BITMASK_ADDRESS_DATA_ENTRY
对于其他数据的提取,我们不再赘述。
在数据写入函数方面,ERC721A 仅提供_setAux
函数,该函数的实现代码如下:
function _setAux(address owner, uint64 aux) internal virtual {uint256 packed = _packedAddressData[owner];uint256 auxCasted;// Cast `aux` with assembly to avoid redundant masking.assembly {auxCasted := aux}packed = (packed & _BITMASK_AUX_COMPLEMENT) | (auxCasted << _BITPOS_AUX);_packedAddressData[owner] = packed;}
首先我们将输入的aux
变量转化为uint256
类型,以方便后期处理。此后,我们将packed
与(1 << 192) - 1
进行&
操作,此步骤可以将aux
占用[192..255]
重置为 0 ,然后使用|
操作符向该区域内填入最新的aux
。
总结来说,我们可以通过与指定区域置为 1 的
mask
进行&
操作提取指定区域内的数据。另一方面,我们可以通过|
操作向置为 0 的区域写入数据。
铸造
基本函数
铸造使用了_mint
函数,其函数定义是:
function _mint(address to, uint256 quantity) internal virtual
该函数规定了以下参数:
to
铸造NFT接受地址quantity
铸造的NFT数量
由于
ERC721A
只能铸造固定数量的 NFT,所以无法指定铸造NFT的tokenID
其函数的运行逻辑简单如下:
运行_beforeTokenTransfers
,此函数应根据具体目的编写设置_packedOwnerships
,以方便查询NFT的拥有者设置_packedAddressData
,方便查询某一用户的所有NFT释放Transfer
事件运行_afterTokenTransfers
,此函数应根据具体目的编写
接下来,我们将结合代码进行分析。
最先运行的_beforeTokenTransfers
和最后运行的
_afterTokenTransfers
都是由用户自定义的函数,用于实现白名单等功能。函数具体定义如下:
function _beforeTokenTransfers(address from,address to,uint256 startTokenId,uint256 quantity) internal virtual {}function _afterTokenTransfers(address from,address to,uint256 startTokenId,uint256 quantity) internal virtual {}
读者可根据自身需求,通过继承覆盖的方式定义这两个函数。
接下来,我们设置一些核心数据,这些数据的设置是_mint
函数的核心。值得注意的是,这些函数都定义在unchecked
代码块中,因为 NFT 的各个参数设置不会产生溢出情况,通过unchecked
可以避免编译过程中插入溢出检查代码以减少 gas 消耗。
简而言之,在某些已经确定不会出现数据溢出的场景中使用
unchecked
包裹代码可以减少 gas 消耗
最开始,我们设置表示 NFT 所有者的_packOwnershipData
数据结构,具体设置方法如下:
_packedOwnerships[startTokenId] = _packOwnershipData(to,_nextInitializedFlag(quantity) | _nextExtraData(address(0), to, 0));
为方便读者理解代码,在此处,我们给出_packedOwnerships
的定义:
// Bits Layout:// - [0..159] `addr`// - [160..223] `startTimestamp`// - [224]`burned`// - [225]`nextInitialized`// - [232..255] `extraData`mapping(uint256 => uint256) private _packedOwnerships;
我们先对_packOwnershipData
函数的输入参数进行分析,需要解决_nextInitializedFlag
和_nextExtraData
的定义问题,
前者定义如下:
function _nextInitializedFlag(uint256 quantity) private pure returns (uint256 result) {// For branchless setting of the `nextInitialized` flag.assembly {// `(quantity == 1) << _BITPOS_NEXT_INITIALIZED`.result := shl(_BITPOS_NEXT_INITIALIZED, eq(quantity, 1))}}
显然,此函数用于设置nextInitialized
标识,如果铸造的数量为 1 ,我们将此标识置为 1 (即 True )。当然,我们也使用了位移操作使其处于合适的位置。
nextInitialized
是初始化的标识,如果此标识为True
则说明此 NFT 对应的地址已被初始化。如果此标识为False
(正如上文所见,单次铸造多于 1 个 NFT 就会使标识为False
),则意味着这段连续的 NFT 中除第一个外其他 NFT 均为初始化。如下图:[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DKMsV1oA-1675684640934)(https://files.catbox.moe/20sjdu.svg)]
后者定义如下:
function _nextExtraData(address from,address to,uint256 prevOwnershipPacked) private view returns (uint256) {uint24 extraData = uint24(prevOwnershipPacked >> _BITPOS_EXTRA_DATA);return uint256(_extraData(from, to, extraData)) << _BITPOS_EXTRA_DATA;}
此函数用于写入额外的信息,开发者需要自行定义_extraData
函数以实现相关数据的写入。
此过程的核心函数为_packOwnershipData
,其定义如下:
function _packOwnershipData(address owner, uint256 flags) private view returns (uint256 result) {assembly {// Mask `owner` to the lower 160 bits, in case the upper bits somehow aren't clean.owner := and(owner, _BITMASK_ADDRESS)// `owner | (block.timestamp << _BITPOS_START_TIMESTAMP) | flags`.result := or(owner, or(shl(_BITPOS_START_TIMESTAMP, timestamp()), flags))}}
有了上述_nextInitializedFlag
和_nextExtraData
的补充和注释,相信读者可以理解_packOwnershipData
的实现原理,简单来说,该函数使用or
操作符拼接owner
、timestamp
和flags
以实现最终的数据结构。显然,我们只需要构造以下部分作为flags
输入,即可完成_packOwnershipData
的构造:
// - [224]`burned`// - [225]`nextInitialized`// - [232..255] `extraData`
读者可以注意到
owner
、timestamp
和flags
均为uint256
数据类型,所以直接使用or
进行拼接是合适的
接下来设置_packedAddressData
数据结构。此数据结构定义如下:
// Bits Layout:// - [0..63] `balance`// - [64..127] `numberMinted`// - [128..191] `numberBurned`// - [192..255] `aux`mapping(address => uint256) private _packedAddressData;
mint
过程仅涉及balance
和numberMinted
两部分数据。所以设置较为简单,代码如下:
_packedAddressData[to] += quantity * ((1 << _BITPOS_NUMBER_MINTED) | 1);
我们使用((1 << _BITPOS_NUMBER_MINTED) | 1)
构造(此处_BITPOS_NUMBER_MINTED = 64
)出如下二进制数字 (以 16 进制表示):
0b10000001
使用 Python 运行
bin((64 << 1) | 1)
可以获得此结果
所以我们可以直接将数字与balance
和numberMinted
对齐相加。
在释放Transfer
事件前,我们需要对 NFT 接受方的地址进行简单校验,即保证 NFT 接受方的地址不为 0 地址,校验代码如下:
uint256 toMasked = uint256(uint160(to)) & _BITMASK_ADDRESS;if (toMasked == 0) _revert(MintToZeroAddress.selector);
此处进行了一个有趣的操作,将地址转化为uint256
后与0
进行比较。此处涉及address
与uint256
类型的转化。众所周知,address
类型事实上就是uint160
,两者可以直接转化。
如果读者对
address
类型不熟悉,可参考 文档
在直接转化后,为了避免直接转化导致的高位不为 0 的特殊情况出现,我们使用_BITMASK_ADDRESS
进行清理。此常量定义如下:
uint256 private constant _BITMASK_ADDRESS = (1 << 160) - 1;
通过使用此常量进行&
,我们可以保证address
与uint256
的安全转换。
此处我们没有深入讨论为什么
uint160
到uint256
的直接转化可能导致高位不为 0 的情况发生,读者可编写一简单合约编译后使用字节码研究此问题
释放Transfer
事件,此处我们可以一窥emit
背后的原理:
uint256 end = startTokenId + quantity;uint256 tokenId = startTokenId;do {assembly {// Emit the `Transfer` event.log4(0, // Start of data (0, since no data).0, // End of data (0, since no data)._TRANSFER_EVENT_SIGNATURE, // Signature.0, // `address(0)`.toMasked, // `to`.tokenId // `tokenId`.)}// The `!=` check ensures that large values of `quantity`// that overflows uint256 will make the loop run out of gas.} while (++tokenId != end);
常规实现中,Transfer
定义如下:
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
来自 EIP-721 标准 原文
我们可以看到此事件抛出了 3 个topic
,但事实上Transfer
作为事件名称也需要占用一个topic
,所以此处使用了log4
操作码。
此操作码需要的变量如下:
offset
抛出内容位于内存的起始位置size
抛出内容的长度(与offset
参数共同使用)topic1
抛出的的变量topic2
topic3
topic4
有读者好奇为什么存在
offset
和size
参数? 如果读者仔细阅读过 Events 部分的 Solidity 文档 就会理解这一问题。 文档中明确指出events
可以提供合约地址、 最多 4 个topic
和一些任意长度二进制数据。此处的offset
和size
参数就是指明任意长度的二进制数据的
在编写
solidity
代码时,假设存在event foo(uint256 _a, uint256 indexed _b)
定义,其中_a
会以二进制数据的形式抛出(即通过offset
和size
定义抛出),而_b
则以topic
的形式抛出。
至此,读者应该可以很好的理解log4
在代码中的具体功能。此处也使用了do while
循环以逐一抛出每个tokenId
的Transfer
事件。
补充函数
在ERC721A
的官方实现中,开发者提供了一些其他的mint
函数实现,这些实现的主体逻辑与_mint
类似,但提供了一些特别的功能或者符合一些特定的 ERC 标准。
我们首先分析_mintERC2309
函数,此函数根据 ERC 2309 标准编写。在介绍函数具体实现前,我们简单介绍一下ERC 2309
的具体内容。
ERC 2309
主要解决在大规模铸造和代币转账过程中释放过多event
的问题。如在标准_mint
函数实现中,我们在最后使用了while
循环以逐一释放事件。这显然是低效的,且无法用于大规模代币铸造。
为解决这一问题,ERC 2309
的开发者设计了一个新的事件:
event ConsecutiveTransfer(uint256 indexed fromTokenId, uint256 toTokenId, address indexed fromAddress, address indexed toAddress);
基于此事件,我们可以一次性释放所有代币转移的事件,大大降低了 gas 消耗。
对于_mintERC2309
具体实现,与_mint
基本一致,除了增加了以下代码:
ERC2309 最大转移量检查
if (quantity > _MAX_MINT_ERC2309_QUANTITY_LIMIT) _revert(MintERC2309QuantityExceedsLimit.selector);
用于判断单次转移量是否超过5000
ConsecutiveTransfer
事件抛出
emit ConsecutiveTransfer(startTokenId, startTokenId + quantity - 1, address(0), to);
由于使用了solidity
语法编写,所以此处也减少了大量安全性代码编写(如上文的address
到uint256
转化等)。
另一个实现mint
功能的函数是_safeMint
函数,此函数会判断 NFT 接收地址to
的属性,以避免 NFT 接受方不具有接受 NFT 的能力。
此部分逻辑代码如下:
unchecked {if (to.code.length != 0) {uint256 end = _currentIndex;uint256 index = end - quantity;do {if (!_checkContractOnERC721Received(address(0), to, index++, _data)) {_revert(TransferToNonERC721ReceiverImplementer.selector);}} while (index < end);// Reentrancy protection.if (_currentIndex != end) _revert(bytes4(0));}}
当接受方为一合约地址时,我们需要使用_checkContractOnERC721Received
函数判断接受方是否可以接受 NFT,此函数定义如下:
function _checkContractOnERC721Received(address from,address to,uint256 tokenId,bytes memory _data) private returns (bool) {try ERC721A__IERC721Receiver(to).onERC721Received(_msgSenderERC721A(), from, tokenId, _data) returns (bytes4 retval) {return retval == ERC721A__IERC721Receiver(to).onERC721Received.selector;} catch (bytes memory reason) {if (reason.length == 0) {_revert(TransferToNonERC721ReceiverImplementer.selector);}assembly {revert(add(32, reason), mload(reason))}}}
我们在 深入解析Safe多签钱包智能合约:Fallback合约 内已经对onERC721Received
的相关内容进行了分析,读者可自行阅读理解。此处,我们主要对try/catch
这一少见的solidity
关键词进行分析。
try
关键词后必须为一个外部函数调用,在此处为
ERC721A__IERC721Receiver(to).onERC721Received(_msgSenderERC721A(), from, tokenId, _data)
,即调用了外部ERC721A__IERC721Receiver
的onERC721Received
函数。return
会将外部调用的返回值封装为特定的函数名,此处为retval
。
如果外部调用和返回值封装没有出现错误,就会运行第一个语句块的语句,此处为
return retval == ERC721A__IERC721Receiver(to).onERC721Received.selector;
该语句块较为简单,不再具体分析。
catch
用来捕获错误,solidity
提供了以下catch
语句:
catch Error(string memory reason) { ... }
用于捕获revert("reasonString")
或require(false, "reasonString")
等语句造成的错误catch Panic(uint errorCode) { ... }
用于捕获panic
类型错误,如assert
、除以 0 等错误catch (bytes memory lowLevelData) { ... }
用于直接捕获底层错误信息,涵盖所有类型错误
在真实场景下,显然我们无法保证调用的合约使用
solidity
编写,所以使用最后一张catch
方法是有必要的。
显然,此处使用的是最后一种catch
语句。在捕获到底层错误后,我们首先使用if
语句判断此错误信息是否长度为0
,如果长度为 0 ,则意味着我们没有具体的错误信息,采取直接抛出TransferToNonERC721ReceiverImplementer.selector
的策略。
此处使用了_revert
函数,此函数是对revert
包装,定义如下:
function _revert(bytes4 errorSelector) internal pure {assembly {mstore(0x00, errorSelector)revert(0x00, 0x04)}}
此函数是对抛出errorSelector
错误信息的revert
的包装。读者应该可以理解此函数内部的yul
代码,较为简单。
如果错误信息reason
长度不为 0 ,我们则考虑抛出此信息。使用revert
抛出错误信息是一个好的选择。
可能有读者对
revert
操作码不熟悉,此操作码会抛出指定的错误信息、回滚当前状态并返还未使用的gas
费用。使用revert
操作码可以构建出稳赚不陪的偷跑(front-running
)机器人,可参考 Setting Bear Traps in the Dark Forest 。
revert(offset, size)
需要以下参数以抛出错误信息:
offset
错误信息在内存中的起始位置size
错误信息的长度
由于reason
属于bytes
类型,此类型属于array
,其在内存中的存在方式如下图:
+--------+--------+| length | .... |+--------+--------+| \_______/| lengthreason
reason
在内存中大致如上图。其在内存中的起始位置保存在reason
代表的数字中,然后32 bytes
是变量占据的内存长度,而后length
长度的内容为其真正存储的内容。
如果读者阅读过我之前的一系列关于智能合约的文章,相信可以理解这一内容。简单来说,在
solidity
内所有变量都是指向内存特定位置的指针。但由于数据类型的不同,其在内存中的结构也不相同,可以参考 solidity 文档
有了上述内容,我们可以理解revert(add(32, reason), mload(reason))
的具体含义。
我们使用add(32, reason)
跳过reason
的长度部分以其内容的起始部分作为offset
,使用mload(reason)
读取reason
的前32 bytes
,这正是reason
的长度信息。使用上述操作,可以保证revert
抛出的错误信息不包含长度内容。
至此,我们完成了_safeMint
的核心代码分析。
授权
授权,或称approve
是 NFT 的核心逻辑之一,也是 NFT 可组合性的基础之一。
_approve
实现approve
的核心函数为_approve
函数,其代码如下:
function _approve(address to,uint256 tokenId,bool approvalCheck) internal virtual {address owner = ownerOf(tokenId);if (approvalCheck && _msgSenderERC721A() != owner)if (!isApprovedForAll(owner, _msgSenderERC721A())) {_revert(ApprovalCallerNotOwnerNorApproved.selector);}_tokenApprovals[tokenId].value = to;emit Approval(owner, to, tokenId);}
其逻辑大致如下:
查询待授权 NFT 的所有者进行资格审查,判断函数调用者是否有权进行授权设置_tokenApprovals
映射,确定授权
在资格审查方面,要求函数调用者满足以下条件:
approvalCheck
为false
且函数调用者是 NFT 拥有者approvalCheck
为true
且函数调用者被授权控制 NFT 拥有者的所有NFT
首先分析ownerOf
函数,其定义如下:
function ownerOf(uint256 tokenId) public view virtual override returns (address) {return address(uint160(_packedOwnershipOf(tokenId)));}
显然,我们需要分析_packedOwnershipOf
的实现:
function _packedOwnershipOf(uint256 tokenId) private view returns (uint256 packed) {if (_startTokenId() <= tokenId) {packed = _packedOwnerships[tokenId];if (packed & _BITMASK_BURNED == 0) {if (packed == 0) {if (tokenId >= _currentIndex) _revert(OwnerQueryForNonexistentToken.selector);for (;;) {unchecked {packed = _packedOwnerships[--tokenId];}if (packed == 0) continue;return packed;}}return packed;}}_revert(OwnerQueryForNonexistentToken.selector);}
该函数的基本逻辑如下:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I4FT4MJs-1675684643092)(null)]
通过上述流程图,读者应该可以理解查询packed
的流程,其中的核心步骤是for
循环代码块内的回溯。正如在 mint 所说明的,_packedOwnerships
内仅存储startTokenId
,所以此处使用--tokenId
进行回溯查询。
此处使用了映射的性质,如果映射中的键不存在,那么返回的值为空。此处使用的
_packedOwnerships[tokenId]
会在tokenId
不存在时返回空值。
在理解_packedOwnershipOf
和ownerOf
的基础上,理解_approve
实现是容易的。
其他函数
本部分主要介绍关于approval
授权相关的其他函数,这些函数在是实现上都较为简单。
function setApprovalForAll(address operator, bool approved) public virtual override {_operatorApprovals[_msgSenderERC721A()][operator] = approved;emit ApprovalForAll(_msgSenderERC721A(), operator, approved);}
此处使用了_operatorApprovals
映射以实现将拥有者所有 NFT 同一授权为其他地址,映射定义如下:
mapping(address => mapping(address => bool)) private _operatorApprovals;
getApproved
函数用于确定某个 NFT 被授权地址,实现如下:
function getApproved(uint256 tokenId) public view virtual override returns (address) {if (!_exists(tokenId)) _revert(ApprovalQueryForNonexistentToken.selector);return _tokenApprovals[tokenId].value;}
在返回被授权者前,该函数使用了_exists
确定对应的 NFT 存在,_exists
实现如下:
function _exists(uint256 tokenId) internal view virtual returns (bool) {return_startTokenId() <= tokenId &&tokenId < _currentIndex && // If within bounds,_packedOwnerships[tokenId] & _BITMASK_BURNED == 0; // and not burned.}
配合注释,读者应该可以理解此函数的具体逻辑
转账
转账方面的基础函数为transferFrom
函数,其他所有转账函数都建立在此函数的基础上,该函数的逻辑设计如下:
使用_packedOwnershipOf
函数获得 NFT 持有者地址校验函数请求者是否是 NFT 拥有者或具有授权删除待转移 NFT 的授权修改_packedAddressData
映射增减balance
修改_packedOwnerships
映射释放转移事件
函数定义如下:
function transferFrom(address from,address to,uint256 tokenId) public payable virtual override
该函数的参数为:
from
待转移 NFT 的拥有者地址to
待转移 NFT 的接收者地址tokenId
待转移 NFT 的tokenId
根据上述流程,我们将逐个解析其中使用的函数。
uint256 prevOwnershipPacked = _packedOwnershipOf(tokenId);from = address(uint160(uint256(uint160(from)) & _BITMASK_ADDRESS));if (address(uint160(prevOwnershipPacked)) != from) _revert(TransferFromIncorrectOwner.selector);
通过_packedOwnershipOf
函数获得 NFT 拥有者地址,使用address(uint160(uint256(uint160(from)) & _BITMASK_ADDRESS))
进行数据类型转化。如果我们发现调用参数中的from
与 NFT 拥有者不同,则直接抛出错误。
接下来,我们使用以下代码校验 NFT 转移的相关权限问题:
(uint256 approvedAddressSlot, address approvedAddress) = _getApprovedSlotAndAddress(tokenId);if (!_isSenderApprovedOrOwner(approvedAddress, from, _msgSenderERC721A()))if (!isApprovedForAll(from, _msgSenderERC721A())) _revert(TransferCallerNotOwnerNorApproved.selector);
满足以下条件则继续运行:
函数调用者为 NFT 拥有者或被授权者 或 函数调用者存在isApprovedForAll
权限。
如果上述条件全不满足,则抛出异常。
该部分中最复杂的函数为_getApprovedSlotAndAddress
:
function _getApprovedSlotAndAddress(uint256 tokenId)privateviewreturns (uint256 approvedAddressSlot, address approvedAddress){TokenApprovalRef storage tokenApproval = _tokenApprovals[tokenId];assembly {approvedAddressSlot := tokenApproval.slotapprovedAddress := sload(approvedAddressSlot)}}
该函数会返回两个底层数据,即授权地址在storage
中的位置approvedAddressSlot
和授权地址的值approvedAddress
。
理解此代码需要对 EVM 的存储结构有一定了解,推荐阅读 Understanding Ethereum Smart Contract Storage
当函数调用者满足条件后,我们进入真正的 NFT 转移程序。首先清除待转移 NFT 的原有授权,代码如下:
assembly {if approvedAddress {sstore(approvedAddressSlot, 0)}}
直接将_tokenApprovals
中 NFT 对应的值清空。
接下来,我们进入了最复杂的 NFT 转移阶段,该阶段的逻辑大致如下:
修正转移双方的balance
参数
--_packedAddressData[from];++_packedAddressData[to];
更新tokenId
对应的_packedOwnerships
数据:
_packedOwnerships[tokenId] = _packOwnershipData(to,_BITMASK_NEXT_INITIALIZED | _nextExtraData(from, to, prevOwnershipPacked));
由于转移过程必须进行初始化,所以此处将转移的 NFT 的nextInitialized
设置为True
考虑下一个 NFT 是否被初始化,
如转移下图中tokenId = 3
的 NFT:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wKsxnwNP-1675684640935)(https://files.catbox.moe/20sjdu.svg)]
该 NFT 转移后,由于破坏了拥有者0x2
的连续性,所以我们需要重写tokenId = 4
的对应数据,代码如下:
if (prevOwnershipPacked & _BITMASK_NEXT_INITIALIZED == 0) {uint256 nextTokenId = tokenId + 1;if (_packedOwnerships[nextTokenId] == 0) {if (nextTokenId != _currentIndex) {_packedOwnerships[nextTokenId] = prevOwnershipPacked;}}
此处使用了_packedOwnerships[nextTokenId] == 0
排除了tokenId = 4
转移的特殊情况。该 NFT 位于连续 NFT 的末尾,转移此 NFT 不会破环连续性
至此,我们完成了 NFT 的转移的核心流程。接下来就是已经介绍过的Transfer
释放流程:
uint256 toMasked = uint256(uint160(to)) & _BITMASK_ADDRESS;assembly {// Emit the `Transfer` event.log4(0, // Start of data (0, since no data).0, // End of data (0, since no data)._TRANSFER_EVENT_SIGNATURE, // Signature.from, // `from`.toMasked, // `to`.tokenId // `tokenId`.)}if (toMasked == 0) _revert(TransferToZeroAddress.selector);
safeTransferFrom
作为transferFrom
的安全版本,该函数只是增加了_checkContractOnERC721Received
检测,此检测函数已在上文进行了介绍,此处不再赘述。
销毁
burn
销毁的核心函数为_burn
函数,由于销毁事实上相当于将 NFT 转移给 0 地址,所以其大量逻辑与transfer
类似。
_burn
函数定义如下:
function _burn(uint256 tokenId, bool approvalCheck) internal virtual
参数含义如下:
tokenId
待销毁 NFT 的tokenId
approvalCheck
是否检测函数调用者的权限
大致流程如下:
获取待销毁 NFT 拥有者的信息如果设置approvalCheck
为true
则检测函数调用者的相关权限清空待销毁 NFT 的授权approve
数据减少拥有者的balance
在_packedOwnerships
中写入销毁信息恢复代币连续性释放事件
接下来,我们详细分析具体的代码实现:
uint256 prevOwnershipPacked = _packedOwnershipOf(tokenId);address from = address(uint160(prevOwnershipPacked));(uint256 approvedAddressSlot, address approvedAddress) = _getApprovedSlotAndAddress(tokenId);
此处代码与transferFrom
函数的开始部分基本一致,但在from
处理方面进行了简化。
接下来,我们检查调用者的相关权限并清空授权,代码如下:
if (approvalCheck) {if (!_isSenderApprovedOrOwner(approvedAddress, from, _msgSenderERC721A()))if (!isApprovedForAll(from, _msgSenderERC721A())) _revert(TransferCallerNotOwnerNorApproved.selector);}assembly {if approvedAddress {// This is equivalent to `delete _tokenApprovals[tokenId]`.sstore(approvedAddressSlot, 0)}}
此部分代码与transferFrom
函数完全一致,不再详细介绍。
_packedAddressData[from] += (1 << _BITPOS_NUMBER_BURNED) - 1;_packedOwnerships[tokenId] = _packOwnershipData(from,(_BITMASK_BURNED | _BITMASK_NEXT_INITIALIZED) | _nextExtraData(from, address(0), prevOwnershipPacked));
此处使用_packedAddressData[from] += (1 << _BITPOS_NUMBER_BURNED) - 1;
代码将balance -= 1
和numberBurned += 1
合并一起执行。
其中_BITPOS_NUMBER_BURNED
的值为 128,为方便读者理解,我们再次给出_packedAddressData
的格式:
// Bits Layout:// - [0..63] `balance`// - [64..127] `numberMinted`// - [128..191] `numberBurned`// - [192..255] `aux`mapping(address => uint256) private _packedAddressData;
为方便理解,我们将原有代码进行重写:
_packedAddressData[from] = _packedAddressData[from] + (1 << 128) - 1
如此来看,我们首先使用加法完成了numberBurned
的更新,然后使用减法完成了balance
的更新。
对于_packOwnershipData
函数,最重要的是分析以下部分:
(_BITMASK_BURNED | _BITMASK_NEXT_INITIALIZED) | _nextExtraData(from, address(0), prevOwnershipPacked)
我们将burned
和_BITMASK_NEXT_INITIALIZED
置为True
并写入extraData
部分。
最后我们还是讨论连续性问题,假如当前的代币拥有如下图:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Fvkc8I16-1675684640935)(https://files.catbox.moe/20sjdu.svg)]
我们将tokenId = 3
的代币销毁,那么我们需要修正tokenId = 4
的 NFT 以避免 NFT 丢失。这部分代码与transferFrom
是一致的,实现如下:
if (prevOwnershipPacked & _BITMASK_NEXT_INITIALIZED == 0) {uint256 nextTokenId = tokenId + 1;if (_packedOwnerships[nextTokenId] == 0) {if (nextTokenId != _currentIndex) {_packedOwnerships[nextTokenId] = prevOwnershipPacked;}}}
简单来说,我们只需要将tokenId = 2
的数据放入tokenId = 4
的 NFT 中即可。
对于释放事件,使用了emit Transfer(from, address(0), tokenId);
语句,较为简单。
有读者可能发现为什么在
ERC721A
内的编码风格并不统一,有使用底层log4
释放事件的,有使用emit
释放事件的。这可能是我没有使用Realse
版本的代码而是直接clone
了开发中的代码。
总结
在本文中,我们分析了ERC721A
合约的主体逻辑,但仍存在部分代码没有分析。这些代码实现都较为简单,故不再本文继续介绍。
总体而言,ERC721A
通过对连续 NFT 的合并处理大幅度降低了 NFT 批量铸造的 gas 消耗。