中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文主要列舉了一些我在區(qū)塊鏈產(chǎn)品設(shè)計過程中，遇到的與區(qū)塊鏈相關(guān)的常見問題和處理方案，適用于準(zhǔn)備或初入?yún)^(qū)塊鏈行業(yè)的產(chǎn)品經(jīng)理閱讀。本文中列舉的處理方案并不是唯一的，如果大家有其他方案，或遇到了其他的問題，歡迎留言討論。

一、上鏈數(shù)據(jù)處理

1. Hash

一般的，出于以下原因，我們無法在區(qū)塊鏈上存儲數(shù)據(jù)的原文：

• 數(shù)據(jù)隱私；
• 避免因數(shù)據(jù)量過大，加重全節(jié)點的存儲負(fù)擔(dān)；
• 礦工可能分布于世界各地，假設(shè)北京的礦工廣播了一個高度為100的新挖出的區(qū)塊（命名為區(qū)塊100A），受網(wǎng)速影響，位于北京的另一位礦工和位于非洲的礦工接收到這一區(qū)塊的時間必然不同。區(qū)塊越大，非洲的礦工接收到區(qū)塊100A的時間越晚。這就導(dǎo)致了非洲的礦工可能會在高度為99的區(qū)塊的基礎(chǔ)上繼續(xù)挖礦，進而挖出了區(qū)塊100B并廣播，此時就出現(xiàn)了有競爭關(guān)系的兩條分叉，分叉A和分叉B，直到新的主鏈被選擇。這進一步導(dǎo)致了在未被選擇為主鏈的分叉上挖礦的礦工所做的工作均作廢，造成了資源的浪費。

出于上述原因，普遍做法是在區(qū)塊鏈上存儲數(shù)據(jù)原文的Hash值?；贖ash算法的特點，數(shù)據(jù)原文均會被轉(zhuǎn)換為固定長度的字符串，且無法通過Hash值反推出數(shù)據(jù)原文，簡單有效地避免了上述問題的發(fā)生。

當(dāng)然，這一做法也有其局限性，即只存儲Hash值的區(qū)塊鏈，只能用作數(shù)據(jù)在某一時刻的存在性驗證，而無法替用戶存儲數(shù)據(jù)原文。數(shù)據(jù)原文需由用戶自行保管，或交由第三方機構(gòu)保管（可能面臨數(shù)據(jù)被篡改而無法通過驗證的風(fēng)險）。

2. Merkel Proof

在日常工作中，我們可能會面臨這樣一種情況：一條數(shù)據(jù)包含A、B、C、D四個字段，此時如何將這條數(shù)據(jù)上鏈呢？

簡單的將字段A、B、C、D連接并進行Hash是一種方案，但對于某些場景，比如應(yīng)聘者要將這條數(shù)據(jù)分享給用人單位，但出于隱私考慮，只想分享字段A、B的數(shù)據(jù)原文，而不想分享字段C、D的數(shù)據(jù)原文，在這一場景下，只對數(shù)據(jù)進行Hash計算并上鏈，顯然無法滿足這一需求。

此時，一種可行的方案是基于Merkel Proof，使用各字段計算出Merkel Root Hash，并將該Root Hash上鏈。Merkel Root Hash的計算過程示意見下圖。

當(dāng)用戶在分享數(shù)據(jù)時，愿意展示給他人的字段顯示為數(shù)據(jù)原文，不愿意展示給他人的字段顯示為Hash值，根據(jù)Merkel Proof，拿到這條數(shù)據(jù)的人依然可以計算出Merkel Root Hash，并在區(qū)塊鏈上驗證數(shù)據(jù)是否未被篡改。示意如下圖：

應(yīng)用Merkel Proof除了可以解決涉及隱私的數(shù)據(jù)分享的問題外，還可以大幅降低上鏈數(shù)據(jù)的數(shù)量，間接提高TPS，如果數(shù)據(jù)上鏈?zhǔn)窃谌缫蕴坏裙?，還可以大幅降低上鏈成本。

例如，有100條數(shù)據(jù)需要上鏈，通過Merkel Proof，可以將這100條數(shù)據(jù)計算為一個Merkel Root Hash。

缺點在于，若用戶自行保管數(shù)據(jù)，除了要保管自己的數(shù)據(jù)外，還要保管跟自己的數(shù)據(jù)相關(guān)的數(shù)據(jù)Hash，增加了用戶需要存儲的數(shù)據(jù)量。

示意如下圖，用戶需要保管紅框中的數(shù)據(jù)。

二、私鑰管理

