BigchainDB 2.0 区块链数据库白皮书 V1.0

摘要

BigchainDB是具有区块链块链属性（例如，去中心化、不可篡改、自治性）的和数据库属性（例如，高交易率、低延迟、结构化数据的索引和查询）。于2016年2月首次发布和开源，并不断改进。BigchainDB2.0版本与以前的版本相比有了显著的改进。尤其是现在支持拜占庭容错，即在多达三分之一节点失效的情况下，系统仍可以继续就如何进行达成一致意见。BigchainDB 2.0目前已经为许多业务场景做好了生产准备。在此白皮书中，我们回顾了BigchainDB 2.0的设计目标以及如何达到这些目标，我们探讨一些用例展示BigchainDB如何进入去中心化的生态系统，我们从交易生命周期的角度来理解BigchainDB如何工作的，并且说明了试用BigchainDB的路线、总结了您如何贡献以及未来的计划。

1、BigchainDB 2.0 设计目标

BigchainDB于2016年2月首次发布【1】，一起发布的有原始白皮书和第一个软件版本（0.1）。BigchainDB之所以叫区块链数据库因为含有区块链特性和数据库特性。最初的设计是从数据库开始，并在此加上了像去中心化、不可篡改、自治性等区块链特性。其思想是，所得到的系统将继承数据库所需的属性，例如低延迟、高交易率和高容量。
它能正常工作，但是也存在问题。第一个问题是，产生的系统无法承受任意故障（在节点的有界子集中）；它不是拜占庭容错（BFT）的【2】。另一个问题是底层数据库有一个主（或主）节点，该节点执行所有写操作。其他节点只复制主节点写入的任何内容。主节点可能很长一段时间都是主节点。这个点就是单点故障点。第三个问题是只有一个逻辑数据库，因此如果恶意代理设法获得管理员特权可以使用单个命令删除整个数据库（跨越所有节点）。
BigchainDB 2.0旨在解决所有这些问题，同时保留所需的数据库和区块链属性。下面，我们将介绍BigchainDB 2.0的每个设计目标，并概述它是如何实现的。

-	传统区块链	传统分布式数据库	BigchainDB
去中心化	x		x
拜占庭容错	x		x
不可篡改	x		x
自治性	x		x
高交易率		x	x
低延迟		x	x
结构化数据索引和查询		x	x

1.1、 完全去中心化和拜占庭容错

BigchainDB 2.0使用Tendermint[3,4]实现所有联网和共识。每个节点都有自己的本地MongoDB数据库[5]，节点之间的所有通信都是使用Tendermint协议完成的。这样的一个结果就是因为Tendermint是BFT（拜占庭容错）的，所以目标系统也是BFT。另一个结果是，如果黑客设法获得其中一个本地MongoDB数据库的管理员权限，那么他们可以做的最坏的事情是损坏或删除该本地数据库中的数据;但是其他节点中的MongoDB数据库不会受到影响。Tendermint仍然具有类似于主节点（当前块提议者）的内容，但是它随着每轮（使用轮询）而变化，并且Tendermint开发团队有一个开放性问题，以使其更加安全（例如，不可预测）[6]。
如果BigchainDB 2.0网络中的每个节点都由不同的人或实体拥有和操作，那么它就是一个去中心化的网络，因为它没有单一所有者，没有单一控制点，也没有单点故障。理想情况下，节点应该位于许多国家、区区和主机提供商中，所以一个问题不会影响所有的节点。任何节点都可能失败，网络的其余部分将继续运行。实际上，多达三分之一的节点可以以任意方式失败1（从技术上讲，多达三分之一的投票权可能失败，但是我们通常使用具有相同投票权的所有节点运行BigchainDB网络，因此三分之一的投票权与三分之一的节点相同。），并且网络的其余部分将继续工作，即非故障节点将就如何继续进行协商。

1.2、不可篡改（Immutability）

一旦数据存储在BigchainDB网络中，就不能对其进行更改或擦除，或者至少不能毫不费力地进行更改或擦除。数据的更改或擦除都是可检测的。也就是说存储“实际不可篡改”，而不是区块链中经常所说的“不可篡改”。
BigchainDB使用几种策略来实现实际的不可篡改。最简单的一点是不提供BigchainDB的API来更改或擦除存储的数据。
另一个策略是每个节点都具有独立MongoDB数据库（即没有全局MongoDB数据库）中所有数据的完整副本。即使一个节点被破坏或销毁，其他节点也不会被攻击，并且仍然具有所有数据的副本。
还有一个策略是所有交易都以密码方式签名。在存储交易之后，更改其内容将更改可检测到的签名（除非公钥也更改，但是因为每个交易块都由节点签名，并且所有节点的公钥都是已知的，所以这也应该是可检测到的）。

1.3、自治性（Owner-Controlled Assets）

和大多数的区块链一样，BigchainDB有一个由所有者控制的资产的概念。只有资产的所有者（或所有者）才能转移该资产。（所有者是一组特定私钥的持有者。）甚至节点操作员都不能转移资产。
在大多数区块链中，只有一个内置资产（例如，比特币或以太坊），但是BigchainDB允许外部用户根据需要创建尽可能多的资产。但是用户不能创建看起来是由其他人创建的资产。Mike创建的所有资产都由Mike进行加密签名。例如，名为Joe的用户可能决定创建1000个“Joe令牌”。 他会通过构建一个BigchainDB CREATE交易，用他的私钥签署它，并将它发送到BigchainDB网络。（在本文的后面，我们跟踪交易到达BigchainDB网络时发生的情况。）最初，Joe可能拥有所有1000个令牌，所以只有他才能将它们传递给其他人。他可以通过创建具有两个输出的BigchainDB TRANSFER交易来向Lisa传输37个令牌：一个具有37个令牌的总额，条件是只有Lisa可以传输它，另一个具有所有剩余令牌（1000-37=963个令牌），条件是只有Joe可以传输它。（BigchainDB允许非常复杂的输出条件。例如，输出可能具有这样的条件，即“Jamie OR （Pat AND Kelly）OR（three of {Casey,Drew,Laurie、Riley or Whitneyg}）必须签名。）
BigchainDB检查每个交易，以确保它没有试图转移已经由另一个交易转移（花费）的输出，即它防止双重花费。它还检查许多其他内容，所有这些都列在BigchainDB Transaction Spec v2[7]中。

1.4、 高交易率（High Transaction Rate）

BigchainDB的一个设计目标始终是每秒处理大量交易的能力。这在BigchainDB 2.0中仍然适用。
在编写本文时，BigchainDB 2.0仍在Alpha中。性能测试正在编写和启动，但是还没有具体的结果。（稳定的BigchainDB 2.0预计在2018年6月发布。）然而，由于BigchainDB 2.0是基于Tendermint的，所以我们可以查看其他基于Tendermint的网络，以了解可以预期的内容。根据Cosmos的白皮书【8】：
尽管有强有力的保证Tendermint具备出色的性能。在5个大洲的7个数据中心上分布的64个节点的基准测试中，在商业云实例上，Tendermint共识可以每秒处理数千个交易，提交延迟大约为1到2秒。值得注意的是，即使在恶劣的对抗条件下，即在验证者崩溃或恶意广播制作的投票的情况下，也能保持每秒超过一千次交易的表现。

1.5、 低延迟和快速响应（Low Latency and Fast Finality）

基于Tendermint的网络（例如BigchainDB网络）只需几秒钟（或更少）就可以将交易包括在新的提交块中。一旦发生这种情况，它就不可能在将来被恢复或认为已经失效，因为Tendermint不会进行分叉。

1.6、 结构化数据查询和索引（Indexing & Querying Structured Data）

BigchainDB 2.0网络中的每个节点都有自己的本地MongoDB数据库。这意味着每个节点操作员都可以访问MongoDB的全部功能来索引和查询存储的数据（交易、资产、元数据和块，所有这些都是JSON字符串）。每个节点操作者可以自由地决定它们向外部用户暴露了多少功能。一个节点操作员可能决定索引地理空间数据并通过REST API提供优化的地理空间查询，而另一个节点操作员可能决定提供GraphQL API。
默认情况下，BigchainDB 2.0创建一些MongoDB索引，BigchainDB HTTP API包括一些用于执行基本查询的端点。但是，如前段所述，每个节点操作符可以添加额外的索引和查询API。

