Allow Mine instruction CPI's

[Kriptikz]

This PR updates the transaction introspection logic of the Mine instruction to improve program composability.

A new instruction DeclareProof is used to declare a single proof pubkey for processing in the transaction. The DeclareProof instruction must be the second instruction in the transaction. The first instruction is reserved for setting the compute limits.

A new function find_and_parse_declared_proof can be used by other instructions in the program to get the declared proofs pubkey. It looks at the second instruction in the transaction when parsing the declared proof.

The Mine instruction processor was updated to use the find_and_parse_declared_proof with the instruction introspection data to validate that only the declared proof can be processed.

These changes should allow other programs to CPI into the Mine instruction while still ensuring only a single hash can be processed in a single transaction.

[Kriptikz]

@HardhatChad Any chance of this, or something like this getting merged? It opens up a lot of potential while still preventing multiple proof accounts from be mined in the same transaction.

It can also make the ore-relayer setup much cleaner. No need to worry about constantly claiming after each mine or missing out on commision, as the ore-relayer itself would be able to distribute the rewards appropriately.

[HardhatChad]

What's the use case for submitting mine instructions via CPI?

[HardhatChad]

For relayer stuff, we assume the relayer can pass in a collect ix on the tx

[blasrodri]

What's the use case for submitting mine instructions via CPI?

On chain mining pool

[Kriptikz]

The biggest one would be delegate staking.

If any other programs require locking up ore for something. Being able to still put that ore to use is valuable. The locked ore can be delegated to a miner to earn rewards instead of just sitting there.

It will also allow a wrapper program like the ore-relayer to take a commision % directly on a mine submission instead of having to add a collect ix or send a collect tx after every mined hash is submitted.

I generally think composability is pretty valuable.

[HardhatChad]

I could be wrong, but pretty sure both of these (liquid staking and mining pool) can be done w/o mine CPI. Supporting these use-cases was the primary reason we added the miner authority to the Proof account.

For liquid staking, you just need a wrapping program that implements the pool math correctly for stake and claim. The actual miner (hashpower operator) can submit hashes with their miner pubkey. And for a mining pool, it's the same setup. Pool only lowers your cost basis if you coordinating hashpower off-chain. If you are paying tx fees to submit your partial solutions on-chain, you might as well just mine directly with the ORE contract and avoid the pool middleman. Pool claims/staking can happen via wrapping program without mine CPI.

[HardhatChad]

Composability is important though, and I can see where this would make some things a little easier. Very clever solution

[HardhatChad]

There are some holes in the introspection logic. Merging into separate branch to play around with this

[Kriptikz]

There are some holes in the introspection logic. Merging into separate branch to play around with this

Yea it doesn't actually verify that it's the DeclareProof instruction. But it does make sure that the ix there has only one account pubkey provided and the instruction is for the Ore program. Can read and parse some more bytes from the data if you want to ensure it is that instruction.

Also could probably use the load_instruction_at_checked system function instead of parsing the tx data the way it does now.

[HardhatChad]

Implemented stricter introspection here. Supports an arbitrary number of ixs prior to the auth, but the auth has to be the first ore ix.

https://github.com/regolith-labs/ore/pull/72