私鑰管理目前常用的有四種模式：

1. 不為用戶生成公鑰和私鑰

用戶在簽名交易（數(shù)據(jù)上鏈）時，由平臺使用統(tǒng)一的私鑰進行簽名。

優(yōu)點：用戶學(xué)習(xí)成本很低；開發(fā)成本低；用戶不需要擔(dān)心私鑰丟失問題。

缺點：由于所有數(shù)據(jù)均使用一個私鑰簽名，無法在區(qū)塊鏈上區(qū)分執(zhí)行數(shù)據(jù)上鏈操作的用戶；過于中心化的處理方式，導(dǎo)致用戶有可能質(zhì)疑上鏈數(shù)據(jù)的真實性；平臺將承擔(dān)重大的安全責(zé)任。

2. 為用戶生成公鑰和私鑰

私鑰由平臺統(tǒng)一保管，用戶在簽名交易（數(shù)據(jù)上鏈）時，由平臺直接使用用戶私鑰簽名。

優(yōu)點：用戶學(xué)習(xí)成本很低；開發(fā)成本低；用戶不需要擔(dān)心私鑰丟失問題；可以在區(qū)塊鏈上分辨出數(shù)據(jù)是由哪個用戶執(zhí)行的上鏈操作。

缺點：過于中心化的處理方式，導(dǎo)致用戶有可能質(zhì)疑上鏈數(shù)據(jù)的真實性；平臺將承擔(dān)重大的安全責(zé)任。

3. Keystore

為用戶生成公鑰和私鑰。其中私鑰由用戶自行設(shè)置密碼加密，并由平臺統(tǒng)一保管。用戶在簽名交易（數(shù)據(jù)上鏈）時，需輸入密碼解密獲得私鑰并簽名。

優(yōu)點：用戶學(xué)習(xí)成本較低；可以在區(qū)塊鏈上分辨出數(shù)據(jù)是由哪個用戶執(zhí)行的上鏈操作；在某種程度上，可以認(rèn)為是去中心化的數(shù)據(jù)上鏈方式。

缺點：開發(fā)成本高；用戶多了一步設(shè)置密碼操作，以及在每次執(zhí)行上鏈操作時多了一步輸入密碼的操作；由于平臺沒有保存用戶私鑰的原文，一旦用戶丟失或忘記用于加密私鑰的密碼，后續(xù)該用戶上鏈的數(shù)據(jù)的真實性將無法保證，甚至無法執(zhí)行上鏈操作。

4. 為用戶生成公鑰和私鑰，由用戶自行保管私鑰。

優(yōu)點：開發(fā)成本很低；可以分辨出數(shù)據(jù)是由哪個用戶執(zhí)行的上鏈操作；完全去中心化的數(shù)據(jù)上鏈方式。

缺點：用戶學(xué)習(xí)成本高；用戶每次執(zhí)行上鏈操作時多了一步輸入私鑰的操作；由于平臺沒有保存用戶私鑰的原文，一旦用戶丟失或忘記私鑰，后續(xù)該用戶上鏈的數(shù)據(jù)的真實性將無法保證，甚至無法執(zhí)行上鏈操作。

具體采用哪種方式，需要根據(jù)去中心化要求、安全、成本、開發(fā)能力等多方情況綜合考慮。

三、私鑰的丟失處理

在第三節(jié)列舉的私鑰管理方案中，無論私鑰由平臺保管還是用戶保管，都可能涉及遺忘私鑰或私鑰的加密密碼的情況。在傳統(tǒng)互聯(lián)網(wǎng)產(chǎn)品中，若用戶忘記密碼，可以通過手機號、郵箱等方式重新設(shè)置密碼，但對于區(qū)塊鏈產(chǎn)品，無論是私鑰還是私鑰的加密密碼，都不能簡單的使用傳統(tǒng)的忘記密碼流程進行處理。

目前一種可行的處理方式是，在區(qū)塊鏈上的智能合約中，記錄用戶信息、用戶公鑰地址、公鑰地址的有效狀態(tài)（包括有效和實效）和失效時間。其中公鑰地址為與用戶私鑰唯一對應(yīng)的公鑰的Hash值，有效狀態(tài)和失效時間用于在數(shù)據(jù)驗證時，驗證數(shù)據(jù)的有效性（在第七節(jié)將具體說明）。

當(dāng)用戶遺忘私鑰或私鑰的加密密碼時，可以為其重新生成一組公私鑰對，并把新的公鑰地址寫入智能合約，并與用戶信息關(guān)聯(lián)，同時將舊公鑰地址的有效狀態(tài)改為失效，并寫入失效時間。

