The CPU excels at problems where the number of iterations is not known at the time the problem is proposed. Conventional predicate-based code can be used in conjunction with loop unrolling when the number can be approximated, but this approach enables the solver to dynamically interact with the contract. With future expansion into areas like checkpointing and data signature verification, the proposer, or even other parties entirely, can interact with contracts dynamically while they're being worked on.
Since a complex sequence of many transactions are used in order to define a complete solution and claim a smart contract's bounty (each a CPU clock cycle), we are left with a problem: how to prevent malicious actors from broadcasting partial solutions that put the state of the CPU into an untennable position, where no solution could ever be found from that point on.
To solve this problem, we introduce the concept of a solver's bond paid before a solution can be attempted: before the solver can cycle the CPU on-chain, they must post a bond into the contract. The contract records its initial state (before any transactions), and if after a pre-defined timeout, the solver has not completed their solution, anyone may call a public method that would reset the state of the contract, causing the solver to forfeit their bond.
Discussion