區塊鏈嘻哈值

㈠ 鍖哄潡閾炬槸浠涔堟剰鎬

鍖哄潡閾炬妧鏈濡備粖闈炲父嫻佽岋紝浣嗘槸瀹冨埌搴曟槸浠涔堝憿錛熸槸濡備綍宸ヤ綔鐨勶紝瑙ｅ喅浜嗗摢浜涢棶棰橈紝鍙堟湁鍝浜涚敤閫斿憿錛熶粖澶╂垜鏉ョ敤閫氫織鏄撴噦鐨勮璦瑙ｉ噴涓涓嬨
鍖哄潡閾鵑【鍚嶆濅箟錛屽氨鏄
涓緇勫寘鍚鏁版嵁鍧楃殑鏁版嵁閾炬潯銆
瀹冩渶鏃╁嚭鐜板湪1991騫達紝鐢變竴緹ょ爺絀朵漢鍛樼敤鏉ョ粰鏁板瓧鍖栨枃妗ｆ墦鏃墮棿鎴熾備互浣垮緱榪欎簺鏂囨。涓嶈兘琚綃℃敼錛岀湅涓婂幓鍖哄潡閾炬妧鏈灝卞儚涓浣嶅叕璇佷漢涓鏍楓
鐒惰岃繖涓鎶鏈鑷浠庨偅涔嬪悗灝辨病鏈夊啀鍙戞尌鍏跺畠浣滅敤錛岀洿鍒2009騫翠竴涓鍙涓鏈鑱鐨勪漢閲囩敤鍖哄潡閾炬妧鏈鍒涢犱簡鏁板瓧鍔犲瘑璐у竵
姣旂壒甯併
涓鏉″尯鍧楅摼灝辨槸
瀵規墍鏈変漢瀹屽叏鍏寮鐨勫垎甯冨紡璐︽湰錛
瀹冩湁涓涓寰堟湁瓚ｇ殑灞炴э細
涓鏃︽暟鎹琚璁板綍鍒板尯鍧楅摼涓鍚庡氨寰堥毦鍐嶅彂鐢熸敼鍙樸
閭ｄ箞瀹冨埌搴曟槸濡備綍宸ヤ綔鐨勫憿錛熸帴涓嬫潵璁╂垜浠棣栧厛鏉ヨ傚療涓涓嬪崟涓鍖哄潡鐨勭粍鎴愩
姣忎釜鍖哄潡閮藉寘鍚浜嗕笁涓閲嶈佺殑閮ㄥ垎錛
鏁版嵁錛屽搱甯屽礆紝鍓嶄竴涓鍖哄潡鐨勫搱甯屽
銆傚叾涓鏁版嵁閮ㄥ垎璺熷尯鍧楅摼鐨勭被鍨嬫湁鍏籌紝渚嬪傦細姣旂壒甯佸尯鍧楅摼涓鐨勫尯鍧椾繚瀛樹簡鐩稿叧鐨勪氦鏄撲俊鎮錛屽寘鎷鍗栧朵拱瀹朵互鍙婁氦鏄撴瘮鐗瑰竵鐨勬暟閲忋
鎺ヤ笅鏉ユ垜浠鍐嶆潵璇翠笅
鍝堝笇鍊礆紝
瀹冨氨鍍忓尯鍧楃殑鎸囩汗涓鏍鳳紝鐢ㄦ潵鏍囪瘑鍖哄潡鍜屽畠鍖呭惈鐨勬暟鎹銆
涓鏃︽煇涓鍖哄潡琚鍒涘緩錛屽畠鐨勫搱甯屽煎氨琚鍞涓鐨勭『瀹氫笅鏉ュ暒錛屾敼鍙樺尯鍧椾腑浠諱綍涓涓佺偣鍎跨殑鍐呭癸紝閮戒細浣垮緱瀹冪殑鍝堝笇鍊煎彂鐢熷緢澶х殑鍙樺寲銆備篃灝辨槸璇村綋浣犻渶瑕佹鏌ュ尯鍧楁槸鍚﹁綃℃敼鏃跺彧闇瑕佹嫻嬪畠鐨勫搱甯屽兼槸鍚﹀彂鐢熷彉鍖栧氨鍙浠ヤ簡銆傚傛灉涓涓鍖哄潡鐨勫搱甯屽煎彂鐢熶簡鍙樺寲錛岄偅瀹冪殑鍐呭逛竴瀹氬彂鐢熶簡鏀瑰彉銆傚畠灝卞啀涔熶笉鏄涔嬪墠鐨勫尯鍧楀暒錛
鍖哄潡涓鍖呭惈鐨勭涓変釜鍏冪礌鏄鍓嶄竴涓鍖哄潡鐨勫搱甯屽礆紝榪欎釜鍏冪礌浣垮緱鍖哄潡涔嬮棿鍙浠ュ艦鎴愪竴涓閾炬潯銆傚苟涓旇兘澶熶嬌寰楀尯鍧楅摼鍗佸垎鐨勫畨鍏ㄣ備婦涓渚嬪瓙錛氬亣璁炬垜浠鏈変竴鏉″尯鍧楅摼鍖呭惈涓変釜鍖哄潡銆傚傚浘鎵紺猴細
3鍙峰尯鍧楁寚鍚2鍙峰尯鍧楋紝2鍙峰尯鍧楀張鎸囧悜1鍙峰尯鍧楋紝1鍙峰尯鍧楄繖閲屾湁鐐圭壒孌婏紝瀹冧笉鎸囧悜鍓嶄竴涓鍖哄潡錛屽洜涓哄畠灝辨槸榪欐潯鍖哄潡閾句腑鐨勭涓涓鍖哄潡錛屼篃鍙
鍒涗笘鍖哄潡
銆傚亣璁劇幇鍦ㄤ綘綃℃敼浜2鍙峰尯鍧楅噷闈㈢殑鏁版嵁錛岃繖灝嗕嬌寰2鍙峰尯鍧楃殑鍝堝笇鍊間篃璺熺潃鍙戠敓鏀瑰彉銆傞偅涔堣繖涔熷皢浣垮緱3鍙峰尯鍧楃殑鎸囧悜鍙樺緱闈炴硶錛岃繘鑰屼嬌寰楀叾鍚庣畫鎵鏈夊尯鍧楅兘鍙樺緱闈炴硶銆傛墍浠ユ敼鍙樹竴涓鍖哄潡浼氫嬌寰楀叾鍚庣畫鎵鏈夊尯鍧楀彉寰楅潪娉曘
浣嗘槸浠呬嬌鐢ㄥ搱甯屽肩殑媯嫻嬫柟娉曚笉瓚抽槻姝㈢敤鎴風℃敼鍖哄潡錛屽洜涓轟互鐜板湪璁＄畻鏈虹殑閫熷害錛屾瘡縐掕兘澶熻＄畻鎴愬崈涓婁竾鐨勫搱甯屽礆紝浣犲畬鍏ㄥ彲浠ョ℃敼涓涓鍖哄潡錛屽苟閲嶆柊璁＄畻鍏跺悗緇鎵鏈夊尯鍧楃殑鍝堝笇鍊箋傝繖鏍峰氨浣垮緱浣犵殑鍖哄潡鍐嶆″彉寰楀悎娉曘傛墍浠ヤ負浜嗛槻姝㈣繖縐嶄簨鎯呭彂鐢燂紝鍖哄潡閾鵑噰鐢ㄤ簡涓縐嶆妧鏈鍙鍋
宸ヤ綔閲忚瘉鏄庯紙POW),
鏉ュ噺緙撴柊鍖哄潡鐨勫壋寤洪熷害錛屾瘮鐗瑰竵鍖哄潡閾句腑澶ф傞渶瑕10鍒嗛挓宸﹀彸鏉ュ畬鎴愬伐浣滈噺璇佹槑錛岀敓鎴愪竴涓鏂扮殑鍖哄潡錛岃繖灝變嬌寰楀尯鍧楅摼鐨勭℃敼鏇村姞鐨勫洶闅俱傞櫎姝や箣澶栧尯鍧楅摼榪樻湁涓縐嶆満鍒舵潵淇濊瘉瀹夊叏鎬э紝閭ｅ氨鏄
鍘諱腑蹇冨寲銆
鐩稿逛簬涓蹇冨寲鐨勭綉緇滐紝鍖哄潡閾鵑噰鐢ㄧ殑鏄涓縐嶅幓涓蹇冨寲鐨勭偣瀵圭偣緗戠粶銆傚苟涓旀墍鏈変漢閮藉彲浠ュ姞鍏ヨ繖涓緗戠粶銆傚綋鏈変漢鍔犲叆榪欎釜緗戠粶鐨勬椂鍊欙紝浠栧氨鑳藉熷緱鍒版暣鏉″尯鍧楅摼鐨勫嶅埗銆傝繖涓浜哄氨鍙浠ユ潵楠岃瘉鍖哄潡閾句笂鐨勫尯鍧楁槸鍚堟硶鐨勮繕鏄琚綃℃敼榪囩殑銆
鎺ヤ笅鏉ワ紝鎴戜滑鏉ョ湅鐪嬪綋鏌愪漢鍒涘緩浜嗘柊鐨勫尯鍧楀悗錛屽尯鍧楅摼浼氬彂鐢熷摢浜涙敼鍙橈紵榪欎釜鏂扮殑鍖哄潡浼氳鍙戦佺粰緗戠粶涓婃墍鏈変漢銆傛瘡涓浜洪獙璇佽繖涓鍖哄潡浠ョ『淇濊繖涓鍖哄潡娌¤綃℃敼榪囷紝濡傛灉鎵鏈変笢瑗塊兘媯楠屾病鏈夐棶棰樺悗錛岃繖涓浜哄氨浼氭妸鏂扮殑鍖哄潡娣誨姞鍒板尯鍧楅摼涓娿
榪欎釜榪囩▼鎴戜滑縐頒箣涓虹綉緇滀笂鎵鏈変漢杈炬垚浜嗗叡璇嗐備粬浠璁ゅ悓緗戠粶涓鍝浜涘尯鍧楁槸鍚堟硶鐨勶紝鍝浜涙槸涓嶅悎娉曠殑錛岄偅浜涜綃℃敼榪囩殑鍖哄潡浼氳緗戠粶鎷掔粷銆傛墍浠ヨ佺℃敼鍖哄潡錛屼綘闇瑕佺℃敼榪欎釜鍖哄潡鍚庣畫鎵鏈夊尯鍧楋紝騫朵笖鎺у埗緗戠粶涓瓚呰繃50%鐨勭敤鎴楓傚彲浠ヨ磋繖鍩烘湰涓婃槸涓嶅彲鑳藉仛寰楀埌鐨勩
鍖哄潡閾炬湰韜涔熷湪涓嶆柇鍙戝睍錛屽悗闈㈠嚭鐜頒簡鏅鴻兘鍚堢害鎶鏈銆傛櫤鑳藉悎綰﹀氨鏄瀛樻斁鍦ㄥ尯鍧楅摼涓婇潰鐨勭▼搴忥紝瀹冨湪鏌愪簺鐗瑰畾鐨勬潯浠朵笅鍙浠ヨ嚜鍔ㄧ殑鎵ц屻傚洜姝ゅ尯鍧楅摼鎶鏈涔熷彲浠ョ敤鏉ュ瓨鏀劇棶鍙叉。妗堬紝鍒涘緩鏁板瓧鍖栧叕璇侊紝鍟嗗搧鏈旀簮絳夌瓑銆傞偅涔堝埌榪欓噷浣犲簲璇ユ槑鐧戒簡鍖哄潡閾劇殑宸ヤ綔鍘熺悊浠ュ強瀹冪殑鐢ㄩ斿暒鍚э紒

