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
Share Dialog
Share Dialog

Subscribe to xyyme.eth

Subscribe to xyyme.eth
<100 subscribers
<100 subscribers
我们知道,NFT 最开始 mint 之后,所有的图都是一样的,比如下面这种:

(上图为 MURI项目)
在经过项目方“开图”之后,每个图都有了各自的风格,比如下面这样:

(上图为 Azuki项目)
那么这一步是怎么实现的呢?
其实原理很简单,我们知道,ERC721 中有一个字段 tokenURI,一般是由
baseURI + tokenId
构成。在项目初期,管理员地址会将未开图的图片信息设置到 baseURI 上,一般是通过发送交易或者直接在合约构造方法中设置。以 MURI 为例,管理员是直接在构造方法中就设置了最初的 baseURI:
constructor(bytes32 _merkleRoot, string memory contractBaseURI)
ERC721A ("MURI", "MURI") {
merkleRoot = _merkleRoot;
baseURI = contractBaseURI;
}
查询 baseURI 内容为:
ipfs://QmTCAt4Y4r1HyHRyqwqHgrJvU7D78PSRuw4LefEbG5Ww49/
我们随便查询一个 tokenId,也就是直接在后面加上 tokenId,得到一个 Json 文本:
{
"name": "MURI [11]",
"description": "MURI is a collection of 10,000 individual characters, each playing a role in the story between the worlds of Night City and its spirit.",
"image": "ipfs://QmfJEERKhLJbenpMFBtcbC9pMssBBd6CjJTKW5K47UUdp7/",
"attributes": [
]
}
其中 image 字段存储的就是图片的 ipfs 地址,这就是我们前面看到的图片的 ipfs 地址。
当管理员“开图”的时候,会发送一笔交易设置 baseURI。以 Azuki 为例,这笔交易进行设置:

在设置了 baseURI 之后,也就是已经开图了。我们在 baseURI 后面随便加上一个 tokenId,同样得到一个 Json 文本,继续查询 image 字段,就得到了开图后的相应 tokenId 的图片地址。
其实开图的逻辑很简单,就是对 baseURI 进行更改,从而达到效果。
我们知道,NFT 最开始 mint 之后,所有的图都是一样的,比如下面这种:

(上图为 MURI项目)
在经过项目方“开图”之后,每个图都有了各自的风格,比如下面这样:

(上图为 Azuki项目)
那么这一步是怎么实现的呢?
其实原理很简单,我们知道,ERC721 中有一个字段 tokenURI,一般是由
baseURI + tokenId
构成。在项目初期,管理员地址会将未开图的图片信息设置到 baseURI 上,一般是通过发送交易或者直接在合约构造方法中设置。以 MURI 为例,管理员是直接在构造方法中就设置了最初的 baseURI:
constructor(bytes32 _merkleRoot, string memory contractBaseURI)
ERC721A ("MURI", "MURI") {
merkleRoot = _merkleRoot;
baseURI = contractBaseURI;
}
查询 baseURI 内容为:
ipfs://QmTCAt4Y4r1HyHRyqwqHgrJvU7D78PSRuw4LefEbG5Ww49/
我们随便查询一个 tokenId,也就是直接在后面加上 tokenId,得到一个 Json 文本:
{
"name": "MURI [11]",
"description": "MURI is a collection of 10,000 individual characters, each playing a role in the story between the worlds of Night City and its spirit.",
"image": "ipfs://QmfJEERKhLJbenpMFBtcbC9pMssBBd6CjJTKW5K47UUdp7/",
"attributes": [
]
}
其中 image 字段存储的就是图片的 ipfs 地址,这就是我们前面看到的图片的 ipfs 地址。
当管理员“开图”的时候,会发送一笔交易设置 baseURI。以 Azuki 为例,这笔交易进行设置:

在设置了 baseURI 之后,也就是已经开图了。我们在 baseURI 后面随便加上一个 tokenId,同样得到一个 Json 文本,继续查询 image 字段,就得到了开图后的相应 tokenId 的图片地址。
其实开图的逻辑很简单,就是对 baseURI 进行更改,从而达到效果。
No activity yet