Development Paradigm of Layer1.5 Using Cell Model

English CKB Development & Technical Discussion
1

This article is translated from my article: Cell模型的Layer1.5开发范式.

1. Overview

In Jan’s article, Cell Model : A generalized UTXO as state storage | by Jan Xie, the Cell model is introduced as an abstract state verification model. In this model, Cells store states, and Cells->Cells represent abstract state transitions. Most applications developed based on the Cell model follow this pattern. For example, sUDT stores sUDT balances in Cells, mNFT stores NFT metadata in Cells, and DAS stores basic domain name information in Cells.

However, there is a limit to the number of Cells that can be used at a certain stage. The short-term storage space is approximately 30GB, which is only sufficient to store around 200-300 million different sUDT Cells or even 100 million DAS Cells. This limitation implies that future Dapps will face increasing usage costs. Despite the underutilization of other resources such as network and computation, the total quantity of CKB is limited, which compels developers to move to Layer 2 development. Similar resource allocation issues existed in EOS, where CPU and RAM resources were exhausted, resulting in artificial congestion. However, EOS’s resource pricing was more volatile.

Although we have GodWoken, which allows the development of Layer 2 applications, applications developed on Layer 1 can have greater flexibility due to the superiority of the Cell model and CKB-VM. Layer 1 applications can learn from Rollups and store states off-chain using some form of vector commitment or accumulator scheme (such as Sparse Merkle Tree or Verkle Tree), while only storing the state root in Cells. In simple terms, Layer 1 development used to be like building a small villa, but with vector commitment, developers can reuse a plot of land and build a skyscraper. This new development paradigm, compared to Layer 2 designs like GodWoken, can be referred to as Layer 1.5.

By adopting the Cell model, applications can achieve a similar user experience as an account system while significantly reducing the state occupancy of CKB. This does not diminish CKB’s value-capturing capability because it means that CKB can support more Layer1 applications. Users and developers are always the most important indicators of a network’s value. Unlike EOS, where they are constrained by a specific resource, leading to congestion despite significant idle computing and network resources.

Currently, there are applications that adopt the Layer 1.5 development paradigm, such as Compact Extension for m-NFT Protocol: The Key to Mass Adoption used to compress NFT occupancy and save costs, and RFC: Compact UDT Lock used to compress UDT’s state occupancy and save costs.

In summary, the verification of Layer 1.5 transactions can be divided into three steps:

  • Verification of resource operation correctness: This step corresponds to the Cell model and can be likened to TypeScript. It ensures the correctness of state fragments during the transition process. For example, 1 USD can be transformed into two 0.5 USD, but not into 2 USD. Each transition needs to be verified for correctness.

  • Verification of resource permissions: This step corresponds to the Cell model and can be seen as the lock script. It verifies the logic of whether a state fragment can be used, such as Unipass unlocking or secp256k1 verification. Each unlocking condition needs to be verified.

  • Verification of state transition correctness: This step involves verifying the correctness of the transition from the old state to the new state. After applying the resource operations from the first step, it checks whether the old state has strictly transformed into the new state.

Layer1.5 offers the same level of security as Layer1, but its availability assurance relies on the design of a consensus rule. It resembles zkRollup but doesn’t require implementing complex zk circuits to achieve similar effects. While zkRollup achieves off-chain state storage and complete off-chain computation, Layer1.5 only implements off-chain state storage, with full on-chain computation still intact. However, considering that the verification cost of zkRollup is much higher than the typical application’s verification cost, Layer1.5 doesn’t impose excessive computational overhead.

After sufficient optimization, the verification cost of zk circuits may significantly decrease, and the difficulty of circuit composition may also reduce. At that point, the development experience and applications built on Layer1.5 can directly transition to zkRollup since they are both based on validity proofs. In other words, when the three-step verification mentioned above is transformed into zero-knowledge proof circuits, it becomes zkRollup.

Therefore, Layer1.5 can be designed as a framework, similar to Godwoken. The correctness verification of resource operations and permission verification can be implemented as interfaces. The required code can be organized through celldeps dependencies and invoked through dynamic linking or execution. Compared to Layer1, it does not compromise expressive power. On the other hand, the Layer1.5 development model inherits the characteristics of an account model and can be understood as a hybrid model that combines the advantages of the Extended UTXO model and account model. The deprecated Layer1 versions of Polyjuice and Gliadex can be re-implemented using the Layer1.5 development paradigm.

2. Layer1.5 Pros and Cons

Let’s briefly analyze the pros and cons of this development model:

