在ICO泡沫迅速涌起和迅速破滅后，比特幣仍然一路高歌，在最近突破了9600美金的大關(guān)。作為一種獨立于貨幣體系的數(shù)字加密幣，比特幣成功的本質(zhì)還是要歸功于技術(shù)——區(qū)塊鏈的安全和隱私支撐起了比特幣最核心的價值。
提到區(qū)塊鏈，非對稱加密算法和哈希算法是兩個不能避開的技術(shù)名詞。尤其是哈希算法，在區(qū)塊鏈相關(guān)的技術(shù)文章中總能看到這個名字，卻很難真正理解它的奧秘。今天，我們就來看看哈希算法是如何保護比特幣和其他數(shù)據(jù)的？
學(xué)好哈希算法，用腦子儲存比特幣
如果你準備購買比特幣，你就會擁有一個“比特幣錢包”。通常來講，比特幣錢包會是一個移動/本地客戶端，用戶可以通過客戶端進行交易。但是還有一種更高端的玩法：腦錢包。
我們知道，比特幣實際上是一種“資源”，它并不是像文檔一樣躺在誰的U盤里，而想要確立這種資源的所有權(quán)，則需要由用戶自己生成一串數(shù)字密鑰并儲存到某個地方。交易時，先生成一套只能由交易中某一方用來解密的私有密鑰，再根據(jù)私有密鑰單向加密生成雙方都能看到的共有密鑰。
由于密鑰的生成是獨立于比特幣協(xié)議和區(qū)塊鏈的，所以如何保護好自己的密鑰成了一個大問題，以前甚至發(fā)生過黑客破解比特幣錢包客戶端獲取比特幣的事件。
為了避免這種問題，就有人想出了一個新方法：自己生成一段比特幣密鑰，然后記在自己腦子里。
生成比特幣密鑰的方式并不難，最初始的密鑰只是一串256位的二進制數(shù)字，拋二百多次硬幣即可得到。但想記住二百多個0和1實在是太復(fù)雜了，腦錢包概念的關(guān)鍵在于，用哈希算法SHA-256對密鑰進行校驗，讓256位二進制數(shù)字變成更短的編碼，就可以保證讓這串字符適合人腦記憶。
來自國家安全局，怪不得哈希算法很安全！
不管是拋二百次硬幣用腦子記憶的腦錢包，還是在移動端、PC端作為客戶端的電子錢包，基本都繞不開用SHA-256算法校驗這一步驟。
其實SHA-256算法發(fā)明的最初目的和比特幣毫無關(guān)系，1993年，美國國家安全局設(shè)計了一套用于安全加密的密碼散列函數(shù)——Secure Hash Algorithm，翻譯過來就是安全散列算法。人們更愿意把它叫做SHA，1993年推出的版本名為SHA-0，后來隨著算法不斷的被破解又不斷自我修正，最終推出了數(shù)個SHA算法的變體，其中就包括SHA-256。
SHA最主要的特性就是，接收到二進制數(shù)字消息時會形成一串“數(shù)字摘要”，而這一摘要還可以用來驗證數(shù)字消息的完整性。如上文所示，SHA-256就意味著算法可以把256位的二進制數(shù)字進行壓縮。
很多人會感到疑惑的是，哈希算法對數(shù)字進行壓縮、摘要，那么為什么不可以根據(jù)這些摘要反向“破解”呢？
哈希算法與其說是“加密”，其實更接近于“壓縮”。這其中涉及到一個“映射”的概念。所謂映射，我們可以理解為“代表”。舉個例子，可以用ABC這樣的字符去代表10001101這樣的數(shù)字，字符A可以代表1、001、0001等等，但只得到字符A時，我們無法得知加密前的數(shù)字究竟是1還是001還是0001還是……
用更簡單的案例解釋一下：在比特幣交易中，交易雙方都能得知的共有密鑰是“100”，但只有其中一方知道加密前的私有密鑰是2+78+5+5+10。
得到100這個共有密鑰的人，想要破解私有密鑰只能去挨個去排列“1+0+0+0+99”、“1+1+0+0+98”……如果變成256位的密鑰，幾乎是一個不可能完成的任務(wù)。而想要驗證公有密鑰也很簡單，既然加密前的私有密鑰是2+78+5+5+10，那么99、98這些公有密鑰就都是錯誤的。
忘記比特幣，下載過盜版電影的你早就認識了哈希算法
所以，目前看來哈希算法的壓縮功能最大的用處是在比特幣交易加密上？
實際上哈希算法最大的用處還是壓縮數(shù)據(jù)，之所以被用在比特幣上，是因為其中包含的大量運算貼合了以“消耗資源來獲取比特幣”的規(guī)則。在其他領(lǐng)域中，哈希算法也能發(fā)揮很大作用。
一個比較典型的例子是游戲公司暴雪推出的“One Way Hash”算法。
作為手握魔獸爭霸、星際等等數(shù)款大型游戲的企業(yè)，暴雪和其他企業(yè)一樣，擁有一個巨大的數(shù)據(jù)庫。而當數(shù)據(jù)庫太大時，從中檢索就成了一個巨大的麻煩。
通常情況下在數(shù)據(jù)庫中尋找數(shù)據(jù)就像在KTV點歌，數(shù)據(jù)庫是曲庫，想要找到自己要點的歌，只能把曲庫從頭到尾翻個遍。但也有一種更簡單的方法，那就是建立一種代表關(guān)系，把歌曲名字《小星星》簡寫成XXX，并把這種對應(yīng)關(guān)系儲存在數(shù)據(jù)庫中。尋找歌曲時，如果連XXX都找不到，說明曲庫中不可能存在《小星星》這首歌。
同理，《小星星》=XXX、《愛我中華》=AWZH，這種文字轉(zhuǎn)化成拼音、拼音取首字母的對應(yīng)方式在現(xiàn)實應(yīng)用時可能會涉及到函數(shù)、坐標等等數(shù)學(xué)問題，總之這種對應(yīng)方式被稱作“哈希表”。
但我們在KTV點歌時，搜索XXX得出的結(jié)果不光有《小星星》、還有《笑哈哈》，面對這種同一字符串在哈希表上位置相同的問題，暴雪的程序猿們想出了一種絕妙的解決辦法——在哈希表中用三個哈希值來校驗位置。
也就是說在暴雪KTV的曲庫中，《小星星》（xiaoxingxing）的哈希值可以分別是XXX、OGG和III，這時再搜索歌曲，就幾乎不會遇到《小星星》和《笑哈哈》同時出現(xiàn)的情況了。
同樣的作用也體現(xiàn)在P2P（點對點）傳播上。如果是上古時代的互聯(lián)網(wǎng)用戶，可以對emule（電驢）這款下載軟件有印象，在eMule上可以從全球所有eMule用戶手中接收某一件文件的數(shù)據(jù)上行和下載。
其原理就是，當你想下載電影《戰(zhàn)狼2》時，系統(tǒng)會提取《戰(zhàn)狼2》的哈希
上一篇：
未來已黑，被集體看衰的IBM難再翻身嗎？
下一篇：
AWS推出獎勵計劃，資助機器學(xué)習(xí)研究
