The HTTPS outcalls feature has been live on the Internet Computer for almost a year now. This feature lets dapps on the Internet Computer call any HTTP server, over HTTPS, ingest data from web 2.0 sources and publish updates from the dapps to web 2.0.
When launching the feature, during the experimental phase, the pricing was set quite conservatively. The price per HTTPS outcall on a 13-nodes subnet was set to:
400M + 100K * (request_size + max_response_bytes) cycles
request_size is the size of the request in bytes and
max_response_bytes is the value provided in the request for the
max_response_bytes argument (which defaults to 2MB, but can be set to much lower based on the application requirements).
This formula above results in a relatively high price per HTTPS outcall, compared to other operations on the Internet Computer (but still, much cheaper than using external oracles).
Recently, we have re-evaluated this price formula by conducting a set of experiments and a thorough analysis to reduce the price of HTTPS outcalls, while still having it cover the actual cost of them to node providers.
We would like to propose a new formula for the price of HTTPS outcalls, which would be, for a 13-nodes subnet, as follows:
49.14M + 5200 * request_size + 10400 * max_response_bytes cycles
As you can see, the proposed new formula reduces the price per outcall by almost 10x factor. In the rest of this post, I will try to explain what stands behind these numbers.
Part 1: The Cost Factors of HTTPS Outcalls
To make an HTTPS outcall, each node on the subnet starts by sending out the HTTP request, then getting a response. Each node then applies the transform function on the response, if one is specified. Then, each node hashes the transformed response, signs the hash, and sends the hash with the signature to all its peers. A block maker may, at some point, validate the received hashes (and their corresponding signatures), and if enough hashes match, include the response in the block and hence return the response to the calling canister.
As you may see in the description above, the process of making one outcall is quite involved and includes several sources of overhead. For example, the fact that the outcall is made by all subnet nodes, and the fact that each node then has to send out
(N-1) messages for each outcall, where
N is the number of nodes in the subnet. Part of the cost is therefore growing quadratically with the size of the subnet, and looking forward into the future where bigger and bigger subnets will be available, the price formula should account for this quadratic growth in cost.
Part 2: Quantifying it in Cycles
Quantifying the resources such as CPU, network bandwidth, memory, etc., we upper-bound the cost for each node making an HTTPS outcall at:
3M + 60K * N + 400 * request_size + 800 * response_size cycles
N is the number of nodes in the subnet,
request_size is the size of the request in bytes, and
response_size is the size of the response in bytes, assuming no transformation is performed)
This formula has been obtained by experimenting with the feature on testnets of different sizes, with and without HTTPS outcalls being made, with different sizes of requests and responses, and by considering its theoretical properties of messages, e.g., number of messages sent and their sizes.
Plugging a subnet size of
N=13 (and using
max_response_bytes as an approximation for the actual response size) would yield the new formula shown above.
Part 3: What does that Mean?
The figure above shows the current and proposed new price of an HTTPS outcall on a 13-nodes subnet, with a request size of 1KB. Using the new price function, the price indeed drops significantly for all sizes of responses. The table below shows some sample prices in SDR cents:
We hope that the new price function would encourage more developers to use HTTPS outcalls in their canisters, to demonstrate the unparalleled power of the Internet Computer to the world.
We have not submitted a proposal for the suggested changes yet. We would be happy to have a discussion and the community’s feedback on this topic.