Vineyy on Nostr: Nostr Binding Script and Nostr Lock Script correspond to the Type Script and Lock ...
Nostr Binding Script and Nostr Lock Script correspond to the Type Script and Lock Script in the CKB Cell model, respectively. By incorporating Nostr Event data into these two Scripts, we can deeply integrate the Nostr protocol with the CKB blockchain, utilizing the data of Nostr Events to control the behavior and ownership verification of CKB Cells.
Specifically:
Nostr Binding Script (Type Script): By including the Nostr Event ID in the args, it ensures that a CKB Cell can only be bound to a specific Nostr Event. This establishes a one-to-one mapping between the Nostr Event and the CKB Cell.
Nostr Lock Script (Lock Script): By including the Nostr public key in the args and requiring the corresponding private key-signed Nostr Event in the witness, it achieves the goal of controlling the ownership of the CKB Cell using the Nostr private key.
In this way, we can use the data of Nostr Events to express the operation intentions on CKB Cells, such as asset issuance and transfer, in the context of the Nostr protocol. Meanwhile, the Script model of CKB provides powerful verification and execution capabilities for these operations.
Regarding your second question, whether the CKB network transaction will be initiated synchronously when sending the Nostr Event in the Nostr client, it depends on the specific implementation. There are two possible approaches:
Users need to operate both the Nostr client and the CKB wallet: Users first send the Event (e.g., a transfer Event) in the Nostr client, then construct the corresponding CKB transaction in the CKB wallet, including the Nostr Event in the witness, and submit the CKB transaction to the chain.
Only operate the Nostr client: Users send a specific format of Event (e.g., a transfer Event containing CKB transaction data) in the Nostr client. A dedicated relay server listens for these Events, parses the Event data, constructs the CKB transaction offline, and submits it to the CKB network. The entire process is transparent to the user.
The second approach can provide a better user experience, as the user does not perceive the existence of CKB. However, it requires a trustworthy relay server to complete the offline transaction construction work.
The choice of which approach to use depends on the product design goals. Regardless of the approach, the Nostr Event serves as the link between Nostr and CKB, acting as a bridge to allow Nostr clients to control assets on CKB, while enabling CKB Scripts to understand and verify the data of Nostr Events. This is the core idea of the Nostr Binding Protocol.
Specifically:
Nostr Binding Script (Type Script): By including the Nostr Event ID in the args, it ensures that a CKB Cell can only be bound to a specific Nostr Event. This establishes a one-to-one mapping between the Nostr Event and the CKB Cell.
Nostr Lock Script (Lock Script): By including the Nostr public key in the args and requiring the corresponding private key-signed Nostr Event in the witness, it achieves the goal of controlling the ownership of the CKB Cell using the Nostr private key.
In this way, we can use the data of Nostr Events to express the operation intentions on CKB Cells, such as asset issuance and transfer, in the context of the Nostr protocol. Meanwhile, the Script model of CKB provides powerful verification and execution capabilities for these operations.
Regarding your second question, whether the CKB network transaction will be initiated synchronously when sending the Nostr Event in the Nostr client, it depends on the specific implementation. There are two possible approaches:
Users need to operate both the Nostr client and the CKB wallet: Users first send the Event (e.g., a transfer Event) in the Nostr client, then construct the corresponding CKB transaction in the CKB wallet, including the Nostr Event in the witness, and submit the CKB transaction to the chain.
Only operate the Nostr client: Users send a specific format of Event (e.g., a transfer Event containing CKB transaction data) in the Nostr client. A dedicated relay server listens for these Events, parses the Event data, constructs the CKB transaction offline, and submits it to the CKB network. The entire process is transparent to the user.
The second approach can provide a better user experience, as the user does not perceive the existence of CKB. However, it requires a trustworthy relay server to complete the offline transaction construction work.
The choice of which approach to use depends on the product design goals. Regardless of the approach, the Nostr Event serves as the link between Nostr and CKB, acting as a bridge to allow Nostr clients to control assets on CKB, while enabling CKB Scripts to understand and verify the data of Nostr Events. This is the core idea of the Nostr Binding Protocol.