Daisy: A private blockchain where blocks are SQLite databases, in Go(github.com)
github.com
Daisy: A private blockchain where blocks are SQLite databases, in Go
https://github.com/ivoras/daisy
12 comments
Everything abut this feels like the most terrible idea ever, but in such a fascinating way. It's beautiful.
My thought EXACTLY. Can't wait to play around with this...
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?
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.
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.
Something like https://github.com/lmatteis/torrent-net ?
I was thinking the same but you were able to articulate it much better!
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!
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!
Shameless plug: I've tried to articulate what Bitcoin is, and hence why the blockchain data structure was invented, in this article (hint: it's all related to proof-of-work)[1].
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.
[1] https://news.ycombinator.com/item?id=14553146
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.
[1] https://news.ycombinator.com/item?id=14553146
From what I read, any holder of a private key that is accepted as authoritative can add data to the chain at will and without restriction. The consensus algorithm would then allow that user to rewrite the entirety of the blockchain at will from the point their key was trusted forward by simply creating a longer chain at no cost. What am I missing?
> What am I missing?
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.
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.
Government employ working on publishing government documents here. This looks very interesting. What if a private key is leaked (by accident or on purpose)? It would be good to have multiple branches of government sign the published documents.
Is there a small tutorial on how to quickly set this up for demo and evaluation?
Is there a small tutorial on how to quickly set this up for demo and evaluation?
There is something I don't get about the databases distributed : they are read/write, and their data is not part of what is distributed in p2p, is that right? It seems to be what means "Block payloads are SQLite database files. Except for special metadata tables, their content is not enforced".
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)?
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)?
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...
I'm guessing that SQL databases were chosen to enable easy queries of structured data...
My understanding is the data is distributed, the metadata tables are enforced by the blockchain protocol, but the contents are free to be whatever the writer wants to put in the database. Once it's written, the metadata/protocol enforces the integrity of the data on the blockchain.
Indeed, it would make sense. "Content is not enforced" would mean "content data structure is up to block creator". Thanks!
I feel like people are actively trying to mash up technologies just because. No real benefit, just toy projects.
So? Just for fun is not allowed anymore?
¯\_(ツ)_/¯ idk I'd rather it be on Show HN than front page.
It was on posted as Show HN six days ago but didn't generate any discussion: https://news.ycombinator.com/item?id=14512531
This looks interesting, but I feel like it's conflating two equally interesting ideas, "what if only certain nodes could make new blocks" and "what if the blocks had some kind of structured data".
I think moving those into two separate but compatible projects might help both of them take off.
I think moving those into two separate but compatible projects might help both of them take off.
Private versions of Ethereum do both things; JP Morgan is leading the charge on this with their Quorum software. But it's object-structured data instead of SQL.
https://www.jpmorgan.com/country/US/EN/Quorum
https://www.jpmorgan.com/country/US/EN/Quorum
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.
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.
See https://github.com/pixelspark/catena - does exactly this.
Love this. Catana and Daisy have different approaches, Daisy is distributing databases that can bootstrap an offline app, while Catana is truly a decentralized online database. Both are really interesting ideas, thanks for pointing it out!
Why store a database file in each block when you could also store transactions? This is what Catena does: https://news.ycombinator.com/item?id=14548174. Also allows for some interesting things you can do with privileges, for instance.
I don't understand. The added value of a blockchain compared to a simple distributed store is that peers who don't want to trust each other need to get to an agreement. All the examples look like they can be solved with a standard distributed store like a set of couchDB instances where no deletion can happen.
If a blockchain is a public ledger, what is a private blockchain?
A blockchain is a distributed ledger, not necessarily public, although bitcoin, being the most famous, is public.
In this implementation it seems anyone can read the blockchain, but writing to it is permissioned/controlled.
In this implementation it seems anyone can read the blockchain, but writing to it is permissioned/controlled.
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.
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.
What's the difference/benefits from, for example, having a feed to stream pgp signed data where signature is for the current and previous message for example?
You just described a blockchain/DLT...