1.7 女巫攻击（Sybil Tolerance）

一些块链网络（如比特币）允许任何人将他们的节点添加到网络中。这让人担心有人会添加很多的节点，使得他们实际上控制了网络：即Sybil攻击[9]。比特币使得Sybil攻击变得不可能，因为它们太昂贵了。在BigchainDB网络中，网络背后的管理组织控制成员列表，因此Sybil攻击不成问题。

2. 用例

BigchainDB具有上一节中提到的功能，可以为大量业务服务。只要需要表示数字资产的不可变、防篡改的数据，可以使用BigchainDB。有几个垂直行业可以直接从BigchainDB特性中获益。在下面的小节中，我们将简要地触及这些垂直行业中的一些，并讨论BigchainDB在这些场景中如何提供帮助。

2.1、 供应链

在典型的供应链场景中，存在若干方/实体彼此协作和交换信息。这些信息主要是关于跟踪货物生产的过程，直到它们到达供应链周期的逻辑终点（零售商/最终消费者）。这些实体在供应链情景中合作所面临的主要挑战是管理和共享信息的安全性。最终会出现了几个数据孤岛，变得难以管理。通常，这就是区块链技术能够帮助在共享系统中组织这些数据的地方，从而使信息的整体管理变得容易。由于不可变性和抗篡改性，区块链还为协作实体提供了信任层，以便它们即使在彼此不相信时也能够信任数据。虽然其他的区块链和去中心化系统可以帮助在共享系统中组织数据，但是它们没有针对供应链场景所需的高吞吐量和查询能力进行优化。这就是BigchainDB的优点，它带来了查询能力和高吞吐量性能。在供应链场景中使用BigchainDB，像普通的区块链技术一样，可以帮助在去中心化系统中组织数据，但除此之外，还允许用户查询数据以生成报告和动态地进行计算。

2.2、 知识产权管理

当涉及到知识产权的管理和来源时，区块链技术有几个优势，因为它有助于为艺术家的声明提供不可篡改性。一旦艺术品资产在具有适当属性的区块链上注册，就可以用它来证明知识产权的所有权。所有权转移也可以记录。出于这个原因，我们在2014年创建了ascribe[10]，它是基于比特币的区块链。然而，比特币公共模块链的吞吐量很快成为瓶颈。就在那时，我们设想了BigchainDB，并开始构建它。BigchainDB 2.0还处理高吞吐量，因此是IP用例的最佳选择。

2.3、 Digital Twins 和 IoT

Digital Twins是物理对象的数字表示，可以根据真实性和来源的验证，所有权证明，生命周期可追溯性以及物联网设备和传感器的输入数据进行跟踪。 为了管理这种信息模型，为每个产品和对象提供自己的细节，我们需要一个高吞吐量的防篡改系统，它也可以快速提供结果。 这是BigchainDB。

2.4、 身份管理

在管理用户特定信息时，身份是最关键的部分之一。在像IoT和数字双胞胎这样的场景中，它变得越来越重要，甚至机器都有自己的身份。随着身份盗窃成为当今人们关注的主要问题之一，我们需要确保人类或机器的身份是自主权和防黑客的。由于与身份关联的数据量很大，我们还需要确保处理身份相关数据的系统能够处理大规模的数据。这时BigchainDB由于区块链和数据库的组合特性而成为解决身份相关用例的自然选择。

2.5、 数据治理

数据治理用例是多个独立组织或实体协作定义公共流程和指令的场景。今天，数据治理的主要挑战是缺乏协作和信任。而且，参与者在治理主题上没有明确的合作动机。BigchainDB通过提供一个激励驱动的、易于集成的平台，帮助解决数据治理中的这些挑战。该方法将数据治理主题、反馈和经济激励建模为BigchainDB资产。一旦我们将数据治理系统建模为BigchainDB资产的集合，当使用公共底层共享数据并且鼓励所有参与者参与时，协作并在其上定义流程就变得相当简单。

2.6、 防篡改审计跟踪（Immutable Audit Trails）

