分布式账本存证数据库BlockDB产品文档

1.BlockDB简介

1.1.产品理念

目前对于数据的修改审计，大多时候是在用同一等级的数据来保护数据，即，通过额外记录一些数据来描述对于数据的操作。看似可靠，实则是在同一个维度上解决不同维度的问题，这种机制始终无法保证“用来保护数据的数据”本身是被保护且无法篡改的。

区块链作为天然的存证方案，能够从第二维度上保护数据的真实有效。这个第二维度是以时间、算力、共识结合而成的一种高度浓缩的事实（哈希），修改它需要非常大的代价，实践上是不可篡改的。

基于此，越来越多的企业将区块链技术应用到存证领域，以期保留数据的完整修改历史供审计。大量的团队使用了诸如Fisco-BCOS，Fabric，以太坊等链上智能合约方案，通过在传统的区块链上记录数据，配以上层定制化应用，提供区块链解决方案。

然而，这种方案开发成本非常大：

需要了解Fisco-Bcos的原理
自行搭建区块链节点
编写基于Solidity的合约代码
编写基于Java的上链代码
各方自行处理签名、认证等事务

一个普通的存证应用牵涉到的技术非常之多，以目前的区块链推广水平，这些技术壁垒足以阻碍存证设施推广。

BlockDB旨在彻底屏蔽使用区块链进行存证的过程中牵涉到的一切复杂机制。对于参与任何使用了BlockDB的存证系统的参与方而言，BlockDB就如同普通的数据库（如MongoDB，MySQL）一样直观好用，同时BlockDB从底层机制保证了数据的可追溯操作、可信查询、可靠分享和可审计。BlockDB的产生极大地降低了区块链存证业务的部署难度，使区块链数据库彻底平民化，真正做到开箱即用。

1.2.典型场景

1.2.1.数据行为记录

需要追溯数据的全部历史版本（如户籍、学籍、证书等）

需要追溯对数据的全部历史操作（如线上数据订正、变更记录等）

1.2.2.数据多方共享协作

需要去中心化数据交换与上报的场景（供应商与采购方共享数据库，无法抵赖无法篡改）

1.2.3.多种数据存证需求

Append Only（存证型）：数据只可被附加，不可被修改。
Modifiable（留痕型）：数据可以被修改（不可修改主键），留下数据的操作记录。
Full（完整型）：数据可以被修改（不可修改主键），留下数据的所有历史版本。

1.2.4.数据可信查询

虽然不能接触到所有数据，但是需要对特定查询语句进行可被证明的查询时。

例如，我如何证明：【选择数据库中所有18-20岁的男性】所获得的结果

1，可靠性：所有返回的数据都具有某种特性。

2，完备性：所有具有某种特性的数据都已经被返回了。

尤其涉及到无法暴露完整数据库，但是需要对查询方提供查询证明的场合。

1.3.目标客户

1.3.1.单体企业

主要需求：数据操作追溯，数据历史版本查询。

1.3.2.企业联盟

主要需求：多企业数据协作、数据共享，数据确权和责任追溯。

1.3.3.审计方

主要需求：实时审计，数据流转渠道全程不可篡改不可抵赖。

1.3.4.监督方

主要需求：实时监督。

2.产品特性

2.1.1.一键部署，一键记录上链，简单易用，瞬时可查

BlockDB的设计思路是为用户提供可审计的存证服务，向用户屏蔽区块链的实现细节，但是让用户能够感知到区块链对于数据的安全保障。

为了降低部署难度和使用难度，并且为自动化部署提供支持，BlockDB支持全流程的参数注入、快速部署和极简操作。

BlockDB尽可能地与传统文档型数据库所支持的操作贴近，例如支持MongoDB的过滤、排序、聚合语法。

BlockDB能够满足企业级的压力承载能力和业务上可以接受的延迟能力。

2.1.2.查询结果与链上数据对应性

BlockDB创新性地研发了“基于区块链的可信查询机制”，能够为每一条查询语句提供基于Merkle Tree的密码学证据，以证明查询的结果在整个流程中的可信和不可篡改。用户能够完全相信BlockDB返回的查询结果就是目前链上数据的真实反映，查询对象（索引）与链之间应当尽可能缩短距离并且进行佐证。

否则，即时用户通过索引能够查询到历史数据，也无法证明该数据的正确性和权威性。

