The Internet Computer for Ethereum Developers

From Internet Computer Wiki
Revision as of 10:20, 25 January 2024 by Ruediger.birkner (talk | contribs) (Removed the mention of the service worker as it is not being used anymore.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


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 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 WASM byte code. This allows 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 mechanics of the Internet Computer have a look at the following resources:

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 ID or fingerprint scanner. Internet Identity which is 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 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:

  1. A user points her browser to the domain of the application.
  2. The front end of the application is served by a traditional hosting provider.
  3. 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.
  4. The user connects to the application with her wallet.
  5. 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.
  6. The user approves using the wallet and the wallet submits the signed transaction.
  7. 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.

  1. Chain-key technology and subnets allow for lightweight verification and lower costs because of lower replication and horizontal scaling.
  2. The reverse gas model allows contracts to be pre-loaded with gas to simplify user onboarding
  3. Internet Identity allows privacy-preserving authentication to services on the IC using WebAuthentication and a delegation mechanism. Cryptographic secrets are managed with secure hardware.
  4. Boundary nodes and certified asset contracts allow serving the front end directly from a contract.

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

  1. 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 an ic0.app domain.
  2. The user is asked to login with Internet Identity or another authentication method.
  3. 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 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 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 Service Nervous System, a customizable turn-key solution to govern services on the IC, inspired by 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 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 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.

  1. 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.
  2. 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 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 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:

  1. It can be burned to create cycles that are needed to pay for resources on the IC
  2. 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 here or here.

Scalability and Costs


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

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 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 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 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 heartbeat functionality or 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 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 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 Web page, the docs or forum, or watch the community conversations.

Dictionary

contract → canister

gas → cycles

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

(validator) nodes → replicas

Retrieved from "https://wiki.internetcomputer.org/w/index.php?title=The_Internet_Computer_for_Ethereum_Developers&oldid=7056"