A resource guide that explains the differentiating capabilities of the Internet Computer blockchain compared to Ethereum.
For many developers, their 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 actually works.
In this article, we’ll explain the differences that most developers encounter and present the differentiating capabilities of the Internet Computer. Since the languages of Ethereum and the Internet Computer slightly differ, we mostly talk in terms common to Ethereum developers and provide a little dictionary:
contract → canistergas → cyclesshard → subnet (Not entirely true, since Ethereum currently only considers data shards)(validator) nodes → replicas
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 Network Nervous System (NNS), which is essentially a Decentralized Autonomous Organization (DAO) running on the initial subnet — also called NNS — 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 WebAssembly (Wasm) byte code. This allows developers to create contracts in a range of programming languages. In addition, there’s 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 the mechanics of the Internet Computer, have a look at the following resources:
Without further ado, we’ll dive into some of notable differences between Ethereum and the IC. We organize these differences according to the following categories:
User ExperienceDeveloper ExperienceScalability & CostPrivacyDifferentiating Capabilities
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 Internet Identity, a cryptographic authentication system based on the 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 is much more flexible in this regard.
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 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 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 WebAuthentication and a delegation mechanism. Cryptographic secrets are managed with secure hardware.Boundary nodes and certified asset contracts allow serving the front end directly from a contract.
So what 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 Java Script agent to verify the 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.
Try it yourself. Head over to icApps, for example, and try a few of the popular dapps on the IC.
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 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 to 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. Therefore, The DFINITY foundation is working on the Service Nervous System, a customizable turnkey solution to govern services on the IC, inspired by the Network Nervous System that governs the IC.
Inter-contract calls are asynchronous and not atomic
The Ethereum Virtual Machine (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 completely with no effect but 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 flash loans 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 in a contract 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 here in the documentation. There’s also a 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 are often anxious about the cycle consumption and that their contracts will be deleted suddenly. However, there are two effective safeguards built into the IC.
There’s an 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 freezing_threshold that 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.
Still, if you want to implement an autonomous service on the IC you have to think about its economic viability — otherwise it will get out of cycles and will get erased.
Gas fees are predictable
In the EVM, specific operations (Opcodes) have a defined cost measured 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 to (but more extensive than) gas in Ethereum, the IC has a set of fixed prices in cycles for various resources. The main difference, however, is that the price of cycles is pegged to SDR, which is based on a basket of the world’s main currencies.
1 SDR = 1 Trillion cycles
The exchange rate between SDR 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 NNS 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 here and here.
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 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 back-end logic. For an overview of common costs on the IC, have a look at the Computation and Storage Cost documentation.
There is generally 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 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.
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 contractThe name of the contractThe hash of the WASM module of the contractThe 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.
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 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 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 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 forum and watch the community conversations.
