Date
Participants
List meeting participants using their @mention names:
Goals
List goals for this meeting (e.g., Set design priorities for FY19):
Discussion topics
Item | Notes |
---|
Resources | |
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 Polkadot approach 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?
|
Action items
Add action items to close the loop on open questions or discussion topics:
Decisions
Type /decision to record the decisions you make in this meeting:
53a906d8-dd47-4e48-b60a-45c542893454DECIDED7de5722e-ba5b-451f-a808-f1fe8f1eae66