What is Blockchain?

Blockchain is a distributed systems software architecture based on a network that assigns timestamps for transactions using hash formulas to insert them into the network blockchain — forming a chain that has a security mechanism based on the validation of transactions by most nodes in the chain. For an attack to be successful, the attacker would have to dominate most of the network's nodes, in the case of the bitcoin blockchain 9571 nodes are operating, making an attack that would alter the transaction chain is virtually impossible. The network needs minimal structure, and nodes can leave and return to the network at any time.

Origin

Blockchain is a distributed system architectural concept proposed in October 2008 by a person or group of people under the name of Satoshi Nakamoto, in the article "Bitcoin: A Peer-to-Peer Electronic Cash System" published in a mailing list named Cryptography Mailing.

Satoshi Nakamoto continued to develop Bitcoin and blockchain until 2010 when he made his last blog post that he built to discuss bitcoin on December 13, 2010, at 4:45 pm.

The original code is hosted on the SourceForge website, where you can also see the latest changes made by Satoshi Nakamoto to the code written in C ++.

How it works

1. Nodes
   A blockchain consists of several computers with distinct processing power that validates blockchain operations, that computers are called nodes. The architecture of a blockchain does not restrict where nodes will be in the world, nor when they can enter or leave the chain.
   

2. Chain of Transactions
   When a blockchain user wants to insert a new transaction in the chain, he needs to broadcast his transaction that will go to the nearest node. It is up to this node to forward the transaction received to the nodes adjacent to it, causing all nodes in the blockchain to receive the new transaction inserted in the chain.

3. Signature
   The blockchain architecture uses digital signatures in its transactions for validation.
   A digital signature uses two distinct keys to create it, a public key and a private key. The signature generation uses the private key and the transaction data as inputs, which the public key can validate. The signature is validated to prove that the author of the transaction has the private key, so the transaction is authentic.
   In a blockchain, to do a transaction between two users, the recipient and sender are identified by their respective public keys, so the chain nodes can validate the transaction signature using the sender's public key.
   Since the transaction signature depends on the transaction data, each transaction will have a distinct signature, regardless of whether the sender and recipient are the same as a previous transaction.
   The equation behind the signature generation operation may vary in distinct blockchain implementations. Bitcoin uses Elliptic Curve Digital Signature Algorithm (ECDSA) to generate signatures, for example, which is a very complex algorithm that this paper will not address because of its technical depth.
   
   If someone tries to change the data of a transaction and pass that change to the rest of the chain, it would eventually change the hash of your transaction, because the generation of signatures uses the previous transaction data as inputs. So the other nodes would invalidate that fraudulent transaction.

4. Wallet balance
   The nodes iterate through the list of subsequent transactions and calculate the sender's current balance to check if he has enough balance to make a new transaction.
   In addition to more than one input, a transaction can also have more than one output, which in this case are the recipients of the transaction. It can be useful to send values ​​to different recipients at the same time or use it as transaction change as the chain calculates your entire current balance and uses it in the new transaction. Hence, if the wallet balance of the sender is higher than the amount he wants to spend, the sender can put his public key as one of the outputs and the transaction change as the value.
   
   After an output is used as input in a new transaction, it cannot be used again as input, because the "money" has already been "spent".

Race condition

1. The problem
   Imagine the following situation: Rodrigo wants to buy Julia's product with bitcoins, but Rodrigo is well aware of the blockchain mechanisms. Bitcoin uses to validate transactions, and he knows that nodes cannot be sure of the order of transactions.
   Therefore, Rodrigo makes the transaction of 1 BTC to Julia as payment and expects some node to validate this operation. Once validated, Rodrigo informs Julia that the transaction has been authenticated, and then Julia dispatches his request. Upon receiving the news that Julia has dispatched the order, Rodrigo trades 1 BTC to himself. He hopes that most nodes in the chain validate the 1 BTC transaction to himself before validating the 1 BTC transaction to Julia because when these nodes receive the transaction to Julia, it will be invalidated since the corresponding input has been used before. So, Rodrigo can potentially receive his order and still have his 1 BTC. It is a potential breach in the system.
   

