为什么要强调优化 gas 的重要性
DAPP 中收取的费用取决于性能逻辑的复杂程度，越简单耗费的计算资源越多。并且须要用户承当一部分 gas, 所以 solidity 的优化显得十分的重要。同时重视优化 gas 的合约开发人员写进去的合约代码更平安，品质更高。
1. 封装构造
以 uint 为例，如果咱们的程序中蕴含多个相似的变量，能够将其封装在一起，因为不论 uint8 ,uint32 ,uint16,solidity 都会为其保留 256 位。即便你应用 uint8 也不会节俭 gas.
2. 最小化读写链上数据
首先明确一点在读写 memory 变量比读写 storage 变量便宜。
contract NotSaveGas {
uint public var1 = 70;
function f1() external view returns (uint) {
uint sum = 0;
for (uint i = 0; i < var1; i++) {sum += i;}
return sum;
}
contract SaveGas {function f2() external view returns (uint) {
uint sum = 0;
for (uint i = 0; i < var1; i++) {sum += i;}
return sum;
}
}请肯定要防止 f1 这种循环读写 storage 变量，这是比拟耗费 gas 的形式。解决这种问题理论能够定义内存变量作为缓存，将数据写入，这样能够节俭大量的 gas.
3. 关上 solidity 优化器
hardhat 配置：
module.exports = {
solidity: {
version: "0.8.9",
settings: {
optimizer: {
enabled: true,
runs: 1000,
},
},
},
}4. 尽可能减少链上数据
区块链上保留数据是十分低廉的，所以须要尽可能将链上存储的信息缩小，以此来节俭大量的交易 gas.
应用事件
事件是内部事物 (例如用户界面) 从区块链中取得告诉的内置形式。当收回事件时，将告诉该事件的监督者。更新合约变量时不会产生告诉。事件以不同的形式存储，比应用合约存储便宜得多。合约不能间接拜访日志。
IPFS
如果你须要存储文件之类，能够应用 IPFS 保留文件，并将存储的 ID 保留在链上。
无状态合约
Merkle Proofs
如果须要应用区块链来验证一些信息是否无效，能够应用 merkle 证实。Merkle 证实应用繁多的数据块来证实更大的数据量的有效性。例如，如果有人想证实 “Tx4 “ 的有效性，他将须要提供 Tx4、Hash3、Hash12 和 Hash5678，而后你的合约将可能从新计算 Merkle 根（Hash12345678），并查看它是否与存储在区块链上的根相一致。你将不须要存储所有交易的哈希值。
5. 重视变量程序
Solidity 存储槽的长度为 32 字节，但并不是所有的数据类型都须要这么大的空间：bool, int8 … int128, bytes1 … bytes31 和地址须要的空间小于 32 字节。solidity 会尝试将这些变量打包到同一个存储槽中。
如果你接连定义了 2 个 uint128，它们都会被打包到同一个存储槽中，因为它们各占 16 字节。然而，如果你定义了一个 uint128，接着是一个 unit256，而后是另一个 int128，你将应用 3 个存储槽，因为在两个 int128 之间的 unit256 须要一个残缺的存储槽。
contract T{
// 不好的形式
uint128 v1;
uint256 v2;
uint128 v3;
// 举荐形式
uint128 v1;
uint128 v3;
uint256 v2;
}6. 首选数据类型
如果智能合约只须要一个状态变量，一个永远不会大于 255 的无符号整数。咱们惯例思维可能是想用 uint8, 会感觉节俭 gas, 理论并不会。以太坊操作码被设计为应用 256 位的变量（EVM 堆栈的大小），而 uint8 只须要 8 位，EVM 会在残余的位上填上 “0”，以便可能操作它。这个由 EVM 执行的填 “0” 操作将破费 Gas，因而为了节俭交易 Gas，最好应用 uint256 而不是 uint8。
7. 独立部署库
如果在智能合约中重复使用代码，最好是将所有的代码打包到一个库中，并通过 import 的形式指向它。
库蕴含：
- 嵌入式库：蕴含外部函数的库，这些库都是嵌入在合约中，和合约一起部署，所以会比拟耗费 gas
- 独立库：蕴含 public 和内部函数的库，这些库只会被部署一次，同时被所有导入它的所有合约应用，从而节俭了大量的 gas.
8. 构造函数
常量和不可变的状态变量在合约被部署后不能被扭转。区别在于，常量必须在编译时定义，而不可变量能够在构造函数中定义。总是尽量应用常量，以便使构造函数更便宜。
9. 使合约尽可能的小
单个合约的限度是 24KB，所以要想节俭 gas, 就必须使实现的合约尽可能的小。
- revert 和 assert 的提示信息要尽可能的短
- 修改器：修改器（modifier）代码是内联的，这意味着它会被增加在所批改的函数的结尾或结尾。在应用修改器时缩小合约大小的一个技巧是编写一个实现修改器逻辑的函数，而后让修改器调用该函数。这样实现修改器的代码就不会被复制，只有函数调用会被复制。这种技术只在同一修改器被屡次应用时无效。
modifier TestModifier(uint256 value){JudgeLength(value);
_;
}
function JudgeLength(uint256 value)internal{//logic}10. 最小代理（ERC1167）
如果须要部署多个性能完全相同的合约，应该思考应用 “ 最小代理 ”（在 ERC 1167 中定义）
最小的代理只是一个合约，它将把所有的调用委托给一个事后定义的 实现合约。它有一个定义好的字节码，代表最小代理合约的编译代码，你只须要把你的实现合约地址插入其中，你就能够依据须要部署最小代理的多个正本。参考 ERC 1167 相干文章，理解如何应用最小代理）。
因为最小的代理字节码十分小，部署它的老本也低到不能再低，因而节俭一堆 部署 Gas。
应用最小代理的注意事项，你应该牢记：最小代理的实现合约地址不能扭转，这意味着你将不能降级他们的代码。
11. 内存地位
以太坊存在 4 个内存地位，从最便宜到最贵的：calldata、stack、memory、storage。
- calldata：只实用于输出参数且参数是内部函数的援用数据类型（数组，字符串 …）。Calldata 参数是只读的，如果你有一些须要传递给函数的援用类型，总是思考应用 calldata，因为它是最便宜的。
- stack：只对办法中定义的值类型数据无效。
- memory：内存是易失落的 RAM，在 EVM 终止运行的时候会被移除。能够用它来存储援用数据类型，它比 storage 变量更便宜。当向其余函数传递参数，或在你的函数中申明长期变量时，除非你严格须要应用 storage 变量，否则应该总是应用 memory 变量。
- storage：是最低廉的存储地位。存储数据在区块链上长久存在，请尽量减少链上数据存储。
- 本地存储变量：本地存储变量是办法的本地变量，它指向一个理论的状态变量（存储在区块链存储中）。与其在内存中复制 / 粘贴存储数组以便操作它们，而后将它们复制回存储，不如简略地应用本地存储变量，间接在存储上操作。
- 批处理：与其让用户用不同的值屡次调用同一个函数（通过向区块链发送多个交易），不如让他们通过传递动静大小的数组，以便能够在一个繁多的交易中批量执行雷同的性能。这将可能节俭一些交易根底开销老本。理论 ERC1155 有些思维就是如此
12. 尽量减少链上操作
- 字符串：如果能够应用 bytes, 则尽量应用。如果依然须要操作，则尽量放在智能合约内部操作。
- 返回值：对返回值无需额定转换，如果这个是能够通过链外数据来解决。
- 循环：防止在长数组中循环，这不仅会破费大量的 Gas，而且如果 Gas 成本增加到很高的水平（超过 BlockGas 限度），会使合约无奈执行。应用映射来代替长数组，映射是一个哈希表，能够让你在一次操作中应用其键来拜访任何值，而不是在数组中循环，直到找到你要找的键。
13. 利用 view 函数缩小 gas
当用户从内部调用一个 view 函数，是不须要领取一分 gas 的。
这是因为 view 函数不会真正扭转区块链上的任何数据 – 它们只是读取。因而用 view 标记一个函数，意味着通知 web3.js，运行这个函数只须要查问你的本地以太坊节点，而不须要在区块链上创立一个事务（事务须要运行在每个节点上，因而破费 gas）。
在所能只读的函数上标记上示意“只读”的“external view 申明，就能为你的玩家缩小在 DApp 中 gas 用量。
留神：如果一个 view 函数在另一个函数的外部被调用，而调用函数与 view 函数的不属于同一个合约，也会产生调用老本。这是因为如果主调函数在以太坊创立了一个事务，它依然须要一一节点去验证。所以标记为 view 的函数只有在 内部调用 时才是收费的。
14. 应用短路模式排序 solidity 操作
短路（short-circuiting）是一种应用或 / 与逻辑来排序不同老本操作的 solidity 合约 开发模式，它将低 gas 老本的操作放在后面，高 gas 老本的操作放在前面，这样如果后面的低成本操作可行，就能够跳过（短路）前面的高老本以太坊虚拟机操作了。
// f(x) 是低 gas 老本的操作
// g(y) 是高 gas 老本的操作
// 按如下排序不同 gas 老本的操作
f(x) || g(y)
f(x) && g(y)15. 删除不必要的库
在开发 Solidity 智能合约时，咱们引入的库通常只须要用到其中的局部性能，这意味着其中可能会蕴含大量对于你的智能合约而言其实是冗余的 solidity 代码。如果能够在你本人的合约里平安无效地实现所依赖的库性能，那么就可能达到优化 solidity 合约的 gas 利用的目标。
例如，在上面的 solidity 代码中，咱们的以太坊合约只是用到了 SafeMath 库的 add 办法：
import './SafeMath.sol' as SafeMath;
contract SafeAddition {function safeAdd(uint a, uint b) public pure returns(uint) {return SafeMath.add(a, b);
}
}通过参考 SafeMath 的这部分代码的实现，能够把对这个 solidity 库的依赖剔除掉：
contract SafeAddition {function safeAdd(uint a, uint b) public pure returns(uint) {
uint c = a + b;
require(c >= a, "Addition overflow");
return c;
}
}16. 准确的申明函数的可见性
在 Solidity 合约开发中，显式申明函数的可见性不仅能够进步智能合约的安全性，同时也有利于优化合约执行的 gas 老本。例如，通过显式地标记函数为内部函数（External），能够强制将函数参数的存储地位设置为calldata，这会节约每次函数执行时所需的以太坊 gas 老本。
External 可见性比 public 耗费 gas 少。
17. 防止代码中死代码
死代码（Dead code）是指那些永远也不会执行的 Solidity 代码，例如那些执行条件永远也不可能满足的代码，就像上面的两个自圆其说的条件判断里的 Solidity 代码块，耗费了以太坊 gas 资源但没有任何作用：
function deadCode(uint x) public pure {
if(x < 1 {if(x > 2) {return x;}
}
}18. 防止应用常量后果的循环
如果一个循环计算的后果是无需编译执行 Solidity 代码就能够预测的，那么 就不要应用循环，这能够可观地节俭 gas。例如上面的以太坊合约代码就能够 间接设置 num 变量的值：
function constantOutcome() public pure returns(uint) {
uint num = 0;
for(uint i = 0; i < 100; i++) {num += 1;}
return num;
}19. 合并循环
有时候在 Solidity 智能合约中，你会发现两个循环的判断条件统一，那么在这种状况下就没有理由不合并它们。例如上面的以太坊合约代码：
function loopFusion(uint x, uint y) public pure returns(uint) {for(uint i = 0; i < 100; i++) {x += 1;}
for(uint i = 0; i < 100; i++) {y += 1;}
return x + y;
}20. 去除循环中的比拟运算
如果在循环的每个迭代中执行比拟运算，但每次的比拟后果都雷同，则应将其从循环中删除。
function unilateralOutcome(uint x) public returns(uint) {
uint sum = 0;
for(uint i = 0; i <= 100; i++) {if(x > 1) {sum += 1;}
}
return sum;
} ********************
最终的定稿：https://github.com/blockchainGuide/blockchainguide
公众号：区块链技术栈
********************参考
https://medium.com/coinmonks/…
本文由博客群发一文多发等经营工具平台 OpenWrite 公布