Address false claims of a compute order being executed. (OrderExecuted)
What happends after a startOrder ? Consumer will reach out to provider, trying to download file or start a computeJob And he succeeds.
Nevertheless, we will claim that he never downloaded or start a computeJob, which leads to claim resolving. How to fix that ?
Proposal: Have a set of ENV vars, that control how Provider creates the proof:
- USE_CHAIN_PROOF (boolean): if true, then Provider calls ERC20. OrderExecuted (ERC20.https://github.com/oceanprotocol/contracts/blob/v4main_postaudit/contracts/templates/ERC20Template.sol#L1081)
- USE_HTTP_PROOF (string): calls the HTTP endpoint instead of calling ERC20.OrderExecuted (POST query, body description below)
Parameters: For any kind of proof, we need the following:
- orderTxId,
- providerSignature, (Provider signs providerData using it's own private key)
- consumerData (Consumer parameters that formed the signature message that Provider received)
- consumerSignature (Consumer signature is passthrough)
- consumerAddress
- providerData:
-
- For download, we need a JSON object that holds: DID, serviceIndex, fileIndex, downloadedBytes
-
- For compute, we need a JSON object that holds: dataset DID, dataset serviceIndex, algo DID, algo serviceIndex, additionalDatasets (DIDs & serviceIndex)
Moving to backlog for now, signatures are incompatible and we need to table this for now
Blocked now because we need to refactor signature on the entire backend (ocean.js/py + provider)
This is done except for the downloadedBytes part.
@alexcos20 status on this? can we close it?