(键，值)对在帐户存储和相应的修改Merkle树

Question

在黄纸(第4.1节，storageRoot)中提到了

storageRoot: Merkle树根节点的256位散列，编码帐户的存储内容(256位整数值之间的映射)，编码到trie中，从256位整数键的Keccak 256位哈希映射到RLP编码的256位整数值。哈希正式表示为一个_sσ。

从上面我可以了解到，对于存储映射(k，v)的所有键值对，(Kecak(k)，RLP(v))将被用于存储的修改merkle trie，其中Keccak(k)将作为值RLP(v)的密钥。

我的问题是：

1.在帐户的存储内容中，这些(k，v)即密钥和值是什么？

用一个例子来解释是非常有帮助的。

2.为什么使用Keccak(k)作为树的密钥而不是直接使用k？

提前谢谢。

Answer 1

在帐户的存储内容中，这些(k，v)，即密钥和值是什么？

合同代码可以随意使用这些代码。例如，在这个稳固的代码中，编译器将使用var1的索引0和var2的索引1：

pragma solidity 0.4.20;

contract Test {

  uint public var1;
  address public var2;

  function test() public {
    var1 = 5;
    var2 = address(6);
  }
}

所以调用test()后的(k，v)对：

(0,5)
(1,6)

您可以在本文中找到更多细节：https://medium.com/@hayeah/diving-into-the-ethereum-vm-part-2-storage-layout-bc5349cb11b7

2.为什么使用Keccak(k)作为树的密钥而不是直接使用k？

在设计原理文档中对此进行了解释，该文档位于Ethereum中：

使用sha3(k)作为“安全树”的关键(在状态和帐户存储尝试中使用)：这使得通过设置深度最大的分散节点链( 64层)并在其上反复调用SLOAD和SSTORE来DoS trie变得更加困难。请注意，这使得枚举树变得更加困难；如果希望在客户端具有枚举功能，最简单的方法是维护数据库映射sha3( k ) -> k。

先前的回答

我不确定，但我的猜测是，使用散列会导致更平衡的trie。如果您想象一个Patricia trie，其中条目是按索引顺序添加的，the的一边通常会比另一边重。另一方面，在使用散列时，会将新元素添加到随机位置。插入/删除/查找在平衡的trie中提供更一致的性能。

使用散列也有可能产生一个更小的trie，因为可能会有更多的叶节点和扩展节点，而在基于索引的trie中则会有更多的分支节点。

为了演示如何使用连续索引作为键导致一个不平衡的trie，让我们设想一种情况，在trie的某个级别上，有一个分支节点，其中只有第1和第2个节点正在攻击其他节点：

<hash0> branch [<hash1>, <hash2>, NULL,..<13 NULLs>, value]

如果这个分支位于trie的n级(可能有64级，因为键是32字节，根位于0级)，那么它将把2 ^ ((64 - n) * 4 - 8)插入到trie中，直到第三个小块变为非空。

例如，如果这个分支位于根，则需要在第三个小块变为非空之前插入2 ^ 248键--这是不可能的(但是，这样的分支不可能在根级别，因为它需要2 ^ 247键才能到达这个状态，但是更高级别的trie是可能的)。一般来说，左边的咬口比右边的咬口更有可能是非零的，这意味着左边的小口要重一些。