G.1 Countering DDoS Attacks and Minimizing the load of the PoS-chain

Our hybrid protocol ΠBCPoR/PoS allows malicious PoS-slot leaders to post fake complains. These complaint will be debunked by the honest parties, but doing so requires costly verification of multiple signatures. In order to avoid such overloading attacks which can lead to DDoS against the backup blockchain and incentivize parties to use it for checking, we will apply the following mechanism inspired by [66]:

1.

The reputation parties will be posting their hash-pointers on the backup PoS-blockchain as part of a collateral-transaction, which commits funds that will be refunded if there is no dispute in the next few rounds (the exact number of rounds and size of collateral will be specified in the implementation) or there is a dispute which leads to detection of fault in the PoR-blockchain.

2.

Similarly, any accuser will have to post, along with his accusation, an analogous collateral-transaction which will be refunded if the dispute leads to detection of fault in the PoR-blockchain.

3.

If any dispute is resolved in favor of one of the parties, then this party can claim the collateral of the other and get his own collateral refunded.

The above mechanism will ensure that: (1) reputation parties post the actual hash pointers that they see on the PoR-blockchain—as invalid hashes will lead to disputes resolved in favor of the accuser and, therefore, loss of funds for the accused; and (2) accusers do not post invalid/redundant accusations—as they will, otherwise, lose their collateral.

G.2 Relaxing Synchrony

Removing the arguably strong simplifying assumptions of perfect synchrony with zero-delay channels is another interesting direction. We conjecture one can adapt techniques from the blockchain literature, e.g., [37, 38] for removing the deterministic zero-delay assumption and clock synchronizarion techniques synchronization [42, 67, 52, 45, 44, 15, 82, 69, 76] to relax the perfect synchrony assumption.

DDoS Effect and Mitigation Our blockchain leverages the reputation system to ensure that it selects an honest-majority committee in every slot. However, as discussed here, the identities of slot leaders become public prior to the round in which they participate in the committee. One might argue that this opens the system to DDoS attacks, as even honest parties might be targeted. We point out however that that any such attack will result in an empty slot and not a fork, as the adversary, even when DDoS-ing a party cannot create a majority of signatures from the current slot’s committee. In fact, one can mitigate this issue by either using—e.g., reputation-penalties for successful DDoS attacks—which will inceltivize high reputation parties to safeguard their availability, or using verifiable random functions (VRF) as in [39, 16, 49] but this will require not only circulating more information (VRF proofs) but also flooding it to the entire network. Alternative one can spread out VRF slots will help recover from stalling due to very effective DDoS attacks, but still most slots will be using the reputation-based incentives, thereby ensuring the good communication efficiency of our blockchain protocol. The exact dynamics of this mechanism are left as a future research direction.