PowerPool

PowerPool believes that “whitelisting” Keeper or Jobs is an unsatisfactory option for building a truly decentralized and widely adopted automation network. This is why PowerAgent v2 is built as a fully permissionless network — anyone can run a Keeper node and set up an automation Job.However, like any permissionless system, PowerAgent v2 potentially can be abused or attacked. Malicious behavior within the network or just accidental errors while running a Keeper node or registering a Job in PowerAgent might lead to unforeseen consequences for the network and the economic viability of operating Keeper nodes.In this article, we would like to discuss specific attacks against PowerAgent that have been recently discovered. The main goal is to educate developers and token engineers who ask “what if?” questions when building complex systems in a decentralized and permissionless environment.Understanding the system and its possible attack vectorsThe examined systemIn a nutshell, PowerPool’s PowerAgent network works as follows: there is a set of N Keepers and M Jobs. Keepers deposit a CVP stake to be eligible to be assigned automation tasks. When a task should be executed, it is randomly assigned to one of the admissible Keepers. If the Keeper fails to execute the Job in a given temporal interval, the slasher is permitted to do so instead. If the slasher succeeds, slashing commences and the transaction is executed at the same time.The Job can contain a Resolver — a condition that results in “0” or “1”, greenlighting the Job execution when specific conditions are met. When the Resolver returns “1” (meaning that Job should be executed now by the network), it also provides CallData that should be passed in a call to the Job target contract by the selected Keeper.<blockquote>What if the Resolver logic can be malicious by design and focused on crashing the Keeper network?</blockquote>Exploring attack vectorsHowever, how can it happen? We see two main possibilities:<ol><li>Registering a Resolver (or, simply, an algorithm) that cannot be executed on-chain due to exceeding block gas limit or executors’ whitelisting</li><li>Registering Resolvers that can be executed on-chain but provide CallData that always reverts the transaction when Keepers try to execute it.</li></ol>#1 comes from the possibility of registering a Resolver that can never be executed on-chain (but has no logic errors and theoretically looks “good to go” when executing off-chain). It can happen because it contains intense calculations that consume more gas than is possible to use in the block (for example, calculating &#x1d6d1; to the 100th digit with Monte Carlo sampling). We named it “computation abuse”. Another example is whitelisting the possible executor which evidently leads to the impossibility of being executed by any of the registered keepers.The #2 issue arises when registering incorrect Resolvers that return faulty CallData.Examples of CallData errors that result in transaction non-execution:<ol><li>Incorrect formatting (return address in byte format, etc)</li><li>Incorrectly hard-coded bytes data</li></ol>Both of these Resolver Jobs can’t be run by either the Keeper or the Slasher. These Jobs will stay assigned to the selected Keeper, never being able to be properly executed. As a result, this Keeper will not be able to withdraw his stake, as the network sees him as responsible for performing a task.Of course, these are not critical bugs, as no one can actually gain any financial benefit from them. However, they can cause some inconvenience for Keepers and the network in general. That’s why we’ve decided to implement a quick fix to allow Keepers to withdraw their stakes if these problems ever occur.In one of the latest Agent updates, we’ve allowed the contract owner to manually disable certain Jobs as an MVP-like solution. If our staff detects such problematic Jobs off-chain, they will disable them to allow Keepers to free up their staked tokens. In the future, this process will be automated by a dedicated smart contract.Potentially, there can be a permanent, “bulletproof” solution for at least the first type of issues described above. By implementing ZK proofing technologies for Resolvers, we can allow all of their calculations to be performed off-chain, and only the ZK proofs of their execution will be sent to the blockchain. This would completely eliminate all the problems associated with Resolvers being non-executable on-chain. The PowerPool team is currently working to add the zkResolvers feature in the future.The PowerAgent v2 Bug Bounty programPowerPool is about to launch the PowerAgent v2 Bug Bounty program to incentivize its users to actively search for these types of attack possibilities and other issues in its architecture. Individuals or teams of hackers will be able to win bounties for reporting any substantial bugs, errors, and abuse mechanisms to the PowerPool team. These bounties will be in the form of USDC and range from $500 to $5000 depending on the severity of the issue.Stay tuned to <a href="https://twitter.com/powerpoolcvp" rel="noopener noreferrer nofollow">PowerPool Twitter</a> to get all the details of the Bug Bounty program.

Decentralization cost: exploring attacks on keeper networks

PowerPool

Autres articles publiés le 9 août 2023

PowerPool Community Call #1 Recap — April 28th, 2023

The Cypher Protocol Hacker Flooded with NFTs Demanding Return of Loot

Shido - Infinitely Scalable Layer 1

Indian Authorities Arrest Masterminds of $120M Crypto Scheme

XRP Sets Sights on $1.5 Following Another Ripple Triumph – Here Are the Next Key Support Levels

Cardano's MuesliSwap Takes Action on Slippage Issues as ADA Surges

Join our free newsletter for daily crypto updates!