㈡ 小白如何秒懂區塊鏈中的哈希計算

​ 小白如何秒懂區塊鏈中的哈希計算

當我在區塊鏈的學習過程中，發現有一個詞像幽靈一樣反復出現，「哈希」，英文寫作「HASH」。

那位說「拉稀」同學你給我出去！！

這個「哈希」據說是來源於密碼學的一個函數，嘗試搜一搜，論文出來一堆一堆的，不是橫式就是豎式，不是表格就是圖片，還有一堆看不懂得xyzabc。大哥，我就是想了解一下區塊鏈的基礎知識，給我弄那麼難幹啥呀？！我最長的密碼就是123456，復雜一點的就是654321，最復雜的時候在最後加個a，你給我寫的那麼復雜明顯感覺腦力被榨乾，僅有的腦細胞成批成批的死亡！為了讓和我一樣的小白同學了解這點，我就勉為其難，努力用傻瓜式的語言講解一下哈希計算，不求最准確但求最簡單最易懂。下面我們開始：

# 一、什麼是哈希演算法

## 1、定義：哈希演算法是將任意長度的字元串變換為固定長度的字元串。

從這里可以看出，可以理解為給**「哈希運算」輸入一串數字，它會輸出一串數字**。

如果我們自己定義 「增一演算法」，那麼輸入1，就輸出2；輸入100就輸出101。

