A Programmable Execution Layer with Shared State is Required

In Ideas: Nervos - A Modular Blockchain Network with CKB as the Kernel - English / CKB Development & Technical Discussion - Nervos Talk, I summarized the design philosophy of the Nervos Network as a multi-layer, web-like blockchain network with CKB serving as the hub.

However, to date, the Nervos Network still lacks an efficient programmable execution layer with shared state.

  1. A long time ago, Nervos developed CITA, which later became a consortium blockchain framework.
  2. Subsequently, Muta was developed, but for various reasons, it was never brought into production.
  3. Later, with the rise of the EVM wave, Godwoken was introduced as the first shared-state execution layer in the Nervos Network to enter production. However, the launch of Godwoken faced several challenges, making it difficult to sustain its development: 1. The project followed a challenging path of implementing an Optimistic Rollup from scratch, which extended the release timeline, causing it to miss the peak of the EVM wave and fail to attract sufficient capital. 2. It did not implement asynchronous sequencing between Layer 2 and Layer 1, resulting in long block intervals and low throughput.
  4. Following this, Axon, which inherited Muta’s design philosophy, was developed. It supported EVM and other VMs and could integrate with various cryptographic algorithms. However, due to conflicting development strategies, Axon’s progress stalled.

As of now, the Nervos Network still does not have a viable execution layer with shared state.

The Importance of a Shared-State Execution Layer

Such an execution layer is a nearly indispensable infrastructure in the competitive landscape of programmable blockchains. Without it, essential functions such as issuing and trading new assets, swapping between various stablecoins, and supporting innovations in blockchain application layers become significantly more challenging. While UTXO is a reasonable design for peer-to-peer applications and execution layers, it falls short for the types of applications most commonly used by users today.

Recommendations for Building a New Execution Layer with Shared State

If Nervos intends to develop a new shared-state execution layer, the following considerations might be helpful:

  1. Simpler Implementation Methods:
    Given the challenges of development, if modifying open-source implementations of OpRollup or zkRollup is unfeasible, directly launching a sidechain might be a simpler and more viable approach. Its security can be enhanced as the on-chain TVL grows, such as by increasing the number of validators.
  2. Flexibility in Execution Layer Choice:
    EVM is no longer a mandatory option. Alternatives such as Sui’s MoveVM, or account models and object models(similar to Sui or Fuel) based on RISC-V VM or WASM VM , are feasible.
  3. Asset Issuance Strategy:
    Important assets can first be issued on CKB and then transferred to the execution layer for usage.

Leveraging Existing Innovations

Over the years, significant advancements have been made in execution layer innovation and development across the blockchain ecosystem. Leveraging these existing research and development achievements can make creating a shared-state execution layer much easier than before.

Launching such an execution layer does not guarantee immediate success, but it provides fertile ground for experimentation within the Nervos ecosystem. It enables Nervos community developers to easily test various application possibilities and allows supporters to interact with the CKB ecosystem using their CKB assets more conveniently.

We must continue to move towards the vision of The Nervos Positioning White Paper.

3 Likes

Since RUNckb has become a thing and MattBitcoin’s position within Nervos has changed, the Contract Kernel of Bitcoin slogan has become more and more and more of a thing. We should write CKB in all possible places and say it instead of ‘Nervos’.
Since all possible executable binary files can be used, CKB is very powerful. As far as I know Java is fast and widely used and we see developments for CKB in this direction.

3 Likes

The initiative with Godwoken was the closest to success, but ultimately, the effort did not reach a sustainable critical mass. I believe a lot of that was due to the unfortunate timing of needing to raise during one of the worst bear markets, but as you noted, there were other challenges.

I supported continuing the effort that Eric was working towards. Eric has now moved on, successfully raised funding, and relaunched the same effort in another ecosystem. Decisions were made, for better or worse. I supported the effort at the time. If I were to go back in time I would support it again. But I do not think I would support a reboot of that effort again today.

I do not want to see more efforts go towards EVM (or similar solutions) since they will ultimately encounter the same problems that the Cell Model is attempting to solve. All UTXO platforms are struggling with similar challenges. CKB is the best-suited platform to work past them, so I would like to see the efforts placed there.

Shared state may be one of the biggest challenges for developers, but it is a challenge, not an impossibility. OTX and intents are solutions, but generalizing these patterns to lower the barrier to entry for developers is another challenge in itself.

