Nostr binding protocol brings new possibilities based on on-chain mechanisms

Web5's Three-Layer Structure:

About Nostr

Nostr is a simple and open information distribution protocol that uses a relay-client model to distribute standard messages across a global network. The relay-client model is similar to the P2P network in blockchain but is cheaper, more flexible, more practical (and more centralized), making it better suited for large-scale adoption of consumer applications. Standard messages are the core innovation of Nostr. Nostr defines a standard message format based on JSON (which is also the basic data structure of the protocol) to describe various types of data. It is called an "Event."

Event Structure:

An Event is a piece of data containing arbitrary content and is signed by the user, allowing it to be verified on the client side without trusting any relay server. All messages you publish in the Nostr protocol are Events of different types and requirements. You can learn more about Nostr from NIPs.

About CKB

CKB is a second-layer network for Bitcoin, designed with UTXO and POW. The basic data structure of CKB is called a Cell. A Cell is a general UTXO with strong programmability.

Cell Structure:

Script Structure:

You can learn more about CKB from docs.nervos.org.

Binding

Binding refers to creating a one-to-one mapping between Nostr Events and CKB Cells. Events are used to define the details of your assets, while the Cells mapped to these Events provide ownership protection and other blockchain-specific capabilities. To create this one-to-one mapping, you need to make a Nostr Event point to a CKB Cell and vice versa. Due to the simplicity of the Nostr and CKB protocols, creating such bindings is very easy.

We Only Need Two Scripts

We introduced two CKB Scripts in the Nostr binding protocol. The first is the Nostr binding Script, which is a Type Script that defines how to bind certain special Events from the Nostr protocol to CKB. It is a very simple Script but covers the core logic of the binding. The second is the Nostr lock Script, which uses Nostr Events as unlocking signatures. It is used to simplify the user experience and the process of building Nostr dApps based on CKB.

Nostr Binding Script

The Nostr binding Script is a Type Script used to define the rules for binding certain special Events from the Nostr protocol to the chain. The Nostr binding Script ensures that a Cell using this Script as a Type Script is the only live Cell on the CKB blockchain bound to a specific Nostr Event.

Binding Script:

• TYPE_ID ensures that there is only one live Cell with this type hash on the blockchain.
• NOSTREVENTID ensures that this Cell points to a unique Nostr Event.

Using the Nostr binding Script as a Type Script Cell is the binding Cell for Nostr Events.

Nostr Binding Event Structure:

• celltypeid tag ensures that the Event in Nostr asset Event points to a unique CKB Cell.

Nostr asset Events represent the assets minted by users. The Nostr asset metadata Event is used to describe the metadata of the same asset collection.

Nostr Asset Metadata Event Structure:

Nostr Lock Script

The Nostr lock Script is a Lock Script that uses Nostr Events as unlocking proofs. It is used to simplify the user experience and the process of building Nostr dApps 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 the unlocking Event must meet a certain POW difficulty.
• When args is 32 bytes of all zeros, it means no one can unlock this lock.
• When the current 32 bytes are all zeros and the last 4 bytes are non-zero, it means that this 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 using the Nostr lock Script, a Nostr unlock Event must be provided in the witness field of the transaction. Users can generate multiple unlock Events, but since the Events will be recorded with the corresponding CKB transaction in the tag when uploaded to the chain, the remaining Events will automatically become invalid, thus avoiding replay risks.

The Nostr lock Script also supports multi-signature. Its lock Script args can be a Nostr Event ID. The Tag field of that Event records the public keys of all M owners. Unlocking requires at least N (N ≤ M) Nostr accounts to provide Nostr unlock Events as proof.

With the help of the Nostr lock Script, users can directly sign and generate unlock Events as signature proofs to unlock CKB transactions using Nostr ecosystem clients and browser plugins, allowing developers of these off-chain Nostr ecosystem tools to understand and introduce as little CKB and blockchain-related code as possible. Meanwhile, users can almost "not care" about the blockchain. Project teams or other volunteers can run a special relay to monitor the Nostr network for new unlock Events, and if there are any, help parse the transactions and submit them to the CKB chain for unlocking. Transaction fees can be paid by reserving part of the balance as a fee Cell.

Issuing Assets

Direct Binding

Users: Need a Nostr account and CKB

1. Index the CKB Cell and calculate the TYPE_ID of that Cell.
2. Use the TYPE_ID to generate a Nostr asset Event with a Nostr signature.
3. Generate a CKB binding transaction using the Nostr asset Event and send it to the chain.

