Daisy: A private blockchain where blocks are SQLite databases, in Go

Thinking twice about it, there is something exciting here about the concept.

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.

It is a private, yet decentralized, ledger. This can have many use cases; for example a ledger could be shared between a network of financial institutions, without one of these institutions getting to be the single source of truth. It could also be used by for example a nation state to make parts of its financial system transparent to the entities to which it holds relevance.

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.

The way that I understand it, the SQL databases are not empty and the mining process, if similar to standard blockchains, will mean that the block's hash has to be of a specific format. Thus data can be distributed, e.g. academic articles, which are safe from changes, as the hash is fixed.

I'm guessing that SQL databases were chosen to enable easy queries of structured data...

What's the point of using a blockchain in this way?

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?

You could probably probably get away with putting a single sqlite database on IPFS and using IPNS to point to the latest version and achieve the same thing. IFPS' block level deduplication means you'd only have to download the changes if the database receives a new update.

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.