Cryptocurrencies and smart-contracts on top of a blockchain aren’t the most trivial concepts to understand, things like wallets, addresses, block proof-of-work, transactions and their signatures, make more sense when they are in a broad context. Inspired by Naivechain from Lauri Hartikka, the Naivecoin project is an attempt to provide as concise and simple an implementation of a cryptocurrency as possible.
From Wikipedia : A cryptocurrency (or crypto currency) is a digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units of the currency.
Naivechain uses websocket for p2p communication, but it was dropped to simplify the understanding of message exchange. It is relying only on REST communication.
Not all components in this implementation follow the complete list of requirements for a secure and scalable cryptocurrency. Inside the source-code, you can find comments with
INFO: that describes what parts could be improved (and how) and what techniques were used to solve that specific challenge.
Provides an API to manage the blockchain, wallets, addresses, transaction creation, mining request and peer connectivity.
It’s the starting point to interact with the Naivecoin, and every node provides a swagger API to make this interaction easier.
From the Swagger UI is possible to access a simple UI to visualize the blockchain and the unconfirmed transactions.
The blockchain holds two pieces of information, the block list (a linked list), and the transaction list (a hash map).
It’s responsible for:
The blockchain is a linked list where the hash of the next block is calculated based on the hash of the previous block plus the data inside the block itself:
A block is added to the block list if:
A transaction inside a block is valid if:
Transactions is a list of unconfirmed transactions. Nothing special about it. In this implementation, the list of transactions contains only the unconfirmed transactions. As soon as a transaction is confirmed, the blockchain removes it from this list.
[ transaction 1, transaction 2, transaction 3]
A transaction is added to the transaction list if:
A block represents a group of transactions and contains information that links it to the previous block.
The details about the nonce and the proof-of-work algorithm used to generate the block will be described somewhere ahead.
A transaction contains a list of inputs and outputs representing a transfer of coins between the coin owner and an address. The input list contains a list of existing unspent output transactions and it is signed by the address owner. The output list contains amounts to other addresses, including or not a change to the owner address.
The operator handles wallets and addresses as well the transaction creation. Most of its operation are CRUD related. Each operator has its list of wallets and addresses, meaning that they aren’t synchronized between nodes.
A wallet contains a random id number, the password hash and the secret generated from that password. It contains a list of key pairs each one representing an address.
The address is created in a deterministic way, meaning that for a given password, the next address is created based on the previous address (or the password secret if it’s the first address).
It uses the EdDSA algorithm to generate a secret public key pair using a seed that can come from a random generated value from the password hash (also in a deterministic way) or from the last secret key.
Only the public key is exposed as the user’s address.
The Miner gets the list of pending transactions and creates a new block containing the transactions. By configuration, every block has at most 2 transactions in it.
Assembling a new block:
The proof-of-work is done by calculating the 14 first hex values for a given transaction hash and increases the nonce until it reaches the minimal difficulty level required. The difficulty increases by an exponential value (power of 5) every 5 blocks created. Around the 70th block created it starts to spend around 50 seconds to generate a new block with this configuration. All these values can be tweaked.
this.blockchain.getDifficulty() returns the hex value of the current blockchain's index difficulty. This value is calculated by powering the initial difficulty by 5 every 5 blocks.
block.getDifficulty() returns the hex value of the first 14 bytes of block's hash and compares it to the currently accepted difficulty.
When the hash generated reaches the desired difficulty level, it returns the block as it is.
The node contains a list of connected peers and does all the data exchange between nodes, including:
The node rebroadcasts every information it receives unless it doesn’t do anything with it, for example, if it already has the peer/transaction/blockchain.
An extra responsibility is to get a number of confirmations for a given transaction. It does that by asking every node if it has that transaction in its blockchain.
Check it out: