Hi Everyone!
I want to update you all on the progress DFINITY has made on the Tokamak milestone that aims to reduce end-to-end (E2E) latency of update calls to canister smart contracts. We have completed the implementation of several exciting upcoming features that will lower user-perceived latency when interacting with the Internet Computer. All of these features will greatly improve how users experience the speed of ICP.
Synchronous Ingress Messages
We have completed the implementation of a new HTTPS endpoint for making update calls, /v3/ā¦/call. This new endpoint is synchronous and responds with a certificate. This differs from todayās asynchronous endpoint, /v2/ā¦/call, where users submit ingress messages, and must then continuously poll the for ingress messageās status. This polling adds significant latency to every call, so switching to a synchronous endpoint that does not require polling will lower the end-to-end latency.
Figure 1 below illustrates the semantics of the old and new call endpoints. On the left, we see that when a user submits an update call to the old endpoint, they must start polling the ICP for the certified response with the /read_state requests. On the right-hand side, we see that the new call endpoint waits to respond until a certificate is ready and sends it back to the user.
Figure 1
Routing ingress messages to the new call endpoint will just be an implementation detail of user agents such as agent-js and agent-rs. This means your dapp can benefit from the new endpoint by simply upgrading the agent version once the agents support the new endpoint.
Geo Aware boundary node routing
Boundary nodes serve as a gateway to the Internet Computer by providing HTTP endpoints that route canister requests to the right subnet.
At the moment, boundary nodes route a request to a random node within the destination subnet. As the nodes are distributed across the globe, some nodes are closer and others further away. This leads to vastly different network latencies per request (from tens to hundreds of milliseconds).
We are proposing to change the boundary nodesā routing behavior for update calls. In particular, we propose that they choose among the closest āthirdā (f+1). This helps reduce the latency between the boundary nodes and the replica nodes.
Increasing the Block Rate of subnets.
We also want to increase the rate at which Internet Computer subnets produce blocks. A higher block rate means messages can be included in a block sooner, leading to a lower latency. Note that this change will lead to more variability in the block rate of subnets: under low load, we expect to see more than 2 blocks per second, but under high load, the block rate would likely fall to ~1 block per second. This increased block rate can be achieved by modifying consensus protocol parameters that are part of the subnet settings in the registry (namely, the initial_notary_delay_millis).
The reason we can now lower this notarisation delay is partly due to the new P2P layer of ICP, announced here. The new P2P supports a higher throughput between nodes and an optimized protocol for sending messages between nodes. This means that subnets can produce blocks at a faster rate and ensure that all nodes can keep up.
Next Steps
DFINITY plans to submit proposals to gradually roll out these three features over the coming months, and use this forum thread to keep everybody informed of the progress. We also plan to collect end-to-end latency metrics, so hopefully we will see this number reduce as the new features roll out.
Feel free to comment if you have any questions!
- Daniel
