Date post: | 15-Apr-2017 |
Category: |
Technology |
Upload: | bigchaindb |
View: | 141 times |
Download: | 0 times |
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