Glossary and References

Glossary

Terms used throughout this documentation, defined without assuming a distributed systems background.

Attestation A cryptographic report produced by a processor stating what is running inside a protected environment, so a remote party can verify it before sending data. See Trust and Security Model.

BFT — Byzantine fault tolerance The property that a system keeps producing correct results even when some participants fail arbitrarily, including acting maliciously. Requires 3f + 1 participants to tolerate f faulty ones — the reason an engine has a minimum of four nodes.

Canister The unit of deployment: code plus its own persistent state, compiled to WebAssembly and replicated across every node of an engine. Closest conventional analogue is a container that carries its own database inside it and cannot be restarted from a clean slate.

Chain-key signatures A mechanism by which a canister signs transactions for external blockchains natively, without any node holding the private key. Served by ICP mainnet rather than by the engine; see Cloud Engine.

Cloud Engine A private, replicated computer running the Internet Computer Protocol, built from a minimum of four nodes and operated for a single client. See Cloud Engine.

Consensus The protocol by which the nodes of an engine agree on the order of operations before executing them. It is why an update call takes about two seconds regardless of hardware.

Cycles The unit in which computation is metered on the public Internet Computer. A Cloud Engine has no per-message cycle accounting — the engine is paid for as a unit. See Development.

Determinism The property that the same input produces the same output on every machine. Required because every node executes the same code independently and results must match. The constraint that most affects how application code is written.

GuestOS The operating system image a node runs the engine in, as a guest virtual machine. A version becomes installable only when on-chain governance elects it, naming it by Git revision and image checksum; builds are reproducible from public source and the registry records the image hash and launch measurement. See Trust and Security Model.

HTTPS outcall The protocol mechanism by which a canister calls an external HTTP API. Because every node makes the call and all must agree on the response, varying fields must be stripped before agreement. See Integration Patterns.

ICP — Internet Computer Protocol The protocol a Cloud Engine runs. The public Internet Computer is one deployment of it; a Cloud Engine is a private one. Software written for either runs on the other.

NNS — Network Nervous System The on-chain governance system of the public Internet Computer. Today it defines the node provider requirements that Swiss Subnet’s node providers are contractually bound to. See Swiss Subnet and Cloud Engines.

Node One physical machine in an engine, holding a full copy of state and executing every instruction independently of the others.

Orthogonal persistence State held in ordinary program variables that survives upgrades automatically, without an external database or schema migration.

Principal The unit of identity, derived from a public key. A caller signs its requests and the engine identifies it by the resulting principal. There is no account and no password. See Interfaces.

Query call A read that executes on a single node without consensus. Fast — around 100 ms — but not threshold-signed by default, so it does not carry the verifiability guarantee.

Replication factor The number of nodes holding a complete copy of state. Determines both fault tolerance and the cost of every write.

SEV-SNP — Secure Encrypted Virtualization, Secure Nested Paging An AMD processor feature that encrypts a virtual machine’s memory so the hypervisor and the machine’s operator cannot read it, and that can attest what is running inside. The basis for the claim that a node operator cannot read data in use. Enabled for an engine alone on its node; not yet available where engines share one — see Trust and Security Model.

Canister Snapshot A point-in-time copy of a canister’s code and state, held by the engine and restorable by whoever controls the canister. The reason deleted data stays recoverable for a short period; see Data Storage and Locations.

State certification The threshold signature the nodes of an engine jointly place on every response, verifiable against one public key, where no individual node holds the signing key. The mechanism behind verifiability, and in production on every engine. Distinct from chain-key signing, which is served by ICP mainnet; see Cloud Engine.

Update call A call that may modify state. Executes on every node through consensus, takes about two seconds, and returns a threshold-signed response.

vetKeys A protocol mechanism for distributed key management and encryption, so that keys need not be held by any single party.

WebAssembly (Wasm) The compilation target for canisters. The reason several source languages can be used and the reason module size limits are expressed in MiB of bytecode.

References

Primary sources only. Retrieved 2026-08-19 unless stated otherwise.

Source	Covers
ICP resource limits	Instruction, message, memory and module limits
Trusted Execution Environments	SEV-SNP on the Internet Computer
Node Provider Documentation	Node provider requirements as defined by the NNS
The Internet Computer for Geeks	Protocol design, consensus, execution
ICP developer documentation	SDK, canister development, deployment
Canister snapshots	Snapshot contents, limits, download format. Retrieved 2026-08-20
HTTPS outcalls security best practices	Outcall amplification, consensus over responses, transform functions. Retrieved 2026-08-20
Developer tools	icp-cli, PocketIC, SDKs and local development. Retrieved 2026-08-20
Protocol stack	Peer-to-peer layer, consensus, message routing, execution. Retrieved 2026-08-20
Cloud engines	The upstream definition of a cloud engine. Retrieved 2026-08-20