Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ETCM-193] Make target time between blocks configurable #773

Merged
merged 2 commits into from
Nov 6, 2020

Conversation

pslaski
Copy link
Contributor

@pslaski pslaski commented Nov 4, 2020

Description

Due to OBFT constraints, our internal testnet will have a higher target time between blocks than ETC, so we should make the block rate configurable for changing it on the different environments.

Proposed Solution

Introduced new Difficulty calculator which will try to compute difficulty to target configured PoW time

Important Changes Introduced

  • new blockchain configuration key - pow-target-time (default is null which means that normal ethash calculator will be used)

@pslaski pslaski requested review from rtkaczyk and ntallar November 4, 2020 14:27
* [0.5 min, 1.5 min) => difficulty stays the same (the average should be powTargetTime)
* [1.5 min, +infinity) => difficulty decreases
*/
val LowerBoundExpectedRatio: Long = powTargetTime / 2
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thinking about it now, I did too simple assumption here. WDYT guts, should we configure also the deviation of target time or we should assume that deviation is X % of target time?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I'm not sure if this deviation will bother us too much, neither if it's easy to change this formulas without screwing up... I wouldn't mind leaving it as is for now

src/main/resources/chains/etc-chain.conf Show resolved Hide resolved
* [0.5 min, 1.5 min) => difficulty stays the same (the average should be powTargetTime)
* [1.5 min, +infinity) => difficulty decreases
*/
val LowerBoundExpectedRatio: Long = powTargetTime / 2
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I'm not sure if this deviation will bother us too much, neither if it's easy to change this formulas without screwing up... I wouldn't mind leaving it as is for now

@pslaski pslaski force-pushed the etcm-193-target-time-between-blocks-configurable branch from b8f3eff to ce7df7f Compare November 5, 2020 14:32
* [0.5 min, 1 min) => difficulty stays the same (the average should be powTargetTime)
* [1 min, +infinity) => difficulty decreases
*/
private val LowerBoundExpectedRatio: Long = (powTargetTime / 1.5).toLong
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nazi comment: capitalised names are for constants and this is not a constant if it depends on the class parameter

import io.iohk.ethereum.consensus.difficulty.DifficultyCalculator
import io.iohk.ethereum.domain.BlockHeader

class ConfiguredDifficultyCalculator(powTargetTime: Long) extends DifficultyCalculator {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not fond of the name, EthashDiffCalc is also configured. Maybe TargetTimeDiffCalc or simply QaDiffCalc?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I don't like QaDiffCalc as this will be used on our testnet and I'm not sure for how long, not just testing purposes)

val x: BigInt = parentHeader.difficulty / DifficultyBoundDivision
val c: BigInt = math.max(1 - (timestampDiff / LowerBoundExpectedRatio), FrontierTimestampDiffLimit)

MinimumDifficulty.max(parentHeader.difficulty + x * c)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How did we arrive at this formula? I would have expected it to be parameterised by something like:

  • mu - the expected block time
  • sigma - std deviation, where we don't change the diff
  • delta - rate of change outside of std deviation range

Perhaps something like: https://en.wikipedia.org/wiki/Beta_distribution could be used. The formula we have is eerily similar ETH formula, but I think we are allowed more freedom with this, no?

Disclaimer: these are very rough proposals and are not to be taken word-for-word. But I think something along those lines would give us more control. It's not a blocker if such control is not required.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was inspired by what I had done on this regard on the other project so I'll share my thoughts. As you said this formula is the ETH formula with simplifications, I didn't want to deviate too much from it just in case I'd break something (for example, if we are more aggressive with when to increase/decrease difficulty it might lead to an divergent time between blocks).

Either way, the only reason I see for maintaining the current formula is so that this doesn't become a blocker for deploying checkpointing on our testnet, if that isn't at risk we could go for another better one

(of course, if this formula doesn't work as expected we should definitely change it!)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would go now with the current formula for three reasons: 1. we need this fast for testnet deployment 2. It is the same formula used in other project and its upgraded version is in mantis now. 3. Developing new formula only for testnet without having in mind using it in mainnet is not worth a time now imho.

Maybe we can think about it in the future? (new task)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would try it out on the testnet and only create a follow-up task if we detect there that's not enough (or that it would be good to have something better)

@pslaski pslaski force-pushed the etcm-193-target-time-between-blocks-configurable branch 4 times, most recently from f61f4f5 to 756c797 Compare November 6, 2020 12:37
@ntallar ntallar requested a review from lemastero November 6, 2020 12:57
Copy link

@ntallar ntallar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

 .\\            //.
. \ \          / /.
.\  ,\     /` /,.-
 -.   \  /'/ /  .
 ` -   `-'  \  -
   '.       /.\`
      -    .-
      :`//.'
      .`.'
      .' BP 

@pslaski pslaski force-pushed the etcm-193-target-time-between-blocks-configurable branch from 756c797 to b20ae80 Compare November 6, 2020 13:21
@ntallar ntallar merged commit 614aad9 into develop Nov 6, 2020
@ntallar ntallar deleted the etcm-193-target-time-between-blocks-configurable branch November 6, 2020 19:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants