BaumankaCoin - a bike in 3000 lines or a blockchain on the fingers

About Blockchain today does not write just lazy. There is a huge number of articles of varying degrees of clarity and usefulness. This is the next one. We wanted to create as simple as possible, but a working blockchain and write briefly, but understandable to non-specialists, how this dog This blockchain works. This is how the project BaumankaCoin was born, the source of which can be downloaded from GitHub .

Many people imagine the blockchain and cryptocurrency technology as a kind of mega rocket science. Of course, to understand all the subtleties and nuances - it will take a lot of time; but in reality, this technology, if you look, turns out to be much easier to understand than is commonly believed. By implementing our coin, we intended to help people understand the device of these technologies “on their fingers”.

BaumankaCoin was developed by two students, almiku and skalniy, under the mentorship of PavelMSTU .

The basics

Transaction

The first semantic unit with which we will deal is a transaction: transferring money from one account to another. In the modern world of banking systems, the transfer is carried out by reducing the amount opposite one name and increasing opposite another. In a blockchain transaction is arranged differently.

For now let's leave the question about mysterious and terrible mining, but let's talk only about transactions in the blockchain.

To begin with, assume that transactions look like this:

• Transaction 1 "Vasya sent 50 koins to Anya"
• Transaction 2 “Grisha sent 30 koins to Anya”
• ...

Having information about all completed transactions, you can find out the amounts in the accounts of Ani, Vasya and Grisha.
The overall structure is a bit more complicated. In each transaction there are fields:

• inputs - transactions that this transaction refers to.
• tails - a list of structures of the form: {recipient, amount}.

In our case, the transaction structure of Vasya and Grisha will look like this:

Now suppose that Anya was going to translate Ole 70 baumankakainov. As it was written above, for this Anya needs to refer to the transaction from Vasya and Grisha. The translation structure will be as follows:

We remember that when transferring a person is obliged to refer to previous transactions, however, you can refer to each specific transaction only once. That is, in order to spend the remaining 10 Coins, Anya cannot refer to money transfers from Vasya and from Grisha. What to do?

There is a very elegant way out of this situation: Anna must make a transfer for the remaining amount to herself.

In the future, Anya will be able to refer to the translation, which she made to herself, which will allow her to spend the last 10 coins.

As a result, all the operations described above can be represented as follows:

User identification

Let's talk about how a person gets the address of his e-wallet, to which people will transfer money to him. This procedure consists of three stages, which we will discuss later: generation of private and public keys, obtaining an address.

The main tool that determines each individual is the private key . Thus, to create a new account, you just need to take a random number from a certain range. If the number is chosen really randomly - the probability of coincidence that someone else has chosen the same number is extremely small.

Next, the public key is built using the private key . Then the public key is passed as an argument to the hash function .

Cryptographic hash functions are used in coin emission and message authentication protocols. In this particular case, the hash function is used to generate pseudo-random numbers. There are various functions for hashing, we will look at SHA-256 . Its peculiarity is that it converts any amount of incoming data into a hash of 256 bits. The result of the function, which is also a hash, is essentially the address of our wallet.

It must be said that knowing the value of the public key, it is difficult to calculate by what private key it was built. Also, the number of possible results of the function is ^2,256 .

Validation

Now, when making a transfer, we need to confirm that we are indeed the owners of the wallet. To do this, two more fields appear in the transaction structure:

• signature;
• public key.

Step A: our key is recorded in the public key field.

Step B: the transaction is signed and the signature is recorded in the appropriate field.

What is a signature? The signature creation scheme is as follows:

All transaction information is collected , i.e. inputs , tails and the public key . This information is passed to the hash function, and the hash and private key are transferred to the signature algorithm. This algorithm works in such a way that it is possible to find out with the help of the public key whether the correct private key was actually used, but the private key itself cannot again be known. The output is a string weighing 512 bits.

The overall structure of the transaction is as follows:

class Transaction { . . . protected: std::vector<Input> inputs; std::vector<Tail> tails; std::vector<uint8_t> pubKey = std::vector<uint8_t>(279, 0); std::vector<uint8_t> signature = std::vector<uint8_t>(64, 0); . . . }; 

Block

We now turn to the blocks.

A block is an object that stores several transactions and a link to the previous block.

The creation of the block involved in the so-called miners (about them below). To create a new block, you need to fill in all the fields and fulfill a certain condition. The block creation scheme is as follows:

The illustration shows the process as a result of which the first block appears. Let's look at it in more detail.

