Chromia presents a highly distinctive technical approach through its cluster architecture, relational database, and newly developed programming language.
Chromia employs a cluster architecture consisting of dApp clusters and system clusters, achieving horizontal scalability by independently operating sidechains within each cluster.
Chromia's Postchain validates transactions and queries from clusters based on the eBFT consensus protocol, executes dApp chain code, and updates the state of each dApp chain.
Chromia adopts a relational database instead of a key-value database and introduces Rell, a SQL-like programming language, providing an effective environment for processing complex queries while offering a familiar development experience for existing developers.
Along with its mainnet launch, Chromia is introducing features such as native $CHR staking and 'Extensions', particularly focusing on developing as a data layer for AI infrastructure by maximizing the advantages of its relational database architecture.
At a point where the concept of blockchain has become significantly mainstream, it's rare to find people discussing the fundamental definition of blockchain anymore. However, for an in-depth examination of blockchain, understanding its essential characteristics must come first. What is blockchain? While blockchain is generally defined as a distributed ledger system, at a more fundamental level, blockchain is ultimately just a database system. This is because all user activities are stored as data, and all transactions occurring on the blockchain directly affect the state values of the entire system.
Most existing blockchains have adopted a key-value database structure. This is not coincidental but rather a choice based on clear technical advantages. The simplicity and scalability provided by key-value databases offer crucial benefits in implementing distributed systems. Unlike relational databases that require complex schemas, the key-value structure makes it easier to maintain data consistency in distributed environments and is optimized for blockchain's essential functions of transaction processing and state management (I will elaborate on this in more detail later). Additionally, integration with cryptographic data structures like Merkle trees occurs naturally.
Then, is the adoption of a key-value structure inevitable in blockchain architecture? Is it impossible to implement an efficient blockchain using other database paradigms? The answer to this is firmly "no." From a researcher's perspective, the greatest appeal of this field lies in the fact that there are no established absolute answers yet. This means that various technical attempts all hold potential value. As a researcher, I believe we have a responsibility to pay attention not only to the dominant methods adopted by existing blockchains but also to projects that boldly break away from these conventions to present innovative methodologies.
For example, if a blockchain adopted a relational database structure with the complexity I mentioned earlier instead of a key-value structure, wouldn't it be worth examining at least once? This is regardless of whether the project succeeds or fails (and it's too early in the market to definitively declare what has succeeded or failed anyway). Despite the clear advantages of the key-value structure, if they chose a relational database, they must have their own unique technical rationale. In this article, I would like to introduce an interesting blockchain project that not only adopted a relational database structure but also departed from existing paradigms in programming language selection. This is the story of Chromia.
As we'll examine Chromia's technical characteristics in detail later, as briefly mentioned above, Chromia presents methods that differentiate it from other blockchains in terms of how it stores data and its development of its own programming language. However, we must be clear that deviating from the mainstream doesn't always guarantee positive results. In fact, proposing new methodologies requires overcoming more challenges based on deeper and broader knowledge of the field compared to traditionally adopted methods. In this regard, there's another reason to highlight Chromia's attempt: their innovative approach isn't a hasty proposal of a new meta, but rather is grounded in the unique background and deep understanding of blockchain possessed by its creators.
The members of ChromaWay, which created Chromia, established their credentials in the blockchain industry relatively early. In particular, CTO Alex Mizrahi and COO Or Perelman were active in early Bitcoin wallet projects and were early contributors to Colored Coins, a protocol that adds specificity to Bitcoin. Developed in 2012, Colored Coins is a protocol that defines specific assets by adding unique identifiers or metadata to Bitcoin transactions, and is especially well-known as a precursor to NFTs.
While concepts like NFTs and asset tokenization are now widely used, and wallets are commonplace for anyone using on-chain services, token standards and wallets have become established infrastructure. However, remembering that this was a period when blockchain had just emerged and there were no predetermined rules, allowing various ideas to newly germinate, we can see that these individuals were among those who dove into development to experiment with blockchain's utility. Through their background, we can understand that ChromaWay's members, much like Chromia with its uniquely distinctive architecture, were already familiar with proposing new methodologies rather than blindly accepting existing ones.
Furthermore, ChromaWay originally started by creating Postchain, a private blockchain, in 2016, and participated in e-Krona, Sweden's CBDC project. From this point, Postchain was already adopting SQL databases, conceived from concerns about key-value databases' dependency on external storage and complexity in data queries. The Chromia we know today is a public blockchain created by integrating sidechains for dApp construction into Postchain and modifying its consensus model.
The journey Chromia has taken since its launch is quite unique as well. Since publishing its whitepaper in 2019, it took 4-5 years until the recent mainnet launch. To evaluate this honestly, considering that most blockchain projects typically follow a standard pattern of pre-campaign and mainnet launch within about a year, dedicating five years until mainnet launch is an exceptional case.
2.2.1 What is a Cluster?
Source: Chromia Docs
The Chromia blockchain operates in a cluster format where node groups, differentiated by their specialized functions, work in interconnection. These clusters are further divided into dApp clusters and system clusters, each serving different roles. dApp clusters are responsible for hosting decentralized applications, while system clusters serve as central hubs responsible for operations such as collecting block headers, EVM compatibility, and code storage in the Chromia network.
This structure is specialized in achieving horizontal scaling of the Chromia blockchain by separating the areas of responsibility between dApp clusters and system clusters. When demand for a particular dApp increases, the number of transactions generated by that dApp will also increase dramatically.
In traditional single-chain structures, all transactions must be processed sequentially on one chain, meaning increased transaction volume from a specific dApp can strain the entire network's processing capacity. While solutions such as improving validator hardware performance or implementing transaction parallelization have been proposed to optimize latency, Chromia, as mentioned earlier, seeks to solve network performance degradation issues by presenting a new approach optimized for its blockchain rather than blindly accepting dominant methodologies. (This is particularly aimed at optimization for relational databases, which we'll discuss in detail later.)
The approach Chromia presents is a multi-chain structure where each dApp maintains its own sidechain. Each dApp is managed as a sidechain that possesses its own computing resources, storage, and dedicated nodes, and these sidechains are bundled into clusters, thereby solving the problem of a single dApp impacting the entire network. This unique structure differs from other blockchain networks where a single operating system is responsible for all blockchain operations. Instead, each dApp processes traffic through its independent sidechain, and these sidechains are connected through clusters, preventing the issue of overall network performance degradation caused by a single dApp.
Therefore, the interconnection of sidechains and clusters plays a central role in Chromia's architecture. In the following sections, we will examine in detail the dApp chains (which refer to dApp sidechains), and both dApp clusters and system clusters, which are divided based on their different roles and the different dApp chains they manage.
2.2.2 dApp Cluster
A dApp cluster is an environment where nodes host decentralized applications in the Chromia network. To explain dApp clusters, we must first understand their constituent components. A single dApp cluster operates by managing multiple 1)dApp chains and a 2)cluster anchoring chain. Let's start by examining the dApp chain, which serves as the starting point for horizontal scaling.
1)dApp Chain
Chromia's dApps are built as dApp chains, each possessing different sidechains. A dApp chain stores the data necessary for operating its respective dApp and leases dedicated computing resources and storage from the Chromia network (dApp Container) to ensure consistent transaction processing for the dApp.
Chromia's dApp chains retain the advantages of typical sidechains. dApp chains can maintain their integrity through the typical two-way pegged structure of sidechains, either by verifying data through connection with the parent chain or by committing hashes to it. Here, the cluster anchoring chain, which we'll discuss later, serves as the parent chain responsible for validating each dApp chain.
This structure, where dApps within the dApp cluster have their own sidechains, is useful in securing horizontal scaling of the Chromia network. For example, even if security issues or network congestion occur in one dApp chain, the remaining dApp chains can maintain normal operation without being affected by these issues. This design allows each sidechain to store and process all transaction data on-chain without relying on separate off-chain storage, and can create good synergy in performing tasks that require large amounts of data queries, such as games or Large Language Model (LLM) training.
2)Cluster Anchoring Chain
The cluster anchoring chain ensures the integrity of data generated by dApp chains. Anchoring refers to the process of storing hashed block headers in another blockchain, where one blockchain prevents potential flaws or manipulation in the consensus process by referencing another blockchain. Anchoring in Chromia's dApp cluster operates in the same way. In this process, it executes a mechanism for validating dApp chain states by hierarchically storing dApp chain data up to the system anchoring chain of the system cluster.
For each block generated in the dApp chain, that block's header is sent to cluster anchoring and hashed.
The cluster anchoring chain waits to receive block headers from the dApp chain.
Upon receiving the block header, it hashes it and generates a block containing the hashed block header.
The system anchoring blockchain follows the same process - the system anchoring chain receives block headers from the cluster anchoring chain and generates blocks. If consensus fails, the system anchoring chain can validate the state of all clusters by referencing the hashed block headers.
Finally, the system anchoring chain provides additional security by anchoring to Ethereum, establishing safeguards against attacks such as reorg attacks.
According to the above method, the dApp chain exists as a sidechain for operating its respective dApp, and the cluster anchoring chain secures the dApp chain. So, what role do the nodes in the dApp cluster play, which integrate dApp chains and cluster anchoring chains into a single cluster for operation?
First, nodes in the dApp cluster validate transactions from dApp chains and appropriately route validated transactions back to dApp chains. Therefore, when a dApp chain is newly deployed or updated, the dApp chain's statements always go through a process of validation and replication by all nodes in the dApp cluster.
Second, nodes in the dApp cluster maintain a state that stores all information about the dApp chain, including the Rell code written for dApp chain operation and dApp chain node details. Based on this information, nodes determine which dApps to execute within the dApp cluster.
At this point, nodes maintain a copy of the directory chain, part of the system cluster, to store dApp chain information. Here, the directory chain is responsible for data storage in the system cluster, another cluster. This structure of maintaining a separate copy of the directory chain within the dApp cluster was designed to ensure the resilience of the entire Chromia network by enabling nodes to maintain the operational state of all dApp chains in the cluster under any circumstances.
2.2.3 System Cluster
While dApp clusters manage dApp chain operations, the system cluster serves as the central hub of the Chromia network. In the system cluster, sidechains with different roles are responsible for the overall operation of the Chromia network. The sidechains within the system cluster are divided into five system chains: 1)Directory Chain, 2)Economy Chain, 3)System Anchoring Chain, 4)Transaction Submitter Chain, and 5)EVM Event Receiver Chain. These interact complementarily to enable smooth operation of the Chromia blockchain.
1)Directory Chain The directory chain stores details such as the Rell code embedded in dApp chains within dApp clusters, chain updates, and node information. As explained above, since dApp clusters have copies of the directory chain, if issues arise in dApp clusters or chains, they can be quickly restored through the directory chain, which serves as the source of data stored in clusters and chains.
2)Economy Chain The economy chain is literally the system chain responsible for the economic aspects of the Chromia blockchain. DApp chains in dApp clusters lease dedicated computing resources and storage (containers) from the Chromia network to ensure consistent transaction processing. The economy chain charges rental fees for dApp chain containers and provides incentives to node providers for validation.
An important aspect to examine alongside the economy chain is the container costs it charges to dApp chain builders. Builders constructing dApp chains can pay container costs with $CHR, Chromia's native token, to lease nodes, computing resources, and storage necessary for operating sidechains. This eliminates the need for dApp chain builders to operate their own nodes, with the economy chain calculating and charging the resulting fee costs.
3)System Anchoring Chain The system anchoring chain performs the same role as the cluster anchoring chain in dApp clusters, ensuring the integrity of the Chromia network by collecting block headers from cluster anchoring chains and generating blocks. In other words, after the cluster anchoring chain receives block headers from dApp chains and generates blocks, the system anchoring chain receives block headers from cluster anchoring chains and generates blocks. In Chromia network's hierarchical anchoring structure, the system anchoring chain plays a crucial role in overall network security by performing final block header anchoring before additional anchoring to the Ethereum network.
4)Transaction Submitter Chain The transaction submitter chain receives block headers from the system anchoring chain and periodically submits transactions to the Ethereum blockchain to generate blocks on Ethereum. It's important to note that although Chromia ultimately submits transactions to Ethereum, it's not structured like an L2 where transaction finality is guaranteed by Ethereum.
Rather, Chromia's dApp chains and system chains are all composed of sidechains, allowing each chain to secure its own transaction finality. Specifically, finality is considered secured when two-thirds of nodes in each chain sign and commit to add a block. However, to prevent additional attack vectors like reorg attacks, additional security is secured by ultimately storing block headers on Ethereum. The transaction submitter chain is the system chain that submits system anchoring chain block headers to generate blocks on Ethereum.
5)EVM Event Receiver Chain One advantage of Chromia not mentioned earlier is its smooth compatibility with the EVM execution environment. Therefore, a system chain acting as a bridge to the EVM environment is necessary, and the EVM receiver chain serves this role. For example, when a user deposits $CHR tokens into an Ethereum-based $CHR token contract, the EVM event receiver chain reads the contract's updated statement and notifies the economy chain of the newly updated details. Once the deposit of Ethereum-based $CHR is confirmed normally, the economy chain allocates mainnet-based $CHR tokens equivalent to the deposited amount on the Chromia network.
2.2.4 Cross-chain Infrastructure After examining Chromia's overall cluster structure, the following question is how to connect clusters and sidechains within clusters that serve different roles. Chromia's adopted cluster structure has advantages in that it can secure its own resources and transaction finality through sidechains, prevent performance degradation of all dApps due to network congestion, and achieve horizontal scaling. However, as a trade-off for horizontal scaling, the potential creation of an ecosystem where sidechains are economically and security-wise fragmented serves as a clear disadvantage.
Therefore, the crucial infrastructure in the cluster structure is the cross-chain infrastructure that connects clusters within the Chromia network and chains within clusters to exchange events and data. Specifically, Chromia utilizes two distinct protocols: ICMF (Interchain Messaging Facility) and ICCF (Interchain Confirmation Facility).
The ICMF protocol is specifically designed to support communication between sidechains within the same cluster, providing efficient intra-cluster messaging, while ICCF is engineered to facilitate secure communication between sidechains across different clusters, ensuring reliable inter-cluster data exchange
Chromia network's nodes validate transactions and queries from clusters and sidechains within clusters and generate blocks through a framework called Postchain. Additionally, all node interactions with dApp chain Rell code interpretation or relational databases occur through Postchain. Following the lifecycle of a transaction in Chromia, here are the main functions of Postchain in detail:
Transaction Processing: Accepts and processes transactions signed and submitted by users or dApp chains.
Consensus Management: Validates blocks and achieves consensus between nodes based on the eBFT consensus protocol, a modified version of PBFT.
Data Storage: Interacts with PostgreSQL to store blockchain data, including validated transaction history and the state of each dApp chain.
DApp Code Execution: Updates the state of each dApp chain by executing dApp chain code written in the Rell programming language.
2.4.1 How Postchain Achieves Consensus
Source: Chromia Docs
In this process, nodes validate transactions and generate blocks according to Chromia's eBFT consensus protocol. Following this process, nodes receive transactions and propagate them to all other nodes in the cluster. Subsequently, a validator node group selected by Proof of Authority gains the authority to generate new blocks and adds only valid transactions to blocks, following these specific steps:
Nodes collect transactions received within a specific time interval and add them to the proposed block for the current round.
Nodes propagate the proposed block to all other nodes.
Other nodes receiving the proposed block validate it by executing the transactions within the block. If valid, they sign the block and propagate their signatures to all other nodes.
When more than 2/3 of nodes complete block signing, each node commits the block to the database.
Through this consensus process, Postchain securely validates transactions. By propagating proposed blocks and having each node execute, sign, and commit them, the blockchain can be maintained stably even if less than 1/3 of nodes in the cluster act maliciously or become inoperable.
2.4.2 How Postchain Interacts with Relational Databases
Reliably propagating transactions between nodes and achieving consensus is a basic blockchain function. Beyond this, Postchain's more special function lies in its interaction with Chromia network's relational database. As we saw in the dApp cluster structure, Chromia's dApp chains have their own embedded databases and store transactions occurring in dApp chains in relational databases. Therefore, when new dApps are created or dApp states are updated, Postchain directly interacts with the relational database.
First, when a new dApp chain is deployed or updated, Postchain reads the dApp chain's Rell code to determine the database needed by the dApp. It then automatically creates data tables and columns in the database to enable smooth dApp execution.
Additionally, Postchain updates the database based on transaction results. When a user calls a specific dApp function, a transaction is generated, which calls for the execution of operations defined in the dApp chain's Rell code. At this point, Postchain interprets this Rell code and converts it to SQL queries, which are then applied to the dApp chain's relational database to update it. This process is important because it allows dApp chain builders to implement complex database operations with simple Rell code instead of directly performing raw SQL queries to modify the relational database embedded in the dApp chain.
2.4.3 How Postchain Responds to Queries
Beyond calling operations to update databases according to transactions, Postchain implements read-only queries for dApps. These are queries purely aimed at retrieving information through data calls, and the useful aspect of read-only queries is that they can provide data quickly without going through complex consensus processes, as they simply retrieve data without modifying or adding new blocks to data already committed by validator nodes.
For example, consider a user checking their account balance or recent transaction history on a dApp chain functioning as a DEX. Using read-only queries can provide immediate responses to such information requests. Real-time responses can be provided by calling queries stored in the relational database through the frontend without any significant delay. These read-only queries can be particularly useful in applications where real-time data processing and retrieval are important, and they're an efficient method for overall network resource management as they don't require node consensus.
If someone asked me to summarize the 2024 blockchain market, I would answer without hesitation "diversity," as the blockchain market has pursued diversity in many aspects compared to the previous cycle. The diversity mentioned here goes beyond just increased technical choices in virtual machines and programming languages. It's particularly noteworthy that innovative networks are emerging that attempt differentiation from fundamental architecture, including blockchain's basic structure and database design methods. A prime example of such attempts is the Sui Network. Sui Network not only introduced a new programming language called Move but also proved that various methodologies could be applied to blockchain infrastructure construction by implementing an object-centered model for storage structure.
Of course, such bold attempts might seem quite risky from some perspectives. However, looking at it differently, this is actually a very rational strategy in the current market situation. In the current blockchain ecosystem flooded with similar infrastructures lacking distinction, it's difficult to attract developers' and builders' attention without clear differentiating points. Without providing a clear answer to the fundamental question "Why should this blockchain be chosen?", it can only remain as one of many interchangeable options.
In a way, Chromia is showing a very noteworthy attempt from this perspective. As I explained while examining Chromia blockchain's structure earlier, Chromia is already walking a path differentiated from other blockchains from its fundamental architecture. Among these, what particularly stands out are Chromia's unique database structure and programming language. Interestingly, Chromia's technical choices show clear distinctions even from Sui's approach, which has been gaining attention recently. So what are Chromia's database and programming language, and what advantages and differentiating points do they have?
First, the relational database model isn't a concept invented by Chromia. Tracing its history back to the 1970s, it's a database model with a very long history. Its distinction lies in focusing on efficiently managing data by organizing data in table form and defining relationships between tables, unlike other databases. Thanks to this, relational databases have the advantage of being capable of processing complex queries.
3.1.1 Limitations of Relational Databases and Chromia's Efforts to Solve Them
However, why is the relational database concept unfamiliar in the blockchain industry? This is because relational database models have been considered unsuitable for blockchain until now. The reasons are as follows:
Relational databases are characterized by free data modification, which fundamentally conflicts with blockchain's emphasis on immutability.
Relational databases manage databases in a centralized form, which also doesn't align with blockchain's decentralization.
Finally, the table format of relational databases doesn't fit well with the chain structure that includes previous block hash values.
For these and other reasons, most blockchains have used key-value databases rather than relational databases until now. However, Chromia boldly adopted relational databases. So how is Chromia utilizing relational databases in blockchain?
The answer can be found in Chromia's Post Chain and Anchoring Chain. As explained earlier, Chromia consists of various chains performing different roles. Among these, Post Chain goes beyond simply validating queries and generating blocks to directly interact with relational databases. While relational databases themselves might not naturally align with blockchain characteristics, the presence of Post Chain allows maintenance of blockchain's decentralization and immutability. Additionally, since the Anchoring Chain handles the role of storing hash values, it complements the traditional limitations of relational databases.
Some might evaluate Chromia's multi-chain structure as "complicated," but users don't need to directly interact with all chains. Rather, this multi-chain structure is essential design because it allows for complementing the disadvantages of relational databases. So what advantages does Chromia gain by using relational databases?
3.1.2 Advantages of Relational Databases
First, as I mentioned, because relational databases can process complex queries, they can directly execute queries on blockchain that were impossible on existing blockchains, and automatic indexing means there's no need to rely on third parties for data indexing work. Most importantly, since most AI models operate on relational databases, a major advantage is Chromia's suitability as an AI infrastructure (I'll discuss later how Chromia is utilized for AI).
Finally, using relational databases offers the advantage of using programming languages very familiar to existing developers, like SQL. This is crucial for blockchain platforms where developer experience is extremely important. Because Chromia uses relational databases, it uses a language similar to SQL - the Rell programming language developed by the Chromia team. Let's now examine Rell in detail.
Source: Stack Overflow
According to recent data from Stack Overflow, the most familiar programming languages to developers are JavaScript, Python, and SQL. From the blockchain industry's perspective of needing to onboard developers, improving developers' usage/programming experience is paramount, so the programming language should also be the most familiar to existing developers.
In this context, Rell offers comparative advantages over various programming languages in the blockchain industry. While Rell provides relational data modeling and query functionality similar to SQL (for example, developers can define data structures using the 'entity' keyword), it focuses on reducing SQL's unnecessary verbosity and clearly and accurately conveying essential details. Additionally, because it implements syntax similar to languages like JavaScript and Kotlin, even developers encountering Rell for the first time can quickly learn the language and build applications on Chromia.
Rell also possesses notable characteristics in terms of stability. First, all variables and expressions in Rell have clear types, minimizing runtime errors. Another significant advantage is the ability to verify at compile-time whether types returned from queries match those used in the code. Furthermore, it includes features to prevent overflow in arithmetic operations.
Of course, since the Chromia ecosystem isn't large yet, we'll have to wait and see how widely Rell will be used in the blockchain ecosystem. However, the disadvantages of being a "new programming language" seem largely offset. Rather, because it has a structure more familiar to existing developers, it could serve as a greater advantage in onboarding large numbers of Web2 developers.
Looking at Chromia's architecture and relational database so far, Chromia clearly presents an innovative approach to blockchain design methodology. The cluster structure with hierarchically connected sidechains is useful for achieving horizontal scalability, and it attempts to complement the limitations of existing key-value databases through relational databases.
However, apart from Chromia's technical innovation, one remaining question is whether the Chromia ecosystem has sufficient factors to attract market participants' interest or expect an influx of builders to fill the ecosystem in line with market and industry trends. In particular, Chromia has gone through a long development period of 4-5 years until mainnet launch and is far from mainstream blockchain architecture. In the blockchain industry, which develops by agilely transforming its market trends and technical roadmap, Chromia might be sufficiently concerning in terms of timeliness.
However, whether by chance or necessity, Chromia is currently developing active initiatives with excellent synergy with AI, which is receiving the most attention in the market. In particular, the news that Chromia launched a $20 million data and AI ecosystem fund drew significant attention when interest in crypto x AI was igniting. Moreover, with the official mainnet launch in October this year, Chromia is making thorough preparations to gather sufficient attention in the future market by collaborating with projects that create good synergy with relational database blockchain.
Source: Chromia Blog
Chromia recently revealed its future plans while announcing the Asgard update, a software upgrade along with its mainnet launch.
First, with the transition from MVP stage mainnet to full mainnet, Chromia's native token $CHR was launched. The previously functionless ERC-20 standard token $CHR was converted into a token necessary for operating the network. Consequently, native staking was launched, allowing token holders to stake CHR and receive rewards. While providers (such as validator nodes) must meet a minimum CHR requirement to participate, token holders can delegate their $CHR to provider staking and receive distributed network rewards.
Additionally, $CHR's use as a network token is crucial for token value accrual. Going forward, dApp chains will pay container costs in $CHR when leasing containers. These fees will be pooled and distributed to network providers and staker holders. This establishes a mechanism for $CHR token value accrual as dApp chain activity increases and more dApp chains are created, marking an important turning point in tokenomics for creating network effects in the ecosystem.
Source: Chromia Blog
The second notable update is the upcoming Asgard update. Through this update, all node providers will uniformly upgrade their software. One major upgrade is the introduction of 'Chromia Extension,' which can expand Chromia blockchain's functionality through a modular framework. Chromia envisions serving as a data layer providing decentralized cloud to various dApp chains, and the extension is one of the key upgrades to achieve this roadmap.
The first released extension is the oracle extension for real-time off-chain data integration, with a recently announced collaboration with oracle solution Stork. The oracle extension built through this collaboration will provide real-time data feeds necessary for price tracking and transactions across various types of dApp chains, aiming to secure possibilities for dApp chains to enter areas such as games, RWA, or money market protocols. Following the oracle extension, additional extensions related to AI inference, data availability, zero-knowledge proofs, and other functionalities are planned for successive release.
4.2.1 Synergy Between Chromia and AI
While Chromia is essentially a general-purpose blockchain where various dApp chains including games, RWA, DeFi, and consumer applications compose the ecosystem, it is particularly developing an AI-centered roadmap based on its high synergy with relational databases.
AI can be broadly defined as software that perceives autonomously. However, if we redefine AI from a data-centric perspective, AI can be described as the result of standardizing and refining data, followed by automating data processing. More specifically, AI as we know it emerges after going through a standardization process that converts data with different structures into a uniform format, followed by preprocessing that transforms raw data into a form suitable for modeling, and then automating processes such as data collection and input/output. From this perspective, data fundamentally underlies AI, and similarly, the ability to store and process databases in a decentralized manner is fundamentally core to the Chromia blockchain.
Above all, Chromia's programming language Rell is highly suitable for AI-related data operations. Looking at how AI utilizes data, AI's Natural Language Processing (NLP) models require databases to store large amounts of text for AI learning and inference. Here, SQL, which is suitable for storing structured text, is used for efficiently querying and storing required data. Since SQL is already used as a standard in AI natural language processing, Chromia's SQL-based Rell language maintains high compatibility with AI-related data operations.
Meanwhile, both Chromia's relational database and cluster structure have architectures suitable for AI-related data operations. First, because each dApp in Chromia's cluster structure has its own sidechain, even if one dApp becomes overloaded, the network can maintain high throughput stably without being affected by bottlenecks that might occur in processing large-scale data. Additionally, Chromia's relational database is specialized in efficiently storing and querying structured data necessary for operating AI applications.
4.2.2 Chromia's Distinctive Position in the Crypto x AI Phase: Proof of AI
Nevertheless, the synergy between Chromia and AI cannot be fully explained merely by the fact that its programming language and architecture are suitable for AI-related data processing. Moreover, some might question the ambiguous justification for why blockchain should be used for processing AI data, even beyond Chromia.
However, AI has recently emerged as the most important topic in the blockchain industry. While blockchain and AI show integration in contexts such as token incentive-based data markets or GPU markets, an equally important emphasized role of blockchain is that it can be usefully employed in proving that AI is truly AI. The rise of AI agents triggered by GOAT, Terminal of Truth, and LUNA has brought such discourse as an important topic in the crypto market, and here Chromia holds the potential to present appropriate solutions.
Source: Chormia LLM Explorer
Chromia's decentralized relational database can be specially utilized as a solution for transparently verifying AI's reasoning process. Through collaboration with Chasm Network, which builds decentralized AI inference APIs, Chromia is actively positioning itself as a key data layer for inference data. This is being implemented through the creation of the Chasm opML database dApp chain, which specifically handles AI inference data.
The technical implementation is remarkably efficient - it's already possible to add complete transparency to AI processes with just four concise lines of Rell code. This implementation makes it significantly difficult for AI decisions to be biased or manipulated, as every decision and its underlying reasoning process is recorded on the blockchain, allowing anyone to verify and audit how the AI makes its decisions. This creates an unprecedented level of accountability and transparency in AI decision-making processes.
The most striking impression I had while researching Chromia was how unfamiliar its structure is. Although professionally analyzing various blockchains and closely examining their structures is my job, Chromia's structure shows clear distinctions from existing blockchains just by itself. The multi-chain structure might initially remind one of Avalanche's subnets or Polkadot's structure, but looking into the detailed design of the chains shows a completely different direction from these. This is because each chain has been assigned clear roles and has a unique structure where they interact organically with each other. Additionally, they introduced relational databases that existing blockchains hadn't attempted, used their self-developed programming language (Rell), and even presented FT4 as an independent token standard. In fact, these radical attempts could be considered quite adventurous from a builder's perspective. Even setting aside general users, it's difficult to predict how developers familiar with existing blockchain environments will react to such innovative structures.
However, I believe these bold attempts are exactly the innovation needed in the current blockchain ecosystem. Especially in times like now when SDKs and development tools are highly advanced and anyone can easily create mass-produced blockchains, the existence of teams that reconsider fundamental blockchain design philosophy becomes even more valuable. Of course, such innovative attempts carry corresponding risks of failure. This is less about technical fundamentals and more about practical challenges that might be faced in ecosystem building due to unfamiliarity. However, it's worth remembering that historically, innovation in every market has always stemmed from bold attempts that break existing frameworks. These challenging attempts that bring fresh air to the currently stagnant blockchain market deserve sufficient attention and evaluation, regardless of their final outcome. Perhaps someday, Chromia's innovative approach might become the new standard for numerous mass-produced blockchains.
In particular, since Chromia has significant differentiating points in its database and programming language, we expect it to show pioneering of new markets different from existing blockchains.
Taiko
Initia
Cosmos
Arbitrum
Base