防篡改审计跟踪是BigchainDB的一般用例之一。 虽然没有与任何垂直行业直接相关，但它们有助于解决垂直行业中的许多跟踪和跟踪挑战。 从银行业务到供应链，从公用事业到访问控制，严重依赖审计跟踪。 如果这些审计跟踪是防篡改的并且易于查询，它确实增加了很多价值。 由于高吞吐量和查询功能，BigchainDB成为维护防篡改审计跟踪的自然因素。

2.7、 关于用例的一些结束语

通常，BigchainDB几乎可用于所有需要以高吞吐量和搜索和查询能力进行数据资产存储的不可变和防篡改的场景。 BigchainDB也可以被希望拥有共享数据库的人或组织使用，即使他们不相互信任（或知道）。 必须注意一个存储在BigchainDB网络中的数据。 例如，不鼓励存储个人身份信息（PII），因为许多国家/地区都有法规要求PII可根据要求进行删除。

3. 去中心化生态中的BigchainDB

作为区块链数据库，BigchainDB是对其他去中心化系统的补充，例如去中心化文件存储（例如IPFS [11]），去中心化数据交换协议（例如Ocean Protocol[12]），智能合约区块链（例如[13，14]）或Hyperledger Fabric [15]）和去中心化处理（例如TrueBit [16]）。BigchainDB也适用于集中式计算系统。 图1说明了BigchainDB可用于各种技术堆栈的一些方法。

图1：从集中式云计算生态系统的基础环境（左），BigchainDB可以作为另一个数据库添加，以获得一些去中心化的优势（中）。 它还涉及一个完全去中心化的技术堆栈（右）。

4. BigchainDB交易的生命周期、BigchainDB 2.0如何工作的

通过跟踪BigchainDB交易的生命周期，可以了解BigchainDB 2.0是如何工作的。

4.1、 BigchainDB交易

BigchainDB交易是符合BigchainDB交易规范（Spec）的JSON字符串。在编写本文时，有两个这样的规范：v1和v2。符合BigchainDB Transactions Spec v1的交易被BigchainDB版本1.0-1.3接受；不再支持此类交易。符合BigchainDB Transactions Spec v2[17]的交易被BigchainDB版本2.0（即编写时的最新版本）接受。每个交易规范解释了预期的键和值（包括它们的含义）、如何构造交易的说明、检查交易是否有效必须执行的检查列表以及使用的加密原语的详细信息。清单1显示了一个示例BigchainDB交易（v2）。
如果有人想要构造有效的BigchainDB交易，那么他们通常使用BigchainDB驱动程序（软件包）。BigchainDB文档中有一个BigchainDB驱动程序列表[18]。

{
    "id": "3667c0e5cbf1fd3398e375dc24f47206cc52d53d771ac68ce14d df0fde806a1c" ,
    "version": "2.0" ,
    "inputs":  [
       {
          "fulfillment": "pGSAIEGwaKW1LibaZXx7_NZ5-V0alDLvrguGLyLRkgmKWG73gUBJ2Wpnab0Y-4i-kSGFa_VxxYCcctpT8D6s4uTGOOF-hVR2VbbxS35NiDrwUJXYCHSH2IALYUoUZ6529Qbe2g4G" ,
          "fulfills": null ,
          "owners_before":  [
             "5RRWzmZBKPM84o63dppAttCpXG3wqYqL5niwNS1XBFyY"
           ]
        }
      ],
      "outputs":  [
         {
         "amount": "1" ,
         "condition":  {
            "details":  {
               "public_key": "5RRWzmZBKPM84o63dppAttCpXG3wqYqL5niwNS1XBFyY" ,
               "type": "ed25519-sha-256"
              },
          "uri": "ni:///sha-256;d-_huQ-eG-QQD-GAJpvrSsy7lLJqyNhtUAs_own7aTY?fpt=ed25519-sha-256&cost=131072"
         },
        "public_keys":  [
           "5RRWzmZBKPM84o63dppAttCpXG3wqYqL5niwNS1XBFyY"
         ]
       }
     ],
     "operation": "CREATE" ,
     "asset":  {
        "data":  {
           "message": "Greetings from Berlin!"
       }
     },
   "metadata": null
 }

