HTTPS outcall consensus on GET calls

I read up a bunch of material on HTTPS outcalls. Basically every node in a subnet issues a GET request and receives some data. Each node signs the content and broadcasts the signatures. Now I am assuming that only the signatures are broadcast and the recipient of the signature accumulates them and verifies the aggregated signature on the state they would have obtained. But if the state at each node is different then signature verification would fail. So I am guessing the resulting state is also broadcast with the signature. But then they all have to choose one message and the same message. How is that accomplished? Thanks in advance.

Nice to hear that you are digging deeper into how HTTPS outcalls work. Did you read about the transform function? If there is slightly different data in the responses that are not relevant, this can be ignored for building consensus on the response data. E.g. most of the time the headers are not needed at all and often lead to issues when moving to mainnet. Locally, the devs typically only run one replica where this effect does not appear.

Also, responses generally need to be idempotent which should always be the case for GET requests. However, for POST requests there are also solutions to workaround this if a web2 API does not support this. You can e.g. use idempotent-proxy to achieve this.

1 Like