The Second Wave of Blockchain Innovation | Hacker News Reader

The Second Wave of Blockchain Innovation

medium.com

39 pointsJd8 comments

I'm not trying to be snide but that article is very difficult to read b/c of the white text.

Readability[1] helps a lot in these cases.

As well as readability (mentioned above), I find Evernote's Clearly to be a great extension for reading anything on the web (medium.com tends to be notorious to read)...

https://evernote.com/clearly/

Note that you don't need a evernote account to use this (I don't, and it just works).

Argh, 'i.e.' means 'that is'; in the text, it is used to mean 'for example,' which is of course abbreviated 'e.g.'

Interestingly, this leaves out any mention of what all of these systems entail: global state shared between all users of a currency.

Expecting every user to perform all calculations on the system is a rather tall order, and one that will influence investment dynamics far more than any of the factors looked at in this MBA analysis of the space.

Every user might verify just a random sample of all calculations and the system would still work.

Three approaches to blockchain scalability were discussed:

    1. jury selection
    2. multichains
    3. hypercube

1. Jury Selection means that tx-s validated first by a small jury and only if there no consensus, theie entire network become involved.

2. Multichains is like sharding. And just like in sharding you need to decided on criteria for sharding (i.e. you shard by asset ID, geography of the sender or receiver, by the amount transferred, etc.)

3. Hypercube - you see every tx as an edge in the hypercube. Then this edges randomly assigned to the jury? I'm not fully understand this one.

It would be convenient if there was a data structure that could store the set of unspent transactions as a sparse tree, and easily add/remove transactions without knowing the full tree. Perhaps as a merkle tree. There might be something more efficient.

I think that if this has was included in each block, then a user of bitcoin could download the block headers starting from their last known-good block. Then download the structure containing the transaction set from a recent block (6-10 blocks back, perhaps) to prevent having invalid blocks with good proof of work at the end, as those wouldn't be built upon by other miners. Then download the transactions from the blocks after the one you have the transaction set from and only verify those blocks.

Reply on news.ycombinator.com