Low latency DID resolution

THIS SECTION IS NOT NORMATIVE

As previously detailed (See Section 3), a DID and its associated DID Document are constructed through two linked transactions connected by the spending of a unique UTXO Each blockchain transaction refers to a previous blockchain transaction. Given a TxID the ledger allows an observer trace back to the previous transaction. The DID method requires every DID status update to be linked to the initial transaction TxID0, and the DID controller requires verification of the UTXO status corresponding to the most recent transaction on the chain. Therefore, we are required to trace back though every transaction in the chain until we get to TxID0. To make this more efficient, our implementation uses an indexing service to enable forward Tx retrieval and DID status check.

Timing and Latency in DID Resolution Processes

Currently, the DID resolver only searches for transactions in mined blocks. Given that the average time for a block to be mined is approximately 10 minutes, this forms the basis for the resolution time it takes for newly minted DIDs. Since broadcast transactions are not subject to reorganization or modification in the mempool the mempool becomes the first trusted source of transaction status check. In addition, for this specific implementation and the blockchain network of used, which supports large blocks, allows most transactions in the mempool to be included in the following block, enhancing reliability in the mempool. The key innovation of this approach is that it accomplishes low resolution latency, but it shifts the responsibility of the stability of the DID Document from the DID Resolver to the requester of the status check.

User-Controlled Security through Miner Block Validation

This approach shifts the responsibility for determining DID security and stability from the BSV DID method to the user. By using miner block validation, users can assess the security of a DID based on the number of block confirmations. This method provides low resolve latency while giving users the flexibility to determine stability based on the DID Resolution Metadata. The metadata includes information on the number of confirmations (i.e., the distance from the mempool in blocks) that a resolved DID document has received. The BSV DID method specifications will also offer clear guidelines on how different numbers of confirmations correspond to varying levels of stability and security guarantees:

• BSV DID Method specification

  • Resolution process: should specify that mempool will be searched too

  • DID Resolution metadata: should document the new field defined in previous section

  • Security section: should list recommendations on how number of confirmations maps to DID stability and DID Document stability

The DID Spec Registries should define a new field for where the resolver can signal the number of confirmations for the first DID transaction (Tx0) and the confirmations of the resolved (last by default) DID Document transaction.

Confirmations.create	DID Location	Guidance of Use
0	Mempool	Still in the mempool; do not rely on it
< 5	Blockchain	Confirmed recently; handle with moderate care
>= 5	Blockchain	Confirmed in several blocks; ready for normal use

"confirmations": {
- "create": 123, // confirmations of the initial transaction for the resolved DID
- "update": 234  // confirmations of the DID Document transaction for the resolved DID}

For a newly created DID the number of confirmations is highly likely to be the same as both initial transactions are submitted to the bitcoin network together. The update field will signal the confirmations of the resolved DID Document, which by default is the last DID document in the chain, unless resolution of specific DID document version was requested by Version-ID.

The issuers and verifiers can configure number of valid blocks needed to accept a DID as resolved. It could be 0 confirmation requirement to n confirmations.