This is pretty impressive work, hats off! Their extensive whitepaper is absolutely worth reading: https://www.bigchaindb.com/whitepaper/bigchaindb-whitepaper.... - its full of details of their solution and also has a good collection of background reading material.
What is important to note is that they don't address the Sybil attack on a technological level:
> Deploying BigchainDB in a federation with a high barrier of entry based on trust and reputation discourages the participants from performing an attack of the clones. The DNS system, for example, is living proof of an Internet-scale distributed federation. Appendix C describes how the DNS has successfully run a decentralized Internetscale database for decades.
As far as I understand with spending only little time on this matter that's the main tradeoff they took compared to fully decentralized databases such as the Bitcoin's public ledger and which allow them to scale the performance.
They use a lot of buzzwords but it comes down to one thing for me. Their security relies on trusting everyone in the federated group. Yes this has worked fairly well for the global DNS system but it has nothing to do with blockchains.
This is exactly the opposite of the Bitcoin model and a great example of the nonsensical hype around so-called blockchain technology. There is no real security if you have to trust a handful of the big guys to play fair.
The DNS was our inspiration. The fmr CEO and CTO are advisors and guided us through the process to build both the technology and the surrounding incentive and collaboration model.
To your point about "have to trust a handful of big guys to play fair," please refer to exhibit A - https://blockchain.info/pools - where 2 miners control 52% and 4 miners control over 75% of the hashing power. If that's not trusting a handful of guys to play fair, I don't know what is.
We can take a permissioned, federated model because we have no native asset coin that needs to be backed up by wasteful mining, meaning that BigchainDB can handle an infinite number of assets on the same ledger. That, along with our pipelining innovation, we can hit writes/s up to 2 million.
And it scales. BigchainDB isn't meant to replace Bitcoin, it's meant to serve enterprise customers who want to be able to run blockchain systems in production, at scale.
I really want to like this but it could do with a better summary explanation of how it works. I'm not sure I can understand the security properties of this without reading the 70 page whitepaper.
The whitepaper also mentions it is built on a commercial database but it doesn't mention which one on the website, that sounds like important information.
The idea of strapping on blockchain semantics onto traditional databases, distributes or otherwise has been around for quite a long time. Openchain is one such example. So we end up with a system of clients connecting to some distributed store and able to do a ton of tps, but without the ability to independantly verify transaction history. It is a completely different security problem then the public digital currency networks.
There are also assertions in the paper about Bitcoin and the network that are wrong. It's not a broadcast network, it's a peer-to-peer gossip network, there is a huge difference in terms of propagation and scale.
Openchain is a series of sidechains that communicate to one another, with only one authority that validates transactions within each sidechain.
BigchainDB is a single instance that leverages distributed databases but builds on top decentralized control so that for every transaction, a least a majority of nodes must validate and approve. Each block is validated and then chained together, giving the characteristic of immutability.
What is important to note is that they don't address the Sybil attack on a technological level:
> Deploying BigchainDB in a federation with a high barrier of entry based on trust and reputation discourages the participants from performing an attack of the clones. The DNS system, for example, is living proof of an Internet-scale distributed federation. Appendix C describes how the DNS has successfully run a decentralized Internetscale database for decades.
As far as I understand with spending only little time on this matter that's the main tradeoff they took compared to fully decentralized databases such as the Bitcoin's public ledger and which allow them to scale the performance.