基於比特幣的去中心數字身份實現

02-10

介紹

本體網路是支持多鏈數字身份的實現，本文將會介紹一種基於比特幣的DID實現方法，未來也會成為本體網路的有機組成。本文的方案使用了比特幣區塊鏈上的TX Ref-encoded交易。 DID描述信息由交易內容和補充描述信息（可選）組成，其地址存儲在OP_RETURN欄位中，這裡的地址也可以是一個指向某實體DID描述的IPFS地址。

交易結構

先定義一些縮寫:

Bi = 比特幣地址 i
Pi = 公鑰 i
Si = 私鑰 i

創建初始的比特幣區塊鏈 DID:

創建一個比特幣賬號 (B0/P0/S0)
創建另一個比特幣賬號 (B1/P1/S1)
創建一個比特幣交易:

輸出: 地址指向 B1
可選的輸出: OP_RETURN <DDO描述信息的鏈接>
用於簽名的密鑰是 S0, 代表 P0 身份的擁有者

發起交易TX0 並等待網路確認，得到該交易的 TX Ref encoding TXREF(TX0)

至此，我們生成了一個DID，格式形如： did:btc:<TXREF(TX0)>

下面的流程圖展示了DID的構造過程

定義

DID 視圖

W3C的DID標準方案是如下格式：

did:<method>:<specific-idstring>

在本文中，方法是「btc」代表使用比特幣區塊鏈，specific-idstring指比特幣區塊鏈上已確認交易的TX Ref。

TX Refs

TX Refs在BIP 136 "Bech32 Encoded Transaction Position References"中有描述，他的優點是提供了一個簡潔的方式來引用指定鏈（測試網or主網）上已確認交易的區塊高度和索引。

txid和txref的區別主要是txid只是交易的哈希，可能還沒有被確認，並且不會對區塊鏈進行編碼，而TX Ref必須是已確認的。

查詢 DID

DID的使用方需要能夠從DID構建DDO描述信息。在本文方案中其工作原理如下：

給定一個DID，我們知道交易引用的內容是 (did:btc:<TXREF(TX0)>)
查詢交易。看看這筆交易是否已花費？

否：這是DID的最新版本。我們可以用來構建DID的描述
是：保持區塊同步，等到沒有UTXO花費為止

更新DID的描述

一個實體通過花費一筆UTXO來更新DID的描述內容，交易流程如下：

創建一筆新tx，發送到B2
將OP_RETURN設置為新的DID描述
用S1簽名交易tx

一個DID實現的簡單例子

下面我們基於比特幣測試鏈來做一個DID實現的例子

首先，我們通過TXRef查詢一條DID記錄，返回了DID txtest1-xkyt-fzgq-qq87-xnhn的描述信息。

輸出信息如下

