关键技术与方法
合同数据的接入及保全方式
在一个基于区块链的合同存证系统中，首先要解决的就是合同数据的接入方式问题，即合同数据如何“上链”。
在区块链网络中，区块数据将被多个节点备份，因此不能将合同文件直接存储在链上，以免造成大量冗余，影响区块链的运行效率。
区块链上只保存合同的轻量级元数据，保证合同信息在存储和流转的过程中只有拥有合法访问权限的用户才可以获取，而合同文件本身则存储在云端。
与公正通（Factom）类似，用户将合同文件上传至云服务器，同时将基于合同内容的Hash地址保存在区块链上。
区块数据仅记录合同文件的数字指纹，而非文件本身。
第三方CA负责用户的身份认证及密钥发放，审计员通过加密通道访问区块数据，通过数字指纹查验合同文件的真伪，提供合同公证服务。
数据的接入及保全方式
具体过程如下：
（1）区块链节点将进程列表重置为空。
（2）用户通过公钥提交请求。
（3）根据用户公钥，区块链网络选择是否接受该请求。
（4）若某个记账节点接收了该请求，则向网络广播该请求被接受。
（5）用户看到请求被接受，然后提交合同条目。
（6）根据合同条目的链标识，其中一区块链节点把条目加入其进程列表，并添加进入相应链的区块中（如果这是该链的第一个条目，那就创建这个新链）。
（7）服务器对网络广播该条目的确认，内容含有条目在进程列表中的位置、条目的哈希值及最新进程列表的哈希值。
（8）区块链网络中的所有其他节点更新该服务器的进程列表，验证该列表，并更新该链的区块。
（9）只要用户可以验证相关的进程列表中包含自己提交的合同条目，那么他们就可以相信它会被成功地被录入区块链。
（10）在一个打包周期结束时，所有服务器确认进程列表高度，计算合同条目的反向哈希，还有被处理区块的一系列哈希值。
（11）一个打包周期内的目录区块是由所有服务器中定义的所有条目区块组合到一起生成的。因此，每个服务器都拥有所有的条目区块、所有的目录区块和所有合同条目。
（12）使用反向哈希值的集合来创造一个种子，为下一轮的链标识重新分配服务器。
（13）在完成10个目录区块后，执行以下操作：
1）对最后一分钟的合同条目块创建默克尔树根，按链标识排序。
2）创建最后一分钟的目录区块，并计算其默克尔树根。
3）用10个目录区块的默克尔树根创建一个锚定。
4）用服务器的反向哈希值集合来创建一个种子，再用其选择下一个服务器来把锚定写到区块链上。
（14）返回步骤1。
区块链服务用一种去中心化的方式来收集、打包、安全保护合同数据，并把数据锚定到区块链上。
区块链节点不断变换在系统中所承担的责任，永远不会只有一个节点控制整个系统，每个节点都只是系统中的一部分。
在开始创建一个目录区块的时候，每个区块链节点需要对某一部分的用户链负责。
每一个目录区块内都会为每个有更新的链标识记录下一个区块头，区块头包含着合同条目的哈希值。
记录的哈希值同时证明了数据的存在和在分布式散列表网络中能找到记录的钥匙。个体应用将会关注各种各样的链标识，可以从一个链标识搜索到所有可能相关的记录。
区块头包含了和一个链ID有关的全部合同条目信息。
如果某个条目不是关联到某个区块头的话，那么可以认为这个合同条目并不存在。
这样的设计能让应用程序很容易证伪，方便地识别哪些合同条目是真实可靠的。区块头并不包含合同条目。
比起所有数据都被集合起来放入区块中，这种方式会让区块头的体积更小。把记录从区块中分离出来，也会让数据更加容易审计。
审计员可以在一个单独的链中发布记录，用来批准或拒绝一个普通链中的记录，并添加加密签名来表明此条记录有效或无效。
合同存证系统可以直接采用这个审计员对记录的决定（批准或拒绝），不用再去重新审核一次合同条目，并且只需要下载那些已经被审计通过的合同条目。
多个审计员可以引用相同的记录，单个记录只需要在分布式散列表中存储一次，之后就可以在多条不同的链上被引用。
合同条目的审计是一个独立的过程，可以依靠信任第三方或不依靠信任第三方来完成。
审计是至关重要的，当一个项目被输入系统中，审计人员首先要验证输入是否有效。
审计人员将提交自己的加密签名，表示该条目通过了所有审计师认为需要做的检查。审计要求的条件实际上是区块链的一部分。
以购售电合同为例，审计师会仔细检查交易电量、电价是否符合当地标准。如果交易的规则能够用计算机语言描述，则应用程序可以下载有关的数据，并进行自我审计和审核过程。
该应用程序可以下载数据条目，验证数据条目，并决定条目是否有效，从而使该应用程序建立起对系统的感知。通过基于区块链的合同存证应用场景可完成如下可行性验证：
（1）存在性证明验证：通过区块链证明电子合同在某个时刻的合法存在。
（2）开展第三方合作：如公证、证据鉴定、司法服务等。
（3）区块链数据层的云存储扩展的可能性验证：将数据文件存储在云端，区块链上仅保存该数据文件不可篡改的指纹信息，节约区块链上数据存储空间。
