加载中 ...

KV-Witness会不会是另一种高效区块见证方法?

2020-07-31 16:11 编辑:币牛牛 来源:币源

目前有一种针对无状态以太坊中的区块见证的提议格式,它在GitHub repo中有一个规范。它是基于操作码,您可以想象只有一种命令可以生成Merkle Mupltiproof的小型编程语言。



这篇文章研究了区块见证建设的另一种方法。它是基于键和值的列表,并且具有更简单的语义。



在这篇文章中,我将尝试回答以下问题:



1. 什么是KV-Witness格式?它与当前提议的(基于操作码的)见证格式有何不同?
2. 比较KV的优缺点是什么?
3. 就网络带宽而言,这种格式的效率如何?



要求



任何集体见证人必须满足以下要求:



Correctness(正确性):我们使用这种格式能够正常运转以太坊主网的任何区块。
Efficiency(效率):我们能够使用最小的网络带宽来转移此见证人。
Merkelization(默克尔化):见证人格式必须支持代码默克尔化。
Arity-agnostic(不可知论):见证格式必须同时支持hexary和二进制Merkle Tries。



语义



我在文章的这一部分描述的见证格式是语义。我不是在这里谈论确切的字节布局。



稍后,我将详细介绍用于测试的见证人的精确二进制格式。

witness ::= header, body, proofs
header ::= version : byte, trie_arity : byte
body ::= array of [ { type: byte key : []byte, value : []byte } ]
proofs ::= map { <type>: [ { prefix : []byte, hash : []byte } ] }

Witness body

Witness body 由2个元素组成:

1、Data.

密钥可以是:帐户地址,存储密钥或代码密钥,值分别是帐户,存储项目或代码块。Witness body的这一部分完全与用于验证其正确性的Merkle Trie无关。此外,如果我们使用其他方法进行正确性检查,则此部分不会更改。

2、Proof(s).

关键是Merkle路径和哈希的值。证明取决于trie arity,十六进制和二进制尝试会有所不同。此语义允许在同一见证人中包含具有不同类型的多个证明。因此,从理论上讲,我们可以做一个既支持十六进制也支持二进制的见证人。

body是按字母顺序在字典上排序,请确保:

较短的键在列表的前面(因此我们从上到下重新构造了trie);
当密钥相同(account和code可能发生这种情况)时,account总是在第一位。

解析算法

1. 验证证人版本和证明Arity(确保证人证明Arity匹配该块要求的Trie Arity)。
2. 验证见证哈希(如果存在规范的见证)。
3. 创建一个正确arity的空trie。
4. 遍历数据,只需按顺序将数据插入此trie(见证人应按字典顺序排序)。
5. 在trie中插入证据。
6. 验证根哈希(应与上一个块的根哈希匹配)。

优点和缺点

下面是比较KV-Witness与当前基于操作码的见证格式的优缺点列表。

优点

它与flat DB结构匹配,如果规范的见证哈希有效,则可以立即插入(无需验证Merkle根)。
它可以用于快照同步。
见证数据独立于我们选择的有效性证明方法:Merkle Tries或多项式承诺或其他。

缺点

由于字节对齐(例如校验密钥0b01,即2位将占用一个字节的存储空间),二进制尝试时可能会占用更大的网络占用空间。
证人解析可能会变慢。

带宽效率研究

· KV-Witness实例实施

我们需要能够证明格式的正确性。它应该能够在以太坊主网的所有区块上运行。

为此,我已经在turbo-geth存储库的一个分支中实现了这种见证格式:kv-witness-research。

此实现已在5.000.000–8.000.000的以太坊主网上的Google Cloud中进行了测试。

如何重复实验?

您至少需要200GB的可用空间和至少32gbs的RAM(该代码是PoC,而且优化程度不高)。

1)复制kv-witness-research branch of turbo-geth (commit aa6b4dc609b3d871c778597a71ac08601f17de53
2) (在我的例子中花了1天的时间)同步主网的header和body:运行./cmd/geth--syncmode staged--datadir~/stateless chaindata/
3) (在我的例子中花了17天)在这个数据上运行无状态原型。

go run ./cmd/state stateless --blockSource ~/stateless-chaindata/geth
/chaindata --statefile ~/kv_witness_statefile --witnessInterval
5000000 --statsfile ~/stats_kv_witness.csv 2>&1 | tee debug.log

这样您应该在stats_kv_witness.csv中获得与本文档相同的统计信息。

见证二进制格式

见证人从包含版本:header的单字节标头开始。

然后,有一个见证人body,它由大小(1-4个字节,取决于见证人元素的数量)和elements本身组成。

每个elements均以单字节type开头,其后为键字段,该键字段是任意大小的字节数组,其前缀为大小字节(就像body一样),后跟实际数据。

数据取决于元素的类型:

对于存储叶子,它是由字节大小决定的任意大小的字节数组;

对于代码叶子,它也是一个任意大小的字节数组,并以大小字节为前缀;

为了证明,它是一个固定大小的32字节哈希值,没有任何大小的前缀;

对于帐户来说,它更复杂,但基本上是:

标记字节(掩码,用于告知帐户元素是否没有默认值)

随机数,8个字节(如果随机数!= 0)

balance(如果balance!= 0),任意大小的字节数组,以其大小为前缀;

存储根哈希(如果不是空的根哈希),32字节,固定大小的字节数组;

代码哈希(如果代码不为空),32字节,固定大小的字节数组。

最后我们得到这样的结果:this: [<header> <witness_elements_count> <element1_type> <element1_key_size> <element1_key_byte1> ... <element1_value_size> ... <element2_type> ...]

关键词:比特币新闻 币牛牛

转载自比特币新闻网(www.btc268.com),提供比特币行情走势分析与数字货币投资炒币最新消息。

原文标题:KV-Witness会不会是另一种高效区块见证方法?

原文地址:http://www.btc268.com/news/btc/24283.html

本文来源:币源编辑:币牛牛

本文仅代表作者个人观点,与本网站立场无关。

本网站转载信息目的在于传递更多信息。请读者仅作参考,投资有风险,入市须谨慎!

'); })();