如果我我們自己定義「變大寫演算法」，那麼輸入「abc」輸出「ABC」。

呵呵，先別打我啊！這確實就只是一個函數的概念。

## 2、特點：

這個哈希演算法和我的「增一演算法」和「變大寫演算法」相比有什麼特點呢？

1）**確定性，算得快**：咋算結果都一樣，算起來效率高。

2）**不可逆**：就是知道輸出推不出輸入的值。

3）**結果不可測**：就是輸入變一點，結果天翻地覆毫無規律。

總之，這個哈希運算就是個黑箱，是加密的好幫手！你說「11111」，它給你加密成「」，你說「11112」它給你弄成「」。反正輸入和輸出一個天上一個地下，即使輸入相關但兩個輸出毫不相關。

# 二、哈希運算在區塊鏈中的使用

## 1、數據加密

**交易數據是通過哈希運算進行加密，並把相應的哈希值寫入區塊頭**。如下圖所示，一個區塊頭包含了上一個區塊的hash值，還包含下一個區塊的hash值。

1）、**識別區塊數據是否被篡改**：區塊鏈的哈希值能夠唯一而精準地標識一個區塊，區塊鏈中任意節點通過簡單的哈希計算都可以獲得這個區塊的哈希值，計算出的哈希值沒有變化也就意味著區塊鏈中的信息沒有被篡改。

2）、**把各個區塊串聯成區塊鏈**：每個區塊都包含上一個區塊的哈希值和下一個區塊的值，就相當於通過上一個區塊的哈希值掛鉤到上一個區塊尾，通過下一個區塊的哈希值掛鉤到下一個區塊鏈的頭，就自然而然形成一個鏈式結構的區塊鏈。

## 2、加密交易地址及哈希

在上圖的區塊頭中，有一個Merkle root（默克爾根）的哈希值，它是用來做什麼的呢？

首先了解啥叫Merkle root？ 它就是個二叉樹結構的根。啥叫二叉樹？啥叫根？看看下面的圖就知道了。一分二，二分四，四分八可以一直分下去就叫二叉樹。根就是最上面的節點就叫 根。

這個根的數據是怎麼來的呢？是把一個區塊中的每筆交易的哈希值得出後，再兩兩哈希值再哈希，再哈希，再哈希，直到最頂層的數值。

這么哈希了半天，搞什麼事情？有啥作用呢？

1）、**快速定位每筆交易**：由於交易在存儲上是線性存儲，定位到某筆交易會需要遍歷，效率低時間慢，通過這樣的二叉樹可以快速定位到想要找的交易。

