Safe Haskell | None |
---|---|
Language | Haskell2010 |
Synopsis
- newtype BackoffDelay = BackoffDelay NominalDiffTime
-
data
HardForkBlockchainTimeArgs
m blk =
HardForkBlockchainTimeArgs
{
- hfbtBackoffDelay :: m BackoffDelay
- hfbtGetLedgerState :: STM m ( LedgerState blk)
- hfbtLedgerConfig :: LedgerConfig blk
- hfbtRegistry :: ResourceRegistry m
- hfbtSystemTime :: SystemTime m
- hfbtTracer :: Tracer m ( TraceBlockchainTimeEvent RelativeTime )
- hfbtMaxClockRewind :: NominalDiffTime
- hardForkBlockchainTime :: forall m blk. ( IOLike m, HasHardForkHistory blk, HasCallStack ) => HardForkBlockchainTimeArgs m blk -> m ( BlockchainTime m)
Documentation
newtype BackoffDelay Source #
A backoff delay
If the
horizon
is very far away, the current tip is very far away from the
wallclock. However, that probably does not mean we have to wait
now -
horizon
time: we are probably just syncing, and so the tip of the ledger
will rapidly move forward. So at most
now - horizon
could be used as a
heuristic for how long to wait. For now we just trace it.
Instead, we just return a fixed delay of
backoffDelay
. There is a
trade-off between trying to often, incurring computational overhead, and
missing the opportunity to produce a block. For mainnet, we anticipate a 60
second delay will keep both the computational overhead and the number of
slots we might miss reasonably small. We anyway can't guarantee the speed of
syncing, so delaying it by a further 60 seconds as needed does not change
anything fundamentally.
(NOTE: We could reduce this delay but Edsko doesn't think it would change very much, and it would increase the frequency of the trace messages and incur computational overhead.)
data HardForkBlockchainTimeArgs m blk Source #
HardForkBlockchainTimeArgs | |
|
hardForkBlockchainTime :: forall m blk. ( IOLike m, HasHardForkHistory blk, HasCallStack ) => HardForkBlockchainTimeArgs m blk -> m ( BlockchainTime m) Source #
BlockchainTime
instance with support for the hard fork history