Minimal Slashing Conditions
Vitalik Buterin

Great post and I love the ideas behind this technology.

In the condition PREPARE COMMIT CONSISTENCY is it the case that if you always prepare the newest blocks, you can’t go back and commit blocks when you see 2/3 later? Does a client have to delay on sending prepares on future blocks until it commits older blocks? Is it expected that a conforming client would wait until the last minute to send prepares so it can get it’s commits in. If this is the case, doesn’t it become more likely that the source epoch of the prepares will get smeared out across many blocks and reduce the chance of getting a quorum?

Would it make sense to relax PREPARE REQ to allow for more prepares with advancing epoch_source? One example would be that you send [“PREPARE”, 10, HASH1, 4], and you don’t see 2/3 pointing to 4, but you later send [“PREPARE”, 10, HASH1, 8] because you’ve seen that 8 has been agreed upon and they are on the same chain. Now you have 2/3 of prepares on epoch 10 pointing to source epoch 8 because clients have re-prepared to encourage a quorum.

I was thinking maybe the PREPARE COMMIT CONSISTENCY could be, before sending a COMMIT at epoch1, you must advance your prepare from epoch2 to point at epoch1. This means if you have prepared the wrong branch you are not allowed to commit. This implies you can’t make your commit money if you picked the wrong branch. But it seems more likely to finalize and still allow clients to run prepares many block ahead of commits.

Show your support

Clapping shows how much you appreciated John Carrino’s story.