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?