Chromia vs EVM

This page provides a high-level comparison between Chromia and traditional EVM-based blockchains like Ethereum. If you're coming from a Solidity background, this guide will help you understand how common smart contract patterns translate into Chromia's model using Rell.

Key differences

State model: Entities vs structs

• EVM: You declare structs and manually manage arrays, mappings, and storage.
• Chromia: You define entitys, and they become relational tables stored on-chain automatically. No manual storage logic required.

Example:

struct Company {
  string name;
  string address;
}
Company[] public companies;

entity company {
  name: text;
  address: text;
}

Operations vs functions

• EVM: Public/external functions on contracts, often require gas and access modifiers.
• Chromia: operations represent signed, transactional logic; no gas required. They are isolated and clean.

operation create_company(name: text, address: text) {
  create company(name, address);
}

Storing and accessing application state

• EVM: Due to gas costs and storage limitations, developers often minimize state storage inside contracts and instead emit events to record additional information externally for off-chain indexing and reconstruction.
• Chromia: Developers store the full application state directly on-chain inside entity tables. There is no need for off-chain indexing — data remains on-chain, structured relationally, and can be queried efficiently.

Queries vs view functions

• EVM: view and pure functions allow users to read the contract state without modifying it.
• Chromia: query operations allow reading structured relational data directly from the blockchain, similar to SQL queries.

query get_company(id: rowid) {
  return company @ { .rowid == id };
}

Authentication: FT4 vs msg.sender

• EVM: You use msg.sender to determine the sender and enforce authorization.
• Chromia: You use auth.authenticate() (via FT4) to retrieve the signed-in user.

val account = auth.authenticate();

Chromia also supports authorization constraints like op_context.is_signer() for admin-level operations.

Scheduled logic: __begin_block() vs bots

• EVM: You need off-chain bots or cron jobs to trigger time-sensitive events like auction settlement.
• Chromia: You can define operation __begin_block(height: integer) which runs automatically with every new block (if any tx occurs).

operation __begin_block(height: integer) {
  val expired = auction @* { .end_at <= op_context.last_block_time and not .ended };
  for (a in expired) {
    end_auction(a.id);
  }
}

Note: this only runs when a transaction triggers a new block — it's not guaranteed on a time basis unless activity occurs.

Developer experience

• Rell feels more like backend or database programming: concise, structured, readable.
• You work with types, queries, and state as first-class relational data.
• There's no need to optimize every byte — no gas model means better UX and simpler dev workflows.

Summary

Topic	EVM / Solidity	Chromia / Rell
Data storage	Manual structs, mappings, arrays	Declarative entity tables
Gas fees	Required per tx	None (resource leasing model)
State access	view / pure functions	On-chain relational query operations
Authentication	msg.sender	auth.authenticate() (FT4)
Scheduled logic	Off-chain bots	__begin_block() on block activity
Dev experience	Smart contract centric	Structured, DB-inspired dapp backend

In the next section, you will explore how Chromia's architecture is structured. You will learn about the main network entities, how the consensus algorithm operates, the primary types of blockchain networks in Chromia, and how the entire system functions.