Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2803

Abstract

lock we must know the hash of the previous block and create the rest of the required content (= index, hash, data and timestamp). Block data is something that is provided by the end-user.</p> <figure id="4b1c"> <div> <div>

            <iframe class="gist-iframe" src="/gist/lhartikk/9029e732712345d17db90f005817f466.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><h2 id="1317">Storing the blocks</h2><p id="8624">A in-memory Javascript array is used to store the blockchain. The first block of the blockchain is always a so-called “genesis-block”, which is hard coded.</p>
    <figure id="966b">
        <div>
          <div>
            
            <iframe class="gist-iframe" src="/gist/lhartikk/cf05294551eb9cfb85bebd075c1e1737.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><h2 id="393e">Validating the integrity of blocks</h2><p id="c7af">At any given time we must be able to validate if a block or a chain of blocks are valid in terms of integrity. This is true especially when we receive new blocks from other nodes and must decide whether to accept them or not.</p>
    <figure id="9571">
        <div>
          <div>
            
            <iframe class="gist-iframe" src="/gist/lhartikk/bfc392a9d0156582de42b0d8fa2a0d5a.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><h2 id="c0a2">Choosing the longest chain</h2><p id="515a">There should always be only one explicit set of blocks in the chain at a given time. In case of conflicts (e.g. two nodes both generate block number 72) we choose the chain that has the longest number of blocks.</p><figure id="ee0f"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*KM7WYPiZwxyfDL6Eb66QIg.png"><figcaption></figcaption></figure>
    <figure id="bba9">
        <div>
          <div>
            
            <iframe class="gist-iframe" src="/gist/lhartikk/41d840235c5558a572324d59994e98b4.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><h2 id="677d">Communicating with other nodes</h2><p id="fa18">An essential part of a node is to share and sync the blockchain with other nodes. The following rules are used to keep the network in sync.</p><ul><li>When a node generates a new block, it broadcasts it to the network</li><li>When a node connects to a

Options

new peer it querys for the latest block</li><li>When a node encounters a block that has an index larger than the current known block, it either adds the block the its current chain or querys for the full blockchain.</li></ul><figure id="606d"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*sz2iVHdWBdtwNl3npeLddQ.png"><figcaption>Some typical communication scenarios that follows when the nodes obey the described protocol</figcaption></figure><p id="af4f">No automatic peer discovery is used. The location (=URLs) of peers must be manually added.</p><h2 id="2219">Controlling the node</h2><p id="d04f">The user must be able to control the node in some way. This is done by setting up a HTTP server.</p> <figure id="59e2"> <div> <div>

            <iframe class="gist-iframe" src="/gist/lhartikk/410744c0699214daa9f7af506306cdb4.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><p id="c396">As seen, the user is able to interact with the node in the following ways:</p><ul><li>List all blocks</li><li>Create a new block with a content given by the user</li><li>List or add peers</li></ul><p id="8f31">The most straightforward way to control the node is e.g. with Curl:</p><div id="18f6"><pre><span class="hljs-comment">#get all blocks from the node</span>

curl http://localhost:3001/blocks</pre></div><h2 id="990d">Architecture</h2><p id="5987">It should be noted that the node actually exposes two web servers: One for the user to control the node (HTTP server) and one for the peer-to-peer communication between the nodes.(Websocket HTTP server)</p><figure id="f7c3"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*BMc5ZcrrH1IRtAx1dOG7DQ.png"><figcaption>The main components of NaiveChain</figcaption></figure><h2 id="3784">Conlusions</h2><p id="c8fc">The NaiveChain was created for demonstration and learning purposes. Since it does not have a “<a href="https://en.bitcoin.it/wiki/Mining">mining</a>” algorithm (<a href="https://en.wikipedia.org/wiki/Proof-of-stake">PoS </a>of <a href="https://en.wikipedia.org/wiki/Proof-of-work_system">PoW</a>) it cannot used in a public network. It nonetheless implements the basic features for a functioning blockchain.</p><p id="8250">You can check the <a href="https://github.com/lhartikk/naivechain">Github repository</a> for more technical details.</p><p id="6bf3">If you want to understand more about blockchains, I suggest you to check out <a href="https://lhartikk.github.io">Naivecoin: a tutorial for building a cryptocurrency</a>. In this tutorial we will talk more about e.g. mining (proof-of-work), transactions and wallets.</p></article></body>

A blockchain in 200 lines of code

The basic concept of blockchain is quite simple: a distributed database that maintains a continuously growing list of ordered records. However, it is easy to get mixed up as usually when we talk about blockchains we also talk about the problems we are trying to solve with them. This is the case in the popular blockchain-based projects such as Bitcoin and Ethereum . The term “blockchain” is usually strongly tied to concepts like transactions, smart contracts or cryptocurrencies.

This makes understanding blockchains a necessarily harder task, than it must be. Especially source-code-wisely. Here I will go through a super-simple blockchain I implemented in 200 lines of Javascript called NaiveChain.

Block structure

The first logical step is to decide the block structure. To keep things as simple as possible we include only the most necessary: index, timestamp, data, hash and previous hash.

The hash of the previous block must be found in the block to preserve the chain integrity

Block hash

The block needs to be hashed to keep the integrity of the data. A SHA-256 is taken over the content of the block. It should be noted that this hash has nothing to do with “mining”, since there is no Proof Of Work problem to solve.

Generating a block

To generate a block we must know the hash of the previous block and create the rest of the required content (= index, hash, data and timestamp). Block data is something that is provided by the end-user.

Storing the blocks

A in-memory Javascript array is used to store the blockchain. The first block of the blockchain is always a so-called “genesis-block”, which is hard coded.

Validating the integrity of blocks

At any given time we must be able to validate if a block or a chain of blocks are valid in terms of integrity. This is true especially when we receive new blocks from other nodes and must decide whether to accept them or not.

Choosing the longest chain

There should always be only one explicit set of blocks in the chain at a given time. In case of conflicts (e.g. two nodes both generate block number 72) we choose the chain that has the longest number of blocks.

Communicating with other nodes

An essential part of a node is to share and sync the blockchain with other nodes. The following rules are used to keep the network in sync.

When a node generates a new block, it broadcasts it to the network
When a node connects to a new peer it querys for the latest block
When a node encounters a block that has an index larger than the current known block, it either adds the block the its current chain or querys for the full blockchain.

Some typical communication scenarios that follows when the nodes obey the described protocol

No automatic peer discovery is used. The location (=URLs) of peers must be manually added.

Controlling the node

The user must be able to control the node in some way. This is done by setting up a HTTP server.

As seen, the user is able to interact with the node in the following ways:

List all blocks
Create a new block with a content given by the user
List or add peers

The most straightforward way to control the node is e.g. with Curl:

#get all blocks from the node
curl http://localhost:3001/blocks

Architecture

It should be noted that the node actually exposes two web servers: One for the user to control the node (HTTP server) and one for the peer-to-peer communication between the nodes.(Websocket HTTP server)

Conlusions

The NaiveChain was created for demonstration and learning purposes. Since it does not have a “mining” algorithm (PoS of PoW) it cannot used in a public network. It nonetheless implements the basic features for a functioning blockchain.

You can check the Github repository for more technical details.

If you want to understand more about blockchains, I suggest you to check out Naivecoin: a tutorial for building a cryptocurrency. In this tutorial we will talk more about e.g. mining (proof-of-work), transactions and wallets.