OpenZepplin 已经成为如今合约开发的事实标准，很难找到一个完全不使用它而完全从零自行打造合约系统的例子。除非要开发一个竞品，摆脱它既无必要，也不经济，同时还浪费时间。

在一般语境下，OpenZepplin 指代的其实是：OpenZepplin Contract，一组合约开发的可重用包。同时，由于合约升级相对特殊，它还专门提供了用于编写可升级合约的包。关于可升级合约，本系列会另行说明，本文对此将直接略过。

OpenZepplin 的各部分组成如下。

interfaces，支持接口

for tokens

• IERC20 / IERC721 / IERC777 / IERC1155
  • 关于 ERC20/721/1155，已有很多文章介绍过，不必在赘述。
  • ERC777 可以简单理解问 ERC20 的升级版，提供了向后兼容同时涵盖更多场景，并提供了更多的接口。
• draft-IERC2612
  • 对于 ERC20 permit 的扩展，允许 owner 只通过签名就可以授权。这带来了几个好处：
    • owner 可以只提供签名，但不必亲自执行 permit 方法（如元交易场景），可参见这篇 Uniswap 文章
    • 更好的用户体验和更低的 gas fee，因为可以将若干操作打包在一起一次执行。而不像 erc20 中 approve 和 transfer 因为是两个不同人，得分别执行。
• IERC1363
  • 扩展 erc20 行为，提供：transfer and call 和 approve and call。
• IERC2981
  • nft royal 规范，不过请注意：不见得所有市场都支持它。
• IERC4626
  • defi vaults（金库）标准

for upgrade

• draft-IERC1822
  • 通用可升级代理标准（UUPS）。

for flash load

• IERC3156
  • 闪电贷规范，可参见这篇 Uniswap 文章。

for introspection

• IERC165
  • 用于判断合约是否实现某接口
• IERC1820
  • 合约接口注册表规范，熟悉 web service 历史的开发者应该记得“服务注册表”这个概念。此规范的目前与之类似，帮助实现一个注册表合约，让账户注册：
    • 它支持哪些接口
    • 哪些合约负责其实现

for cryptography

• IERC1271
  • 合约签名验证标准接口，注意，此处签名是合约产生，而非外部账户。

supporting，支撑代码

• utils
  • 工具类和方法，著名的 safeMath、Merkle Proof 等都在这里。对于 solidity 0.8.0 之后，safe math 已不是必须。关于 merkle proof，会有专文介绍其妙用。关于 merkle tree，可参见图解默克尔树。
• access
  • 封装了访问控制，通过它可以实现 RBAC。最出名的接口就是 Ownable。
• security
  • 封装合约的安全最佳实践，如防重入之类的。
• metatx
  • 元交易工具类，实现了 ERC2771 规范。但若真要使你的合约支持元交易，建议基于 GSN 实现更佳，未来会有专文介绍。

biz，业务流程

• tokens
  • 上面提到的 token 接口实现
• governance
  • 封装了基本的治理逻辑，其中的 TimelockController 可以关注一下。
• finance
  • 封装了分账和分期兑现逻辑，其中的 PaymentSplitter 可以关注一下。关于分账，有兴趣的同学还可以看一下0xsplits。

maintenance

• proxy
  • 封装了实现 proxy 合约的代码逻辑。

cross chain

封装跨链逻辑，使合约可以方便的实现跨链功能。但此处经验值为 0，故略过不提。

• crosschain
• vendor

最后

由上可知，OpenZepplin 本身是一个范围广泛、功能完善的合约开发框架，但使用时也请注意几点：

• 不要生搬硬套，按照需求本身来合理选择使用那些类和库。理由很简单，gas fee。
• 在使用之前务必：熟悉其背后的 EIP，同时熟悉代码。
• 不要把它当做唯一选择，了解其他备选方案，比如 ERC721A 就提供了更省 gas fee 的实现。