详解以太坊虚拟机（EVM）的数据存储机制
来源 | 区块链研究实验室
封图 | CSDN 付费下载于视觉中国
以太坊存储机制
在EVM中允许执行智能合约代码。合约状态或内存存储在智能合约地址中。可以将这种存储视为位于智能合约地址的无限长度的数据结构数组。存储机制确保存储位置没有冲突，并遵循一组规则。使用这些规则，我们可以解码任何合约的状态。解码存储在映射中的数据需要知道所使用的密钥。合约数据的解码使用RPC调用eth_getStorageAt进行。
插槽位置
变量在智能合约的存储阵列中的位置由代码中出现的顺序以及变量的大小决定。此位置称为插槽。如果一个变量小于256位，则EVM会尝试在空间中容纳一个以上的变量，因此一个以上的变量可能会占用存储阵列中单个插槽的空间。映射或数组将始终占据一个插槽。数组和映射元素的位置遵循一组特殊的哈希规则，本文将对此进行介绍，这些规则在以太坊文档中也有描述。
下表（表1）提供了EVM遵循的分配规则的摘要。我们将看两个智能合约的示例，并使用表1中提供的规则对其进行解码
256位变量的简单示例
首先让我们看一个简单示例，所有变量都是256bit（32字节长）。这样做使我们无需考虑可变变量即可查看分配。
请注意，当对数字应用keccack哈希时，数字必须是0填充的64位值。
所有解码都是使用以太坊RPC调用eth_getStorageAt执行的，在本文中将其表示为GetStorageAt。可以使用任何语言打包程序（例如nethereum或web3j）来调用此RPC api。
下图（图1）显示了如何对智能合约的地址和传递给它的位置值进行GetStorageAt调用。图1左侧的数字是变量的位置。对于基类型（uint、string等），可以将此位置传递到GetStorageAt以获取变量值。对于数组，位置将返回数组的长度。
通过将Keccack哈希传递给索引为0的GetStorageAt来解码数组索引。数组的每个后续索引位于与位置求和的哈希值处。可以认为这是访问数组的指针并增加其位置以查找每个元素，类似于C或C ++。
传递给每个键的GetStoragetAt的位置值是键的keccack哈希值和映射声明的位置。对于多维映射，将密钥和变量位置递归调用Keccack哈希值。参见图1中的示例进行说明。
接下来，我们来看一个发生变量打包的示例。打包要记住的是：
1. 它仅按出现顺序适用于基本变量类型（uint128，string，int等）。EVM将按照代码中列出的顺序在256位空间中打包尽可能多的变量。
2. 每个映射和数组变量将占用一个新的插槽。
3. 数组变量映射将遵循打包规则。也就是说，如果一个元素小于256位，则阵列的多个索引将占用存储阵列中的单个插槽。
图2显示并提供了发生的打包的说明。当类型的长度小于256位时，EVM尝试将其他变量打包到插槽中。EVM按列出的顺序选择要打包的变量。映射和数组始终出现在新位置。但是打包规则仍适用于解码数组索引，打包规则仍适用于存储在映射中的结构。
有关这种情况下如何存储变量的说明，请参见图2。
继承
关于继承的说明。当智能合约继承其他智能合约时，基本智能合约的存储变量将按继承顺序占据存储阵列的第一个插槽。子类的存储变量将随后出现。
结论
如前所述，我们在本文介绍的规则来解码以太坊智能合约的存储机制。在接下来的，第2部分将描述的智能合约规则编写的工具。
同时，欢迎所有开发者扫描下方二维码填写《开发者与AI大调研》，只需2分钟，便可收获价值299元的「AI开发者万人大会」在线直播门票!
推荐阅读：
比特币当赎金，WannaRen 勒索病毒二度来袭！
通过 Python 代码实现时间序列数据的统计学预测模型
你知道吗？其实 Oracle 直方图自动统计算法存在这些缺陷！（附验证步骤）
你公司的虚拟机还闲着？基于 Jenkins 和 Kubernetes 的持续集成测试实践了解一下！
一站式杀手级 AI 开发平台来袭！告别切换零散建模工具
那些神一样的程序员
老铁们求在看！????