# Power Agent Extension Proposal Draft

## Introduction

This draft proposal aims to extend the capabilities of the [Power Agent](https://mirror.xyz/cvp.eth/QSH6MfjGX054_g6LHpxI58EtkmoRLaWnLrZpf-DDc1s) protocol, which allows the creation of `execution jobs` with specific time contraints and conditions. The `Smart Contract` stores the execution jobs and assigns them to a group of `Keepers` for monitoring. The Keepers are responsible for executing the jobs by calling the relevant functions in the Smart Contract. Once the job is completed, the `Keepers` receive their rewards from the `Contract`.

The current algorithm used by the `Keepers` to execute jobs is based on an auction system. In this system, `Keepers` submit proposals to execute a job, including the fee they would charge for their services. The `Keeper` with the highest proposed priority fee (and therefore the lowest margin fee) is selected to execute the job.

This decentralized system allows for reliable execution of transactions when certain conditions are met, without the need for a central server or node to monitor the network and trigger transactions.

We suggest to implement `Commit-Reveal Keeper Selection` on this existing framework to improve the `Keepers` selections to execute jobs in the Power Agent protocol.

## Commit-Reveal Keeper Selection Method

Another way to automatically execute transactions within the Power Agent protocol is to use the following approach for Keeper selection:

1. Keepers which are interested in the execution of this specific job commit a random number that is signed and hashed(Even just being hased is good enough to save processing).
2. In the reveal stage, Keepers reveal the numbers that they have committed by submitting another transaction to the contract. The submitted number of a keeper will be $v_i$. Where $i$ is an id of the keeper.
3. Each job can be executed by three keepers which will be picked randomly. For this random pick contract has 3 big prime constants, let's call them $p_1, p_2, p_3$. The algorithm adds all of the previously accepted numbers from and then produces the ids of the keepers that will be able to execute the job: $$ k_j \equiv (p_j + \sum_{i=1}^{n} v_i) (\bmod{n}), j \in [1,3]$$ at will be able to execute the job, n is a number of active keepers(or keeper-owned cells, if we want to have the probability of the keeper to be an executor become bigger if he has a bigger stake).
5. The Keepers with these IDs are entitled to execute the transaction.
6. The first Keeper to execute the transaction will receive a reward, while the other two will receive a consolation prize (such as a gas refund and possibly a token reward as well).
7. After a certain timeout after the keeper election if transaction wasn't executed any keeper can pick it up and execute it.

This approach allows for more reliable execution of transactions and provides a more balanced distribution of rewards among Keepers. It also reduces the risk of fraudulent behavior, as `Keepers` are unable to manipulate the system to gain a greater share of rewards. Overall, implementing this new algorithm would improve the efficiency and reliability of the Power Agent protocol.

This flow most likely is going to happen on some of the second-layer networks due to the high volume of on-chain interaction. And transaction execution will be bridged to the main net after the keepers for the execution were picked. We should also mention a serious drawback to this specific method, which is that it will definitely cause some time lag between the condition satisfaction and the execution of the job, due to this 2-step process. Plus this approach will require to possibly increase the cost of the job, because ideally the job submission will also consist a compensation for the partisipation in this "election" rounds.

One of the possible ways to optimise it is to do the election rounds for the keepers before the job is open for the proposal. This way the delay will be shrinked only to the execution of the transaction.

## TLDR

The Commit-Reveal Keeper Selection method is a proposal to improve upon the existing auction system used by `Keepers` in the Power Agent protocol. This new approach would involve Keepers committing and revealing random numbers, which are then used to identify three Keepers who are entitled to execute a transaction. This method offers several benefits over the current auction system, including increased security and reduced fees for users. Additionally, the use of a nonce and a modulo in the selection process ensures that the Keeper selection is randomized and fair. Overall, the Commit-Reveal Keeper Selection method is a valuable addition to the Power Agent protocol, offering improved reliability and efficiency for transaction execution.

## Phases
Every submitted job has three steps required for the execution, if the conditions for its execution are already satisfied:

### Commit phase

After the submission of the job, interested people need to mark their participation by sending a `commit` message which will contain a sha256 hash of the random integer number. From this `commit` message we store both an address of the `Keeper` and a hash to validate it later on.

Very important thing starts at the first commit message for the job. As it is received the contract starts a timer for the commit phase, `time` of a commit phase will be a contract parameter. It defines the `time` while it will be possible to submit the commit messages.

Afterwards, commit phase can end in two possible ways:
1. Timer runs out, and Reveal phase is put immedeatly in place
2. We have a number of cells for commits specific for a job. If cells are filled we finish the commit phase

We also run a checker server in the background. If noone has commited for a specific job we take a look at it and slash all of the commiters if the job was still profitable. We need to estimate tx execution cost, if it does not exceed the payback for the transaction, then we slash "collective slash".

<!-- Give to the keepers the possibility to leave job.

We have 2 categories of jobs:
1. Interval. Here we can have 2 types of commit-reveal : dynamic and static, we either set "Keeper" cells in the beginning, and then commit-reveal happens between them, or we update "Keeper" set every iteration.

Signature, Signature with calldata, Resolver

Think about cheap "compensation" distribution between commiters. -->

### Reveal phase

Reveal phase starts directly after the commit phase. It also has a timeout as well. During the reveal phase, people are sending a message with the value that they hased and commited during the first time. If hash values correspond, then we do the arithmetics described above.

Reveal phase also has just 2 possible ends:
1. Timer runs out, and Execution phase put immediatly in place.
2. All of the commiters have submitted their reveal messages.

## Execution phase

Finaly an execution phase kicks in. During reveal phase the executors are being picked by the usage of the formulas. There are 3 executors picked for the job, now any of them can transfer an execution transaction. Only people who participated both in commit and reveal phase can be picked as the executors.
Execution phase also has a timer, after time $T_1$ if transaction was not executed, the executors are getting slashed, and anyone who participated in the commit phase will be able to execute the transaction. If noone executes the transaction in time $T_2$, then all of the commiters get slashed, and any keeper is able to execute the transaction.

<!-- ## Jobs

There are three types of jobs that exist in the contract for the execution: -->

## Possible ideas

- We can add bridging to the mix, this will allow cheap voting for l1 executions