Hello Paul,
I appreciate your kind words and your taking time to review this work. Please see rest of my comments inline.
* In your description of the ideal blockchain (from the article) you've omitted a very important attribute, 'permissionlessness' (excuse the non-word), which describes the ability of a party interested in participating in the block creation process to do so. Because your protocol is PoS, any interested party requires stake in order to participate in block production, making it permissioned.
'Permissionless'
is an extremely important attribute, especially for the growth aspects of a blockchain and Proof-of-Approval is in fact permissionless. Proof-of-Approval does not require any stake to create blocks, but it does require approvals from parties holding a quorum (>50%) stake. If a party has 0 stake, it's block needs approval from others totaling a quorum stake (>50%). On the other hand, if a party has 10% stake, it's block needs approval from others totaling a quorum stake minus its own stake (>40%). PoS applies for approvals and not for block creation or winning rewards.
* The consensus mechanism is based around timestamps, but there is no objective way to verify a historical timestamp. Doesn't this present a number of problems, e.g bootstrap poisoning?
Consensus mechanism is based on signed approval messages that are stored in the blockchain to deter long-range attacks. Also note that the approving stake is at the current timeslot, not something in the past. Let's consider a couple of scenarios here.
1. An adversary attempts to create a block n blocks in the past. In order to successfully fork from n block in the past, the adversary needs signed approval, in that timestamp, from >50% stakeholders for every block since the n-blocks in past (blocks -n, -n+1, -n+2...).
2. Past >50% stakeholders (n blocks ago) sell off all their stake and turn adversarial (but current >50% stakeholders are still honest). Again, in order to successfully fork from n blocks ago, they need signed approvals for every block in the past (blocks -n, -n+1, -n+2...). While they may be able to approve some blocks when they did hold > 50% stake, as their stake goes down, they need other parties to approve their more recent blocks. In order to get the newest block approved, they would need adversarial stake > 50% in the present.
* You are rewarding newly minted blocks with stake, yet to produce blocks, you require stake. How is this resolved?
As stated above, a party with no stake requires approvals with other parties that can form a quorum. While it is harder to achieve than another party holding a large amount of stake but is definitely achievable.
* Doesn't the Pareto distribution of stake over time present centralisation concerns?
Yes, Pareto distribution does present centralization concerns just like mining pools for bitcoins. There does not seem to be a known solution for it yet.
* How does your protocol deal with the keys-from-the-very-recent-past attack, whereby an attacker purchases newly emptied private keys of very large stake value, then creates a fork where he steals all the stake back for himself?
I believe it is the same as the scenario 2 described above.
Thanks again.
Shunsai
Show Posts
