# Wireless May Benefit Blockchain +
## 3 Consensus Among Wireless Nodes
### PoS  
Let us shed light on the key characteristics of PoS on which wireless connections may have impacts. Here, we take the Ethereum 2.0 [18] as an example. Selectivity in consensus participation is the first characteristic that is affected by wireless communications. The reason is that such a smaller number of consensus participants can make the blockchain more vulnerable to faults attributed to uncertainties of wireless connections in addition to already existing Byzantine faults. (This usually is not the case in a PoW-based blockchain.) Let us continue to characterize the Ethereum 2.0's PoS algorithm in further detail as an effort to investigate the applicability of wireless connections. In Ethereum's PoS system, validators commit their capital in the form of Ethereum token (ETH) to a smart contract on the network. These validators are then tasked with validating new blocks and, on occasion, creating and disseminating new blocks themselves [18]. To participate as a validator, an individual must deposit 32 ETHs into the contract and operate three distinct software components, viz., an execution client, a consensus client, and a validator client [46]. Every slot randomly selects one validator as the block proposer, responsible for creating a new block and transmitting it to other nodes in the network. Concurrently, in each slot, a committee of validators is randomly chosen, and their votes are instrumental in determining the validity of the proposed block. The partitioning of the validator set into committees is crucial for effectively managing network load. Second, due to this unique structure, PoS has a higher level of reliance on the network layer. As a means to elaborate, let us take an in-depth look at the procedure of executing a transaction in Ethereum PoS:A user initiates a transaction by generating and signing it using their private key. The user specifies the gas amount they are willing to pay as a tip to incentivize a validator for including the transaction in a block. 2. The transaction is then submitted to an Ethereum execution client, where its validity is verified. This verification includes checking if the sender has sufficient ETH for the transaction and if it has been correctly signed with the corresponding key. 3. Upon confirming the transaction's validity, the execution client adds it to its local mempool (a list of pending transactions) and broadcasts it to other nodes through the execution layer gossip network. Other nodes, upon receiving the transaction, also add it to their mempool. 4. A node is randomly selected as the block proposer for the current slot via the pseudo-random RANDAO process. This proposer is responsible for constructing and broadcasting the next block to be appended to the chain, along with updating the global state. 5. Other nodes receive the new beacon block through the consensus layer gossip network. They forward it to their _execution client_, where transactions are re-executed locally to verify the proposed state change's validity. The validator client then attests to the block's validity, confirming that it logically follows the chain with the highest weight of attestations as defined in the fork choice rules. The block is added to the local database in each attesting node. 6. The transaction achieves a state of being \"finalized\" when it becomes part of a chain with a supermajority link between two checkpoints, indicating agreement from 66% of the total staked ETH on the network regarding two specific checkpoints. As shown from the above protocol, Ethereum's PoS uses two P2P networks: one for transaction communication among execution clients and another for block information exchange among consensus clients [46]. Transactions are transmitted through the execution layer's P2P network via encrypted communication between authenticated peers. When a validator proposes a block, the transactions are sent to consensus clients, encapsulated into beacon blocks, and disseminated across the P2P network.