Age-aware Mining #92
Age-aware Mining #92
Conversation
src/Chainweb/CutDB.hs
Outdated
| -- components of this node. | ||
| -- | ||
| updateNetworkHeight :: CutHashes -> IO () | ||
| updateNetworkHeight = atomically . writeTVar networkHeight . Just . cutHashesHeight |
There was a problem hiding this comment.
@larskuhtz is there a chance that a Cut could come in that would significantly drop the agreed-upon Cut Height?
There was a problem hiding this comment.
There will be incoming cuts with very low height, but the agreed upon height should never decrease. Cuts of very low height should be filtered out immediately by the cut processor.
There was a problem hiding this comment.
There is some interference with #161 here: with the changes from that PR, if a cuts that are far ahead, would be dropped, too. So we would see in the processor only cuts that are at most 1000 blocks ahead. Once we get close to those we would start mining, even though the network is much further ahead.
One solution could be to sample the current height after we drop old cuts and before we drop far-ahead cuts.
larskuhtz
force-pushed
the
lars/tmp
branch
3 times, most recently
from
ce80f40
to
6c63c1d
Compare
This will help nodes detect whether there is a point in mining or not.
STM is the much more idiomatic way to handle this.
fosskers
force-pushed
the
colin/sync-phase
branch
from
9fc3f50
to
0365f50
Compare
This avoids special song-and-dance around detecting if the TMVar is empty.
|
What about keeping a little bit of state and compute the current height by more than a single incoming cut. E.g. we could keep track of the maximum for each node/origin and take some percentile of that. For example: the 90 percentile or the minimum of the max of the top 5 nodes, whatever, is less. |
|
@larskuhtz Yes I think something like that will be better for preventing attacks / being more accurate. I'm thinking about design now. |
| @@ -266,26 +284,28 @@ startCutDb | |||
| startCutDb config logfun headerStore payloadStore = mask_ $ do | |||
| cutVar <- newTVarIO (_cutDbConfigInitialCut config) | |||
| queue <- newEmptyPQueue | |||
| cutAsync <- asyncWithUnmask $ \u -> u $ processor queue cutVar | |||
| peerHeights <- newTVarIO . PeerHeights $ BQ.singleton 16 (BlockHeight 0) | |||
There was a problem hiding this comment.
Unsure how big the Queue should be.
There was a problem hiding this comment.
Why not use TBQueue in this case?
There was a problem hiding this comment.
There's no way to fold over a TBQueue.
| updateNetworkHeight ch = case _cutOrigin ch of | ||
| Nothing -> pure () | ||
| Just _ -> atomically . modifyTVar' peerHeights $ | ||
| \(PeerHeights q) -> PeerHeights $ BQ.cons (_cutHashesHeight ch) q |
There was a problem hiding this comment.
O(1) consing + "forgetting" of oldest values.
| @@ -266,26 +284,28 @@ startCutDb | |||
| startCutDb config logfun headerStore payloadStore = mask_ $ do | |||
| cutVar <- newTVarIO (_cutDbConfigInitialCut config) | |||
| queue <- newEmptyPQueue | |||
| cutAsync <- asyncWithUnmask $ \u -> u $ processor queue cutVar | |||
| peerHeights <- newTVarIO . PeerHeights $ BQ.singleton 16 (BlockHeight 0) | |||
There was a problem hiding this comment.
Why not use TBQueue in this case?
| -> Adjustments | ||
| -> IO () | ||
| go :: Given WebBlockHeaderDb | ||
| => Given (PayloadDb cas) |
There was a problem hiding this comment.
Could we purge these Given values?
There was a problem hiding this comment.
Likely? @larskuhtz ?
| -- considered "caught up". | ||
| -- | ||
| catchupThreshold :: ChainwebVersion -> Natural | ||
| catchupThreshold = (2 *) . diameter . _chainGraph |
There was a problem hiding this comment.
It'd probably be easier to inline this here or as a data entry in the chainweb version instead of calculating this every time we need to establish a consensusCut. That way, we can think of chainweb versions as having a tuneable "catchup threshold" built in.
fosskers
added
the
component: miner
|
Closing for now - the stand-alone mining client will likely make all of this defunct. |
Currently, if fresh/out-of-date nodes are introduced to the network, they spend a fair amount of time getting caught up. Meanwhile, they continue to mine old blocks and yield
Cutinformation into the network. This is wasted work, as any blocks they produce will never be considered by the main "Consensus Pack".This PR allows the POW miner to detect its distance from the main Consensus. If too far, it will halt mining until caught up.