Address false claims of a compute order being executed. (OrderExecuted)

[alexcos20]

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)

[calina-c]

Moving to backlog for now, signatures are incompatible and we need to table this for now

[alexcos20]

Blocked now because we need to refactor signature on the entire backend (ocean.js/py + provider)

[calina-c]

This is done except for the downloadedBytes part.

[mihaisc]

@alexcos20 status on this? can we close it?