EIP-712 使用详解
之前的文章我们介绍过如何对数据进行签名,利用签名技术我们可以实现一些功能例如白名单校验等。但是这种签名技术的应用场景比较简单,一般就是给一串字符串,或者一串哈希签名,如果我们想为更复杂的数据签名就无法实现了。 EIP-712 的出现就是为了解决这个问题,利用 EIP-712,我们可以对更大的数据集,例如对结构体进行签名。那么这种签名格式有什么实际的应用场景呢。使用过 Uniswap,PancakeSwap 等 DEX 的朋友应该有印象,在移除 LP 流动性的时候,我们需要先签名,然后再发送一笔交易移除流动性。正常情况下,其实应该我们先调用 LP 代币的授权方法,授权 DEX 合约可以转移我们的 LP,然后再去移除流动性。而这种二合一的实现正是应用了 EIP-712。它帮助我们仅仅签名一次,就可以将两步交易合并为一步交易,从而节省 Gas 费用。这篇文章我们就来看看 EIP-712 到底是怎么使用的。基本结构EIP712Domain顾名思义,是一个与域相关的结构体,总共包含五个字段:name,合约或者协议的名称version,合约的版本chainId,合约部署的链 Id,一般使用 ...
流动性挖矿-合约原理详解
流动性挖矿应该是上个牛市最火热的内容,基本上整个 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)是用户 ...
CREATE2 操作码使用方法详解
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
EIP-712 使用详解
之前的文章我们介绍过如何对数据进行签名,利用签名技术我们可以实现一些功能例如白名单校验等。但是这种签名技术的应用场景比较简单,一般就是给一串字符串,或者一串哈希签名,如果我们想为更复杂的数据签名就无法实现了。 EIP-712 的出现就是为了解决这个问题,利用 EIP-712,我们可以对更大的数据集,例如对结构体进行签名。那么这种签名格式有什么实际的应用场景呢。使用过 Uniswap,PancakeSwap 等 DEX 的朋友应该有印象,在移除 LP 流动性的时候,我们需要先签名,然后再发送一笔交易移除流动性。正常情况下,其实应该我们先调用 LP 代币的授权方法,授权 DEX 合约可以转移我们的 LP,然后再去移除流动性。而这种二合一的实现正是应用了 EIP-712。它帮助我们仅仅签名一次,就可以将两步交易合并为一步交易,从而节省 Gas 费用。这篇文章我们就来看看 EIP-712 到底是怎么使用的。基本结构EIP712Domain顾名思义,是一个与域相关的结构体,总共包含五个字段:name,合约或者协议的名称version,合约的版本chainId,合约部署的链 Id,一般使用 ...
流动性挖矿-合约原理详解
流动性挖矿应该是上个牛市最火热的内容,基本上整个 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)是用户 ...
CREATE2 操作码使用方法详解
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

Subscribe to xyyme.eth

Subscribe to xyyme.eth
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
今天在推特上看到好多人都在说一个新的标准叫 ERC721R,可以给用户退款,防止 rug。抽了点时间看了看,其实代码也很简单,简单写篇文章介绍一下(官网,GitHub)。
现在有好多项目方,发完图捞一笔之后就跑路了,而参与 mint 的用户都成了接盘侠。ERC721R 的目的就是让用户可以在 mint 之后的一段时间内,有后悔药吃,可以用 mint 到的 NFT 以原价换回自己的币。这对于用户来说是一个很好的规则。来看看官方文档对于自己的优点说明:
对于买家来说:
购买风险低(最差的情况也可以换回自己的币)
防止 rug pull
强迫项目方能够好好做事
对于项目方来说:
能够在消费者心中建立对自己的信心
对于两者都有的有点:
当处于退款期间时,项目的地板价不会低于 mint 的价格(因为可以反向刚兑)
短期炒作者会早早离开项目,便于项目长期发展
数据结构:
// 退款时间区间
uint256 public constant refundPeriod;
// 退款结束时间
uint256 public refundEndTime;
// 退款接收地址
address public refundAddress;
合约函数:
当用户在退款期内想要退款时,可以调用 refund 函数,传入想要退款的 tokenId 列表,就可以将 NFT 换成币。

管理员在退款期内,不能转出币(以实现用户可以刚兑)。到期后可以转出。

ERC721R 的代码还是很简单的,只是加了几个字段和对应的函数。虽然我个人觉得可能没啥用处,但是毕竟也是一个技术创新,值得支持。
这个合约有一个 bug,就是 refundAddress 可以用一个 tokenId 无限次退款,把钱都给套出来。这个 bug 我开始写文章的时候没有注意,后面看到了崔棉大师的推特,发现确实是这样。
目前我想到的解决方法有两种:
退款的时候直接将对应的 tokenId burn 掉
建立一个 mapping(tokenId => 是否退款 bool),来限制一个 tokenId 只能退款一次
这两种方法的目的都是限制一个 tokenId 只能退款一次。
不过当你看到这篇文章的时候,可能 bug 已经被修复了~
今天在推特上看到好多人都在说一个新的标准叫 ERC721R,可以给用户退款,防止 rug。抽了点时间看了看,其实代码也很简单,简单写篇文章介绍一下(官网,GitHub)。
现在有好多项目方,发完图捞一笔之后就跑路了,而参与 mint 的用户都成了接盘侠。ERC721R 的目的就是让用户可以在 mint 之后的一段时间内,有后悔药吃,可以用 mint 到的 NFT 以原价换回自己的币。这对于用户来说是一个很好的规则。来看看官方文档对于自己的优点说明:
对于买家来说:
购买风险低(最差的情况也可以换回自己的币)
防止 rug pull
强迫项目方能够好好做事
对于项目方来说:
能够在消费者心中建立对自己的信心
对于两者都有的有点:
当处于退款期间时,项目的地板价不会低于 mint 的价格(因为可以反向刚兑)
短期炒作者会早早离开项目,便于项目长期发展
数据结构:
// 退款时间区间
uint256 public constant refundPeriod;
// 退款结束时间
uint256 public refundEndTime;
// 退款接收地址
address public refundAddress;
合约函数:
当用户在退款期内想要退款时,可以调用 refund 函数,传入想要退款的 tokenId 列表,就可以将 NFT 换成币。

管理员在退款期内,不能转出币(以实现用户可以刚兑)。到期后可以转出。

ERC721R 的代码还是很简单的,只是加了几个字段和对应的函数。虽然我个人觉得可能没啥用处,但是毕竟也是一个技术创新,值得支持。
这个合约有一个 bug,就是 refundAddress 可以用一个 tokenId 无限次退款,把钱都给套出来。这个 bug 我开始写文章的时候没有注意,后面看到了崔棉大师的推特,发现确实是这样。
目前我想到的解决方法有两种:
退款的时候直接将对应的 tokenId burn 掉
建立一个 mapping(tokenId => 是否退款 bool),来限制一个 tokenId 只能退款一次
这两种方法的目的都是限制一个 tokenId 只能退款一次。
不过当你看到这篇文章的时候,可能 bug 已经被修复了~
No activity yet