清单1：一个BigchainDB交易示例（v2）

4.2、 发送一个交易到BigchainDB网络

一旦有了交易，他们就可以使用BigchainDB HTTP API[19]将其发送到BigchainDB网络。更具体地说，在HTTP请求主体中的交易中使用以下请求之一：

POST /api/v1/transactions
POST /api/v1/transactions?mode=async
POST /api/v1/transactions?mode=sync
POST /api/v1/transactions?mode=commit

稍后，我们将了解不同模式的含义。BigchainDB驱动程序也可以用于发布交易。HTTP请求（包含交易）可以发送到BigchainDB网络中的任何节点，甚至不止一个。图2说明了四节点BigchainDB 2.0网络中的主要组件，以及它们如何相互通信。

图2：四节点BigchainDB 2.0网络中的通信

4.3、 节点中交易的到达

接下来发生的细节可能会有所不同。让我们跳过这些细节，并假设HTTP请求成功地到达BigchainDB节点内的GunicornWeb服务器，因为这是所有传入的HTTP请求应该被路由的地方。Gunicorn公开了一个标准接口（Web Server Gateway Interface[WSGI]），它使Python应用程序能够与之进行通信。（WSGI是Python标准；规范在Python增强建议3333[20]中。）BigchainDB使用Flask web应用程序开发框架来简化与WSGI/Gunicorn的工作。
Flask用于将请求路由到用于处理该端点的Python方法。该方法检查交易的有效性。如果它无效，那么这就是交易的结束，HTTP响应状态代码是400（错误），响应主体给出关于为什么无效的一些信息。如果交易有效，则将其转换为Base64，并将其与其他一些信息（如模式）一起放入新的JSON字符串中。然后，BigchainDB将该字符串发送到HTTP POST请求主体中的本地Tendermint实例。该请求使用Tendermint Broadcast API[21]（Tendermint还有其他API）。

4.4、 在Tendermint实例上交易的到达

要了解交易一旦到达本地Tendermint实例会发生什么，应该阅读关于Broadcast API的Tendermint文档[21]。在写本文当时，这些文档说：
当交易被发送到Tendermint节点时，它将通过CheckTx对应用程序运行。如果通过CheckTx，它将被包括在mempool中，广播到其他对等节点，并最终被包括在块中。
由于处理交易有多个阶段，因此我们提供多个端点来广播交易：
/broadcast tx async
/broadcast tx sync
/broadcast tx commit
它们分别对应于不处理、通过mempool处理和通过块处理。也就是说，broadcast tx async将立即返回，而不等待听到交易是否有效，而broadcast tx sync将通过CheckTx运行交易的结果返回。使用broadcast tx commit将等待直到交易在块中提交或达到某个超时，但是如果交易没有通过CheckTx，则将立即返回。…
使用broadcast tx commit的好处在于，请求在交易提交（即包含在块中）之后返回，但是可以采取秒的顺序。为了快速获得结果，使用broadcast tx sync，但是交易直到稍后才会提交，到那时，它对状态的影响可能会改变。
上述文字中的一些解释：

• CheckTx是Tendermint希望BigchainDB实现的API。下面将对此进行解释。
• 如果有人使用BigchainDB的POST /api/v1/transactions？mode=async端点发送交易，Tendermint将使用/broadcast_tx_async。对于同步和提交模式，可以采用类似的方式。如果没有指定模式，则默认为异步。
• 每个Tendermint实例都有一个交易的本地mempool（内存池），这些交易已经通过了初始验证，但是还没有包括在块中。
  当Tendermint想要确定交易是否有效时，它使用CheckTx请求将交易发送到BigchainDB。它期望BigchainDB实现CheckTx和其他几种消息类型，所有这些都在ABCI规范[22]中进行了说明。（ABCI表示应用程序块链接口。）具体而言，BigchainDB实现：
