An introduction to BigchainDB - by a fan and follower at Ethereum Meetup Taipei
3 likes612 views
A presentation uploaded by an outsider of BigchainDB, introducing BigchainDB's stack and the DCS triangle. Thanks to Feng-Ren Tsai
![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](https://image.slidesharecdn.com/intro-160729153413-161027095545/85/An-introduction-to-BigchainDB-by-a-fan-and-follower-at-Ethereum-Meetup-Taipei-18-320.jpg)
![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](https://image.slidesharecdn.com/intro-160729153413-161027095545/85/An-introduction-to-BigchainDB-by-a-fan-and-follower-at-Ethereum-Meetup-Taipei-19-320.jpg)
Ad
More Related Content
What's hot (18)
Viewers also liked (14)
Ad
Similar to An introduction to BigchainDB - by a fan and follower at Ethereum Meetup Taipei (20)
![[Call for code] IBM 블록체인을 활용하여 투명하게 구호기금 관리하기 - Hyperledger Fabric v1.1 by 맹개발](https://cdn.slidesharecdn.com/ss_thumbnails/callforcodeblockchainglobalcitizenyunhomaeng-180807004902-thumbnail.jpg?width=560&fit=bounds)
Ad
More from BigchainDB (8)
Recently uploaded (20)
An introduction to BigchainDB - by a fan and follower at Ethereum Meetup Taipei
- 2. 2
- 3. DCS triangle
- 5. 5
- 6. 6
- 8. 8
- 9. 9
- 10. 10
- 11. BigchainDB
- 12. Property 12
- 13. Architecture 13
- 14. 14
- 15. Behaviour 15
- 16. Life of a transaction 16
- 18. 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
- 19. 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
- 20. 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
- 21. 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
- 22. 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
- 23. 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
- 24. 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
- 25. 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
- 26. 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
- 27. 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
- 28. References BigchainDB BigchainDB Whitepaper BigchainDB Documentation The DCS triangle BigchainDB: how we built a blockchain database on top of RethinkDB 28