
Learn Blockchains by Building One - tzury
https://hackernoon.com/learn-blockchains-by-building-one-117428612f46
======
geraldbauer
FYI: You might also be interested in Awesome Blockchains [1] includes
blockchain samples (from scratch) with proof of work, transactions, etc. in
Ruby, Python, and JavaScript. PS: I've also bundled up the samples for easy
(re)use into libraries, see the blockchain-lite ruby gem or node package
module (npm), for example. Happy blockchaining. Cheers. [1]:
[https://github.com/openblockchains/awesome-
blockchains](https://github.com/openblockchains/awesome-blockchains)

------
dbattaglia
I know all discussions about blockchains must include the obligatory mention
of mankinds utopian future as a result of it, but damn did it feel jarring
here. The article was such a rare and excellent technical explanation behind
the concept of blockchains. It was all meat and no hype. And then it ends with
"Blockchains will rapidly change the way we think about economies, governments
and record-keeping.". Seems like a pretty amazing linked list, would love just
a bit more explanation why you were lead to that conclusion.

------
geraldbauer
FYI: For more blockchain samples from scratch (in JavaScript) see the notes
from last week's Vienna.js talk titled "Build Your Own Blockchain in 20 Lines
of JavaScript - Blockchain! Blockchain! Blockchain! For Fun (and Profit)" \-
[https://github.com/geraldb/talks/blob/master/blockchain.md](https://github.com/geraldb/talks/blob/master/blockchain.md)
Cheers.

~~~
dnautics
I can't tell if the author is being funny or being insane, but it's great
either way.

------
bobwaycott
Damn, this is a great post. It really demystified a lot for me.

Question for those in the know (or the author, if you're lurking about):

> _At this point, the idea of a chain should be apparent—each new block
> contains within itself, the hash of the previous Block. This is crucial
> because it’s what gives blockchains immutability: If an attacker corrupted
> an earlier Block in the chain then all subsequent blocks will contain
> incorrect hashes._

Grokking the idea of a chain is certainly apparent. However, it's a bit less
clear in what specific way referencing blockchain immutability with this
statement should be taken. If an attacker corrupted an earlier block in the
chain, is that being mentioned as something that occurs _after_ all subsequent
blocks have already been created, thus proving the corrupted block is, indeed,
corrupted by way of identifying it via verifying hashes and seeing a corrupted
one?

If a bad actor corrupted block _N_ , then all blocks after block _N_ would
themselves be corrupt (and presumably invalid and a waste of mining effort),
correct? At this point, it seems to me that protecting the integrity of the
chain requires dismissing the corrupted block & all its children, right?
Doesn't that kind of indicate mutability of the chain? Or is immutability
maintained by allowing corrupted blocks to remain in the chain, but some other
process stepping in to essentially invalidate blocks?

I think there's something I'm missing here. No doubt it's obvious, and I'm
just looking past it.

edit: I'm also just starting the consensus section, so perhaps that will
resolve my confusion.

edit2: After finishing consensus, I think I get it.

~~~
thisisit
A block is connected or chained to the previous block by using the previous
block's hash and connected to the next block by providing it's hash. So the
immutability comes after the fact ie once the block is created.

So at N + M block, changing the Nth block means all M blocks will become
corrupted and needs to be changed or recalculated. The consensus or the p2p
will come in the way of re-doing the blocks as everyone except the attacker
will be at N+M. So unless everyone agrees there will be no way to change those
blocks ie forced immutability.

Though the part people have hard time getting their head that there is never a
single blockchain in existence. At a given point there are multiple
blockchains existing but only the block with "most work" or the most difficult
to calculate hash is added to the main chain. That is why the "confirmations"
are required for a payment. The older a block gets, the probability of it
getting added to the chain is higher. In bitcoin depending on the site, some
take 6 confirmations or 6 blocks before being sure that the coin cannot be
double spent.

~~~
vanflymen
Yup, you got it. :)

------
notaboutdave
Some other useful points:

1\. Transactions can be secured using public-key encryption. This way Bob
can't spend Alice's coins (unless he has her key pair).

2\. Wallets are typically a collection of public/private key pairs, where each
pair is a ledger address/password combo.

Also, I could be wrong, but it looks like the example code will accept longer
peer chains even if they're completely different.

Great article!

~~~
konschubert
> Also, I could be wrong, but it looks like the example code will accept
> longer peer chains even if they're completely different.

I think there is a problem with his proof-of-work algorithm in that his proof
of work is not tied to the transactions in the blockchain. Should't it include
the hash of the previous block or something, in order to prevent people from
simply building a new blockchain while re-using the proofs of work?

------
avinassh
If you are interested in building one in Golang, here is a good article I read
recently - Building Blockchain in Go [0]

Bonus: There is a pretty good Coursera course on the same - Bitcoin and
Cryptocurrency Technologies [1] and it also has a really good companion book -
Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction [2]

[0] - [https://jeiwan.cc/posts/building-blockchain-in-go-
part-1/](https://jeiwan.cc/posts/building-blockchain-in-go-part-1/)

[1] -
[https://www.coursera.org/learn/cryptocurrency](https://www.coursera.org/learn/cryptocurrency)

[2] -
[https://www.amazon.com/dp/B01GGQJ2XW](https://www.amazon.com/dp/B01GGQJ2XW)

------
konschubert
Isn’t there a mistake with your proof of work? Because the way you implemented
the proof of work, it isn’t tied to the transaction history. This means that
somebody could re-write the transaction history, compute the new block hashes,
and re-use your proofs of work. He could then mine a single new block, and
thus create a new longest chain and cause everybody to accept this chain. The
way to fix this would be to include the hash of the last block in the proof of
work for the next block. This way, proofs of work can not be recycled on other
chains.

------
sandGorgon
Does anyone if there is a formal verification mechanism for proof-of-work
blockchains (kinda like Jepsen) ?

------
jaequery
this is literally the best explanation of blockchain

~~~
wiremine
I always seem to internalize concepts like this better using code, vs. formal
math or abstract explanations. I learned basic neural networks that way using
this book last year:

[https://www.amazon.com/gp/product/B01EER4Z4G/](https://www.amazon.com/gp/product/B01EER4Z4G/)

Everybody learns different, but I'm wondering how many HN readers are "code-
first" sorts of learners?

~~~
tonybaroneee
Cool! And yeah, count me into that camp as well.

------
kexari
Thanks for this. Any idea how to build a simple p2p network though (over the
internet not local host) and make it decentralized? That’s the hardest part :p

~~~
zeroxfe
It's actually not that hard. Most blockchains use a variation of Gossip, which
is quite trivial to implement. On startup, your nodes get a list of seed
nodes, recursively ask for peer lists until they can connect to some "max peer
count."

When they receive transactions (from a client, or a peer), they simply forward
them to all other peers (if it's the first time they've seen them.)

That's basically it. :-)

------
jokoon
Aren't there existing implementations of decentralized data storage or
database that use a blockchain?

I've thought a little about it, and I wonder what could be achieved. Storing
the data on peers, redundancy, private or public access... I think it's
possible, but I'm not really sure. Does anyone have already studied the idea?

~~~
atomical
Filecoin, Sia. It's actually a horrible idea. Can you imagine competing with
Amazon?

~~~
kamping
?

~~~
atomical
Do you have a point? Make it.

------
tudorconstantin
One thing I don't grasp is: are the transactions part of their block's hash?

Because if they're not, what's stopping an attacker adding random transactions
to exising blocks, thus enabling double spending?

If they are, how is it possible to validate a bitcoin transaction in less than
10 minutes?(the average target time to mine a btc block)

~~~
monort
Transactions are a part of block's hash. What do you mean by the second
question?

------
yandrypozo
this one is in Go, and looks really nice: [https://jeiwan.cc/posts/building-
blockchain-in-go-part-1/](https://jeiwan.cc/posts/building-blockchain-in-go-
part-1/)

------
m3kw9
When a software concept is explained in code it leaves no ambiguity, can
anyone verify this is a legit explanation? I do find it make sense but some
code such as the Proof of Work I had to just trust the writer without testing
it out

------
mlamat
It seemed interesting until he started with the ideology...

------
EternalData
Awesome work! More tutorials like this are needed.