Through RGB++

Users: Need a Nostr account, Bitcoin wallet, and satoshis.

1. Index the UTXO, generate a mapping Cell through RGB++, and calculate the TYPE_ID of that Cell.
2. Use the TYPE_ID to generate a Nostr asset Event with a Nostr signature.
3. Generate a CKB binding transaction using the Nostr asset Event and send it to the chain.

Transfer

When Using Nostr Locking

Users: Need a Nostr account.

• Index the Cell you want to unlock using the Nostr lock Script on CKB.
• Construct a CKB transaction, replacing this Cell with another lock Script.
• Use the result from step 2 to generate a Nostr unlock Event through the Nostr client/browser extension.
• Send the Nostr unlock Event to a special relay group and submit it to the chain.

When Using Other Locking

Users: Need to have a wallet corresponding to the other locking, no Nostr-related operations required.

Just follow the normal process on CKB/RGB++ to unlock the transfer.

Scalability Issues

The main advantage of the Nostr binding protocol is its simplicity and directness. This simplicity also makes it easier for client developers to build products on top of it. On the other hand, the downside of the Nostr binding protocol is the scalability issue. Under this simple design, the throughput of Nostr tokens is bound to the CKB blockchain, making the CKB blockchain a bottleneck. Considering that Nostr is designed as a more flexible social network aimed at large-scale adoption, this throughput may become a problem when a large number of users interact with these native assets in the future.

However, we see some options to address this issue:

1. Integration with CKB Lightning Network

Since the Nostr native assets created by the Nostr binding protocol can be viewed as ordinary CKB assets, once the CKB Lightning Network is launched, we can leverage it to scale the Nostr binding protocol. The Nostr binding protocol itself does not require any changes, making it a free feature. The downside is that we need to wait for the CKB Lightning Network to launch.

2. Implement Simple but Useful Payment Channels

Another option before the launch of the CKB Lightning Network is to implement some very simple but useful payment channels, such as spillman channels. Spillman channels are a type of one-way payment channel that is easier to implement. There is a payer and a payee in the channel. While this payment channel may not be very useful for the blockchain, in the case of the Nostr binding protocol, it is very suitable for subscription models between content creators and their followers.

3. N-to-1 Binding Instead of 1-to-1 Binding

Instead of creating 1-to-1 bindings, we can create N-to-1 bindings between Nostr Events and CKB Cells. In other words, we bundle multiple Events into a single Cell for scalability. This would make the mapping storage costs on-chain much smaller than off-chain Nostr Events. However, the problem with N-to-1 bindings is that it requires designing a new model to control and split the ownership of bundled Events. This will be more complex and require additional design and implementation work.

4. RGB-style Solutions

Another way to achieve ultimate scalability is to create an RGB-style solution that uses CKB Cells as one-time seals and makes the Nostr protocol an implementation layer similar to the RGB protocol. This solution can choose to implement only the token standard while excluding the general smart contract concepts in the original RGB protocol, thus simplifying the workflow.

Frequently Asked Questions

Why choose Nostr?

Nostr is an ideal layer for mass applications based on cryptography. It is a super simple, direct, 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 an obsession with a fully decentralized P2P network, nor an over-commitment to token economics and incentive mechanisms that have long existed in the web3 world, making Nostr more practical and unbiased.

Why not use blockchain assets directly?

Allowing users to issue their native assets based on Events in the Nostr network, rather than using existing blockchain tokens directly in the Nostr network, is primarily based on the simple fact that tokens have no meaning without creating value. For consumer-grade products, most blockchain assets only add friction to the product workflow without adding value to the product. Rather than imposing a token mechanism on 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 Event-based native assets align with this methodology. Application developers and users can look at what they can do with assets from their perspective, rather than forcing them to accept existing blockchain assets and rules. Additionally, Event-based assets are easier to work seamlessly with the Nostr protocol, bringing new playability to existing Nostr ecosystem products and tools.

Why choose CKB?

Due to the programmability of CKB, implementing the binding protocol using CKB is much easier. Bitcoin is even more difficult. Furthermore, considering the unique way CKB binds with BTC, it will be easier to bind first with CKB and then with BTC.

Conclusion

In summary, Nostr, as a simple and practical information distribution protocol, is very suitable for large-scale adoption of consumer-grade 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 Events allows for designing new product mechanisms from the application perspective, enabling Nostr to compete with other traditional internet applications and find its unique PMF.