Resource limits

Beginner

Concept

Overview

The Internet Computer uses WebAssembly as the platform for executing messages of smart contracts. Since WebAssembly is Turing-complete, it can express different kinds of computations including non-terminating computations. The Internet Computer protects against non-terminating computations by limiting the number of WebAssembly instructions and other resources per message execution. The limits depend on the message type as shown in the following table.

Resource constraints and limits

Message resource limits	Constraint
Message queue limit, messages per canister	500
Maximum ingress message payload	2MiB
Maximum cross-net inter-canister message payload	2MiB
Maximum same-subnet inter-canister request payload (may be deprecated at some point)	10MiB
Maximum response size (replicated execution)	2MiB
Maximum response size (non-replicated execution, i.e. in query calls)	3MiB

Instruction resource limits	Constraint
Instruction limit, instructions per update call/heartbeat/timer	40 Billion
Instruction limit, instructions per query call	5 Billion
Instruction limit, instructions per canister install/upgrade	200 Billion
Instruction limit, instructions per inspect_message	200 Million
Instruction limit, instructions per round	7 Billion

Subnet limits	Constraint
Subnet capacity (total memory available per subnet)	700GiB

Memory resource limits	Constraint
Wasm heap memory, per canister	4GiB
Wasm stable memory, per canister	400GiB
Wasm stable memory, data access per replicated message	2GiB
Wasm stable memory, data written per replicated message	2GiB
Wasm stable memory, data access per upgrade message	8GiB
Wasm stable memory, data written per upgrade message	8GiB
Wasm stable memory, data access per (replicated) query	1GiB
Wasm stable memory, data written per (replicated) query	1GiB

Wasm module limits	Constraint
Wasm total size, per canister	100MiB
Wasm code section, per canister	10MiB
Wasm custom sections, per subnet	2GiB
Wasm custom sections, per canister	1MiB
Wasm custom sections, sections per canister	16

Query call resource limits	Constraint
Query calls execution threads, per replica node	4
Query calls execution threads, per canister	2

Update call resource limits	Constraint
Update calls execution threads, per subnet	4
Update calls execution threads, per canister	1

Performance limits

The block rate varies from 0.75 blocks per second to 1.5 blocks per second depending on the subnet and the number of nodes in the subnet.

Up to 1000 messages can be included in a block. Since ICP decouples message reception from message execution, the messages included in a block are not guaranteed to be executed in the same block. Messages for different canisters maybe executed in parallel on multiple threads. ICP currently has 4 execution threads and each thread can execute up to 1000 messages. Another limiting factor in execution throughput is the number of executed Wasm instructions. ICP currently targets 2B instructions per block.

Additional notes

The expiration time of an ingress message is specified by the agent making the request, and can be up to 5 minutes.

The Internet Computer Protocol may reject WebAssembly modules for reasons such that:

• They declare more than 50_000 functions.
• They declare more than 1_000 globals.
• They declare a function with more than 1_000_000 Wasm instructions.
• They declare more than 16 exported custom sections (the custom section names with prefix icp:).
• The number of all exported functions called canister_update <name> or canister_query <name> exceeds 1_000.
• The sum of <name> lengths in all exported functions called canister_update <name> or canister_query <name> exceeds 20_000.
• The total size of the exported custom sections exceeds 1MiB.

More information regarding these restrictions can be found in the Internet Computer interface specification.