舉個不恰當的例子：怎麼找到0-100之間的一個任意整數？（假設答案是88）那比較好的一個方法就是問：1、比50大還是小？2、比75大還是小？3、比88大還是小？ 僅僅通過幾個問題就可以快速定位到答案。

2）、**核實交易數據是否被篡改**：從交易到每個二叉樹的哈希值，有任何一個數字有變化都會導致Merkle root值的變化。同時，如果有錯誤發生的情況，也可以快速定位錯誤的地方。

## 3、挖礦

  在我們的區塊頭中有個參數叫**隨機數Nonce，尋找這個隨機數的過程就叫做「挖礦」**！網路上任何一台機器只要找到一個合適的數字填到自己的這個區塊的Nonce位置，使得區塊頭這6個欄位（80個位元組）的數據的哈希值的哈希值以18個以上的0開頭，誰就找到了「挖到了那個金子」！既然我們沒有辦法事先寫好一個滿足18個0的數字然後反推Nounce，唯一的做法就是從0開始一個一個的嘗試，看結果是不是滿足要求，不滿足就再試下一個，直到找到。

找這個數字是弄啥呢？做這個有什麼作用呢？

1）、**公平的找到計算能力最強的計算機**：這個有點像我這里有個沙子，再告訴你它也那一個沙灘的中的一粒相同，你把相同的那粒找出來一樣。那可行的辦法就是把每一粒都拿起來都比較一下！那麼比較速度最快的那個人是最有可能先早到那個沙子。這就是所謂的「工作量證明pow」，你先找到這個沙子，我就認為你比較的次數最多，乾的工作最多。

2）、**動態調整難度**：比特幣為了保證10分鍾出一個區塊，就會每2016個塊（2周）的時間計算一下找到這個nonce數字的難度，如果這2016個塊平均時間低於10分鍾則調高難度，如高於十分鍾則調低難度。這樣，不管全網的挖礦算力是怎麼變化，都可以保證10分鍾的算出這個隨機數nonce。

# 三、哈希運算有哪些？

說了這么多哈希運算，好像哈希運算就是一種似的，其實不是！作為密碼學中的哈希運算在不斷的發展中衍生出很多流派。我看了」滿頭包」還是覺得內在機理也太復雜了，暫時羅列如下，小白們有印象知道是怎麼回事就好。

從下表中也可以看得出，哈希運算也在不斷的發展中，有著各種各樣的演算法，各種不同的應用也在靈活應用著單個或者多個演算法。比特幣系統中，哈希運算基本都是使用的SHA256演算法，而萊特幣是使用SCRYPT演算法，誇克幣（Quark）達世幣（DASH）是把很多演算法一層層串聯上使用，Heavycoin（HAV）卻又是把一下演算法並聯起來，各取部分混起來使用。以太坊的POW階段使用ETHASH演算法，ZCASH使用EQUIHASH。

需要說明的是，哈希運算的各種演算法都是在不斷升級完善中，而各種幣種使用的演算法也並非一成不變，也在不斷地優化中。

**總結**：哈希運算在區塊鏈的各個項目中都有著廣泛的應用，我們以比特幣為例就能看到在**數據加密、交易數據定位、挖礦等等各個方面都有著極其重要的作用**。而哈希運算作為加密學的一門方向不斷的發展和延伸，身為普通小白的我們，想理解區塊鏈的一些基礎概念，了解到這個層面也已經足夠。

㈢ 區塊鏈技術中的區塊頭包含的三組元數據是什麼

1、前區塊哈希值。用於索引前區塊
2、挖礦難度、隨機值（用於工作量證明計算）、時間戳
3、梅克爾樹，能夠總結並迅速歸納校驗區塊中全部交易數據的樹根數據。

㈣ 區塊鏈中的哈希值是什麼意思

如果你對區塊鏈領域有所了解，那麼你一定聽說過哈希值，或許我們在瀏覽區塊鏈信息時會經常看到哈希值，但是如果讓我們說說哈希值到底是什麼，可能我們也並不能說明白。我知到，雖然很多人都已經進入幣圈很久，但是對於區塊鏈領域的一些概念還處於一個一知半解，知道又不完全清楚的狀態。其實哈希就是一種壓縮信息的方法，我們可以通過哈希將很長的一段文字壓縮成一小段亂碼，那麼區塊鏈中的哈希值是什麼意思呢？現在就讓我來為大家詳細的講解一下。

哈希值是將任意長度的輸入字元串轉換為密碼並進行固定輸出的過程。哈希值不是一個「密碼」，我們不能通過解密哈希來檢索原始數據，它是一個單向的加密函數。

區塊鏈哈希是什麼?如果是剛開始了解區塊鏈，就需要結合「區塊」的概念來一起理解了。每一個區塊，包含的內容有數據信息，本區塊的哈希值以及上一個區塊的哈希值。區塊中的數據信息，主要是交易雙方的地址與此次交易數量還有交易時間信息等。而哈希值就是尋找到區塊，繼而了解到這些區塊信息的鑰匙。以上就是區塊鏈中哈希的含義了。

區塊鏈通過哈希演算法對一個交易區塊中的交易信息進行加密，並把信息壓縮成由一串數字和字母組成的散列字元串。金窩窩集團分析其哈希演算法的作用如下：區塊鏈的哈希值能夠唯一而精準地標識一個區塊，區塊鏈中任意節點通過簡單的哈希計算都接獲得這個區塊的哈希值，計算出的哈希值沒有變化也就意味著區塊鏈中的信息沒有被篡改。

