减少智能合约的 gas 消耗的8种方法
我目前正在开发一个Dapp项目,该项目的第一个主要开发阶段已经接近尾声。由于交易成本始终是开发人员的大问题,因此,我想使用本文分享一些我的见解。分享我过去几周/几个月来在该领域获得的收获。
<center> 在[Unsplash]上的“ 100美元钞票的特写照片” </center>
下面,我列出了一些优化技术,其中一些可以参考有关该主题的更详细的文章,你可以将其应用于合约设计。我将从一些更基本的、熟悉的概念开始,然后逐步深入到更加复杂细节。
尽量使用256位的变量,例如 uint256和bytes32!乍一看,这似乎有点违反直觉,但是当你更仔细地考虑以太坊虚拟机(EVM)的运行方式时,这完全有意义。每个存储插槽都有256位。因此,如果你只存储一个uint8,则EVM将用零填充所有缺少的数字,这会耗费gas。此外,EVM执行计算也会转化为 uint256 ,因此除uint256之外的任何其他类型也必须进行转换。
注意:通常,应该调整变量的大小,以便填满整个存储插槽。在第 3 节 “通过SOLC编译器将变量打包到单个插槽中”中,当使用小于256位的变量有意义时,将变得更加清楚。
一种相对便宜的存储和读取信息的方法是,将信息部署在区块链上时,直接将其包含在智能合约的字节码中。不利之处是此值以后不能更改。但是,用于加载和存储数据的 gas 消耗将大大减少。有两种可能的实现方法:
uint256 public v1;
uint256 public constant v2;
function calculate() returns (uint256 result) {
return v1 * v2 * 10000
}
变量v1 是合约状态的一部分,而v2和1000是合约字节码的一部分。
(读取v1是通过SLOAD操作执行的,仅此一项就已经消耗了200 gas 。)
当你将数据永久存储在区块链上时,要在后台执行汇编命令SSTORE。这是最昂贵的命令,费用为20,000 gas,因此我们应尽量少使用它。在内部结构体中,可以通过简单地重新排列变量来减少执行的SSTORE操作量,如以下示例所示:
struct Data {
uint64 a;
uint64 b;
uint128 c;
uint256 d;
}
Data public data;
constructor(uint64 _a, uint64 _b, uint128 _c, uint256 _d) public {
Data.a = _a;
Data.b = _b;
Data.c = _c;
Data.d = _d;
}
请注意,在struct中,所有可以填充为256位插槽的变量都彼此相邻排序,以便编译器以后可以将它们堆叠在一起(也使用占用少于256位的那些变量)。在上面的例子中,仅使用两次SSTORE 操作码,一次用于存储a,b和c,另一次用于存储d。这同样适用于在结构体外部的变量。另外,请记住,将多个变量放入同一个插槽所节省的费用要比填满整个插槽(首选数据类型)所节省的费用大得多。
注意:请记得使用编译器打包优化
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!