Ethereum Stack Exchange is a question and answer site for users of Ethereum, the decentralized application platform and smart contract enabled blockchain. It only takes a minute to sign up.
Sign up to join this community
BigchainDB says:
It is complementary to decentralized processing platforms like Ethereum.
In the Blockchain Stack it suggests that the Ethereum "decentralized processing" is above the File System and BigchainDB.
How can BigchainDB be used in Ethereum? Will Geth be able to use BigchainDB? Given BigchainDB keeps repeating "One Million Writes per Second" is that the same as transactions per second? Is scalability with tx/second then solved?
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.
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.
The part that's not clear is the interop... In the current model users of a Distributed ledget submit signed transactions through the network to be included in the next block mined. This is the chokepoint.
Would users instead push all transactions through a network into BigchainDB to be stored, than something would pull out ordered transactions from this db and create blocks to be executed by ethereum?
Or is the model more like : simple sends go to BigchainDB and Smartcontract calls go to ethereum? Some mechanism will sync ethereum execution state with BigchainDB (every block found changes balances in ethereum, those balances are then moved around within BigchainDB)
BigchainDB could be used alongside Ethereum (or vice-versa) and such integration would occur through a custom application or service.
The features of bigchaindb and ethereum are different so "writes per second" is comparing apples to oranges. Ethereum provides consensus executing EVM code (contracts) whereas - based on the whitepaper - BigchainDB provides a consensus layer for transfer of assets/value. That is, Ethereum stores the state of the system after executing code and BigchainDB stores the state of balances and registrations.
