Introduction to BigchainDB

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 algorithm
Block construction order
After nalizing the creation of a block, that
block must not allow any more transactions to
be added to it. For easier detection of double-
spending.
Hashing votes
No need to include votes for computing block
hash. Because votes are digitally signed by
signing nodes, and therefore not malleable.
21

Consensus algorithm
Dropping transactions
Add a way to re-assign transactions if the
previous node assignment got stale.
Denial of service
Not an issue any more than with a traditional
web service.
22

Consensus algorithm
Client transaction order
Must ensure that transactions sent from the
same client in a particular order are processed
in that order, or at least with a bias to that
order.
Database built-in communication vulnerability
Use big data DB’s own built-in consensus
algorithm like Paxos to tolerate benign failures.
Many nodes would have to be affected for it to
have any major consequences.
23

Consensus algorithm
Double spends
All past transactions are checked to make sure
that input was not already spent. This can be
fast for BigchainDB because it can use an
optimized query of the underlying DB.
Malicious behaviour
Because of the federation model, bad behavior
can be detected when a node’s vote on a block is
different than the majority.
24

Consensus algorithm
Admin becoming god
If admin can be god, that constitute a single
point of failure. To prevent it, all write
transactions ( 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 is
still online. Otherwise, wait until enough nodes
come back online to vote.
25

Consensus algorithm
Chaining blocks rather than transactions
It is easier to write 1000 blocks (each
containing up to 1000 transactions) per second
than to write 1 million transactions per second.
Each voting node only has to append a vote to
each block, rather than to each transaction.
Constructing a vote needs to compute a
cryptographic signature. Save time by doing
that only once per block.
26

Possible use cases
Tracking 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

References
BigchainDB
BigchainDB Whitepaper
BigchainDB Documentation
The DCS triangle
BigchainDB: how we built a blockchain database
on top of RethinkDB
28

Introduction to BigchainDB

More Related Content

What's hot (18)

Similar to Introduction to BigchainDB (20)

Recently uploaded (20)

Introduction to BigchainDB