The Internet Computer: Redefining the Possibilities of Decentralized Computing (Edited)
Ivan Lele, Distributed LabTL;DR: You can host your Web3 application entirely on a blockchain platform with support for TLS, and the platform also offers seamless integration with both Bitcoin and chains that support ECDSA

Introduction
About the Internet Computer
The Internet Computer, also known as IC, is a blockchain-based technology that facilitates the deployment of canister smart contracts. Its primary objective is to provide a versatile World Computer that can supplant conventional IT infrastructure, and support a new class of Web3 applications and services that operate exclusively on the blockchain, without relying on traditional IT infrastructure. Additionally, it can act as a Web3 orchestrator by integrating with established blockchains.
Origins
The IC in question features an innovative design that represents a thorough overhaul of traditional blockchain architecture, leveraging contemporary cryptographic techniques, with roots dating back to 2015. The blockchain was developed by a research and development team within the cryptocurrency industry, employing esteemed cryptographers, computer science researchers, and engineers. The genesis of the blockchain took place in May 2021, marking its integration into the public internet. It was founded by the DFINITY foundation.
Motivations
It is a revolutionary decentralized computing network that enables the development of secure and scalable software systems with the potential to disrupt traditional centralized models of web hosting and cloud computing. It earned its name as the Internet Computer.
Technical capabilities
The IC Architecture
Nodes, which are hosted in independent data centers worldwide, ensure fault tolerance and decentralization for the Internet Computer Protocol. These nodes operate on standardized server hardware and are grouped into subnets. Each subnet contains its own blockchain that advances separately from other subnets, resulting in unparalleled scalability and performance in the blockchain domain. The Internet Computer Protocol connects all subnets to create the Internet Computer. It undergoes constant software updates to enhance performance, fix bugs, and introduce new features, and it can scale indefinitely by adding nodes or subnets and through hardware upgrades.
The P2P Communication
The P2P layer is the foundation of the Internet Computer protocol and facilitates secure and dependable communication between nodes on a subnet. It establishes a virtual network for broadcasting between nodes on the subnet, using the Internet Protocol (IP) connectivity. This makes the P2P layer the conduit for connecting all nodes on the subnet. Nodes can use P2P to broadcast network messages or artifacts, such as input to canisters submitted by users or protocol messages like block proposals. P2P guarantees that all artifacts are delivered to every node in the subnet, reflecting the asynchronous nature of communication networks.
Smart contract(Canisters)
A canister is akin to a wasm module instance that can be automatically executed by the network without requiring any manual intervention. In essence, it functions as a process within an operating system. The primary divergence between smart contracts deployed on the Internet Computer and those on conventional blockchains is the approach to data verification. The Internet Computer employs Chain Key Cryptography, which permits validation of any artifact authorized by any smart contract operating on any subnet blockchain using a single 48-byte public key for the entire Internet Computer. This is a marked departure from traditional blockchains, where the entire blockchain from its inception is necessary to authenticate the current state of affairs.
One noteworthy distinction between traditional actors and canisters is that canisters on the Internet Computer enable bidirectional message passing. The messages are categorized as requests and responses, with requests being answered and the Internet Computer keeping track of the responses' callbacks. In actor parlance, every actor has a mailing address that accepts messages. Similarly, a canister also has a mailing address, which resembles an IPv6 address. Although a canister's update throughput is restricted by the blockchain consensus and the single thread of execution, it can concurrently serve hundreds of queries, delivering throughput in the thousands of queries per second and latency in the milliseconds range. Canisters can be programmed using any language that compiles into wasm, such as Rust, Go, or Motoko (Solidity equivalent in the world of IC)
These characteristics endow canisters with a set of distinct attributes, including the ability to:
- Serve a user interface directly to any web browser
- Store gigabytes of memory at a minimal cost
- Carry out significant amounts of computation at a low expense
- Self-fund their own computation without requiring payment from users.
Government
IC is managed by The Network Nervous System (NNS), which serves as the decentralized authority on the entire IC framework, storing information on all nodes and their allocation to subnets. The NNS also maintains the ICP ledger, which records the accounts and transactions involving the ICP utility token.
Consensus
Each subnet of the Internet Computer operates as its own blockchain, advancing concurrently with other subnets by running its own instance of the IC core protocol stack, including consensus. The primary objective of consensus is to create blocks agreed upon by subnet nodes, resulting in an ordered sequence of messages for execution. This is critical to ensure that the top two layers of the protocol stack - message routing and execution - receive identical inputs in every round on each node.
The IC consensus protocol is designed to meet three main requirements: low latency, high throughput, and robustness, which entails graceful degradation of latency and throughput in the face of node or network failures. Chain-key cryptography is leveraged to achieve these goals.
The IC consensus protocol ensures cryptographic finality, rather than probabilistic finality, which is utilized in Bitcoin-like protocols where a block is considered final once an adequate number of blocks have been built on top of it in the blockchain. Probabilistic finality is not acceptable for the IC because it is a weaker notion of finality and significantly increases time to finality.
The IC consensus protocol achieves all these objectives by making minimal assumptions about the communication network. It does not assume any bounds on the time it takes for protocol messages to be delivered, thereby requiring an asynchronous network instead of a synchronous one. Synchrony is unrealistic for a globally distributed decentralized network, and consensus protocols that operate in a purely asynchronous setting usually have very poor latency. Therefore, the IC consensus protocol demands prompt delivery of protocol messages to make progress, while ensuring the protocol's correctness, regardless of message delays, as long as less than a third of the nodes in the subnet are faulty.
Further reading: IC Consensus
Web2 interaction
The passage describes how the canister HTTP outcalls feature is implemented on the Internet Computer replica. When a canister needs to make an outgoing HTTP request, it calls the management canister API using the http_request method. The request is then stored temporarily in the replicated state of the subnet. Periodically, an adapter at the networking layer in each replica fetches the pending HTTP outcalls from replicated state and executes the HTTP request by sending it to the target server. The corresponding HTTP response from the server is received by the adapter on each replica of the subnet and provided to a component in the replica process. An optional transformation function implemented as part of the canister is invoked on the respective response on each replica to transform the response. The transformed response is handed over to consensus on each replica, which agrees on a response if at least 2/3 of the replicas have the same response for the request as input. The management canister API provides the response or error back to the calling canister.
Below you can see an example of the Rust code that makes a HTTP request:

