Protocols 節點

Protocols 節點用於記錄用戶使用各種第三方協議的交易情況。Protocols 節點下的子路徑為第三方協議路徑，其應為協議名稱。協議路徑下為用戶使用該協議所產生的具體交易。結構如下：

由於 Protocols 的協議是開放的，所有應用方都可以構建自己的協議。每個協議下的結構由協議制定方/應用方自己決定，但需保證協議節點的標識具有唯一性。

關於協議名字的約定

構建一個新協議節點時，/protocols 之後的子路徑其為協議名稱，即 /protocols/{sub-protocol}。協議名稱沒有限制，應用方可根據自己的需要，構成一個方便閱讀和理解的協議名稱。協議名可以重名，應用方可以根據其格式來獲取所對應的內容。

關於協議的結構和約定

每個協議的結構由協議制定方/應用方約定，每個協議下可以是扁平的一層結構，也可以是複雜的多層結構。如果業務允許的話，該協議的結構和詳細說明應公開，以便其他應用方/數據服務方可以調用和解析。

需注意的是，這些節點的結構雖由協議制定方/應用方決定，但相關的節點創建還是由用戶創建，為用戶所掌握，用戶只記錄和自己相關的協議數據。

協議交易節點

每個子協議下的 PIN 均為用戶使用該協議下的產生的具體交易，每條具體的交易稱為協議交易節點。

• payload 為協議數據的存儲處。協議數據由應用方根據約定的協議自行解析。

• content-type 為數據類型和編碼方式。應用方需根據 content-type 來讀取 payload 數據。

• 協議交易節點的子路徑名稱需為域樹中同一層級內是唯一的，以方便以後用 URI 方式查找。例如可以採用 publickey 作為子級路徑名稱，也可以自行設定，只需確定與 publickey 映射關係即可。

假設某一 MetaID 交易是屬於 SampleBuzz 協議的，其數據格式採用 JSON，數據內容如下：

{"content":"This is a test","title":"Test-Title"}

那麼，該 MetaID 交易的構建參考如下：

OP_FALSE
OP_IF
	metaid                          
	create                           
	/protocols/simplebuzz          
	0                                
	0                                
	application/json;utf-8
	{"content":"This is a test","title":"Test-Title"}
OP_ENDIF

或者

OP_0
OP_RETURN
	metaid                          
	create                           
	/protocols/simplebuzz          
	0                                
	0                                
	application/json;utf-8
	{"content":"This is a test","title":"Test-Title"}

需注意的是，協議交易節點中的 version 值代表了其所遵循的協議版本，不同版本號代表其 payload 內容有可能不一樣。數據解析時，需根據不同的 version 做不同的解析。生成的 MetaID 樹結構參考如下：