-
Notifications
You must be signed in to change notification settings - Fork 75
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-109] ECIP-1099 implementation #764
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good to me!
val epoch = EthashUtils.epoch(parentBlock.header.number.toLong + 1) | ||
|
||
val blockNumber = parentBlock.header.number.toLong + 1 | ||
val epoch = EthashUtils.epoch(blockNumber, blockCreator.blockchainConfig.ecip1099BlockNumber.toLong) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not accepting BigInt
there? I mean - if domain uses BigInt
for block numbers, why shouldn't miner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we are using only Long
s in EthashUtils
. I am not sure if we do that because of performance or sth else, but I don't want to change that in this pr.
|
||
# Epoch calibration block number | ||
# https://ecips.ethereumclassic.org/ECIPs/ecip-1099 | ||
ecip1099-block-number = "2520000" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this has already been reached on Mordor, right? Have we synced and try it there already?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I will sync with the Mordor before the merge
Option(powCaches.get(epoch)) match { | ||
case Some(pcd) => pcd | ||
case None => | ||
val data = new PowCacheData(cache = EthashUtils.makeCache(epoch), dagSize = EthashUtils.dagSize(epoch)) | ||
val data = new PowCacheData(cache = EthashUtils.makeCache(epoch, seed), dagSize = EthashUtils.dagSize(epoch)) | ||
|
||
val keys = powCaches.keySet().asScala | ||
val keysToRemove = keys.toSeq.sorted.take(keys.size - MaxPowCaches + 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it won't make problems during transition. i.e
- lets say we have epoch
358
and359
here. - we enter fork block
ecip-1099
so next epoch is180
instead of360
- so we put dag cache for this epoch in cache, and we have there dag for epoch
180
and359
(as we have limit of 2 dag caches max, and we always removes oldest one) - after some blocks we arive at epoch
181
. And now we will remove dag cache for epoch180
instead on359
.
It means dag dag cache for epoch359
will be with us for long time (until we get to new epoch360
), and if rollbacks happen accross new epoch boundaries we will need to recreate dag caches. (we have one stale in there, and we have max size of 2 dag caches )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I fixed that
@jmendiola222, I synced with the Mordor top |
Description
https://ecips.ethereumclassic.org/ECIPs/ecip-1099