BigchainDB：可扩展的区块链数据库，革新分布式存储

1星需积分: 49 114 浏览量更新于2024-07-20 1 收藏 3.26MB PDF 举报

巨链数据库（BigchainDB）是一项革新性的区块链技术解决方案，旨在填补分布式生态系统中的一个重要空白——一个可扩展的、去中心化的数据库。由Trent McConaghy、Rodolphe Marques、Andreas Müller等人在2016年6月提出，BigchainDB的设计灵感源于RethinkDB，但它超越了传统数据库的局限，提供了强大的性能与特性。首先，BigchainDB的目标是实现每秒百万级别的写入吞吐量，能够存储海量数据，同时保持低于一秒的响应时间。这使得它成为处理大规模商业交易和法律文档的理想选择，如合同和证书的存储。它的设计基础是一个分布式数据库（DB），确保了数据的分散存储，提高了系统的可用性和安全性。其次，BigchainDB引入了区块链的关键特性。通过分布式控制，所有参与者都能平等参与决策过程，实现了真正的去中心化管理。其 immutability（不可变性）保证了数据一旦写入就无法被修改，这对于需要记录不可篡改历史记录的应用场景至关重要。此外，BigchainDB支持创建和转移数字资产，比如加密货币或智能合约，这进一步拓展了其应用场景。在功能上，BigchainDB继承了现代分布式数据库的优点，如线性扩展，随着节点数量的增长，其处理能力和存储容量可以随之提升。它采用了一种全功能的NoSQL查询语言，使得数据查询效率高且灵活。同时，BigchainDB还具备权限管理系统，允许对数据访问进行精细控制，符合企业级安全标准。作为基于现有分布式数据库构建的项目，BigchainDB在大部分代码库中采用了成熟且经过企业级考验的代码基础，这意味着它在稳定性和可靠性方面有着坚实的基础。这种可扩展的容量使得将法律约束力强的文档直接存储在链上成为可能，降低了中介环节，提高了效率。总结来说，BigchainDB是一个集高性能、去中心化、不可变性和资产操作能力于一体的区块链数据库，它不仅提升了区块链技术在实际应用中的实用性，还在性能和安全性方面达到了商业级标准，为分布式系统中的关键数据提供了一个可靠的存储和管理平台。

DBs, and they handle replication in a sane fashion. Raft, a Paxos derivative, makes

distributed consensus systems easier to design and deploy.

Weaknesses. While their technical attributes and performance are impressive, tra-

ditional “big data” distributed DBs are not perfect: they are centralized. They are

deployed by a single authority with central control, rather than decentralized control as

in blockchains. This creates a number of failings. Centralized DBs are:

• Controlled by a single admin user so that if the admin user (or account) gets

compromised, then the entire database might become compromised.

• Mutable. A hacker could change a 5-year-old record without anyone noticing (as-

suming no additional safeguards in place). For example, this would have prevented

police from doctoring evidence in the India exam scandal [47]. In blockchains, tam-

pering with past transactons usually quite diﬃcult. Even if someone does manage

to change a past transaction, the change is easy to spot, because the hash of its

block get stored in the next block; an auditor would detect a hash mismatch.

• Not usable by participants with divergent interests in situations where

they do not want to cede control to a single administrator. For example, the risk

of losing control of the management of information is one reason that copyright

rightsholders in the music industry do not share a single DB.

• Not designed to stop Sybil attacks, where one errant node can swamp all the

votes in the system.

• Traditionally without support for the creation and transfer of digital

assets where only the owner of the digital asset, not the administrator of the DB,

can transfer the asset.

• Not typically open to the public to read, let alone write. Public openness is

important for public utilities. A notable exception is Wikidata [48].

3.5. Fault Tolerance in the BigchainDB System

Simultaneously preserving the scalability and trustless decentralization of both large-

scale databases and decentralized blockchains is the main objective of the BigchainDB

system. The following were considered when designing BigchainDB’s security measures:

• Benign faults: In the BigchainDB setup, nodes communicate through a database

which uses a fault-tolerant consensus protocol such as Raft or Paxos. Hence we

can assume that if there are 2f + 1 nodes, f benign-faulty nodes can be tolerated

(at any point in time) and each node sees the same order of writes to the database.

• Byzantine faults: In order to operate in a trustless network, BigchainDB in-

corporates measures against malicious or unpredictable behavior of nodes in the

system. These include mechanisms for voting upon transaction and block valida-

tion. Eﬀorts to achieve full Byzantine tolerance are on the roadmap and will be

tested with regular security audits.

• Sybil Attack: Deploying BigchainDB in a federation with a high barrier of entry

based on trust and reputation discourages the participants from performing an

attack of the clones. The DNS system, for example, is living proof of an Internet-

scale distributed federation. Appendix C describes how the DNS has successfully

run a decentralized Internet-scale database for decades.

4. BigchainDB Description

4.1. Principles

Rather than trying to scale up blockchain technology, BigchainDB starts with a “big