As you can see, there is a transform method that transforms the data before it gets to the nodes.
Threshold ECDSA
The Internet Computer's chain-key signatures toolbox includes a novel threshold ECDSA protocol where the private ECDSA key is held in a secret-shared manner by multiple parties, specifically the replicas of a threshold-ECDSA-enabled subnet. Signatures are computed using these secret shares without ever reconstructing the private key. Each replica holds a key share that alone provides no information about the key. At least one-third of the replicas are required to generate a threshold signature using their respective key shares. The chain-key ECDSA also comprises secure key distributed key generation and periodic key resharing protocols, which are crucial parts of the protocol. This makes chain-key ECDSA signatures much more powerful than any off-the-shelf threshold ECDSA protocol.
Each canister on any subnet of the Internet Computer can control a unique ECDSA key pair and request signatures with the corresponding private key to be computed. Only the eligible canister, which is the legitimate holder of the ECDSA key, can receive the signature. Canisters do not hold any private ECDSA keys or key shares themselves but delegate this to specific threshold-ECDSA-enabled subnets of the IC. The use of threshold cryptography enables the trust model of a blockchain to achieve functionalities that would be impossible with conventional cryptography alone.
Another one Rust code that can sign any data using the threshold ECDSA:

Real example
I have created a standard tokens Bridge for Ethreum-family networks. This bridge is fully hosted on-chain, ensuring security and transparency throughout the entire process. Below, you can see the demo:
Pitfalls
At the moment, the IC only allows HTTP requests to servers with an IPv6 address. Additionally, the backend that receives requests from canisters may need to be modified to handle the high volume of similar requests and perform actions multiple times. However, this can be resolved by adding a request counter, nonce, or hash.
It's important to know that the state of a canister won't be saved permanently on the blockchain, and once the local gas runs out, all data in the canister will be deleted.
While the Internet Computer is designed to be highly scalable, there may still be limitations to its capacity, especially as more users and applications join the network. You may experience delays or other issues if the network becomes overloaded.
To use the Internet Computer, you will need to acquire and use IC tokens, which are the platform's native currency. This means that your ability to use the platform may be limited by the availability and value of these tokens.
The Internet Computer is a relatively new platform, and it may not yet have extensive interoperability with other blockchain and decentralized systems. This could limit its potential applications and integration with other systems.
Performance
With low latency and high throughput, the Internet Computer stands out in terms of performance metrics. Unlike other blockchains, the ICP has no theoretical maximum TX/s and can scale its throughput horizontally by adding subnets. This scalability is similar to how cloud computing scales out with more machines. The platform enables smart contracts to communicate with each other seamlessly, even with an increasing number of subnets. As of the time of writing this article, the IC has achieved impressive performance data:
- 1.890.600.000 processed blocks
- 75 MB/s block throughput capacity
- 36 parallel subnet
- 241.500 ETH equivalent Tx/s
- $0.0000022 average cost/Tx
- 5.900 ICP Tx/s
- 3.45 TB smart contract memory
- $0.44/GB/month cost
Potential
The potential of the IC lies in its ability to bring about a new era of decentralized computing by enabling developers to build and deploy complex software systems without the need for traditional cloud infrastructure. This could lead to a more open, transparent, and democratic internet where users have more control over their data and applications.
However, like any new technology, the success of the IC depends on a number of factors, such as adoption, scalability, security, and regulatory environment.
In conclusion, while the future of the Internet Computer is uncertain, it has the potential to disrupt traditional cloud infrastructure and usher in a new era of decentralized computing. It will be interesting to see how it develops and evolves over time.
Conclusion
In conclusion, the Internet Computer is a novel blockchain technology that aims to bring the benefits of decentralization to the mainstream by providing a decentralized cloud computing platform. The Internet Computer allows developers to build and deploy applications without relying on centralized infrastructure providers, which can help increase the security, transparency, and trustworthiness of these applications. With its unique features such as smart contracts, canisters, and chain-key signatures, the Internet Computer is poised to become a major player in the blockchain space and beyond. Its ability to scale seamlessly and host web applications natively without the need for additional servers, along with its compatibility with Ethereum and other popular blockchains, makes it a promising platform for the future of decentralized computing.