Introduction to BigchainDB

2

DCS triangle

DCS triangle

4

5

6

DCS triangle

7

8

9

10

BigchainDB

Property

12

Architecture

13

14

Behaviour

15

Life of a transaction

16

Estimation of latency

17

Transaction model{ "id": "<hash of transaction , excluding signatures>", "version": "<version number of the transaction model>", "transaction": { "fulfillments": ["<list of fulfillments>"], "conditions": ["<list of conditions>"], "operation": "<string>", "timestamp": "<timestamp from client>", "data": { "hash": "<hash of payload>", "payload": "<any JSON document>" } } }

18

Block model{ "id": "<hash of block>", "block": { "timestamp": "<block - creation timestamp>", "transactions": ["<list of transactions>"], "node_pubkey": "<public key of the node \ creating the block>", "voters": ["<list of federation nodes public keys>"] }, "signature": "<signature of block>", "votes": ["<list of votes>"] }

19

Vote model{ "node_pubkey": "<the public key of the voting node>", "vote": { "voting_for_block": "<id of the block \ the node is voting for>", "previous_block": "<id of the block \ previous to this one>", "is_block_valid": "<true|false>", "invalid_reason": "<None| DOUBLE_SPEND \ | TRANSACTIONS_HASH_MISMATCH \ | NODES_PUBKEYS_MISMATCH>", "timestamp": "<timestamp of the voting action>" }, "signature": "<signature of vote>" }

20

Consensus algorithmBlock construction order

After �nalizing the creation of a block, thatblock must not allow any more transactions tobe added to it. For easier detection of double-spending.

Hashing votes

No need to include votes for computing blockhash. Because votes are digitally signed bysigning nodes, and therefore not malleable.

21

Consensus algorithmDropping transactions

Add a way to re-assign transactions if theprevious node assignment got stale.

Denial of service

Not an issue any more than with a traditionalweb service.

22

Consensus algorithmClient transaction order

Must ensure that transactions sent from thesame client in a particular order are processedin that order, or at least with a bias to thatorder.

Database built-in communication vulnerability

Use big data DB’s own built-in consensusalgorithm like Paxos to tolerate benign failures.Many nodes would have to be affected for it tohave any major consequences.

23

Consensus algorithmDouble spends

All past transactions are checked to make surethat input was not already spent. This can befast for BigchainDB because it can use anoptimized query of the underlying DB.

Malicious behaviour

Because of the federation model, bad behaviorcan be detected when a node’s vote on a block isdifferent than the majority.

24

Consensus algorithmAdmin becoming god

If admin can be god, that constitute a singlepoint of failure. To prevent it, all writetransactions ( including updating software )need to be voted on by the federation.

Of�ine nodes

One or a few of�ine nodes is �ne, as a quorum isstill online. Otherwise, wait until enough nodescome back online to vote.

25

Consensus algorithmChaining blocks rather than transactions

It is easier to write 1000 blocks (eachcontaining up to 1000 transactions) per secondthan to write 1 million transactions per second.

Each voting node only has to append a vote toeach block, rather than to each transaction.

Constructing a vote needs to compute acryptographic signature. Save time by doingthat only once per block.

26

Possible use casesTracking intellectual property assets

Receipts, and certi�cation

Legally-binding contracts

Creation and real-time movement of high-volume�nancial assets

Tracking high-volume physical assets

Smart contracts

Data science

27

ReferencesBigchainDB

BigchainDB Whitepaper

BigchainDB Documentation

The DCS triangle

BigchainDB: how we built a blockchain databaseon top of RethinkDB

28