BigchainDB白皮书，中文翻译

BigChainDB：可扩展区块链数据库

这篇白皮书介绍BigChainDB。BigChainDB填补了去中心生态系统中的一个空白：是一个可用的去中心数据库。它具有每秒百万次写操作，存储PB级别的数据和亚秒级响应时间的性能。BigChainDB的设计起始于分布式数据库，通过创新加入了很多区块链的特性，像去中心控制、不可改变性、数字资产的创建和移动。BigChainDB继承了现代分布式数据库的特性：吞吐量和容量都是与节点数量线性相关，功能齐全的NoSQL查询语言，高效的查询和权限管理。因为构建在已有的分布式数据库上，它在代码层面也继承了企业级的健壮性。可扩展的容量意味着具有法律效力的合同和认证可以直接存储在区块链数据库里。权限管理系统支持从私有企业级区块链数据库到开放公有的区块链数据库配置。BigChainDB是对于像以太坊这样的去中心处理平台和Inter Planetary File System（IPFS）这样的去中心文件系统的补充。本文从技术角度介绍BigChainDB的设计：传统区块链，分布式数据库，域名系统（DNS）的案例分析。我们介绍一个叫作区块链流水线的概念，当把类似区块链的特性加入分布式数据库时，它是体现可扩展性的关键。我们提供了BigChainDB的一个总体介绍，延迟分析和初步的实验结果。 本文以一个案例分析的描述结束。

这不是一个实时更新的文档，2016年6月8日之后的大的更新都在后面的附录中。

1.介绍

1.1 面向去中心化的应用程序栈。

比特币的引入在去中心化计算领域曾经触发了一波新的浪潮。比特币带来了一些新颖的特性：去中心化控制，没有任何人可以拥有和控制整个网络；不可修改，已经写入的数据是不可篡改的（永远）；不需要依赖任何中心实体，在网络中创建和传输资产的能力。

比特币最初令人兴奋起源于它作为一个有价值的令牌，作为一种政府发布货币的替代品。当人们了解到越来越多的底层的区块链技术，他们扩展了这项技术本身（例如，智能合约）和还有应用程序（知识产权）。

随着应用场景的增加，区块链作为一个整体被重构成包含四层程序栈的组件：

1。应用程序

2。去中心化计算平台（“区块链平台”）

3。去中心化处理（“智能合约”）和去中心化存储（文件系统，数据库），以及去中心化通信

4。密码原语，一致性协议，和其他算法

1.2区块链和数据库

当我们使用传统区块链作为数据库时，是看中它提供的存储功能。如果我们以传统数据库标准衡量比特币区块链，比特币区块链非常差：吞吐量只有每秒几笔交易，每个写操作的确认时间延迟是10分钟，总容量只有十几个GB。而且增加节点带来更多的问题：节点数量翻倍的话，网络流量会增加四倍，但是吞吐量，延迟和容量没有任何增加。本质上来说，它不支持查询，是一个NoQL（http://www.noql.com）数据库。

与此相反，现代分布式数据库可以有超过百万次每秒写操作的吞吐量，大于PB级别的容量，极小的延迟，而且吞吐量和容量随着节点的增加而增加。现代数据库，无论SQL还是NoSQL，还支持丰富的插入，查询和访问控制；事实上SQL是国际ANSI和ISO标准。

1.3扩展的需求

去中心化技术有望重新定义现代金融系统，供应链，创意产业，甚至是互联网本身。但是这些野心勃勃的目标需要扩展性：存储技术需要吞吐量达到每秒百万次（或更高），亚秒级别延迟，PB级别（或更大）容量。这些需要超过现有比特币区块链性能好几个数量级。

1.4 BigChainDB：区块链遇到大数据

本文介绍BigChainDB，数据库风格的去中心化存储：一个区块链数据库。BigChainDB把分布式数据库和传统区块链的主要优点组合在一起，加强了扩展性，如Table1所示：

Table1：BigChainDB与传统区块链，传统分布式数据库比较

	传统区块链	传统分布式数据库	BigChainDB
高吞吐量；吞吐量随节点数量增加	-	Y	Y
低延迟	-	Y	Y
高容量；容量随节点数量增加	-	Y	Y
丰富查询方法	-	Y	Y
丰富的权限管理	-	Y	Y
去中心化控制	Y	-	Y
不可修改	Y	-	Y
创建移动数字资产	Y	-	Y
事件链结构	Merkle Tree	-	Hash Chain

我们在企业级分布式数据库的基础上构建BigChainDB，这样它就继承了高吞吐量，大容量，低延迟，丰富高效的查询语言和权限管理。吞吐量和容量随着节点数量的增加而增加。

BigChainDB具有去中心化控制，不可修改和创建传输数字资产等区块链技术的优点。去中心化控制是通过一些有投票权的节点组成的联邦实现，它是一个由超级节点组成的P2P网络（光绕地球半圈需要70微秒，有些金融应用需要30-100微秒的延迟，因为光速的限制，这些节点需要尽量靠近）。投票操作工作在数据库自带的一致性功能层次之上。不可修改/防止篡改通过几种机制实现：分片复制，不允许更新或修改，经常备份数据库，所有交易签名加密，区块和投票。每个区块上的每个投票还包含前一个块的哈希（不包含前一个块的投票）。任何有资产创建权的实体都可以创建一个资产；一个资产只有当新所有者满足加密条件时才可以被新所有者接收。这意味着黑客或者被感染的管理员不能任意更改数据，而且没有单点错误风险。

可扩展性意味着具有法律效力的合约和证书可以直接存储在区块链数据库里。权限管理系统可以支持从私人企业区块链数据库到公开区块链数据库。当我们发布BigChainDB时，我们也会发布一个公开版本。

Figure1: 从一个基本的中心化云计算生态系统（左），BigChainDB可以加入其中，以获得一些去中心化的优点（中），它同样适用于完全的去中心化生态系统（右）。

1.5 去中心化生态系统中的BigChainDB

Figure1 显示了BigChainDB可以用在完全的去中心化环境中，或者作为一个传统中心化环境的扩展。

BigChainDB是去中心化处理/智能合约（Ethereum VM，Enigma），去中心化文件系统（IPFS）和通信组件（email）的补充。它可以包含在去中心化计算平台的高层（Eris/Tendermint）。它可以和身份协议，金融资产协议（比特币），知识产权资产协议（SPOOL），胶协议（pegged sidechain，Interledger）。智能合约中可扩展性的改进帮助完全去中心化的应用程序更好的利用BigchainDB的可扩展特性。

BigchainDB同样也适用于更多的中心化计算系统。一个案例就是只是把存储去中心化就带来了大多数的优点。另一个案例是在现存去中心化处理技术中可扩展性的需求要大于容量的需求；正因为如此，BigchainDB提供了一个通往最终完全去中心化的桥梁。

1.6内容

本文首先给出了相关构建模块的背景：

• Section 2 - 传统区块链的可扩展性
• Section 3 - 分布式数据库

然后介绍BigchainDB，如下：

• Section 4 - BigchainDB描述
• Section 5 - BigchainDB的实现，包括容量和节点 (Figure 9)
• Section 6 - BigchainDB延迟分析
• Section 7 - 私有，公有BigchainDB的权限管理
• Section 8 - BigchainDB测试基准，包括吞吐量和吞吐量（Figure 13）
• Section 9 - BigchainDB发布，包括案例和时间表
• Section 10 - 结论

附录包括：

• Appendix A - 术语，例如 分布式和去中心化的区别
• Appendix B - 区块链可扩展性的建议
• Appendix C - 域名系统（DNS）
• Appendix D - BigchainDB的进一步基准

2.背景：传统区块链的可扩展性

本节讨论传统区块链如何实现可扩展性，尤其是在比特币中。

2.1技术问题描述

一种区块链的定义可以是一种解决了强拜占庭将军问题的分布式数据库，强拜占庭将军问题是指拜占庭将军问题和女巫攻击问题的组合。在拜占庭将军问题中，即使在某些节点出现不可知故障的情况下（包括节点本身的恶意行为），节点需要对数据库的某个值取得共识。女巫攻击问题是指在对某个值获取共识的过程中，一个或几个节点获得大于自己所应占比例的影响力。这是一种“复制攻击”，一些看似不相关的节点一起欺骗系统。

2.2比特币扩展性问题

比特币扩展性问题是指吞吐量，延迟，容量和网络带宽的扩展问题。

吞吐量。比特币网络平均每秒处理一笔交易，理论上最多7笔交易。如果每个块更大的话，吞吐量也可以更大，但是扩大每个块会带来尺寸的问题（见下面的容量和网络带宽部分）。这种吞吐量很多系统相比的话低的不可以接受，比如Visa系统（通常2000个交易每秒，峰值可达10000个每秒）和Twitter（通常5000个交易每秒，峰值可达15000个每秒）和广告网络（通常500000个交易每秒）和传统网络，以及电子邮件网络（全球每天1830亿个邮件，每秒两百一十万个）。一个理想的全球区块链，或者区块链集合需要支持这种高吞吐量的应用场景。

延迟。处理每个比特币的区块链中的块需要10分钟。为了足够的安全性，最好等待1小时好让更多的节点确认这笔交易。相比较，Visa系统的交易最多需要几秒钟。很多金融应用都要求延迟在30-100毫秒之间。

容量和网络带宽。截至本文写作时间，比特币区块链大约有70GB；2015年增加了24GB。下载整个区块链大约需要一整天时间。如果吞吐量增加2000倍，达到Visa的级别，这些增加的交易会让数据库每天增加3.9GB，每年增加1.42PB。如果每秒处理15万个交易，区块链会每年增加214PB。如果每秒处理1百万笔，它会占据所有节点的全部连接带宽。

2.3影响可扩展性的技术

比特币区块链以下这些技术影响了可扩展性：

1.一致性算法：POW。比特币的挖矿奖励机制刺激节点来增加计算资源的使用，但是对于吞吐量，延迟和容量没有任何帮助。一个节点发出的确认平均需要10分钟，所以6个确认要大约1小时。在比特币中，这是设计使然。莱特币和其他山寨币减少了这个延迟，但是付出的代价是减少安全性。

2.复制方式：全复制。这就是说，每个节点保存一个所有数据的复制品；通常这个复制品在一个单一的硬盘驱动器中。讽刺的是，它是中心化的，随着数据的增多，将来只有有足够资源存储所有数据的节点才能参与其中。

这些特点导致比特币无法扩展。

2.4区块链扩展性努力

比特币/区块链社区花了极大的力气来改进区块链的性能。Appendix B详细列举了所有这些建议。

前面这些努力有些共同点：他们都从区块链设计开始来改进其性能。其实还有另外的方法：从大数据分布式数据库开始，然后增加区块链的特性。

3.背景：分布式数据库和大数据

3.1简介

我们有个问题：在分布式数据库中有大规模扩展的先例吗？答案是，有。所有的大型互联网公司，和很多小型公司，使用大数据分布式数据库，包括脸书，谷歌，亚马逊，netflix。

分布式数据库通常存储PB（百万GB）级别或更多的有用内容。相反，区块链数据库存储50GB的数据，只相当于现在一个便携式优盘的大小。尽管区块链有相对较小的大小，比特币社区依然担心他的大小太大了。事实上，现在已经采取了一些行动来避免被垃圾交易污染造成的区块链膨胀。

让我们从另一个角度看这个问题，也许分布式数据库技术可以给区块链的设计上一课。

Figure 2: Netflix在它的Cassandra数据库上测试吞吐量的数据（基于节点数量的客户端每秒写入数量，副本数=3）。x轴是节点数；y轴是每秒写入数。

Figure 2 展示了Cassandra数据库的吞吐量，Cassandra是Netflix使用的一个分布式数据库。在左下角的点，我们用50个分布式的Cassandra的节点，每秒处理174000个写入操作。增加到300个节点，可以每秒写入110万次。三年后的一个后续研究显示几十个节点满足1百万的吞吐量。要强调的是，这个数据库吞吐量的增加随节点数量增加，增加是线性变化的。

每个节点存储数据，确切的说，一个节点只存储所有数据的一个子集，也就是说，每个节点都有副本的一部分。在Netflix例子中，每一部分数据在整个系统中都有三个副本，也就是说，副本因子是3。部分复制使存储容量能够随节点数增加。大多数现代的分布式数据库的存储容量都是随节点数线性增长的，这是一个很棒的属性。进一步，随着节点数的增加，Cassandra的延迟和网络使用量并没有变糟。Cassandra不只可以分布在一个区域中，也可以在全球分布。而比特币的区块链，容量是不能随节点数量变化的。

Cassandra这样的分布式数据库的可扩展性是一个很好的可以借鉴的属性。

3.2分布式数据库的一致性算法

3.2.1简介

上面提到，Cassandra在每个节点上仅存储部分数据。每个比特的数据都在几个节点上有副本。负责复制数据的节点使用一致性算法来保证他们存储数据的一致性。Cassandra使用Paxos一致性算法；相关节点即使在有些节点失去响应时依然能够达成一致。

Paxos一致性算法是在不可靠的分布式系统中解决一致性问题的众多算法之一（是最好的一个，译者认为）。笼统的来讲，一致性问题就是在一些各自独立的计算进程中找到关于某件事情的共识，而这些进程有可能出错，他们只能通过双方的消息进行通信。解决方案由所有非故障节点使用一致性算法。

3.2.2拜占庭容错

一致性问题第一次背景却的描述是在Pease，Shostak和Lamport 1980年的论文中（附件25，26）.这篇论文允许错误节点发生任意错误；例如，他们可以死掉，串通做坏事，选择性参与，假装崩溃。所有这些错误被称作拜占庭错误，在后续1982年的描述同样问题的论文中，被称作拜占庭将军问题。解决分布式系统中拜占庭错误的一致性算法就叫做拜占庭容错（BFT）。

这篇1980年的论文有几个非常好的结论：证明了，如果有f个进程发生了拜占庭错误，至少需要3f+1（低效率）个进程才能保证容错，证明了少于3f+1个进程是无法容错的。论文中还提到了如果消息是经过验证的（如果某个进程在传递消息的过程中改变了该消息，这个改动能被发现）。2f+1个进程就足够了。

3.2.3（良性）容错

最常见的进程错误是失去响应。他们可能是因为硬盘错误或者是CPU过热。这种错误被称作良性错误或者失败停止故障。一个能在分布式系统中解决良性错误的一致性算法叫做容错（FT）。（叫做良性容错更确切些，不过我们说了不算）总的来说，容错算法需要最少2f+1个进程才能最多容错f个进程。

3.2.4 Paxos

最有名的容错一致性算法就是Paxos；它有Lamport在1998年发布（附件27）。从那以后又出现了很多变种（快速Paxos，附件28），所以现在有了整个Paxos算法家族，有些是解决BFT问题的（附件29）。

谷歌的Mike Burrows（谷歌Chubby，BigTable和Dapper的联合发明人）说过，只有一个一致性协议，那就是Paxos，附件30，我们目前可用的异步一致性协议都使用Paxos作为他们的核心（附件31）。Cloudera的Herry Robinson说过，所有其他的方法都只是Paxos的不同版本。 和非常明显，一个好的一致性协议是很难找到的。

Paxos和他的变种在很多公司广泛应用，像Google,IBM,Microsoft,OpenReplica,VMWare,XtreemFS,Heroku,Ceph,Clusterix,Neo4j等等。

Paxos非常难于理解而且实现起来有风险。为了解决这个问题，Raft就是被设计出来的一种容易理解，实现风险低算法。Raft有一个BFT的变种，叫Tangaroa。

3.2.4 FLP结论

一个异步进程是指一个进程不能保证在一定时间内会给你返回结果。异步建模非常常见，特别是在全球分布的巨大系统(像万维网)。异步一致性协议是指异步进程使用的协议。

在1985年，Fischer，Lynch和Paterson（FLP）公布了一个令人震惊的结论：没有一个完整的一步一致性算法可以发现，甚至即使是一个未知的进程死掉（FT）（附件35)。如果这是真的，那就很难容错其他错误了（所有其他错误）！实用的一致性算法可以通过假设某些同步属性（部分同步，弱同步），或者允许某种概率性的一致性（经过一定时间达到一致性的概率）来达到FLP结论。

比特币一致性算法实现后者：没有人能确定比特币网络关于某个区块达成一直与否，这个区块总是有可能只是个分支。所有能做的也就是估计这个区块在主链中的概率。

3.2.6 实用拜占庭容错一致性算法

早期的拜占庭容错一致性算法要么很慢，要么代价昂贵，要么是适用于同步系统（附件36，37，38，39）.在1999年，所有这些都改变了，Castro和Liskov发布了他们名为“实用拜占庭容错”（PBFT）（附件40，41）.就像题目中描述的，这篇论文描述了一个实用的拜占庭容错一致性算法，引起了一个寻找实用拜占庭容错一致性算法的小高潮。这项研究现在还在继续，Aardvark（附件42），RBFT（附件43）和Stellar（附件44）就是这些为了增加速度和可靠性的实例。

3.3 复制因子和区块链“所有节点”

现代分布式数据库设计的更像一个整体的单一数据库，但是在底层，它把存储在整个网络中分布到很多便宜的存储设备上。每个数据记录都冗余存储在多个驱动器上，所以当一个驱动器出错时，数据可以很容易的恢复。如果一次只有一个磁盘出错，那就只需要一个备份驱动器。基于多少个磁盘同时出错的假设的估计，这种风险可以非常小。现代分布式数据库通常每个数据对象都有三个备份，也就是说备份因子是3（附件45）。

相反的，比特币有6500个全节点--备份因子是6500.所有节点（假设节点间完全独立）同时出错的概率是1/8760的6500次方，或者10的-25626次方。这种概率大概是3万亿年会发生一次。说这个数据过度保护都是温和的了。

当然，硬件错误不是数据丢失的唯一原因。网络节点遭到攻击有更大的概率丢失数据。一个针对两三个挖矿池精心计划好的攻击有可能从现有的比特币网络中去除50%的算力，网络需要大约两周后的工作量复杂度调整才能恢复使用。

3.4 强项和弱项

我们来看看使用像Paxos这样的分布式一致性算法的数据库的强项和弱项。

强项。正如上面讨论过的，Paxos是一个已经证实了的一致性算法，可以良性容错（已经开发出他的扩展可以进行拜占庭容错）。它使用在大数据分布式数据库中，具有如下能力：高吞吐量，低延迟，大容量，高效的网络使用，支持各种形式的数据，包括表格样式的SQL界面，对象结构的NoSQL数据库，图形数据库，而且他们以一种理智的方式处理复制。Raft，一种Paxos的变种，使分布式一致性系统容易设计和部署。

弱项。虽然他们的技术属性和性能是非常好的，但是传统的大数据分布式数据库也不是完美的：他们是中心化的。他们由一个单一的官方发布并控制，而不是像区块链一样是去中心控制的。这就有可能造成一些错误。中心化数据库是：

• 被一个单一的管理员控制，所以如果管理员帐号被入侵，那么整个数据库就被入侵了
• 可修改，一个黑客可以修改一个五年前的数据而不被任何人发现（假设没有其他任何安全检查）。例如，这将阻止警察在印度考试丑闻中获取证据（附件47）.在区块链中，篡改过去的交易通常是非常困难的，即使有人真的修改了过去的一个交易，这个修改也很容易被发现，因为这笔交易的hash值被存储在另一个区块中，检测程序会发现一个hash的不匹配。
• 参与者有不同利益时不适用，当他们不想把控制权让度给一个单一的管理员。例如，音乐行业的版权所有者不共享一个单一的数据库的一个原因就是有可能失去对信息管理权控制的风险。
• 无法停止女巫攻击，一个错误的节点可以淹没整个系统的投票。
• 传统上不支持创建和传输数字资产，只有数字资产的的所有者，而不是数据库管理员才能传输资产。
• 通常不开放给公众，读取，更不用说写入了。对公众的开放性对一个开发的应用很重要。一个著名的例外是Wikidata。（附件48）

3.5 BigchainDB系统中的容错

同时解决大型数据库和去中心区块链的可扩展性和不可信的去中心化问题是BigchainDB的主要目标。在设计BigchainDB的安全性时，考虑了以下问题：

• 良性错误：在BigchainDB安装时，数据库节点之间的通信使用像Raft和Paxos这样的容错一致性协议。因此我们假设如果有2f+1个节点，f个良性错误就可以容错，数据库中的所有节点看到同样的写入顺序。
• 拜占庭错误：为了在不可靠网络中运行，BigchainDB合并了针对系统中节点恶意和不可预测行为的检测。这些包括，针对交易的投票和区块的确认。完全实现拜占庭容错的努力已经在路线图上，将会使用常规安全审计进行测试。
• 女巫攻击：在一个高进入门槛基于信任和声誉的节点联邦中部署BigchainDB可以阻止发动克隆攻击。例如DNS系统，就是一个活生生的互联网范围分布式联邦。附件C描述了DNS是如何成功的在十几年间运行一个去中心化系统的。

4 BigchainDB描述

4.1 原则

BigchainDB从大数据分布式数据库开始，增加区块链特性，而不是向上扩展区块链技术。这样就避免了折磨比特币的技术选择，例如，全复制。

我们在一个企业级的分布式数据库上构建BigchainDB，在它的基础上，BigchainDB继承了高吞吐量，大容量，全NoSQL查询语言支持，高效的查询和权限管理。可以通过增加节点来增加吞吐量和容量。

既然大数据数据库本身包含内建的一致性算法进行良性容错，我们就直接使用这个。我们避开这个算法，让他自己决定那个交易去写入，以及每个区块的顺序。我们不允许节点间私自的，点对点的通信，只允许数据库内建的通信，这样来解决复杂性问题和减少安全性风险。这意味着恶意节点不能把一个消息传给网络中的一部分节点，再把不一样的消息传给网络中的另一部分。每次一个节点说，其他节点都听。

4.2 高层描述

我们致力于把下面的区块链特性加到数据库中：

1. 去中心化控制，没有人拥有或者控制整个网络
2. 不可修改，已经写入的数据是不可篡改的（永远）
3. 创建和传输资产的能力，不需要通过中央节点

通过使用类似DNS的有投票权的节点联邦来实现去中心控制。其他节点可以连接以读取和提出交易；这使它成为一个超级P2P网络（附件2）。投票操作是在数据库内嵌的一致性方法之上的。合法多数就是大多数选票。在速度方面，每个区块在合法多数验证和投票之前就已经写入了。链接发生在投票阶段。每个区块有一个id，这个id就是它的交易，时间戳，投票人列表，创建者公钥的哈希值。它还有一个加密的签名和投票列表。当一个区块第一次被写的时候，区块不包含前一个区块的哈希（id）。相反的，投票随着时间被附在区块后面，每个投票都有一个“前一个区块”的属性，这个属性等于它前面一个区块的哈希值。不可修改/不可篡改通过几种机制来实现：分片复制，不允许更新或者修改，经常的数据库备份，所有交易加密签名，区块和投票。任何有资产生成权限的实体都可以生成资产，新的所有者只有在能够满足以前所有者的加密条件时才可以获得这个资产。这意味着黑客或者被感染的系统管理员不能任意修改数据，而且也没有单点故障的风险。

4.3 架构

Figure 3： BigchainDB系统的架构。有两个大数据分布式数据库：一个存储来到的交易的交易集合Backlog S（左边），一个保存排序号的不可更改交易的区块链C（右边）。已签名的节点运行BigchainDB一致性算法来更新S和C，还有他们之间的交易（txs）

Figure 3 展示了BigchainDB系统的整体架构。BigchainDB系统提供给客户端类似单个区块链数据库的API。在底层，实际上有两个分布式数据库（也可以是两张数据表，没有本质区别），S（交易集合或待办交易Backlog）和C（区块链），通过BigchainDB一致性算法（BCA）连接。BCA在每个已签名节点上运行。未签名的客户端可以连接到BigchainDB；基于权限，他们可以读取，生成资产，传输资产，Section 7展示了更多。

每个分布式数据库S和C，都是一个现成的大数据数据库。我们不干扰这些数据库的内部工作；这种情况下，我们利用这些数据库的可扩展属性，和版本控制以及经过测试的代码。每个数据库都运行他自己的Paxos类似的一致性算法来保证一致性。

第一个数据库保存待办交易Backlog-未经排序的交易集合S。当有新的交易到来时，由接受节点验证它，如果有效（基于接受节点的判断），就存储到S中（来晚的相同的交易会被节点拒绝接收）。接收节点会随机的把交易发送到其他节点。

假设有N个已签名节点。S k = {t k,1, t k,2, . . . }是发送给节点k的交易集合。

运行BigchainDB一致性算法的节点k按下面的流程处理S中的交易：它把交易从无序的S k中，移动到一个有序的列表中，为这些交易创建一个区块，把这个区块放入第二个数据库C中。C是一个区块的有序列表，每个区块连接着他的父区块和它自己的数据，这样就构成了一个区块链。

一个已签名的节点可以对一个区块进行投票，决定它有效，还是无效。为了作决定，已签名的节点检查区块中的每个交易的有效性，如果发现一个无效的交易，已签名的节点就把标志为无效的票投给这个区块。如果没有发现无效的交易，就为这个区块投票“有效”。

每个区块在没有已签名节点投票时，状态为“未定”。一旦对某一个区块，大多数投票有效或者无效，区块的状态从“未定”变为“已决定 有效”或“已决定 无效”。一旦状态决定，就可以把它当成已经刻入石头了（不可更改）。这个过程类似于比特币区块链中的多次确认的方法。

一个区块链中的区块B，有ID，时间戳，实际交易，投票信息。Section4.5精确描述区块，交易和投票。

4.4 行为描述

这一节介绍交易从一个客户端到指定服务器节点的流程。每个节点有自己的待处理交易Backlog S和区块C的视图。

Figure 4 和后续的Figure描述了高层的架构，每个卡片是一个物理机。客户机在左边，客户机连接到BigchainDB服务器节点（可投票节点），在右边显示。每个客户机都可能发送交易到任何BigchainDB服务器节点。

Figure 4: 左图：待办交易S开始时是空的，区块C开始时只有一个初始区块。右图：客户端在S中插入交易，把他们分别分配给1，3和2号节点。

在Figure 4的左图中，一个客户端有一个ID为#A的交易和有效负载（Payload）。BigchainDB的待办交易（Backlog）S为空；区块C只有一个为空的初始区块。其他的客户端也有要传输给服务器节点的交易。

当一个客户端提交一笔交易，接收节点把它分配给某个联邦节点，很有可能是它自己，然后把它存储到待办交易S中去。Figure 4 的右图显示了这种状态。我们看到节点1被分配了ID为#A，#G，#H的三笔交易。节点3被分配了ID为#B和#E的两笔交易，节点2被分配了ID为#D和#C的两笔交易。还没有任何东西存储在区块C中。

Figure 5：左图：节点1把它分配到的交易从待办交易Backlog S移动到了区块C

右图：节点3也已经处理了它分配到的交易。

Figure 5 左图显示了这个状态，节点1已经把分配给它的交易处理完成。它从待办交易S中取出交易#A，#G，#H，创建一个区块保存他们，然后把这个区块写入链C中。这个区块指向C中的前一个区块。

Figure 5 右图显示节点3已经处理了所有非配给他的交易，也把他们作为一个块，写入链C中。

当把一个区块第一次写入C时，起始状态是“未定”。每个服务器节点可以给这个块投支持票或者反对票。如果一个区块里的所有交易都是有效的，而且它前面的区块没有“未定”的，那对这个区块就只能投支持票。一旦对于一个区块得到支持或者反对票达到多数，这个区块的就会从“未定”变为“已决定有效”或者“已决定无效”。

在这个例子中，节点1创建的区块得到了投票，变为已决定有效。然后，节点3的区块得到投票，变成已决定无效。在Figure 5 右图中，白色背景表示已决定有效，阴影背景表示已决定无效。

Figure 6： 无效区块中的交易重新插入到待处理交易S中，以备重新考虑。

当一个区块整个被认为是无效的，这个区块中的一些交易可能是有效的，所以BigchainDB再给他们一个机会。Figure 6 显示如何实现：交易#B和#E重新插入到待处理交易S中重新考虑。Figure 6 同时显示BigchainDB如何存储无效的区块。在链C中有个区块是无效的。但是BigchainDB不会删除这个区块，既然这个区块已经标志为无效，没有必要删除，磁盘空间不是问题，保留所有的区块可以使它快速而且简单。同样的，在已经投票的区块上，投票还会继续，因为继续直接投票要比多一步来判断是否要继续投票快速和简单。

