以太坊一种可升级的可信存证智能合约设计与实现

存证作为区块链的一个重要应用场景，在各个公链中都有已落地的应用和服务。本文将介绍在以太坊上的一种可升级的存证合约的设计与实现。

本文作者—六天

一、存证业务模型

存证业务的核心是确权，业务逻辑相对比较简单，一般分为存证方和取证方。

• 存证方负责将需要确权的数据进行上链；
• 取证方在需要时可以在区块链上查询到存证内容和该内容的所有者。

如果存证的内容本身能够自证真实性（如电子合同，已有相关参与方的签名），这种业务模型是可以满足需求的。

但是大多数存证场景的存证内容并不能够自证真实，比如你正在阅读的文章，并不能证明作者就是六天，那么为了保证存证方上链的内容是可信的，这时候就需要引入第三个角色审核方。

审核方负责对存证方发起的存证内容进行审核，只有审核通过的内容才能够上链。

如果是在联盟环境中，审核方也有可能是取证方，联盟内的成员对自己审核通过并已上链的内容自然认为是可信的。

在公链的环境中，审核方一般由第三方公信机构担任，存证内容的真实性由公信机构负责审查。

二、需求分析

根据上边的存证业务模型介绍，存证合约需要能够满足以下需求。

1. 只有存证方能够发起存证内容上链
2. 链上的存证数据应该包含存证内容和内容的所有者
3. 可以对已上链的存证进行检索
4. 审核方需要对待上链的存证投票，投票数满足一定条件后存证才能上链

三、合约设计

1.0版

基于需求分析，我们根据最小可使用原则，设计第一版存证合约框架，如下图所示。

在存证合约架构1.0版本中，只需要两个合约，一个用于权限控制的Owner合约，一个用于存证业务的Evidence合约。如果说存证合约任何用户都能够调用，进行存证内容上链，权限控制都可以不需要。

2.0版

在第二版中，我们采用了类似MVC结构，将数据和逻辑分离，并且引入控制层。

对存证的所有请求，都通过控制层进行转发，控制层将请求通过代理转发给逻辑层，逻辑层按照业务逻辑处理后通过数据层进行数据上链。架构图如下图所示。

3.0版

3.0版本与2.0版本在架构上是一致的，核心区别在逻辑层。3.0版本在逻辑层增加了存