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

专员之前跟大家聊过区块链存储的相关的话题，其实大家都知道，随着时间的不断流逝，区块链上的交易会越来越多，随之也就造成了区块链的数据容量不断增大，由于区块链的冗余备份，要求所有节点都需要保存全量的数据文件，这个时候，假如有一个用户想用自己创建一个区块链节点来进行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进行直接的存储。

文末

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