合约开发的奇妙技巧：从Uniswap代码中学到的经验

最近在编写去中心化交易所开发教程时,参考了某知名DEX的代码实现,学到了不少新知识。作为一个曾经开发过简单NFT合约的开发者,这是我首次尝试Defi合约开发,相信这些小技巧对想要学习合约开发的新手会很有帮助。

接下来让我们一起看看这些有趣的技巧吧,有些甚至可以称得上是奇技淫巧。

可预测的合约部署地址

通常部署合约得到的是一个看似随机的地址,因为与nonce相关,所以合约地址不易预测。但在某些场景下,我们需要通过交易对和相关信息来推断合约地址。这在很多情况下非常有用,比如判断交易权限或获取流动性池地址等。

可以通过添加salt参数使用CREATE2方式来创建合约,这样创建的合约地址是可预测的。地址生成逻辑为:新地址 = hash("0xFF",创建者地址, salt, initcode)。

善用回调函数

在Solidity中,合约之间可以相互调用。有一种场景是A在某个方法调用B,B在被调用的方法中回调A,这在某些场景中很实用。

例如,当你调用某DEX合约的swap方法交易时,它会回调swapCallback,传入计算出的本次交易实际需要的Token。调用方需要在回调中将交易所需Token转入DEX合约,而不是将swap方法拆分为两部分让调用方调用。这确保了swap方法的安全性,保证整个逻辑被完整执行,无需繁琐的变量记录来确保安全性。

用异常传递信息,用try catch实现交易预估

在某些DEX的代码中,我们发现它把swap方法用try catch包裹执行了一下。这是为什么呢?因为我们需要模拟swap方法来预估交易所需Token,但预估时并不会实际产生Token交换,所以会报错。它通过在交易回调函数中抛出特殊错误,然后捕获这个错误,从错误信息中解析出所需信息。

这看起来有点取巧,但很实用。这样就不需要为预估交易的需求去改造swap方法了,逻辑也更简单。

用大数解决精度问题

在DEX的代码中,有很多计算逻辑,比如根据当前价格和流动性计算交换的Token。在这个过程中我们要避免除法操作时丢失精度。在某些实现中,计算过程会经常使用"<< FixedPoint96.RESOLUTION"这个操作,它代表左移96位,相当于乘以2^96。左移后再做除法运算,这样可以在正常交易不溢出(通常用uint256计算,足够)的情况下保证精度。

用Share方式计算收益

在DEX中,我们需要记录LP(流动性提供者)的手续费收益。显然,不能在每次交易时都给每个LP记录各自的手续费,这会消耗大量Gas。那该如何处理呢?

可以在Position中定义包含feeGrowthInside0LastX128和feeGrowthInside1LastX128的结构体,它们记录了每个头寸上一次提取手续费时每个流动性应获得的手续费。

简单说,只需记录总手续费和每个流动性应分配的手续费即可。LP提取手续费时,根据持有的流动性就能计算出可提取的手续费。这类似于持有某公司股票,提取股票收益时只需知道公司历史每股收益,以及你上次提取时的收益即可。

并非所有信息都需从链上获取

链上存储相对昂贵,因此并非所有信息都要上链或从链上获取。比如某些DEX前端网站调用的很多接口就是传统Web2接口。

交易池列表、交易池信息等可以存储在普通数据库中,有些可能需要定期从链上同步,但不需要实时调用链或节点服务提供的RPC接口来获取相关数据。

当然,关键交易肯定是在链上进行的。

学会合约拆分,利用已有标准合约

一个项目可能包含多个实际部署的合约。即使实际部署只有一个合约,我们也可以通过继承方式将合约拆分为多个合约来维护。

此外,可以直接使用像@openzeppelin/contracts/token/ERC721/ERC721.sol这样的标准合约。这样一方面可以通过NFT方式管理头寸,另一方面也能用已有标准合约提高开发效率。

总结

亲身实践开发一个简易版去中心化交易所,能让你更深入理解DEX的代码实现,也能学到更多实际项目中的知识点。无论你是对Web3还是DeFi项目开发感兴趣,实战经验都会对你大有帮助。