目前，无状态以太网运动已经提出了一种块见证的格式，其细节如下所示。该块见证方案基于操作码。你可以理解为一种小编程语言，可以用几个命令生成“默克尔多值证明”(中文翻译)。

本文研究了块见证数据的另一种构造方法，该方法基于键值对列表，语义更简单。

在本文中，我将尝试回答以下问题：

什么是键值对见证数据(KvWitness)，KV  witness和目前提出的基于操作码的见证数据格式有什么区别？

键值对见证数据与操作码见证数据相比有什么优缺点？

从网络带宽的角度来看，键值对见证数据方案有多高效？

(见证数据方案满足的前提)

所有块见证数据方案必须满足以下要求：

是正确的(正确性)。确保该节点可以执行以太网主网络的任何块。

效率(效率)。传输见证数据所需的网络带宽应尽可能小。

merk  alization(merk  alization)。有必要支持合约码的汉化(中文翻译)。

状态树的格式(不依赖于Arity)被忽略。支持十六进制默克尔树和二进制默克尔树(中文翻译)。

语义意义

这部分我先说键值对见证格式的语义，具体的字节布局就不说了。

稍后，我将解释我在测试中使用的数据格式。

见证：=标题、正文、校样

报头：=版本：字节，trie_arity  :字节

body  :=数组[ { type: byte  key  : []byte，value  : []byte  } ]

校样：=map  { :[{ prefix  :[]byte，hash  : []byte  } ] }

见证数据主体

见证数据的数据主体由两个元素组成：

数据

“密钥”可以是：账户地址、存储密钥或代码密钥；“值”可以是：帐户、存储项目或相应的代码块。这部分的数据体与用来验证正确性的默克尔树格式无关。而且即使用其他方法验证正确性，这部分也不会改变。

证据。

密钥是默克尔路径，值是哈希值。证据的形式取决于状态树的格式，所以十六进制树和二叉树下的证据会有所不同。这种语义使我们能够在同一个见证中包含多种类型的多值证明。因此，理论上，我们可以创建一个既支持十六进制又支持二进制状态树的见证数据格式。

数据体根据关键字的字典顺序进行排序和存储，以确保：

较短的键总是在列表的顶部(从上到下重建默克尔树时很有用)

当两个数据的关键字相同时(账号地址可能与代码关键字相同)，与账号相关的数据总是排在第一位。

解析算法

检查证人数据的版本和用于证据的默克尔树格式(以确保证据的格式与块要求的状态树格式相匹配)

验证见证数据的哈希值(如果有“规范见证”的概念)

用正确的格式创建一个空的默克尔树

遍历数据，并按照读取数据的顺序为这个空的默克尔树插入数据(见证数据也应按照字典顺序存储)

将证据插入树中

验证根哈希值(它应该与前一个块的根哈希值一致)

优点和缺点

比较键值对见证格式和当前操作码见证格式的优缺点。

优点：

匹配平坦数据库机制，因此如果规范见证哈希值有效，可以立即插入(不需要验证默克尔根值)

它可以用于快照同步

见证中的数据与我们选择的验证证据的方法无关：无论是默克尔树、多项式承诺还是其他方法，都不会影响我们需要添加的数据。

缺点：

在二进制状态树中，由于字节对齐可能会占用更高的带宽(例如，证据的密钥是0b01，只有两位，但需要占用一个字节的存储空间)

解析可能会更慢