A little known fact about the nature of blockchain networks is that smart contracts are not actually self-executing. They are tamper-proof digital agreements that must be “pinged” by an on-chain address known as a Keeper in order to make a state transition. While this is fine for a large number of smart contract applications such as the transfer of tokens or trades on a decentralized exchange, where state changes only need to occur when a user generates a transactions, there are number of smart contract use cases that require state changes on a time schedule or an event-based schedule.
Such use cases can include the liquidation of collateralized loans on a decentralized money market when a user’s position becomes too close to being undercollateralized (if a liquidation doesn’t occur then the protocol can become insolvent). This requires an event-based Keeper which “pings” the contract to initiate liquidation when the financial value of the asset used as collateral passes a specific threshold as determined by an on-chain price feed. There are also time-based Keeper tasks such as rebases for algorithmic stablecoins, where on a regular basis (e.g. once a day), the Keeper calls a smart contract function that dynamically adjusts the token supply of the stablecoin in order to track a peg, such as the US dollar. There are many more use cases, but these are some of the primary ones we see today.
Because blockchain networks do not offer self-executing code (as this could be a denial of service attack vector), development teams often build their own Keeper bot in the form of a centralized cloud function that monitors when a “ping” transaction could occur. However, this results in a central point of failure as when that centralized cloud function goes down, the contract is unable to make the required state changes. As the value secured by smart contract applications rises, it is key to decentralize the keepers used in order to ensure liveness of key state changes. However, such a decentralized Keeper solution also needs to be cost-efficient in order to be practical for large and small decentralized applications alike.
One solution that recently launched is Chainlink Keepers. It leverages the existing network of Chainlink oracle node operators to provide transaction automation services, in addition to the oracle services such as price feeds and verifiable randomness. In this implementation, a decentralized network of Keepers monitors when a “ping” transaction needs to be initiated by executing a portion of the smart contract off-chain. When it is determined an on-chain transaction is required, a node is selected using a round robin process to submit the transaction. If the selected node fails to generate a transaction with a predefined time bound, then a new node is selected. This ensures high uptime through redundancy, while preventing price gas auction wars seen in other Keeper implementations (nodes compete to complete the task), thereby lowering the costs for the end-user. This effectively uses a decentralized oracle network to bootstrap a decentralized transaction automation service.
With Keepers, developers can create autonomous smart contracts that are fully decentralized end-to-end, including the contract’s on-chain logic on the blockchain, its external inputs and outputs with oracles, as well as the initiation of state changes with Keepers. With Keepers, I think there are some interesting questions that arise, such as:
Should the smart contract function a Keeper network calls be permissionless or permissioned to a specific committee of Keepers? What are the implications of either?
Can Keepers help the growth of the multi-chain ecosystem by providing the ability to mint and burn cross-chain tokens?
How many nodes does a Keeper network require to ensure maximum uptime while keeping the costs of the transaction automation service viable?
Can Keepers outsource not only the automated triggering of a contract but provide off-chain computation of a portion of the contract’s logic?
Awesome, I didn’t realize this about Chainlink Keepers!
Should the smart contract function a Keeper network calls be permissionless or permissioned to a specific committee of Keepers? What are the implications of either?
IMO permissionless: the onus should be on the user to determinine the average price per unit time a user is willing to pay for a given upkeep, and ensure that the parameters of the job (when it can be called, etc) cant be gamed. As a potential user of Keepers via LinkPool’s KeeperSweeper, a contract that will allow Keepers to kick off a mechanism that “sweeps” rewards from a Chainlink node’s set of addresses that job rewards accrue to, our mechanism is essentially that a contract becomes “sweepable” if a certain amount of rewards have accrued on it. If a certain amount of contracts are sweepable, then the upkeep becomes callable, ensuring we’re getting good value for our payment to the keeper.
Can Keepers outsource not only the automated triggering of a contract but provide off-chain computation of a portion of the contract’s logic?
Here’s an interesting one I’m working to wrap my head around still. I’m curious to know what some folks who have more experience developing smart contracts (like @tina1998612@jyezie etc) think! My primary concerns would be game-theoretical, and based on trusting the keeper.
Imagine KeeperSweeper above, I suppose, and breaking out the logic of determining whether an individual contract was sweepable. A malicious Keeper could say all the contracts are sweepable, burning the KeeperSweeper’s ETH (because to my understanding the KeeperSweeper contract pays the ETH to actually withdraw from the rewards contracts), still paying their relatively fixed cost to call the exposed upkeep job, (which kicks off the sweeping) and collecting their payment.
This looks like a useful service for protocols that require frequent parameter adjustments. Derivatives being a prime example based on what underlying markets are doing.
Are there any comparison models around the costs and benefits for protocols that currently run their own incentivized keeper programs migrating to Chainlink Keepers?
I have the same question. What would say they can’t or should not?
It seems like this could be prevented through an on-chain verification check, it would require some on-chain computation, but potentially less as it only needs to check specific contracts and not all of them. I think it’s mostly use case dependent, like Keepers posting a layer 2 rollup block or providing a hash that can be checked later for verification.
I’m not aware of any quantified examples, but when a project creates their own keeper, they would likely need to hire engineers, building monitoring software, fund their keepers with extra ETH for gas fees, undergo security audits, subsidizing keepers, and deploy more capital in general for creating infrastructure rather than using existing infrastructure.
I think for computation, it would really depend on the use case and the trust model desired by users. If users are already trusting the same set of oracles for accurate data, they could also trust them for keeper computations to make state changes as needed.