Taskmaster is a new module of Paloma, responsible for executing hard coded, recurring logic and synching the outcome on KV stores on the chain.
Creating the ability to execute arbitrary logic on a recurring basis will serve as the foundation of setting up a pricing oracle within Paloma. In order to accelerate production speed, we’re opting to keep logic definition hard coded for the moment, but this can be expanded in the future, allowing users to setup their own oracles directly on the chain.
With the concept of recurring jobs being established for cross chain arbitrary logic execution, it’s important we stay consistent in our terminology in order to avoid any confusion when communication about either feature. Therefore, we establish the term
task for the execution of arbitrary on-chain logic.
- Create a new module with a KV Store keeper implementation
- Create an abstract task definition
Persistencelayer: Tasks need a way to sync their outcome in their own KV store
Migrationlayer: Tasks might need to create new stores during migrations
- Create an implementation of the task definition to setup a task which
- check if the node is staking (only participating validators will be running the data retrieval task)
- will be executed every
nblocks, or after
- query prices from coingecko using the validator’s API key
- on fail: ???
- on finish: write results to KV storage
- Create the scheduling logic executing the new task
- Create the rescheduling logic
- Create a KV store migration
- Create the task monitoring
Currently the only task implementation is hardcoded, doing a data curl against coin gecko and storing the results.
In the future, we could expand the module with Lua or Python callbacks to allow users to propose and store any arbitrary on chain logic as a task.
- Coingecko Oracle: How do we approach a failed task execution? Should validators who consistently fail to execute be jailed in order to incentivise?
Include any additional information or notes that are relevant to this feature request.