

The Second Wave of Blockchain Innovation - Jd
https://medium.com/@Swarm/the-second-wave-of-blockchain-innovation-270e6daff3f5

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

~~~
dboyd
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/](https://evernote.com/clearly/)

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

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

------
woah
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.

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

~~~
nivertech
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.

~~~
fryguy
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.