Figure 7： 左图：多个客户端可以连接一个给定节点。右图：有多个节点，通常，一个客户端连接一个节点（随意选择一个）

Figure 7 强调多台机器如何配置。Figure 7左图显示多个客户端可能连接一个给定的节点。Figure 7 右图显示有多个节点，每个节点都有一个显示待处理交易Backlog S和链C的视图。

4.5 数据模型

4.5.1 交易模型

BigchainDB存储的最基本的记录就是交易。有两种交易类型：创建交易和传输交易。一个创建交易在BigchainDB中创建资产记录，包含他的描述，原始所有人，接收者需要满足的条件。一个传输交易把资产的所有者给到新人，分配新的条件。

一个交易以JSON文档的形式显示成以下结构：

• id: 交易transaction中所有内容的哈希值，fulfillments中的每个fulfillment都设为null。id也是数据库主键。
• version：交易模型的版本号，这样就可以支持不同版本的交易模型
• fulfillments：满足条件的列表。每个满足条件包含一个指向未消费资产的指针和一个加密了的满足条件用来满足这个未消费资产的条件。一个满足条件通常是一个证明资产所有权的签名。
• conditions：条件列表。每个条件都是一个需要被满足的加密的条件，用来传输交易时传输所有权。
• operation： 表示操作的字符串（现在要么是“CREATE”，要么是“TRANSFER”）。它决定这笔交易如何验证。
• timestamp： 交易创建时的世界调整时间（UTC）。有客户端提供。
• hash：序列花后的payload的哈希值
• payload：可以使任何JSON文档。在传输交易中，可以为空。

交易，条件，满足条件的详细解释超出了本白皮书的内容，可以参看BigchainDB的文档和Interledger协议。

4.5.2 区块模型

一个区块代表一个如下结构的JSON文档

• id：block序列化后的哈希值。也是数据库主键；这样来保证所有区块的唯一性。
• block：
  • timestamp：区块创建时的时间戳，由创建区块的节点提供。
  • transactions：区块中交易的列表。
  • node_pubkey：创建区块的节点的公钥。
  • voters：联邦节点的公钥列表。既然联邦的大小会随时间改变，这个告诉我们在区块创建时，多少个节点在联邦中，这样我们能检查这个区块收到了正确数量的投票。
• signature：创建区块的节点给区块的签名。（创建一个签名，节点先序列化区块内容，再用私钥签名）
• votes：初始是一个空列表。当投票从节点中来到时，添加在后面。

4.5.3 投票模型

每个节点为每个区块生成一个投票，添加到这个区块的投票列表后面，一个投票有如下结构：

4.6 区块验证和区块链管道

Figure 8 BigchainDB区块链C中的管道。投票在每个区块中累积。投票在每个区块中可以不停的累积，即使他们的父，祖父区块是“未定”状态。关键在于当增加一个新区块时，这个区块可包含那些不依赖于未定区块中的交易的交易。

Figure 8 显示了一个区块链C的例子。初始区块B1有一个空交易。

底层数据库决定了写入C的区块的顺序。这意味着当一个签名节点把一个区块插入C，它不能同时投票（因为一个投票包含前一个区块的引用，但是前一个区块现在还未知）。只有在写入操作完全提交之后，区块的顺序才会变得清晰。

区块顺序确定后，节点们对区块进行投票。当一个区块被创建，状态是“未定”。当大多数投票是支持或反对时，区块的状态从未定改为已决定有效或者已决定无效。

记住，不像通常的区块链，BigchaiDB的区块模型不指向前一个区块。相反，它有一个投票列表，每一个投票指向前一个区块（投票节点基于对它的changefeed视图的考虑）。我们称之为“投票时进行链接”。

通常情况下，所有的投票都连接同一个前区块，但是不同的投票有可能声明不同的区块是同一个前区块。如果一个节点出故障，这个就有可能发生。当它重新上线后，没有什么可靠的方法可以恢复在故障期间丢掉的新区块的顺序。那前区块id应该怎么设置呢？我们会实验多种方法（像把id置为null，或者大多数投票的id）。

如果一个节点出现故障，当它恢复后，它不会有那个它必须投票的很长的区块列表。因为需要为某个区块投票的节点列表是在区块创建时指定的，如果节点出现故障，它就不会在这个区块的需要投票的节点列表上。

区块B2已经收到了5个可能投票中的3个。在这个例子中，所有的投票都是支持。既然多数投票为有效，那这个区块为已决定有效。

区块B3已经收到了5个可能投票中的5个，支持，反对，支持，两个反对。既然大多数节点投票反对，这个区块就是已决定无效。因为所有投票显示它无效，它可以仍然在链中。当检验以后的交易时，它会被忽略。保持区块不动，我们可以快速在链中处理子区块。

区块B4是未决定，因为它还没有收到足够多的支持或反对票，对B4的投票在继续。

尽管B4是未决定，它依然有子区块B5，这很关键。这成为可能是因为，我们使用数据库内在的一致性算法决定区块的顺序，逻辑上我们写区块和投票是分离的。即使在数据库层面，“分岔”也不是一个风险，更不用说在代码层面的支持了。这是因为每个节点在同一条区块链上工作（而不是每个节点有各自的不同的区块链副本），每个节点通过数据库通信，这种方式基本上就是一种开放的广播形式（而不是各自一对一的通信）。因为如此，每个节点都可以试图添加一个区块，但是只有一个能成为B4的子区块；剩下的遵循内在的一致性算法。就好像一条铁轨，后一条枕木的位置依赖于前一个。在一个未定的区块后面添加时，我们不需要等待-就好像Figure中B6那样，我们积极的铺设轨道。

当父区块未定时，我们需要做一件事来避免多次消费：任何新区块中的交易都不能依赖于未定区块中的交易。例如，新交易的输入不能在未定区块的输入中。通过两种方式加强这一点，在未定区块上创建新区块时，这样的重复消费是被禁止的，投票时，任何包含这样交易的区块都被投票为无效。

我们叫它“区块链管道”是因为这个让我们想起了微处理器的管道。微处理器同时启动执行多个指令。当微处理器发现指令顺序不对，它会核对输出，忽略无用的结果。应用微处理器管道，区块链管道处理速度很快。

4.7 BigchainDB一致性算法（BCA）

BigchainDB一致性算法是一个运行在每个已签名节点（服务器）上的状态机。这节介绍BCA的python伪码。

4.7.1主循环

在每个已签名节点上开始mainLoop()函数之前，数据库Backlog S和C必须被创建和初始化。一个初始化的步骤就是在C中创建初始区块。

Listing 1 有关于BCA的高层伪码。它显示了在每个签名节点k上运行的mainLoop()函数。每个签名节点都运行同样的mainLoop()。

第四行强调了所有的节点都可以同样的访问数据库Backlog S和C。BCA把数据从交易集合S移动到区块链C，偶尔也会相反操作。

Listing 1：BigchainDB一致性算法。这个算法在每个签名节点上运行。

第五行是主循环的开始。所有剩余的伪码都是这个循环的一部分，一直运行直到这个节点关闭。

第六行接收交易到S中，把他们分配给节点，第七行把没排序的交易移动到排好序并按区块分好组的C中，第八行是在未定的区块上投票。

Listing 2： 并行版的BigchainDB一致性算法

Listing 1 中的伪码是假设只有一个单一的进程写的，但是每个主要步骤都可能是分开的，独立的进程。事实上，有可能有多个进程做同样的事情；这样可以极大地改进性能。Listing 2 显示了这样的伪码。

4.7.2 分配交易

Listing 3 算法是分配交易的：

Listing 3 assignTransactions()函数是主要程序，它分为两个主要步骤：接收和分配来到的交易（第二行），重新分配旧的交易。

Listing 3 assignNewTransactions()函数显示一个节点如何从一个客户端接收一笔交易并把它分配给另外的节点。接收节点首先检查这笔交易是否有效。如果无效，会发送一个错误信息给客户端。如果有效（从接收节点来看），就把它随机分配给另外的节点。我们分配交易给节点，而不是由节点来抓取，因为分配可以大规模减少在区块链创建端所要的重复消费检测，这样就提高了吞吐量。我们认为分配节点是确定的，例如基于交易的哈希值。但是这样也会有问题，如果一个恶意的节点重复把一个坏的交易插入C，然后这笔交易被踢回给S，然后这个恶意节点就又有了同样的交易。相反的，我们以以同样的概率随机分配节点，除了本节点k，这样可以避免重复投票。

在这个算法中，第七行接收交易，然后在其中循环处理；第八行检查交易的有效性；第九行以同样概率选择把这笔交易分配给哪个节点；第十一行记录分配时间（原因见下一个算法）；第十二行实际把交易分配给选定节点。

Listing 3： 接收及分配交易程序

Listing 3 reassignOldTransactions()函数重新分配旧的交易。当一个节点关机，变慢，被感染，出故障时，交易会过期。通过把过期时间足够长的交易分配给新的节点，就可以避免一个节点上的交易陷入两难境地。它循环所有分配来的交易（18-19行），如果一笔交易过期足够长（20行），就为它随机选择一个新的节点（21行），设置新的分配节点（22行），交易从旧节点（节点j）分配到新节点（节点i）。为了让这个程序运行正常，它也需要为没有分配的交易设置交易时间，在assignNewTransactions()函数中实现（11行）。

4.7.3.区块上增加和投票

Listing 4 addBlock()函数创建和在C中添加一个（非初始）区块，以一组要延迟的交易结束。

Listing 4： 增加普通区块的程序

2-3行初始化程序的主要变量，要增加的区块Bnew，要延迟到以后再添加的交易Tpostpone。

4-17行创建一个区块，以C中的一致性算法的顺序添加到C中。4行把Btail指针指向最新的区块C。当剩下的程序在运行，增加新的区块时，在这里获取Btail而不是运行中计算它，这很重要。5行初始化添加到区块中的交易列表的顺序，7-10行一次增加一个。如果交易t依赖于一个未定的区块（存在多次消费风险），它会被添加到Tpostpone中，来延迟到另外一个区块中。否则，如果它被认为是有效的，就添加到Tnew中（9-10行）。否则，它会被丢弃。11-14行创建了一个区块，并加到C中。

Listing 4 15-16行当区块被正常添加时会出现。那些已经在C中的新交易，可以从S中删除，15行就是清除Sk。16行把需要推迟的交易加回，例如那些因为依赖于未定区块而存在被重复消费风险的交易。

Listing 5. 在区块上的投票程序。

Listing 5：在区块上投票的程序voteOnBlocks()是节点k上为还没有投票的区块投票的程序。

注意，一个节点有可能给已经被决定的区块投票，因为这样做比先查询区块是否已经被决定了要速度快。3-8行在节点k上遍历最旧（2行）到最新区块（7行）。对于每个区块，4行在区块B中的所有交易是否有效，5行存储B的投票B.V，由节点k签名。6行把潜在的有效的交易发送回S。

4.7.4 验证交易

Listing 6： 验证交易程序

Listing 6描述了决定交易有效性的程序。

transactionsValid()函数是一个在循环所有在交易列表T中交易的顶层函数（3-6行），如果任何交易被发现无效，这个程序返回False。

transactionValid()函数基于传统的区块链方法（错误格式，多次消费，等等）检查一个交易是否有效，在11-12行，而且看它是否依赖于未定的区块（13-14行）

dependsOnUndecidedBlock()函数说明什么是依赖于一个未定的区块。

4.8.一致性算法检查表

既然设计了BCA，我们就描述下担心的事情。

区块构造顺序。当创建了一个区块，这个区块就不允许再添加任何交易到期中了。这是为了保证在这个区块之后创建的区块可以检查他们的交易没有多次消费前一个区块中的交易已经消费过的资产。如果一个区块创建完成后还可以加入更多的交易，这个就不可能实现。

哈希投票。 有交易被损坏是因为投票没有被哈希？这个看起来好像是个问题，因为在所有投票进入之前，区块的哈希可以传播给它的子区块。一个初级的答案是有第二条哈希链来真正包含投票。但是这种方案可以更简化：一个没有投票的哈希是可以的，因为投票是被签名节点数字签名的，因此不能被损坏。

丢弃交易。如果一个节点出故障，分配给它的交易会怎么处理？这些交易会被丢弃吗？在我们最初的设计中，回答基本是不，因为所有交易都存储在S中，直到他们提交到一个区块中。但是，如果一个节点出现故障，或者出现别的问题，分配给这个节点的交易可能就不会被处理。我们增加了一种方法来解决这个问题，如果前一个节点的分配过期，我们就重新分配交易：Listing 3中的reassignOldTransactions()。

拒绝服务。有发起攻击的客户端或者恶意的服务器节点能重复调用一些交易，使之完全占用网络吗？就我们所知，相对于传统网络服务来说，这已经不是个问题。

客户端交易顺序。我们必须确保由同一个客户端发出的有一定顺序的交易以同样的顺序被处理--最起码是有一定偏差的同样的顺序。当一个客户端发送两个交易到同一个节点，那个接收节点在把它们写入待处理backlog前，是可以修改他们的顺序的。这个不正确的顺序可能被RethinkDB的changelog保留，所以所有的节点会看到同样的错误的顺序。在写的时候，我们考虑了几种可能的解决方案，包括使用客户端提供的时间戳来确定多节点的一致性。

数据库内嵌的通信的方式的脆弱性。节点通信使用大数据数据库内嵌的一致性算法，像Paxos来容错良性错误。这个脆弱吗？回答是很多节点都出现问题才会发生严重的后果。

多次消费。有多次消费的方式吗？这是个在开发所有阶段要问的有用的问题。BigchainDB使用和比特币网络同样的方法。所有以前的交易都被检查来确定输入没有被消费过。这个在BigchainDB可以很快，因为可以使用底层的数据库优化查询。

恶意行为。问题：BigchainDB如何检测一个节点有个坏的行为（拜占庭）？它不鼓励坏的行为吗？如何做的？回答：总的来说，因为使用联邦模型，这是一个简单的问题。当一个节点对一个区块的投票与大多数不同时，坏的行为可以被检测到。有很多可能的方法来不鼓励坏的行为，从由联邦检测的手动惩罚到要求提交一个安全保证金，然后根据坏的行为自动丢弃保证金。

