I am Dimi - a developer at BigchainDB.
In the Blockchain Stack it suggests that the Ethereum "decentralized processing" is above the File System and BigchainDB.
At BigchainDB we believe that each technology serves its purpose. In typical web-application stacks, some technologies are better at processing (eg. Amazon EC2) than data querying (eg. MongoDB). For developers it should feel natural to map a similar stack to the decentralized paradigm.
Here is an example how that could look like.
| Application: DApp |
| Processing: Ethereum, Hyperledger, ... |
| File Storage: | Database: | e-cash/e-gold: |
| IPFS, Swarm, ... | BigchainDB, IPDB, ... | Bitcoin, Ripple, ... |
How can BigchainDB be used in Ethereum?
There are many paths to achieve this. Some constraints are the isolation of the EVM during execution, standardization of messages and OP-codes, determinism of data and so on. Below I list a few scenario's on how to integrate Bigchaindb with Ethereum, and possibly other smart contract platforms. Note that some of them are more of-the-shelve than others - which would need additional opcodes or a maybe a fork of the source code.
- use Ethereum smart contracts as a registry with access control rights for storing URI's that point to external resources such as BigchainDB and IPFS.
- use BigchainDB as a registry for smart contracts in Ethereum. Eg dapp.registry.
- push data from BigchainDB to Ethereum as an oracle, without needing changes to Ethereum via eg. Oraclize and others
- use data in BigchainDB inside Ethereum dapp, as a first-class citizen but needing changes to Ethereum: requires an opcode to be added to Ethereum
- exchange messages/assets/data using the Interledger Protocol (ILP).
- integration by higher-level blockchain platform where BigchainDB & Ethereum are complementary (BigchainDB as DB backend; Ethereum as smart contracts or currency). Eg Monax, MonetaGo, BlockEx
- integration by higher-level blockchain application where BDB & Ethereum are complementary (BigchainDB as DB; Ethereum as smart contracts or currency)
Given BigchainDB keeps repeating "One Million Writes per Second" is that the same as transactions per second? Is scalability with tx/second then solved?
When we initially released BigchainDB, we showed the 1M writes/sec on the underlying datastore (RethinkDB) to show the possibility of large scale throughput, and as an aspiration for BDB throughput (we talk about "towards 1M"). Around that time, we had internal benchmarks with up to 200K tx/s. Since then, we paused the work on throughput, to focus on transaction UX and stability. So BDB has lower throughput right now, but in our roadmap has work to re-optimize BDB towards the aspirational numbers, being able to draw on the high performance & horizontal scaling of the underlying datastore as well as parallel processing.