As a developer on ICP, understanding the distinction between query calls and update calls is essential for building decentralized applications (dApps) on the platform. This distinction impacts the performance, security, and design of applications running on the ICP. To provide a clear understanding, this article will explore the nature of both types of calls, their use cases, and the technical differences that influence the execution of dApp logic.

What Are Ingress Messages?

Before diving into query and update calls, it's important to understand the concept of ingress messages. In ICP, an ingress message is any external message sent by a user or another canister to a specific canister smart contract for processing. These messages are processed by a subnet of replicas — nodes that host the Internet Computer — in the same order to maintain the integrity of the decentralized system. This ensures that every node in the subnet has the same view of the replicated state.

Overview of an Update Call

An update call is an ingress message that modifies the state of a canister (a smart contract). Update calls must go through consensus, meaning that all replicas on a subnet agree on the order in which the message is processed and the outcome of the call. This ensures the integrity of the system by making the state changes part of the permanent replicated state, which all nodes in the subnet hold.

Update calls:

• Modify the replicated state of a subnet: When an update call is made, the state of the canister is changed and committed.
• Go through consensus: Every update call is agreed upon by all replicas, ensuring consistency and preventing conflicting changes to the canister's state.
• Latency: Since update calls must be processed by all replicas and pass through the consensus mechanism, the time to get a response is higher than for query calls.

Use case examples:

• Updating account balances in a decentralized finance (DeFi) app.
• Recording user actions in a dApp to maintain the integrity of user data.
• Writing data to the canister’s persistent storage.

Overview of A Query Call

On the other hand, query calls are designed for read-only operations that do not modify the state of a canister. They allow for fast access to the canister's data because they don’t require consensus from all replicas in a subnet. Instead, query calls are executed directly by a single replica, which dramatically reduces the latency of the response.

Query calls:

• Do not modify the replicated state of a subnet: Any changes to the canister’s state during a query call are temporary and are not committed to the network's replicated state.
• Bypass consensus: Since the results do not alter the state, there's no need for consensus, which allows the query to be processed much faster.
• Low latency: The response time is significantly reduced, as query calls are processed by only one replica rather than waiting for a subnet-wide agreement.
  

Use case examples:

• Fetching a user’s balance or transaction history in a dApp without modifying the state.
• Retrieving information from a canister to display on a front-end without committing any changes.
• Running computational operations that only require reading data from the canister.
  

Authentication of Query Calls

One limitation of query calls is that they are not recorded in the ingress history data structure. This means that responses from query calls cannot be authenticated using the per-round certified state mechanism that governs update calls. Essentially, query calls are faster but come with reduced security guarantees because they bypass consensus.

However, the Internet Computer provides a solution for developers who need both the performance benefits of query calls and the security of authenticated responses. Canisters can store data in certified variables while processing update calls. Certified variables allow query calls to return values that can still be authenticated, ensuring that the data returned to the user is trustworthy.

Certified Variables:

• Used to store data that can be authenticated even when processed by a query call.
• These variables are updated during update calls and are included in the certified state.
• By leveraging certified variables, query calls can provide fast responses while maintaining data integrity.
  

Choosing Between Query Calls and Update Calls

As a developer building on the Internet Computer, understanding when to use query calls versus update calls is critical to optimizing your application’s performance and security.

• For operations requiring high throughput and low latency, such as retrieving data for front-end displays, query calls are ideal.
• For operations involving permanent state changes, such as financial transactions or critical user actions, update calls are necessary to ensure consensus and data integrity.

By carefully architecting the use of both query and update calls, developers can build scalable, secure, and responsive applications that make the most of the Internet Computer’s capabilities.

Conclusion

The distinction between query calls and update calls is a fundamental aspect of the Internet Computer’s design, allowing developers to optimize for both performance and security based on the requirements of their applications. While query calls offer a low-latency solution for data retrieval, update calls ensure that critical changes to the state of canisters are processed securely through consensus. Developers can create robust dApps that offer both speed and trustworthiness to users by balancing the use of these calls and utilizing certified variables,

Article by: Mana Lamja