{ "@context": [ "https://schema.org/", "https://w3id.org/security/v1" ], "authorization": [ { "capability": "UpdateDidDescription", "permittedProofType": [ { "proofType": "SatoshiBlockchainSignature2017", "authenticationCredential": [ { "type": [ "EdDsaSAPublicKey", "CryptographicKey" ], "hash-base58check": "mvq9zXGAr76uSoRG5ybEdECuXoPGY42ihh" } ] } ] }, { "capability": "IssueCredential", "permittedProofType": [ [ { "type": [ "EdDsaSAPublicKey", "CryptographicKey" ], "publicKeyHex": "0280e0b456b9e97eecb8028215664c5b99ffa79628b60798edd9d562c6db1e4f85", "owner": "did:btc:xkyt-fzgq-qq87-xnhn", "id": "did:btc:xkyt-fzgq-qq87-xnhn/keys/fundingKey" } ] ], "entity": "did:btc:xkyt-fzgq-qq87-xnhn" }, { "capability": "IssueCredential", "entity": "did:btc:xkyt-fzgq-qq87-xnhn", "permittedProofType": [ [ { "id": "did:example:12345678/keys/1", "type": "RsaCryptographicKey", "owner": "did:example:12345678", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY----- " } ] ] } ], "authenticationCredential": [ { "type": [ "EdDsaSAPublicKey", "CryptographicKey" ], "curve": "secp256k1", "publicKeyHex": "0280e0b456b9e97eecb8028215664c5b99ffa79628b60798edd9d562c6db1e4f85", "owner": "did:btc:xkyt-fzgq-qq87-xnhn", "id": "did:btc:xkyt-fzgq-qq87-xnhn/keys/fundingKey" }, { "id": "did:example:12345678/keys/1", "type": "RsaCryptographicKey", "owner": "did:example:12345678", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY----- " } ], "signature": { "type": "SatoshiBlockchainSignature2017", "id": "did:btc:xkyt-fzgq-qq87-xnhn", "chain": "testnet" }}

構造一個 DID 描述

DID txtest1-xkyt-fzgq-qq87-xnhn 的描述由如下信息指定：

1）由TX Ref查詢區塊鏈交易的內容

2）每個交易有一個OP_RETURN的輸出，指向的信息在data_string欄位，如下：

相應的信息如下：

{ "@context": { "@vocab": "https://w3id.org/btcr/v1" }, "authenticationCredential": [ { "type": [ "EdDsaSAPublicKey", "CryptographicKey" ], "curve": "secp256k1", "publicKeyHex": "0280e0b456b9e97eecb8028215664c5b99ffa79628b60798edd9d562c6db1e4f85" }, { "id": "did:example:12345678/keys/1", "type": "RsaCryptographicKey", "owner": "did:example:12345678", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY----- " } ], "proof": { "type": "EcdsaKoblitzSignature2016", "created": "2017-10-04T16:29:05Z", "creator": "ecdsa-koblitz-pubkey:034c3deaee7b81469d6ac7ab25f8bbf394b166dc85a8dda30f32b24e83ef5a062f", "signatureValue": "IEMc0Ypu5Q1kaCAA4MVZCpXvPzmi3AjTnNvXtogHo6R6LtkeyKTWmK+Yb9sViEkhvZSQjfiAoVghzD48w9CSv44=" }

從上面信息看出，DID描述包含一組授權和憑證信息。

對這部分描述信息做一個解析

這段描述主要授予兩類實體有關的許可權：

1.兩類實體可以頒發憑證

1）一種是沒有id的實體（沒有聲明者），但可以通過（SatoshiBlockchainSignature2017）這個驗證方法和它的十六進位編碼的公鑰來進行描述。

2）一種是有DID描述的實體，具有RsaSignature2017的證明類型

2.兩類實體可以驗證憑證信息

{ "@context": "https://w3id.org/btcr/v1", "authorization": [ { // gives the entity with TBD DID the ability to issue credentials where the "issuer" field is TBD DID. TODO: This could be a default ability. "capability": "IssueCredential", "permittedProofType": [ { // Would we need a different type for off-chain signatures? "proofType": "SatoshiBlockchainSignature2017", "authenticationCredential": [ { "type": [ "EdDsaSAPublicKey", "CryptographicKey" ], "publicKeyHex": "0280e0b456b9e97eecb8028215664c5b99ffa79628b60798edd9d562c6db1e4f85" } ] } ] }, { // enables an entity to issue credentials where the "issuer" field is TBD DID as long as this specific RSA key is used "capability": "IssueCredential", "entity": "did:example:12345678", "permittedProofType": [ { "proofType": "RsaSignature2017", "authenticationCredential": [ { "id": "did:example:12345678/keys/1", "type": "RsaCryptographicKey", "owner": "did:example:12345678", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY----- " } ] } ] } ], "authenticationCredential": [ { "type": [ "EdDsaSAPublicKey", "CryptographicKey" ], "curve": "secp256k1", "publicKeyHex": "0280e0b456b9e97eecb8028215664c5b99ffa79628b60798edd9d562c6db1e4f85" }, { "id": "did:example:12345678/keys/1", "type": "RsaCryptographicKey", "owner": "did:example:12345678", "publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY----- " } ]}

為什麼可以不需要ID、實體和所有者的內容？

假設描述信息存儲在區塊鏈上，那麼它的內容將是不可篡改的，而且所有的區塊鏈交易內容都帶有簽名。因此，改變內容會改變哈希。由於本方案的DID依賴於比特幣的TXRef，所以我們碰到一個問題，我們一開始還沒法使用DID，這裡稱之為TBD DID。所以，我們可以通過省略ID、實體和所有者來避免這個問題，先有屬性然後再綁定DID。

對於鏈接數據對象來說，省略id的方式是非常靈活的，這部分數據是已知的屬性，通過指定聲明者進行證明和關聯。

合併DID描述

通過合併碎片的DID描述片段，我們可以形成完整的DID描述。

如果授權部分缺少實體屬性，需使用已知的DID（如did：btc：xkyt-fzgq-qq87-xnhn）
如果驗證要素缺少所有者，需用已知的DID更新它
如果驗證要素缺少id，有兩種情況：

如果憑證的十六進位編碼的公鑰和證明類型與用於交易簽名的秘鑰匹配，需使用did：btc：xkyt-fzgq-qq87-xnhn / keys / fundingKey表達該ID。注意：/ keys / fundingKey路徑是可以調整的
否則，使用did：btc：xkyt-fzgq-qq87-xnhn / keys / i表達該id，其中i是DID描述片段中的驗證要素的位置。

授權信息由更新DID描述的一筆交易輸出來指定

DID通過花費一筆UTXO來更新
我們看到的輸出形式就是比特幣地址
這時候我們還無法查詢實體的屬性,直到DID描述更新完成後
我們可以約定一個ID的格式，例如：btc：xyv2-xzyq-qqm5-tyke / keys / output_address

遺留問題

基於比特幣的數字身份設計還有不少技術細節需要思考，簡單羅列一些：

上面這個例子沒有給出實體驗證的默認方法
BTC DID需要多少個交易確認數需要被考慮
第一個BTC DID沒有OP_RETURN，這裡也會存在一些審計風險

比特幣是第一代區塊鏈，未來區塊鏈的基礎設施會基於這套體系大幅度升級性能、可擴展性、隱私甚至是新型的點對點通信模式mesh，本體網路的底層平台將會融合這些特性開發更具彈性的DID的解決方案，來滿足下一代全球身份一體化的需求。：