Bitcoin's blockchain is necessary because newer blocks need to inherit the proof-of-work done on previous blocks, since the correct chain will be the one with the most cumulative work in it (presuming it's also valid). So it needs to be a sequential list of blocks, where each new block references the previous one.
But I can't see why this is useful when a) proof-of-work isn't used and b) blocks are separate databases. Why not just have one, big database and accept commits into this if they're signed with the expected private keys?
I'd like to see a decentralised database that doesn't require downloading the entire dataset. It should be possible to implement index-only queries that don't need to do a full table scan and therefore could run entirely in a browser. The only problem is that having an index for every possible query means the indices require more data than the dataset itself.
This is interesting enough for me to dig into and read the code, but what am I going to use this for? Now if transactions were blocks in a single database I could see more use for this.
Maybe it's too early and too little coffee for me to have a brilliant thought!
I think a lot of people see that 1) Bitcoin uses a blockchain and 2) Bitcoin creates digital money seemingly out of nowhere, and feel fascinated with the technology without being able to explain exactly why. So we're left with a lot of people using blockchains without really understanding the reasoning behind it.
You're not missing anything, in my opinion.
Private blockchains make little sense, and the standard rebuttal of this simply lists a large number of "potential applications", without going into detail on any of them and explaining how a private blockchain solves that specific problem.
Is there a small tutorial on how to quickly set this up for demo and evaluation?
If that's so, what is the purpose of distributing blank sqlite databases (with exception of blockchain keys metadata)? Also, how is it p2p distributed if several users may have the sqlite databases in different state (and thus, different sqlite files)?
I'm guessing that SQL databases were chosen to enable easy queries of structured data...
I think moving those into two separate but compatible projects might help both of them take off.
Of all databases, sqlite has this special interest : it's the perfect tool to be embedded as local database in clients.
Now, if we consider that blockchain is a new p2p effort to build decentralized softwares, putting sqlite on a blockchain makes a lot of sense : this is a mean to distribute data for decentralized apps.
It also makes sense in an era where data mining becomes a thing on its own, and not just as part of a software stack.
Now, this is clearly not a drop in for our usual database on our server (where latency and concurrent writing is the topmost concern, two points which are blockchains weak points - and sqlite weakpoints), but there is certainly something to explore there.
In this implementation it seems anyone can read the blockchain, but writing to it is permissioned/controlled.
All in all, it in many ways mitigates the need for trust between the systems participants, just like what is the purpose of the block chain in the case of for example bitcoins.