可見，這一方式通過在區(qū)塊鏈上為用戶關(guān)聯(lián)多個公鑰地址，解決了用戶遺忘私鑰或私鑰加密密碼的問題，同時還能標(biāo)識出公鑰的擁有者，便于確定執(zhí)行上鏈數(shù)據(jù)的用戶。

四、用戶的自我數(shù)據(jù)保管

傳統(tǒng)的互聯(lián)網(wǎng)產(chǎn)品，用戶數(shù)據(jù)由平臺中心化保管，這導(dǎo)致了用戶隱私、數(shù)據(jù)安全等問題，且用戶自己產(chǎn)生的數(shù)據(jù)沒有為用戶創(chuàng)造出價值。

而在區(qū)塊鏈產(chǎn)品中，為改變這一情況，需要允許用戶導(dǎo)出自己的數(shù)據(jù)。有一個原則是，用戶導(dǎo)出的數(shù)據(jù)，需要能不依賴于任何中心化的驗證平臺，獨立在區(qū)塊鏈上驗證該數(shù)據(jù)是否存在，這就要求導(dǎo)出的文件中必須包含所有數(shù)據(jù)驗證所需的字段，如數(shù)據(jù)原文、Hash算法等，這些數(shù)據(jù)通常以json文件的形式存。

同時，考慮到j(luò)son文件的可讀性較差，導(dǎo)出的數(shù)據(jù)還可以包含易讀的明文數(shù)據(jù)（比如用戶的原始數(shù)據(jù)文件，如圖片或文檔）。通常會將這些導(dǎo)出的數(shù)據(jù)打包為一個壓縮包供用戶下載。另外，為提升用戶體驗，壓縮包中還可以帶有使用說明，以說明壓縮包中各文件的作用，及數(shù)據(jù)驗證方法。

五、數(shù)據(jù)刪除和編輯

在傳統(tǒng)的互聯(lián)網(wǎng)產(chǎn)品和軟件產(chǎn)品中，一般都允許用戶刪除和編輯自己的數(shù)據(jù)。但對于區(qū)塊鏈產(chǎn)品，如果僅對數(shù)據(jù)庫進行操作，而不在區(qū)塊鏈上采取對應(yīng)措施，會導(dǎo)致已刪除或編輯前的數(shù)據(jù)存在于區(qū)塊鏈上，且能夠通過存在性證明，進而產(chǎn)生安全隱患等。

一般來說，對于刪除的數(shù)據(jù)，需要重新在區(qū)塊鏈上發(fā)起一筆交易，除帶有該數(shù)據(jù)的Hash等常規(guī)信息外，還需要額外帶有數(shù)據(jù)撤銷標(biāo)識。在數(shù)據(jù)驗證時，如果待驗證的數(shù)據(jù)所在交易中，存在撤銷標(biāo)識，則意味著這條數(shù)據(jù)已被刪除，驗證將無法通過。

對于編輯的數(shù)據(jù)，相當(dāng)于在區(qū)塊鏈上發(fā)起兩筆交易，一筆交易用于撤銷編輯前的數(shù)據(jù)，另一筆交易用于將編輯后的數(shù)據(jù)上鏈。

一般來說，用戶自身不具備通過區(qū)塊鏈驗證數(shù)據(jù)是否存在且未被篡改的能力，而是需要通過中心化的平臺提供的驗證能力進行驗證，這里就涉及到平臺需要驗證哪些內(nèi)容。

下面列舉一些較為通用的驗證項（不代表先后順序），可根據(jù)實際需要選?。?/p>

• 獲取待驗證數(shù)據(jù)中，代表該數(shù)據(jù)所在交易的標(biāo)識，并使用該標(biāo)識獲取區(qū)塊鏈上的相應(yīng)交易詳情；
• 從交易詳情中獲取簽發(fā)交易的用戶的ID，并使用用戶ID和交易標(biāo)識檢查該交易是否已被撤銷；
• 驗證數(shù)據(jù)相關(guān)的智能合約是否未被篡改；
• 從交易詳情中獲取簽發(fā)該條數(shù)據(jù)的用戶的公鑰地址，并在用戶管理智能合約（參見第四節(jié)）中，檢查該公鑰地址是否存在且是否未過期；
• 檢查待驗證數(shù)據(jù)的格式是否符合平臺規(guī)范；
• 檢查待驗證數(shù)據(jù)的哈希值是否與區(qū)塊鏈上的交易詳情中記錄的哈希值一致。

本文由@Nik 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash, 基于CC0協(xié)議