Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm looking at this will little knowledge of how this makes the blockchain application easier. What seems odd to me is that merging branches isn't supported? So you can't perform a bunch of "transactions" and then merge them back into your master state. Maybe someone could illuminate the purpose this solves a little more clearly, as I'm guessing it has nothing to do with my naive understanding.


This is apparently intended to be used for a blockchain that contains SQL transactions in the blocks [1]. As there can be multiple 'heads' of a blockchain (before the network settles on a longest chain), there is a chance the head you picked as being the currently 'longest chain' eventually will not be on the longest chain at all. Hence you'd need the ability to go back to a point in time and execute the queries for another head, should it become the longest one.

This also explains why merging is not included (it is simply not needed for this application).

I did an SQL-on-blockchain a while ago [2][3] and ran into this problem as well. I solved it by not committing the last N transactions, and re-executing them for each read query in a transaction. This obviously is not a very efficient solution (and still runs the risk of having to re-execute the whole chain of queries in case a chain split occurs further than N blocks before the current head).

[1] https://github.com/aergoio/aergo [2] https://catena.one [3] https://github.com/pixelspark/catena


Bitcoin-like block chains don’t merge.


We would need some rules for how to resolve collisions. If I change a record in two different ways, which one wins?


That is up to the upper layers to decide which record wins.

In my implementation, the default is to take the records from the "other" branch because you want 'devel' in 'master' not the other way around. Not sure I am clear. LMK.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: