CKB community member Retric proposed Nostr Binding Protocol
The original article was published on Github https://github.com/RetricSu/nostr-binding/blob/main/docs/lightpaper-zh.md
In this post, we proposed a protocol to bind basic data structures in the Nostr protocol to the CKB blockchain. Through this binding, we allow Nostr native data to inherit the characteristics of UTXO/Cell on the CKB blockchain, bringing new possibilities for Nostr protocol based on on-chain mechanisms. A potential use case is to issue native assets on Nostr. The Nostr binding protocol also brings a new development paradigm for dApps. Instead of splitting your dApp into two systems (one is the off-chain server, and the other is the on-chain smart contract), we use a consistent system with different data levels to build dApps. This is fundamentally different from Ethereum's model.
The three-layer structure of Web5:
About Nostr
Nostr is a simple and open information distribution protocol that uses a relay-client model to distribute standard messages in a global network. The relay-client model is similar to the P2P network in the blockchain, but cheaper, more flexible, more practical (and more centralized), and more suitable for mass adoption of consumer applications. Standard messages are the core innovation of Nostr. Nostr defines a standard message format based on JSON (this message format is also the basic data structure of the protocol) for describing various different data. It is called "Event".
Event structure:
An Event is a piece of data that contains arbitrary content and is signed by the user, so it can be verified on the client side without trusting any relay servers. All messages you publish in the Nostr protocol are Events of different kinds and requirements. You can learn more about Nostr from NIPs.
About CKB
CKB is a second-layer network of Bitcoin with a UTXO-like and POW-like design. The basic data structure of CKB is called Cell. Cell is a general-purpose UTXO with powerful programmability.
Cell structure:
Script structure:
You can learn more about CKB from docs.nervos.org.
Binding
Binding is about creating a one-to-one mapping between a Nostr Event and a CKB Cell. Events are used to define the details of your assets, while the Cells that are mapped to this Event are used to provide ownership protection and other blockchain-specific capabilities. To create this one-to-one mapping, you need to have a Nostr Event point to a CKB Cell and vice versa. Due to the simplicity of the Nostr and CKB protocols, it is very easy to create this binding.
All we need are two scripts
We introduced two CKB Scripts in the Nostr binding protocol. The first one is the Nostr binding Script, which is a Type Script that defines the method of binding from the Nostr protocol's Event to CKB. It is a very simple Script, but covers the core logic of the binding. The second one is the Nostr lock Script, a Lock Script that uses the Nostr Event as the unlocking signature. It is used to simplify the user experience and the process of building a Nostr dApp based on CKB.
Nostr binding Script
Nostr binding Script is a Type Script that defines the rules for binding certain special events from the Nostr protocol to the chain. Nostr binding Script ensures that the cell using this Script as the Type Script is the only live cell in the CKB blockchain that is bound to a specific Nostr event.
binding Script:
TYPE_ID is used to ensure that there is only one live cell in the blockchain with this type hash
NOSTR_EVENT_ID is used to ensure that the cell only points to a unique Nostr Event
The cell that uses Nostr binding Script as Type Script is the binding cell of Nostr Event.
Nostr bound Event structure:
The cell_type_id tag in the Nostr asset event ensures that the event only points to a unique CKB Cell
Nostr Asset Event presents the asset minted by the user. Nostr Asset Metadata Event is used to describe the metadata of the same asset collection.
Nostr Asset Metadata Event Structure:
Nostr Lock Script
Nostr lock script is a lock script that uses Nostr event as unlock proof. It is used to simplify the user experience and the process of building Nostr dApp based on CKB.
Nostr lock Script structure:
args is set to the public key of the Nostr account. You can also add a POW value in the last 4 bytes, which means that a certain POW difficulty must be met to unlock the Event.
When args is 32 bytes full of 0, it means no one can unlock the lock.
When the first 32 bytes are all 0 and the last 4 bytes are non-zero values, it means that the lock can be unlocked by any Nostr account as long as the unlocking Event meets a certain POW difficulty value (this can be used for fair issuance)
Nostr Unlock Event Structure:
To unlock a CKB Cell that uses the Nostr lock script, a Nostr unlocking event must be provided in the witness field of the transaction. Users can generate multiple unlocking events, but since the corresponding CKB transaction will be recorded in the tag when the event is uploaded to the chain, the remaining events will automatically become invalid, so there is no risk of replay.
Nostr lock Script can also support multi-signature. Its lock Script args can be a Nostr Event ID. The Tag field of the Event records all the owners' M P public keys. Unlocking requires at least N (N<=M) Nostr accounts to provide Nostr unlock Event as proof.
With the help of Nostr lock script, users can use Nostr ecological client and browser plug-in to directly sign and generate unlocking event as signature proof to unlock CKB transaction, so the developers of these off-chain Nostr ecological tools can understand and introduce CKB and blockchain-related codes as little as possible. At the same time, users can almost "not care" about the blockchain. The project party or other volunteers can run a special relay to monitor whether there is a new unlocking event in the Nostr network. If there is, help parse the transaction and submit it to the CKB chain for unlocking. The transaction fee can be paid by reserving part of the balance as a handling fee.
Issued assets
Direct Binding
User: Nostr account and CKB required
Index the CKB Cell and calculate the TYPE_ID of the Cell
Generate a Nostr asset Event with a Nostr signature using TYPE_ID
Use Nostr asset event to generate CKB binding transaction and send it to the chain
By RGB++
User: Nostr account, Bitcoin wallet and Satoshi required
Index UTXO, generate mapping Cell through RGB++, and calculate the TYPE_ID of the Cell
Generate a Nostr asset Event with a Nostr signature using TYPE_ID
Use Nostr asset event to generate CKB binding transaction and send it to the chain
transfer
When using Nostr lock
User: Nostr account required
Index the cell on CKB that you want to unlock using the Nostr lock script
Construct a CKB transaction and replace this Cell with another lock Script
Using the results from step 2, generate a Nostr Unlock Event via the Nostr client/browser extension
Send the Nostr unlock event to a special relay group and submit it to the chain
When using other locks
User: Need to have other locked wallets, no Nostr related operations are required
Simply follow the normal process on CKB/RGB++ to unlock the transfer.
Scalability issues
The main advantage of the Nostr binding protocol is that it is very simple and straightforward. The simplicity also makes it easier for client developers to build products on top of it. On the other hand, the disadvantage of the Nostr binding protocol is the scalability issue. Under this simple design, the throughput of the Nostr token is tied to the CKB blockchain, so the CKB blockchain will become a bottleneck. Considering that Nostr is a more flexible social network aimed at mass adoption, this throughput may become a problem when a large number of users interact with these native assets in the future.
However, we see a few options to address this issue:
Integration with CKB Lightning Network
Since the Nostr native assets created by the Nostr Binding Protocol can be treated as normal CKB assets, we can use it to extend the Nostr Binding Protocol once the CKB Lightning Network is launched. The Nostr Binding Protocol itself does not require any changes, and it is a free feature. But the disadvantage is that you need to wait for the CKB Lightning Network to be launched.
Implementing a simple but useful payment channel
Another option before the launch of CKB Lightning Network is to implement some very simple but useful payment channels like spillman channels. A spillman channel is a one-way payment channel that is simpler to implement. There is a payer and a payee in the channel. This payment channel may not be very useful for blockchains, but in the case of the Nostr binding protocol, it is a great fit for a subscription model between content creators and their followers.
N-to-1 binding instead of 1-to-1 binding
Instead of creating a 1-to-1 binding, we can create an N-to-1 binding between Nostr Event and CKB Cell. In other words, we bundle multiple events into one cell for scalability. This will make the on-chain mapping storage cost much smaller than the off-chain Nostr Event. However, the problem with N-to-1 binding is that it requires designing a new pattern to control and split the ownership of bundled events. This will be more complex and require additional design and implementation work.
RGB style solution
Another way to achieve ultimate scalability is to create an RGB-style solution, using CKB Cell as a one-time seal and making the Nostr protocol an implementation layer similar to the RGB protocol. This solution can choose to implement only the token standard and exclude the general smart contract concept in the original RGB protocol, thereby simplifying the workflow.
Frequently Asked Questions
Why Nostr?
Nostr is an ideal layer for mass-market applications based on cryptography. It is a super simple, straightforward, practical, unbiased, and easy-to-integrate information distribution protocol. Many web3 projects may use something like Arweave and IPFS, which hold completely different values and philosophies. You can think of Nostr as a super loose protocol without the obsession with a fully decentralized P2P network, nor the over-commitment to token economics and incentive mechanisms that have long existed in the web3 world, which makes Nostr more practical and unbiased.
Why not just use blockchain assets?
The idea of enabling users to issue their own native assets in the Nostr network based on Events, rather than using existing blockchain tokens directly in the Nostr network, is based on the simple fact that tokens are meaningless if value is not created. For consumer products, most blockchain assets only create friction in the product workflow without adding value to the product. Instead of forcing token mechanisms into the product, it is better to start from the user's perspective and see what they need and how blockchain can help. We believe that native assets based on Events fit this methodology. Application developers and users can see what they can do with assets from their own perspective, rather than forcing them to accept existing blockchain assets and rules. In addition, Event-based assets are more likely to work seamlessly with the Nostr protocol, bringing new ways to play to existing Nostr ecosystem products and tools.
Why choose CKB?
Due to CKB’s programmability, it is much easier to implement a binding protocol with CKB. Bitcoin is more difficult. In addition, given the unique way CKB is bound to BTC, it would be easier to bind to BTC by first binding to CKB.
Conclusion
In general, as a simple and practical information distribution protocol, Nostr is very suitable for large-scale adoption of consumer applications. The programmability of CKB and its binding relationship with Bitcoin make it an ideal choice for implementing the Nostr binding protocol. At the same time, issuing native assets based on Nostr Event can design new product mechanisms based on applications, allowing Nostr to compete with other traditional Internet applications and find its own unique PMF.