在區塊鏈中，每個塊都有前一個塊的哈希值，前一個塊被稱為當前塊的父塊，如果考慮父塊有一個當前區塊。它將會有上一個塊的哈希值即父塊。

在區塊鏈中，每個塊都有前一個塊的哈希值。當我們更改當前塊中的任何數據時，塊的哈希值將被更改，這將影響前一個塊，因為它有前一個塊的地址。例如，如果我們只有兩個塊，一個是當前塊，一個是父塊。當前塊將擁有父塊的地址。如果需要更改當前塊中的數據，還需要更改父塊。當只有兩個數據塊時，很容易更改數據，但是現在，當我們在區塊鏈中實現時，2020-01-24 12:32已經挖掘了614272個塊，而614272(th)塊的哈希值為00000000000000000007 。如果我們要更改當前塊614272(th)中的數據，614271塊的哈希地址必須更改，但是614271塊的哈希是不可能更改的，所以這就是區塊鏈被稱為不可變的，數據可信的。區塊鏈的第一個塊，稱為起源塊。你可以從這個起源塊中看到有多少塊被開採到現在。

如果我們對輸入的任何部分做一個小的改變，輸出就會有一個大的改變，請看下面的例子以獲得更多的理解。哈希值是區塊鏈技術不可變的和確定的潛力核心基礎和最重要的方面。它保留了記錄和查看的數據的真實性，以及區塊鏈作為一個整體的完整性。

#比特幣[超話]# #數字貨幣# #歐易OKEx#

㈤ 區塊鏈哈希值可以暴露嗎

可以。
哈希值是將任意長度的輸入字元串轉換為密碼並進行固定輸出的過程。哈希值不是一個「密碼」，我們不能通過解密哈希來檢索原始數據，它是一個單向的加密函數。在區塊鏈中，每個塊都有前一個塊的哈希值，前一個塊被稱為當前塊的父塊，如果考慮父塊有一個當前區塊。
它將會有上一個塊的哈希值即父塊。在區塊鏈中，每個塊都有前一個塊的哈希值。當我們更改當前塊中的任何數據時，塊的哈希值將被更改，這將影響前一個塊，因為它有前一個塊的地址。

㈥ 區塊鏈技術中的哈希演算法是什麼

1.1. 簡介

計算機行業從業者對哈希這個詞應該非常熟悉，哈希能夠實現數據從一個維度向另一個維度的映射，通常使用哈希函數實現這種映射。通常業界使用y = hash(x)的方式進行表示，該哈希函數實現對x進行運算計算出一個哈希值y。
區塊鏈中哈希函數特性：

• 函數參數為string類型；

• 固定大小輸出；

• 計算高效；

• collision-free 即沖突概率小：x != y => hash(x) != hash(y)
  
  隱藏原始信息：例如區塊鏈中各個節點之間對交易的驗證只需要驗證交易的信息熵，而不需要對原始信息進行比對，節點間不需要傳輸交易的原始數據只傳輸交易的哈希即可，常見演算法有SHA系列和MD5等演算法
  

1.2. 哈希的用法

哈希在區塊鏈中用處廣泛，其一我們稱之為哈希指針（Hash Pointer）
哈希指針是指該變數的值是通過實際數據計算出來的且指向實際的數據所在位置，即其既可以表示實際數據內容又可以表示實際數據的存儲位置。下圖為Hash Pointer的示意圖

㈦ 區塊鏈中的哈希值是什麼

區塊鏈中的哈希值是將任意長度的輸入字元串轉換為密碼並進行固定輸出的過程。哈希值不是一個「密碼」，不能通過解密哈希來檢索原始數據，它是一個單向的加密函數。

在區塊鏈中，每個塊都有前一個塊的哈希值。當更改當前塊中的任何數據時，塊的哈希值將被更改，這將影響前一個塊，因為它有前一個塊的地址。例如如果只有兩個塊，一個是當前塊，一個是父塊。當前塊將擁有父塊的地址，如果需要更改當前塊中的數據，還需要更改父塊。

一個加密哈希函數需要具備以下幾個關鍵的特性才能被認為是有用的

1、每個哈希值都是不同的。

2、 對於相同的消息，總是生成相同的哈希值。

3、不可能根據哈希值來決定輸入。

4、即使對輸入的整個哈希值做一個小的更改也會被更改。

㈧ 區塊鏈中的哈希值是什麼

哈希值是將任意長度的輸入字元串轉換為密碼並進行固定輸出的過程。哈希值不是一個「密碼」,我們不能通過解密哈希來檢索原始數據,它是一個單向的加密函數。

區塊鏈：

區塊鏈是一個信息技術領域的術語。從本質上講，它是一個共享資料庫，存儲於其中的數據或信息，具有「不可偽造」「全程留痕」「可以追溯」「公開透明」「集體維護」等特徵。基於這些特徵，區塊鏈技術奠定了堅實的「信任」基礎，創造了可靠的「合作」機制，具有廣闊的運用前景。2019年1月10日，國家互聯網信息辦公室發布《區塊鏈信息服務管理規定》 。

㈨ 區塊鏈 --- 共識演算法

