0
$\begingroup$

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?

New contributor
rasputin is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
$\endgroup$

1 Answer 1

3
$\begingroup$

Your protocol description is very informal so it's difficult to say whether it would work or not. Here are a few comments:

Every unspent transaction output is broadcasted to all n nodes.

On the internet there is no broadcast channel, so you need to specify what broadcast means. Do you need reliably broadcast (e.g., Bracha's protocol) or do you mean just sending a message on all the point-to-point channel. Also, which node is broadcasting? If your UTXO is like the UTXO in Bitcoin then it's usually not broadcasted. It's computed from new transactions against an old UTXO set.

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.

What do you mean by "add it to their block"? Is this new block finalized? Is there a chance it might be reverted later? For example a failure occurs.

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

How is this selection made and how do you prevent the adversary from biasing the selection?

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.

Again, what kind of broadcast do you need? Also, how do the majority of the nodes reach agreement? Do they run a consensus protocol or broadcast signatures or something else?

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?

A few final comments: if you have a fixed set of nodes $n$ then there's little reason to design a new consensus protocol. The classical consensus protocols such as PBFT work well without mining or PoS. Also, keeping the protocols formal is important so that the readers know exactly what is happening and can prove (or disprove) properties about them. For example, it is very difficult to say whether a protocol is going to work without defining what it means to work (e.g., do you need properties like liveness, agreement, consistency, and/or something else?) and what are the adversaries (are they adaptive? what's the proportion?). Some texts I can recommend are:

$\endgroup$

Your Answer

rasputin is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.