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文档。在传输交易中，可以为空。
<