Re: Proof-of-Approval: A Better Blockchain Consensus Protocol
Hello Fresheneesz,
1. Improve security by achieving near 50% adversarial stake tolerance. Near 50% tolerance would offer deterrence even more than the corresponding mining power. Only Cardano achieves that (not counting TON because I have no knowledge of their protocol).
2. Improve finality. The fact that Ethereum is trying to get Casper FFG shows how important finality is (although Casper FFG only improves tolerance to long-range attacks). Cardano's finality degrades continuously with rising adversarial stake.
3. Reduce cost. AFAIK, Bitcoin's breakeven (cost of mining vs its price) is around $8050. That's a lot of expense for the node owners.
Thanks,
Shunsai
Am I right that the goals of this protocol are primarily to reduce the finality time in comparison to Bitcoin as well as reduce the cost of running the system?
Yes, the goals are to 1. Improve security by achieving near 50% adversarial stake tolerance. Near 50% tolerance would offer deterrence even more than the corresponding mining power. Only Cardano achieves that (not counting TON because I have no knowledge of their protocol).
2. Improve finality. The fact that Ethereum is trying to get Casper FFG shows how important finality is (although Casper FFG only improves tolerance to long-range attacks). Cardano's finality degrades continuously with rising adversarial stake.
3. Reduce cost. AFAIK, Bitcoin's breakeven (cost of mining vs its price) is around $8050. That's a lot of expense for the node owners.
The image of how blocks are set up (https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.
Thanks for pointing it out - I had not seen that before. I will definitely offer comparison even if they are simply superior 
Your comparison table claims Proof-of-Approval is fully finalized after a single block, however, you also talk about how there may be multiple top-level blocks where the "preferred" chain is unresolved. Doesn't this imply that your transaction being inside a valid block doesn't mean its been fully finalized? How do you reconcile that?
In order to be fully robust, the fork selection has to work on all conditions that may be produce in normal operation. It is not a detriment that the fork selection actually works even beyond those conditions. It's just a good design practice to design for more than needed (within cost constraints of course).Since any node can produce a candidate block, this seems like it would potentially cause unbounded network traffic with everyone and their mother suggesting blocks to vote on. How is this resolved in the case of, say, an adversarial ddos attack?
Traffic can be a problem but only the headers (which are few hundred bytes) are being transmitted. Still, a node would need to validate the blocks of headers it receives (after downloading full blocks). Having a smaller time-slot (as opposed to larger) will reduce the number of headers received by a node (assuming the software's low level code simply drops headers received in mismatched time-slots). An adversarial ddos attack may look like network fragmentation and may prevent blocks from being added to chain temporarily. But I have the same question as monsterer2, why would anyone with stake approve the block of anyone without stake? In fact, why would anyone with stake approve *anyone* else's blocks? It seems there's no incentive to mine on top of someone else's blocks. This could manifest in more subtle attacks where you have stakeholders who refuse to mint on top of a competitor. It could also manifest in deadlock as nodes try to maximize their probability of winning the minted block.
Yes, and there may be a need to reward block approvals. I will work on adding block approval rewards. They can be added to approval-block since the content-block has already been created.I have a hard time seeing the purpose of having nodes pay attention to timestamps and comparing them to their receive-time. At its core, the mechanism is just voting, right? I don't see why the protocol doesn't just let nodes vote for whatever blocks they want. I see the appeal of a simple stake-voting process for block creation (similar to DPoS), but the Proof of Approval method seems like rational profit-seeking minters would make things devolve into the top 50% stakeholders passing around permission to mine the blocks, completely excluding the other 50%.
Nodes are allowed to rank in any order they choose. The time is just the default order built into the software.Also, could you provide a glossary of variables you use in this paper? Its hard for me to keep track of which variables mean what and find their definition in the prose when I need to refer to what they mean later.
Good point, I will add glossary.Thanks,
Shunsai