中文版
Do You Hear the CCC?: Come, Let Us Build a Tower
Good moon, good sun. I am the developer of CCC. You might know who I am, but let’s pretend we don’t.
In 2024, toolchains in Nervos were like a rotting, unfinished house, hazardous to the physical and mental health of every developer, which eventually whipped CCC into existence. CCC, which I call CCC is CKBer’s Codebase (tell me self-referential jokes aren’t outdated yet, or I’ll cry), is rooted in the most commonly used browser ecosystem. It aims to provide a one-stop solution, allowing developers to build their applications on established scaffolding, freeing them from the Avici of building applications from bottom-level concepts over and over again.
Simply put, CCC makes the ideas in a developer’s head become reality faster and with higher probability; in detail, from the moment of clicking the frontend to connect a wallet, through the user selecting a wallet, handling various protocols, assembling CKB transactions (this is super troublesome), requesting user signatures, and finally sending the transaction to the chain. CCC provides complete yet flexible, free yet concise assistance throughout the entire process.
I hope reading this sparks your interest in CCC, because I’m about to suddenly start pasting the changelog. You’ll need that interest to survive these things no one likes to read.
CCC 2.0.0: Come, Let Us Build a Tower
The release of 1.0.0 was a boring moment. Back then, we didn’t even think to name it, referring to it by a serial number like prisons or Chinese schools refer to inmates. A year has passed, and we finally welcome 2.0.0 – which hasn’t been released yet. Three months ago, I published the v1-final branch, but there was always something that was just about to be finished waiting to make the cut for this moment, forcing me to resort to “fake it till you make it.” I’ll write the changelog first. I can’t drag this out until next year to release it, right?
Updating a major version number is a badge of shame, marking that the guy writing the code didn’t think things through at the start and has to proclaim to the world, “I changed my mind! Everyone update”. Despite this, I still hope the implied imagery of “something became better than before” can take us to a new beginning.
With 2.0.0, CCC looks like a serious project. This log will introduce the things I found interesting between 1.0.0 and 2.0.0: some may have been live for a year, others might still be in development. We have provided support for common usage scenarios and iterated based on community feedback. CCC is no longer just a novel experiment; it has gradually become a reliable foundation. Perhaps we have reached the time to build a Tower of Babel.
Nostr
Nostr is not the first signing method CCC supported, nor will it be the last. But I want to express my special fondness for it because we can gratefully freeload use the Nostr community’s public relay servers to store and share data.
Based on this feature (feature), I added a “Share” button to the CCC Playground, a code execution environment within the browser. After you click it, the webpage automatically generates a private key, signs your code, and sends it to Nostr, allowing you to share it with our good friends via a link.
CCC Playground Super Evolution
In this year’s Playground update, my favorite part is the graphical redesign for the concept of the CKB “Cell”. I used the form of Bagua to display cells, using combinations of trigrams (it’s binary!) to represent the different “Lock” and “Type” scripts on the cell. I also added some animation to it; although it’s frivolous, maybe it makes people feel like they are doing something cool. If you are interested, you can try this example.
The reason we can display images in the terminal is due to another new feature of the Playground: writing code directly using React’s TSX syntax. This means developers can display arbitrary frontend elements, or even write a simple tool with a user interface to share with others, without worrying about troublesome issues like frameworks, dependencies, or deployment.
Better Nervos DAO Adaptation
Finally, developers have a tool to operate the Nervos DAO. By locking the data storage capacity of CKB native tokens, one can resist inflation, a fundamental part of the Nervos ecosystem design (although the Nervos official website still doesn’t introduce it. Who wants to write an article for it?).
Thanks to @phroi for providing a lot of valuable feedback for this series of improvements. The iCKB he developed, a protocol that allows Nervos DAO to be tokenized and circulated, provided many real-world usage scenarios.
UDT
The User Defined Token (UDT) series of protocols, from the sUDT core that appeared earliest and is still in use today, to the xUDT extension that almost no one has used, supports all secondary currencies issued on CKB. Its core idea is to use data in cells to represent denomination. It isn’t complex, but integrating this logic into applications is quite challenging.
CCC provides an interface for operating UDTs similar to operating native CKB tokens, avoiding extra learning costs. This series of improvement suggestions also came from @phroi , stemming from the solutions he summarized while writing UDT-related code for iCKB. Additionally, thanks to suggestions from @rink1969 , we optimized CKB occupancy when calculating UDT change.
Type ID-like Protocols
Type ID leverages the characteristic that CKB cells can only be consumed once. It is used to assign a unique on-chain ID to a cell to track the updates and destruction of a cell singleton. Designed from the beginning to track the latest state of upgradable contracts, it has gradually been applied more broadly to other protocols.
CCC’s new Type ID package, in addition to supporting the simplest arbitrary data Type ID, provides advanced methods to facilitate extending support for Type ID-like protocols. The DID CKB support added alongside the Type ID package is a great example.
Multisig Lock
Another support for an early CKB feature. Although the multisig lock only supports the Secp256k1 algorithm, it is still frequently used in scenarios like contracts or fund management. Previously, developers mostly used the command-line tool ckb-cli to handle multisig transactions. I hope things will get better after adding support in CCC.
CCC’s support includes two modes: sequential signing and merging transactions after multiple signatures.
FeePayer Abstraction Layer
Thanks to the characteristics of the UTXO model, all parties in a transaction can pay the transaction fee. This makes calculating fees exceptionally difficult. Past SDKs would assume there is a specific native address that adds more tokens to be responsible for paying fees, but this cannot satisfy features like the zero-fee feature in the Spore protocol or the UDT instant convert (how many people know about this interesting thing?) that we want to introduce.
FeePayer hopes to abstract fee payment into a separate step, providing a unified interface for more fee payment methods. Once developers utilize these interesting features, users may no longer need to hold extra CKB to initiate transactions, but instead pay fees through pre-deposited assets or on-the-spot micro-exchanges.
Anything More?
Honestly, I don’t know what CCC will look like in the future. We have some things in progress, like the support for RGB++, support for the Fiber Network, or the implementation of the Script-Sourced Rich Information (SSRI), but they won’t be all that CCC is. I hope CCC can help developers solve different problems in different scenarios, and this requires understanding what developers need, which requires more feedback from the community.
Anyone interested is welcome to leave your thoughts on CCC Issues, or see if there are any problems you’d be willing to solve. If you like CCC, star the repo to encourage us.
I changed accounts, hoping to make you start paying attention to the meaning represented by “identity” in this community, hoping to remind you to think about how dangerous these things are that are packaged as having reference value but actually possess none. I, from my own perspective, unrelated to any organization, am disappointed by this appeal to authority and disgusted by artificial reputation.
Let me be clear: I struggled for a long time whether to vote against that because of the procedural injustice, even though I don’t object to the proposal itself. I believe these people all have good reasons to explain why they are doing this, and the rules (containing massive loopholes) do not prohibit this behavior. Perhaps we should have some consensus on what is ethical, rather than one side using methods with even less integrity than the other to rush towards the abyss of a race to the bottom.
I encourage everyone who is still interested in voting to think about what their own answer is.
