Initial very rough draft for early pre-ELVES soft concensus #144
Conversation
I'm really not confinced by how we'dchoose this delay yet.
|
|
||
| We expect this early soft concensus creates back pressure that improves performance under babe forks. | ||
|
|
||
| Alistair: TODO? |
There was a problem hiding this comment.
This proposal also halts the chain when less than 2/3 of validators are online. ELVES is not secure when this happens. Governance, even doomsday governance, is planned to be secured by ELVES so cannot help.
There was a problem hiding this comment.
Added remarks on this in 425bfee but further down. We could make that remark here, not sure.
| ### Mid-strenght concensus | ||
|
|
||
| In this RFC, we only require that each relay chain block contain preference votes for its parent from 2/3rds of validators. We could enforce the opposite direction too: Around y>2 seconds after a validator V has seen preference votes for a chain head X from 2/3rd of validators, the V begins rejecting any relay chain block that does not build upon X. This is tricky because the y>2 second delay must be long enough so that most honest nodes learn both X and its preference votes. This strengthens MEV defenses that assume some honest nodes. | ||
|
|
There was a problem hiding this comment.
Indeed we can use this vote in an economic finality mechanism that gives new trade-offs of latency for security. In 8-10 seconds after a block is produced, we would normally know that only disputes, which always result in large slashes could reverse it. There should be an easy migration path from this RFC to such a protocol, by putting more conditions on this vote and block production.
3 participants
Rendered
Addresses relay chain equivocations in ELVES, makes nicer assignment strategies possible, and hopefuly reduces validator workloads.