2

I wrote a new consensus algorithm. Is there a self-evaluation checklist I can run to see if it meets the basic requirements? Like is it resistant to double-spent attacks? Or how does it scales?

Ilya Gazman
  • 31,250
  • 24
  • 137
  • 216

2 Answers2

2

I reviewed this entire algorithm. Though the idea is great, it feels a bit incomplete. The self-evaluation checklist below is based on the requirements and safety measures taken by well established blockchains i.e. ETH, BTC, etc.

System Criteria:

  • What is the required storage capacity of system? -- RAM usage, bandwidth
  • What happens when the entire network goes offline?

Algorithm evaluation:

  • Is this algorithm scalable? scalable as in operable when the users multiply exponentially.
  • How long does it take the miners to reach a 2/3 consensus?
  • Are there safety measures for the user' funds?
  • How can a user transfer funds safely? (Cryptographic hash algorithms that can be deciphered only by the authorised entities to ensure safety)

Architecture evaluation:

  • Is it decentralized, transparent and immutable?

User evaluation:

  • Is there enough incentive for a miner/validator to validate the transactions?
  • Is there enough incentive for a "new" miner/validator to join the network?
  • Is it possible for a single entity to dominate the network?
  • What safety measure is there in order to prevent blind/unreliable transfer of data?

Resistance to attacks evaluation:

  • Is the algorithm resistant to double spend attacks, eclipse attacks, sybil attacks(identity thefts), 67% attack?
  • Is there a way for the honest users to defend against such attacks? If not then how likely is it that an attacker is successful after attacking the blockchain?
  • As an attacker what is the weakness of this algorithm? Once something is confirmed by 2/3 then it is unchangeable, so how can you get that 2/3 vote ?

These are some conditions that came to my mind while reading the algorithm description which were unanswered. A consensus algorithm takes into account the maximum throughput and latency of the current systems in order to provide a holistic idea of how to evade attacks and secure the users. If the consensus algorithm fails to do either of those then it would not fly in the market because the network would become untrustworthy because of a lacking algorithm. To ensure it is not, such questions should be asked in addition to the blockchain/algorithm specific questions that would rise in a user's mind when trying to join a network. At the end of the day, everyone likes to keep their money safe and secure and hidden away from the general public to avoid any and all kinds of attack.

Darsh Gondalia
  • 106
  • 5
  • Thank you, I appreciate the general feedback. It is a good answer for any consensus algorithm. But I am looking for feedback on my implementation. – Ilya Gazman Jan 16 '23 at 14:55
  • I did try to keep that in mind and give you a general checklist. If your implementation satisfies all of the above conditions and has a positive answer for the subjective questions then I would say your consensus algorithm is pretty strong. I do think that this consensus algorithm is incomplete as in it has some shortcomings that fail the concept, even though it is a good one. I suggest you go through the questions and evaluate the algorithm based on that and make additions or subtractions to make it better and complete. – Darsh Gondalia Jan 17 '23 at 06:57
1

I'll admit I didn't read it too carefully - but I was looking on how the document hands CAP theorem.

There is a statement in your doc: "since they (validators) are looking at the full blockchain picture". This statement is never true in a distributed system.

Second statement "Once 2/3 of the validators approve an item" - who does this decision that 2/3 reached? When does the customer knows that the transaction is good? It seems the system is not too stable and will come to halt quite often.

Looking forward for other comments from the community :)

AndrewR
  • 1,252
  • 8
  • 7
  • My consensus kind of breaks CAP. CAP assumes that the system itself is a constant thing. A fixed number of nodes, but Flash says: errors are not allowed. If you make an error, you are removed. I explain it in the Connectivity section of Red, Yellow, and Green. And more in the networking attack. – Ilya Gazman Jan 13 '23 at 20:35
  • By full blockchain picture, I meant the local Blockchain that each Validator is managing. There is a consensus on the local version of each Validator up to the latest block. The latest block is not final until all the Validators approve it. At this point, the Blockchain grows by one block, and it repeats. – Ilya Gazman Jan 13 '23 at 20:39
  • There are two types of nodes. Wallets(consumers) and Validators. Both have a local version of the blockchain. When a transaction is approved by 2/3 of the Validators, it is considered final and committed. What makes you think the system will ever halt? – Ilya Gazman Jan 13 '23 at 20:42
  • 1. CAP theorem (unfortunately) is always applicable, it actually assumes that system is a dynamic things as any node may depart at any time. 2. I did not understood how 2/3 of validators get calculated - how do I know who are the validators to be able to pick 2/3 of them? It is pretty much guaranteed that the set will be different for everyone. If the set is the same, then the system will come to halt any time it is partitioned. – AndrewR Jan 16 '23 at 19:56
  • all the nodes from level N of blockchain DAG references all the nodes in level N-1. You can't build level N+1 before you got all the nodes of N. Each node in this example is a block. The block that a validator produces for N+1 votes on all the blocks from N. When the Validator starts to work on Block N+2, it has all the votes on its N+1 block, and hance can count 2/3 votes – Ilya Gazman Jan 16 '23 at 21:04