• InitChain
• Info
• CheckTx
• BeginBlock
• DeliverTx
• EndBlock
• Commit
  Tendermint负责提出新块（每个块包含一组交易），并确保所有节点都以拜占庭容错方式同意下一个块。每个BigchainDB实例通过收集（由DeliverTx）BeginBlock和EndBlock调用之间传递的交易来跟踪正在构建中的块。
  当Tendermint使用DeliverTx将交易交付给BigchainDB实例时，BigchainDB再次检查交易的有效性。如果它是有效的，它将交易保持在（内存中），但是还没有向MongoDB写入任何内容。BigchainDB在将新块（以及所有包含的交易）写入MongoDB之前等待提交消息。
  在MongoDB中存储交易时，BigchainDB删除asset.data值（JSON字符串），并将其存储在单独的MongoDB assets集合中。这样做是为了方便assets的文本搜索。类似地，元数据值（JSON字符串）也被移除并存储在单独的集合中。
  Tendermint在获得对Commit消息的响应之后将块写入到块链（存储在本地LevelDB数据库中）。
  我们隐藏了上面的一些细节，因为我们的目标是给出一个总体的概述。如果你想了解所有的细节，那你就走运了！所讨论的所有代码都是开源的，因此您可以查找它，并准确地阅读它的功能。

5. 进一步阅读（技术阅读）

• BigchainDB Transactions Spec v2 [7]
• BigchainDB HTTP API [19]
• BigchainDB Enhancement Proposals [23]
• Tendermint Documentation [24]
• Tendermint ABCI Speci_cation [25]
• Papers about Tendermint found by Google Scholar [26]

6. 如何尝试BigchainDB

如果想尝试BigchainDB，则需要连接到BigchainDB网络。您可以部署自己的网络，也可以使用BigchainDB Testnet，它是由BigchainDB开发团队操作的实时BigchainDB网络。
如果转到BigchainDB网站上的Get Started页面[27]，您可以输入一些文本并单击“Off you go”。页面内的JavaScript应用程序将构建BigchainDB交易并将其发送到BigchainDB Testnet。您可以看到构造的交易，并检查它是否被实际存储。
您还可以编写自己的应用程序来向BigchainDB网络进行写入和读取。它可以使用任何编程语言编写，但是有用于JavaScript和Python的官方BigchainDB驱动程序（软件包），因此我们建议使用其中之一。链接可以在文档的“驱动程序和工具”页面中找到[18]。这些驱动程序的文档包括示例代码。
一旦您编写了一个应用程序，就可以通过BigchainDB Test-net对其进行测试，但是首先需要访问凭据。你可以在testnet.bigchaindb.com注册一个帐户（免费）获得这些信息。

7. 如何贡献想法或代码

我们更改了流程，使得任何人都可以更容易地向BigchainDB贡献想法或代码。可以在Gitter上的BigchainDB聊天室之一中询问问题[28]。可以通过在相关的GitHub存储库中创建新问题来提交错误报告。可以通过向相关的GitHub存储库提交拉动请求来更改代码。我们使用集体代码构建合同（C4）[29]的一个变体来指导我们如何处理拉动请求。可以通过在bigchaindb/BEPs存储库中提交BigchainDB增强建议（BEP）作为拉请求来提出详细的特性请求[30]。BEP的格式应该遵循我们在面向共识的规范体系（COSS）[31]的变体中给出的大纲。

8. BigchainDB 路线图

我们的目标是在2018年6月发布新的、稳定的BigchainDB 2.0。在此之前不会添加任何新特性；我们主要是（各种）进行测试。我们将修复出现的任何问题，并在获得性能测试结果后报告它们。
从BigchainDB 2.0开始，总会有一些工具和文档来帮助迁移到未来版本（包括数据迁移）。BigchainDB 2.0已经为许多用例做好了生产准备。
有一个列出我们中期目标的在线BigchainDB路线图[32]。它经常更新。一个目标是创建一些示例项目，说明如何将BigchainDB与其他去中心化系统（如Ethereum）一起使用。从长远来看，我们希望能够创建一个公共BigchainDB网络，任何人都可以在不获得许可的情况下添加节点。

9. 结论