PoW演算法是一種防止分布式服務資源被濫用、拒絕服務攻擊的機制。它要求節點進行適量消耗時間和資源的復雜運算，並且其運算結果能被其他節點快速驗算，以耗用時間、能源做擔保，以確保服務與資源被真正的需求所使用。

PoW演算法中最基本的技術原理是使用哈希演算法。假設求哈希值Hash(r)，若原始數據為r（raw），則運算結果為R（Result）。

R = Hash(r)

哈希函數Hash()的特性是，對於任意輸入值r，得出結果R，並且無法從R反推回r。當輸入的原始數據r變動1比特時，其結果R值完全改變。在比特幣的PoW演算法中，引入演算法難度d和隨機值n，得到以下公式：

Rd = Hash(r+n)

該公式要求在填入隨機值n的情況下，計算結果Rd的前d位元組必須為0。由於哈希函數結果的未知性，每個礦工都要做大量運算之後，才能得出正確結果，而算出結果廣播給全網之後，其他節點只需要進行一次哈希運算即可校驗。PoW演算法就是採用這種方式讓計算消耗資源，而校驗僅需一次。

 

PoS演算法要求節點驗證者必須質押一定的資金才有挖礦打包資格，並且區域鏈系統在選定打包節點時使用隨機的方式，當節點質押的資金越多時，其被選定打包區塊的概率越大。

POS模式下，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000。這個時候，如果你驗證了一個POS區塊，你的幣齡就會被清空為0，同時從區塊中獲得相對應的數字貨幣利息。

節點通過PoS演算法出塊的過程如下：普通的節點要成為出塊節點，首先要進行資產的質押，當輪到自己出塊時，打包區塊，然後向全網廣播，其他驗證節點將會校驗區塊的合法性。

 

DPoS演算法和PoS演算法相似，也採用股份和權益質押。

但不同的是，DPoS演算法採用委託質押的方式，類似於用全民選舉代表的方式選出N個超級節點記賬出塊。

選民把自己的選票投給某個節點，如果某個節點當選記賬節點，那麼該記賬節點往往在獲取出塊獎勵後，可以採用任意方式來回報自己的選民。

這N個記賬節點將輪流出塊，並且節點之間相互監督，如果其作惡，那麼會被扣除質押金。

通過信任少量的誠信節點，可以去除區塊簽名過程中不必要的步驟，提高了交易的速度。
 

拜占庭問題：

拜占庭是古代東羅馬帝國的首都，為了防禦在每塊封地都駐扎一支由單個將軍帶領的軍隊，將軍之間只能靠信差傳遞消息。在戰爭時，所有將軍必須達成共識，決定是否共同開戰。

但是，在軍隊內可能有叛徒，這些人將影響將軍們達成共識。拜占庭將軍問題是指在已知有將軍是叛徒的情況下，剩餘的將軍如何達成一致決策的問題。

BFT：

BFT即拜占庭容錯，拜占庭容錯技術是一類分布式計算領域的容錯技術。拜占庭假設是對現實世界的模型化，由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊等原因，計算機和網路可能出現不可預料的行為。拜占庭容錯技術被設計用來處理這些異常行為，並滿足所要解決的問題的規范要求。

拜占庭容錯系統 ：

發生故障的節點被稱為 拜占庭節點 ，而正常的節點即為 非拜占庭節點 。

假設分布式系統擁有n台節點，並假設整個系統拜占庭節點不超過m台（n ≥ 3m + 1），拜占庭容錯系統需要滿足如下兩個條件：

另外，拜占庭容錯系統需要達成如下兩個指標：

PBFT即實用拜占庭容錯演算法，解決了原始拜占庭容錯演算法效率不高的問題，演算法的時間復雜度是O(n^2)，使得在實際系統應用中可以解決拜占庭容錯問題
 

PBFT是一種狀態機副本復制演算法，所有的副本在一個視圖（view）輪換的過程中操作，主節點通過視圖編號以及節點數集合來確定，即：主節點 p = v mod |R|。v：視圖編號，|R|節點個數，p：主節點編號。

PBFT演算法的共識過程如下：客戶端（Client）發起消息請求（request），並廣播轉發至每一個副本節點（Replica），由其中一個主節點（Leader）發起提案消息pre-prepare，並廣播。其他節點獲取原始消息，在校驗完成後發送prepare消息。每個節點收到2f+1個prepare消息，即認為已經准備完畢，並發送commit消息。當節點收到2f+1個commit消息，客戶端收到f+1個相同的reply消息時，說明客戶端發起的請求已經達成全網共識。

具體流程如下 ：

客戶端c向主節點p發送<REQUEST, o, t, c>請求。o: 請求的具體操作，t: 請求時客戶端追加的時間戳，c：客戶端標識。REQUEST: 包含消息內容m，以及消息摘要d(m)。客戶端對請求進行簽名。

主節點收到客戶端的請求，需要進行以下交驗：

a. 客戶端請求消息簽名是否正確。

非法請求丟棄。正確請求，分配一個編號n，編號n主要用於對客戶端的請求進行排序。然後廣播一條<<PRE-PREPARE, v, n, d>, m>消息給其他副本節點。v：視圖編號，d客戶端消息摘要，m消息內容。<PRE-PREPARE, v, n, d>進行主節點簽名。n是要在某一個范圍區間內的[h, H]，具體原因參見 垃圾回收 章節。

