The goal for the report proc macro is to expose functions / hooks that developers to leverage that will
Allow automated triggering of report checking logic (whether a peer is offline, a misbehavior is publicly verifiable, a malicious behavior has been detected, etc.)
Create an event listener for the job submission if the ID is provided.
Craft a proof for the report submission
Handle submitting the report if the hook is satisfied
Features
There are 2 main categories of reports.
There are reports for specific jobs that have been completed incorrectly or maliciously.
There are reports for general behavior expected by operators (reliability metrics).
We thus want to have a macro that can exist on its own or can also relate directly to a job through the ID, creating a pair (job, report) that triggers on incorrect job completions. The macro should expose in this event an event listener that listens to that specific job submissions, gets the signed submission or tx information, and triggers it's handler to prepare submission on chain.
The developer can also specify in these functions how severe the report should be if the constraints are satisfied.
Additional comments/thoughts
This design is a WIP and can be updated. Perhaps there's a better return argument for the report functionality besides the severity of the report. This is defined by blueprint dev so the thinking is they want to control how much to slash using the successful report, however this might not match up exactly as intended, perhaps the severity is defined in the smart contract and the output of the report is a proof/submission.
Overview
The goal for the report proc macro is to expose functions / hooks that developers to leverage that will
Features
There are 2 main categories of reports.
We thus want to have a macro that can exist on its own or can also relate directly to a job through the ID, creating a pair (job, report) that triggers on incorrect job completions. The macro should expose in this event an event listener that listens to that specific job submissions, gets the signed submission or tx information, and triggers it's handler to prepare submission on chain.
The developer can also specify in these functions how severe the report should be if the constraints are satisfied.
Additional comments/thoughts
This design is a WIP and can be updated. Perhaps there's a better return argument for the report functionality besides the severity of the report. This is defined by blueprint dev so the thinking is they want to control how much to slash using the successful report, however this might not match up exactly as intended, perhaps the severity is defined in the smart contract and the output of the report is a proof/submission.