{{#externalredirect: </nowiki>https://learn.internetcomputer.org/hc/en-us/articles/39320190051348-Performance}}

'''While having the security of Web3 blockchains, the performance of the Internet Computer (IC) is comparable to Web2 and cloud technology stacks. The IC far outperforms traditional blockchain protocols in efficiency.'''

==Performance goals==
A key objective of the Internet Computer is to provide a public compute layer that replaces traditional IT. A natural concern is that this will cause far less efficient computation.

The Internet Computer works very differently to other blockchains, and is powered by advanced new cryptography. Internally, the network is able to strictly limit the replication of data and computation, while still providing the liveness and security guarantees expected of a blockchain. It also has the ability to assign different “trust levels” to units of blockchain code that it hosts (“smart contracts”), which changes the level of replication applied to their computations and data. In its current state of development, it is already orders of magnitude more efficient than other blockchains, but it is designed to eventually become more efficient that traditional IT too.

Like all blockchains, the Internet Computer network directly applies replication, in combination with advanced cryptography, to create a tamperproof platform with better liveness guarantees than traditional IT. Yet, it also limits replication, while using the replication that occurs to drive efficiency, for example by scaling out “query” transactions.

For example, a large online service might be built on Amazon Web Services using a database in a master-slave configuration, Kubernetes instances of web workers, memcached instances for caching the results of database queries, and a CDN (content distribution network) that caches web content they serve on the edge of the network. This already creates a large amount of replication without creating a tamperproof platform, nor providing liveness guarantees. For example, each slave node of the database replicates its computations and data, and regular snapshots will also be taken as backups, data used by the web workers is replicated by the memcached instances, and each work will also cache data in its memory, while the product of web queries will be replicated all over the world on CDN nodes.

Because replication is at the core of the design of the Internet Computer, it can derive powerful security, liveness and other properties from replication, while also applying it more efficiently. For example, because the Internet Computer is a single logical blockchain and platform, as it grows larger, the utilization of the underlying node hardware upon which it runs can be made higher than, say, a standalone server machine in a data center. A key objective of the Internet Computer is, over time, to provide a public compute platform that provides a more power efficient way for the world to build systems and services.

== Performance experiments==
Scalability of the Internet Computer is facilitated by sharding the IC into subnet blockchains. Every subnet blockchain can process '''update calls''' (writes) from ingress messages independently from other subnets. The IC can scale up by adding more subnets at the cost of having more network traffic (as applications potentially need to communicate across subnets). In its current form, the IC should be able to scale out to hundreds of subnets.

'''Query calls''' (reads) can be processed locally by nodes in a subnet. The response to a query call can therefore have low latency since the query just needs a response by a single node and does not require inter-node communication or agreement. The more nodes a subnet has, the more query calls it can handle; and the more nodes the IC has, the more query calls it can handle.

== Test setup==

The experiments were run concurrently against all subnets other than the NNS and some of the most utilized application subnets to avoid disturbance of active IC users.
The IC has a set of boundary nodes that route calls to the core nodes that host the subnets. The experiments sent loads against the subnets directly and are did not route traffic through the boundary nodes. Boundary nodes have additional rate limiting, which is currently set slightly more conservative compared to what the IC can handle and running against the boundary nodes would therefore be unsuitable for performance evaluation.
The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if they would be used.

The experiment consisted of installing one counter canister in every subnet. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queried via query calls and incremented via update calls. The counter value is not using orthogonal persistence, so the overhead for the execution layer of the IC is minimal. Stressing the counter canister can be seen as a way to determine the system overhead or baseline performance.

== Measurements==

We evaluate the performance of the IC on a CD pipeline, which is running periodically. Those benchmarks target a single subnetwork with a configuration close to IC nodes on mainnet. We scale up those numbers to the current number of nodes and subnetworks on mainnet, which yields the following numbers:

Query calls: '''3,196,225''' queries/s (7,025 queries/s per node scaled up to 455 nodes in application subnetworks)

Update calls: '''33,749''' updates/s (1,023 updates/s per subnetwork scaled up to 33 application subnetworks)

Above calculation is based on measurements from: '''2023-11-22'''.

All benchmark run against a small number of canister that simply return, as the goal of this benchmark is to measure throughput of the messaging subsystem and to determine runtime overhead of message processing.

Canister code can be (almost) arbitrarily complex and therefor significantly lower the throughput if canister execution is becoming the bottleneck (and not messaging).

===Previous measurements===
The following measurements were made on '''May 24, 2022''', with 31 application subnets (having each 13 nodes) out of a total of 35 subnets (4 are system subnets such as the NNS and SNS subnets that have more nodes). Benchmarks where executed by simultaneously stressing all subnetworks on mainnet.

====Update calls====
The Internet Computer sustained more than '''20'841 updates/second''' calls to application canisters for a period of four minutes (averaging '''672 updates/second''' per subnet).
The update calls measured here are triggered from ingress messages sent from outside the IC.

====Query calls====
Arguably more important are query calls, since they contribute to more than 90% of the traffic observed on the IC.
The Internet Computer processed '''1'125'982 queries per second''' calls to application canisters (averaging '''2'792 queries per second''' per node).
During the experiment each load is increased incrementally and run for a period of 5 minutes.

==Conclusion and next steps==
The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:
*More subnets: This will immediately increase the query and update call throughput. While adding subnets might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnets.
*Performance improvements: Performance can also be improved by better single machine, network and consensus performance tuning. Increasing the performance by at least an order of magnitude is plausible.

==See Also==
*'''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''
*[https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef The Internet Computer’s Transaction Speed and Finality Outpace Other L1 Blockchains]
*[https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 Internet Computer Performance - Dec 1, 2021 Load testing]
===References===
<references />

Internet Computer performance

2025-08-25T14:17:24Z

Bjoern.tackmann:

<nowiki>{{#externalredirect: </nowiki>https://learn.internetcomputer.org/hc/en-us/articles/39320190051348-Performance<nowiki/>}}

'''While having the security of Web3 blockchains, the performance of the Internet Computer (IC) is comparable to Web2 and cloud technology stacks. The IC far outperforms traditional blockchain protocols in efficiency.'''

==Performance goals==
A key objective of the Internet Computer is to provide a public compute layer that replaces traditional IT. A natural concern is that this will cause far less efficient computation.

The Internet Computer works very differently to other blockchains, and is powered by advanced new cryptography. Internally, the network is able to strictly limit the replication of data and computation, while still providing the liveness and security guarantees expected of a blockchain. It also has the ability to assign different “trust levels” to units of blockchain code that it hosts (“smart contracts”), which changes the level of replication applied to their computations and data. In its current state of development, it is already orders of magnitude more efficient than other blockchains, but it is designed to eventually become more efficient that traditional IT too.

Like all blockchains, the Internet Computer network directly applies replication, in combination with advanced cryptography, to create a tamperproof platform with better liveness guarantees than traditional IT. Yet, it also limits replication, while using the replication that occurs to drive efficiency, for example by scaling out “query” transactions.

For example, a large online service might be built on Amazon Web Services using a database in a master-slave configuration, Kubernetes instances of web workers, memcached instances for caching the results of database queries, and a CDN (content distribution network) that caches web content they serve on the edge of the network. This already creates a large amount of replication without creating a tamperproof platform, nor providing liveness guarantees. For example, each slave node of the database replicates its computations and data, and regular snapshots will also be taken as backups, data used by the web workers is replicated by the memcached instances, and each work will also cache data in its memory, while the product of web queries will be replicated all over the world on CDN nodes.

Because replication is at the core of the design of the Internet Computer, it can derive powerful security, liveness and other properties from replication, while also applying it more efficiently. For example, because the Internet Computer is a single logical blockchain and platform, as it grows larger, the utilization of the underlying node hardware upon which it runs can be made higher than, say, a standalone server machine in a data center. A key objective of the Internet Computer is, over time, to provide a public compute platform that provides a more power efficient way for the world to build systems and services.

== Performance experiments==
Scalability of the Internet Computer is facilitated by sharding the IC into subnet blockchains. Every subnet blockchain can process '''update calls''' (writes) from ingress messages independently from other subnets. The IC can scale up by adding more subnets at the cost of having more network traffic (as applications potentially need to communicate across subnets). In its current form, the IC should be able to scale out to hundreds of subnets.

'''Query calls''' (reads) can be processed locally by nodes in a subnet. The response to a query call can therefore have low latency since the query just needs a response by a single node and does not require inter-node communication or agreement. The more nodes a subnet has, the more query calls it can handle; and the more nodes the IC has, the more query calls it can handle.

== Test setup==

The experiments were run concurrently against all subnets other than the NNS and some of the most utilized application subnets to avoid disturbance of active IC users.
The IC has a set of boundary nodes that route calls to the core nodes that host the subnets. The experiments sent loads against the subnets directly and are did not route traffic through the boundary nodes. Boundary nodes have additional rate limiting, which is currently set slightly more conservative compared to what the IC can handle and running against the boundary nodes would therefore be unsuitable for performance evaluation.
The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if they would be used.

The experiment consisted of installing one counter canister in every subnet. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queried via query calls and incremented via update calls. The counter value is not using orthogonal persistence, so the overhead for the execution layer of the IC is minimal. Stressing the counter canister can be seen as a way to determine the system overhead or baseline performance.

== Measurements==

We evaluate the performance of the IC on a CD pipeline, which is running periodically. Those benchmarks target a single subnetwork with a configuration close to IC nodes on mainnet. We scale up those numbers to the current number of nodes and subnetworks on mainnet, which yields the following numbers:

Query calls: '''3,196,225''' queries/s (7,025 queries/s per node scaled up to 455 nodes in application subnetworks)

Update calls: '''33,749''' updates/s (1,023 updates/s per subnetwork scaled up to 33 application subnetworks)

Above calculation is based on measurements from: '''2023-11-22'''.

All benchmark run against a small number of canister that simply return, as the goal of this benchmark is to measure throughput of the messaging subsystem and to determine runtime overhead of message processing.

Canister code can be (almost) arbitrarily complex and therefor significantly lower the throughput if canister execution is becoming the bottleneck (and not messaging).

===Previous measurements===
The following measurements were made on '''May 24, 2022''', with 31 application subnets (having each 13 nodes) out of a total of 35 subnets (4 are system subnets such as the NNS and SNS subnets that have more nodes). Benchmarks where executed by simultaneously stressing all subnetworks on mainnet.

====Update calls====
The Internet Computer sustained more than '''20'841 updates/second''' calls to application canisters for a period of four minutes (averaging '''672 updates/second''' per subnet).
The update calls measured here are triggered from ingress messages sent from outside the IC.

====Query calls====
Arguably more important are query calls, since they contribute to more than 90% of the traffic observed on the IC.
The Internet Computer processed '''1'125'982 queries per second''' calls to application canisters (averaging '''2'792 queries per second''' per node).
During the experiment each load is increased incrementally and run for a period of 5 minutes.

==Conclusion and next steps==
The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:
*More subnets: This will immediately increase the query and update call throughput. While adding subnets might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnets.
*Performance improvements: Performance can also be improved by better single machine, network and consensus performance tuning. Increasing the performance by at least an order of magnitude is plausible.

==See Also==
*'''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''
*[https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef The Internet Computer’s Transaction Speed and Finality Outpace Other L1 Blockchains]
*[https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 Internet Computer Performance - Dec 1, 2021 Load testing]
===References===
<references />

Internet Computer performance

2025-08-25T14:16:53Z

Bjoern.tackmann:

Energy Consumption and Sustainability

2025-08-25T13:07:32Z

Bjoern.tackmann: Remove link to page we want to drop

The Internet Computer and its community are committed to sustatinability. Sustainability is one of the core design goals of the IC, together with the goals of scalability, usability, storage, and security built into the IC by default.

== Sustainability timeline ==

'''Earth Day 2022.''' On April 22nd 2022 there was a [https://dashboard.internetcomputer.org/proposal/55487 motion proposal] requesting to measure the sustainability of the IC. The motion proposal passed and was assigned to DFINITY to work on producing measurements.

''' June 2nd 2022''' [https://medium.com/@orlhut/internet-computer-footprint-5d612eefa1b Carbon Crowd proposed] to compute the carbon footprint of the Internet Computer. Requiring each other's skills, Carbon Crowd and DFINITY joined efforts to capture energy consumption readings from nodes running the IC, and to compute the carbon footprint under a methodology developed by Carbon Crowd and audited by Fingreen AI.

''' October 5th 2022''' This resulted in a report, jointly published [https://carboncrowd.io/ Carbon Crowd] and the DFINITY Foundation and was on [https://medium.com/dfinity/internet-computer-footprint-assessing-ic-energy-consumption-and-sustainability-4a4dcf10707a Medium].

''' April 2023 ''' Real-time analytics were exposed in the IC Dashboard API. Carbon Crowd launched a sustainability dashboard visualising the carbon footprint of the Internet Computer. Jointly, DFINITY and Carbon Crowd launched the Proof of Green initiative to bring transparency to the reporting of energy consumption and carbon emissions.

'''May 2023''' Real-time analytics were shown on the [https://dashboard.internetcomputer.org/ IC Dashboard front page] as well as on individual node pages, for which readings exist, see [https://dashboard.internetcomputer.org/node/2cdp4-vnes7-h3luw-mmiz5-p37op-a5hti-lb2om-3ttdc-lqlu7-cinvr-4ae here] for an example.

== Carbon footprint methodology ==
To measure the carbon footprint of the IC, the energy consumption of some nodes is first measured, then extrapolated the average to all nodes, then weight the node average consumption by the emissions factor of the node's region. This methodology is put forward by [https://carboncrowd.io/ Carbon Crowd], and audited by Fingreen AI. The Internet Computer has 275 tonnes of CO2 emissions per year.

== Energy consumption ==

The energy consumption of the Internet computer is approximated by measuring nodes on various subnets, averaging them, and extrapolating to all nodes.

The average energy consumption of an Internet Computer node is 0.232KWh.

Assuming a power usage effectiveness (PUE) [https://en.wikipedia.org/wiki/Power_usage_effectiveness 1], [https://energyinnovation.org/2020/03/17/how-much-energy-do-data-centers-really-use/ 2], of 2.33 that leads to a total power consumption of 1631.0 W including cooling and other data center operations costs.

Given a total of 518 nodes and 11 boundary nodes in mainnet, resulting in a worst case of 862799W to operate all IC nodes for mainnet (including also system subnets).
This is a worst case analysis for power consumption of nodes as it is expected for them to throttle when not fully utilized and thereby reducing power consumption.
Given the maximum rate of updates and queries that are currently supported in the IC, one update call would consume 38.95 J (Joules) and one query call 0.59 J. These figures are for a hypothetically fully utilized IC.
With the current approximate rate of 3300 transactions/s, the IC uses 261.45J per transaction.

In the future, the energy consumption will be much lower as the overhead of the system subnets will be comparatively smaller, boundary nodes will contain caching, and the replica software much more optimised.

= Putting this in context =
Even with conservative estimations, the energy consumption of the Internet Computer is substantially lower than competing blockchain projects, but also existing (highly optimized) web2 tech. See the table below to put IC performance in perspective. Correct as of May 2022.

{| class="wikitable"
|+ Energy consumption comparison
|-
! Source !! Cost (measured in Joules (J))
|-
| One Internet Computer transaction || 261 J
|-
| One Solana transaction || 1'837 J<ref>https://solana.com/news/solana-energy-usage-report-november-2021#ref1</ref>
|-
| One Ethereum 2 transaction || 126'000 J<ref>https://blog.ethereum.org/2021/05/18/country-power-no-more/</ref>
|-
| One Cardano transaction || 1'972'440 J<ref>https://www.trgdatacenters.com/most-environment-friendly-cryptocurrencies/</ref>
|-
| One Ethereum transaction || 692'820'000 J<ref>https://digiconomist.net/ethereum-energy-consumption/</ref>
|-
| One Bitcoin transaction || 6'995'592'000 J<ref>https://digiconomist.net/bitcoin-energy-consumption</ref>
|}

Introduction to ICP

2025-08-25T13:06:03Z

Bjoern.tackmann:

{{#externalredirect: https://internetcomputer.org/docs/building-apps/essentials/network-overview}}

==Introduction==

The Internet Computer is a general-purpose blockchain that hosts [[canister smart contract]]s. It is designed to [[Replace traditional IT with a World Computer|provide a World Computer that can replace traditional IT]] and host a new generation of [[Web3:_The_bull_case_for_the_Internet_Computer|Web3]] services and applications that run solely from the blockchain, without the need for traditional IT. It can also play the role of Web3 orchestrator, by interacting with traditional blockchains.

It has a completely unique design that reflects a ground-up rethink of blockchain architecture and the application of modern cryptography, [https://web.archive.org/web/20150914013643/http://dfinity.io/ which can be traced back to 2015]. It was built by the largest [https://dfinity.org/team ongoing R&D effort in crypto], which has employed many notable cryptographers, computer science researchers and engineers. The blockchain underwent genesis in May 2021 and became part of the public internet.

The Internet Computer blockchain nodes run on a [[sovereign network]] with [[Proof of Useful Work | proof of useful work]] consensus. The protocols leverage novel [[chain key cryptography]] to combine multiple [[Limitless_Scaling#Subnet Architecture|subnet blockchains]] into a single blockchain. This allows it to [https://en.wikipedia.org/wiki/Scalability#Horizontal_(scale_out)_and_vertical_scaling_(scale_up) horizontally scale] the total volume of hosted [[canister smart contract]], and their computations and data, without limit. These smart contracts run at web speed, and with web-levels of efficiency, and uniquely, thanks to the blockchain architecture enabled by chain key crypto, can process HTTP requests and directly and securely serve interactive web experiences to the end-users of web3 services, without need for trusted intermediaries (whereas on other blockchains, the web experience users interact with is generally built on centralized, insecure and trusted servers or cloud computing services).

Through these kinds of unique capabilities, the Internet Computer provides a platform that can be used to build mass market web3 services that run 100% on-chain, without any need for traditional IT, such as web servers and databases running on cloud computing services. The longer-term objective is that the Internet Computer will completely replace traditional IT, creating a ''blockchain singularity'', in which everything runs fully on-chain in powerful new forms where it is unstoppable and cannot be hacked.

The development of the Internet Computer has heralded numerous notable technological developments, such as [[chain key cryptography]] and programming languages such as [https://wiki.internetcomputer.org/wiki/Motoko Motoko]. In another notable advance, the Internet Computer hosts an advanced [https://en.wikipedia.org/wiki/Decentralized_autonomous_organization DAO] within its protocols, called the [[Network Nervous System]], which provides the community with direct control over network governance, and can upgrade the protocol running on its network nodes, without requiring the network to fork. The network's utility token is [[ICP token]].

A recent new technological advance has extended the Internet Computer's [[chain key cryptography]] protocols. This has enabled smart contracts hosted on the Internet Computer to directly interact with other blockchains, without need for dangerous centrally-controlled bridges or wrapping (see [[trustless multi-chain web3 using the IC]], and [[Extend Bitcoin, Ethereum and other blockchains|extending Bitcoin, Ethereum and other blockchains]]).

For example, a canister smart contract hosted on the Internet Computer can create bitcoin addresses, and directly send and receive bitcoins on the Bitcoin ledger as though it were hosted by the Bitcoin network itself. This is possible because chain key crypto enables blockchains to create public "chain keys", for which their nodes can create corresponding signatures. Recent work has now made it possible to create ECDSA chain keys. Since [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] is the signature scheme used by most other blockchains, this means the Internet Computer can create TX on other blockchains.

Future work will enable its smart contracts to directly interact with other important blockchains such as [https://ethereum.org/en/ Ethereum]. This also leverages other important features such as [[HTTPS outcalls]]. As a consequence, many believe that the Internet Computer will play the role of an orchestration layer that combines different blockchains in the web3 environment, and helps combine them with off-chain services and systems, such as Web 2.0 services and enterprise systems, in a trustless way.

===Why build the Internet Computer?===

For end-users, accessing Internet Computer-based services is largely transparent, the experience of interacting with a decentralized application is the same as it is on a public or private cloud.

For the people creating and managing those Internet Computer-based services, however, the Internet Computer eliminates many of the costs, risks, and complexities associated with developing and deploying modern applications and microservices. In addition, its secure protocol guarantees reliable message delivery, transparent accountability, and resilience without relying on firewalls, backup facilities, load balancing services, or failover orchestration.

In some ways, building the Internet Computer is about restoring the Internet to its open, innovative, and creative roots. To focus on a few specific examples, the Internet Computer does the following:

* Supports interoperability, shared functions, permanent APIs, and ownerless applications which reduces platform risk and encourages innovation and collaboration.
* Persists data automatically in memory which eliminates the need for database servers and storage management, improves computational efficiency, and simplifies software development.
* Simplifies the technology stack that IT organizations need to integrate and manage which improves operational efficiency.

See also [[Web3: The bull case for the Internet Computer]].

==Key Concepts==

===Smart Contracts & Dapps===
ICP was designed to improve the user experience of interacting with [[Canister smart contract | smart contracts]] and dapps running on a blockchain. Smart contracts Dapps on the IC are able to serve web content, allowing users to interact with the dapps through their browser. Dapps themselves are run by canisters (dapps/smart contracts) on the IC with the robustness and security guarantees it affords.
Developers create dapps in programming languages such as Rust or Motoko, compile them to WebAssembly byte code, and deploy the WebAssembly modules into canisters on the Internet Computer. A canister comprises a WebAssembly module and persisted memory.
For more information or to start using dapps on the IC see:
* [[Index of dapps on the Internet Computer ecosystem|Index of dapps on the IC]]
* This [https://medium.com/dfinity/internet-computer-pioneers-early-adopters-describe-launching-dapps-on-the-blockchain-e979281f19b8 Medium post] where early adopters describe their experience of launching dapps on the IC.

===Tokens===
The Internet Computer uses a utility token ICP. Holders can stake ICP, allowing them to participate in the governance of the Internet Computer and earn voting rewards. ICP can also be converted into cycles and used to power computation, communication and storage costs of canisters. The blockchain incorporates a "reverse gas" model, in which smart contracts pay for their own computation, and must be pre-charged with cycles to run in much the same way an electric car must be pre-charged with electricity to drive. This ensures that end-users of dapps, systems and services can interact with them over the web without needing tokens to pay for the computations that they initiate. The Internet Computer maintains a floating conversion rate so that 1 Trillion cycles costs approximately 1 IMF SDR in ICP.

===Network Nervous System===

The [[Network Nervous System]] (NNS) is the control center where the Internet Computer’s nodes and subnets are organized, tracked, and managed. The NNS is an automated in-protocol governance system that makes the network self-directed. Unlike Bitcoin or Ethereum, this means the Internet Computer blockchain can update itself via community-led proposals so the community controls the network.

Advantages of the NNS:
* Seamless community-driven evolution and governance without disruptive hard forks
* Gives control of the network to token holders as well as node providers (in Bitcoin or Ethereum, only nodes affect the upgrades of the network)
* Accelerates the number of improvements or updates to the network. In 2021, the Internet Computer had dozens of updates, giving the IC very fast development iterations while also being decentralized.

==Internet Identity==
[[Internet_Identity_technical_overview|Internet Identity]] is a blockchain authentication system that enables you to sign in securely and pseudonymously to dapps on the Internet Computer. This makes logging into dapps easy and safe for consumers.

Users can create identity "anchors" to which they assign compatible cryptographically enabled devices, such as the fingerprint sensor on a laptop, the face ID system on a phone, or a portable HSM, such as a YubiKey or Ledger wallet. Thereafter, they can signup and authenticate to any dapp running on the Internet Computer using any of the devices they have assigned to their anchor. This provides a high level of convenience, allowing users to authenticate to dapps they are interested in with a very low level of friction, while benefiting from the highest level of cryptographic security, but without the need to directly manage or handle cryptographic key material themselves, which prevents mistakes and the theft of their key material. The system is anonymizing towards dapps, and whenever an anchor is used to interact with a dapp, the dapp sees a specially generated pseudonym, which prevents users being tracked across the various dapps they use. A user can create as many identity anchors as they wish.

Unlike most authentication methods, Internet Identity does not require users to set and manage passwords or provide any personal identifying information to dapps or to Internet Identity.

To read more about Internet Identity, or to generate an anchor, see:
* The [https://identity.ic0.app/ Internet Identity dapp].
* [[Internet_Identity_for_dapp_users|Internet Identity for dapp users]].
* [[Internet_Identity_technical_overview|Internet Identity technical overview]].
* The Internet Identity [https://smartcontracts.org/docs/ic-identity-guide/what-is-ic-identity.html developer documentation].

==Key Capabilities==

===Web speed===

[[Canister Smart Contracts | Smart contracts]] on ICP are fast and performant to allow developers to build anything. The design goal is that developers can build consumer-facing experiences that are as fast as they would expect from centralized servers. Dapp developers do not need to choose between "smart contracts" and "fast." In short, dapp users experience is so fast that users should not notice if their web experience is running on a blockchain or centralized provider.

From a blockchain POV, Internet Computer Performance performance tests shows the IC latency at 200 milliseconds for query calls (reads) and 2 seconds for update calls (writes). As of December 1, 2021, The Internet Computer can handle 250,000 queries per second and 11,500 update calls per second.

===Low costs===

====Low direct costs====
Unlike most blockchains, the efficiency and costs of the Internet Computer approaches the traditional IT stack so its is economically feasible to host dapps with lots of data and content.

For comparison:

{| class="wikitable"
|-
! Blockchain !! Storage Costs
|-
| Ethereum || $350,000,000 USD per GB per year
|-
| Internet Computer || $5 USD per GB per year
|}

====Low indirect costs====

Smart contracts as "secure-by-default" that comes with data replication removes a lot of software complexity that developers do not need to build. The design intent of the IC is to make development and deployment simple to reduce the time necessary to build and maintain software compared to traditional systems.

===Low energy consumption===

The Internet Computer and its community are committed to sustainability. Sustainability is one of the core design goals of the IC, together with the goals of scalability, usability, storage, and security built into the IC by default.

See current stats and comparisons here: [[Energy Consumption and Sustainability]]

===Network scales without limit===

Most blockchains have transactions limits baked into the protocol (e.g. adding more servers to Bitcoin does not increase its transaction volume) and need cumbersome workarounds to address scaling. The Internet Computer can process unbounded volumes of smart contract data and computation natively because it can grow in capacity by adding more nodes. That is how the network went from 19 blocks per second in July 2021 to 30 blocks per second by December 2021.

See Internet Computer Dashboard: https://dashboard.internetcomputer.org/

===Network scaling is transparent to systems===

Network scaling is transparent to smart contract code which means that dapp developers do not need to worry about details about the network in order for their dapps to operate or scale. For example:

<blockquote>
Although subnets are the fundamental building blocks of the overall Internet Computer network, they’re transparent to users and software. Users and canister software only need to know the identity of a canister to call the functions that it offers.
</blockquote>

Source: https://medium.com/dfinity/a-technical-overview-of-the-internet-computer-f57c62abc20f

===Web serving===

====Dapp code hosted and executed on-chain====
Smart contracts on the Internet Computer serve web content directly to users. This is a distinguishing feature, on other blockchains a small part of the dapp logic runs in a smart contract, but the actual consumer-facing web or interface is hosted on a centralized cloud provider (e.g. AWS) instead of being served directly from the blockchain.

The Internet Computer serving dapps whose code is hosted and executed entirely on-chain unlocks the Web3 potential of smart contracts.

====Reverse Gas Model (AKA "canister pays")====
In dapps built on Ethereum (as an example), users require a wallet or tokens to use it. This slows down adoption of dapps because using a dapp is not as simple as clicking on a website link; it requires users to buy tokens, install browser plugins, etc. Internet Computer dapps have he "Reverse Gas model" where users can interact with a dapp without having to pay in tokens since the canister can store a certain amount of [[cycles]] and pay for the user.

As an example, the Motoko Playground dapp is hosted and executed entirely on-chain and it does not require visitors to pay for the computation: https://m7sm4-2iaaa-aaaab-qabra-cai.raw.ic0.app/

====Processing HTTP requests====
Blockchains differ in their processing of computation from regular web servers, which makes serving web a difficult task. To overcome this, the Internet Computer introduces something called [https://wiki.internetcomputer.org/wiki/Boundary_Nodes boundary nodes]. These nodes act as a layer that translates HTTP requests from users to messages that can be processed by smart contracts running on the Internet Computer. This allows users to update the state of the blockchain simply by interacting with a browser.

===Novel “canister” smart contract framework===

Smart contracts have proven to be powerful new types of software programs because of their tamperproof nature. They can host financial contracts and systems with billions of dollars in value. However, as the scope of smart contracts increase, performance really matters. Building an "airbnb clone" entirely with Ethereum smart contracts would be impractical due to performance bottlenecks on individual smart contracts, but it is easy with the Internet Computer's canisters (dapps/smart contracts). A rough but helpful analogy may be "you can build complex calculations and logic with an excel spreadsheet, but you would not build Twitter by cobbling up many spreadsheets."

Attributes that make Internet Computer smart contracts powerful ways of building dapps:
* Orthogonal persistence (data lives in persistent memory pages) making managing data much easier
* [[Actor model]] gives dapps a time-tested model for concurrency that scales (deterministic parallelism, internally and externally)
* Dapps get access to system APIs uncommon in Ethereum smart contracts (but common tools in centralized solutions) such as public randomness
* Integration with other blockchains e.g. canisters will be able to have Bitcoin addresses in the future

===Service Nervous System (SNS) DAO framework for dapps===

The Internet Computer’s SNS feature will allow developers to create decentralized, token-based governance systems for their dapps.

This unlocks a few possibilities:
* An advanced DAO can take control of a dapp
* Dapps run under the control of a community (full decentralization)
* Dapps run as extensions of the blockchain (microeconomy with macroeconomy)
* Dapps can raise funds into the SNS; funds controlled by community

The Internet Computer is a “general-purpose” blockchain that provides a public platform for hosting tokens and decentralized applications (dapps). It acts as a complete technology stack, such that systems and services can be built that run entirely from the blockchain.

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''
* [https://www.youtube.com/watch?v=XgsOKP224Zw Overview of the Internet Computer] video on YouTube.
* The [https://internetcomputer.org/howitworks/ How it Works] page where you can get an overview of different building blocks and features of the internet computer.

Introduction to the Internet Computer for dapp users

2025-08-25T13:05:07Z

Bjoern.tackmann: Remove link to page we want to drop

As an end user, you interact with decentralized applications (dapps) running on the Internet Computer. Here is an [[index of dapps on the Internet Computer]] that are available to users.

The Internet Computer was designed to improve the user experience of smart contracts and dapps running on a blockchain. Dapps on the IC are able to serve web content, allowing you to interact with the dapps through your browser. The dapps themselves are run by [[canisters (dapps/smart contracts)]] on the IC with the robustness and security guarantees it affords.

== Compared to other blockchains ==
Compared to other smart contract blokchains like Ethereum, the Internet Computer offers the following immediate benefits to dapp users:

=== Direct web experience ===

Smart contracts on the Internet Computer securely serve web content directly to users. This is unique among blockchains since their typical dapps have a small part of the logic running in a smart contract, but the actual consumer-facing web or interface is hosted on a centralized cloud provider (e.g. AWS) instead of being served directly from the blockchain.

Example of the user experience, [https://h5aet-waaaa-aaaab-qaamq-cai.raw.ic0.app/post/5/introducing-dscvr-a-platform-that-belongs-to-its DSCVR] is a decentralized social media platform.

=== Users do not pay for access ===

Dapp users on Ethereum typically have to pay for using smart contracts. Besides the high fees, it also means that the users have to install plugins or other software (and pay via tokens). The IC's "canister pays model" means that dapp developers can pay for the storage and compute to create a frictionless user experience.

=== Fast user experience ===
Traditional smart contracts on other blockchains are slow and deliver a poor user experience. That is why many non-IC dapps use non-blockchain technologies for most of their "dapp." The IC's design goal is that developers can build consumer-facing experiences that are as fast as they would expect from centralized servers. Dapp developers on the IC do not need to choose between "smart contracts" and "fast."

Internet Computer performance tests showed the IC latency at 200 milliseconds for query calls (reads) and 2 seconds for update calls (writes). As of December 1, 2021, The Internet Computer can handle 250,000 queries per second and 11,000 update calls per second.

=== Internet Identity ===
Users can log in to most dapps on the IC with the [https://identity.ic0.app Internet Identity dapp]. [[Internet Identity for dapp users|Internet Identity]] is a blockchain authentication system that enables you to sign in securely and pseudonymously to dapps on the Internet Computer. This makes logging into dapps much easier and safer for dapp consumers. Besides providing a safer authentication experience, it is a service native to the IC so dapp developers who need authentication systems do not need to build their own.

==Compared to traditional platforms ==

===Decentralization===
Unlike applications hosted on centralized providers dapps on the Internet Computer allow end users to trust their data will be processed as intended.

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''
* [[Internet Computer vision]]

Introduction to the Internet Computer for dapp users

2025-08-25T12:30:15Z

Bjoern.tackmann: Removed link to a page we want to drop.

IC Smart Contract Memory

2024-04-19T13:34:06Z

Bjoern.tackmann: Update stable storage size

==Overall Architecture==
Canister smart contracts running on the Internet Computer (IC) store data just like most other programs would. To this end, the IC offers developers two types of memory where data can be stored, as depicted in Figure 1. The first is the regular '''heap memory''' that is exposed as the Web Assembly virtual machine heap. This should be used as a scratch, temporary memory that will be cleared after any canister upgrade. The second type of memory is the '''stable memory''', which is a larger memory (several orders of magnitude larger than the heap) used for permanent data storage.

[[File:Canister memory 2.png|alt=|512x512px|Figure 1. The two memories that can be accessed by the canister smart contracts.|center|frameless]]

==Orthogonal Persistence==

<syntaxhighlight lang="rust">
use ic_cdk_macros::{query, update};
use std::{cell::RefCell, collections::HashMap};

thread_local! {
static STORE: RefCell<HashMap<String, u64>> = RefCell::default();
}

#[update]
fn insert(key: String, value: u64) {
STORE.with(|store| store.borrow_mut().insert(key, value));
}

#[query]
fn lookup(key: String) -> u64 {
STORE.with(|store| *store.borrow().get(&key).unwrap_or(&0))
}
</syntaxhighlight>

The IC offers orthogonal persistence, an illusion given to programs to run forever: the heap of each canister is automatically preserved and restored the next time it is called. For that, the execution environment needs to determine efficiently which memory pages have been dirtied during message execution so that the modified pages are tracked and periodically persisted to disk. The listing above shows an example key-value store that illustrates how easy it is to use orthogonal persistence. The key-value store in this case is backed by a simple Rust HashMap stored on the heap by means of a thread-local variable. A RefCell is used to provide interior mutability. The example would also be possible without it, but mutating the thread-local variable would be unsafe in that case, as the Rust compiler cannot guarantee exclusive access to it.

==Main Memory==
Canisters running on the IC are programmed either in Rust or Motoko. The canisters are then compiled down to web assembly (Wasm). All the variables and data structures defined in these higher-level languages are then stored in the Wasm heap. All accesses to data structures and variables defined in the higher-level languages are then translated to memory copy operations in Wasm (e.g., load, store, copy, grow). The Wasm main memory (also known as heap memory) has a maximum size of 4GiB, due to the 32-bit address space that backs the Wasm programs. The memory pages are persistent between calls to a canister (changes made by calls that throw exceptions are reverted, so these pages never enter an inconsistent state). However, they are reset when the canister's software bytecode is upgraded. Typically, canisters that need to be upgraded, serialize data in main memory to stable memory to perform upgrades. More precisely, because possible changes in data structures and in Wasm (and high-level language) compilers, the heap layout might change (i.e., data structure layouts) which could leave the canister in an unusable state when a canister is upgraded. Thus, the heap should not be used as a permanent memory, but rather as a (faster) scratch, temporary memory.

==Stable Memory==
Next to the heap memory, canister developers can make use of the stable memory. This is an additional 64-bit addressable memory, which is currently 400GiB in size, with plans to increase it further in the future. Programs written in either Rust or Motoko need to explicitly use stable memory by using the API. This API offers primitives to copy memory back and forth between the Wasm heap and the stable memory. An alternative to using this lower level API directly is to use the stable structures API, which offers developers a collection of Rust data structures (e.g., B-trees) that operate directly in stable memory. Next to using the stable memory through stable data structures, a pattern often used by developers is to persist heap state between canister upgrades. This is achieved via serializing heap memory (or data structures), saving it to stable memory and applying the opposite operations (copying back and deserializing) when the upgrade is done.

==Behind the scenes: Implementation==
To serve memory contents to canister smart contracts, the IC software stack has the following design. First, it is important to mention that every N (consensus) rounds, canister state (heap, stable memory and other data structures) are checkpointed on disk. This is called a checkpoint file. Whenever a canister executes messages after a checkpoint, all its memory resides in the checkpoint file. Therefore, all memory requested will be served from the checkpoint file. Memory modifications (i.e., dirtied pages in terms of operating systems) are saved in a data structure called the heap delta. The following paragraphs describe how this design enables orthogonal persistence.

[[File:Screen_Shot_2022-12-01_at_14.30.58.png|512px|thumb|Figure 2. The memory faulting architecture which encompasses the checkpoint file and the heap delta.
.]]

Any implementation of orthogonal persistence has to solve two problems: (1) How to map the persisted memory into the Wasm memory?; and (2) How to keep track of all modifications in the Wasm memory so that they can be persisted later. Page protection is used to solve both problems.The entire address space of the Wasm memory is divided into 4KiB pages. All pages are initially marked as inaccessible using the page protection flags of the operating system.

The first memory access triggers a page fault, pauses the execution, and invokes a signal handler. The signal handler then fetches the corresponding page from persisted memory and marks the page as read-only. Subsequent read accesses to that page will succeed without any help from the signal handler. The first write access will trigger another page fault, however, and allow the signal handler to remember the page as modified and mark the page as readable and writable. All subsequent accesses to that page (both r/w) will succeed without invoking the signal handler.

Invoking a signal handler and changing page protection flags are expensive operations. Messages that read or write large chunks of memory cause a storm of such operations, degrading performance of the whole system. This can cause severe slowdowns under heavy load.

==Versioning: Heap Delta and Checkpoint Files==

A canister executes update messages sequentially, one by one. Queries, in contrast, can run concurrently to each other and to update messages. The support for concurrent execution makes the memory implementation much more challenging. Imagine that a canister is executing an update message at (blockchain) block height H. At the same time, there could still be a previous long-running query that started earlier, at block height H-K. This means the same canister can have multiple versions of its memory active at the same time; this is used for the parallel execution of queries and update calls.

A naive solution to this problem would be to copy the entire memory after each update message. That would be slow and use too much storage. Thus, our implementation takes a different route. It keeps track of the modified memory pages in a persistent tree data-structure called Heap Delta that is based on Fast Mergeable Integer Maps. At a regular interval (i.e., every N rounds), there is a checkpoint event that commits the modified pages into the checkpoint file after cloning the file to preserve its previous version. Figure 2 shows how the Wasm memory is constructed from Heap Delta and the checkpoint file.

====Memory-related performance optimizations====
'''Optimization 1:''' Memory mapping the checkpoint file pages.
This reduces the memory usage by sharing the pages between multiple calls being executed concurrently. This optimization also improves performance by avoiding page copying on read accesses. The number of signal handler invocations remains the same as before, so the issue of signal storms is still open after this optimization.

'''Optimization 2:''' Page Tracking in Queries
All pages dirtied by a query are discarded after execution. This means that the signal handler does not have to keep track of modified pages for query calls. As opposed to update calls, queries saw the introduction of a fast path that marks pages as readable and writable on the first access. This low-hanging fruit optimization made queries 1.5x-2x faster on average.

'''Optimization 3:''' Amortized Prefetching of Pages
The idea behind the most impactful optimization is simple: to reduce the number of page faults, more work is needed per signal handler invocation. Instead of fetching a single page at a time, the signal handler tries to speculatively prefetch pages. The right balance is required here because prefetching too many pages may degrade performance of small messages that access only a few pages. The optimization computes the largest contiguous range of accessed pages immediately preceding the current page. It uses the size of the range as a hint for prefetching more pages. This way the cost of prefetching is amortized by previously accessed pages. As a result, the optimization reduces the number of page faults in memory intensive messages by an order of magnitude.

A downside of this approach is that prefetched page content needs to be compared with previous content after message execution to determine if a page was modified instead of relying on tracking write accesses via signal handlers.

These optimizations bring substantial benefits for the performance of the memory faulting component of the execution environment. The optimizations allow the IC to improve its throughput for memory-intensive workloads.

==See Also==
* '''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''

The Internet Computer for Ethereum Developers

2023-12-09T08:55:49Z

Bjoern.tackmann: Corrected link from smartcontract.org to internetcomputer.org

<br>For many developers, the first contact with a smart contract platform is through Ethereum. Hence, when developers later encounter the Internet Computer (IC) they have many preconceptions about how things ought to work and this does not always map to the way the Internet Computer works.

In this article, we’ll try to explain the differences that most developers will encounter and present the differentiating capabilities. Since the language of Ethereum and the Internet Computer slightly differ, this page mostly talks in terms common to Ethereum developers and provide a little dictionary in the end. This page is a living article which gets updated by the community over time to provide a comprehensive reference for new developers coming across the IC.

===A very brief introduction to the Internet Computer===

Before diving into a list of specific differences, we’ll give a brief description of the IC as a whole. The IC is a network of mostly independent subnet blockchains, but contracts can interact transparently across subnets. This allows horizontal scaling of the IC by continuously adding subnets. The subnets are managed by the [https://dfinity.org/howitworks/network-nervous-system-nns Network Nervous System (NNS)], essentially a Decentralized Autonomous Organization (DAO), running on the first subnet itself. The IC has a main utility token - ICP - which can be staked in the NNS to participate in governance and has to be converted to cycles in order to pay for resource consumption on the IC. Contracts on the IC are called canisters and contain [https://webassembly.org/ WASM] byte code. This allows to create contracts in a range of programming languages. In addition, there’s [https://dfinity.org/howitworks/motoko Motoko], a programming language that has been purposefully designed to write canisters in the actor model for the IC.

If you want to dig deeper into mechanics of the Internet Computer have a look at the following resources:

* [https://dfinity.org/whitepaper.pdf The Internet Computer for Geeks]
* The Internet Computer [https://dfinity.org/howitworks/ “How it works”] series with many in depth articles and videos
* The official [https://smartcontracts.org/ Developer Documentation]
* [https://smartcontracts.org/docs/current/references/ic-interface-spec The Internet Computer Interface Specification]
* The [https://forum.dfinity.org/ Developer Forum] and [https://discord.com/invite/cA7y6ezyE2 Discord]

===Differences between Ethereum and the Internet Computer===

So without further ado, we’ll dive into some of notable differences between Ethereum and the IC.
<br>
<br>
====User Experience====
<br>
=====External accounts don’t have to pay for gas=====

The IC implements a “reverse gas” model, where contracts have to pay for their resources in cycles. Hence, a user of a dapp doesn’t need a wallet or tokens to interact with the dapp. Nevertheless, users can still be strongly authenticated to dapps using [https://medium.com/dfinity/internet-identity-the-end-of-usernames-and-passwords-ff45e4861bf7 ID or fingerprint scanner]. Internet Identity which is based on the [https://www.w3.org/TR/webauthn-2/ Web Authentication] standard.

If you wonder how canisters pay for their resources. Every canister has a cycle balance and the balance can be topped up by any other canister. Of course, you can also require users to pay a fee in ICP and then let your canister convert the ICP to cycles, essentially imitating the gas model of Ethereum. Hence, the IC allows for much more flexibility.
<br>

=====Users can interact with the IC safely from their browsers=====

The interaction between a user and an application on Ethereum usually looks like the following:
# A user points her browser to the domain of the application.
# The front end of the application is served by a traditional hosting provider.
# Dynamic data from the blockchain is typically proxied by either a centralized backend provided by the application provider or by a service provider like [https://infura.io/ Infura].
# The user connects to the application with her wallet.
# The front end drafts a transaction and asks the wallet to sign and submit the transaction. Even in the case of a non-financial application the user needs to have ETH in her wallet to pay for gas fees.
# The user approves using the wallet and the wallet submits the signed transaction.
# The user waits - depending on the current usage of the network and the provided fees - from 10s of seconds to minutes until the transaction is confirmed. (See [https://ethgasstation.info/ ETH Gas Station] for current costs and waiting times)

The synergy of a few key innovations allows a user to safely interact with an application on the IC without setting up a wallet, without buying cryptocurrency, and without having to rely on any intermediaries.

# Chain-key technology and subnets allow for lightweight verification and lower costs because of lower replication and horizontal scaling.
# The reverse gas model allows contracts to be pre-loaded with gas to simplify user onboarding
# Internet Identity allows privacy-preserving authentication to services on the IC using [https://webauthn.guide/ WebAuthentication] and a delegation mechanism. Cryptographic secrets are managed with secure hardware.
# Boundary nodes and [https://dfinity.org/howitworks/response-certification certified asset] contracts allow [[Web Serving|serving the front end]] directly from a contract.

So how does interaction with a dapp on the IC look like?

# A user points her browser to the domain of the application which is either a ''ic0.app'' domain directly or the browser will be redirected to a ''ic0.app'' domain.
# The user will see that a service worker gets installed which uses the [https://www.npmjs.com/package/@dfinity/agent Java Script agent] to verify the [https://dfinity.org/howitworks/response-certification certified assets] originating from a contract on the IC. The service worker mechanism is workaround until browsers support the IC, either natively or via an extension.
# The user is asked to login with Internet Identity or another authentication method.
# The user can interact with the dapp without paying fees. State-changing updates take seconds and can mostly be hidden from the user by utilizing optimistic ui patterns.

The best is to try it yourself. Head over to [https://internetcomputer.org/ecosystem our ecosystem page] for example and try a few of the popular apps on the IC.

<br>
<br>
====Developer Experience====
<br>

=====Contracts are upgradable by default=====

On Ethereum, contracts are immutable. If there is a bug in a contract, there is little a developer can do. This led to clever workarounds like [https://docs.openzeppelin.com/learn/upgrading-smart-contracts proxy contracts] which lead to additional complexity and risks for users. On the IC, contracts are mutable by default. Each contract has an associated list of controllers, which are authorized to upgrade contracts. By setting the controllers an empty list or a black hole contract, you can make your contract immutable. But in the IC community, there is the vision that most contracts will be governed by Decentralized Autonomous Organizations (DAOs) just like the IC itself. The DFINITY foundation is working on the [https://medium.com/dfinity/how-the-service-nervous-system-sns-will-bring-tokenized-governance-to-on-chain-dapps-b74fb8364a5c#:~:text=An%20SNS%20would%20derive%20from,%2C%20permissionless%2C%20and%20decentralized%20manner. Service Nervous System], a customizable turn-key solution to govern services on the IC, inspired by [https://dfinity.org/howitworks/network-nervous-system-nns Network Nervous System] which governs the IC.
<br>

=====Inter-contract calls are asynchronous and not atomic=====

The EVM is synchronous and transactions are atomic. This means if a user sends a transaction the transaction is either executed completely or the state is rolled back - only consuming the gas attached to the transaction. This is true independently of the number of contracts involved in the transaction. This property has led to interesting innovations such as Flashloans but severely limits scalability since the entire Ethereum network acts as a single process. On the IC inter-contract calls are asynchronous. Every time you use `await` the state is committed. In case a function traps, the state is only rolled back to the last occurrence of await. You can read more about this [https://smartcontracts.org/docs/current/developer-docs/build/languages/motoko/actors-async/#traps-and-commit-points here] in the documentation. There’s also a [https://forum.dfinity.org/t/we-need-a-defi-subnet/11388/32#world-computers-and-real-world-computers-for-defi-1 great forum post about the different models concerning DeFi].
<br>

===== Contracts will be deleted when they are running out of gas =====

On Ethereum contracts are permanent. While this has some advantages (peace of mind for developers and users), it also has considerable disadvantages (limited scalability). The state of Ethereum is growing without bounds, and there is little incentive for developers to free space in the state. Hence, there are still all those tokens from 2017 in the Ethereum state, although many projects have long been abandoned. On the IC, contracts consume cycles according to their actual resource consumption. Even if contracts won’t be called they consume some cycles, although very little. This is important for the sustainability of the platform. When coming from Ethereum to the IC, developers often are anxious about the cycle consumption and that their contracts will be deleted suddenly. However, there are two effective guards built into the IC.

# There’s an [https://smartcontracts.org/docs/current/references/ic-interface-spec/#system-api-inspect-message ''inspect_message'' functionality] that lets contracts introspect ingress messages (i.e. messages originating from outside the IC) and decide if they want to process the message. This introspection is not charged.
# The IC can freeze a canister such that it automatically rejects all calls and only the base maintenance has to be paid for. Each canister has a [https://smartcontracts.org/docs/current/references/ic-interface-spec/#ic-create_canister ''freezing_threshold''] which can be set as a period in seconds and essentially guarantees that the IC will freeze the canister such that the canister has a balance to afford the maintenance cost for this period. The default ''freezing_threshold'' is approximately 30 days and should give developers or users ample time to top up the canister before it is garbage collected.
<br>

=====Gas fees are predictable=====

In the Ethereum Virtual Machine (EVM), specific operations (Opcodes) have a defined cost in gas, but the exchange rate between ETH and gas is entirely defined by the market. The user can define a ''maxFeePerGas'' that she is willing to pay in a transaction and the individual miner decides if it deems this offer acceptable or not. Since the throughput of Ethereum is highly limited, the price of gas can fluctuate wildly with demand. In addition, the actual price in USD or EUR is even more unpredictable due to the current market price of ETH.

Similar (but more extensive) to gas in Ethereum, the IC has a set of [https://internetcomputer.org/docs/current/developer-docs/gas-cost fixed prices in cycles for various resources]. The main difference however is that the price of cycles is pegged to the XDR, which is based on a basket of the world’s main currencies.

<br>
''1 XDR = 1 Trillion cycles''
<br>

The exchange rate between XDR and ICP is managed by the NNS. Hence, the actual cost of running a canister is relatively stable and predictable, and independent of the current market price of ICP.
<br>
=====The ICP Token is not part of the system but is implemented as a contract=====
The ICP token has two important roles in the IC:

# It can be burned to create cycles that are needed to pay for resources on the IC
# It can be locked in neurons to participate in the governance of the IC

However, ICP does not appear in the system state but is built as a contract running on the NNS subnet. You can find more information about the Ledger canister [https://smartcontracts.org/docs/current/references/ledger here] or [https://www.youtube.com/watch?v=im5HBRd3mqo here].
<br>
<br>
====Scalability and Costs====
<br>
=====96-bytes are enough to verify the state of the IC=====

Verifying the EVM state is a resource-intensive process by which a node has to verify the whole blockchain from genesis. It is possible to have light nodes, that verify only the header chain (which is nevertheless growing forever), in addition to relevant parts of the current state, but the infrastructure is not built yet. Hence, most users rely on centralized APIs to access the Ethereum state, most notably [https://infura.io/ Infura]. The Internet Computer in contrast allows clients to verify the state with a constant 96-byte BLS public key. This public key could be hardcoded into software such as browsers or even hardware like Internet of Things devices to let them interact securely with contracts on the IC.
<br>
=====The Internet Computer can scale horizontally=====

The IC is a network of subnets where contracts can interact transparently across subnets. With increasing demand of the Internet Computer additional subnets can be added by proposals to the NNS.
<br>
=====Contract storage is orders of magnitudes cheaper=====

Ethereum does not yet implement sharding and every node in the network needs to store and execute every contract and every transaction. On the IC only the nodes in a particular subnet replicate execution and state. While this might decrease security in contrast to Ethereum, it is still much more secure than traditional web services with comparable costs. While storing 1 GB on Ethereum is on the order of hundreds of millions of dollars, it is only a few dollars per year on the IC. This allows hosting entire web applications, music, and even videos on the IC, instead of only stripped backend logic. For an overview of common costs on the IC have look at the [https://smartcontracts.org/docs/current/developer-docs/deploy/computation-and-storage-costs Computation and Storage Cost documentation].
<br>
=====There is in general no need to keep track of old blocks=====

Chain-key technology allows a new (validator) node to quickly sync the state and join the validator set using [https://eprint.iacr.org/2021/339 non-interactive distributed key resharing] instead of syncing and validating the blockchain from genesis. Hence, nodes can safely prune the chain every few minutes. For some applications, however, it’s not enough to only be sure that all state transitions have been authorized by at least 2/3 of the nodes, but an audit trail is required. Examples are the ICP ledger and the NNS. In this case, the audit trail is implemented on the application i.e. contract layer. Thereby, in contrast to Ethereum, contracts have access to the audit trails, and not only outside observers.

However, in the future there will be two types of subnets. Private and public subnets. For public subnets, it will be possible for an observer to get the raw block data. The first public subnet will be Nervous Network System subnet itself.
<br>
<br>
====Privacy====
<br>
=====External accounts are not (directly) part of the global state=====

The world state of Ethereum consists of external accounts (users) and internal accounts (contracts). Each account has an associated ether balance. On the IC only canister principals are part of the state. Each canister principal has an associated cycle balance which is not public by default. This has privacy advantages since a user can interact with canisters on the IC in an authenticated manner without disclosing its principal in the public state. The disadvantage is that user principals can’t hold cycles directly, but need a canister like the cycles wallet.
<br>
=====The global state is not public, but only parts=====

On Ethereum, everyone can run a full node, and therefore everything is public. Privacy can only be achieved by keeping data off-chain or by using cryptography. On the IC, nodes are permissioned by the NNS and only parts of the IC are public. Besides the API a contract developer defines for the contract itself, the following data is public

* The subnet of the contract
* The name of the contract
* The hash of the [https://webassembly.org/ WASM] module of the contract
* The controllers of the contract

In particular, neither the actual byte code nor the (cycles) balance of a contract is public. However, as mentioned earlier, the IC will support public subnets in the future. These subnets will make the raw IC block data available.
<br>
<br>
====Differentiating Capabilities====
<br>
=====Contracts can trigger themselves=====

On Ethereum, every state change has to be triggered by an external account. On the IC, however, a canister can use the [https://smartcontracts.org/docs/current/developer-docs/build/languages/motoko/heartbeats ''heartbeat'' functionality] or [https://internetcomputer.org/docs/current/motoko/main/timers timers] to be triggered by the IC. This opens up a lot of new possibilities. A simple example would be a cron service, which allows other canisters to register themselves to be called.
<br>
=====Contracts have access to cryptographic randomness=====

The unique consensus algorithm of the IC can be used as a source of cryptographic randomness. This randomness is [https://smartcontracts.org/docs/current/references/motoko-ref/random/ accessible to contracts] and can be used in applications like lotteries or games.
<br>
=====Contracts can hold private keys and sign messages=====

On Ethereum every contract is public. This means a contract can’t hold private information and hence can’t sign messages because there’s no way to securely store a private key. The consensus mechanism of the IC uses a mechanism known as threshold signing where the validator nodes collaborate to create a (BLS) signature without the entire private key existing at all. In the new [https://dfinity.org/howitworks/threshold-ecdsa-signing chain-key ECDSA signing feature] a similar mechanism has been made available for contracts to order the IC to generate threshold ECDSA signatures. These signatures will be verifiable outside the IC just like regular ECDSA signatures — they are 100% conforming to the standard. This means you can sign Ethereum or Bitcoin transactions with a contract on the IC or you can create JWTs, verifiable credentials, or x.509 certificates.
<br>
=====Contracts can call web services=====

If you need data from the outside world on Ethereum you need oracles that feed this information into a contract on Ethereum. On the IC it is possible to call web services from inside a contract. You can read more about this feature on the [https://internetcomputer.org/https-outcalls Web page], the [https://internetcomputer.org/docs/current/developer-docs/integrations/http_requests/ docs] or [https://forum.dfinity.org/t/enable-canisters-to-make-http-s-requests/9670 forum], or watch the [https://www.youtube.com/watch?v=n_LFCc0ws6o community conversations].
<br>
<br>
===Dictionary===
contract → canister

gas → cycles

shard → subnet (Not entirely true, since Ethereum currently only considers data shards)

(validator) nodes → replicas

Decentralization

2023-11-20T11:20:53Z

Bjoern.tackmann: Some clarifications

Decentralization is key to making Web 3.0 dapps run in a trustless manner. However, decentralization has many dimensions and cannot be understood and quantified using a single number or coefficient. One can distinguish between the decentralization of the entities running the machines on top of which a protocol runs, the decentralization of the consensus and sharding mechanism, the governance system, the owners of liquid tokens etc. In this case, the whole is greater than the sum of its parts and one cannot understand decentralization as a single discussion on each of these topics.

For a truly decentralized system, anyone must have the possibility to contribute to the computing power and supporting infrastructure. Anybody should be able to check the integrity and authenticity of Web 3.0 content served. No part of this should be restricted by a single party and all decisions should be taken by the community via a DAO. See also [https://assets-global.website-files.com/5fd11235b3950c2c1a3b6df4/62af6c641a672b3329b9a480_Unintended_Centralities_in_Distributed_Ledgers.pdf Trail of Bits Decentralization Report] and [https://arxiv.org/pdf/2205.04256.pdf SOK: Blockchain Decentralization] for related publicly accessible reports on these topics.

== Node provider decentralization ==
Reducing this aspect to the number of machines is definitely insufficient, if the majority of them are owned or operated by a small number of parties or reside in a small number of companies’ data centers. Furthermore, for censorship resistance, the jurisdictional location is important, while availability in the face of outages benefits from geographical distribution. In other words, decentralization is reflected by the number of nodes, the number of node providers, the number of data centers and the number of countries and continents where they are located. In February 2023, all 56 [https://dashboard.internetcomputer.org/providers IC node providers], which operate between 1 and 65 of the total 1235 nodes are known legal entities. How many nodes they operate and where they are located is publicly available information. Node providers must provide a [[Node_Provider_Self-declaration|self-declaration]] of identity and good intent, and can be held liable under misconduct. Anyone can submit a proposal to become a node provider, which the community can then choose to accept. In contrast, node providers for most other blockchains remain anonymous and it is impossible to find out how many nodes they operate and where they are located.

== Consensus and sharding decentralization ==
For the consensus and sharding mechanism, the number of corrupted entities required to lead to forks is crucial. Other important factors are the assignment of nodes to shards and the guarantees offered for the communication between shards. The main assumption the IC is based on requires more than ⅔ of the nodes to adhere to the protocol. No system can work with fewer correct nodes in the presence of arbitrary node behavior and a potentially unreliable network, and still guarantee consensus. Indeed, this is the highest fraction of potentially malicious actors that any system can tolerate with a communication network that doesn’t guarantee known bounds on message delivery (see the [https://internetcomputer.org/whitepaper.pdf whitepaper] for more details on these assumptions). As long as this assumption holds in all subnets, all messages are guaranteed to be processed according to the interface spec, regardless of which subnet their canisters reside in. Subnet membership is subject to NNS votes, thus the community can assess if the assignment of nodes of different providers and different jurisdictions is satisfying their decentralization requirements.

== Governance and token ownership decentralization ==
The evolution of a system depends on the governance mechanism that defines how a system can change (deploying user-facing improvements, tokenomics changes, API and cryptographic protocol modifications, node management, …). In some systems, this is basically decided by the entities running the nodes, while for others, e.g. in case of the IC, the NNS canisters define the governance mechanisms, including the parameters for staking, voting and rewards. Users can stake ICP to be able participate in voting. Among other topics, the IC community votes on the protocol version running in the subnets, node provider remuneration and voting rewards, the addition/removal of node providers and the assignment of nodes to subnets. The DFINITY foundation and the ICA are the parties with the highest voting power in the ecosystem, together holding less than 23% of the total voting power. The overall voting participation is often above 99% due to the use of liquid democracy. More information on Governance and Tokenomics can be found [[NNS Canisters|here]] and [[Tokenomics of a DAO|here]].

Total supply, circulating supply, and staked ICP

2023-11-20T11:04:13Z

Bjoern.tackmann: Minor correction in counting and grammar.

For a crypto community to understand the [[Governance of the Internet Computer | governance]] and [[ICP Tokenomics | tokenomics]] of ICP, understanding the supply of ICP is important.

==Definitions==

===Total supply===

Total supply is the sum of all tokens currently in the system (whether they are locked/staked or not).

The total supply changes over time due to inflation and deflation. Its current value can be seen on the [https://dashboard.internetcomputer.org/circulation IC Circulation page] of the IC dashboard.

===Circulating supply===

The circulating supply is all tokens except liquid (non-staked) tokens owned by the DFINITY Foundation. The circulating supply definition was updated to its current definition on 18APR23 through an approved vote by the NNS on [https://dashboard.internetcomputer.org/proposal/117360 proposal 117360.]

The current circulating supply can be seen on the [https://dashboard.internetcomputer.org/circulation IC Circulation page] of the IC dashboard.

===Staked ICP===

Staked ICP supply is the sum of all the tokens that are locked or dissolving in neurons at any given time that are earning rewards. At this time, there is a minimum lockup period of 6 months to accrue voting rewards.

The total amount of staked ICP changes over time. Its current value can be seen on the [https://dashboard.internetcomputer.org/neurons Neurons page] of the IC dashboard.

==Numbers==

===At network Genesis===

May 10, 2021:
* Total supply: 469 million
* Circulating supply: 123 million

===Current status===
As of November 16th, 2023:
* Total supply: 509.9 million ICP
* Circulating supply: 449.5 million (88.2% of total supply)
* Staked ICP: 247.7 million (48.6% of total supply).
** 86.6% of ICP staked is staked with more than a 1-year dissolve delay
** 54.0% of ICP staked is staked for an 8-year dissolve
** One can see the breakdown of staked ICP by dissolve delays in [https://dashboard.internetcomputer.org/neurons IC neuron dashboard].

* As outlined in the section above Circulating supply represents ICP that was ever liquid. A subset of the circulating supply is locked in neurons as staked ICP.

==Inflationary mechanisms==

The NNS mints ICP tokens for two reasons:
* For voting rewards (Governance).
* For node provider rewards.

The amount of ICP minted since Genesis can be seen in the [https://dashboard.internetcomputer.org/circulation "Total Rewards" chart] on the IC dashboard.

===Paying staking rewards===

Voting rewards are generated by minting ICP, although this minting only happens at the moment rewards are spawned, maturity is merged, or the neuron is disbursed.

The voting rewards rate schedule is designed with the goal that 90% of the token supply is staked in neurons. With this goal in mind, in the first year, the NNS allocates 10% of the total supply to generate voting rewards. Note the term "allocates" rather than "mints", because rewards are not minted (increasing the total supply) until they are spawned, merged, or the neuron is disbursed.

As the network becomes more stable over time, this allocation rate drops quadratically until it reaches 5% by year 8. See chart below from the [https://dashboard.internetcomputer.org/circulation IC Circulation page] on the IC dashboard.:

[[File:NNS minting % by year.png|800px|frameless]]

'''Like all parameters in the NNS, this rate schedule can be changed via NNS proposals.'''

See more in [[Staking, voting and rewards]].

===Node provider rewards===

Node providers are rewarded for running the node machines that power the Internet Computer.

==Deflationary mechanisms==

The NNS burns ICP tokens for three reasons:

* To mint cycles, used to pay for compute and storage.
* For transaction fees.
* For failed NNS proposal fees.

The amount of ICP burned since Genesis can be seen in the [https://dashboard.internetcomputer.org/circulation "Total ICP Burned" chart] on the IC dashboard.

===Paying for compute and storage===

Dapp and smart contract developers pay computation and storage costs with cycles. Cycles are acquired from the NNS by converting ICP to cycles, which burns the converted ICP.

The cycles costs for IC computation and storage can be seen at [https://smartcontracts.org/docs/developers-guide/computation-and-storage-costs.html Computation and Storage Costs].

===Transaction fees===

Transferring ICP across accounts incurs a transaction fee of 0.0001 ICP, which is burned.

===Failed NNS proposals===

It costs 10 ICP to submit a proposal. If the proposal passes, the 10 ICP is returned to the proposer. If the proposal is rejected, the 10 ICP is burned. Note that this only happens at disbursement or merging of neurons, so accumulated failed proposal fees can persist for a while before finally contributing to deflation.

==Historical factors affecting circulating supply==

The Internet Computer blockchain is a result of several years of unyielding R&D. By Genesis, the DFINITY foundation, a major contributor to the Internet Computer was over 200 full-time members. Over the past several years the foundation raised financing in three main rounds and also allocated ICP tokens to the community in the form of an airdrop event.

For a breakdown of the different rounds and vesting schedules, see Messari's report [https://messari.io/article/an-introduction-to-dfinity-and-the-internet-computer?referrer=asset:internet-computer "Introduction to ICP"]. The unlocking of neurons has been the '''largest contributing factor''' to circulating supply since Genesis, so it's important to understand the context.

1. '''Seed Round, Feb-2017 (Public ICO):''' This round was advertised by a tweet and open to the public by downloading a web extension. DFINITY raised CHF3.9 million (US$3.9 million) from 370 participants, at a valuation of $16 million, or a price of $0.03 per token. It held a portion of these funds in ETH and BTC during the 2017 crypto bull run. Seed round participants received all of their tokens at genesis but are staked inside 49 neurons. Each neuron has a different dissolve delay counting from 0 to 48 months. So this is practically equivalent to a 48-month "vesting schedule" see [https://medium.com/dfinity/how-to-access-seed-and-airdrop-icp-tokens-and-participate-in-the-internet-computer-network-e6cd663a0c3c How to Access ‘Seed’ and ‘Airdrop’ ICP Tokens and Participate in the Internet Computer Network].

2. '''Strategic Round, Jan-2018:''' DFINITY raised $20.54 million for 7.00% of the initial supply (the number has been revised from the previously cited 6.84%). This allocation vests monthly over three years starting from mainnet launch (May 2021). Participants include Polychain Capital, Andreessen Horowitz, CoinFund, Multicoin Capital, and Greycroft Partners. This round marks the first token a16z invested in. Polychain and DFINITY later collaborated to create the "DFINITY Ecosystem Venture Fund" (later renamed [https://dfinity.org/ecosystem/fund/ "Beacon Fund"]) of an undisclosed size. The goal is to fund new projects that would grow the IC's application ecosystem. The media reported that DFINITY raised a much larger amount of $61 million, some of which related to funds committed to projects building on the Internet Computer.

3. '''Presale, Aug-2018:''' 110 participants contributed $97 million for 4.96% of the initial supply, sold at 4 CHF (around $4 at the time) per ICP token. This number has been revised from 4.75% previously reported. This allocation came with a monthly vesting schedule of one year from mainnet launch. Vesting began one month after the initial token distribution event on May 10, 2021. Participants in this round include Andreessen Horowitz, Polychain Capital, SV Angel, Aspect Ventures, Electric Capital, ZeroEx, Scalar Capital, and Multicoin Capital.

4. '''Airdrop, May-2018:''' $35 million worth of ICP tokens (formerly DFN), or 0.80% of the initial supply, was airdropped to early supporters by being part of their mailing list, forums, and community. At this time, valuations reached $1.89 billion. Airdrop participants received the IOU version of their ICP tokens in September 2020. This allocation came with a monthly distribution schedule of one year from mainnet launch, which began on May 10, 2021.

==Conclusion==

'''Ultimately, the NNS is controlled by the community so it can vote to change any of the parameters. The parameters and mechanisms described are the current ones.'''

The ICP token has a Total Supply of 509.9MM, Circulating Supply of 449.5MM as of November, 2023. 247.7MM ICP (48.6% of total supply) is staked by token holders in the form of neurons with over 86.6% locked for over 1 year.

The number of tokens is constantly changing. The rewards paid out to the node providers and governance participants contribute to the inflation in token supply while factors like compute/storage fees and transaction fees cause deflation in the total supply.

Milestone Three: Node Provider Onboarding

2023-11-20T10:49:13Z

Bjoern.tackmann: Changed redirect to a more appropriate site.

#REDIRECT [[Node Provider Roadmap]]

Main Page

2023-11-20T10:36:59Z

Bjoern.tackmann: Minor edits.

<templatestyles src="Template:Main_page/styles.css"/>

<div>

<div></div>

==Introduction to Internet Computer Protocol (ICP) Blockchain==


The [[Introduction_to_ICP | Internet Computer]] is a general-purpose blockchain that hosts canister smart contracts. It is designed to provide a World Computer that can replace traditional IT and host a new generation of Web 3.0 services and applications that run solely from the blockchain, without the need for traditional IT. It can also play the role of Web 3.0 orchestrator, by interacting with other blockchains.

It has a completely unique design that reflects a ground-up rethink of blockchain architecture and the application of modern cryptography, [https://web.archive.org/web/20150914013643/http://dfinity.io/ which can be traced back to 2015]. It was built by the largest [https://dfinity.org/team ongoing R&D effort in crypto], which has employed many notable cryptographers, computer science researchers and engineers. The blockchain underwent genesis in May 2021 and became part of the public internet.

See more at [[Introduction to ICP]].

<div style="clear: both;"></div>

==Main Sections ==


<div id="audiences" class="mainpage_row">


<div class="mainpage_box overview" id="overview">
<h3>

<span>'''Overview''': ICP Blockchain and ICP Ecosystem</span>
</h3>
<div id="mainpage-users" title="Users" class="items">
* [[Introduction to ICP]] blockchain
* [[Popular Explainers of ICP |Popular explainers of ICP]] blockchain
* [https://internetcomputer.org internetcomputer.org website]
* [https://dashboard.internetcomputer.org ICP Network Dashboard]
* [[Web3: The bull case for the Internet Computer]]
* [[ICP Ecosystem Stats |ICP ecosystem stats]]
* [[ICP Community |ICP community]]
* [[ICP Tokenomics |ICP tokenomics]]
</div>
</div>


<div class="mainpage_box users">
<h3 class="mainpage_box_header_users">

<span>'''For Users''': Getting Started with ICP</span>
</h3>
<div id="mainpage-users" title="Users" class="items">
* Aquire an [[Internet Identity]] (not necessary, but highly recommended)
* [[Tutorials for acquiring, managing, and staking ICP |Managing and staking ICP tokens]]
* [https://internetcomputer.org/ecosystem/ Examples of ICP smart contracts and dapps]
* [[Support Center|DFINITY support center]]
</div>
</div>


<div class="mainpage_box developers">
<h3>

<span>'''For Developers''': Building ICP Smart Contracts</span>
</h3>
<div id="mainpage-devs" title="Developers" class="items">
* [https://internetcomputer.org/docs/current/home Developer Documentation]
* [[Technical working groups]]
* Launching an [[Service Nervous System (SNS) |SNS]] DAO
* Smart contracts with [[Bitcoin integration]]
* [[The Internet Computer for Ethereum Developers |ICP for Ethereum developers]]
* [https://forum.dfinity.org/ Developer forum] for ICP developers.
* [[CommunityTutorials|Community Tutorials]]
</div>
</div>
</div>


<div id="misc-news" class="mainpage_row nodes">

<div class="mainpage_box">
<h3>

<span>'''For Node Providers''': Joining ICP Network</span>
</h3>
<div id="mainpage-help-contribute" title="Support and Contributing" class="items">
*[[Node Provider Documentation]]
*[[Node Provider Roadmap]]
*[[Node Provider Troubleshooting]]
* Status of the network on [https://dashboard.internetcomputer.org ICP Dashboard]
* [[Node Provider Matrix channel|IC Node Provider Matrix channel]]
* ICP is a [[Sovereign Network]] using [[Deterministic Decentralization]] with [[Proof of Useful Work]] consensus
</div>
</div>

<div class="mainpage_box community">
<h3>

<span>'''For ICP Community''': Participating in ICP</span>
</h3>
<div id="mainpage-help-contribute" title="Support and Contributing" class=" items">
* [[Technical Working Groups]]
* [[Governance of the Internet Computer |ICP governance]]
* [[Contributing to the wiki]]
</div>
</div>

<div class="mainpage_box researchers">
<h3>

<span>'''For ICP Researchers''': Deep Dive into ICP</span>
</h3>
<div id="mainpage-researchers" title="Deep Dive into ICP" class=" items">
* [https://eprint.iacr.org/2022/087 "Internet Computer for Geeks" white paper]
* [[IC architecture overview]]
* [https://www.reddit.com/r/dfinity/comments/ozboyi/megathread_technical_amas/ Technical AMAs on Reddit by different IC and DFINITY teams]
</div>
</div>

</div>

''If you are looking for the old main page, go [[Main page old | here]].''
</div>

Hardware Wallet CLI

2023-08-22T09:55:39Z

Bjoern.tackmann: Created the hardware wallet page and included a tutorial for maintaining ckBTC.

In addition to the [https://nns.ic0.app/ NNS frontend dapp] that runs within a browser, the Ledger Nano hardware wallet is also supported by the [https://github.com/dfinity/hardware-wallet-cli ic-hardware-wallet] CLI tool.

=== Installing ic-hardware-wallet ===
Installation of <code>ic-hardware-wallet</code> follows the steps laid out in the file [https://github.com/dfinity/hardware-wallet-cli/blob/main/README.md README.md], which is first installing a sufficiently recent version of [https://nodejs.org/en Node.js] and then using <code>npm</code> to install the tool itself. After you completed these steps, you will be able to call <code>ic-hardware-wallet</code> in your terminal.

=== Retrieve the principal and ICP account ===
After the tool <code>ic-hardware-wallet</code> has been installed on your computer as described above, you can view the principal and ICP account associated with the hardware wallet by running the command <code>ic-hardware-wallet info</code>. The output contains a principal whose format looks similar to this: <code>hw5je-hd33v-7xl3v-g7t2y-aapa3-635og-fz5dz-mhma6-dthmt-kzqlk-wqe</code>.

=== Maintaining ICP ===
The command <code>ic-hardware-wallet balance</code> will output the balance (in e8s, that is, units of 10<sup>-8</sup> ICP) of the main ICP account associated with the hardware wallet. You can send ICP by using the <code>ic-hardware-wallet transfer --to [64-char hex address] --amount [in e8s]</code> command.

=== Minting and maintaining ckBTC with the hardware wallet ===
This section contains a step-by-step guide for minting ckBTC to an account controlled by the hardware wallet. Two steps are needed as a preparation: Installing the ic-hardware-wallet tool as described above, as well as ic-repl, which can be installed by downloading a release binary from the [https://github.com/dfinity/ic-repl/releases repository].

# Obtain the main principal that is associated with your hardware wallet by running <code>ic-hardware-wallet info</code> as described above.
# Compute the Bitcoin address for depositing funds. This is done as follows:
## Run <code>ic-repl -r ic</code> to enter the <code>ic-repl</code> CLI.
## Load a non-anonymous identity, for instance via <code>identity default "~/.config/dfx/identity/default/identity.pem"</code>, this assumes that the <code>dfx</code> <code>default</code> identity is installed. (Other PEM-files work as well, but the actual identity does not really matter, the canister simply does not accept anonymous messages.)
## Retrieve the BTC address from the ckBTC minter canister. Using the example principal from above, this is done via <code>call "mqygn-kiaaa-aaaar-qaadq-cai".get_btc_address(record { owner = opt principal "vcruu-d2fof-5dudt-i7txp-krvmo-65mku-lvjne-nxmp4-z6qya-zzqgc-3ae"; subaccount = null })</code>. Please adapt the <code>owner</code> value to your hardware wallet principal. The result of this call is a BTC address, in this case <code>bc1qelxlq9jzds3e2vfqaz9qpnj3l69ktx8sfqz384</code>.
# Send BTC to the address you retrieved in the previous step.
# After waiting for 12 confirmations (approximately 2 hours), use the <code>ic-repl</code> CLI to run <code>call "mqygn-kiaaa-aaaar-qaadq-cai".update_balance(record { owner = opt principal "vcruu-d2fof-5dudt-i7txp-krvmo-65mku-lvjne-nxmp4-z6qya-zzqgc-3ae"; subaccount = null })</code>, again adapting owner to your hardware wallet principal. If this step returns successful, the ckBTC will be in your wallet.
# Validate the ckBTC balance by calling <code>ic-hardware-wallet icrc balance --canister-id mxzaz-hqaaa-aaaar-qaada-cai</code>.

The ckBTC controlled by the hardware wallet can then be transferred by calling <code>ic-hardware-wallet icrc transfer --canister-id mxzaz-hqaaa-aaaar-qaada-cai --to [principal] --amount [in e8s]</code> and confirming the transaction on the hardware wallet.

ICP custody with Ledger Nano

2023-08-22T07:34:07Z

Bjoern.tackmann: Add reference to hardware wallet CLI page that I am about to write.

== Ledger Nano ==

The [https://www.ledger.com/ Ledger] Nano is one of the world’s most popular hardware wallets for safely storing crypto assets. A Ledger wallet combined with the Ledger Live app gives users complete control over their crypto, ensuring ownership over their assets while providing maximum security.

== ICP and Ledger Nano==

To use the Ledger Nano to manage your ICP follow these instructions, you need three things:

* Networked computer
* [https://identity.ic0.app/ Internet Identity] with [https://nns.ic0.app/v2/ NNS frontend dapp]
* Ledger Nano

You can follow the user manual here: [https://medium.com/dfinity/integrating-ledger-nano-with-the-nns-front-end-dapp-user-manual-9c5600925e16 Integrating Ledger Nano With the NNS Front-End Dapp]. If you prefer using CLI, there is a [[Hardware Wallet CLI]] that you can also use to manage any ICRC-1 token.

==Features==

The Ledger Nano + NNS dapp integration supports the following actions:

* Receive/send ICP
* Stake a neuron
* View neurons
* Add neurons as hotkeys
* Dissolve neurons
* Disburse neurons
* Increase dissolve delay of neurons
* View NNS proposals
* Vote on NNS proposals
* Choose neurons to follow for voting

==Benefits==

* Maximum control of one's seed phrase (NNS frontend dapp does not access one's seed phrase)
* Has all the functionality one needs for custody, staking, voting
* Ideal for people who want to want to combine easy web experience with to control of their seedphrase ICP

==Trade-offs and risks==

If you use this combination, you are accepting the following trade-offs:

* '''Risk of losing access''' - If you only have lose access your Ledger Nano AND forget seed phrase, you lose access to your ICP.

* '''Risk your devices do not support it''' - Not all devices and browsers support WebAuthn, so this option is sometimes not available. Supported browsers for Ledger Nano integration currently include Chrome (desktop) v89+, Edge v89+, and Opera v76+.

== Security ==

The Ledger Internet Computer (ICP) app was built by a collaboration between the [https://zondax.ch/ Zondax] team of engineers and cryptographers and the DFINITY Foundation. It was released and announced on December 3, 2021 [https://medium.com/dfinity/introducing-the-ledger-internet-computer-icp-app-for-nano-wallets-eed38c549f0d].

The Ledger Internet Computer (ICP) app has undergone a third-party audit and has been reviewed and approved by Ledger. You can access the Ledger Internet Computer (ICP) app repository here: https://github.com/Zondax/ledger-icp.

== See Also ==
* [[Managing ICP holdings]]
* [[ICP custody options]]

IC architecture overview

2022-11-16T10:21:34Z

Bjoern.tackmann:

[[File:IC-protocol-stack.png|500px]]

As illustrated in the above diagram, the Internet Computer Protocol consists of four layers:
* [[IC execution layer]]
* [[IC message routing layer]]
* [[IC consensus layer]]
* [[IC P2P (peer to peer) layer]]

Description of specific features:
* [[Bitcoin integration]]
* [[HTTPS outcalls]]

Canisters serving the web:
* [[HTTP asset certification]]
* [[Boundary Nodes]]

IC architecture overview

2022-11-11T12:20:11Z

Bjoern.tackmann:

IC architecture overview

2022-11-11T12:19:43Z

Bjoern.tackmann:

IC architecture overview

2022-11-11T12:19:10Z

Bjoern.tackmann:

Internet Computer wiki

2022-11-11T12:17:53Z

Bjoern.tackmann:

==Welcome!==

This is a general source of information about the '''Internet Computer (IC)''', the world's fastest and most powerful blockchain network<ref>https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef</ref>. Created for and by the IC community, topics vary from cryptography, network governance, user experience, tokenomics, developer tutorials and more.

==Introduction to the Internet Computer==
The Internet Computer is a general-purpose blockchain that hosts [[canister smart contract]]s. It is designed to [[Replace traditional IT with a World Computer|provide a World Computer that can replace traditional IT]] and host a new generation of [[Web3:_The_bull_case_for_the_Internet_Computer|Web3]] services and applications that run solely from the blockchain, without the need for traditional IT. It can also play the role of Web3 orchestrator, by interacting with traditional blockchains.

It has a completely unique design that reflects a ground-up rethink of blockchain architecture and the application of modern cryptography, [https://web.archive.org/web/20150914013643/http://dfinity.io/ which can be traced back to 2015]. It was built by the largest [https://dfinity.org/team ongoing R&D effort in crypto], which has employed many notable cryptographers, computer science researchers and engineers. The blockchain underwent genesis in May 2021 and became part of the public internet.

The Internet Computer blockchain's protocols leverage novel [[chain key cryptography]] to combine multiple [[Limitless_Scaling#Subnet Architecture|subnet blockchains]] into a single blockchain. This allows it to [https://en.wikipedia.org/wiki/Scalability#Horizontal_(scale_out)_and_vertical_scaling_(scale_up) horizontally scale] the total volume of hosted [[canister smart contract]], and their computations and data, without limit. These smart contracts run at web speed, and with web-levels of efficiency, and uniquely, thanks to the blockchain architecture enabled by chain key crypto, can process HTTP requests and directly and securely serve interactive web experiences to the end-users of web3 services, without need for trusted intermediaries (whereas on other blockchains, the web experience users interact with is generally built on centralized, insecure and trusted servers or cloud computing services).

Through these kinds of unique capabilities, the Internet Computer provides a platform that can be used to build mass market web3 services that run 100% on-chain, without any need for traditional IT, such as web servers and databases running on cloud computing services. The longer-term objective is that the Internet Computer will completely replace traditional IT, creating a ''blockchain singularity'', in which everything runs fully on-chain in powerful new forms where it is unstoppable and cannot be hacked.

The development of the Internet Computer has heralded numerous notable technological developments, such as [[chain key cryptography]] and programming languages such as [https://wiki.internetcomputer.org/wiki/Motoko Motoko]. In another notable advance, the Internet Computer hosts an advanced [https://en.wikipedia.org/wiki/Decentralized_autonomous_organization DAO] within its protocols, called the [[Network Nervous System]], which provides the community with direct control over network governance, and can upgrade the protocol running on its network nodes, without requiring the network to fork. The network's utility token is ICP (see [[Roles of the ICP utility token]]).

A recent new technological advance has extended the Internet Computer's [[chain key cryptography]] protocols. This has enabled smart contracts hosted on the Internet Computer to directly interact with other blockchains, without need for dangerous centrally-controlled bridges or wrapping (see [[trustless multi-chain web3 using the IC]], and [[Extend Bitcoin, Ethereum and other blockchains|extending Bitcoin, Ethereum and other blockchains]]).

For example, a canister smart contract hosted on the Internet Computer can create bitcoin addresses, and directly send and receive bitcoins on the Bitcoin ledger as though it were hosted by the Bitcoin network itself. This is possible because chain key crypto enables blockchains to create public "chain keys", for which their nodes can create corresponding signatures. Recent work has now made it possible to create ECDSA chain keys. Since [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] is the signature scheme used by most other blockchains, this means the Internet Computer can create TX on other blockchains.

Future work will enable its smart contracts to directly interact with other important blockchains such as [https://ethereum.org/en/ Ethereum]. This also leverages other important features such as [[HTTPS outcalls]]. As a consequence, many believe that the Internet Computer will play the role of an orchestration layer that combines different blockchains in the web3 environment, and helps combine them with off-chain services and systems, such as Web 2.0 services and enterprise systems, in a trustless way.

===Popular places to start===
* [https://www.youtube.com/watch?v=IfM3I8pudFs&t=327s Internet Computer overview video from 2022 IC hackathon]
* [https://www.youtube.com/watch?v=IfM3I8pudFs June 2022 IC hackathon, full launch video]
* [https://dfinity.org/icig.pdf Internet Computer Infographic (PDF)]

* [[Glossary]]

===For a general audience===
* [[Internet Computer overview]]
* [[Internet Computer vision]]
* [https://dfinity.org/roadmap/ Internet Computer roadmap]

===For a more technical audience===
* [https://eprint.iacr.org/2022/087 "Internet Computer for Geeks" paper]
* [[IC architecture overview]]
* The [https://dfinity.org/howitworks "How it works" series] with videos and in-depth articles on various topics.
* [https://www.reddit.com/r/dfinity/comments/ozboyi/megathread_technical_amas/ Technical AMAs on Reddit by different IC and DFINITY teams]

== Internet Identity Introduction ==
One of the core benefits of building on the Internet Computer is that end users do not need to pay fees or use tokens to access and use dapps. As an alternative to authenticating from a wallet, users can authenticate with an Internet Identity. Learn more information about Internet Identity (II), a blockchain authentication framework supported by the Internet Computer:

* [[What is Internet Identity]]
* [[How to create an Internet Identity]]
* [[Internet Identity technical overview]]
* [https://identity.ic0.app/ Internet Identity dapp]

==IC for Dapp Users ==

If you use or are interested in using dapps on the Internet Computer, this section will help you understand the user experience benefits of the IC, how to use Internet Identity, or find more IC dapps.

Examples:
* [[Introduction to the Internet Computer for dapp users]]
* [[Index of dapps on the Internet Computer]]

See more in [[Internet Computer for dapp users]]

== IC for ICP Token-holders, Stakers, and Neuron Holders==

The Internet Computer is governed by on-chain governance system called the Network Nervous System (NNS). To participate on governance, users need to stake ICP tokens. This section will explain how the NNS works, ICP tokens, staking, voting, rewards, and options for managing one's ICP.

Examples:
* [[ICP token]]
* [[Tutorials for acquiring, managing, and staking ICP]]
* [[Staking, voting and rewards]]
* [[Governance of the Internet Computer]]
* [[Network Nervous System]]
* [[Total supply, circulating supply, and staked_ICP]]
* [[NNS neuron operations related to maturity]]

See more in [[Internet_Computer_token-holders,_investors_and_neuron_holders|Internet Computer token-holders, investors, and neuron holders]].

== IC for Smart Contract and Dapp Developers ==

The Internet Computer (IC) is a new platform for executing smart contracts. This section contains information for developers, including links to documentation, developer forums, and relevant dashboards.

Examples:
* [[Canisters (dapps/smart contracts)]]
* [https://smartcontracts.org/ Developer documentation on smartcontract.org]
* [https://forum.dfinity.org/ IC community developer forum]


* [[Bitcoin integration]]
* [[SNS Tokenization Considerations]]
* [[Web Speed]]
* [[Web Serving]]
* [[Limitless Scaling]]
* [[Users interact with dapps without tokens]]
* [[Parallelism]]
* [[Error Handling inside Internet Computer]]

If you've been programming smart contracts on Ethereum before, you should read [[The Internet Computer for Ethereum Developers]].

See more in [[Internet Computer for smart contract and dapp developers]].

== IC for the Curious, Researchers and Blockchain Enthusiasts ==

This section is for those interested in how the Internet Computer works under the hood. It touches many different subject areas from cryptography, consensus protocols, virtual machines, operating systems, networking, distributed systems, etc.

Examples:
* [https://dfinity.org/howitworks/ How the Internet Computer Works]
* [https://dashboard.internetcomputer.org/ Internet Computer dashboard]
* [[Internet Computer performance]]
* [[DFINITY Foundation]]
* [[Bitcoin integration]]
* [[Third-party security audits]]
* [[Networking]]
* [[Replicated state structure]]
* [[ICP technical design documents]]

== For Node Providers ==
Node providers invest in and operate node hardware, which powers the Internet Computer with processing and storage capacity. Running these nodes in data centers provides the high performance and the cost-effectiveness of the Internet Computer. Every node provider is allowed a limited amount of nodes.
* [[Node Provider Onboarding]]
* [[Gen-2 Data Center runbook]]
* [[Gen-2 Network Requirements]]
* [[IC OS Installation Runbook - Dell Poweredge]]
* [[IC OS Installation Runbook - Supermicro]]
* [[Possible Node Onboarding Errors]]
* [[Storage Runbook]]
* [[Node rewards]]
* [[Node Provider Remuneration]]

== Technical Working Groups ==
* [[Identity & Authentication]]
* [[Developer Tooling]]
* [[Ledger & Tokenization]]
* [[Scalability & Performance]]

== FAQs, Tutorials, and How-tos==
Tutorials are guided introductions to user stories, intended for first-time users and characterized by a shallow learning curve. How-Tos are step-by-step instructions for specific, narrow goals.

===FAQs===
* [[FAQ]]

===Best Practices===
Example:
* [[Managing ICP holdings]]
* [[Managing Internet Identity]]
* [[Maximizing Voting and NNS Rewards]]
See more in [[Best Practices]]

=== Tutorials ===
Example:
* [[Tutorials for acquiring, managing, and staking ICP]]
* [[How-To: Claim neurons for seed participants]]
* [[How-To: Create an NNS motion proposal]]
* [[How-To: Set your neuron to follow another neuron]]
* [[How-To: Updating neuron following via quill]]

See more in [[How-Tos]].

==Contributing to the Wiki==

=== How to contribute ===
Anyone can read the wiki. You can also edit pages, all you need to do is [https://wiki.internetcomputer.org/wiki/Special:CreateAccount create an account]. See more in [[Contributing to the wiki]].

==References==

test

ICP technical design documents

2022-10-17T10:47:01Z

Bjoern.tackmann:

This page will serve as a directory of technical design documents for the improvement of ICP.

ICP technical design documents

2022-10-17T10:46:39Z

Bjoern.tackmann: Created page with "= Technical design documents = This page will serve as a directory of technical design documents for the improvement of ICP."

= Technical design documents =

This page will serve as a directory of technical design documents for the improvement of ICP.

Internet Computer wiki

2022-10-17T10:45:44Z

Bjoern.tackmann: Add a new design documents page.

==Welcome!==

This is a general source of information about the '''Internet Computer (IC)''', the world's fastest and most powerful blockchain network<ref>https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef</ref>. Created for and by the IC community, topics vary from cryptography, network governance, user experience, tokenomics, developer tutorials and more.

==Introduction to the Internet Computer==
The Internet Computer is a general-purpose blockchain that hosts [[canister smart contract]]s. It is designed to [[Replace traditional IT with a World Computer|provide a World Computer that can replace traditional IT]] and host a new generation of [[Web3:_The_bull_case_for_the_Internet_Computer|Web3]] services and applications that run solely from the blockchain, without the need for traditional IT. It can also play the role of Web3 orchestrator, by interacting with traditional blockchains.

It has a completely unique design that reflects a ground-up rethink of blockchain architecture and the application of modern cryptography, [https://web.archive.org/web/20150914013643/http://dfinity.io/ which can be traced back to 2015]. It was built by the largest [https://dfinity.org/team ongoing R&D effort in crypto], which has employed many notable cryptographers, computer science researchers and engineers. The blockchain underwent genesis in May 2021 and became part of the public internet.

The Internet Computer blockchain's protocols leverage novel [[chain key cryptography]] to combine multiple [[Limitless_Scaling#Subnet Architecture|subnet blockchains]] into a single blockchain. This allows it to [https://en.wikipedia.org/wiki/Scalability#Horizontal_(scale_out)_and_vertical_scaling_(scale_up) horizontally scale] the total volume of hosted [[canister smart contract]], and their computations and data, without limit. These smart contracts run at web speed, and with web-levels of efficiency, and uniquely, thanks to the blockchain architecture enabled by chain key crypto, can process HTTP requests and directly and securely serve interactive web experiences to the end-users of web3 services, without need for trusted intermediaries (whereas on other blockchains, the web experience users interact with is generally built on centralized, insecure and trusted servers or cloud computing services).

Through these kinds of unique capabilities, the Internet Computer provides a platform that can be used to build mass market web3 services that run 100% on-chain, without any need for traditional IT, such as web servers and databases running on cloud computing services. The longer-term objective is that the Internet Computer will completely replace traditional IT, creating a ''blockchain singularity'', in which everything runs fully on-chain in powerful new forms where it is unstoppable and cannot be hacked.

The development of the Internet Computer has heralded numerous notable technological developments, such as [[chain key cryptography]] and programming languages such as [https://wiki.internetcomputer.org/wiki/Motoko Motoko]. In another notable advance, the Internet Computer hosts an advanced [https://en.wikipedia.org/wiki/Decentralized_autonomous_organization DAO] within its protocols, called the [[Network Nervous System]], which provides the community with direct control over network governance, and can upgrade the protocol running on its network nodes, without requiring the network to fork. The network's utility token is ICP (see [[Roles of the ICP utility token]]).

A recent new technological advance has extended the Internet Computer's [[chain key cryptography]] protocols. This has enabled smart contracts hosted on the Internet Computer to directly interact with other blockchains, without need for dangerous centrally-controlled bridges or wrapping (see [[trustless multi-chain web3 using the IC]], and [[Extend Bitcoin, Ethereum and other blockchains|extending Bitcoin, Ethereum and other blockchains]]).

For example, a canister smart contract hosted on the Internet Computer can create bitcoin addresses, and directly send and receive bitcoins on the Bitcoin ledger as though it were hosted by the Bitcoin network itself. This is possible because chain key crypto enables blockchains to create public "chain keys", for which their nodes can create corresponding signatures. Recent work has now made it possible to create ECDSA chain keys. Since [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] is the signature scheme used by most other blockchains, this means the Internet Computer can create TX on other blockchains.

Future work will enable its smart contracts to directly interact with other important blockchains such as [https://ethereum.org/en/ Ethereum]. This also leverages other important features such as [[HTTPS outcalls]]. As a consequence, many believe that the Internet Computer will play the role of an orchestration layer that combines different blockchains in the web3 environment, and helps combine them with off-chain services and systems, such as Web 2.0 services and enterprise systems, in a trustless way.

===Popular places to start===
* [https://www.youtube.com/watch?v=IfM3I8pudFs&t=327s Internet Computer overview video from 2022 IC hackathon]
* [https://www.youtube.com/watch?v=IfM3I8pudFs June 2022 IC hackathon, full launch video]
* [https://dfinity.org/icig.pdf Internet Computer Infographic (PDF)]

* [[Glossary]]

===For a general audience===
* [[Internet Computer overview]]
* [[Internet Computer vision]]
* [https://dfinity.org/roadmap/ Internet Computer roadmap]

===For a more technical audience===
* [https://eprint.iacr.org/2022/087 "Internet Computer for Geeks" paper]
* The [https://dfinity.org/howitworks "How it works" series] with videos and in-depth articles on various topics.
* [https://www.reddit.com/r/dfinity/comments/ozboyi/megathread_technical_amas/ Technical AMAs on Reddit by different IC and DFINITY teams]

== Internet Identity Introduction ==
One of the core benefits of building on the Internet Computer is that end users do not need to pay fees or use tokens to access and use dapps. As an alternative to authenticating from a wallet, users can authenticate with an Internet Identity. Learn more information about Internet Identity (II), a blockchain authentication framework supported by the Internet Computer:

* [[What is Internet Identity]]
* [[How to create an Internet Identity]]
* [[Internet Identity technical overview]]
* [https://identity.ic0.app/ Internet Identity dapp]

==IC for Dapp Users ==

If you use or are interested in using dapps on the Internet Computer, this section will help you understand the user experience benefits of the IC, how to use Internet Identity, or find more IC dapps.

Examples:
* [[Introduction to the Internet Computer for dapp users]]
* [[Index of dapps on the Internet Computer]]

See more in [[Internet Computer for dapp users]]

== IC for ICP Token-holders, Stakers, and Neuron Holders==

The Internet Computer is governed by on-chain governance system called the Network Nervous System (NNS). To participate on governance, users need to stake ICP tokens. This section will explain how the NNS works, ICP tokens, staking, voting, rewards, and options for managing one's ICP.

Examples:
* [[ICP token]]
* [[Tutorials for acquiring, managing, and staking ICP]]
* [[Staking, voting and rewards]]
* [[Governance of the Internet Computer]]
* [[Network Nervous System]]
* [[Total supply, circulating supply, and staked_ICP]]
* [[NNS neuron operations related to maturity]]

See more in [[Internet_Computer_token-holders,_investors_and_neuron_holders|Internet Computer token-holders, investors, and neuron holders]].

== IC for Smart Contract and Dapp Developers ==

The Internet Computer (IC) is a new platform for executing smart contracts. This section contains information for developers, including links to documentation, developer forums, and relevant dashboards.

Examples:
* [[Canisters (dapps/smart contracts)]]
* [https://smartcontracts.org/ Developer documentation on smartcontract.org]
* [https://forum.dfinity.org/ IC community developer forum]


* [[Bitcoin integration]]
* [[SNS Tokenization Considerations]]
* [[Web Speed]]
* [[Web Serving]]
* [[Limitless Scaling]]
* [[Users interact with dapps without tokens]]
* [[Parallelism]]

If you've been programming smart contracts on Ethereum before, you should read [[The Internet Computer for Ethereum Developers]].

See more in [[Internet Computer for smart contract and dapp developers]].

== IC for the Curious, Researchers and Blockchain Enthusiasts ==

This section is for those interested in how the Internet Computer works under the hood. It touches many different subject areas from cryptography, consensus protocols, virtual machines, operating systems, networking, distributed systems, etc.

Examples:
* [https://dfinity.org/howitworks/ How the Internet Computer Works]
* [https://dashboard.internetcomputer.org/ Internet Computer dashboard]
* [[Internet Computer performance]]
* [[DFINITY Foundation]]
* [[Bitcoin integration]]
* [[Third-party security audits]]
* [[Networking]]
* [[ICP technical design documents]]

== For Node Providers ==
Node providers invest in and operate node hardware, which powers the Internet Computer with processing and storage capacity. Running these nodes in data centers provides the high performance and the cost-effectiveness of the Internet Computer. Every node provider is allowed a limited amount of nodes.
* [[Node Provider Onboarding]]
* [[IC OS Installation Runbook - Dell Poweredge]]
* [[IC OS Installation Runbook - Supermicro]]
* [[Storage Runbook]]
* [[Node rewards]]

== Technical Working Groups ==
* [[Identity & Authentication]]
* [[Developer Tooling]]
* [[Ledger & Tokenization]]
* [[Scalability & Performance]]

== FAQs, Tutorials, and How-tos==
Tutorials are guided introductions to user stories, intended for first-time users and characterized by a shallow learning curve. How-Tos are step-by-step instructions for specific, narrow goals.

===FAQs===
* [[FAQ]]

===Best Practices===
Example:
* [[Managing ICP holdings]]
* [[Managing Internet Identity]]
* [[Maximizing Voting and NNS Rewards]]
See more in [[Best Practices]]

=== Tutorials ===
Example:
* [[Tutorials for acquiring, managing, and staking ICP]]
* [[How-To: Claim neurons for seed participants]]
* [[How-To: Create an NNS motion proposal]]
* [[How-To: Set your neuron to follow another neuron]]
* [[How-To: Updating neuron following via quill]]

See more in [[How-Tos]].

==Contributing to the Wiki==

=== How to contribute ===
Anyone can read the wiki. You can also edit pages, all you need to do is [https://wiki.internetcomputer.org/wiki/Special:CreateAccount create an account]. See more in [[Contributing to the wiki]].

==References==

Internet Computer wiki

2022-05-23T13:47:43Z

Bjoern.tackmann: Add node rewards link

Internet Computer wiki

2022-04-19T14:53:04Z

Bjoern.tackmann: /* IC For the Curious, Researchers and Blockchain Enthusiasts */

Internet Computer wiki

2022-04-19T14:52:53Z

Bjoern.tackmann: /* IC For ICP Token-holders, Stakers, and Neuron Holders */

Internet Computer wiki

2022-04-19T14:52:42Z

Bjoern.tackmann: /* IC For Dapp Users */