2. The Solution: Blocks
   The blocks are the solution to avoid a race condition. Each block has a list of validated transactions and points to the hash of the block generated before it. This concept of blocks interconnected like a chain of hashes inspired the name of the architecture.
   
   Transactions in the same block are considered as if it happened at the same time. Transactions that do not yet belong to any block are considered unconfirmed.
   Any network's node can collect unconfirmed transactions and generate a new block and sending the suggested block to the rest of the network. Still, this implementation would fall into the same transaction's race condition problem.
   To solve the race condition problem in the blocks another strategy is used. So it will be almost impossible for the generation of two blocks at the same time in the network. A valid block must contain the solution of a cryptographic hash equation, which is generated using all block data and a random value, the value generated by this function must be less than the target value generated by the network. In the case of Bitcoin, the hash function used is SHA256, developed by the United States National Security Agency (NSA).
   The average time for the solution of this hash function using all bitcoin's nodes, which is currently the largest blockchain implementation, is 10 minutes. The probability of the generation of two blocks at the same time is very low. Even so, if two blocks are generated at the same time, there is another strategy to deal with it, the branch strategy.
   If branches were created, the nodes continue the blockchain in the branch with the most number of blocks or - if the branches have the same number of blocks - the node continues the chain in the first branch received.
   

3. Branches' race condition
   The strategy of using branches prevents race conditions since the blockchain stabilizes after a certain period and that even if someone tries to precompute a branch and insert it into the chain, the cryptographic hashes function system itself still needs to be resolved. And the average time is about ten minutes using all the computing power of the world's largest blockchain. Thus, to a blockchain attack be successful, the attacker would have to get more than fifty percent of all the chain's processing power to have the same percentage chance of generating a larger branch than the rest of the entire chain, defrauding the system. Thus, the chance of a successful attack on a large blockchain is nearly impossible.
   Even so, the end of the blockchain may contain certain instabilities and several branches that have not yet been stabilized by the entire network. The point is that the network user may expect at least six blocks to be generated by the network before he can be sure that his transaction has been validated and committed to the chain.
   This estimate of six blocks comes from Meni Rosenfeld's 2012 study, which calculates that the chance of an attack being able to calculate six blocks in a row before the rest of the network is almost nil without having more than half of the computing power of the whole network.
   

Mining

If the blockchain implementation is opened so that any node can collaborate in the validation of transactions, there must be an incentive because there are electrical and spatial expenses in computational calculations. In the case of Bitcoin, there is the mining system in which nodes that validate transactions on the network receive a small amount of bitcoins as payment for the service.

The algorithm that generates these bitcoins decreases the amount of transaction-generated bitcoins validated every four years by half, so eventually, bitcoins will not be generated anymore. There is an estimative that the total number of bitcoins that will exist is approximately twenty-one million and that the last bitcoin will be generated around 2140. However, the network has another validated transaction payment system that is based on a percentage of the transaction made. So, even if bitcoins stop being generated, the validations will still receive a payment for the service.

In the case of private blockchains, there would be no need to implement a bitcoin-like mining system, as all computing power would be in a closed group and with a common purpose, for example, a company for credit card payment validation.

References

NAKAMOTO, Satoshi. Bitcoin: A Peer-to-Peer Electronic Cash System. Cryptography Mailing List, [S. l.], October 2008. Available at: https://bitcoin.org/bitcoin.pdf. Access on: May 13, 2019.

GLOBAL BITCOIN NODES DISTRIBUTION. [S. l.], 2019. Available at: https://bitnodes.earn.com/. Access on: May 27, 2019.

ROSENFELD, Meni. Analysis of hashrate-based double-spending. Bitcoil, [S. l.], p. 1–14, 11 Dec. 2012. Available at: https://www.bitcoil.co.il/Doublespend.pdf. Access on: May 30, 2019.

KALIQUE, Aqeel. Implementation of Elliptic Curve Digital Signature Algorithm. International Journal of Computer Applications, May 2010. Available at: https://www.ijcaonline.org/volume2/number2/pxc387876.pdf. Access on: May 13, 2019.