Synchronization between proxy and node is desired

[jorgeantonio21]

If the node and the proxy are not synchronized, they need to negotiate what is the right number of compute units already being computed. We can assume that the node is running with a TEE, so claimed compute units can be assumed by the node are correct, unless (most of these cases happen on streaming):

1. The node goes down (liveness failure). In this case, the node might have updated the number of compute units without sending the request to the proxy.

2. The proxy should have a callback mechanism that retries calling the node a few times. If the node is live, it should cache its responses, and send them back to the proxy, if a callback is triggered (this is the case, in which the proxy errored, while the node successfully generated the full response. In this case, the node retrieves the cached response and sends it as is to the proxy. The node should keep its cache for a few seconds (say 10/20 seconds) and then delete it.

3. The node goes down (potential liveness failure). The proxy fails a number of callback retries. In that case, the proxy needs to inform the contract, which will trigger a timeout event. If the node answers back to the contract within that event, it might get back online fast enough, it is supposed to send it back to the proxy and send a hash of the already generated response to the contract (the flow order is important), it then should restart a connection (or just store everything on a dStorage layer). Otherwise, the node is flagged as down and it should get the stack compute units locked, (fully or partially).