A Technical Overview of the Internet Computer

In the next step of our introduction to the Internet Computer, we can take a look at how the blockchain network’s technical infrastructure allows its canister smart contracts to scale without bound. We will also provide a high-level, technical overview of how the entire network functions. This includes in-depth technical explanations of the IC’s consensus protocols, its token economics, and its cryptography.

Let’s start our technical introduction to the Internet Computer with a look at its technical architecture. The Internet Computer Protocol (ICP) is the blockchain computer protocol that the IC is based on. The Internet Computer Network itself consists of different building blocks: Data centers that host specialized node machines can be found at the bottom of the hierarchy. These nodes are combined to form so-called subnets (i.e. a cluster of nodes). Canister smart contracts (i.e. interoperable compute units that developers can upload) are running on top of such subnets.

The Network Nervous System (NNS) is the governance system of the Internet Computer and is responsible for orchestrating the decentralized decision-making process that controls and manages the network. Its open governance system oversees – among other things – the permission to participate in the network. For example, one of its responsibilities is to induce independent data centers into the network. Data centers can initiate this process by applying to the NNS.

The Network Nervous System (NNS) manages the network’s token economics by generating new ICP tokens. These newly generated tokens are used to reward neuron holders (i.e. those who have staked ICP) that are participating in governance votes. The network is inflationary when new tokens are created.

cycles are burned
leading to network deflation

The token issuance is also used to reward independent node operators as well as governance participants. The network is inflationary when new tokens are created.

new ICP tokens are
generated, leading to inflation

Subnets are a critical component of the Internet Computer network.

A subnet consists of several node machines drawn by the NNS from different data centers. This ensures that the Internet Computer’s subnets are unstoppable, uncensorable, and tamper-proof by using Byzantine fault-tolerant cryptography.

The node machines of a subnet reach agreements on the state of the network and collaborate to symmetrically replicate the computations and data of software canisters.

The Network Nervous System is able to split and merge subnets should it be necessary to balance load across the network. This ensures that canisters will not experience any interruption in service, despite being spawned into a new subnet.

At the same time, subnets are transparent to developers, users, and software applications. This makes it possible to call the functions of a canister – if the identity of the canister and its function signature is known.

Developers that upload canisters need to specify which subnet type they want to target. There are the existing subnet types, aside from the subnet that hosts the NNS, which developers cannot choose from:

Each canister targets one of the three subnet types, which affects its capabilities. Depending on the chosen subnet type, the canister receives certain properties:

Canisters hosted on a data subnet are unable to make calls to other canisters or hold ICP tokens but can process calls. To give a canister the ability to call other canisters, it needs to be hosted on a system subnet. If the additional function of holding ICP token balances and sending cycles is needed, the canister has to be hosted on a fiduciary subnet.

For each subnet, there is a different level of fault tolerance:

Subnets derive some of their capabilities from the underlying fault tolerance, which will allow the NNS to repair broken subnets.

Developers can use their ICP tokens to convert them into cycles, allowing them to charge up their canister smart contracts. Whenever a canister performs a computation or stores memory, cycles are burned until the canister’s cycles are depleted. The network is deflationary when cycles are burned.

The WebAssembly bytecode inside a canister is capable of running on a WebAssembly virtual machine as well as the memory pages it runs within. In most cases, the WebAssembly bytecode is being created by compiling down compatible programming languages, such as Rust or Motoko.

The runtime that is incorporated in the bytecode helps developers to seamlessly interact with the API.

Function definitions have to specify how they can be called. Here is the example of an update call:

And here is the example of a query call:

There are two ways of invoking the functions of a canister on the Internet Computer. Developers can either use a query call or invoke the functions via an update call.

The completion time of update calls takes only two seconds as calls are running within a consistent and global ordering of calls. The mechanisms used for this operate in a fully deterministic execution environment that allows for concurrent execution of calls.

In contrast to update calls, query calls do not persist changes. Changes made to memory by a query call are discarded after the call has run. Query calls provide a lower level of security as they do not run on all nodes of a subnet. For this reason, query calls are performant and inexpensive, reaching a completion time of just a few milliseconds.

Canisters are software actors. As a result, there can only be a single thread of execution processing update calls inside a canister at any given time. Despite that, it is possible to interleave cross-canister update calls by default. However, the number of concurrent threads that are processing query calls inside a canister is not limited.

Persistence happens automatically on the Internet Computer. This frees developers from having to think about how data is persisted.

To better understand how internet services can use the Internet Computer to scale out, we are going to take a look at scalability next.

The upper bound of a canister’s capacity is limited. In the case of memory pages, it is limited to storing 4GB because of WebAssembly implementations.

To accomplish a functioning multi-canister architecture that scales out seamlessly, developers need to utilize both front-end as well as back-end canisters. This is because:

There are several features the Internet Computer provides to connect the end-users of a given application to front-end canisters. One feature allows developers to map domain names via the NNS to multiple front-end canisters. In this case, the Internet Computer returns the IP addresses of the replica nodes found in the closest proximity by looking at the totality of all replica nodes in all the subnets that are hosting the front-end canisters.

Following this approach reduces the network’s inherent latency as the query calls of an end-user will be executed on nearby replicas. This does not only improve the user experience but also provides developers with the benefits of edge computing without a CDN (Content Distribution Network).