Proposed algorithm to ensure condition (ii) of the Persistence property

[saltiniroberto]

GPAv1 feedback GPAv1 states that “Also, it appears that the proposed algorithm [ref. algorithm proposed to guarantee condition (ii) of the persistence problem] will enforce block synchronization regardless of whether there is a valid block available or not, what if during this time of requesting new blocks one of the validators have turned Byzantine and have a ‘bad’ block in their local ledger. It seems that there are no thorough validity or security checks performed here and blocks are synchronized forcefully. It is recommended that a thorough study is conducted to ascertain the message, time and space complexity of all these proposed algorithms.”

Reply Each block is accompanied by a finalisation proof that proves that the block is correct. So, even if a node turns Byzantine, it cannot fool other validators in accepting an invalid block. The only overhead introduced by this modification is the transmission of GetBlockHeaders and GetBlockBodies messages that are quite small (https://github.com/ethereum/wiki/wiki/Ethereum-Wire-Protocol) However, this overhead is required only if the network is not working properly, i.e. some level of network partitioning is occurring, in which case not having this overhead may cause the network to reach a point where blocks cannot be propagated, which is worse than having some message overhead. However, I do agree that this protocol must be specified in more details than in the “Gray Paper”. The “Gray Paper” is intended to be a high level presentation of the protocol to assess the overall protocol correctness. An implementation specification which maps this high level concepts into finely defined implementation details must follow as indicated in the abstract of the “Gray Paper” .

[kubasiemion]

To be closed

[kubasiemion]

Closed as agreed on Aug 14th