区块链的全节点与轻节点?

专员之前跟大家聊过区块链存储的相关的话题,其实大家都知道,随着时间的不断流逝,区块链上的交易会越来越多,随之也就造成了区块链的数据容量不断增大,由于区块链的冗余备份,要求所有节点都需要保存全量的数据文件,这个时候,假如有一个用户想用自己创建一个区块链节点来进行DApp的开发,但是又不想参与共识,其实对于这个用户来说,同步大量的数据是一件很耗时的事情,并且十分浪费相关的硬盘资源。

因此,专员今天想来跟大家讲一下区块链中的全节点以及轻节点的概念,专员的思考角度其实主要也是从以太坊这种账户模型去思考,今天也以以太坊作为例子来说这个事情。

以以太坊作为例子

在说全节点与轻节点相关介绍之前

专员首先向来跟大家说一下以太坊的区块头相关的东西,以太坊区块的存储主要分为两个部分,分别是Header和Body,Body其实比较简单,就是一些的交易列表,还有Uncle Block的相关信息,但是其实更为复杂的其实是Block Header,如下图所示Block Header里面会存比较多的数据,比如说父区块的区块hash,时间戳,挖矿的难度值等等相关的参数,

但是专员觉得,其中最重要的当属以太坊中的“三棵树”,与此对应在区块头中的就是,StateRoot,TransactionRoot和ReceiptRoot三个哈希值。

在以太坊中什么用来存储区块数据的核心数据结构。

利用了一种叫做Merkle-Patricia Trie(MPT)是Ethereum用来存储区块数据的核心数据结构。

最简单理解是一个倒置的树形结构,每个节点可能有若干个子节点,在最底层,也就是叶子节点,把数据分成若干个小的数据块,计算出相应的Hash与之对应。

但是往上层看去,Merkle树并不是直接去运算根哈希,而是把相邻的两个节点的哈希合并成一个字符串,然后运算这个字符串的哈希,这样每两个哈希就能够得到了一个”子哈希“,而这个自哈希就是他们的父节点的哈希值。

于是以此类推

依然是一样的方式计算哈希值,可以得到数目更高级节点的新一级哈希,最终必然形成一棵倒挂的树,到了树根的这个位置,这一代就剩下一个根哈希了,我们把它叫做 Merkle Root。而在以太坊中,还对Merkle树做了相应的优化,在Merkle树的基础上进行前缀树的构建,因此也就通过前缀树能够快速查询相关的数据信息,但是这个专员今天不细讲,有兴趣的同学可以私下去研究一下。

因此通过Merkle树,其实我们可以做到几个事情:

1. 快速重哈希:其实就是说,能够在树节点变化的情况下,根据上次的计算机结果通过计算部分值就可以计算出一个新的Merkle Root。

2. 轻节点扩展:采用Merkle树,我们可以再公链的环境下,扩展一个轻节点。轻节点的特点其实就是,只需要存储Block Header,而不存储全量的交易列表等信息。通过Merkle证明来判断一笔交易是否在现在的区块链交易列表中。这样,其实造就了以太坊的轻节点能够运行在小容量的个人PC等终端设备上。

下面说回以太坊

在StateRoot,TxHashRoot和ReceiptHashRoot,分别取自三个MPT的计算结果:stateTrie, txTrie, 和receiptTrie的根节点哈希值。这样的话,比如说我们在进行Block的同步过程中,通过比对收到的TxHash,可以确认transactions列表是否同步完整,通过StateRoot来判断节点间状态是不是一致的。

因此在以太坊中,所谓全节点,其实就是同步所有区块链数据的节点,包括各种区块Body,交易列表等等相关信息。但也是因为节点全量数据都保存的情况,我们不需要相依赖中介去进行数据的验证。

而所谓的以太坊轻节点(轻客户端)

每当有区块出现在网络便下载区块头,而不是全量的情况状态,并发送客户端需要的特定状态的默克尔证明(Merkle proofs)的请求。同时在以太坊轻节点中使用分布式哈希表来追踪前缀节点,而不是直接采用LevelDB进行直接的存储。

文末

综上,其实不论是轻节点还是全节点,都有存在的价值以及意义,我们可以根据自己的需求去选择部署相应的节点,虽说必然全节点的优势会比轻节点大,但是由此造成的就是全节点的资源损耗也必然会大很多。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180810G1BR7W00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券