Telegram Channel
记录和分享有趣的信息。

Record and share interesting information.

contact: [email protected]
https://laisky.notion.site/Solidity-delegatecall-usage-and-pitfalls-3833eadc06ae4528bfa23d194ea8d3cb?pvs=4

前文介绍了 solidity 中变量的持久化存储方式。而我们之所以关心变量的存储位置(slot),就是因为在使用 Proxy 模式时,需要在合约间共享变量,而合约间变量的共享方式就是通过 slot 对齐的。

合约一旦发布就是只读不可更改的,如果想要修复 bug 或升级功能而发布一个新的合约,那么就会得到一个新的地址。为了在保持地址不变的同时更改合约的代码,最常见的实现方法就是使用 Proxy-Implementation 模式。发布一个 Proxy 合约作为接口,地址永远不变。但是实际的业务代码指向 Implementation 合约,implementation 合约可以不断地升级迭代,只要同步更新 Proxy 合约的指向即可。

实现 Proxy 这一功能,依赖于 solidity 的 delegatecall(),这个函数可以让 Implementation 使用 Proxy 的上下文,即内存数据和存储。而这个数据共享的前提,就要求 Proxy 和 Implementation 的变量声明按照 slot 进行严格的对齐。

按照目前最推荐使用的 UUPS Proxy 模式(UUPS 简而言之就是将升级 Implementation 的 upgrade() method 也放在 Implementation 内定义),为了减少 Proxy 和 Implementation 间的变量冲突,一个最佳实践就是不要在 Proxy 内声明任何非必需的变量,理论上 Proxy 内仅需要定义 owner(设置管理者) 和 implementation(设置 Implementation 的地址) 两个变量即可。所有的业务数据,全部仅在 Implementation 内定义。当 Proxy 使用 delegatecall() 调用 Implementation 时,Proxy 的存储空间会被共享给 Implementation,所以虽然变量仅定义在 Implementation 内,但实际上全部存储于 Proxy 的存储空间内。当 Implementation 迭代升级时,新版本的 Implementation 内的变量声明必须严格对齐于旧版本,仅允许在尾部添加新变量,不允许修改或删除旧变量(append-only)。

此文详细介绍了 delegatecall() 时,Proxy 和 Implementation 间变量对齐的注意事项和案例。 #blockchain #evm Solidity delegatecall usage and pitfalls | Notion
https://laisky.notion.site/Solidity-layout-and-access-of-storage-state-variables-simply-explained-6fb8c4eaca0d4004b361e4358257fa92?pvs=4

详细介绍了 solidity storage 的存储结构。每一个 smart contract 都有独立的 storage,由 2^{256}-1 个 slots 组成,每个 slot 的长度为 32 bytes。

在 solidity 中声明的 variables 都会在 slot 中从头开始逐一存放,它们存储的位置称为 slot index。

比较奇葩的是 dynamic variables,如 array、mapping 和长度超过 32 bytes 的 string。拿 array 来说,其 slot 内存放的只是其长度,它的成员数据实际上是连续存放在另外一组随机的 slots 里的,这组 slots 的首地址由 keccak256(slot index) 计算而来。

理论上,dynamic variables 是有可能和其他的数据的 slot 发生冲突的,但是考虑到 2^256 是一个足够巨大的空间,一般认为超过 2^100 就足够满足密码学的碰撞安全性要求了,ECC-256 的安全等级也就是 2^128,如果你不担心自己的私钥被别人碰撞出来,那么也不需要担心 dynamic variables 和其他 slot 碰撞。

#blockchain #evm
next: https://t.me/laiskynotes/245 Solidity layout and access of storage state variables simply explained | Notion
 
 
Telegram Channel