L1 comparison
The promise of a World Computer and the emergence of a Blockchain Singularity has far reaching consequences in technology, sociology, economics, politics, communication, entertainment, and most aspects of our digital lives. As the industry is one of rapid innovation and progress, and as projects constantly and dynamically change, it's important to take stock, every now and then, to note how the industry is doing, and to check if the Internet Computer is on track to achieve the goals of decentralization, scalability, usability, and functionality.
The industry is now moving out of its infancy, which is seen by the increasing number of smart contract developers, rather than core protocol developers, and users wanting to fully engage with a platform, rather than simply sending transactions back and forth. The shift away from simple payment systems, towards Web3 is well on its way, and it's within this scope that this page attempts to map the blockchain landscape.
Top performing blockchain projects are compared across a number of metrics that are expected to yield a 'good' Web3 experience under the categories of core protocol, developer experience, and user experience.
Unless otherwise stated, all data is correct as of February 7th 2024. Metrics are explained and references are given below.
Base comparisons
This section compares standard metrics that are used to measure performance of the core protocol of popular blockchain projects. Note that these metrics should not always be taken at face value. While references are listed below to note where the figures can be found, it's not always clear how these figures are computed. Additionally, parts of different projects may have the same name, but often are constructed differently (most notably, transactions), and so should not be compared blindly like-for-like. The a16z blog has a nice article describing how the industry should think about metrics.
| Metrics / L1 | Average MIEPs | Average TPS | Average finality | Average block time (seconds) | Average tx Cost | Average energy consumption per transaction (wh/tx) | Size of network (nodes) | On-Chain storage cost (1GB p/a) |
|---|---|---|---|---|---|---|---|---|
| ICP | 20000 | 3200 (update calls) | 0.64 secs | 0.48 | $0.0012 | 0.003 | 559 | $5.35 |
| Avalanche | 46 | 14 | unclear | 2.3 | $0.035 | 2.395 | 1752 | unclear |
| Cardano | 2 | 3 | 1 day | 20 | $0.1 | 41.27 | 2876 | $1,480 |
| Ethereum | 5* | 12 | 15min | 12 | $8.4 | 9.956 | 6395 | $2,439,827 |
| Near | 1600 | 40 | 3.3secs | 1.1 | $0.00013 | 0.602 | 204 | $1,468 |
| Solana | 90 | 700 (non-voting) | 12secs | 0.54 | $0.005 | 0.517 | 1617 | $35,984 |
- Average MIEPs measures millions of executed instructions per second which is an approximation of useful work performed. For ICP, Avalanche and Solana the calculation follows from the reported cycles / gas / compute units used in execution. For Near, we approximate by assuming 1 Tgas corresponds to 1ms of CPU time at 2B instructions / 1s of CPU. For Cardano we give the maximum capacity corresponding to 20ms of CPU time per block at 2B instructions / 1s of CPU. For Ethereum we go by the block gas limit. (*However, the EVM is a 32-byte stack machine, so we count 1 gas as 4 CPU instructions to be generous). Further remarks can be found here: "Not all transactions are equal".
- Average TPS measures the transactions processed per second - note that the interval over which these are measured does vary across chains.
- Average finality refers to the amount of time that passes between the proposal of a new valid block containing transactions until the block has been finalized and its content is guaranteed to not be reversed or modified (for some blockchains, e.g., Bitcoin, this guarantee can only be probabilistic). For ICP, the reported value is the average over all subnets of their node’s average time between starting a round until a valid finalization for this round is available.
- Average block time refers to the amount of time between blocks (per subnet on the IC)
- Average tx Cost measures the cost of a transaction. Note that the definition of 'transaction' varies widely across chains. The dollar amounts are computed by converting the native token cost cycles/gas/fee needed per transaction, to USD given the exchange rate.
- Average energy consumption per transaction measures the network energy consumption to process a transaction (measured in watt hours). Figures true as of December 2023. Source: Carbon Crowd Sustainability Report 2023.
- Size of network (nodes) notes the number of nodes currently validating the blockchain.
- On-chain storage cost gives the dollar cost of storing 1GB of data per year on chain. For Near and Solana, to store data one needs to maintain a specified token balance. We convert this balance to USD and annualise by multiplying by 5%. For Cardano and Ethereum, the user pays to store the data "forever", and again we annualise by multiplying this cost by 5%.
Comparing developer experience
Whether they were writing games, operating systems or text editing applications, in the 70s, 80s and early 90s, developers always had to face limitations imposed by hardware. Applications were constrained to accessing a few kilobytes of memory through small stacks and heaps, using limited (and constantly changing) instruction sets, and using significant amounts of power to run instructions. The history repeats itself in the blockchain landscape these days. Application developers are limited to stack sizes of a few kilobytes to several megabytes at best. Persistent storage is expensive and limited. Programmers are bound to using cumbersome APIs that make hidden assumptions in terms of numbers of executed instructions. And, moreover, most chains operate inefficiently, burning too much power per executed transaction. This not only limits the types of applications that can be deployed on chain, but also increases development and testing time (and cost).
As opposed to all existing blockchains, the IC brings modern programming to on-chain developers, allowing them to use time for creativity rather than fixing memory packing issues or spreading computation in small iterations that do not hit instruction limits. The IC programming model offers orthogonal persistence, large stack and heap spaces (4 GiB), stable storage of 400 GiB in mainstream languages, such as Rust, JavaScript, or even Python.
| Metrics / L1 | Stable tx cost | HTTPs outcalls | Smart contract language support | Max stack size | Max persisted memory (per smart-contract) | Active developers (full-time / monthly) | Active repositories |
|---|---|---|---|---|---|---|---|
| ICP | ✅ | ✅ | Motoko (native), Rust, TypeScript, Python | 4 GiB | 400 GiB | 161/ 644 | 3973 |
| Avalanche | ❌ | ❌ | Solidity | 455 / 1485 | 1901 | ||
| Cardano | ❌ | ❌ | Plutus (native), Haskell | 170 / 490 | 1252 | ||
| Ethereum | ❌ | ❌ | Solidity (native), Vyper, Yul, FE | 32 KiB | 2^261 B | 2392 / 7864 | 29117 |
| Near | ❌ | ❌ | Rust, Javascript | 256 KiB | 32 KiB | 282 / 1137 | 5352 |
| Solana | ❌ | ❌ | Rust C, C++ | 436 / 1615 | 6137 |
- Stable tx cost provides the ability to have predictable costs for computation
- HTTPs outcalls is the ability to communicate directly with Web2 services (outside of the network)
- Max stack size is the maximum size the stack can grow for smart contracts and serves as a measure for the complexity of code that is supported by each platform
- Max persisted memory is the maximum size of persisted memory supported by each platform. Persisted memory is preserved across individual function calls
- Active developers counts the number of developers who made commits on more than 10 days in a month (full-time) or original code authors who made commits in a given month. Source Electric Capital (31/12/23).
- Active repositories are sourced from the Electric Capital crypto ecosystems list. Figures true as of 15/12/22
Comparing user experience
It is widely accepted that the Web3 user experience needs massive development before mainstream adoption is likely. This sections starts to map out key metrics for Web3 usability. First and foremost is privacy, identity management and authentication. On many projects, every interaction that a user ever makes can be traced and monitored. While transparency is good for some things, it's argued that this is a severe hindrance to adoption. Financial privacy and the freedom to interact should be paramount. The tools needed to interact with a project are also noted. These can be seen as a measure of accessibility and openness to onboarding. Finally, metrics about participation in the network are included. A large draw of Web3 is the fact that users can become owners and drivers of the platform. Here the percentage of native tokens staked as a measure of user confidence and participation in the project are included.
| Metrics / L1 | Privacy-preserving authentication | Prerequisites to use | Staking ratio | Monthly active wallets |
|---|---|---|---|---|
| ICP | ✅ | Browser | 73.89% | 93k |
| Cardano | ❌ | Browser, browser extension, tokens | 71.58% | |
| Avalanche | ❌ | Browser, browser extension, tokens | 61.78% | 390k |
| Algorand | ❌ | Browser, browser extension, tokens | 51.17% | |
| Ethereum | ❌ | Browser, browser extension, tokens | 13.57% | 15m |
| Near | ❌ | Browser, browser extension, tokens | 43.19% | |
| Solana | ❌ | Browser, browser extension, tokens | 68.59% | 655k |
- Privacy-preserving authentication notes whether a project allows privacy-preserving interactions with the blockchain.
- Prerequisites to use lists what is needed to interact with the project
- Staking ratio gives the percentage of native tokens that are staked in the protocol. The staking ratio metrics are from Staking Rewards and are correct as of 19.12.2022
- Monthly active wallets counts the wallet addresses that sent or received native currency in a given month (December 2022)
A note about decentralization
Decentralization is key to make web3 dapps run in a trustless manner. However, decentralization has many dimensions and cannot be understood and quantified using a single number or coefficient. One can distinguish between a) the decentralization of the entities running the machines on top of which a protocol runs, b) the decentralization of the consensus and sharding mechanism, c) the governance system, the owners of liquid tokens etc. In this case, the whole is greater than the sum of its parts and one cannot understand decentralization as a single discussion on each of these topics.
See Decentralization Wiki Page for more details.
References
- ICP : IC Dashboard
- ADA : Cardano explorer and cexplorer
- AVAX : Snowtrace and Avalanche explorer
- ETH : Etherscan
- NEAR : Near explorer and Near docs
- SOL : Solana website and Solana beach