管理员成为上帝。系统管理员由权利让他们扮演上帝吗？这样会造成单点错误。我们仔细的限制系统管理员的权利，甚至比一个投票节点都小的权利。就我们所知，因为所有的写交易（包括更新软件）都需要联邦的投票，系统管理员无法扮演上帝的角色。

离线节点。问题：如果一个投票节点离线会发生什么？如果多个离线呢？回答：一个或者几个离线节点是没问题的，因为法定人数（决定一个区块的节点数）还是在线的。如果很多节点离线，那么一个区块就会困在未定状态。（那些依赖于这些未定区块中交易的交易也会被困在待定backlog中）我们的解决方案是等待，直到有足够多的节点上线来投票和决定区块。这是一个合理的方案，因为所有的一致性算法都需要一个最小部分的节点在线才能工作。另一个替换方案是超过一个有限的时间，一个区块就会从未定标志为已决定 无效，这样所有的交易可以被复制回待处理backlog来重新考虑。

区块链表而不是交易链表。问题：为什么我们要把区块链接在一起，而不是交易呢？回答：有很多原因。第一，每秒写1000个区块（每个区块含1000个交易）要比每秒写1百万个交易容易的多（写入到区块链数据库中）。第二，每个投票节点只需要给每个区块附加投票，而不用给每个交易附加，节省了很多存储空间。（如果投票节点投赞成票给某个区块，我们就可以确定这个区块中的所有交易都是有效的）。最后，当构建一个投票，投票节点必须计算一个加密的签名。这会消耗时间的。我们通过只给每个区块签名来节省时间（而不是对每个交易签名）。

4.9 交易验证，激励和本地资产

当确定一个交易是否有效时，需要做很多事情。签名必须有效。某些字段必须存在（其他必须没有）。多个值必须有正确的语法。如果这个交易是创建或者注册新资产，那么这个资产不能已经存在了。如果这个交易传输一个资产，那么这个资产一定要已经存在，传输交易一定要被现有的所有者请求（现在的所有者必须用私钥签名），而不是由前一个所有者或者别的非所有者请求。“你只能消费你拥有的”

每个投票节点检查每个交易的有效性（所以它才能决定怎么给这个交易的区块投票）。回忆下BigchainDB的一致性是基于联邦的。一个节点给交易投票是取决于它是否被赋予了投票节点的角色。和POW模型对比下，POW模型里一个节点是投票节点的概率是和他的哈希计算能力成正比的，假设所有的矿工拥有最新的硬件同样的电力消耗；或者POS，即一个节点是投票节点的比例取决于它的内存大小。

传统上说，区块链持有两种类型的资产。“内部资产”，像比特币和莱特币，是构建在核心协议中的。一致性使用这个资产来检测交易的有效性和以内部交易费用给投票和挖矿节点奖励。第二是在核心协议上的表层协议的非内部的“表层资产”（例如。SPOOL[10]）。但是，这个传统的内部资产和奖励的方法有弱点：

• 表层资产重复消费。传统的区块链一致性模型对于表层资产不可靠。在核心协议层面没有机制来防止表层资产的重复消费。
• 网络参与的内部资产摩擦。传统区块链投票节点需要在内部资产上获得收入，所以任何新的网络参与者必须获得内部资产，通常在进行交易前，是交换。在新的区块链获得内部资产是非常困难的，尤其是资产还没有在很多交换中可用时。和传统的网络服务相比这是一个比较高的门槛，这里的传统网络服务如，任何新参与者可以通过支付一个标准的金额来进行交易，就好像信用卡支付一样。

BigchainDB通过下面的方式克服了这些问题（如同在Table 2中所示）：

• 在每个资产上内部一致性投票。每个交易跟踪它正在操作的资产，再链回创建这个资产的交易。每个资产在用来检查交易有效性上都是内在的。这就克服了表层资产多次消费的问题。
• 网络参与的低摩擦。就像一个传统的网络服务，网络操作者设置如何加入网络和处理交易的方法--但是在这里，网络操作者是投票节点的集体意志。投票节点也决定用户如何为交易付费。

Table 2：内部资产验证和激励

4.10 激励和安全

在POW和POS区块链中，网络，激励模型，网络安全是不可避免的连接在一起的。安全是系统的根本。但是就像在第二节和附件B中讨论过的，POW和POS有扩展性的问题。虽然这是一个双刃剑：当激励是系统的根本的时候，就会有动机欺诈系统。一个例子就是矿池的出现就是为了在比特币内嵌的激励机制中获利（挖矿奖励）。

在一个像BigchainDB的联邦中，每个节点的安全和整个网络的集合安全是非固有的，这意味着机密性，可用性和完整性都在核心网络设计之外。例如，如果所有节点安全条件弱，网络会被攻破。相反的，如果最少一部分节点有合理的安全标准，整个网络作为一个整体可以抵抗攻击。外部激励可以有有点：在一个私有的部署中，网络参与者仅有的激励措施就是成为网络的一部分（例如，更低的成本，更少的欺诈，新功能）。外部激励也可以在一个公有的部署中工作，一个简单的原因：投票节点可以有他们自己的原因让一个公开，开放的数据库存在，例如，受托成为一个非盈利组织，获得合理的利益。（7.5节中）。

5. BigchainDB实现细节

5.1 选择分布式数据库

BigchainDB设计的足够灵活以适应很多种类的现有分布式数据库。当然，我们先选择了一个在上面构建。为了决定选择哪个，我们首先确定了标准，然后增加了相应的指标。

有超过100个数据库可以选择，在51和52中列了出来。这里是我们的一个简表：Cassandra，HBase，Redis，Riak，MongoDB，RethinkDB和ElasticSearch。每个数据库都是用Paxos算法，或者是Paxos的继承者Raft。

首先，我们对我们列出来的数据库做了简单的性能调研：每个都有每秒每线程15-105的写入速度，每秒每线程290-1000的顺序读取速度，80-400每线程读取速度。

在不同数据库之间，性能会有差异，关键要注意的是，性能是每线程的性能：线程增加，性能改进。这和传统的区块链技术不同，传统区块链性能会保持不变，或者变坏。

尽管所有的测试过的数据库都有良好的可扩展性，我们注意到其他的指标更加重要。特别是：

1. 一致性。分布式数据库一定在性能和一致性上做了妥协（在CAP定理中，不在ACID中）。对于一个区块链，一致性是说交易的顺序可以置信，所以我们倾向于有强一致性保证的数据库。
2. 自动修改提醒。一个节点发现数据库发生改动的一个方法是在一个固定的时间询问（轮询），但是这样做没有数据库自动提醒节点有改动的效率高。我们希望数据库自动提醒是一个标准功能。

自动修改提醒带来另一个好处：他们改进了防篡改（超过了一个哈希链所提供的）。如果一个黑客不知怎么成功删除或者修改了数据中的一条记录， 哈希值修改了（就好像所有区块链一样）。进一步，有自动修改提醒的数据集会通知所有的节点，这样就可以马上更正这个改动，恢复哈希的完整性。

经过考虑，我们发现RethinkDB最好的满足我们的需求。它有强一致性保证，它提供自动修改提醒（changefeeds）作为一个标准功能。因此我们在RethinkDB上构建我们的第一个BigchainDB版本。

RethinkDB是一个有灵活查询语言的JSON（NoSQL）数据库。它优化了可扩展实时种子，它是一个有用的协作应用，流分析，多用户，实时市场和连接设备/物联网。它由C写成，开源，有一个生机勃勃的社区。

在将来，我们预计多种分布式会区块链化正如在本文中提到的。有一天每个关系型数据库，文档存储和图形存储都会有一个区块链版本。

5.2 BigchainDB容量

RethinkDB集群中每个节点都会增加整个数据库的容量。

例如，如果每个RethinkDB节点都运行在亚马逊网络服务（AWS）的d2.8xlarge实例上，那么每个实例都贡献了他的24X2000GB=48000GB的存储到数据库中。32个节点就有32X48000=1536000GB的总容量，比1PB还多。（这个计算没有加入副本，如果副本因子是R，总容量就要除以R）

作为一个快速参考，Figure 9 显示总容量如何依赖于节点数量。

Figure 9 BigchainDB的容量和节点数量。每增加一个节点都会增加48000GB到总容量中。

5.3 序列化

在我们哈希或者签名一个JSON信息（交易的内容）前，我们必须用标准的方法把它转化成一个字符串（不管使用什么编程语言或者何种计算机架构，结果都是同样的）。这就是说，我们必须用标准的方法序列化JSON信息。幸运的是，这里有个标准：RFC7159[66].

我们用python-rapidjson中的dumps()函数序列化JSON，它是一个rapidjson的python版本的包装函数（一个用C++写成的快速的和RFC7159兼容的JSON解析器/生成器）。这里是我们如何调用它：

这是参数的含义：

• data是JSON的信息，以Python 字典结构存储。
• skipkeys=False：确保所有关键字都是字符串
• ensure_ascii=False: RFC推荐使用UTF-8编码来确保良好的互操作性。通过把ensure_ascii设置为False，我们可以允许Unicode的字符，把它们强制编码成UTF-8
• sort_keys=True：输出以关键字排序

5.4 加密

这部分介绍BigchainDB使用到的加密算法。

5.4.1加密哈希

所有的哈希都是用SHA3-256算法计算得来的。我们在BigchainDB中存储16进制的哈希。这里是用pysha3实现的一个python例子：

5.4.2关键字和签名

我们使用Ed25519公钥签名系统来生成公钥/私钥对（也叫验证/签名）。Ed25519是Edwards-曲线数字签名算法的一个实例（EdDSA）。截至2016年4月，EdDSA在IETF上还是Internet-Draft状态，但是它已经被广泛使用。

BigchainDB使用Python中的ed25519包，被cryptoconditions库重载。

所有关键字默认都以base58编码。

6.BigchainDB交易的延迟

一个关键的问题是一笔交易要花多长时间才能被写入石头（写入一个已确定 有效的区块中）。开始回答这个问题，我们跟踪一笔交易t的一生，从一个客户端发出它，到这个客户端得到确认它已经在已确定有效的区块中。Figure 10和Figure 11演示了交易的一生：

每一步需要的时间间隔是不同的。它取决于一个节点有多繁忙，一个集群有多繁忙，网络延迟和其他因素。尽管这样我们依然能判断交易生命周期的每一步，来决定延迟的主要来源。

通常讲客户端会在互联网上发送他们的交易t到一个BigchainDB节点。传输时间tin取决于客户端距离BigchainDB节点多远，但是它通常范围在几十到几百毫秒（ms）之间。一旦t在已决定有效的区块中，一个BigchainDB的节点会发送一个成功的通知给客户端。这个传输时间tout大约和tin一样。Figure 12 显示了tin和tout

我们可以把总的延迟写成：

ttotal=tin+tinternal+tout

tinternal是内部延迟：由BigchainDB集群造成的延迟。tin和tout取决于客户端，但是tinternal和客户端无关。本节后续部分主要是对tinternal做一个估计。

我们从一些记号开始。在BigchainDB有很多延迟源，但是关键的一个是信息从一个节点到另一个节点花费的时间。我们把节点到节点之间的一个典型的跳跃延迟叫做thop。thop所花费的时间非常大的依赖于节点是如何分布的。如果所有节点都在一个数据中心里，那么thop有可能小于1微秒。如果数据节点在全球分布，那thop有可能达到150微秒。

另一个主要的延迟源是查询延迟tq。如果一个节点查询后端（分布式）数据库，有可能发生这个节点本身已经有了需要得到结果的所有的信息。这不是很常见，我们忽略这种可能性。更常见的是，需要的信息在一个或多个其他节点上。得到这些信息需要最少2个网络跳跃：一个是发出查询，一个是得到查询结果。在这种情况下，我们写成这样：

tqp是查询所需时间。

如果集群中的所有节点都在一个数据中心中，那么thop和tqp可能在花费时间上很接近，所以相对thop来说我们不能忽略tqp。

我们回到找tinternal总共需要的时间。通常来说，它可能非常大，因为一个交易有可能在待处理Backlog S和区块bigchain C之间来回反复，直到它最终进入已确定有效的区块。我们能做的就是估算一个最小的tinternal（很少来回往复）。

当t到达BigchainDB节点时，这个节点做一个简单的验证（不检查它是否依赖于在未确定区块中的交易）。这最少需要一次查询（检查是否重复消费），所以需要的时间最少时tq。（如果t无效，那客户端会得到通知，t就到此结束了）

如果t有效，那么BigchainDB节点把t随机分配给一个节点。然后把t写入Backlog（S）。底层的分布式数据库会通知其他所有节点这个关于S的改动（这里有个新的交易），包含t的内容。最少要用thop时间来在整个内部BigchainDB网络上传播。

接着t进入被分配到节点的一个队列的尾部，在这里它等待被分配节点检查它的有效性（包括它是否依赖于一个未定区块中的交易）。通常来说，在这个队列中，t的前面会有一些交易。被分配的节点一定要先检查那些交易；每个检查最少要一次查询，对于每个t前面的交易最少需要tq时间。在最好的情况下，被分配节点的队列中t前面没有交易，所以等待时间为0.

等到t轮到被检查，被分配节点一定要检查它是否有效（包括它是否依赖于一个未定区块中的交易）。这最少需要tq时间。如果t确实依赖于未定区块中的交易，那么它一定要回去一个区块中等待被再次检查（回到被分配节点队列的末尾）。

假如t在一个区块中没问题。我们叫这个区块B(t)。t必须等待B(t)积累够1000（或是其他设定的值）笔交易或者超时（比如说上一个交易加入区块5秒钟之后）。超时是为了保证区块不会永远等待新的交易。当有很多交易到来的时候，相对于时间thop，t等待区块B(t)被填满的时间可以忽略，我们可以忽略它。

被分配的节点接着把B(t)写入C中。它需要把B(t)传播到集群中所有节点：最少thop。

每个签名节点会发现这个新区块B(t)，包括它的内容。签名节点k会把新来到的区块加入到它需要投票的区块队列的结尾。k的B(t)的本地副本会等待k的队列中在所有B(t)前面的区块上投票。在最好的情况下，k的队列中B(t)前面没有节点，所以等待时间为0.

