Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.





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?

    • TODO we need to pick this (see action item below)

Paragraph 3

  • Can we change “public key” to “REVAddress”?

    • DECISION in the interest of time we will use “public key”

    • REVAddress is the hash of the Ethereum address that is a hash of the public key

    • TICKET shift to REVAddress instead of public key in the future

Paragraph 4: “draw map”

  • Discussion about grace period related to the draw map

    • If you’re in the draw map you should have your hardware ready

    • This approach favors validators operating in the cloud who can be more flexible than those needing to provision hardware

    • DECISION leave as is

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)

    • Maybe not (Kent) given the plan for the main net launch.

  • From #blockchain

  • Concern about the disincentive created when validators face the possibility of being randomly selected to not validate

    • You are rewarded for being in the draw map and being a validator (Kent)

    • Suggestion validators will attempt to optimize to be in and out of the draw map to reduce time before being a validator (Phil)

  • What is reasonable for an EPOCH? (Chris)

    • 1 hour (Kent)

    • So every hour we’re swapping in 10% of validators in the draw map

      • Risk if the draw map is large, the likelihood of getting into the validator pool will be too low and no one will want to validate

  • 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

Next steps

  • Discussion about desired outcomes

    • We do need to capture the things we plan to address in the future

      • To show plan to address

      • To prevent rehashing in the future

    • We also need to specify what we will implement in 4 weeks

      • To meet Mercury mainnet goals

Action items

  •  Former user (Deleted) propose a value for a maximum block size
  •  Kelly Foster TICKET shift to REVAddress instead of public key in the future
  •  Kelly Foster TICKET shift to commit reveal scheme to support randomness for validator incentives for the future