xyyme.ethEIP-712 使用详解
之前的文章我们介绍过如何对数据进行签名，利用签名技术我们可以实现一些功能例如白名单校验等。但是这种签名技术的应用场景比较简单，一般就是给一串字符串，或者一串哈希签名，如果我们想为更复杂的数据签名就无法实现了。 EIP-712 的出现就是为了解决这个问题，利用 EIP-712，我们可以对更大的数据集，例如对结构体进行签名。那么这种签名格式有什么实际的应用场景呢。使用过 Uniswap，PancakeSwap 等 DEX 的朋友应该有印象，在移除 LP 流动性的时候，我们需要先签名，然后再发送一笔交易移除流动性。正常情况下，其实应该我们先调用 LP 代币的授权方法，授权 DEX 合约可以转移我们的 LP，然后再去移除流动性。而这种二合一的实现正是应用了 EIP-712。它帮助我们仅仅签名一次，就可以将两步交易合并为一步交易，从而节省 Gas 费用。这篇文章我们就来看看 EIP-712 到底是怎么使用的。基本结构EIP712Domain顾名思义，是一个与域相关的结构体，总共包含五个字段：name，合约或者协议的名称version，合约的版本chainId，合约部署的链 Id，一般使用 ...
xyyme.eth流动性挖矿-合约原理详解
流动性挖矿应该是上个牛市最火热的内容，基本上整个 DeFi 都是在围绕着流动性挖矿展开的，今天我们就来看看它到底是什么以及合约代码层面是怎么实现的。流动性挖矿简介首先我们先从用户的角度来理解一下流动性挖矿是什么，实际上就是用户通过在合约中质押一个 token 从而赚取另一个 token 的过程。例如，SushiSwap 最初推出的 DEX 流动性挖矿，用户可以通过将 SushiSwap 的 LP token 质押到合约中赚取 Sushi token。那么这个奖励具体是怎么发放以及如何实现的呢？我们今天就来研究一下这部分内容。 先来看几个例子： 一：假设有一个流动性挖矿的合约，可以质押 A token 赚取 B token。它在 0 秒时开始活动，每秒奖励 R 个 B token。此时有用户 Alice 在第 3 秒时质押了 2 个 A token，并且之后没有其他人参与，在第 8 秒时取出 token，图示：那么他在此时获得的收益就是：5R = (2 / 2) * (8 - 3) * R 其中，第一个 2 是用户 A 质押的数量，第二个 2 是合约中质押的总量，(8-3)是用户 ...
xyyme.ethCREATE2 操作码使用方法详解
CREATE2 是一个可以在合约中创建合约的操作码。我们先来举个例子看看它能干什么：这段代码是 Uniswap v2-core 里面的工厂合约代码，使用 create2 操作码创建了 pair 合约，返回值是 pair 的地址，这样就可以逻辑中直接使用其地址进行接下来的操作。 那么 create2 到底是怎么使用呢，根据官方 EIP 文档，create2 一共接收四个参数，分别是：endowment（创建合约时往合约中打的 ETH 数量）memory_start（代码在内存中的起始位置，一般固定为 add(bytecode, 0x20) ）memory_length（代码长度，一般固定为 mload(bytecode) ）salt（随机数盐）这里要注意的是第一个参数如果大于 0 的话，需要待部署合约的构造方法带有 payable。随机数盐是由用户自定，须为 bytes32 格式，例如在上面 Uniswap 的例子中，salt 为：bytes32 salt = keccak256(abi.encodePacked(token0, token1)); create2 还有一个优点，相...
Smart Contract Developer
我们继续来学习 LooksRare 的代码，上篇文章中我们学习了它的主合约 LooksRareExchange，这篇文章我们着重于其它的辅助合约，包括各种管理合约以及交易策略合约等。
上篇文章的最后，我们谈到了 NFT 的转账操作：
可以看到，需要先根据 NFT 地址获取相应的转账管理器，然后采用对应的管理器来进行转账。其内部的实现为：
这段代码中先查询该 NFT 有没有特定的转账管理器。如果没有，则利用 ERC165 规范，查询 NFT 合约实现了哪种规范（ERC721 或 ERC1155），然后使用对应的通用管理器。转账管理器本身的合约代码很简单，例如 ERC721 的转账代码为：
CurrencyManager，ExecutionManager 这两个管理器合约内容比较简单，包含基本的 add，remove，view 等方法，我们这里不再介绍。
该合约用于存储版税的相关信息，包括设置，读取等方法。
其中设置方法只能由 owner，即 RoyaltyFeeSetter 合约调用。
设置版税信息，可以理解为将上面的 RoyaltyFeeRegistry 合约包装了一层，这里是设置的入口。包含下面几个主要方法：
updateRoyaltyInfoForCollectionIfAdmin
updateRoyaltyInfoForCollectionIfOwner
updateRoyaltyInfoForCollectionIfSetter
updateRoyaltyInfoForCollection
_updateRoyaltyInfoForCollectionIfOwnerOrAdmin（内部方法，被上面的 IfAdmin 和 IfOwner 方法调用）
前四个方法均为设置版税功能，区别在于，前两个是由 NFT 的管理员设置，由于每个 NFT 合约的写法都不同，因此会区分 admin，owner 等角色。第三个方法是由前面设置版税时的 setter 设置。第四个是由 RoyaltyFeeSetter 合约本身的 owner 调用。最后一个内部方法调用上面的 registry 合约，进行设置操作。
我对这几个方法的理解是，如果 NFT 合约本身实现了 owner 或者 admin 方法，那么就有自主设置版税的权利。如果没有实现，可以找到系统管理员协助设置，此时同时会设置一个 setter 角色，以后 NFT 的版税就可以通过 setter 地址调用 updateRoyaltyInfoForCollectionIfSetter 来管理。系统更加推荐使用 setter 角色来管理版税。
我们来看看其中一个设置方法：
逻辑比较简单。要求只有 NFT 的 admin 可以调用。我们看到第一步要求 NFT 不能实现 ERC2981，奇怪了，ERC2981 不就是版税的标准呢，为什么不能实现这个接口呢，我们后面会解答这个问题。
该合约是最外层的接口，主合约在这里获取版税信息，只有一个主要方法：
我们看到，首先要检查系统中是否设置了该 NFT 的版税信息，如果没有设置，再去检查 NFT 本身是否包含版税信息。反过来想，如果合约本身就已经包含了版税信息，那么我们就没有必要在系统中设置。这也就解答了我们前面提出的问题：在 RoyaltyFeeSetter 合约中设置版税时，要求 NFT 合约本身不能实现 ERC2981。因为实现了 ERC2981 的合约，我们直接使用其自身的版税信息即可，不必再次设置。
接下来我们看看交易策略，LooksRare 合约库中一共包含 5 个交易策略，分别是：
StrategyStandardSaleForFixedPrice，标准固定价格交易
StrategyPrivateSale，卖家指定的买家才能购买
StrategyDutchAuction，荷兰拍卖
StrategyAnyItemFromCollectionForFixedPrice，买家出价购买一个 NFT 合集中任意一项。例如，买家想购买 BAYC，任意一个都可以
StrategyAnyItemInASetForFixedPrice，买家出价购买一个 NFT 合集中某些特定 tokenId 中任意一项。例如，买家只想购买蓝色背景的 BAYC
我们回想一下，在上篇文章中我们看到每个 match 成单方法都会调用策略的方法来校验该交易是否有效。例如：
我们先提前了解一点，每个策略中都有两个主要方法：
canExecuteTakerAsk，校验 taker 卖单与 maker 买单能否有效匹配
canExecuteTakerBid，校验 taker 买单与 maker 卖单能否有效匹配
接下来我们分别来介绍每个策略的代码，看看他们的具体实现。
最标准的买卖策略，固定价格，买单与卖单均指定 tokenId。
可以看到标准策略中需要校验 price、tokenId 是否匹配，并检查时间戳是否有效，逻辑比较简单。只要满足这些规则，就是符合标准策略。
当卖家指定由某位固定的买家购买时，使用该策略。
卖家指定买家，此时卖单挂单中会指定买家的地址，将其存放在 MakerOrder 的 params 字段。因为这个策略的执行只能由买家触发，所以 canExecuteTakerAsk 方法没有意义，需要返回 false。在下面的 canExecuteTakerBid 中，需要将卖家指定的买家地址从 params 中解析出来，然后进行校验，同时也要校验价格，tokenId，时间戳等信息。
荷兰拍卖，价格会不断下降，买家为主动方。
荷兰拍卖同样由买家触发，因此 taker 卖单没有意义，canExecuteTakerAsk 需要返回 false。在 canExecuteTakerBid 方法中，根据开始价格，结束价格，拍卖时常来计算当前实时价格，最后对参数进行校验。
买家购买合集中任意一项均可，因此为买家挂单。此时卖家为 taker 主动方，因此 canExecuteTakerBid 没有意义，返回 false。我们看到，在 canExecuteTakerAsk 中仅仅校验了价格与时间，没有 tokenId，这是为何呢？因为买家购买任意一款均可，那么就不用指定 tokenId，只要价格与时间等信息匹配，任意一款 tokenId 都可以，因此这里不用校验。
买家指定购买某些特定的 tokenId，此时买家挂单，卖家为 taker 主动方，因此 canExecuteTakerBid 没有意义，返回 false。canExecuteTakerAsk 中利用了 Merkle Tree 的技术，maker 买单中的 params 字段存储所有想要购买 tokenId 合集的 Merkle Root，taker 卖单中的 params 存储了该 tokenId 对应的 Proof。最后通过 verify 校验 taker 卖单中的 tokenId 是否匹配。
现在我们就已经介绍完了 LooksRare 的所有主要合约，是不是感觉还挺简单的。我个人认为 LooksRare 的文档和代码写得都比较简洁易懂，比较适合开发者来学习 NFT 市场的原理。希望大家能够结合代码库和我的文章，多理解几遍，必然会对自己的能力有一些提升。
欢迎和我交流
我们继续来学习 LooksRare 的代码，上篇文章中我们学习了它的主合约 LooksRareExchange，这篇文章我们着重于其它的辅助合约，包括各种管理合约以及交易策略合约等。
上篇文章的最后，我们谈到了 NFT 的转账操作：
可以看到，需要先根据 NFT 地址获取相应的转账管理器，然后采用对应的管理器来进行转账。其内部的实现为：
这段代码中先查询该 NFT 有没有特定的转账管理器。如果没有，则利用 ERC165 规范，查询 NFT 合约实现了哪种规范（ERC721 或 ERC1155），然后使用对应的通用管理器。转账管理器本身的合约代码很简单，例如 ERC721 的转账代码为：
CurrencyManager，ExecutionManager 这两个管理器合约内容比较简单，包含基本的 add，remove，view 等方法，我们这里不再介绍。
该合约用于存储版税的相关信息，包括设置，读取等方法。
其中设置方法只能由 owner，即 RoyaltyFeeSetter 合约调用。
设置版税信息，可以理解为将上面的 RoyaltyFeeRegistry 合约包装了一层，这里是设置的入口。包含下面几个主要方法：
updateRoyaltyInfoForCollectionIfAdmin
updateRoyaltyInfoForCollectionIfOwner
updateRoyaltyInfoForCollectionIfSetter
updateRoyaltyInfoForCollection
_updateRoyaltyInfoForCollectionIfOwnerOrAdmin（内部方法，被上面的 IfAdmin 和 IfOwner 方法调用）
前四个方法均为设置版税功能，区别在于，前两个是由 NFT 的管理员设置，由于每个 NFT 合约的写法都不同，因此会区分 admin，owner 等角色。第三个方法是由前面设置版税时的 setter 设置。第四个是由 RoyaltyFeeSetter 合约本身的 owner 调用。最后一个内部方法调用上面的 registry 合约，进行设置操作。
我对这几个方法的理解是，如果 NFT 合约本身实现了 owner 或者 admin 方法，那么就有自主设置版税的权利。如果没有实现，可以找到系统管理员协助设置，此时同时会设置一个 setter 角色，以后 NFT 的版税就可以通过 setter 地址调用 updateRoyaltyInfoForCollectionIfSetter 来管理。系统更加推荐使用 setter 角色来管理版税。
我们来看看其中一个设置方法：
逻辑比较简单。要求只有 NFT 的 admin 可以调用。我们看到第一步要求 NFT 不能实现 ERC2981，奇怪了，ERC2981 不就是版税的标准呢，为什么不能实现这个接口呢，我们后面会解答这个问题。
该合约是最外层的接口，主合约在这里获取版税信息，只有一个主要方法：
我们看到，首先要检查系统中是否设置了该 NFT 的版税信息，如果没有设置，再去检查 NFT 本身是否包含版税信息。反过来想，如果合约本身就已经包含了版税信息，那么我们就没有必要在系统中设置。这也就解答了我们前面提出的问题：在 RoyaltyFeeSetter 合约中设置版税时，要求 NFT 合约本身不能实现 ERC2981。因为实现了 ERC2981 的合约，我们直接使用其自身的版税信息即可，不必再次设置。
接下来我们看看交易策略，LooksRare 合约库中一共包含 5 个交易策略，分别是：
StrategyStandardSaleForFixedPrice，标准固定价格交易
StrategyPrivateSale，卖家指定的买家才能购买
StrategyDutchAuction，荷兰拍卖
StrategyAnyItemFromCollectionForFixedPrice，买家出价购买一个 NFT 合集中任意一项。例如，买家想购买 BAYC，任意一个都可以
StrategyAnyItemInASetForFixedPrice，买家出价购买一个 NFT 合集中某些特定 tokenId 中任意一项。例如，买家只想购买蓝色背景的 BAYC
我们回想一下，在上篇文章中我们看到每个 match 成单方法都会调用策略的方法来校验该交易是否有效。例如：
我们先提前了解一点，每个策略中都有两个主要方法：
canExecuteTakerAsk，校验 taker 卖单与 maker 买单能否有效匹配
canExecuteTakerBid，校验 taker 买单与 maker 卖单能否有效匹配
接下来我们分别来介绍每个策略的代码，看看他们的具体实现。
最标准的买卖策略，固定价格，买单与卖单均指定 tokenId。
可以看到标准策略中需要校验 price、tokenId 是否匹配，并检查时间戳是否有效，逻辑比较简单。只要满足这些规则，就是符合标准策略。
当卖家指定由某位固定的买家购买时，使用该策略。
卖家指定买家，此时卖单挂单中会指定买家的地址，将其存放在 MakerOrder 的 params 字段。因为这个策略的执行只能由买家触发，所以 canExecuteTakerAsk 方法没有意义，需要返回 false。在下面的 canExecuteTakerBid 中，需要将卖家指定的买家地址从 params 中解析出来，然后进行校验，同时也要校验价格，tokenId，时间戳等信息。
荷兰拍卖，价格会不断下降，买家为主动方。
荷兰拍卖同样由买家触发，因此 taker 卖单没有意义，canExecuteTakerAsk 需要返回 false。在 canExecuteTakerBid 方法中，根据开始价格，结束价格，拍卖时常来计算当前实时价格，最后对参数进行校验。
买家购买合集中任意一项均可，因此为买家挂单。此时卖家为 taker 主动方，因此 canExecuteTakerBid 没有意义，返回 false。我们看到，在 canExecuteTakerAsk 中仅仅校验了价格与时间，没有 tokenId，这是为何呢？因为买家购买任意一款均可，那么就不用指定 tokenId，只要价格与时间等信息匹配，任意一款 tokenId 都可以，因此这里不用校验。
买家指定购买某些特定的 tokenId，此时买家挂单，卖家为 taker 主动方，因此 canExecuteTakerBid 没有意义，返回 false。canExecuteTakerAsk 中利用了 Merkle Tree 的技术，maker 买单中的 params 字段存储所有想要购买 tokenId 合集的 Merkle Root，taker 卖单中的 params 存储了该 tokenId 对应的 Proof。最后通过 verify 校验 taker 卖单中的 tokenId 是否匹配。
现在我们就已经介绍完了 LooksRare 的所有主要合约，是不是感觉还挺简单的。我个人认为 LooksRare 的文档和代码写得都比较简洁易懂，比较适合开发者来学习 NFT 市场的原理。希望大家能够结合代码库和我的文章，多理解几遍，必然会对自己的能力有一些提升。
欢迎和我交流
xyyme.ethEIP-712 使用详解
之前的文章我们介绍过如何对数据进行签名，利用签名技术我们可以实现一些功能例如白名单校验等。但是这种签名技术的应用场景比较简单，一般就是给一串字符串，或者一串哈希签名，如果我们想为更复杂的数据签名就无法实现了。 EIP-712 的出现就是为了解决这个问题，利用 EIP-712，我们可以对更大的数据集，例如对结构体进行签名。那么这种签名格式有什么实际的应用场景呢。使用过 Uniswap，PancakeSwap 等 DEX 的朋友应该有印象，在移除 LP 流动性的时候，我们需要先签名，然后再发送一笔交易移除流动性。正常情况下，其实应该我们先调用 LP 代币的授权方法，授权 DEX 合约可以转移我们的 LP，然后再去移除流动性。而这种二合一的实现正是应用了 EIP-712。它帮助我们仅仅签名一次，就可以将两步交易合并为一步交易，从而节省 Gas 费用。这篇文章我们就来看看 EIP-712 到底是怎么使用的。基本结构EIP712Domain顾名思义，是一个与域相关的结构体，总共包含五个字段：name，合约或者协议的名称version，合约的版本chainId，合约部署的链 Id，一般使用 ...
xyyme.eth流动性挖矿-合约原理详解
流动性挖矿应该是上个牛市最火热的内容，基本上整个 DeFi 都是在围绕着流动性挖矿展开的，今天我们就来看看它到底是什么以及合约代码层面是怎么实现的。流动性挖矿简介首先我们先从用户的角度来理解一下流动性挖矿是什么，实际上就是用户通过在合约中质押一个 token 从而赚取另一个 token 的过程。例如，SushiSwap 最初推出的 DEX 流动性挖矿，用户可以通过将 SushiSwap 的 LP token 质押到合约中赚取 Sushi token。那么这个奖励具体是怎么发放以及如何实现的呢？我们今天就来研究一下这部分内容。 先来看几个例子： 一：假设有一个流动性挖矿的合约，可以质押 A token 赚取 B token。它在 0 秒时开始活动，每秒奖励 R 个 B token。此时有用户 Alice 在第 3 秒时质押了 2 个 A token，并且之后没有其他人参与，在第 8 秒时取出 token，图示：那么他在此时获得的收益就是：5R = (2 / 2) * (8 - 3) * R 其中，第一个 2 是用户 A 质押的数量，第二个 2 是合约中质押的总量，(8-3)是用户 ...
xyyme.ethCREATE2 操作码使用方法详解
CREATE2 是一个可以在合约中创建合约的操作码。我们先来举个例子看看它能干什么：这段代码是 Uniswap v2-core 里面的工厂合约代码，使用 create2 操作码创建了 pair 合约，返回值是 pair 的地址，这样就可以逻辑中直接使用其地址进行接下来的操作。 那么 create2 到底是怎么使用呢，根据官方 EIP 文档，create2 一共接收四个参数，分别是：endowment（创建合约时往合约中打的 ETH 数量）memory_start（代码在内存中的起始位置，一般固定为 add(bytecode, 0x20) ）memory_length（代码长度，一般固定为 mload(bytecode) ）salt（随机数盐）这里要注意的是第一个参数如果大于 0 的话，需要待部署合约的构造方法带有 payable。随机数盐是由用户自定，须为 bytes32 格式，例如在上面 Uniswap 的例子中，salt 为：bytes32 salt = keccak256(abi.encodePacked(token0, token1)); create2 还有一个优点，相...
Share Dialog
Share Dialog
Smart Contract Developer
Subscribe to xyyme.eth
Subscribe to xyyme.eth
<100 subscribers
<100 subscribers
No activity yet