Software In Block Chain


So far, we have implicitly assumed that all computers on the network use the same software for each role they play. There is software recognized as standard by the community, but the operators have the complete freedom to use others, whether for local needs, or on an experimental basis, for a fraudulent purpose or simply by mistake or negligence . What happens then?

As long as the software installed on all the nodes implements the same script and block validation protocols and the same consensus mechanism, and regardless of their differences, the two essential steps in building the blockchain run in the same way on all nodes and produce identical copies of the chain. This allows countless experiments and variations in terms of usability, performance or additional features, without affecting the central functions of the system. The only truly critical functions are:

the validation protocol of the scripts, used in the diffusion of the writings, in the construction of the blocks and in the construction of the chain of blocks,

the block validation protocol (which itself uses the script validation protocol) and the consensus rules, which are implemented by the blockchain construction program.

If different nodes use different write validation protocols, each node retains and repost only those writes it recognizes as valid. If a node serves one or more minors, they only include in the blocks that it builds the scriptures that this node has validated. These blocks are broadcast to all nodes, but each node is accepted only by nodes that apply the same rules as the minor that built it. The network is then divided into several populations that build and use different block strings. The same is true if the validation protocol is the same, but if the blocks have different formats, or if the consensus rule is different.

Since each node holds in waiting in a kind of secondary branch blocks that it has not incorporated in its block chain, this situation is called  fork . But it is more accurate to describe the phenomenon as a split of the population of nodes, which now use different blockchains.

If the protocols are sufficiently different so that the scripts and the blocks accepted by each of them are rejected by the other, the blocks produced by the miners of each population are recognized as valid only by the nodes of this single population. The split is then total (”  hard fork “) between separate networks that record separately scripts of different natures, the system taking care of sorting.


In the case of Bitcoin (and other payment systems), remember that owning bitcoins is actually able to access transactions that credit my account. Since each can only access transactions in the blockchain of the population of which it is a part, and can only record new transactions on that blockchain, no transaction between members of different populations is then possible through the chain of blocks. In practice, there are two different currencies between which exchange is possible only by means outside the Bitcoin system. In other words, a currency is defined by a transaction validation protocol and a block validation protocol.

Another particularly important case is the introduction of new possibilities by software evolution. In this case, the writes recognized as valid by the existing protocol are usually validated by the new protocol, but the latter also validates writes that were not accepted by the old protocol. In population B that uses the new protocol, the string contains all the writes. In population A, which has retained the old protocol, the blockchain will contain only the old standard script, and the “mixed” blocks produced by the B miners will be kept pending without verification.

From the moment a node of A installs the new version of the software, it will accept the first valid block from a minor of B, and it is very likely that the string that leads to this block will have required more work than the current branch. It is therefore this branch that must become the local main branch, provided that the blocks that compose it and that had been put on hold are validated one by one from the bifurcation. If this validation succeeds, this node thus joins the population B. Such a temporary bifurcation, which is corrected automatically at the time of the software change, is called ”  soft fork “.

This reorganization may call into question certain entries in the old channel if they are no longer in the news. It is for this reason that it is wise to consider a writing as definitive only after a certain number of blocks have been recorded after it in the chain (typically a few dozen).