data” distributed database, and adds blockchain characteristics. It avoids the technology

choices that plague Bitcoin, such as full replication.

We built BigchainDB on top of an enterprise-grade distributed DB, from which BigchainDB

inherits high throughput, high capacity, a full-featured NoSQL query language, eﬃcient

querying, and permissioning. Nodes can be added to increase throughput and capacity.

Since the big data DB has its own built-in consensus algorithm to tolerate benign

faults, we exploit that solution directly. We “get out of the way” of the algorithm to

let it decide which transactions to write, and what the block order is. We disallow

private, peer-to-peer communication between the nodes except via the DB’s built-in

communication, for great savings in complexity and for reduced security risk

. This

means that malicious nodes cannot transmit one message to part of the network and

diﬀerent message to other part of the network. Everytime a node “speaks,” all the others

can listen.

4.2. High-Level Description

We focused on adding the following blockchain features to the DB:

1. Decentralized control, where “no one” owns or controls a network;

2. Immutability, where written data is tamper-resistant (“forever”); and

3. The ability to create & transfer assets on the network, without reliance on a

central entity.

Decentralized control is achieved via a DNS-like federation of nodes with voting per-

missions. Other nodes can connect to read and propose transactions; this makes it a

super-peer P2P network [2]. The voting operates at a layer above the DB’s built-in

consensus. Quorum is a majority of votes. For speed, each block is written before a

Though we must vigilantly exercise restraint in design, as intuition is to just get the nodes talking

directly!

quorum of nodes validates and votes on it. Chainiﬁcation actually happens at voting

time. Every block has an id equal to the hash of its transactions, timestamp, voters

list and public key of its creator-node. It also has a cryptographic signature and a list

of votes. A block doesn’t include the hash (id) of the previous block when it ﬁrst gets

written. Instead, votes get appended to the block over time, and each vote has a “previ-

ous block” attribute equal to the hash (id) of the block coming before it. Immutability

/ tamper-resistance is achieved via several mechanisms: shard replication, reversion of

disallowed updates or deletes, regular database backups, and cryptographic signing of

all transactions, blocks & votes. Any entity with asset-issuance permissions can issue an

asset; an asset can only be acquired by new owners if they fulﬁll its cryptographic con-

ditions. This means hackers or compromised system admins cannot arbitrarily change

data, and there is no single-point-of-failure risk.

4.3. Architecture

Figure 3 illustrates the architecture of the BigchainDB system. The BigchainDB system

presents its API to clients as if it is a single blockchain database. Under the hood,

there are actually two distributed databases

, S (transaction set or “backlog”) and C

(block chain), connected by the BigchainDB Consensus Algorithm (BCA). The BCA

runs on each signing node. Non-signing clients may connect to BigchainDB; depending

on permissions they may be able to read, issue assets, transfer assets, and more; section 7

explores this more.

Each of the distributed DBs, S and C, is an oﬀ-the-shelf big data DB. We do not

interfere with the internal workings of each DB; in this way, we get to leverage the scala-

bility properties of the DBs, in addition to features like revision control and beneﬁts like

battle-tested code. Each DB is running its own internal Paxos-like consensus algorithm

for consistency among the drives.

The ﬁrst DB holds the “backlog” transactions—an unordered set of transactions S.

When a transaction comes in, it gets validated by the receiving node and if it’s valid

(according to that node), then it gets stored in S. (Identical transactions arriving later

will be rejected.) The receiving node also randomly assigns the transaction to one of the

other nodes.

There are N signing nodes. S

= {t

k,1

, t

k,2

, . . . } is the set of transactions assigned to

node k.

Node k running the BigchainDB Consensus Algorithm (BCA) processes transactions

from S as follows: It moves transactions from the unordered set S

into an ordered list,

creates a block for the transactions, and puts the block into the second database C. C

is an ordered list of blocks where each block has reference to a parent block and its data,

that is, a blockchain.

A signing node can vote on whether it considers a block valid or invalid . To decide,

the signing node checks the validity of every transaction in the block, and if it ﬁnds an

This can be implemented as two databases, or as two tables in the same database. While there is no

practical diﬀerence, for the sake of clarity we describe it as two separate databases.

剩余63页未读，继续阅读

yooliee

粉丝: 37
资源: 4

BigchainDB：可扩展的区块链数据库，革新分布式存储

Big Data and its Applications in Supply Chain Management

bigchaindb：认识BigchainDB。 区块链数据库

blockchain数字巨链

新闻管理系统数据库设计

redis实现草稿箱

mysql workbench创建数据库

java有拥有草稿、用户、借车、订单、反馈、调查问卷等接口，帮我粗略写一个CSCI 外部接口需求

java有拥有草稿、用户、借车、订单、反馈、调查问卷等接口，帮我粗略写一个CSCI 能力需求

设计一个邮件收发系统数据库表结构

java有拥有草稿、用户、借车等接口，帮我粗略写一个CSCI 能力需求

最新资源

bigchaindb：认识BigchainDB。区块链数据库