一个节点在一个区块上投票要多久呢？如果一个区块中有1000笔交易，那么这个节点就需要检查所有1000笔交易的有效性。（并不是总要检查所有交易，如果发现有一个无效的，就可以停止不再检查更多了）一旦有效性检查完成，这个节点必须生成一个投票（数据结构）和计算它的数字签名，但是这个时间和检查有效性相比可以忽略不计。

节点不需要依次检查每一笔交易的有效性。可以并行同时检查很多交易，取决于多少进程可以来做有效性检查。原则上来说，同时是有足够的可用处理器来并行检查所有交易有效性的。因此，在最好的情况下，给一个节点投票所需的时间和检查一笔交易的有效性大体相当：tq。

当B(t)到达k队列的头部时，B(t)有可能已经被确定了，但是k无论如何都会投票给它（k不会花时间检查B(t)是否已经被确定了）。就像前面说到的，在B(t)上投票最少需要tq时间。

一旦B(t)得到大多数签名节点的投票，它就会变成已决定有效或者已决定无效。（可以为B(t)投票的节点列表在B(t)创建时就已经确定了，即使在集群中增加或删除节点都不会改变），投票需要thop传播到集群中的所有节点。

如果B(t)是已决定无效，那么B(t)中的所有交易（包括t）都会给发回S，以便在新的区块中做进一步考虑。

如果B(t)是已决定有效，那么t就会被“写入石头”，一个成功的通知信息会发送给客户端。

我们现在可以通过把前面列出来的所有时间相加来估计一个最小的tinternal：

然后用等式（2）

如果集群里的节点分布的非常广泛，thop就比tqp大很多：

对于广泛分布的集群，最小内部延迟要比节点到节点的延迟大一个数量级。（记住tinternal忽略客户端到BigchainDB的网络延迟）

这里有一些常见案例，依赖于BigchainDB是如何分布的，Table 3 总结

阅读这个表格的时候要注意：1）Table 3中的最小内部延迟是数量极的估计。它们只能被看成是期望值。2）在一个数据中心，查询延迟tqp可能和thop在一个数量极上，所以为了更好的估计最小内部延迟，我们需要估计tqp。

7.私有和公有BigchainDB，以及认证

7.1.介绍

BigchainDB在设计上，权限管理在核心上面一层。我们已经看到了很多关于私有公有版本BigchainDB，隐私以及认证的问题。在我们看来，一个丰富的权限管理框架是技术的基础。这一节介绍权限管理，角色，私有BigchainDB和隐私。然后有一节扩展到公有BigchainDB，我们相信这很重要。最后讨论了认证和给角色赋予权限。

7.2权限，身份和角色

权限管理是一个用户可以如何操作一部分数据的规则。权限管理应用在所有计算环境中，从共享文件系统（Dropbox，google drive）到本地文件系统（Windows，iOS和Linux），再到分布式数据库。我们希望区块链数据库有丰富的权限管理系统。

这些系统中的权限管理的理念可以启发我们的设计。在Unix中，每个文件或者目录有三个角色（所有者，所有者群组，其他）和三种权限（读取，写入，执行），就有了一共9中权限值。例如，权限值“rwxr--r”是指所有者可以读取，写入和执行（rwx）；所有者群组可以读取，但是不能写入和执行（r--），其他人没有权限（---）。

一个BigchainDB数据库实例的特点是每种身份有其自己的权限。Table4和Table5分别给出了公有和私有BigchainDB的权限管理的实例。这个可以大致上和企业内网及公共互联网进行类比。稍后我们会进行详细解读。

身份表示唯一私钥的所有者，可以对每种交易类型赋予权限。权限，如上表所示：“Y”表示这个身份可以执行该交易；“O”表示如果该身份是资产所有者就可以执行该操作，所有者是指拥有该资产的私钥；“P”表示当资产所有者把权限给某个身份后，可以执行该操作。大多数交易都需要投票节点投票来批准或否决，除了读取交易之外。

一个角色就是一组独立的权限。角色帮助权限分配，帮助用户澄清分配给他们的权限。角色可以根据上下文自己定制。一个身份可以有多个角色，这个身份的权限就是所有角色权限的和。

BigchainDB的核心协议的包括尽可能少的动作和交易类型，为了保证最大的向后兼容性和最小的复杂度。表层的协议可以增加新的特性，例如针对单一资源所有权的SPOOL，增加类似委托，验证正确交易的动作，Table4和Table5每个都有核心协议动作和SPOOL中的表层协议动作。

7.3.私有BigchainDB

一个私有的BigchainDB在一组利益相关方中建立，在多种多样的场景中来辅助，验证他们之间的交易，就像交换的安全，提高供应链透明度，管理支付的版税。例如，音乐产业可以构建一个可信的网络，其中包含唱片公司，音乐家，收集协会，唱片店，流媒体服务和支持提供商例如律师和沟通代理人。一个运营私有BigChainDB的利益相关方联盟可以组成一个“企业可信网络”（ETN）。

Table 4展示了一个在企业可信网络中使用的私有BigChainDB权限管理实例。

第一列显示允许的动作；第二列显示这个动作是否需要投票；3-9列是角色；最后一列表明这个动作是否在BigChainDB的核心协议中。

一个拥有投票节点角色的身份可以对资产动作进行投票。其他角色都不可以这么做。

投票节点可以更新其他任意身份的权限。修改权限需要其他节点的投票一致通过。这就是新的身份如何进入系统后获得权限或者角色，和增加移除投票节点的方法。

一个投票节点可以提议更新投票节点的软件。投票节点只有当取得一致性后就会更新软件。投票节点为了可以投票还需要可以读取资产。

具有系统管理员角色的身份，就好像一个投票节点，可以提议更新权限和投票节点的软件。这个角色在投票节点的软件没有更新到最新版本时非常有用；当然，它可以只提议软件而且确保投票节点对于更新达成一致。系统管理员角色为了能够调试软件出现的问题，必须也可以读取资产。

发行者角色的主要任务是产生资产。但是它也可以做交易者角色能做的所有事。

交易者角色操作资产的交易，让别人代表它操作交易，对资产进行整理和授权。当资产所有者被标明为“O”时，它可以把所有权转让给一个身份；或者作为一个资产的接受者。类似的，如果它是所有者，它可以把资产委托让另一个身份以它的身份交易；或者在接收端作为受托人。默认情况下，读取的权限是关闭的，但是交易者可以允许其他人读取这个资产的信息。交易者可以添加任意数据或文件到一个资产中。

代理/受托人角色获得交易者权限的一个子集，只是可以代表所有者转让所需要的权限。

我们在section 7.6中描述认证者角色。

为了简化描述，和实际实现相比的一些细节被忽略了。例如，通常一个受托人必须接受一个委托请求。

7.4隐私

问：A银行不希望B银行看到他们的交易。但是如果他们都是投票节点，B银行可以看到A银行的交易吗？

答：这个不关BigchainDB的事；它不关心交易的内容。对于需要验证的交易，它只需要有一个现在没有被消费的输入和一个正确的签名。

问：但是如果每个投票节点直到交易中每个节点的身份，可以知道交易的总数以便于验证交易，那么这样不会失去隐私吗？

答：交易中的节点只是公钥。公钥和身份之间的对应关系由A银行和B银行负责。如果他们希望隐藏交易的总数，他们可以做到。BigchainDB不关心这个。

假设A银行创建了一个输入A，把它给了PUBKA，在数据区域它说这是一个给B的输入，B只是一系列数字。BigchainDB确保输入A只能被消费一次，而且只有PUBKA可以消费它。这其中不包含数量。

7.5公有BigchainDB

7.5.1介绍

BigchainDB可以配置成更加公开，任何人有权限产生资产，交易资产，读取资产和认证。我们正在致力于第一个公有的BigchainDB。

7.5.2动机

去中心化技术有潜力使互联网进入新时期，除了目前的开放和民主外，还要更加容易使用和可信。它本质上是民主的，或者最少是去掉中间环节的。它也值得信赖：加密使不需要信任的陌生人之间安全可靠地交易行为成为可能，不需要一个品牌作为代理。

这个论述围绕公有和私有部分的优点。在公有部分，最显著的优点是在未来互联网的形态中，尤其是万维网。这些技术从根本上重构了过去二十年的社会。九十年代网络开始于开放，自由精神和民主。在过去的15年中，力量在社交媒体和云上。全世界的人必须相信而且依赖于这些服务，它们提供了早期互联网没有的可靠，好用的服务。但是这些服务是极其中心化的，由中心节点严格控制，存在被犯罪分子或者国家攻击的脆弱性。

去中心化对社会承诺了一个巨大的积极地影响。一个这种中心化系统的解毒剂，通过去中心化网络重新设想和重构我们的互联网，使人们可以控制他们自己的数据和资产，而且拥有在互联网分发的能力。

7.5.3公有BigchainDB的角色

Table 5描述了一个公有BigchainDB的权限管理。这里BigchainDB被配置成每个用户可以做任何事情，除了像投票，管理，认证之类的敏感角色。关键的，用户可以产生资产，读取所有资产；这是开放式区块链的一个重要功能。

7.5.4公有BigchainDB联邦守护者

在公有BigchainDB的核心是“守护者”：组织中拥有投票节点角色的身份。一个拥有这个角色的身份可以投票支持或者拒绝一笔交易，可以投票决定是否把投票者角色分配给另一个身份。（注意：一个组织可以拥有多个身份，所以一个守护者可以有两个或更多的拥有投票节点角色的身份。）

作为开始，公有BigchainDB作为投票节点角色会有5种身份： 3个有ascribe所有，2个有ascribe选定的其他组织所有。也就是说，公有BigchainDB开始有3个守护者：ascribe和其他两个。从这里开始，更多的守护者会被现有的守护者选中添加到联邦中。守护者会有不同的利益来避免勾结，但是一定要有一个共同点：他们必须在心中有互联网的利益。在选择守护者时，在组织中会有一些倾向：非盈利，为去中心化互联网创建基础技术；区域上，语言上，特定授权上的多样性。

正确的组织结构是公有BigchainDB成功的关键。管理问题一直折磨着比特币区块链。我们可以把这些教训考虑到公有BigchainDB的设计中去。我们咨询了律师，开发者，学院，积极分子，潜在的守护者来开发一个强壮，稳定的系统，同时足够透明可靠，足够灵活的满足网络的需要。

最终，公有BigchainDB会在它自己的法律实体下完全独立运营。他选择自己的守护者和设置自己的规则---但是它总是会把自由，开放去中心化的互联网作为长期的目标。

我们正在收集一组潜在的公有BigchainDB节点。如果你认为你的组织有合适的节点，或者有建议的节点，请联系作者。

7.6 BigchainDB资产认证

认证者角色给认证和证书授权机构提供了一个正式的位置。例子包括信用打分代理，对绘画作品辨别真伪的专家，发放学位的大学，发放许可的大学，为文件盖章的公证机构。

然而BigChainDB可以在没有认证者角色的情况下运行良好，在一个去中心网络中，任何人都可以产生资产，有一点非常清楚，第三方机构可以为资产买家提供更高层级的信任服务。

这些第三方机构做的事情和现在授信的第三方机构一样--作为一个托管机构，盖许可章，产生一个认证，或者对一个资产生产者的信用或质量进行打分。

对于将要生成的认证，交易者使一个身份对某一资产拥有读取和认证的权限，然后认证者审查关于这个资产的所有相关信息，生成一个报告作为交易。

资产所有者然后可以创建一个加密的防伪证明书，一个包括从各种认证机构获得的所有数字签名报告的数字文档。这个防伪证明书也经过了数字签名，所以即使打印出来，也可以发现是否被篡改。这个防伪证明书被销售者作为正品认证，用来显示资产是真实的。

公有BigChainDB不应该是指定的--它应该是对新的认证源开放的。认证的发放也不一定限制在传统的认证机构中。BigChainDB在这方面很灵活，对用户创建的方法保持开放。BigChainDB因此限制他的角色来提供一种可靠地收集签名数据机制。

我们假设一个丰富的可以签名的社区官方。例如，软硬件创建点的提供商可以认证某个数据产品是由他们的软硬件在某个时间点创建的。个人也可以留下对电影，餐馆，消费品，甚至其他人名声的认证。其他例子可能出现在预测市场中， 证券发行，安全的评级。

在任何人都可以对某人某事发表官方评价的模型中，认证者的声望就至关重要。你怎么知道哪些认证可以信任？我们预计社交媒体信用系统的开发要超过Facebook的朋友及点赞系统。BigChainDB启用广泛实现的新的信用系统，像管理分布式合作的Backfeed协议，或由Cory Docrorow和Daniel Suarez规划的虚构的声誉经济，以及其他。

8. 实验结果

8.1目标

BigChainDB的算法设计是避开底层数据库的，所以我们希望主要的性能方面的限制在底层数据库和物理计算机资源的交流上（写入速度和节点间的I/O）。因为如此，BigChainDB是构建在Rethinkdb上的，我们以测试Rethinkdb的扩展性开展实验。

完整的BigChainDB性能测试指标会在近期发布。

8.2吞吐量实验

附件D1描述了实验环境的细节。

在一个试验中，我们每十秒增加节点的数量，一直到32个节点。我们使用Rethinkdb系统的统计表格记录了写入吞吐量随时间的变化。

Figure 13显示每次当节点增加时吞吐量如何增加。当节点数达到32时，写入吞吐量超过了每秒1百万写入交易（每秒写入1000个区块，每个区块有1000笔交易）。

Figure 14 显示同一个实验中的数据，只是它显示写入吞吐量如何随节点数量变化（而不是时间）。这幅图既无趣有令人兴奋：它显示写入吞吐量如何随节点数量变化。

8.3其他实验

附件D包括更多的实验描述和结果。

9. BigchainDB部署

9.1BigChainDB用例

很多BigChainDB用例就像传统的区块链用例，只是聚焦在需要高吞吐，低延迟以及更大存储的情况上；而且强大的查询和权限管理也很有帮助；既然它好像一个NoSQL数据库，开发也很简单。例如，BigchainDB可以处理大容量付款处理器的吞吐量，而且在数据库端直接存贮合同和其他实际交易的相关文档。另一个例子是比特币2.0应用，能保证应用扩展的情况下交易成本合理。