2.1 Pros

  1. Significantly reduces the need for dedicated state storage, alleviating the burden on the chain. The compressed state does not impose any additional storage cost on Layer1.
  2. Layer1.5 transactions can be batched on-chain to address the state contention issue in UTXO, enabling shared states and facilitating Layer1 applications such as swaps.
  3. By employing transaction compression techniques, transaction sizes can be minimized. However, Cell model transactions inherently have fixed space costs due to state fragmentation. Considering that network resources might become the primary constraint, transaction compression should be prioritized.

2.2 Cons

  1. Transactions require an accompanying state transition proof, which incurs additional network and computational costs. However, this proof can be compressed using zero-knowledge proofs.
  2. Mechanisms need to be designed for transaction ordering in Layer1.5, similar to Rollup, to prevent potential DDOS attacks on Layer1.5 applications by malicious users.
  3. Script development becomes slightly more complex compared to pure Layer1 development. While Cell model allows for flexible choices of Typescript and Lockscript, Layer1.5 requires implementing such dynamics through dynamic linking, execution, spawn (e.g., dynamically selecting unlock methods like Unipass, ETH, Tron).
  4. More sophisticated off-chain components are needed. Simple Layer1 development only requires writing transaction logic, while Layer1.5 involves complex off-chain components like Aggregators, similar to Layer2 projects. This complexity can potentially be addressed by designing a generic development framework for Layer1.5.
  5. Due to the fragmentation of some states, Layer1.5 might impact the composability of the entire network. Refer to the section on cross-cell communication for more details.

Overall, the Layer1.5 solution does not impose significant additional costs on applications, apart from the need for proofs. Network and computational resources that would be consumed by Layer1 are still required. However, the Layer1.5 model ensures that even if a state remains inactive for an extended period, it does not impose any additional costs on Layer1.

3.Model Selection

In commonly used programming models in blockchain, such as the state-based UTXO model, account-based account model, and resource-oriented Move language programming model, Layer1.5 can theoretically adopt any of them.

If we choose the UTXO model, we can treat each leaf node in the Merkle tree as a UTXO. In each transaction, we can consume some leaf nodes and generate a batch of new leaf nodes. This design can be suitable for NFT applications or even fungible token designs (coin model).

Alternatively, we can adopt the account model by considering each leaf in the Merkle tree as an account. Each account can contain token balances or contract code (which can be stored in a specific Cell and used through celldeps). With this model, we can implement swaps or even an EVM-compatible layer.

We can also combine these two models. For example, NFTs can be stored in some leaf nodes while accounts are stored in other leaf nodes. In such a design, NFTs can have a price, and an account can purchase them by transferring assets to the seller’s account. As a result, the ownership of the NFT is automatically transferred to the buyer’s account. This approach can be applied to NFT and domain name marketplaces.

Compared to the limitations of UTXO, in Layer1.5, you have the flexibility to interpret what a leaf contains in any way you want. Additionally, there are no state contention issues, and state renting is not required. By using validity proofs, ensuring the security of Layer1.5 only requires synchronizing the state of a single node.

4. Cross-Cell Communication

Another important aspect to consider in the design is communication. Similar to cross-shard communication in sharding, if we design a Layer1.5 application while maintaining the composability of the entire network, cross-cell communication becomes necessary.

  1. Asynchronous Communication using Cells

    The simplest approach is when a leaf wants to communicate across cells, it can extract the resource and temporarily store it in a Layer1 cell, and then transfer it to another compressed cell. This asynchronous communication mechanism does not have any side effects because each cell is unique, eliminating replay attack concerns. However, in the CKB model, there needs to be a cost in terms of CKB for the state occupation during this time, which complicates the problem.

  2. Synchronous Compositional Communication

    Another side-effect-free communication mechanism is to calculate the entire communication result when A compressed cell and B compressed cell want to communicate, and then consume both A and B compressed cells simultaneously in Layer1 to achieve synchronous communication. Since their communication is already completed in a single transaction, there are no replay attack issues. However, this mechanism requires strict synchronicity. If the control over A cell and B cell is not entirely in the hands of the same organization, there is a high risk of failure. If these two cells belong to different organizations, they may need to be online and interact with each other, similar to Grin’s transactions, to complete the communication.

  3. Asynchronous Communication

    Asynchronous communication is the most convenient solution. Similar to receipts in sharding, a transaction from A cell specifies a receipt that will be obtained and executed by another cell. However, this mode needs to be carefully designed to avoid possible replay attacks. Additionally, as used in the scheme presented in Compact Extension for m-NFT Protocol: The Key to Mass Adoption, this mode can lead to an increasing accumulation of state. In other words, communication may require the use of “withdrawal_nft” and “claim_nft,” and the state of these two operations will accumulate indefinitely.

