Showcase | Manage JavaScript Packages on CKB: Code is common knowledge!

Recently I have been doing a fun side-project that is called npm5. It works like npm, the well-known javascript package manager, excepts that all the packages are stored purely on the CKB blockchain. So I guess you can call npm5 a decentrialized JavaScript package manager.

Traditional package managers host the code on a server. npm5 flips this by storing everything on the CKB blockchain. Your packages become immutable, censorship-resistant, and discoverable by anyone with a blockchain connection.

But why?

Since CKB is called common knowledge base and is actually insipired by version control and git, I am always wondering what is the common knowledge that worth to be stored on such a base.

Law feels like one important case. Code works just like law and is another common knowledge too. And believe it or not, CKB is already the place to host important codes——every script(or so-called Smart Contract) are just codes that are hosted on CKB and executed in the on-chain runtime. Mostly, those codes stay on-chain and rarely come down to the off-chain world so few people realize that CKB is already a very important place like github.com/npmjs.com/crate.io etc.

The experiment of npm5 takes this idea a further step. Since CKB hosts important on-chain codes, npm5 tries to make CKB host important off-chain codes as well. off-chain codes are very important assets too since we rely on them to build such a software world that is so interconnected today. Supply chain attacks and things like left-pad incident happened in the JavaScript community, it reminds us of the fragility of a centrialized code registry. Moving such a registry on-chain gives us some benefits below:

1. Tamper-proof and Code integrity

since it is fully on-chain.

2. Better Access control

Lock-script is more secure than Web2 passwords and two-factor authentication, so code owners can better manage their packages.

For a JavaScript package,

  1. at first the publishes and upgrades can be done by the code owner.
  2. Once it becomes important and real open-source with contributors, the lock-script can be upgraded to multisig or DAO governed so it gives the community the power to publish and update the packages.
  3. If the codes become stable and no one needs to touch them, we can upgrade the lock-script to zero lock so it becomes untouchable.

How it Actually Works

The Tech Stack

npm5 is built with some cool tech:

  • CKB JavaScript VM - Smart contracts in TypeScript (It is actually very easy using offckb v4, see toolchain section in the end)
  • Chunked storage - Big packages get split into 300KB pieces for efficient blockchain storage
  • Type hash identification - Cryptographic package IDs instead of human-readable names

The CLI That Feels Familiar

To make it work more real, we also made the npm5 CLI that feels like the npm you already know:

# Install npm5 (it's a package itself!)
npm install -g @retric/npm5

# Publish any npm package to the blockchain
npm5 publish ./node_modules/lodash \\\\
  --private-key YOUR_PRIVATE_KEY \\\\
  --network testnet

# Install by type hash (yeah, it's different)
npm5 add 0x22e1932fa40de75d7c143dc3d9f2a2a4853c9a0c4caf89cb3ac3ce63939c7218 \\\\
  --network testnet

# See what's available
npm5 list --network testnet
# Right now we have one package on-chain
@ckb-js-std/[email protected]
  TypeHash: 0x22e1932fa40de75d7c143dc3d9f2a2a4853c9a0c4caf89cb3ac3ce63939c7218
  Outpoint: 0xd2cfc922d0a7f1444009a2c18633e028899d1514185f43bcba248136dab75582:0x0
  Controlled By Lock Hash: 0x4472b33b4e1845ebe82f2ce5f511bbe012f144c5f3d7b539909adffc83ccda61
--------------------------------------------------

The toolchain

This experiment is also a demo to showcase how to use CKB-JS-VM with a pure JavaScript tech stack to build different ideas other than DeFi or gambling things on the blockchain.

It turns out pretty easy if you are using the offckb toolchain. You are expected to finish all the jobs, including the smart contract and the off-chain SDK/CLI tools, in one or two days using the boilerplate created by offckb.

If you are interested in such a case, please install the toolchain by

npm install -g @offckb/cli@canary

# create a new boilerplate project
offckb create

and get started from GitHub - ckb-devrel/offckb at v0.4.x

9 Likes

I think I heard of this– And forgive my lack of technical knowledge but is it true that this could be implemented to a wallet so the UI could be on chain verified which would mitigate against some more recent strings of hacks which faked the UI and caused the user’s to sign transaction’s to unintended addresses? and also implemented to protect against the copy address switch ? if so i definitely think this would be a great area of focus

1 Like

am I reading it correctly that this would get stored in state? if so it could get prohibitively expensive to operate, each 300kb chunk is $1200 today.

I really like the idea of npm5 and in some ways am beginning to think that CKB apps should / must be built in this way. Looking forward to exploring more!

1 Like

Putting code on-chain won’t solve supply-chain attacks by itself, but I think it’s a start. Preventing wallet UI poisoning takes more than one layer of defense. If the source is on-chain, we can build verification layers on top of it and crowd-source fraud detection by giving users a clear incentive to report tampering. All of this only works if the code is stored somewhere tamper-proof and freely readable by anyone.

1 Like

Yes it is expensive. so from this point of view, it is pretty reasonable to put on-chain codes(aka smart-contract code) on-chain. It might be a little bit “wasteful” to put off-chain codes on-chain. But I think there might be a case that such off-chain codes are valuable enough to justify the cost.

Another way to look at it is that putting code on-chain makes it more verifiable, which builds greater confidence in using it… to build even more code! Since most libraries and packages are built layer by layer, if a large portion of JavaScript code is already on-chain, it becomes cheaper to upload new JavaScript code (say, a custom library) on CKB. This is because the new code can rely on major dependencies that are already stored on-chain. Re-use codes is already a convention on CKB.

2 Likes

interesting indeed :thinking:

if the code is stored in chain history it is also verifiable

2 Likes