一些BigchainDB的用例也和传统分布式数据库一样，除了集中在区块链有益的特性上：去中心，不可修改，创建和传输数字资产的能力。

BigchainDB用例包括：

• 根据许可证链跟踪知识产权资产。BigchainDB可以减少连接创作者和观众之间渠道的许可的摩擦，给出了数码产品的完美出处。一个典型的音乐服务有3千8百万首歌--BigchainDB可以在一瞬间存储这些信息，包括每首歌的许可证信息和订阅人信息。在另一个例子中，考虑一个中等的照片市场，每天有10万交易；把它放入比特币每天需要花费10000美元，占用比特币网络。
• 收据和认证。BigchainDB通过为电子操作提供不可抵赖的证据来减少法律纠纷。而且，BigchainDB足够大可以支持把收据和认证信息都直接存储到数据库中，而不是连接到外部文档或存储在哈希中。
• 具有法律约束力的合同可以直接存储在BigchainDB中，在交易的旁边，以人和计算机都可以阅读的格式。
• 创建和实时移动大容量金融资产。只有资产的所有人可以移动资产，而不是像以前的数据库管理员。这项能力减少了花费，减少了交易延迟，使新的应用称为可能。
• 在整个供应链中跟踪大容量物理资产。BigchainDB可以帮助仿冒，节省大量花费。每个RFID标签都可以放入BigchainDB中。
• 智能合约（去中心过程），应用城区必须是完全去中心化的，而且数据库功能是关键。
• BigchainDB获得大量数据流的数据科学应用，数据科学家在他们的数据挖掘和分析任务中可以轻松查询BigchainDB。

9.2交易加密

通常BigchainDB中存储的交易是不加密的，但是用户可以根据他们的需要选择合适的加密技术加密数据。（交易的数据可以是合法的JSON格式，最大尺寸在后面描述）交易的其他方面，像现在所有者的公钥，新所有者的公钥，没有加密，也不能加密。

9.3 BigchainDB的限制

因为BigchainDB是构建在现有的大数据数据库上的，它继承了这些数据库的限制。

第一个版本的BigchainDB是构建在Rethinkdb上的，所以它继承了一些Rethinkdb的缺点，包括每个Table最多32个分片（正在扩展到64个）。对于Rethinkdb文档（交易）的大小没有硬性限制，内存性能的原因，推荐限制在16M以内。大文件可以存储在任何地方，只是把文件的路径或者哈希存储在交易数据中。

9.4BigchainDB产品和服务

我们预计BigchainDB有以下的产品和服务：

1. BigchainDB：一个高吞吐，大容量，低延迟，丰富查询支持，和权限管理的区块链数据库。
   1. 对于大型企业和工业联盟创建新的私有可信网络，利用区块链可扩展的能力和增加现有区块链的查询和其他的数据库功能。
   2. BigchainDB就像其他数据库（或定制版本）一样，部署即可用（通过服务，或者用户直接自定义的方式）。
   3. BigchainDB会有像REST API，特定语言绑定，RPC（类似比特币）和命令行之类的接口。在他们下面是一个创造性的内核协议，创造性的资产表层协议，和一个自定义的表层协议。
   4. BigchainDB支持具有法律效力的合约，合约自动生成而且以一个人机都可读的格式直接存储。这里有为创造性协议的创造性的合约，或者自定义协议的自定义合约。
   5. BigchainDB提供加密的COAs，可以自动生成，直接存储在BigchainDB中。会有创造性版本和自定义版本。
   6. BigchainDB是构建在大型开源现存的数据库代码基础上的，这些代码被很多大型企业使用测试了很多年。新的代码会被安全审计以及开源。
2. BigchainDB作为服务，使用一个公有的BigchainDB实例，或者一个有灵活权限管理的私有的BigchainDB。
   1. 为那些想用区块链数据库的优点，而又不想费力自行搭建私有网络的开发者。
   2. 为那些想扩展区块链数据库作为他们服务的一部分的云提供商和区块链平台提供商。
   3. 为那些想把交易成本控制在合理范围的比特币2.0公司。
   4. 主界面是直接使用REST API，REST API通过云服务提供商，与语言绑定（Python）。
   5. 包含上面提到的BigchainDB的特性。
3. 把你的数据库区块链化，帮助其他人吧区块链属性放到分布式数据库中。像MySqlChain，CassandraChain和Neo4jChain。
   1. 帮助数据库提供商把他们的数据库扩展到区块链应用中。
   2. 为了那些希望使用区块链技术的开发者。

9.5时间线

像很多人一样，我们知道比特币和区块链扩展性问题已经好多年了。这里是BigchainDB如何初具规模的时间线：

• 2014年10月，最初的公开讨论大数据和区块链
• 2015年4月，最初的调查，暂停了项目，主要集中注意力在知识产权上
• 2015年9月，重启了项目，细节设计；构建和优化
• 2015年12月，基准测试结果达到每秒10万交易量
• 2015年12月，第一版软件集成到一个企业级用户原型中。
• 2015年12月，和一些评审者分享了这本白皮书的草稿。
• 2016年1月，基准测试结果达到每秒1百万交易
• 2016年2月10日，BigchainDB公布
• 2016年2月10日，最初版本的白皮书公布
• 2016年2月10日，0.1.0版本的软件在GitHub上开源发布。软件还不建议外部使用，开发正在开源进行中。
• 2016年4月10日，0.2.0版发布

目前BigchainDB的路线图可以再GitHub上的bigchaindb/org仓库中找到。

10.结论

本白皮书介绍BigchainDB。BigchainDB填补了去中心化生态系统的一个空白：一个去中心化的数据库，可扩展。BigchainDB性能目标是每秒写1百万次，亚秒级别的延迟和PB级别的容量。使用简单，高效查询。它有一套丰富的权限管理系统可以支持公有和私有区块链。它是去中心处理技术（智能合约）和去中心文件系统的补充，可以是一个区块链平台的组成部分。

11.感谢

我们感谢以下的人，他们帮我们评审，提供修改建议和有用的建议：David Holtzman, Jim Rutt, Evan Schwartz, Ian Grigg, Benjamin Bollen, Carsten Stocker, Adi Ben-Ari, Jae Kwon, Juan Benet and Bruce Pon.

附件

A.词汇表

SQL DB--一个以表格式存储数据的数据库，支持结构化查询语言；一个关系型数据库。例如：MySQL

Ledger--一个以表结构存储数据的数据库，实体是经济交易

NoSQL DB--一个以非表结构存储数据的数据库，像键-值对存储或图像存储。例如：Rethinkdb

NoQL DB--一个没有查询语言的数据库。显然，这影响了数据管理。例子比特币区块链。

Distributed DB--一个在网络中在多个节点上分布数据的数据库。例如：Rethinkdb

Fully replicated DB--一个每个节点持有所有数据的分布式数据库。

Partially replicated DB--一个每个节点持有部分数据的分布式数据库。

Decentralized DB--一个没有一个单一的节点所有或者控制网络的数据库

Immutable DB--一个在网络中的存储都是不可修改的数据库

Blockchain DB--一个分布式，去中心化，不可修改的数据库，它还可以不依赖于一个中心实体创建，传输资产。

Bitcoin Blockchain--一个NoQL，全复制，区块链数据库。

BigchainDB--一个特定的NoSQL，部分复制的区块链数据库。

B.区块链扩展性建议

这里，我们评审一些在扩展区块链时解决强拜占庭将军问题的提议，使和区块链类似的行为更加可扩展。这个列表不会非常详尽。

B.1基本一致性方法

一致性是指区块链网络中的节点接收或者拒绝新交易的方式。这些方法在以下几个方面不同：a）一个节点如何变成投票节点，b）每个节点的投票权重是如何设置的。这些选择可以影响区块链的性能。

工作量证明（POW） 。POW是比特币区块链使用的基本方法。没有严格地规定谁可以进入网络成为一个投票者。节点被随机选择，和它带给网络的计算能力成正比，基于一个数据谜题--它是hash rate。工作量可以是SHA256散列（比特币使用的算法），加密散列（莱特币使用），和其他东西。

POW有一个天然的面向中心化的倾向。他是一个获取最大散列能力的比赛。算力现在被掌握在矿池里。

权益证明（POS） 。在POS模型中，没有限制谁可以进入网络。为了验证一个区块，随机选择一个节点，和它拥有的权益成正比。权益是一个它拥有多少钱币的函数，有时是钱币年龄，衡量上一次钱币投票以来多少天已经过去了的一个测量指标。

POS承诺低延迟，没有POW的超级计算需求。

但是，在过去的几年中，POS建议发现了一些问题（权益为空，富者更富，大范围攻击），也有一些修正建议，POS在持续进化中。这些修正使得POS协议更加复杂。复杂系统通常会有更多的弱点和安全性问题。

联邦。 一个联邦的区块链由一定数量运行一定组规则的节点组成的。每个联邦成员通常有同样的投票权，每个联邦有它自己的作为投票节点加入联邦的规则。通常需要大多数或者2/3的投票节点同意，一个交易或者区块才能被接受（合法多数）。

联邦可以有任意数量的投票节点。更多的节点就意味着更高的延迟，更少的节点意味着联邦不像我们希望的那样去中心化。除了投票节点，其他节点可以有权限来产生资产，传输资产，读取等等（超级点对点网络）。

投票节点的成员规则在模型之间可以差异很大。在Hyperledger模型中，需求是有个TLD和SSL认证。在原始Stellar模型中，成员是基于社交模型的，直到它分叉。在Tendermint，Slasher和Casper模型中，任何人可以通过提交一个固定的安全存款作为保证，如果投票节点行为异常，存款会丢失。

成员规则可以直接影响联邦的大小。例如，在Tendermint中，安全存款越少，投票节点就会越多。

联邦意味着作为一个投票节点，它就必须公开其身份。这意味着当审计阻力是一个关键设计规范时，他们并不适合。这就不同于POW和POS。

B.2. 混搭一致性

以上说的一致性方法可以创新的组合在一起。

POW的层级--中心化。 大比特币交换操作他们自己的交易数据库，然后定时与比特币区块链同步交易摘要。这也类似于股票交易如何暗池交易--金融机构描述那些在公共股票交易之外的交易，定时与公共交易同步。

小型--大型联邦的层级。 一个AI币的例子。最高级别有5个强大的节点，拥有更大的影响力，底层有50个节点，拥有较小影响力。

POW层级--联邦。 一个Factom的例子。底层是一个文档库；文档散列被组合在一个在越来越高的层级，Merkle树结构；最高层的Merkle树根存储在比特币区块链中。

先POW然后POS。 一个例子是以太坊展示计划。以太坊团队发现如果只有少量钱币在POS模型中流动，一个坏人就可以买走所有钱币来控制，因此他们需要更多的时间来开发更有效的可信POS算法。因此，以太坊开始使用POW挖矿来构建网络，在更广的流通环境里获得钱币，当有了足够多的钱币，就切换到POS方式。

先X再中心化在X'。 这个模型在一致性算法在使用中出故障时使用。投票临时由项目管理实体接管，直到一个修正了的算法被开发并发布出来。这在Stellar中发生过。Stellar作为一个联邦开始但是项目发生了分叉。Stellar在2015年初运行在一个单一的服务器上，直到一个新的一致性协议开发并于2015年4月发布。新版很像一个联邦，但是每个节点选择相信哪些节点来验证。另一个关于这个模型的例子是Peercoin，最早的POS变种。在2015年初分叉后，开发者不得不等到修复发布才签署交易。

B.3.工程优化

本节回顾一些可能的步骤来优化现存区块链模型的效率和吞吐量。

缩小问题范围。这个优化的目的是是区块链本身更小。一个缩小区块链尺寸的方法是只记录没有花费的输出。如果历史交易不重要的话，可以这么做，但是在许多区块链应用中，从艺术品验真到供应链跟踪，历史数据都是关键。另一种方法，叫做简单付款验证（SPV），只存区块的头部，而不是整个区块。它可以使一个节点检查一个交易是否在区块中而不用真正持有这笔交易。移动设备通常使用比特币SPV钱包。Cryptonite是把上面这些方法组合起来的例子。这些优化使节点参与网络，但是没有从根本上解决一致性问题。

不同的POW散列算法。 这种优化寻找由网络生成散列的更有效的方法。莱特币是使用scrypt散列而不是比特币的SHA256散列的模型之一，需要比SHA256小2/3的计算量。这种效率没有改进扩展性，因为它还是在矿工之间展开散列军备竞赛。

压缩。区块链中的数据有特殊的结构，所以正确的压缩算法可以使大小尺寸减少一个数量级。这是一个简单交易账簿不需要做太多让步的好方法。压缩通常会阻碍数据库的查询效率。

更好的BFT算法。 拜占庭将军问题的第一个解决方案在1980年发表，从那之后很多建议都在分布式计算会议上被发表。现代的例子包含Aardvark和冗余拜占庭错误容错。这些建议当然很有用，但是他们自己没有解决女巫容错（克隆攻击问题）

多个独立的链。 这个想法是有多个区块链，每个链集中注意力在一部分特定的用户和案例上，实现一个最适合这些案例的模型。目前使用中的无数的中心数据库就遵循这个规则；每个有一个特定的用例。我们实际上希望这个同样发生在区块链上，尤其是私人发布的上，但是也可以用在公有的上。互联然的第34条军规的区块链版是如果它存在，那就把它区块链话。

对于公用例子，如果你想去中心化处理你可以使用以太坊，如果你想让POW对世界有些许帮助，选择Primecoin，如果你想要小巧可爱选择狗狗币。对于私有的例子， 组织和财团根据他们自己特定的需要部署区块链，就像他们现在部署数据库和其他计算机设备一样。

安全上的一个挑战：如果在POW区块链中的算力和POS区块链中的币值太低，他们可以被恶意用户压倒。但是，在一个联邦模型中，这是可行的，假设一个单独的区块链可以满足特定用例的性能，吞吐量和延迟目标。

共享安全资源的多个独立的链。 Pegged侧链是最著名的例子，在链中挖矿有被合并的效果。SuperNET和以太坊的超立方和多链建议适合这个分类。但是，如果目标是获得一个可扩展的数据库，把数据库分成多个不同的子链增加了认知和工程的复杂度，也引入了风险。

