第一节 存在性证明

一个目录块的大小约是64MB。如果平均每个记录区块有5个记录，64MB的目录块将管理着500万个不同的记录。

应用程序通过目录块（Directory Block）可以定位到特定的记录区块（Entry Block），而无须下载所有的记录区块。一个单独的应用只会对一部分ChainID有兴趣。这极大地减小了使用系统时的带宽需要。例如，一个监控房地产转让的应用程序可以放心地忽略摄像机安全日志。

服务器收集记录区块的Merkle根（Merkle Root），然后把它们打包到一个目录块（Directory Block）。十个连续目录块再算出一个Merkle根，这个Merkle根会被记录到比特币区块链。这给比特币区块链带来最小的负担，却又足以保障保全数据的安全，把Merkle根写入比特币区块链的过程被称为锚定（Anchor）。

保全网所在的区块链系统里，目录块（Directory Block）的数据读写需要最多的带宽和存储。用户在建立了自己的链以后，需要保存这个时间点以后所有的目录块才能保证它们的数据能够在它们的链上被找到。

（3）记录区块层（Entry Block Layer）：记录区块层如何管理哈希值和数据。

记录区块（Entry Block）是这个系统的第二个分层。一个个体应用将会关注各种各样的ChainID，在寻找记录的应用需要记录区块，可以从一个ChainID搜索到所有可能相关的记录。

每一个目录区块（Directory Block）内都为每个有更新的ChainID记录下一个记录区块（Entry Block），记录区块包含着条目记录（Entry）的哈希值。条目记录的哈希值同时证明了数据的存在和在分布式散列表（Distributed Hash Table，DHT）网络中找到记录的钥匙。

记录区块（Entry Block）包含了和一个ChainID有关的全部记录（Entry）。如果某个记录不是关联到某个记录区块的话，那么可以认为这个记录并不存在。这样的设计能让应用程序很容易地证伪，方便地识别哪些记录是真实可靠的。

记录区块（Entry Block）本身并不包含记录（Entry）。比起所有数据都被集合起来放入区块中，这种方式会让记录区块的体积更小。把记录从记录区块中分离出来，也会让数据更加容易审计，审计员可以在一个单独的链中发布记录，用来批准或拒绝一个普通链中的记录。审计员可以在记录中添加拒绝的理由。如果一个应用程序信任这个审计员，那么就可以直接采用这个审计员对记录的决定（批准或拒绝），不用再去重新审核一次记录。然后这个应用就可以只下载那些已经被审计通过的记录。多个审计员可以引用相同的记录，单个记录只会存在于分布式散列表（Distributed Hash Table，DHT）中一次。这些记录的容量应该会比刚开始的32字节大很多。忽略列表不需要让应用知道已经被忽略的完整对象。

一个记录会详述一宗土地转让的细节，会根据此类交易的类型决定记录在链的什么位置。一个或多个审计员会在他们自己的链上引用这条土地转让的哈希值记录，并通过添加加密签名来表明此条记录有效或无效。土地转让的文件只需要存储一次，之后就可以在多条不同的链上被引用。

（4）记录（Entry）的创建。

记录是被用户创建并提交到保全网的。通过散列和编码信息，用户可以确保记录的隐私性。如果编码或隐藏数据是不必要的话，那么记录可以替换成为纯文本。

通过记录一份文档的一段哈希值，保全网可以提供基本的发布证明（Proof of Publication）——保全书。待数据提交上链，人们可以生成文档的哈希值，并和之前链块记录的哈希值进行比对，来判断文档是否是当初发布的那个版本。

对数据的处理可以有很大的灵活性，可以出现类似超链接的东西。数据还可以更庞大，但不能过于庞大，数据越大，需要付的费用也越多。这和比特币比较相似。超过100MB的比特币转账数据是可能发生的，但需要支付更多的转账费用。

保全网区块链可以处理比比特币网络里大得多的数据。由于比特币的完整节点需扫描完整的区块链数据，所以区块链体积不能太大。在区块链中完整节点只需要扫描最高级的目录区块（Directory Block），并不需要扫描全部的链块数据。如果不对链数据感兴趣的话，完全可以忽略它。

用一个类似微博的系统进行举例说明。一个人可以制作一条文本记录（Entry）。他会用私钥进行签署，来展示这条记录确实来自他。“粉丝”们可以追踪他发布数据的那条链，随时获取更新。任何有他签署的记录会被“粉丝”们的应用软件识别出来，这记录就相当于一条微博。别人可以通过添加记录到名人的链上来转发这条名人的微博。

（5）记录上链的过程。

区块链中的链是记录的序列，反映了与一个应用相关的事件，如图2.28所示。这些序列是比特币2.0版本链的核心部分，用文件证明了