副本節點i收到主節點的PRE-PREPARE消息，需要進行以下交驗：

a. 主節點PRE-PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了一條在同一v下並且編號也是n，但是簽名不同的PRE-PREPARE信息。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。正確請求，副本節點i向其他節點包括主節點發送一條<PREPARE, v, n, d, i>消息, v, n, d, m與上述PRE-PREPARE消息內容相同，i是當前副本節點編號。<PREPARE, v, n, d, i>進行副本節點i的簽名。記錄PRE-PREPARE和PREPARE消息到log中，用於View Change過程中恢復未完成的請求操作。

主節點和副本節點收到PREPARE消息，需要進行以下交驗：

a. 副本節點PREPARE消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. n是否在區間[h, H]內。

d. d是否和當前已收到PRE-PPREPARE中的d相同

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的PREPARE消息，則向其他節點包括主節點發送一條<COMMIT, v, n, d, i>消息，v, n, d, i與上述PREPARE消息內容相同。<COMMIT, v, n, d, i>進行副本節點i的簽名。記錄COMMIT消息到日誌中，用於View Change過程中恢復未完成的請求操作。記錄其他副本節點發送的PREPARE消息到log中。

主節點和副本節點收到COMMIT消息，需要進行以下交驗：

a. 副本節點COMMIT消息簽名是否正確。

b. 當前副本節點是否已經收到了同一視圖v下的n。

c. d與m的摘要是否一致。

d. n是否在區間[h, H]內。

非法請求丟棄。如果副本節點i收到了2f+1個驗證通過的COMMIT消息，說明當前網路中的大部分節點已經達成共識，運行客戶端的請求操作o，並返回<REPLY, v, t, c, i, r>給客戶端，r：是請求操作結果，客戶端如果收到f+1個相同的REPLY消息，說明客戶端發起的請求已經達成全網共識，否則客戶端需要判斷是否重新發送請求給主節點。記錄其他副本節點發送的COMMIT消息到log中。
 

如果主節點作惡，它可能會給不同的請求編上相同的序號，或者不去分配序號，或者讓相鄰的序號不連續。備份節點應當有職責來主動檢查這些序號的合法性。

如果主節點掉線或者作惡不廣播客戶端的請求，客戶端設置超時機制，超時的話，向所有副本節點廣播請求消息。副本節點檢測出主節點作惡或者下線，發起View Change協議。

View Change協議 ：

副本節點向其他節點廣播<VIEW-CHANGE, v+1, n, C , P , i>消息。n是最新的stable checkpoint的編號， C 是 2f+1驗證過的CheckPoint消息集合， P 是當前副本節點未完成的請求的PRE-PREPARE和PREPARE消息集合。

當主節點p = v + 1 mod |R|收到 2f 個有效的VIEW-CHANGE消息後，向其他節點廣播<NEW-VIEW, v+1, V , O >消息。 V 是有效的VIEW-CHANGE消息集合。 O 是主節點重新發起的未經完成的PRE-PREPARE消息集合。PRE-PREPARE消息集合的選取規則：

副本節點收到主節點的NEW-VIEW消息，驗證有效性，有效的話，進入v+1狀態，並且開始 O 中的PRE-PREPARE消息處理流程。
 

在上述演算法流程中，為了確保在View Change的過程中，能夠恢復先前的請求，每一個副本節點都記錄一些消息到本地的log中，當執行請求後副本節點需要把之前該請求的記錄消息清除掉。

最簡單的做法是在Reply消息後，再執行一次當前狀態的共識同步，這樣做的成本比較高，因此可以在執行完多條請求K（例如：100條）後執行一次狀態同步。這個狀態同步消息就是CheckPoint消息。

副本節點i發送<CheckPoint, n, d, i>給其他節點，n是當前節點所保留的最後一個視圖請求編號，d是對當前狀態的一個摘要，該CheckPoint消息記錄到log中。如果副本節點i收到了2f+1個驗證過的CheckPoint消息，則清除先前日誌中的消息，並以n作為當前一個stable checkpoint。

這是理想情況，實際上當副本節點i向其他節點發出CheckPoint消息後，其他節點還沒有完成K條請求，所以不會立即對i的請求作出響應，它還會按照自己的節奏，向前行進，但此時發出的CheckPoint並未形成stable。

為了防止i的處理請求過快，設置一個上文提到的 高低水位區間[h, H] 來解決這個問題。低水位h等於上一個stable checkpoint的編號，高水位H = h + L，其中L是我們指定的數值，等於checkpoint周期處理請求數K的整數倍，可以設置為L = 2K。當副本節點i處理請求超過高水位H時，此時就會停止腳步，等待stable checkpoint發生變化，再繼續前進。
 

在區塊鏈場景中，一般適合於對強一致性有要求的私有鏈和聯盟鏈場景。例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
 

 

Raft基於領導者驅動的共識模型，其中將選舉一位傑出的領導者(Leader)，而該Leader將完全負責管理集群，Leader負責管理Raft集群的所有節點之間的復制日誌。
 

下圖中，將在啟動過程中選擇集群的Leader（S1），並為來自客戶端的所有命令/請求提供服務。 Raft集群中的所有節點都維護一個分布式日誌（復制日誌）以存儲和提交由客戶端發出的命令（日誌條目）。 Leader接受來自客戶端的日誌條目，並在Raft集群中的所有關注者（S2，S3，S4，S5）之間復制它們。

