Hooks and helper functions
Herein hooks and helpers used in all implementations are described
Shared hooks
Declared, not implemented
//called before execution of a job
function _beforeExecute(
//job key
bytes32 jobKey_,
//executor keeper/slasher ID
uint256 actualKeeperId_,
//binary representation of the job to call
uint256 binJob_) internal view virtual {}
//called before initiating redemption of keeper stake
function _beforeInitiateRedeem(
//keeper ID
uint256 keeperId_) internal view virtual {}
//called after job execution succeeds
function _afterExecutionSucceeded(
//key of the executed job
bytes32 jobKey_,
//executor keeper/slasher ID
uint256 actualKeeperId_,
//binary representation of the executed job
uint256 binJob_) internal virtual {}
//called after job registration
function _afterRegisterJob(
//registered job key
bytes32 jobKey_) internal virtual {}
//called after depositing credits to a job (not job owner!)
function _afterDepositJobCredits(
//job key
bytes32 jobKey_) internal virtual {}
//called after withdrawing credits from a job (not job owner!)
function _afterWithdrawJobCredits(
//job key
bytes32 jobKey_) internal virtual {}Implemented
_afterExecutionReverted
Shared helpers
Getters
calculateCompensationPure
getKeeperWorkerAndStake
getConfig
Gets the Agent config
getKeeper
Gets Keeper information by ID
getJob
Fetches job information
getJobRaw
Fetches the binary representation of a given job, described in Job (Old)
getJobKey
Gets a job key (keccak256 of the concatenation of the job's address and ID)
Miscellanea
_calculateDepositFee
Computes the fee the Agent retains from a deposit made to either Job or Job owner credits
_calculateCompensation
Wraps the compensation calculations
RanDAO-specific hooks
RanDAO overrides many hooks, given hereafter with annotations.
_afterExecutionReverted
_beforeExecute
Called before job execution to make sure only the authorised keeper/slasher may execute
_afterDepositJobCredits
Called after job credits are deposited to handle potential keeper assignemnt.
_afterWithdrawJobCredits
Called after job credit withdrawal to handle potential keeper release
_afterExecutionSucceeded
Handles slashing logic; called after success of automated job execution.
_beforeInitiateRedeem
Ensures the keeper can initiate redemption of a part of his stake, i.e. has no pending jobs with execution of which stake reduction may interfere (e.g. by changing the keeper's eligibility).
_afterRegisterJob
Immediately assign the next keeper. Assignment is unconditional, but this does not beget possibilities of assigning keepers to jobs with insufficient credits because the _assignNextKeeper has an internal check for that by means of _releaseKeeperIfRequiredBinJob called with the checkAlreadyReleased flag as False, which will return True if the job/owner has insufficient credits (see Keeper assignment and release in RanDAO realisation).
RanDAO-specific helpers
Getters
getJobsAssignedToKeeper
Gets the jobs assigned to a particular Keeper, stored in the mapping keeperLocksByJob .
getJobsAssignedToKeeperLength
Returns the amount of jobs pending for a particular Keeper.
getCurrentSlasherId
Returns the ID of the currently assigned slasher. The returned value is distinct from a reserved slasher and corresponds to the ID of the slasher chosen according to the algorithm described in Copy of Slashing.
getActiveKeepersLength
Returns the amount of currently active keepers.
getActiveKeepers
Returns the list of currently active keepers (IDs)
getSlasherIdByBlock
Provides a way to obtain historical data on assigned slasher IDs (returns ID assigned for a given job key at a given block).
Miscellanea
checkCouldBeExecuted
An always-reverting subroutine for checking executability of a certain function, where executability is flagged by different revert messages. Reversion is necessary to make sure no state changes incurred by successful execution persist.
getPseudoRandom
Gets the pseudo-random number corresponding to the RanDAO realisation; stored in block.difficulty field for backward compatibility since the advent of PoS.
_checkBaseFee
Overrides the Flashbots implementation function of the same name that was initially used to make sure the base fee used for computing rewards is not in excess of what was set as maximum by the job. Since in RanDAO realisation the keepers have no choice in whether to execute the job (in Flashbots realisation, they could control whether the _checkBaseFee function would produce and propagate a revert in case of the base fee being capped), the Job owner is bereft of his ability to set a maximal fee, and so to preserve backward compatilibity the function is overridden to always return the maximal value of the type.
_calculateCompensation
Overrides the eponymous function in the Flashbots reaslisation due to the change in the algorithm.
Last updated
Was this helpful?