Would a consensus algorithm like the one I describe work?

Question

Given n nodes(miners/validators),

1. Every unspent transaction output is broadcasted to all n nodes.
2. Each node will select a batch of transactions and add it to their block. The specific mechanism of how they select transactions will be dependent on each node’s source code.
3. A node gets randomly selected to add a block to the blockchain with a chance of 1/n.
4. The node broadcasts its block to all other nodes before adding the block to the chain. If the block contains illegitimate transactions or tampered data, other nodes will reject the block. A block gets added only if majority of the nodes in the blockchain agree that the block is valid.
5. Before the block gets added, it is hashed along with the hash of the previous block.
6. In order to incentivize people to set up their own nodes, a small portion of the actual transaction gets rewarded to the node that added a block. This is different from Ethereum’s additional GAS fees. It is more analogous to taxes, where 100% of the burden is on the seller(recipient of the cryptocurrency).

This algorithm also guards against many common security issues:

1. Corrupting data of previously added nodes: Resolved, since even if a malicious actor tampers with data of previously added blocks, the protocol can always compare the hashes of the tampered chain with that of every other node(nodes constantly communicate), and update its chain to the ‘correct’ chain(once again accepting majority’s chain as correct data, assuming that the 51% rule is always observed).
2. Adding a faulty block in the first place: Resolved, since it is impossible to add a block without getting approval of majority of nodes. Even if a malicious actor adds the block to its own chain, other nodes wouldn’t add it to theirs, causing the malicious node to eventually update an obsolete chain.
3. Data retrieval is also based on proof of majority, so every time a transaction occurs, it checks with all n nodes to find a valid historical precedence of the transaction(e.g. A can only send 100 crypto to B if he or she owned it in the first place) and accepts the majority’s historical record(once again proving why it is meaningless for malicious nodes to update their own chain)

This algorithm doesn’t cost huge amounts of computing power and money to purchase equipment(unlike PoW) and doesn’t cost anything to set up nodes aside from basic equipment cost(unlike PoS).

It should work as a potential consensus algorithm, but I want critiques on potential flaws of the consensus algorithm. Furthermore, blockchain technology is becoming more and more mainstream, but it is rather difficult to research about different consensus algorithms without taking graduate level math. What's the easiest way for newly acquainted scholars of blockchain technology to study it and stay up to date with latest developments?

Answer 1

A node gets randomly selected to add a block to the blockchain with a chance of 1/n.

This step is the key problem. How is the node randomly selected? What source of randomness would you use? If a node is chosen to add a block to the blockchain but goes offline what happens then? Perhaps a replacement node is "randomly" chosen? But then half the network finds out that previous node did actually provide a block and half the network continues to add blocks on top of the block the replacement node provided. What then? With (perhaps rare) edge cases it needs an ultimate authority to clean up uncertainty and confusion. Bitcoin's proof of work is decentralized, incredibly robust to edge cases, does not need a network agreement on a source of randomness and does not need network agreement on time measurement (e.g. we'll wait 30 seconds for a node to provide a block). It can only do this because it only provides eventual finality and eventual network consistency. Although increasingly unlikely any length re-org (2 block, 3 block, 4 block etc) is theoretically possible.