1. The first thing that a miner faces is checking the correctness of transactions that network members want to implement. He should validate the signatures and check that transactions do not refer to already used tails. It is also worth noting that one block can hold a limited amount of information, so the number of transactions for a block is limited.
2. After that, all validated transactions are passed as arguments to the hash function. At the output, we get one of the elements of the first block - Merkle Root .
3. The data supplied to the second hash function (see picture): hash header of the previous block; merkle root; transactions; nonce (about this field below).
4. Everything is hashed and the hash is checked for a "specific view". For example, it checks that the last 4 bytes of the hash are zeros. If this is not the case, the nonce field changes and the miner again tries to get the block. It is impossible to predict the result of the hash function, which means that the miner simply needs to change the nonce argument until the result takes the desired form.

Thus, a valid block can be considered a block that includes the hash of the previous block, the hash of all transactions entered into the block, the list of transactions themselves and nonce fields, and the hash of this block must have a certain appearance, which is achieved by making changes to the nonce field.

As soon as the miner selects the required nonce value, he can send this block to all network participants and mine the next one. If someone made this block before him, he would have to start work already with the new block.

For example, a series of 3 blocks will look like this:

Data persistence

Since the information is transmitted over the network, anyone can change it and pass on the false version.
The blockchain device eliminates such attempts. The information inside the transaction cannot be changed, since the signature will become invalid. The information in the block itself cannot be changed either, since the merkle root hash will not correspond to reality and / or the block hash itself will not satisfy the conditions. Thus achieve the immutability of information.

The very first transaction

An attentive reader may wonder what the first block refers to? Especially for this case there is a “Genesis block” ( Genesis block ) with known fields and a generation algorithm. A chain is considered legitimate only if it begins with a genesis block and all transactions and blocks contained in it are also legitimate.

Branching

Any miner can add a block to the blockchain (provided that all checks are passed). And, since the blockchain is a sequence, the blocks can be numbered by the so-called “height” - the sequence number from the genesis block number 0, however this height is not a unique block identifier.

Each block can only refer to the previous one, but what happens if several blocks appear that refer to the same one? They will have the same height (that is why the height is not used as an identifier), and the chain will become more like a tree. This really happens from time to time when miners create blocks with a difference of just a few seconds (or if attackers with large computing power have attempted to roll back transactions). This is called "fork" ( chainfork ).

Each node independently chooses which of these blocks to accept. We agreed to stop the selection at the first received. Sooner or later, a block with a greater height will appear, then the “main” will become a longer chain, and the forks will be gradually forgotten (as a rule, they do not grow more than one block).

Blocks of forks in some sources are called orphan , in others stale . At bitcoin.it , for example, the terminology changes in different articles ( 1 , 2 ). We stick to the name "stale", because it is closer etymologically. But it is worth mentioning the orphan-blocks. These are such blocks whose information about the predecessors of which the node does not yet possess (that is, cannot verify their authenticity). Recently, few client applications support the work with orphan-blocks, they are usually rejected.

Network

The blockchain is built on a peer-to-peer broadcast network, where each node stores a complete copy of the entire chain. This is sufficient to maintain the basic functionality (block and transaction exchange). For example, in Bitcoin, this is about 130GB at the time of writing (the actual size is here ).

One of the main problems to be addressed in order to connect a new node to the network is the search for the rest of the network. There is no fully decentralized solution at the moment. Bitcoin uses a BitTorrent tracker analogy called DNS Seed , a server that is used to help find the other peers. The information on such servers is hard.

Further connection to all known peers is the same and completely decentralized. Let's look at this process in more detail and for definiteness we call the new node A , and the already well-known feast B. When connected, A sends a B version- message with the following content:

 class version { public: . . . net_addr addr_recv; net_addr addr_from; uint32_t nonce; }; 

B must reply with an empty verack message and set the protocol version to the minimum from his and those received from A , and also send the version from his side. Similar actions are done by A. This process is called a “handshake” (version handshake), and after it is completed, the nodes communicate using a protocol version supported by both of them.

Next is the exchange of information about famous feasts. A requests from B a list of active peers known to him by means of a getaddr request that contains nothing. A peer is considered active if B has received messages from him recently (in Bitcoin, the last three hours). B responds with addr- message with information about nodes.

Inventory messages

When someone creates or receives a transaction or block, he sends an inv message containing several structures of the type {object type (block / transaction), hash} with information about these objects. The recipient responds to getdata messages with the same structures as inv structures, but listing only new objects for themselves. And only after that, sending messages with complete information about the blocks ( block ) and transactions ( tx ) occurs.

After the handshake, A still knows nothing about the relevance of his blockchain. Therefore, this information should be updated. For this, A sends a getblocks request containing the hash of the last block it knows to.

If B has newer blocks, it sends them with pre-sending inv messages. The whole process described looks something like this:

Conclusion

Hopefully, these simple explanations of complex processes have helped form the reader’s idea of ​​blockchain technology. One of the most useful articles that helped us throughout the work was Bitcoin in a Nutshell . As well as protocols with bitcoin.org and bitcoin.it. We remind you that the source can be downloaded here .