2.1.3.降低审计沟通成本

审计机构在日常审计过程中往往处于被动，需要大量的精力保证数据的真实性和完整性。BlockDB支持直接让审计机构接入到区块链网络中，共享链上数据库，能够让审计机构清楚直观地拿到可信的一手数据。

2.1.4.业务逻辑与区块链解耦

目前大部分的区块链存证应用数据与业务的结合过于紧密，存证的数据在链上一定要配上智能合约才能被访问。开发难度大，维护成本高。

BlockDB提供了一种将业务逻辑与应用数据解耦的存证基础设施，开发者使用BlockDB就如同使用MySQL、MongoDB一样简单，与此同时BlockDB内置的审计功能可以保证存入的数据具有不可篡改的权威性。

3.竞争优势

3.1.1.传统方案

手动开发：传统基于手动开发的数据共享、历史版本的实现，定制化程度高，各个解决方案提供商没有统一标准，基本上一套系统一种实现方式。

安全性、正确性由各项目的程序员保证，多数未经审计。

Binlog：主要用于数据库异地集群操作同步，能够复原操作，但不能保证复原的权威性，也无法提供查询性能。

System-versioned tables（SQL 2011）：能够被关闭，关闭后对历史表的增删改不会被记录也不会被发现。

3.1.2.区块链数据库方案

Amazon QLDB

完全托管，技术方案封闭，无法被外部接入。
中心化，没有共识（背后根本没有链）
只支持单使用方的数据完整性和可验证性
基于Journal+Current state and index history

BigChainDB

公链数据库，链上执行查询，由节点负责运行查询并且返回数据。性能低下。

智能合约

易用性差，开发难度高，曲线救国。

4.接入方式

BlockDB支持前端应用以多种方式进行数据存证。

4.1.Proxy

Proxy模式将MongoDB作为已有的业务系统和数据库的中间环节，通过代理的方式记录用户对原有数据库的所有增删改查操作，并记录在BlockDB自有数据库中。该方式通过替换原数据库地址上的设施为BlockDB，将BlockDB的下游配置成原数据库，无需对现有系统进行改造即可无缝部署。

4.2.Kafka

BlockDB可提供Kafka的监听适配器。应用程序可以将需要进行存证的数据发送到消息队列。BlockDB消费该消息队列，将数据存储在分布式账本中。

4.3.HTTP JSON RPC

BlockDB可提供HTTP接口，接收应用端的JSON请求，并且将数据存储在分布式账本中。

4.4.Socket（Log4J Appender）

BlockDB可提供Socket接口，接收应用端的JSON请求（格式兼容Log4J的Socket Appender），并且将数据存储在分布式账本中。

5.数据接口手册

无论数据以何种方式流入BlockDB，其内容均以JSON方式传递。

{

"identity": "OperatorIdentity",

"type": "BusinessType",

"ip": "172.28.152.101",

"primary_key": "RecordPrimaryKey",

"timestamp": 1561375556,

"Data": {}

}

各项属性解释如下表：

存储在BlockDB中的数据形式一般为如下格式：

{

"_id" : ObjectId("5d404c6478a2710f7fa6227e"),

"type" : NumberInt(4),

"hash" : "0xc4e5e4413121a68d1054ad5c1819df81131587088f7ddd43bed61cf42f4c1d71",

"parentshash" : [

"0x237944d504e4c37c5f7c3318737c0ef8bd5ae9a29d2c4a0453f7b4fc329684a9",

"0xceb6ae7f3fccabc6732bcd1648d168a67cbbe80f72995f647e7c08ad5a7e4880"

"accountnonce" : NumberInt(1),

"height" : NumberInt(625),

"publickey" : "",

"signature" : "0x",

"minenonce" : NumberInt(1),

"weight" : NumberInt(203),

"version" : NumberInt(0),

"data" : {

"identity" : "user_id_234823",

"type" : "test",

"ip" : "222.333.22.33",

"primarykey" : "unique_id_2852",

"timestamp" : "2019-07-30 21:55:47",

"data" : {

"my_array" : [

"It",

"supports",

"array"

"my_inner_object" : {

"supported" : true,

"when" : "2019-07-30 21:55:47"

"private_data" : "Your own data here"

"before" : "",

"after" : ""

}