# Protocol for Updating Data: Block Production We have distributed nodes that all hold copies of the same data. We then have transactions that are broadcasted within this distributed network. These transactions need to be used to build a block which is then appended together to form linked blocks usually referred to as chains. The problem is, we do not have a centralized entity to control this, hence we need to design a protocol for it. This act of updating the state by creating a block of transactions is usually called block authoring or block production, and our protocol needs to enable it.

Transaction flow in a blockchain network. (Source: https://www.mdpi.com/2305-6290/6/1/15)

Ideally the block authoring protocol should result in having only one node that is selected to be the block producer out of all the participating nodes. This is to prevent equivocation, where more than one block is produced, that is valid and there needs to be another procedure to break such a tie. Even though avoiding equivocation is desired, In normal running of the block authoring protocol it does happen that more than one valid block producer is selected. This is then resolved as part of the consensus protocol that would be later explained in the post. This means for when it comes to updating the state of the blockchain, we need a Block Authoring protocol, which will be discussed in this section. And in the case where there are conflicting but valid blocks being authored, then we need another protocol to resolve such conflicts. That will be discussed in the next section. So how can such a block authoring protocol be designed? There exist various protocols designed to solve this problem of block production. We quickly go over how this is done within Bitcoin, Ethereum, and Polkadot. We start with Bitcoin. ### Protocol for Selecting Block Author in Bitcoin The protocol for selecting who is the next block author in bitcoin takes the form of a cryptography competition. The competition involves being the first to publish a block with the unique characteristic that a cryptographic hash digest related to that block has a certain number of leading zeros. \ The hash function used is SHA-256 and since it is a cryptographic secured hash, it is impossible to predetermine the input that would produce a particular output: in this case, the output being that the hash has a certain number of leading zeros. The input on the other hand, are the transactions information to be included in the block, and a Nonce variable. Hence the only way to solve this is to continually change the Nonce value, which is the only variable a node can change to influence the outcome of the hashing operation. This is essentially a brute-force operation and requires a lot of power to perform. This is where the notion of **proof of work** comes into play in Bitcoin. In order to increase the chances of arriving at the hash digest with the required number of zeros, a whole lot of hashing operations need to be performed and this requires tremendous computing power.

Proof of work (source https://forkast.news/proof-of-work-what-is-it-bitcoin-halving/)

In this protocol, a node, commonly referred to as a miner, undertakes the task of finding the nonce. This nonce, when combined with the transaction data, yields a hash value with the necessary number of leading zeros. Upon achieving this, the node is deemed valid according to the protocol and is authorised to create the block. The protocol also has the property that ensures that other nodes can verify that the node which authored the block did come up with the required hash. This verification is cheap and can be done in constant time as it only involves hashing once the authored block and checking if the resulting hash is the same as what the block author said. This ensures that the process of finding the hash requires a tremendous amount of effort, but the process of verification does not. This is the birds eye view of the protocol that governs block production in Bitcoin. ### Protocol for Selecting Block Author in Ethereum When Ethereum used Proof of Work, its protocol for selecting block authors was similar to what exists in Bitcoin, but since the switch to Proof of Stake, Ethereum’s protocol for block authors has changed. In Proof of Work, you have nodes (or miners) that participate in block production by solving the required cryptographic challenge. In Proof of Stake, you do not have miners. We still have nodes that participate in block production but now they are called validators instead of miners, and instead of solving cryptographic challenges, they indicate their interest by depositing and locking a valuable amount of money into the protocol. This is called the stake. The nodes participating in the protocol then runs a random algorithm to select the next block producer amongst the nodes that have put down a stake in the system. The random algorithm used in ethereum is called RANDAO, which is a protocol to generate reasonably random numbers in a decentralized way. The random number generated is then used to map to the identity of validators and hence used to select the validator that would be the next block author. Going into the details of how RANDAO works is beyond the scope of this guide, but it is best to think of it as a scheme where various participants come together to generate a random number, instead of simply trusting one entity to do it on everyone's behalf. It works on the principle of having participants contribute some amount of randomness, which is then mixed to generate the final random number. The mixing is done in such a way that ensures each participant's contribution affects the outcome equally.

Depiction of the RANDAO (Source https://eth2book.info/capella/part2/building_blocks/randomness/#randomness)

The protocol then uses the final random number generated, to map to the assigned identity of a validator in order to select which validator should author the next block. This implies that all nodes responsible for block authoring engage in a random number generation process. Only the node for which the random number aligns with its identifier is authorized to produce the next block. Since all nodes operate on the same algorithm, the generated random number should be consistent across all nodes. Consequently, they can verify if a block originates from the authorized node. In this protocol, time is also divided into series of Slots and Epochs. Also participating nodes can engage in other protocol defined activities apart from producing and validating blocks. The RANDAO mechanism is crucial for all the synchronisation of who does what, and at what time.

RANDAO and protocol duties assignment (Source https://eth2book.info/capella/part2/building_blocks/randomness/#randomness)

Unlike proof-of-work-based algorithms, this protocol demands less computational power, but it also facilitates the selection and verification of the next block author. ### Protocol for Selecting Block Author in Polkadot Polkadot is another Proof of Stake blockchain, and to tackle the problem of selecting block authors, it uses a protocol named Blind Assignment for Blockchain Extension (BABE). BABE’s construction is based on a Verifiable Random Function (VRF), a unique random number generator (RNG), that makes it possible to generate randomness, together with a proof that can be used by others to verify that the number generated was indeed generated in a random fashion. The VRF is used in the block authoring protocol as follows: At the point where a new block is to be created, all eligible validators participating in the network run a VRF algorithm to generate a random number. If the random number generated falls below a threshold set by the protocol, then the validator with such a number can proceed to author the next block. The validator then authors the block, broadcasts it, together with the random number that qualified it to be the block author. The proof that it generated the number in a random fashion is also attached. Other participants in the network can then check the validity of the authorship using the proof. Going into more of the details of how VRFs works is beyond the scope of this guide, but it can be thought of as a cryptographic die rolling procedure that also produces a proof. The fact that it also produces a proof means others can verify the number was generated using a random mechanism. This makes it usable in a decentralized environment like blockchain systems because in the absence of a centralized entity responsible for randomness, participants can produce random numbers and others can use the accompanying proof to ascertain that they did not cheat, and the numbers are indeed truly random. Since the number generated by the VRF is random, It is quite possible that no validator comes up with a number that satisfies the threshold to be a block author. In such a scenario, BABE runs a fallback protocol, which is a round-robin-like algorithm for selecting the block producer. This means, in situations where the VRF-based protocol does not result in a block producer, the fallback round-robin protocol will be used to select the block producer. The VRF-based selection is the primary while the round-robin-based protocol is the secondary. It is also possible that more than one validator satisfies the threshold, in such a situation, an equivocation is created but this is later resolved by another protocol for resolving such that will be explained in the next section of this guide. {% hint style="info" %} **Additional Resources** * Bitcoin White Paper \ * Mining: The process of adding blocks to the blockchain\ * Proof Of Work\ * The Beacon Chain Ethereum 2.0 explainer you need to read first\ * RANDAO: A DAO working as RNG of Ethereum\ * Upgrading Ethereum | Randomness\ * Verifiable Random Function\ * Polkadot Consensus Part 3: BABE\ * Randomness | Polkadot Wiki\ * Eth2 Phase 0 Technical Deep\ * But how does bitcoin actually work?\ * MIT 15.S12 Blockchain and Money, Fall 2018\ {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://geekabyte.gitbook.io/blockchain-protocol-development-guide/protocol-for-updating-data-block-production.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.