Discussion about time: wall clock and block times
Concern proposing at any time is a major DoS attack vector
Notion of time
A notion of time is a way to mitigate against some attacks (ex long-range attacks relying on social coordination)
Ways to create a sense of time
Simulated time based on number of blocks
Simulated time based on accumulated REV
Non-empty block (as described in paragraph 2)
Should we assume we are going to layer in a notion of time?
It is a desired property of the system is that we have a stable sense of block time
Mitigates some attack vectors
Benefits users who want to know when to anticipate the next block
Current protocol doesn’t guarantee or incentivize this
DECISION - yes, we agree we need a notion of time
Recommendation to implement a time slot approach to validation instead of a validator can propose at any time (Phil)
Concern this may take more implementation effort than we can afford at the moment (Kent)
Suggestion: Could we add a constraint that validators must allow another validator to propose to prevent a single validator filling up an epoch?
What is the maximum block size a validator can propose?
Paragraph 4: “draw map”
Paragraph 4: randomness
Plan is to use the past 256 block hashes
Agreement that block hashes are flawed.
Recommendation to use a commit reveal scheme
Unclear about the time required to implement
Decision to consider this for the future.
TICKET shift to commit reveal scheme to support randomness for validator incentives
“10% of the bonds map is swapped out”
Why would we take time to implement this at this point? When there are just Coop validators at first? (Chris)
Concern about the disincentive created when validators face the possibility of being randomly selected to not validate
What is reasonable for an EPOCH? (Chris)
What’s the unbond time? (Chris)
6 months (Kent)
Concern that time for EPOCH and unbond time creates an opportunity for long-range attacks. (Phil)
When you call unbond, you are no longer in the draw map nor can you propose