Simple user-defined tokens & more
Nervos enters a new era with user-defined assets!
Sparkling
The Nervos mainnet "Lina" has been live for one year. In the past of year, the Nervos development team has been focused on developing infrastructure and development tooling, with the ultimate goal of supporting a safer blockchain environment.
Recently, the sUDT standard has finally launched and the script has been successfully deployed on Mainnet. A list of deployed sUDT tokens can be found on the sUDT token list on CKB Explorer.
The sUDT standard however only provides the core features of a fungible token and lacks specific features that some utility tokens need. This is why extension proposals based on sUDT have been recently posted to the Nervos Talk forum, such as this one that creates an info cell for token information, and this one that considers the handling of financial regulatory requirements for tokens.
The RFC of the Nervos NFT standard is also in discussion. Check the information below, or go to the Nervos Talk forum to join the discussion.
Let’s build the token economy of Nervos CKB together!
sUDT Sparklings
Approve cell proposal: how to create an Anyone-Can-Pay Cell to improve the user experience of sUDT transfers
We already know that if users want to hold any sUDT, they will need a cell containing 142 CKBytes (CKB) to receive a quantity of sUDT, but who will supply these CKBytes? If the sender or a dApp operator provides them on behalf of the receiver or user, this may not be a sustainable strategy in the long term.
If you are interested in these details of user experience, check out the Approve Cell design proposal on Nervos Talk. With an approve cell, a sender creates a cell with a lock script that can be unlocked by a specified receiver, and the sUDT can then be withdrawn. The process of transferring sUDT can be executed on-chain and a better user experience can be created.
sUDT info cell: embed more complete on-chain token information
The sUDT standard currently only has a simple specification for user-defined token logic, but there is not a set of standards to include basic token information such as the total supply, token symbol, etc. This is why the sUDT info cell has been proposed.
The sUDT Info Cell also utilizes the unique property of the Owner Lock Script's Lock arg, so that the Info cell corresponding to this sUDT can only be modified by the token issuer.
In terms of mechanism design, the issue of how to avoid malicious behavior from an issuer, such as issuing multiple sUDT Info cells (including fake ones) for a single token is still worth thinking about. Check out the forum topic, A SUDT Information Storage Meta Cell Design Proposal.
Can a sUDT satisfy regulatory requirements? Check out two solutions proposed on Nervos Talk!
For a long time, the issue of regulation has been an interesting topic. The past solutions were too hard to manage regulatory requirements on chain, but fortunately with flexible cryptographic primitives and elegant usage of lock script and type scripts, on Nervos, on-chain regulation can be implemented. This article on Nervos Talk discusses how to implement a solution for regulatory-compliant user-defined tokens based on sUDT standard.
Solution 1 : xUDT, a new kind of type script
xUDT can be thought of as an sUDT with more functions, mainly, new cells generated from a transaction must follow the rules of a type script customized by the cell referenced by the xUDT cell (through cell_deps). For example, we can create a global control cell, blacklist cell, whitelist cell, etc. Through these cells and the functions of the cell_deps, we can set up a number of on-chain validation rules that asset owners must follow. Of course, such a solution does not give the token issuer control over user assets.
Solution 2 : xACP, a kind of ACP cell that could help token issuers control all the tokens they issue
Under the xACP design, asset owners must comply with two things: first, authorization of the token issuer for lock script arg value, and second, the lock script of the generated output cell must not be changed. The advantage of this is that it is easy for the issuer to supervise and control the issued assets, while the disadvantage is also obvious: there are many scripts, such as those used in DeFi applications, that will need to change the lock script of output cells, and such a requirement will make it difficult for the asset to interact with other dApps.
If you are interested in regulation-related asset agreements, please join the discussion! Discussion on the regulatory extension to sUDT
NFT standard RFC on CKB: a more flexible solution than ERC 721
Similar to DeFi, the NFT space has grown very fast, and we even find that many NFT projects have learned from many DeFi operations and their associated business logic. NFT trading platform Rari provides their own governance token $Rari for liquidity mining through NFT trading on their platform, and MEME and Aavegotchi allow users to deposit tokens to receive a collectible NFT, but also can be sold on their NFT auction platform.
The Nervos NFT RFC proposal is different from the well known ERC 721 specification. The RFC of Nervos NFT is mainly based on ERC 1155 and is written with the programming features of the Nervos Cell Model.
First of all, the Nervos NFT RFC proposal is more extensible. In addition to the CryptoKitty scenario, in which “every cat is unique", scenarios in which each unique NFT has an issued quantity, such as those seen in games (with items or cards) can be also be accomplished through the Nervos NFT specification.
The NFT spec also allows a single address to create multiple numbers of NFT instances. This ensures the numerous NFT from dApps like games and collectible cards can be issued by single address, and the same NFT instance can be stored in a single cell to save space.
Finally, the NFT spec takes advantage of sUDT, which provides a clear specification and interface for different kinds of users to have different classes of authority, according to their access specified by the lock script.
Nervos applies the RFC (Request for Comments) process for implementing every building block of the protocol. There were 27 Previous RFCs, which can be found here.
If you are curious about why a design in CKB is what it is now, please post your questions in this repository.
Dev Updates
Core
CKB
( #2370 ) upgrade futures and console
( #2360 ) replace dns resolver
( #2367 ) resolve integration script and build error
( #2277 ) add some utils to generate spendable cells
( #2351 ) add with_sentry feature
( #2280 ) add assume valid target config
( #2347 ) consensus rpc
( #2255 ) chain spec check
( #2271 ) refactor: add some mining utils
( #2343 ) rpc get_raw_tx_pool
( #2348 ) change inflight request tx reach limit status to 1xx
( #2333 ) upgrade tentacle, enable reuse port
Dev Tools（11.13）
Lumos [JavaScript/TypeScript based dapp framework]
(#124) Separate cache from hd
(#123) Add TransactionSkeleton <=> Object conversion
(#122) Create new one if to address previous acp output not found
Release v0.13.2
(#117) Fix Locktime pool CellCollector no dao cells & add tests
(#121) add HexNumber alias and jsdoc comment
(#119) add sql-indexer test code
(#118) add indexer test code
(#120) update travis ci node version
Neuron[Link]
(#1902) fix layout of sync status in the navbar
(#1900) handle ‘migrate-acp’ command in UI
(#1915) refactor: sync estimation
(#1916) fix: hardware wallet windows compatibility
(#1904) Disable sign and export button when the device is not connected
(#1903) fix: hardware sign message should use default address to sign
CKB Explorer[Link]
(#742) upgrade ckb-sdk-ruby to v0.37.0
(#739) support query tx in tx pool
(#752) wrong cell info data
(#750) support query pool tx
(#758) update acp tag
Layer 2
Muta [layer2 framework on CKB]
SECBIT Labs [Zero knowledge proof toolkit for CKB]
(#32) add asvc, clinkv2, marlin, merkletree, poseidon, rescue, spartan examples.
CrossChain
( force-bridge-btc ）[maps BTC on Bitcoin to cBTC on CKB in a trustless way]
( force-bridge-eth ）[maps ETH on Ethereum to cETH on CKB in a trustless way]
(#47) create cell rpc
(#48) add rpc lock and get_sudt_balance
(#46) add eth address to settings
(#41) add json rpc server
(#39) add eth crosschain ci
(#29) add Blake2b.sol
(#27) add Eaglesong.sol
(#24) add eth light client lockscript
(#26) Improve the overall process test of eth to ckb
(#20) add mint token && eth light client relay service
Ecosystem
Hxro [Gamified Crypto Trading Platform]
Tocial [cosplayers’ photo sharing app]
Lay2 [pw-sdk, build dApp on CKB and run them everywhere]
Obsidian Labs[developer IDE]
Synapse [browser wallet and keyper agency]
Release v0.1.4
Fixed unable to display transaction list
BlockABC [onechain CKB and web auth]
GrowFi [token swap functionality]
Obsidian Systems CKB integration with ledger wallets
(#22) Release v0.2.1
(#24) Fix multisig witness calculation
(#23) Move anotated.rs to the plugin and update deps
Summa OneBTC/CKB interoperability (completed)
LeapDAO[Sidechain Framework]
( #69 ) Audit delay script and accompanying unit tests
( #68 ) (mostly) collect deposits
( #66 ) Bridge client
The Nervos Foundation currently runs a grants program for builders. check out the scope and how to apply.
CKB Weekly is curated by a group of people who witnessed Lina’s birth and started this to record her growth. Any views expressed are personal and do not represent an official position of the Nervos project. Got updates or articles you would like to include? Any feedback or other suggestions? Let us know by replying to the email.
If you are interested in contributing, welcome to join the review group on TG.
Meanwhile, there are links below if you want to learn more about the project and community.