DID Web5 Method Specification - Appendix

%% # DID Web5 Method Specification - Appendix **Title**:: Appendix **Status**:: #x **Created**:: [[2025-06-19]] **Synopsis**:: Appendix %% ### Appendix A: Introduction to CKB Cell Model #### A.1 UTXO Evolution: From Bitcoin to CKB CKB employs an evolved version of Bitcoin's UTXO (Unspent Transaction Output) model, called the Cell model. In traditional UTXO systems, each transaction output has a fixed value and a script that sets conditions for spending. CKB extends this concept with Cells, which can store not only value but also arbitrary data and executable code. The Cell model represents a fundamental shift from the account-based model used in systems like Ethereum, to a state-centric architecture where state transitions are represented directly in transactions. This approach offers significant advantages for identity management systems like DIDs. #### A.2 Cell Structure A Cell in CKB is a basic unit of storage and has the following components: - **Capacity**: Measured in CKBytes, this represents both the monetary value and the storage space available in the Cell. One CKByte token entitles the holder to one byte of data storage on the blockchain. - **Data**: The arbitrary binary content stored in the Cell. This can include the DID document. - **Lock Script**: A mandatory script that controls the ownership and access to a Cell. This ensures only authorized users can consume/spend the Cell. - **Type Script**: An optional script that defines the rules for state transitions, essentially controlling how a Cell can be used or modified in a transaction. #### A.3 Live and Dead Cells Cells are immutable once created on the blockchain. The state update mechanism follows these principles: - **Live Cell**: A Cell that has been created but not yet consumed. Only Live Cells can be used in new transactions. - **Dead Cell**: A Cell that has been consumed by a transaction. Once a Cell is dead, it cannot be used again. When updating data in a Cell (such as modifying a DID Document), the original Cell must be consumed (destroyed), and a new Cell with the updated data must be created, maintaining the same identifier to represent continuity of the entity. #### A.4 Transaction A transaction in CKB represents a state transition that consumes some existing Cells as inputs and creates new Cells as outputs. A transaction's validity is enforced through the scripts contained in the Cells. This verification process ensures the transaction complies with all rules defined in the Cells' Lock and Type Scripts. #### A.5 Consensus The CKB NC-Max Consensus determines the total order of transactions and ensures that: - A Cell can only be spent once. - A Cell can only be spent after being created. ### Appendix B: Test Vectors #### B.1 Method-Specific Identifier Generation Python script that generates the identifier: ```python import hashlib def ckbhash(): return hashlib.blake2b(digest_size=32, person=b'ckb-default-hash') hasher = ckbhash() # inptus[0].since = 0 hasher.update((0).to_bytes(8, byteorder='little')) # inputs[0].previous_output.tx_hash hasher.update(bytes.fromhex('1ecbf88d692a14d7cbc0bfd1a3d5019e4b613247ae438bad52f94148c6009559')) # inputs[0].previous_output.index = 2 hasher.update((2).to_bytes(4, byteorder='little')) # DID Document Cell output index hasher.update((0).to_bytes(8, byteorder='little')) print(hasher.hexdigest()) # => 8434cfe81aa825c275d513eee20e4235294e3420 6ede66a6b5d8f9d7067b1f39 ``` #### B.2 DID Document Cell Data Encoding Assume that the DID document is: ```javascript { "verificationMethods": { "atproto": "did:key:zSigningKey" }, "alsoKnownAs": ["at://alice.test"], "services": { "atproto_pds": { "type": "AtprotoPersonalDataServer", "endpoint": "https://example.test" } } } ``` The DAG-CBOR encoding is: ``` 0x a3687365727669636573a16b617470726f746f5f706473a26474797065781941 7470726f746f506572736f6e616c4461746153657276657268656e64706f696e 747468747470733a2f2f6578616d706c652e746573746b616c736f4b6e6f776e 4173816f61743a2f2f616c6963652e7465737473766572696669636174696f6e 4d6574686f6473a167617470726f746f736469643a6b65793a7a5369676e696e 674b6579 ``` If `local_id` is `None`, the Molecule encoding of the cell data is: ``` 0x 00000000b40000000c000000b4000000a4000000a3687365727669636573a16b 617470726f746f5f706473a264747970657819417470726f746f506572736f6e 616c4461746153657276657268656e64706f696e747468747470733a2f2f6578 616d706c652e746573746b616c736f4b6e6f776e4173816f61743a2f2f616c69 63652e7465737473766572696669636174696f6e4d6574686f6473a167617470 726f746f736469643a6b65793a7a5369676e696e674b6579 ``` ### Appendix C: Implementation Considerations #### C.1 did-web5-ts Type Script Use Molecule strict mode for reading cell data and witness. Note that witness compatibility isn't required, while cell data compatibility is already handled by `union`. #### C.2 DID Web5 PDS This chapter provides comprehensive implementation guidance for the DID Web5 PDS (Personal Data Server) system, which extends the AT Protocol infrastructure to support the `did:web5` DID method through integration with the Nervos CKB blockchain. ***C.2.1 Identity Resolution*** The `resolveHandle` API MUST support `did:web5` identifiers. A PDS MAY query the CKB blockchain directly using the CKB Indexer RPC to locate DID Document Cells, or synchronize all live DID Document Cells locally by processing all interested transactions. The resolution process involves parsing the method-specific identifier to construct appropriate search queries for Live Cells containing the target DID document. **C.2.2 DID Management APIs** Operations on `did:web5` requires building, signing and submitting CKB transactions. A PDS SHOULD hide the complexity to build CKB transactions from users. It is RECOMMENDED to adopt a two-step procedure pattern: In the first step, the user submits an operation request to the PDS. The PDS uses the CKB SDK to construct a CKB transaction and returns the unsigned transaction to the user. In the second step, the user must sign the transaction based on the used Lock Script, typically using a CKB wallet application. The user then submit back the signed transaction to the PDS. The PDS persistently attempts to submit the transaction to the CKB network until it either succeeds or fails. To create Web5 DIDs, users must coordinate with their PDS regarding who supplies the input capacity to cover the DID Document Cell storage cost. - If users provide the capacity, they must sign the creation transaction. - If the PDS covers the cost, it can sign and submit the transaction directly to the CKB network, as it holds the necessary signing authority. In the latter case, the PDS must secure its creation API to prevent abuse. The PDS should temporarily freeze input cells during creation procedures to prevent their use in other transactions. This avoids double-spending conflicts that only one transaction in a conflicting group will succeed. The PDS CAN split cells with large CKB capacity into small ones to allow concurrent creation requests. Since DID operations involve submitting transactions to the CKB network, they are asynchronous by nature. Therefore, the PDS must implement a method for users to check the operation status. ![[DID Web5 Method Specification - Appendix - 1.svg]]