BigchainDB是一个区块链数据库：它具有区块链属性和数据库属性。这种组合使得它适用于各种各样的用例，包括供应链、知识产权管理、数字双胞胎和物联网，身份、数据治理和不变的审计跟踪。BigchainDB 2.0包括显著的改进，包括针对节点间联网的Tendermint集成和Byzantine容错（BFT）一致性。BigchainDB 2.0。现在已经为许多用例做好了生产准备。有关更多信息，请参阅bigchaindb.com上的BigchainDB网站。

参考
[1] Carlo Thomas. ascribe announces scalable blockchain database Big
chainDB. CoinReport , February 2016. https://coinreport.net/
ascribe-announces-scalable-blockchain-database-bigchaindb/ .
[2] 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 .
[3] Jae Kwon. Tendermint: Consensus without Mining, fall 2014.
[4] Tendermint. https://tendermint.com/ .
[5] MongoDB. https://www.mongodb.com .
[6] Anton Kaliaev (melekes on GitHub). tendermint/tendermint Issue #763:Introduce randomness into proposer selection? https://github.com/tendermint/tendermint/issues/763 .
[7] BigchainDB Transactions Spec v2. https://github.com/bigchaindb/
BEPs/tree/master/13 .
[8] Cosmos: A Network of Distributed Ledgers.https://cosmos.network/
resources/whitepaper .
[9] John R Douceur. The Sybil Attack. In Peer-to-peer Systems , pages
251{260. Springer, 2002. http://research.microsoft.com/pubs/74220/
IPTPS2002.pdf .
[10] ascribe. https://www.ascribe.io/ .
[11] J. Benet. IPFS { Content Addressed, Versioned, P2P File System. http:
//static.benet.ai/t/ipfs.pdf , 2014.
[12] Ocean Protocol: A Decentralized Substrate for AI Data & Services. https://oceanprotocol.com/tech-whitepaper.pdf .
[13] Ethereum. https://ethereum.org/ .
[14] Vitalik Buterin. Ethereum White Paper: A Next Generation Smart Contract & Decentralized Application Platform.http://blog.lavoiedubitcoin.info/public/Bibliotheque/
EthereumWhitePaper.pdf .
[15] Hyperledger Fabric. https://www.hyperledger.org/projects/fabric .
[16] Jason Teutsch and Christian Reitwie_ner. A scalable veri_cation solution for blockchains. November 2017.
[17] BEP-13: BigchainDB Transactions Spec v2. https://github.com/bigchaindb/BEPs/tree/master/13 .
[18] BigchainDB Drivers & Tools. https://docs.bigchaindb.com/projects/server/en/latest/drivers-clients/index.html .
[19] BigchainDB HTTP API. https://docs.bigchaindb.com/projects/server/en/latest/http-client-server-api.html .
[20] PEP 3333 { Python Web Server Gateway Interface v1.0.1. https://www.python.org/dev/peps/pep-3333/ .
[21] Tendermint Broadcast API. http://tendermint.readthedocs.io/projects/tools/en/master/using-tendermint.html#broadcast-api .
[22] Tendermint ABCI Speci_cation. https://github.com/tendermint/abci/blob/master/specification.rst .
[23] BigchainDB Enhancement Proposals. https://github.com/bigchaindb/BEPs .
[24] Tendermint Documentation. http://tendermint.readthedocs.io/projects/tools/en/master/index.html .
[25] ABCI Overview. http://tendermint.readthedocs.io/projects/tools/en/master/introduction.html#abci-overview .
[26] Papers about Tendermint found by Google Scholar. https://scholar.google.de/scholar？hl=en&as_sdt=0%2C5&q=Tendermint&btnG= .
[27] BigchainDB { Get Started. https://www.bigchaindb.com/developers/getstarted/ .
[28] BigchainDB chat rooms. https://gitter.im/bigchaindb/home .
[29] BEP-1: The BigchainDB Variant of the Collective Code Construction Contract (C4). https://github.com/bigchaindb/BEPs/tree/master/1 .
[30] The bigchaindb/BEPs Repository on Github. https://github.com/bigchaindb/BEPs .
[31] BEP-2: The BigchainDB Variant of the Consensus-Oriented Specication System. https://github.com/bigchaindb/BEPs/tree/master/2 .
[32] BigchainDB Roadmap. https://github.com/bigchaindb/org/blob/master/ROADMAP.md .