Web3 Infrastructure: Chainlink Part 2

Introduction

This is the first installation of the series through which I will break down each of Chainlink’s services for better understanding. In this installation, we will be discussing Chainlink Keepers, defined as follows:

Chainlink Keepers is a service that allows for the automation of maintenance tasks that need to be performed for the “upkeep” of a SMART contract. 

As previous, all sources will be contained at the bottom of the article. Any questions and comments can be directed to my twitter @crunchesofoats. Enjoy your reading.

The Problem

To understand the usefulness of Chainlink Keepers, one must first understand how SMART contracts perform activities. Activities herein are defined as any directions dictated by the code in a SMART contract. These directions are completed based on an “If, then” function: “If” conditions X are met, “then” the SMART contract will be triggered to perform Y activity.

It is important to note here that SMART contracts do not have the ability to perform complex computations or monitor real world data. This means that under circumstances in which a SMART contract’s conditions require real time updates, the contracts are unable to ascertain if conditions are being met. In these circumstances, Developers can monitor conditions themselves or outsource to a centralized third-party. 

Chainlink Keepers is proposed as a decentralized solution that allows developers to securely automate maintenance tasks (ie., conditions).

The Players

The below are the parties that operate as part of the Chainlink Keepers system.

** Upkeeps**: On-chain maintenance tasks performed by Keepers once conditions are met 

Keepers: Nodes from the greater Chainlink Decentralized Oracle Network (DON) that monitor and perform upkeeps. Node operators must register with the Keepers Registry to perform as a Keeper. 

Keepers Registry: SMART contract that performs governance and overlooks all players in the Keepers ecosystem. It is responsible for registering and managing upkeeps, tracking all registered Keepers, and providing compensation for task performance

How It Works

Below is a figure that details the interactions between the SMART contract and Chainlink Keepers.

Chainlink Keepers Automation Process
Chainlink Keepers Automation Process

In section 1, the developers of SMART contract X are either: 

  1. Creating a keeper-compatible SMART contract, which includes lines of code that allows the SMART contract to interact with the Chainlink Keepers 

  2. Deploying the keeper-compatible SMART contract so that is now on-chain

  3. Registering the keeper-compatible SMART contract through the Chainlink Keepers DApp; at registration the developer will determine if the conditions for performance will be attached to time (time-based trigger) or specific to the needs of the project (custom logic trigger)

OR

  1. Inputting their specific upkeeps into the Chainlink Keepers Job Scheduler, which does not require a keeper-compatible SMART contract. However, maintenance tasks that make use of the Job Scheduler can only require time-based triggers. All maintenance tasks that require custom triggers must have a keeper-compatible SMART contract.

 

In section 2, the Chainlink Keepers perform via: 

  1. Keepers run the maintenance task functions off-chain to determine if the set conditions for the maintenance task to be performed have been met

  2. If function returns “true” (ie. conditions have been met), the Keeper performs the on-chain transaction necessary to trigger the SMART contract to action

  3. The SMART contract checks to make sure conditions have been met for action. Once confirmed, the SMART contract performs the maintenance task 

  4. If the function returns “false” the Keeper continues to monitor conditions until they have been met

 

Important Note: There is a point of centralization involved in Chainlink Keepers. Only one Keeper can monitor and trigger a maintenance task at a time. Each Keeper is only allowed to monitor and trigger an upkeep for a specific number of blocks (a “turn”), and Keepers are rotated out once that turn has been completed.

If multiple triggers occur during a Keeper’s turn (ie. conditions are met for the upkeep more than once), the current Keeper and the next Keeper in line alternate monitoring and performing the Upkeep until the end of the current Keeper’s turn. If the current Keeper becomes inactive or cannot perform, the next Keeper in line is supplanted to perform the upkeep. An algorithm determines the lineup of Keepers. 

Sources

Breidenbach, Lorenz, et al. Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks. 15 Apr. 2021, https://research.chain.link/whitepaper-v2.pdf?\_ga=2.193233451.740500264.1661436925-2037660992.1657727189.

Chainlink. “Chainlink Automation Job Scheduler For Time-Based Smart Contracts.” Chainlink Blog, 28 June 2022, https://blog.chain.link/chainlink-automation-job-scheduler/.

---. “Smart Contract Automation - Guide & Explained | Chainlink.” Chainlink Blog, 2 Dec. 2021, https://blog.chain.link/smart-contract-automation/.

“Chainlink Automation Documentation.” Chainlink Documentation, https://docs.chain.link/chainlink-automation/introduction/. Accessed 1 Dec. 2022.

“Chainlink on EVM (Ethereum) Chains.” Chainlink Documentation, https://docs.chain.link/ethereum/. Accessed 1 Dec. 2022.