I agree that improvements need to continue. I have doubt that copying any existing execution layer would get us the desired results. If shared state is all that matters, then use Godwoken. It’s not perfect, but it works fine and it’s available right now. The fact that developers are not flocking to it is evidence that it simply existing does not make it the first choice for developers.

4 Likes

Firstly, an execution layer with shared state is essential for a modern blockchain system. Without it, the system would resemble a financial system without a securities trading platform, encountering immense confusion and obstacles wherever liquidity is needed. As an ecosystem begins to thrive, issuing and trading new assets are the most fundamental requirements.

Secondly, although solutions like OTX or Intent are feasible on CKB, they still struggle to meet numerous demands. After careful analysis and design of related methods, I have found that the difficulty and workload required to implement these solutions are not less than those needed to directly integrate an execution layer, and the user experience is likely to be inferior.

Lastly, CKB itself is not intended to be a chain that serves all applications. This was anticipated at the initial design stage of the network. However, for a long time, the entire ecosystem has not fully committed to advancing this original goal.

Hey @orange-xc, nice to talk with you once again :hugs:

I’d like to congratulate you on the prediction (come true) that state channels would come first to Nervos L1 :clap::clap::clap:

I’m well aware of how much time you already dedicated to this and how many shared-state models you proposed in the last few years, since you ask me to review some them and I happily obliged.

Many things together in a single statement, so let’s break it down.

Let’s not kid ourselves, we have already a pretty decent base layer of protocols and standards, but it’s not thriving. Hopefully the upcoming channel tech (that you envisioned) will change this trend.

We are both well aware that Nervos L1 is already the best place for issuing assets. Any shortcoming in the current protocols can be improved by new standards and/or augmenting them with SSRI. See for example PausableUDT.

For the current network activity, trading is a solved problem. For example:

  • Most users use CEXs / trust-based exchanges (not DeFi, but still effective)
  • UTXO Swap exists (not Open Source, but it has some usage)
  • UDT Limit Orders exist (fully Open Source, but low usage)
  • Fiber’s compatible UTXO Stack incorporates a swap mechanism
  • RGB++ can be easily extended to connect base Nervos L1 to another UTXO chain which would provide a programmable execution layer with shared state, effectively using this second UTXO chain as a L2

Unless a well-defined niche-fulfilling need for a Nervos-developed L2 emerges (like Fiber or RGB++), we should stay clear of developing yet another failed L2. History of previous attempts proves this.

Agreed, but users generally don’t use/appreciate L2 :man_shrugging: (Unless this L2 is filling in a specific niche)

That said, special-purpose intent cells are not too hard to create and they are already employed on Nervos L1. All in all, until something better comes along, they fit well enough the requirements.

Given this perspective, feels like Fiber is a step in the right direction. Axon was pretty interesting too, kind of a bummer that its development stalled.

That said, keep in mind that at high-level Nervos L1 is a distributed database with generalized transition rules and that Nervos L1 aims to be as decentralized as possible, so anything can be built on top, at the builders choice.

In this regard, as an independent builder, I would appreciate if all players in the ecosystem were to Open Source their techs, at the very least the implementation of what makes them decentralized. Otherwise, they are just proposing yet another centralized tech with DeFi marketing sprinkled on top.

Love & Peace, Phroi

3 Likes

is it as simple as just running a zk verifier, SP1 with Celestia underneath or something like that?

There’s still the question of getting collateral into this system… I think the culture of “don’t trust, verify” is a huge impediment to reaching your goal unfortunately. We saw this problem with Godwoken and NFT projects, the community’s aversion to “scams” hurt the ecosystem.

The considerable trust assumptions we’re looking at here is similar.


What came first, the chicken or the egg?

Is the problem a lack of shared state or a lack of utility?

We have a cold start problem, but there are billions of CKB in the DAO that would be happy to find additional yield. They can even already be restaked into an xUDT with iCKB.

Your assertion is that shared state is on critical path, I think providing yield and borrowing options to existing CKB holders is on critical path, and it’s possible we could do this with order-based things.

Cobuild/OTX are attempts at generalization, I greatly respect the time you and others have spent with them.

What do you think about the idea of starting with domain-specific partially signed transactions to provide these use cases to the existing ecosystem?

The technology can grow around the needs of CKB holders, and the level of effort on this is much lower than building a novel L2.

2 Likes

Agreed, with order-based protocols built on top of the cell model we can already express so many interesting primitives and protocols with solid qualities. See for example: [V0 Looking for feedback] A next-gen DeFi Primitive

1 Like