在Raft集群中，需要滿足最少數量的節點才能提供預期的級別共識保證， 這也稱為法定人數。 在Raft集群中執行操作所需的最少投票數為 (N / 2 +1) ，其中N是組中成員總數，即 投票至少超過一半 ，這也就是為什麼集群節點通常為奇數的原因。 因此，在上面的示例中，我們至少需要3個節點才能具有共識保證。

如果法定仲裁節點由於任何原因不可用，也就是投票沒有超過半數，則此次協商沒有達成一致，並且無法提交新日誌。

 

數據存儲：Tidb/TiKV

日誌：阿里巴巴的 DLedger

服務發現：Consul& etcd

集群調度：HashiCorp Nomad
 

只能容納故障節點(CFT)，不容納作惡節點

順序投票，只能串列apply，因此高並發場景下性能差
 

Raft通過解決圍繞Leader選舉的三個主要子問題，管理分布式日誌和演算法的安全性功能來解決分布式共識問題。

當我們啟動一個新的Raft集群或某個領導者不可用時，將通過集群中所有成員節點之間協商來選舉一個新的領導者。 因此，在給定的實例中，Raft集群的節點可以處於以下任何狀態: 追隨者(Follower)，候選人(Candidate)或領導者(Leader)。

系統剛開始啟動的時候，所有節點都是follower，在一段時間內如果它們沒有收到Leader的心跳信號，follower就會轉化為Candidate；

如果某個Candidate節點收到大多數節點的票，則這個Candidate就可以轉化為Leader，其餘的Candidate節點都會回到Follower狀態；

一旦一個Leader發現系統中存在一個Leader節點比自己擁有更高的任期(Term)，它就會轉換為Follower。

Raft使用基於心跳的RPC機制來檢測何時開始新的選舉。 在正常期間， Leader 會定期向所有可用的 Follower 發送心跳消息（實際中可能把日誌和心跳一起發過去）。 因此，其他節點以 Follower 狀態啟動，只要它從當前 Leader 那裡收到周期性的心跳，就一直保持在 Follower 狀態。

當 Follower 達到其超時時間時，它將通過以下方式啟動選舉程序：

根據 Candidate 從集群中其他節點收到的響應，可以得出選舉的三個結果。

共識演算法的實現一般是基於復制狀態機（Replicated state machines），何為 復制狀態機 ：

簡單來說： 相同的初識狀態 + 相同的輸入 = 相同的結束狀態 。不同節點要以相同且確定性的函數來處理輸入，而不要引入一下不確定的值，比如本地時間等。使用replicated log是一個很不錯的注意，log具有持久化、保序的特點，是大多數分布式系統的基石。

有了Leader之後，客戶端所有並發的請求可以在Leader這邊形成一個有序的日誌（狀態）序列，以此來表示這些請求的先後處理順序。Leader然後將自己的日誌序列發送Follower，保持整個系統的全局一致性。注意並不是強一致性，而是 最終一致性 。

日誌由有序編號（log index）的日誌條目組成。每個日誌條目包含它被創建時的任期號（term），和日誌中包含的數據組成，日誌包含的數據可以為任何類型，從簡單類型到區塊鏈的區塊。每個日誌條目可以用[ term, index, data]序列對表示，其中term表示任期， index表示索引號，data表示日誌數據。

Leader 嘗試在集群中的大多數節點上執行復制命令。 如果復製成功，則將命令提交給集群，並將響應發送回客戶端。類似兩階段提交(2PC)，不過與2PC的區別在於，leader只需要超過一半節點同意（處於工作狀態）即可。

leader 、 follower 都可能crash，那麼 follower 維護的日誌與 leader 相比可能出現以下情況

當出現了leader與follower不一致的情況，leader強制follower復制自己的log， Leader會從後往前試 ，每次AppendEntries失敗後嘗試前一個日誌條目（遞減nextIndex值）， 直到成功找到每個Follower的日誌一致位置點（基於上述的兩條保證），然後向後逐條覆蓋Followers在該位置之後的條目 。所以丟失的或者多出來的條目可能會持續多個任期。
 

要求候選人的日誌至少與其他節點一樣最新。如果不是，則跟隨者節點將不投票給候選者。

意味著每個提交的條目都必須存在於這些伺服器中的至少一個中。如果候選人的日誌至少與該多數日誌中的其他日誌一樣最新，則它將保存所有已提交的條目，避免了日誌回滾事件的發生。

即任一任期內最多一個leader被選出。這一點非常重要，在一個復制集中任何時刻只能有一個leader。系統中同時有多餘一個leader，被稱之為腦裂（brain split），這是非常嚴重的問題，會導致數據的覆蓋丟失。在raft中，兩點保證了這個屬性：

因此， 某一任期內一定只有一個leader 。
 

當集群中節點的狀態發生變化（集群配置發生變化）時，系統容易受到系統故障。 因此，為防止這種情況，Raft使用了一種稱為兩階段的方法來更改集群成員身份。 因此，在這種方法中，集群在實現新的成員身份配置之前首先更改為中間狀態（稱為聯合共識）。 聯合共識使系統即使在配置之間進行轉換時也可用於響應客戶端請求，它的主要目的是提升分布式系統的可用性。