Internet Computer Wiki - User contributions [en]

How-To: SNS tokenomics configuration

2025-01-08T12:07:43Z

Severin.siffert: fix link to example_sns_init.yaml

== Goal ==
The purpose of this page is to gather information that assists teams in selecting a tokenomics structure for their SNS DAO. Additionally, it aims to aid potential SNS DAO participants in evaluating the proposed tokenomics configurations of an SNS.

== SNS tokenomics set-up ==
The '''SNS governance framework''' is a customizable version of the NNS framework. All its parameters can be set in the [https://github.com/dfinity/sns-testing/blob/main/example_sns_init.yaml SNS initialization file], which also contains a comprehensive guide to these settings. For more detailed information about '''SNS rewards''', please refer to this [https://internetcomputer.org/docs/current/developer-docs/integrations/sns/tokenomics/rewards link].

== SNS decentralization swap ==
In the '''[https://internetcomputer.org/sns/faq#what-is-a-decentralization-swap SNS decentralization swap]''', community members have two ways to get involved. One is '''direct participation''', where they can exchange their ICP for SNS tokens.

Alternatively, community members can engage indirectly through the '''Neurons' Fund''' (NF). The extent of the NF's involvement in a specific SNS swap is decided by the [https://wiki.internetcomputer.org/wiki/Matched_Funding Matched Funding scheme]. This scheme correlates the '''fund participation''' with the level of direct participation. For more details on the Neurons' Fund, visit this [https://internetcomputer.org/docs/current/tokenomics/nns/neurons-fund/ link].

== SNS tokenomics analyzer ==
Use this [https://dashboard.internetcomputer.org/sns/tokenomics dashboard app] to evaluate SNS tokenomics configurations. The tool takes as an input an SNS init file and allows to simulate different levels of direct participation and its impact on key factors

* Token Price Range: Displays the potential exchange rate range between ICP and SNS tokens.
* Matched Funding: Estimates the Neurons' Fund contribution as a function of the simulated direct participation and the overall size of the Neurons' Fund.
* Token Distribution: Shows how tokens are allocated between treasury, swap participants and the development team.
* Voting Power Assessment: Provides a visual representation of the voting power across the community (swap participants) and the developer team.
[[File:SNS tokenomics analyzer visual.png|alt=|center|thumb|900x900px]]

== Frequently asked questions ==

* ''How many and what kind of neurons do you receive when directly participating in an SNS swap ?''
** "In an SNS initialization, a project defines the number of SNS neurons and their dissolve delay range. For instance, a neuron basket with 3 neurons and a 1-month interval will result in neurons with dissolve delays of 0, 1, and 2 months."
* ''How precisely do the minimum and maximum funding targets influence the swap ?''
** "The swap fails if the minimum funding target is not met within the swap window. Conversely, if the maximum funding is reached, the swap concludes immediately."
** "Please note: The minimum and maximum funding target are specified with respect to the direct participation only!"
* ''What should projects consider when setting the minimum and maximum funding targets?''
** "Set a realistic maximum funding target to create scarcity and drive token demand, as reaching this target ends the swap, possibly excluding some participants. A very high maximum can lead to a post-launch price drop, while a very low maximum might limit participation and miss funding opportunities."
* ''What considerations are there when choosing the minimum stake of SNS neurons?''
** "The minimum stake is the lowest amount of SNS tokens required for a neuron. A lower value increases accessibility for those wanting to participate with fewer tokens. However, with a technical limit of 200K neurons in an SNS, a very low minimum stake might lead to too many small neurons."
* ''What should be considered when setting the minimum dissolve delay for SNS neurons?''
** "The minimum dissolve delay is crucial for voting eligibility. It encourages prudent, long-term voting as tokens are locked up. It also offers some defense against attacks, especially those funded by borrowed resources. However, if an attacker gains 51% of the voting power, the minimum staking period becomes irrelevant.

== Further background material ==
* Overall intro to SNS https://internetcomputer.org/sns/
* Tokenomics of a DAO: https://internetcomputer.org/docs/current/tokenomics/sns/tokenomics

Topping up canisters

2023-10-03T12:08:25Z

Severin.siffert:

= Using dfx =
There are two options to top up any canister: By depositing cycles, or by converting ICP to cycles directly.

== Depositing cycles ==

If you have a cycles wallet configured, you can take any amount of cycles from it and deposit them directly into a canister. To do so, use
dfx canister --network ic deposit-cycles <canister id> <amount of cycles>

As an example, to send 10 trillion cycles (TC) to canister <code>fg7gi-vyaaa-aaaal-qadca-cai</code>, you would run
dfx canister --network ic deposit-cycles fg7gi-vyaaa-aaaal-qadca-cai 10000000000000

== Using ICP directly ==

If you have ICP that you want to use to top up any canister, you can run
dfx ledger --network ic top-up <canister id> --amount <amount of ICP to convert>

As an example, to top up canister <code>fg7gi-vyaaa-aaaal-qadca-cai</code> with 10.3 ICP, you can run
dfx ledger --network ic top-up fg7gi-vyaaa-aaaal-qadca-cai --amount 10.3

= Using NNS =

To use ICP to top up a canister via [https://nns.ic0.app/ NNS frontend dapp], follow these steps:

# Go to the "My canisters" tab
# Add the canister to your list of canisters using the "Link canister" button
# Click on the newly linked canister
# Use the "Add cycles" button. This will work even when an error like "there was an error loading the details of the canister" shows up.

The Internet Computer for Ethereum Developers

2023-09-29T07:14:25Z

Severin.siffert: fix broken link

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.
 
 
====User Experience====
 
=====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.
 

=====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.

 
 
====Developer Experience====
 

=====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.
 

=====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].
 

===== 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.
 

=====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://smartcontracts.org/docs/current/developer-docs/deploy/computation-and-storage-costs 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.

 
''1 XDR = 1 Trillion cycles''
 

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.
 
=====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].
 
 
====Scalability and Costs====
 
=====48-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 48-byte 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.
 
=====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.
 
=====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].
 
=====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.
 
 
====Privacy====
 
=====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.
 
=====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.
 
 
====Differentiating Capabilities====
 
=====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.
 
=====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.
 
=====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.
 
=====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].
 
 
===Dictionary===
contract → canister

gas → cycles

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

(validator) nodes → replicas

Topping up canisters

2023-02-01T10:28:52Z

Severin.siffert:

Topping up canisters

2023-02-01T10:26:45Z

Severin.siffert:

= Using dfx =
There are two options to top up any canister: By depositing cycles, or by converting ICP to cycles directly.

== Depositing cycles ==

If you have a cycles wallet configured, you can take any amount of cycles from it and deposit them directly into a canister. To do so, use
dfx canister --network ic deposit-cycles <canister id> <amount of cycles>

As an example, to send 10 trillion cycles (TC) to canister <code>fg7gi-vyaaa-aaaal-qadca-cai</code>, you would run
dfx canister --network ic deposit-cycles fg7gi-vyaaa-aaaal-qadca-cai 10000000000000

== Using ICP directly ==

If you have ICP that you want to use to top up any canister, you can run
dfx ledger --network ic top-up <canister id> --amount <amount of ICP to convert>

As an example, to top up canister <code>fg7gi-vyaaa-aaaal-qadca-cai</code> with 10.3 ICP, you can run
dfx ledger --network ic top-up fg7gi-vyaaa-aaaal-qadca-cai --amount 10.3

= Using NNS =

To use ICP to top up a canister via [https://nns.ic0.app/ NNS], follow these steps:

# Go to the "My canisters" tab
# Add the canister to your list of canisters using the "Link canister" button
# Click on the newly linked canister
# Use the "Add cycles" button

Topping up canisters

2023-02-01T10:17:03Z

Severin.siffert: Created page with "= Using dfx = There are two options to top up any canister: By depositing cycles, or by converting ICP to cycles directly. == Depositing cycles == If you have a cycles walle..."

The Internet Computer for Ethereum Developers

2022-06-01T13:16:54Z

Severin.siffert: fix broken link

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, we mostly talk in terms common to Ethereum developers and provide a little dictionary in the end. We hope that this 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.
 
 
====User Experience====
 
=====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.
 

=====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 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 [http://icapps.xyz/ http://icapps.xyz] for example and try a few of the popular apps on the IC.

 
 
====Developer Experience====
 

=====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.
 

=====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].
 

===== 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 ICO 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.
 

=====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://smartcontracts.org/docs/current/developer-docs/deploy/computation-and-storage-costs 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.

 
''1 XDR = 1 Trillion cycles''
 

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.
 
=====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].
 
 
====Scalability and Costs====
 
=====48-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 48-byte 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.
 
=====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.
 
=====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].
 
=====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.
 
 
====Privacy====
 
=====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.
 
=====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.
 
 
====Differentiating Capabilities====
 
=====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] 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.
 
=====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.
 
=====Contracts can hold private keys and sign messages (Soon)=====

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 an upcoming [https://dfinity.org/howitworks/threshold-ecdsa-signing feature] a similar mechanism will be 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. 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.
 
=====Contracts can call web services (Soon)=====

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 will soon be possible to call web services from inside a contract. You can read more about this feature on the [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].
 
 
===Dictionary===
contract → canister

gas → cycles

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

(validator) nodes → replicas

The Internet Computer for Ethereum Developers

2022-06-01T13:14:28Z

Severin.siffert: update location of computation/storage cost

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, we mostly talk in terms common to Ethereum developers and provide a little dictionary in the end. We hope that this 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.
 
 
====User Experience====
 
=====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#:~:text=Internet%20Identity%20builds%20on%20the,ID%2C%20or%20fingerprint%20scanner. 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.
 

=====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 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 [http://icapps.xyz/ http://icapps.xyz] for example and try a few of the popular apps on the IC.

 
 
====Developer Experience====
 

=====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.
 

=====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].
 

===== 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 ICO 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.
 

=====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://smartcontracts.org/docs/current/developer-docs/deploy/computation-and-storage-costs 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.

 
''1 XDR = 1 Trillion cycles''
 

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.
 
=====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].
 
 
====Scalability and Costs====
 
=====48-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 48-byte 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.
 
=====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.
 
=====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].
 
=====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.
 
 
====Privacy====
 
=====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.
 
=====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.
 
 
====Differentiating Capabilities====
 
=====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] 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.
 
=====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.
 
=====Contracts can hold private keys and sign messages (Soon)=====

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 an upcoming [https://dfinity.org/howitworks/threshold-ecdsa-signing feature] a similar mechanism will be 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. 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.
 
=====Contracts can call web services (Soon)=====

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 will soon be possible to call web services from inside a contract. You can read more about this feature on the [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].
 
 
===Dictionary===
contract → canister

gas → cycles

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

(validator) nodes → replicas

Dealing with cycles limit exceeded errors

2022-03-03T08:06:30Z

Severin.siffert: Created page with "=What is the cycles limit exceeded error?= On the Internet Computer every update function call is limited to a certain hard-coded maximum runtime. This maximum runtime is call..."

=What is the cycles limit exceeded error?=
On the Internet Computer every update function call is limited to a certain hard-coded maximum runtime. This maximum runtime is called <code>cycles limit</code>. When one of your function calls tries to run longer that this limit, the function call is aborted and the canister state is rolled back to the state before the function call. When this happens, you may receive an error message that looks like this:
Error: The Replica returned an error: code 5, message: "Canister <canisterid> exceeded the cycles limit for single message execution."

=Common causes of cycles limit exceeded errors=
There are a few common causes for this error:
* Loops or recursion with bad termination conditions.
* Copying lots of data to/from stable memory during <code>pre_upgrade</code> or <code>post_upgrade</code>.
* Computing the hash of a large chunk of data.

=Dealing with the cycles limit=
Here's a few ideas to work around the cycles limit:

==Speeding up your code==
If you run into the cycles limit because of long-running computations, it may be beneficial to optimise your code. For recursive calls, see if [https://en.wikipedia.org/wiki/Memoization memoization] could help speed up your code.

==Split up your work into multiple functions==
Certain long-running operations can be split into multiple parts. For example, if you copy a large vector from stable memory within your <code>post_upgrade</code> function, you could only load the most necessary data (such as user accounts) during <code>post_upgrade</code> and then load other data in chunks with manual calls to other functions.

If you decide to split computation into multiple functions, make sure to put in the necessary safeguards to prevent your canister from breaking:
* If you have a function that does a lot of one-time work, it shouldn't be possible to do the work many times. Otherwise a malicious user can burn cycles very quickly from your canister.
* If your canister does not work properly before a certain amount of work is done, disable other functions by returning an error until the canister is ready.

Internet Computer for smart contract and dapp developers

2022-03-03T07:24:20Z

Severin.siffert:

==Intended Audience==

This article is an entry point for developers interested in building smart contracts and dapps on the IC.

==Developer Documentation==

===Key Concepts===

* [[Canisters (dapps/smart contracts)]]
* [[Internet Identity technical overview]]
* [[Neuron attributes and commands]]

===Building Dapps===
* [[Index of libraries for Internet Computer development]]
* [[Best practices for a high traffic dapp launch]]
* [[Current limitations of the Internet Computer]]
* [[Bitcoin integration]]
* [https://dfinity.frontify.com/d/XzkdhhDptijE/dfinity-brand-guide#/internet-computer/powered-by-badges-1 "Powered by the IC" badges]
* [[Dealing with cycles limit exceeded errors]]

==Developer Community==

* A common resource for developers unblocking each other is the [https://forum.dfinity.org/ developer forum]. Topics there include things such as help with SDK installation, Motoko, canister troubleshooting, and designs.

* [https://smartcontracts.org/ Developer documentation on smartcontract.org]
* [https://forum.dfinity.org/ IC community developer forum]