大家都知道,随着时间的不断流逝,区块链上的交易会越来越多,随之也就造成了区块链的数据容量不断增大,由于区块链的冗余备份,要求所有节点都需要保存全量的数据文件,这个时候,假如有一个用户想用自己创建一个区块链节点来进行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进行直接的存储。
文末综上,其实不论是轻节点还是全节点,都有存在的价值以及意义,我们可以根据自己的需求去选择部署相应的节点,虽说必然全节点的优势会比轻节点大,但是由此造成的就是全节点的资源损耗也必然会大很多。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)