更多。 上面说的那些这些模型只是举例。还会有个创新（争论）。例如，一个叫比特币-NG的关于修改比特币的建议目标在于减少首次确认的时间同时最小化比特币区块链设计的其他所有改动。比特币路线图包含了很多其他想法，最明显的是隔离的见证。

C.案例学习：DNS一个去中心化的互联网扩展的数据库

C.1. 介绍

在前一节中，我们回顾了大数据分布式数据库（DBs），重点突出了他们互联网级别的扩展属性，和基于Paxos的强一致性。我们还强调了核心缺陷：由一个持有秘钥的可信任的第三方中心控制。

我们留下了这个问题：有这种分布式数据库的先例吗？它不但可以在互联网级别扩展，还是去中心的可信方式。

由一个数据库不止可以在互联网级别扩展，还可以去中心控制，而且使我们都知道的互联网的关键基础：域名系统（DNS）。

C.2.DNS的历史

在1980年代早期，互联网的高速发展让管理域名成了一个主要的记账难题。为了解决这个问题，在1983年，Jon Postel提出了DNS。DNS开始是以中心数据库实现的，有美国政府管理。在1993年，美国政府把控制权交给了Network Solution Inc（NSI），一个私人公司。

NSI面临双重挑战。它必须使DNS功能高效，而且还得把管理权从主要的利益相关方拿走，包括美国政府甚至是NSI自己。David Holtzman，NSI的CTO，设计了一个解决方案：分布在全球的联邦，每个节点的利益都尽量和其他节点正交（无关），从而避免串通。Holtzman部署了这个数据库，当时NSI的CEO Jim Rutt为了使美国商务部和美国国防部远离它，而后者希望继续控制它。在90年代后期，NSI 把DNS监管权给了Internet Corporation for Assigned Names and Numbers(ICANN),一个新的非政府，非国家组织。

在它的核心，DNS只是一个简单的域名和数字的对应关系，(如 amazon.com到54.93.255.255).人们信任DNS，因为没有人真正控制它，它被ICANN监管。

DNS架构随着时间进行了演化和扩展。例如，原始的设计没有包括足够的安全措施，所以DNS安全扩展（DNSSEC）在维护向后兼容性时被加入。

很难想象还有比互联网域名系统更互联网级别的扩展系统了。去中心化的DNS成功的分布在互联网，包括技术和管理级别。ICANN不是很有名，但是它通过自身的成长保证了互联网保持一致，在政府公司和黑客的强大压力下存活了下来。

域名有数字方面的缺陷，因为它使用了不需要用户特别信任的公共账簿。在DNS模型中，只能有一个amazon.com。但是DNS是一个一致性安排。任何人都可以创建一个以同样方式运行的入口，把amazon.com给别人。这另一个入口几乎没有用，因为有大量的用户已经投票给了会使用哪个域名系统，它们的网络设备选择了使用哪个域名系统，使用现有的DNS系统提供的域名。

C.3优势和弱点

弱点。DNS没有解决数据存储大规模扩展的挑战，以及区块链的一些特性，像不可更改，创建传输资产。但是它不打算做。

优势。DNS显示了去中心化控制，以一种联邦的形式，可以再互联网上扩展。它还显示了使用正确的条件或者正确的联邦很重要。

D.其他实验

D.1测试环境

为了测试写入性能，我们写了一个进程用一个无限循环往数据库中插入区块。

这个区块是一个包含小交易的合法的区块。在这里，我们使用没有任何数据的合法交易。一整个区块大约900KB。

在硬耐久模式，在发送确认前，写操作就提交到磁盘；在软耐久模式，一旦存入内存中，写操作就马上发确认。

这意味着插入操作会被阻塞直到Rethinkdb通知数据已经被缓存。在每个服务器上我们可以开启多个进程。

写入单元。我们定义一个写入单元作为一个进程。例如，在一个32节点的集群中，每个节点运行两个进程，我们就有64个写入单元。这会使比较不同测试变得简单。

分片在分布式数据库中意味着把数据表分区，这样数据就可以平均分布到集群中的所有节点上。在大多数分布式数据库中，都有一个每张表的最大分片数。在Rethinkdb中，这个限制是32片。

在RethinkDB中，一个分片也叫一个主备份，缺省的备份因子是1。增加备份因子产生第二个副本来作 为数据冗余。如果持有主备份的节点出现故障，另一个持有第二个副本的节点可以出来变为主备份。

计算资源。对于这些测试，我们使用32核AWS EC2实例，SSD存储和10GB网络连接（c3.8xlarge）.对于这些测试，我们使用不管32个还是64个节点的集群，都是在同一个AWS区域中。

D.2.吞吐量试验

实验环境和D.1中一样。

D.2.1实验1

设定：

• 节点数量：32
• 进程数量：每个节点2个进程
• 写入单元：32X2=64写入单元

结果：

• 输出：稳定在每秒1千写入

这是最成功的实验。我们成功达到了一个稳定的每秒1千区块的输出。机器的负载很稳定，IO大约在50%-60%。

其他测试显示增加每台机器的写入单元数量可以达到一个稳定的性能，每秒1千5百个写入，但是负载会持续增加直到节点故障。这意味着我们能处理短时间（10-20分钟）的突发流量。

这个测试可以作为一个未来的基线，每秒64个写入等于1千个交易。或者每个写入单元每秒产生（1000/64）大约64个写入。

D.2.2 实验 2

设定：

• 节点数量： 32
• 进程数量：
  • 16个节点运行2个进程
  • 16个节点运行3个进程
• 写入单元：16X3+16X2=80写入单元
• 期望结果：每秒1.25K个写入。

结果：

• 输出：稳定在每秒1千2百个写入

增加一定数量的写入单元可以增加输出，非常接近于预期结果，但是IO会达到机器所能处理的极限的90%。

D.2.3 实验 3

设定：

• 节点数量：32
• 进程数量：
  • 16个节点运行2个进程
  • 16个节点运行4个进程
• 写入单元：16X4+16X2=96写入单元
• 期望结果：每秒1千5百个写入

结果：

• 输出：稳定在每秒1千4百个写入

测试结果和前一个类似。结果没有达到预期输出可能是因为Rethinkdb需要时间来存储结果，而且有些时候，增加写入单元的数量不会到时高的输出。另一个问题是Rethinkdb缓存会占满（因为Rethinkdb因为IO限制不能足够快的把数据写入硬盘），性能就会下降，因为进程需要更多的时间来插入区块。

D.2.4 实验 4

设定：

• 节点数量：64
• 进程数量：每个节点1个进程
• 写入单元：64X1=64个写入单元
• 期望结果：每秒1千个写入

结果：

• 输出：稳定在每秒1千个写入

在这种情况下，我们增加一倍一个集群的节点数量。不会影响写入性能，因为Rethinkdb的每个表的最大分片数量是32（将来Rethinkdb有可能增加这个限制）。这里是增加了更多的CPU算力（备份的存储，更多的备份会在下一节讨论）。我们把每个节点的写入单元减半来维持同样的输出。持有主备份的节点的IO和实验D.2.1中一样。

D.2.5 实验 5

设定：

• 节点数量：64
• 进程数量：每个节点2个进程
• 写入单元：64X2=128个写入单元
• 期望结果： 每秒2千写入

结果：

• 输出：每秒不稳定的2千（峰值）写入

在这种情况下，我们把写入单元翻翻。我们可以得到预期结果，但是性能不稳定，因为我们达到了机器的IO极限。

D.2.6 实验 6

设定：

• 节点数量： 64
• 进程数量：
  • 32个节点运行1个进程
  • 32个节点运行2个进程
• 写入单元：32X2+32X1=96写入单元
• 期望输出：每秒1千5百个写入

结果：

• 输出：稳定在每秒1千5百个写入

这个实验类似于实验D.2.3。唯一的不同是写入单元分布在64个节点上，意味着每个节点写自己的本地缓存，不会像实验D.2.3一样超过每个节点的缓存。这也是增加32个节点的好处。

D.3 备份实验

备份是来做数据冗余的。在Rethinkdb中，我们能够定义每个数据表分片和备份的数量。在第二个备份中的数据是不会被直接使用的，他只是一个主备份的镜像，在主备份故障时被使用。

Rethinkdb在把数据平均分配到各个节点中做的非常好。我们运行一些测试来检验这一点。

通过增加副本数量，我们同样增加了集群中写入的数量。对于备份因子是2，我们等于把一个集群中的写入数量扩大一倍，备份因子是3的话，写入数量是以前的3倍。

对于64个节点，因为我们只能有32个分片，我们就只能有32个节点持有分片（主备份）。

对于备份因子是2，我们会有64个备份（32个主备份和32个第二备份）。既然我们已经有了32个节点持有32个分片/主备份，Rethinkdb会使用剩下的32个节点持有第二备份。这样在一个64节点的集群中，32个分片，备份因子是2，32个节点持有主备份，剩下的32个节点持有第二备份。

如果我们在这个环境中再运行试验D.2.4一次，只是备份因子是2，我们可以得到两倍的写入数量。一个好的结果是，持有主备份的节点的IO不会像实验D.2.4一样增加，因为所有超出的写入都由持有第二备份的32个节点做了。

对于备份：如果我有64个节点，创建了一个有32个分片的表，32各节点持有主备份，另外的节点不持有数据。如果我们在创建一个有32个分片的表，Rethinkdb会在没有持有数据的节点上创建分片，平均分配数据。

参考文献

[1] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/

bitcoin.pdf, 2009.

[2] M Tamer Ozsu and Patrick Valduriez. Principles of Distributed Database Systems, 3rd Edition.

Springer Science & Business Media, 2011.

[3] Ethereum. https://ethereum.org/.

[4] Vitalik Buterin. Ethereum White Paper: A Next Generation Smart Contract & Decentralized

Application Platform. http://blog.lavoiedubitcoin.info/public/Bibliotheque/

EthereumWhitePaper.pdf.

[5] Enigma. http://enigma.media.mit.edu/.

[6] Guy Zyskind, Oz Nathan, and Alex Pentland. Enigma: Decentralized Computation Platform with

Guaranteed Privacy. 2015. http://enigma.media.mit.edu/enigma_full.pdf.

