區(qū)塊鏈數(shù)據(jù)驗(yàn)證是怎樣實(shí)現(xiàn)的
簡(jiǎn)介
在本文中，我將用示例代碼來(lái)講述我所知道的最簡(jiǎn)單的區(qū)塊鏈應(yīng)用程序的數(shù)據(jù)驗(yàn)證問(wèn)題。
想象一下下面的用例。您收到一份經(jīng)過(guò)多方認(rèn)可的文件，但是又希望確保其的真實(shí)性。該文件可能是您正在購(gòu)買(mǎi)的汽車(chē)的服務(wù)手冊(cè)，也可能是一份購(gòu)房文件，證明您正在購(gòu)買(mǎi)的房子確實(shí)屬于賣(mài)方。
對(duì)文件進(jìn)行數(shù)字簽名以防止被篡改，這已經(jīng)不是什么新鮮事。您可以獲取文件的內(nèi)容并使用你的私鑰進(jìn)行加密，生成一個(gè)加密文件，將該簽名與文件一起發(fā)送給對(duì)方。
文檔的接收者可以再次生成簽名，并驗(yàn)證它是否與所提供的簽名匹配。驗(yàn)證文檔內(nèi)容是否被篡改。
這是MD5校驗(yàn)和的結(jié)果，使用起來(lái)非常方便。它的缺點(diǎn)是您需要接收簽名來(lái)驗(yàn)證文檔的真實(shí)性。
由于從個(gè)人獲取數(shù)據(jù)并非易于信任，因此有時(shí)第三方會(huì)介入提供記錄保存服務(wù)以獲取利潤(rùn)。這種利潤(rùn)動(dòng)機(jī)是保持記錄保持者誠(chéng)實(shí)的原因。但不是一個(gè)完美的解決方案。但是可怕的是，如果經(jīng)濟(jì)激勵(lì)措施改變，記錄保管人可能會(huì)發(fā)生腐敗。監(jiān)管之人，誰(shuí)人監(jiān)管？
區(qū)塊鏈可以為你做什么？
區(qū)塊鏈數(shù)據(jù)存儲(chǔ)是分散的、健壯的和不可更改的。
· 分散意味著數(shù)據(jù)分布式存儲(chǔ)在不同的設(shè)備上。
· 健壯意味著即使某些參與者離開(kāi)或停止合作，數(shù)據(jù)存儲(chǔ)也將繼續(xù)運(yùn)行。
· 不可更改意味著一旦數(shù)據(jù)存儲(chǔ)在區(qū)塊鏈中，就不能更改。
區(qū)塊鏈以優(yōu)雅的方式解決文檔注冊(cè)問(wèn)題。一旦我們?cè)趨^(qū)塊鏈注冊(cè)表中輸入一個(gè)簽名，我們就不必?fù)?dān)心簽名會(huì)被修改以匹配被篡改的文檔。要做到這一點(diǎn)，需要大部分網(wǎng)絡(luò)參與者一致達(dá)到共識(shí)，這使得它幾乎不為人所知。
在此上下文中，文檔可以是任何數(shù)據(jù)集。同樣的模式也適用于證明任何商業(yè)交易、物聯(lián)網(wǎng)數(shù)據(jù)集或用戶身份的真實(shí)性，以及其他許多模式。
現(xiàn)在，了解如何使用這個(gè)構(gòu)建區(qū)塊來(lái)設(shè)計(jì)更復(fù)雜的解決方案是非常有用的。所有區(qū)塊鏈解決方案都依賴于存儲(chǔ)用戶生成的數(shù)據(jù)，這些數(shù)據(jù)可以在不依賴任何人的情況下被信任。
用例實(shí)施
這次我沒(méi)有從頭開(kāi)始編寫(xiě)合同。我正試圖停止重新發(fā)明輪子，區(qū)塊鏈注冊(cè)表已由十幾個(gè)實(shí)施。
智能合約設(shè)計(jì)非常簡(jiǎn)單，只有一個(gè)相關(guān)的合同變量和兩個(gè)函數(shù)。
1. 文檔映射將為文檔計(jì)算的哈希與添加該哈希的區(qū)塊相鏈接。
2. add方法接受哈希并將其存儲(chǔ)在映射中。
3. verifiy方法返回哈希的時(shí)間戳。
pragma solidity ^0.4.18;
contract DocumentRegistry {
mapping （string =》 uint256） documents;
address contractOwner = msg.sender;
function add（string hash）
public
returns （uint256 dateAdded）
{
require （msg.sender == contractOwner）;
var TImeAdded = block.TImestamp;
documents［hash］ = TImeAdded;
return TImeAdded;
}
function verify（string hash）
constant
public
returns （uint256 dateAdded）
{
return documents［hash］;
}
}
前端可以使用contract.add上載文檔，并將簽名計(jì)算為文檔內(nèi)容的sha256。
async function uploadDocument（） {
…
let fileReader = new FileReader（）;
fileReader.onload = function（） {
let documentHash = sha256（fileReader.result）;
…
contract.add（documentHash， function（err， result） {…}）;
…
}
《}
前端還可以允許上載帶有contract.verify的文檔，以及是否在上載之前，它將告知您大約何時(shí)上載。
function verifyDocument（） {
…
let fileReader = new FileReader（）;
fileReader.onload = function（） {
let documentHash = sha256（fileReader.result）;
…
contract.verify（documentHash， function（err， result） {
…
let contractPublishDate = result.toNumber（）;
if （contractPublishDate 》 0） {
let displayDate = new Date（
contractPublishDate * 1000
）.toLocaleString（）;
showInfo（
`Document ${documentHash} is 《b》valid《b》，
date published： ${displayDate}`
）;
}
else
return showError（
`Document ${documentHash} is 《b》invalid《/b》：
not found in the registry.`
）;
}）;
}
…
}
這就是實(shí)現(xiàn)一個(gè)分布式的文檔注冊(cè)表所需要的全部?jī)?nèi)容，操作兩件事情：
1.簽署文件
2.驗(yàn)證文件簽名后是否發(fā)生了更改。
這是因?yàn)閮蓚€(gè)不同的文檔具有相同簽名的可能性非常接近于零。同時(shí)時(shí)間戳可以確定您提供的文檔是在什么時(shí)候注冊(cè)到注冊(cè)表的。
智能合約的代碼可以根據(jù)實(shí)際情況進(jìn)行更新和改進(jìn)，但這17行代碼屬于整個(gè)實(shí)現(xiàn)的核心部分。
結(jié)論
文檔注冊(cè)表是最具有商業(yè)價(jià)值的區(qū)塊鏈應(yīng)用程序的最簡(jiǎn)單實(shí)現(xiàn)。今天，它們?cè)谠S多領(lǐng)域仍然是有相關(guān)的構(gòu)建塊之一，您可以在更復(fù)雜的解決方案中反復(fù)使用它們。
文檔注冊(cè)中心有效地利用區(qū)塊鏈的分散性和不可篡改的屬性，消除了信任任何人所提供的數(shù)據(jù)都是真實(shí)的。雖然這個(gè)想法很簡(jiǎn)單，但是具有革命性。
來(lái)源： 區(qū)塊鏈研究實(shí)驗(yàn)室
下載文檔