Perhaps there are even better cross-cell communication mechanisms within the development paradigm of Layer1.5. If you have any better proposals, please feel free to contribute.

5. Other Considerations

5.1 Time Issue

Many DApps require the concept of time, such as time locks, lending, and liquidity mining, which involve calculating interests and returns over time. However, incorporating the concept of time into Layer1.5 is challenging. One possible solution is to use header_deps to allow the entire Layer1.5 transaction to have an approximate understanding of the current time. Alternatively, a time oracle can be utilized to address this issue.

5.2 Sequencer Issue

For certain applications where compressed cells store individual assets, a simple global lock can be used for control. For other applications like games, different strategies can be adopted. For example, during normal times, global lock control can be enforced, but if a cell remains unused for 24 hours, its permission control can automatically switch to AlwaysSuccess, allowing the user to reclaim their assets.

Moreover, many applications operate in the form of DAOs (Decentralized Autonomous Organizations). In such cases, the unlocking logic can be designed as a Proof-of-Stake (PoS) mechanism, where users with voting rights can set up a Layer1.5 node to participate in submitting transactions to the chain.

In summary, this issue can be approached by referring to the choices made by other Layer2 solutions.

6. Required Components

6.1 Aggregator

Since Layer1.5 stores states off-chain, there is a need for an off-chain component to store the states. This component is responsible for generating state transition proofs for a specific on-chain block (i.e., batch transaction). It requires a complete backend service.

6.2 Explorer

Layer1.5 transactions cannot be directly visualized on the Layer1 transaction explorer. Therefore, there may be a need to design a specialized transaction explorer. Given the inherent property of state sharding in Layer1.5, further discussions are required to determine the design and presentation of such an explorer.

6.3 General Identity Interface

Identity design refers to how we handle permission control in Layer1.5 transactions. In the Cell model, this is achieved through lock scripts. In Layer1.5, we also need to design an Identity system. For example, each lock should expose a general interface to be used by Layer1.5 transactions, enabling account abstractions in Layer1.5. Hard-coding a specific unlocking method in the Layer1.5 application’s contract would be inconvenient. This issue has been discussed in the design of RFC: Compact UDT Lock 7.

6.4 General Type Interface

If we design a general-purpose Layer1.5, state transitions can also be contract-customized, similar to the customization of locks. This approach enables the development of more user-friendly OpenTransactions, a DApp development model that combines the advantages of UTXO and account models. It could even allow the implementation of a complete Turing-complete virtual machine, such as EVM and Wasm, through this approach.

If we can develop a Layer1.5 DApp development framework that includes the aforementioned components, the difficulty of developing and using DApps in the Cell model should be significantly reduced.

7. Example Ideas

The following are some ideas to explore the possibilities of Layer1.5 development:

7.1 Cross-chain Asset Receipts

Taking the ETH->CKB cross-chain bridge as an example, cross-chain users inevitably need to purchase a certain amount of CKB for state storage. After the price of CKB increases, this becomes a significant cost. Perhaps we can design a compact Cell with an unlocking logic based on ETH (since it is an ETH cross-chain bridge). Each cross-chain asset becomes a leaf node in the vector commitment, thus avoiding the misleading issue of CKB occupation. Then, through cross-cell communication, the cross-chain assets can be transferred to other applications or Layer2 for use.

Similarly, depositing assets into Layer2 can aggregate the assets into a single Cell for easier management.

7.2 Personal Asset Management

A user can put all their assets into a compact Cell to save on state occupancy. There is no individual unlocking logic for each item; only the unlocking logic for the entire Cell exists.

7.3 Asset Trading

With Layer1.5, we can develop native trading platforms without having to consider state contention and concurrency issues. Whether it’s an order book or an automated market maker (AMM), we can use it to trade assets such as sUDT, DAS, mNFT, etc. This eliminates the need for state occupancy when placing orders, which greatly improves the user experience. Existing platforms like DAS Trading Platform and GliaDex faced challenges with state occupancy for placing orders.

7.4 Blockchain Games, Crypto Real Estate, etc.

Other creative ideas involve using each leaf of the vector commitment as a plot of land in a blockchain game, where we can store a certain length of data (e.g., 32 bytes). In addition to the virtual land, it can be used for pixel art auctions or other applications. With Layer1.5, there are even more possibilities for blockchain games.

If you would like to donate to support my writing, please send it to:
CKB:ckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqdz0v4f6jcd4xz74r3yzxaypsgfcc5wlgc8q4upx
BTC: 35t45FZnm3kXuWfnS5ojrTVkvDNyuNY1UH
ETH: 0x45e0205A6faE242C082D620d8ae436A6d001A956

7 Likes