[7] J. Benet. IPFS { Content Addressed, Versioned, P2P File System. http://static.benet.ai/t/

ipfs.pdf, 2014.

[8] Eris Industries. http://erisindustries.com/.

[9] Tendermint. http://www.tendermint.com.

[10] Dimitri De Jonghe and Trent McConaghy. SPOOL Protocol. https://github.com/ascribe/

spool.

59

[11] A. Back. Enabling blockchain innovations with pegged sidechains. Technical report, October 2010.

http://www.blockstream.com/sidechains.pdf.

[12] S. Thomas and Schwartz E. A Protocol for Interledger Payments. https://interledger.org/

interledger.pdf, 2015.

[13] P. Koshy. Bitcoin and the Byzantine Generals Problem { a Crusade is needed? A Revolution?

http://financialcryptography.com/mt/archives/001522.html, November 2014.

[14] Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine Generals Problem. ACM

Transactions on Programming Languages and Systems (TOPLAS), 4(3):382{401, July 1982. http:

//research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf.

[15] Juan Garay, Aggelos Kiayias, and Nikos Leonardos. The bitcoin backbone protocol: Analysis and

applications. In Advances in Cryptology-EUROCRYPT 2015, pages 281{310. Springer, 2015.

[16] Loi Luu, Viswesh Narayanan, Kunal Baweja, Chaodong Zheng, Seth Gilbert, and Prateek Saxena.

Scp: A computationally-scalable byzantine consensus protocol for blockchains. 2015.

[17] John R Douceur. The Sybil Attack. In Peer-to-peer Systems, pages 251{260. Springer, 2002.

http://research.microsoft.com/pubs/74220/IPTPS2002.pdf.

[18] Bitcoin Wiki. Scalability. https://en.bitcoin.it/wiki/Scalability, 2015.

[19] M. Trillo. Stress Test Prepares VisaNet for the Most Wonderful

Time of the Year. http://www.visa.com/blogarchives/us/2013/10/10/

stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html,

October 2013.

[20] Sourabh. How Much Email Do We Use Daily? 182.9 Billion

Emails Sent/Received Per Day Worldwide. http://sourcedigit.com/

4233-much-email-use-daily-182-9-billion-emails-sentreceived-per-day-worldwide/,

February 2014.

[21] Blockchain.info. Blockchain size. https://blockchain.info/charts/blocks-size, December,

30th 2015.

[22] A. Wagner. Ensuring Network Scalability: How to Fight

Blockchain Bloat. https://bitcoinmagazine.com/articles/

how-to-ensure-network-scalibility-fighting-blockchain-bloat-1415304056, November

2014.

[23] Adrian Cockcroft and Denis Sheahan. Benchmarking Cassandra Scalability on AWS

{ Over a million writes per second. 2011. http://techblog.netflix.com/2011/11/

benchmarking-cassandra-scalability-on.html.

[24] C. Kalantzis. Revisiting 1 Million Writes per second. http://techblog.netflix.com/2014/07/

revisiting-1-million-writes-per-second.html.

[25] Marshall Pease, Robert Shostak, and Leslie Lamport. Reaching agreement in the presence of

faults. Journal of the ACM (JACM), 27(2):228{234, April 1980. http://research.microsoft.

com/en-US/um/people/Lamport/pubs/reaching.pdf.

[26] Leslie Lamport. My Writings. http://research.microsoft.com/en-us/um/people/lamport/

pubs/pubs.html.

[27] Leslie Lamport. The part-time parliament. ACM Transactions on Computer Systems

(TOCS), 16(2):133{169, 1998. http://research.microsoft.com/en-us/um/people/lamport/

pubs/lamport-paxos.pdf.

[28] Leslie Lamport. Fast Paxos. Distributed Computing, 19(2):79{103, 2006. http://research.

microsoft.com/pubs/64624/tr-2005-112.pdf.

[29] Leslie Lamport. Byzantizing paxos by renement. In Distributed Computing, pages 211{224.

Springer, 2011. http://research.microsoft.com/en-us/um/people/lamport/tla/byzsimple.

pdf.

60

[30] H. Robinson. Consensus Protocols: Paxos. http://the-paper-trail.org/blog/

consensus-protocols-paxos/, February 2009.

[31] Mike Burrows. The Chubby Lock Service for Loosely-Coupled Distributed Systems. In OSDI'06,

Proceedings of the 7th symposium on Operating systems design and implementation, Seattle, WA,

pages 335{350. USENIX Association, November 2006. http://static.googleusercontent.com/

media/research.google.com/en//archive/chubby-osdi06.pdf.

[32] Wikipedia. Paxos (Computer Science). http://en.wikipedia.org/wiki/Paxos_(computer_

science).

[33] Diego Ongaro and John Ousterhout. In Search of an Understandable Consensus Algorithm. In

2014 USENIX Annual Technical Conference (USENIX ATC 14), pages 305{319, 2014. https:

//ramcloud.stanford.edu/raft.pdf.

[34] C. Copeland and H. Zhong. Tangaroa: a Byzantine Fault Tolerant Raft. August 2014. http:

//www.scs.stanford.edu/14au-cs244b/labs/projects/copeland_zhong.pdf.

[35] Michael J Fischer, Nancy A Lynch, and Michael S Paterson. Impossibility of distributed consensus

with one faulty process. Journal of the ACM (JACM), 32(2):374{382, April 1985. https://groups.

csail.mit.edu/tds/papers/Lynch/jacm85.pdf.

[36] Wikipedia. Byzantine fault tolerance. https://en.wikipedia.org/wiki/Byzantine_fault_

tolerance.

[37] Michael Paulitsch, Jennifer Morris, Brendan Hall, Kevin Driscoll, Elizabeth Latronico, and Philip

Koopman. Coverage and the Use of Cyclic Redundancy Codes in Ultra-Dependable System. In

Dependable Systems and Networks, 2005. DSN 2005. Proceedings. International Conference on,

pages 346{355. IEEE, 2005.

[38] Albert L Hopkins Jr, Jaynarayan H Lala, and T Basil Smith III. The Evolution of Fault Tolerant

Computing at the Charles Stark Draper Laboratory 1955{85. In The Evolution of fault-tolerant

computing, pages 121{140. Springer, 1987.

[39] Kevin Driscoll, G Papadopoulis, S Nelson, G Hartmann, and G Ramohalli. Multi-microprocessor

ight control system. In Proceedings of the IEEE/AIAA 5th Digital Avionics Systems Conference,

Institute of Electrical and Electronic Engineers, New York, NY, 1983.

[40] Miguel Castro and Barbara Liskov. Practical Byzantine fault tolerance. In Proceedings of the

Third Symposium on Operating Systems Design and Implementation, volume 99, pages 173{186,

February 1999.

[41] M. Castro. Practical Byzantine Fault Tolerance. PhD thesis, MIT, 2001. http://research.

microsoft.com/en-us/um/people/mcastro/publications/thesis.pdf.

[42] Allen Clement, Edmund L Wong, Lorenzo Alvisi, Michael Dahlin, and Mirco Marchetti. Making

Byzantine fault tolerant systems tolerate Byzantine faults. In NSDI, volume 9, pages 153{168,

November 2009. https://www.usenix.org/legacy/event/nsdi09/tech/full_papers/clement/

clement.pdf.

[43] Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quema. RBFT: Redundant Byzantine Fault

Tolerance. In Distributed Computing Systems (ICDCS), 2013 IEEE 33rd International Confer-

ence on, pages 297{306. IEEE, 2013. http://www.computer.org/csdl/proceedings/icdcs/2013/

5000/00/5000a297.pdf.

[44] D. Mazieres. The Stellar Consensus Protocol: A Federated Model for Internet-Level Consensus.

https://www.stellar.org/papers/stellar-consensus-protocol.pdf, December 2015. draft of

Nov 17, 2015, retrieved Dec 30, 2015.

[45] Wikipedia. RAID. http://en.wikipedia.org/wiki/RAID.

[46] Bitcoin Wiki. Transaction Fees. https://en.bitcoin.it/wiki/Transaction_fees, 2015.

[47] A. Sethy. The mystery of India's deadly exam scam. http://www.theguardian.com/world/2015/

dec/17/the-mystery-of-indias-deadly-exam-scam, December 2015.

61

[48] WikiData. https://www.wikidata.org.

[49] BigchainDB Documentation. http://bigchaindb.readthedocs.io/en/latest/index.html.

[50] M. Gault. The CIA Secret to Cybersecurity that No One Seems to Get. http://www.wired.com/

2015/12/the-cia-secret-to-cybersecurity-that-no-one-seems-to-get, December 2015.

[51] NoSQL Database. NoSQL: Your Ultimate Guide to the Non-Relational Universe. http://www.

nosql-database.org.

[52] Toad World. Toad for Cloud Databases Community. http://www.toadworld.com/products/

toad-for-cloud-databases/w/wiki/308.survey-distributed-databases, 2015.

[53] The Apache Cassandra Project. https://cassandra.apache.org.

[54] Apache HBase. https://hbase.apache.org.

[55] Redis. https://www.redis.io.

[56] Basho. Riak. https://docs.basho.com/riak.

[57] MongoDB. https://www.mongodb.org.

[58] RethinkDB. https://www.rethinkdb.com.

[59] ElasticSearch. https://www.elastic.co/products/elasticsearch.

[60] Wikipedia. CAP Theorem. https://en.wikipedia.org/wiki/CAP_theorem.

[61] Wikipedia. ACID. https://en.wikipedia.org/wiki/ACID.

[62] RethinkDB Consistency Guarantees. https://rethinkdb.com/docs/consistency/.

[63] RethinkDB Changefeeds. https://rethinkdb.com/docs/changefeeds.

[64] RethinkDB Frequently Asked Questions. https://www.rethinkdb.com/faq/.

[65] GitHub. rethinkdb/rethinkdb. https://github.com/rethinkdb/rethinkdb.

[66] T. Bray. The javascript object notation (json) data interchange format. RFC 7159, RFC Editor,

March 2014. http://www.rfc-editor.org/rfc/rfc7159.txt.

[67] Ed25519: high-speed high-security signatures. https://ed25519.cr.yp.to/.

[68] Simon Josefsson and Ilari Liusvaara. Edwards-curve digital signature algorithm (eddsa).

Internet-Draft draft-irtf-cfrg-eddsa-05, IETF Secretariat, March 2016. http://www.ietf.org/

internet-drafts/draft-irtf-cfrg-eddsa-05.txt.

[69] Thins that use Ed25519. https://ianix.com/pub/ed25519-deployment.html.

[70] Melanie Swan. Blockchain: Blueprint for a New Economy. " O'Reilly Media, Inc.", 2015. http:

//shop.oreilly.com/product/0636920037040.do.

[71] M. Andreesen. Why Bitcoin Matters. http://dealbook.nytimes.com/2014/01/21/

why-bitcoin-matters, January 2014. New York Times.

[72] J. Monegro. The Blockchain Application Stack. http://joel.mn/post/103546215249/

the-blockchain-application-stack, November 2014. Joel Monegro Blog.

[73] T. Berners-Lee. Information Management: A Proposal. http://www.w3.org/History/1989/

proposal.html, 1989. World Wide Web Consortium.

[74] N. Popper. A Bitcoin Believer's Crisis of Faith. http://www.nytimes.com/2016/01/17/business/

dealbook/the-bitcoin-believer-who-gave-up.html?_r=0, January 2016.

[75] Robin Hanson. Information Prizes { Patronizing Basic Research, Finding Consensus. In West-

ern Economics Association meeting, Lake Tahoe, June 2013. http://mason.gmu.edu/~rhanson/

ideafutures.html.

[76] Backfeed. http://backfeed.cc.

[77] Cory Doctorow. Down and Out in the Magic Kingdom. Macmillan, February 2003. http://www.

amazon.com/Down-Magic-Kingdom-Cory-Doctorow/dp/076530953X.

62

[78] D. Suarez. Freedom (TM). http://www.amazon.com/Freedom-TM-Daniel-Suarez/dp/

0525951571, January 2010.

[79] Blockchain.info. Total transaction fees. https://server2.blockchain.info/charts/

transaction-fees, December, 30th 2015.

[80] Tradeblock. Recent Blocks. https://tradeblock.com/bitcoin/.

[81] Ian Grigg. The Ricardian Contract. In Electronic Contracting, 2004. Proceedings. First IEEE

International Workshop on, pages 25{31. IEEE, 2004. http://iang.org/papers/ricardian_

contract.html.

[82] Trent McConaghy. Blockchain, Throughput, and Big Data. http://trent.st/content/

2014-10-28%20mcconaghy%20-%20blockchain%20big%20data.pdf, October 2014. Berlin, Germany.

[83] A. Back. Hashcash - a denial of service counter-measure. Technical report, August 2002. technical

report.

[84] Bitcoin Wiki. Proof of Stake. https://en.bitcoin.it/wiki/Proof_of_Stake, 2015.

[85] Bitsmith. Dan O'Prey talks Hyperledger. http://www.thecoinsman.com/2014/08/

decentralization/dan-oprey-talks-hyperledger/, August 2014.

[86] J. Kim. Safety, liveness and fault tolerance | the consensus choices. https://www.stellar.org/

blog/safety_liveness_and_fault_tolerance_consensus_choice/, December 2014.

[87] J. Kwon. Tendermint: Consensus without Mining. http://tendermint.com/docs/tendermint.

pdf, fall 2014.

[88] Vitalik Buterin. Slasher: A Punitive Proof-of-Stake Algorithm. https://blog.ethereum.org/

2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/, January, 15th 2014.

[89] Vitalik Buterin. Slasher Ghost, and other Developments in Proof of Stake. https://blog.

ethereum.org/2014/10/03/slasher-ghost-developments-proof-stake/, October, 3th 2014.

[90] V. Zamr. Introducing Casper `the Friendly Ghost'. https://blog.ethereum.org/2015/08/01/

introducing-casper-friendly-ghost/, August 2015.

[91] AI Coin. http://www.ai-coin.org.

[92] Factom. http://factom.org/.

[93] J. Kim. Stellar Consensus Protocol: Proof and Code. https://www.stellar.org/blog/

stellar-consensus-protocol-proof-code/, April 2015.

[94] Wikipedia. Peercoin. http://en.wikipedia.org/wiki/Peercoin.

[95] Cryptonite. http://cryptonite.info/.

[96] J.S. Galt. JL777's vision of the Supernet. https://bitcoinmagazine.com/18167/

what-is-the-supernet-jl777s-vision/, November 2014.

[97] Vitalik Buterin. Scalability, Part 2: Hypercubes. https://blog.ethereum.org/2014/10/21/

scalability-part-2-hypercubes/, October, 21st 2014.

[98] Bitcoin Wiki. Block size limit controversy. https://en.bitcoin.it/wiki/Block_size_limit_

controversy.

[99] Ittay Eyal, Adem Efe Gencer, Emin Gun Sirer, and Robbert van Renesse. Bitcoin-NG: A Scalable

Blockchain Protocol. In NSDI, 2016. http://diyhpl.us/~bryan/papers2/bitcoin/Bitcoin-NG:

%20A%20scalable%20blockchain%20protocol.pdf.

[100] Bitcoin Core. Bitcoin Capacity Increases FAQ. https://bitcoincore.org/en/2015/12/23/

capacity-increases-faq/, December 2015.

[101] G. Maxwell. Capacity increases for the Bitcoin system. https://lists.linuxfoundation.org/

pipermail/bitcoin-dev/2015-December/011865.html, December 2015.

63

[102] P. Wuille. Segregated witness and its impact on scalability.

http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/

segregated-witness-and-its-impact-on-scalability/.

[103] Berkman Center for Internet and Society. Brief History of the Domain Name System. http:

//cyber.law.harvard.edu/icann/pressingissues2000/briefingbook/dnshistory.html, 2000.

Harvard.

[104] J. Schwartz. Internet `Bad Boy' Takes on a New Challenge. http://www.nytimes.com/2001/04/

23/business/technology-Internet-bad-boy-takes-on-a-new-challenge.html, April 2001.

[105] ICANN. DNSSEC { What Is It and Why Is It Important? https://www.icann.org/resources/

pages/dnssec-qaa-2014-01-29-en, January 2014.

BigchainDB白皮书补遗

BigchainDB GmbH，柏林，德国

2016年12月18日

这个补遗总结了BigchainDB白皮书最后更新后的重大改变。在线的BigchainDB文档会实时更新。

• 文档中有更多关于BigchainDB如何达到去中心化和不可修改/防篡改。
• Sections 4和6. 白皮书描述了S和C作为两个分开的数据库，但是在实际实现中，他们在分开的三张表中（在一个数据库里）。S成为Backlog表（关于交易）。C成为两个只可以增加的表，一个用来存放区块，一个存放投票。为了理解为什么，看在Issue #368中的讨论和Gibhub上的相关讨论。
• Section 4.3，Section 6和Figure 10。交易在写入Backlog（S）之前不会被验证。
• Section 4.5。交易，区块和投票的数据结构已经改变，很有可能还要改变。他们现在的模式可以在BigchainDB文档中找到。每个节点为每个区块投一票。每一票包括每个被投票区块的id（hash），和被投票节点决定的前一个区块的id。另一个节点会考虑选择一个不同的区块作为前一个区块。总的来说，每个节点记录一个不同的区块顺序（根据他的投票）。这样没有问题是因为判断一个交易是否被重复消费并不依赖于区块的顺序。
• （这不是改变，更像一个有趣的实现。） 如果你随机选择一个区块，它的hash存在一些投票中，但是这些投票中的信息永远不会包含在任何别的东西中（区块或投票）。因此没有区块的hash链或者Merkle链。有趣的是，每个创建交易都开始一个Merkle有向非循环图，因为所有的传输交易包含前一个交易的Hash。
• Section 5.1 截止2017年1月，可以选择Rethinkdb或者MongoDB作为后台数据库。两个都支持。在将来，更多的数据库可能被支持。MongoDB被选择作为第二个被支持的数据库原因和Rethinkdb一样：它是面向文档的，强一致性保证，同样的开源许可证（AGPL v3）。而且，在MongoDB中可以找到类似于Rethinkdb的changefeed.
• Section 5.2 一个BigChainDB的节点可以有极其巨大的存储空间（例如在一个RAID阵列中）。其他限制集群最大存储空间的因素（例如，在Rethinkdb中的可用内存）。
• Section 5.4在加密hash和签名如何计算的细节上做了改动。最新的细节，看文档关于加密计算的相关页。