以太坊解密

1. 【深度知識】區塊鏈之加密原理圖示(加密,簽名)

先放一張以太坊的架構圖：

在學習的過程中主要是採用單個模塊了學習了解的，包括P2P,密碼學，網路，協議等。直接開始總結：

秘鑰分配問題也就是秘鑰的傳輸問題，如果對稱秘鑰，那麼只能在線下進行秘鑰的交換。如果在線上傳輸秘鑰，那就有可能被攔截。所以採用非對稱加密，兩把鑰匙，一把私鑰自留，一把公鑰公開。公鑰可以在網上傳輸。不用線下交易。保證數據的安全性。

如上圖，A節點發送數據到B節點，此時採用公鑰加密。A節點從自己的公鑰中獲取到B節點的公鑰對明文數據加密，得到密文發送給B節點。而B節點採用自己的私鑰解密。

2、無法解決消息篡改。

如上圖，A節點採用B的公鑰進行加密，然後將密文傳輸給B節點。B節點拿A節點的公鑰將密文解密。

1、由於A的公鑰是公開的，一旦網上黑客攔截消息，密文形同虛設。說白了，這種加密方式，只要攔截消息，就都能解開。

2、同樣存在無法確定消息來源的問題，和消息篡改的問題。

如上圖，A節點在發送數據前，先用B的公鑰加密，得到密文1，再用A的私鑰對密文1加密得到密文2。而B節點得到密文後，先用A的公鑰解密，得到密文1，之後用B的私鑰解密得到明文。

1、當網路上攔截到數據密文2時， 由於A的公鑰是公開的，故可以用A的公鑰對密文2解密，就得到了密文1。所以這樣看起來是雙重加密，其實最後一層的私鑰簽名是無效的。一般來講，我們都希望簽名是簽在最原始的數據上。如果簽名放在後面，由於公鑰是公開的，簽名就缺乏安全性。

2、存在性能問題，非對稱加密本身效率就很低下，還進行了兩次加密過程。

如上圖，A節點先用A的私鑰加密，之後用B的公鑰加密。B節點收到消息後，先採用B的私鑰解密，然後再利用A的公鑰解密。

1、當密文數據2被黑客攔截後，由於密文2隻能採用B的私鑰解密，而B的私鑰只有B節點有，其他人無法機密。故安全性最高。
2、當B節點解密得到密文1後， 只能採用A的公鑰來解密。而只有經過A的私鑰加密的數據才能用A的公鑰解密成功，A的私鑰只有A節點有，所以可以確定數據是由A節點傳輸過來的。

經兩次非對稱加密，性能問題比較嚴重。

基於以上篡改數據的問題，我們引入了消息認證。經過消息認證後的加密流程如下：

當A節點發送消息前，先對明文數據做一次散列計算。得到一個摘要, 之後將照耀與原始數據同時發送給B節點。當B節點接收到消息後，對消息解密。解析出其中的散列摘要和原始數據，然後再對原始數據進行一次同樣的散列計算得到摘要1, 比較摘要與摘要1。如果相同則未被篡改，如果不同則表示已經被篡改。

在傳輸過程中，密文2隻要被篡改，最後導致的hash與hash1就會產生不同。

無法解決簽名問題，也就是雙方相互攻擊。A對於自己發送的消息始終不承認。比如A對B發送了一條錯誤消息，導致B有損失。但A抵賴不是自己發送的。

在(三)的過程中，沒有辦法解決交互雙方相互攻擊。什麼意思呢？ 有可能是因為A發送的消息，對A節點不利，後來A就抵賴這消息不是它發送的。

為了解決這個問題，故引入了簽名。這里我們將(二)-4中的加密方式，與消息簽名合並設計在一起。

在上圖中，我們利用A節點的私鑰對其發送的摘要信息進行簽名，然後將簽名+原文，再利用B的公鑰進行加密。而B得到密文後，先用B的私鑰解密，然後 對摘要再用A的公鑰解密，只有比較兩次摘要的內容是否相同。這既避免了防篡改問題，有規避了雙方攻擊問題。因為A對信息進行了簽名，故是無法抵賴的。

為了解決非對稱加密數據時的性能問題，故往往採用混合加密。這里就需要引入對稱加密，如下圖:

在對數據加密時，我們採用了雙方共享的對稱秘鑰來加密。而對稱秘鑰盡量不要在網路上傳輸，以免丟失。這里的共享對稱秘鑰是根據自己的私鑰和對方的公鑰計算出的，然後適用對稱秘鑰對數據加密。而對方接收到數據時，也計算出對稱秘鑰然後對密文解密。

以上這種對稱秘鑰是不安全的，因為A的私鑰和B的公鑰一般短期內固定，所以共享對稱秘鑰也是固定不變的。為了增強安全性，最好的方式是每次交互都生成一個臨時的共享對稱秘鑰。那麼如何才能在每次交互過程中生成一個隨機的對稱秘鑰，且不需要傳輸呢？

那麼如何生成隨機的共享秘鑰進行加密呢？

對於發送方A節點，在每次發送時，都生成一個臨時非對稱秘鑰對，然後根據B節點的公鑰 和 臨時的非對稱私鑰 可以計算出一個對稱秘鑰(KA演算法-Key Agreement)。然後利用該對稱秘鑰對數據進行加密，針對共享秘鑰這里的流程如下：

對於B節點，當接收到傳輸過來的數據時，解析出其中A節點的隨機公鑰，之後利用A節點的隨機公鑰 與 B節點自身的私鑰 計算出對稱秘鑰(KA演算法)。之後利用對稱秘鑰機密數據。

對於以上加密方式，其實仍然存在很多問題，比如如何避免重放攻擊(在消息中加入 Nonce )，再比如彩虹表(參考 KDF機制解決 )之類的問題。由於時間及能力有限，故暫時忽略。

那麼究竟應該採用何種加密呢？

主要還是基於要傳輸的數據的安全等級來考量。不重要的數據其實做好認證和簽名就可以，但是很重要的數據就需要採用安全等級比較高的加密方案了。

密碼套件 是一個網路協議的概念。其中主要包括身份認證、加密、消息認證(MAC)、秘鑰交換的演算法組成。

在整個網路的傳輸過程中，根據密碼套件主要分如下幾大類演算法：

秘鑰交換演算法：比如ECDHE、RSA。主要用於客戶端和服務端握手時如何進行身份驗證。

消息認證演算法：比如SHA1、SHA2、SHA3。主要用於消息摘要。

批量加密演算法：比如AES, 主要用於加密信息流。

偽隨機數演算法：例如TLS 1.2的偽隨機函數使用MAC演算法的散列函數來創建一個 主密鑰 ——連接雙方共享的一個48位元組的私鑰。主密鑰在創建會話密鑰（例如創建MAC）時作為一個熵來源。

在網路中，一次消息的傳輸一般需要在如下4個階段分別進行加密，才能保證消息安全、可靠的傳輸。

握手/網路協商階段：

在雙方進行握手階段，需要進行鏈接的協商。主要的加密演算法包括RSA、DH、ECDH等

身份認證階段：

身份認證階段，需要確定發送的消息的來源來源。主要採用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA簽名)等。

消息加密階段：

消息加密指對發送的信息流進行加密。主要採用的加密方式包括DES、RC4、AES等。

消息身份認證階段/防篡改階段：

主要是保證消息在傳輸過程中確保沒有被篡改過。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。

ECC ：Elliptic Curves Cryptography，橢圓曲線密碼編碼學。是一種根據橢圓上點倍積生成 公鑰、私鑰的演算法。用於生成公私秘鑰。

ECDSA ：用於數字簽名,是一種數字簽名演算法。一種有效的數字簽名使接收者有理由相信消息是由已知的發送者創建的，從而發送者不能否認已經發送了消息(身份驗證和不可否認)，並且消息在運輸過程中沒有改變。ECDSA簽名演算法是ECC與DSA的結合，整個簽名過程與DSA類似，所不一樣的是簽名中採取的演算法為ECC，最後簽名出來的值也是分為r,s。 主要用於身份認證階段 。

ECDH ：也是基於ECC演算法的霍夫曼樹秘鑰，通過ECDH，雙方可以在不共享任何秘密的前提下協商出一個共享秘密，並且是這種共享秘鑰是為當前的通信暫時性的隨機生成的，通信一旦中斷秘鑰就消失。 主要用於握手磋商階段。

ECIES： 是一種集成加密方案,也可稱為一種混合加密方案，它提供了對所選擇的明文和選擇的密碼文本攻擊的語義安全性。ECIES可以使用不同類型的函數：秘鑰協商函數(KA)，秘鑰推導函數(KDF)，對稱加密方案(ENC)，哈希函數(HASH), H-MAC函數(MAC)。

ECC 是橢圓加密演算法，主要講述了按照公私鑰怎麼在橢圓上產生，並且不可逆。 ECDSA 則主要是採用ECC演算法怎麼來做簽名， ECDH 則是採用ECC演算法怎麼生成對稱秘鑰。以上三者都是對ECC加密演算法的應用。而現實場景中，我們往往會採用混合加密(對稱加密，非對稱加密結合使用，簽名技術等一起使用)。 ECIES 就是底層利用ECC演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密，對稱加密和簽名的功能。

<meta charset="utf-8">

這個先訂條件是為了保證曲線不包含奇點。

所以，隨著曲線參數a和b的不斷變化，曲線也呈現出了不同的形狀。比如:

所有的非對稱加密的基本原理基本都是基於一個公式 K = k G。其中K代表公鑰，k代表私鑰，G代表某一個選取的基點。非對稱加密的演算法 就是要保證 該公式 不可進行逆運算( 也就是說G/K是無法計算的 )。 *

ECC是如何計算出公私鑰呢？這里我按照我自己的理解來描述。

我理解，ECC的核心思想就是：選擇曲線上的一個基點G，之後隨機在ECC曲線上取一個點k(作為私鑰)，然後根據k G計算出我們的公鑰K。並且保證公鑰K也要在曲線上。*

那麼k G怎麼計算呢？如何計算k G才能保證最後的結果不可逆呢？這就是ECC演算法要解決的。

首先，我們先隨便選擇一條ECC曲線，a = -3, b = 7 得到如下曲線：

在這個曲線上，我隨機選取兩個點，這兩個點的乘法怎麼算呢？我們可以簡化下問題，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 5+5+5。 那麼我們只要能在曲線上計算出加法，理論上就能算乘法。所以，只要能在這個曲線上進行加法計算，理論上就可以來計算乘法，理論上也就可以計算k*G這種表達式的值。

曲線上兩點的加法又怎麼算呢？這里ECC為了保證不可逆性，在曲線上自定義了加法體系。

現實中，1+1=2，2+2=4，但在ECC演算法里，我們理解的這種加法體系是不可能。故需要自定義一套適用於該曲線的加法體系。

ECC定義，在圖形中隨機找一條直線，與ECC曲線相交於三個點(也有可能是兩個點)，這三點分別是P、Q、R。

那麼P+Q+R = 0。其中0 不是坐標軸上的0點，而是ECC中的無窮遠點。也就是說定義了無窮遠點為0點。

同樣，我們就能得出 P+Q = -R。 由於R 與-R是關於X軸對稱的，所以我們就能在曲線上找到其坐標。

P+R+Q = 0, 故P+R = -Q , 如上圖。

以上就描述了ECC曲線的世界裡是如何進行加法運算的。

從上圖可看出，直線與曲線只有兩個交點，也就是說 直線是曲線的切線。此時P,R 重合了。

也就是P = R, 根據上述ECC的加法體系，P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0

於是乎得到 2 P = -Q (是不是與我們非對稱演算法的公式 K = k G 越來越近了)。

於是我們得出一個結論，可以算乘法，不過只有在切點的時候才能算乘法，而且只能算2的乘法。

假若 2 可以變成任意個數進行想乘，那麼就能代表在ECC曲線里可以進行乘法運算，那麼ECC演算法就能滿足非對稱加密演算法的要求了。

那麼我們是不是可以隨機任何一個數的乘法都可以算呢？ 答案是肯定的。 也就是點倍積 計算方式。

選一個隨機數 k, 那麼k * P等於多少呢？

我們知道在計算機的世界裡，所有的都是二進制的，ECC既然能算2的乘法，那麼我們可以將隨機數k描 述成二進制然後計算。假若k = 151 = 10010111

由於2 P = -Q 所以 這樣就計算出了k P。 這就是點倍積演算法 。所以在ECC的曲線體系下是可以來計算乘法，那麼以為這非對稱加密的方式是可行的。

至於為什麼這樣計算 是不可逆的。這需要大量的推演，我也不了解。但是我覺得可以這樣理解：

我們的手錶上，一般都有時間刻度。現在如果把1990年01月01日0點0分0秒作為起始點，如果告訴你至起始點為止時間流逝了 整1年，那麼我們是可以計算出現在的時間的，也就是能在手錶上將時分秒指針應該指向00：00：00。但是反過來，我說現在手錶上的時分秒指針指向了00：00：00,你能告訴我至起始點算過了有幾年了么？

ECDSA簽名演算法和其他DSA、RSA基本相似，都是採用私鑰簽名，公鑰驗證。只不過演算法體系採用的是ECC的演算法。交互的雙方要採用同一套參數體系。簽名原理如下：

在曲線上選取一個無窮遠點為基點 G = (x,y)。隨機在曲線上取一點k 作為私鑰， K = k*G 計算出公鑰。

簽名過程：

生成隨機數R, 計算出RG.

根據隨機數R,消息M的HASH值H,以及私鑰k, 計算出簽名S = (H+kx)/R.

將消息M,RG,S發送給接收方。

簽名驗證過程：

接收到消息M, RG,S

根據消息計算出HASH值H

根據發送方的公鑰K,計算 HG/S + xK/S, 將計算的結果與 RG比較。如果相等則驗證成功。

公式推論：

HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG

在介紹原理前，說明一下ECC是滿足結合律和交換律的，也就是說A+B+C = A+C+B = (A+C)+B。

這里舉一個WIKI上的例子說明如何生成共享秘鑰，也可以參考 Alice And Bob 的例子。

Alice 與Bob 要進行通信，雙方前提都是基於 同一參數體系的ECC生成的 公鑰和私鑰。所以有ECC有共同的基點G。

生成秘鑰階段：

Alice 採用公鑰演算法 KA = ka * G ，生成了公鑰KA和私鑰ka, 並公開公鑰KA。

Bob 採用公鑰演算法 KB = kb * G ，生成了公鑰KB和私鑰 kb, 並公開公鑰KB。

計算ECDH階段：

Alice 利用計算公式 Q = ka * KB 計算出一個秘鑰Q。

Bob 利用計算公式 Q' = kb * KA 計算出一個秘鑰Q'。

共享秘鑰驗證：

Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'

故 雙方分別計算出的共享秘鑰不需要進行公開就可採用Q進行加密。我們將Q稱為共享秘鑰。

在以太坊中，採用的ECIEC的加密套件中的其他內容：

1、其中HASH演算法採用的是最安全的SHA3演算法 Keccak 。

2、簽名演算法採用的是 ECDSA

3、認證方式採用的是 H-MAC

4、ECC的參數體系採用了secp256k1, 其他參數體系 參考這里

H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下：

在 以太坊 的 UDP通信時(RPC通信加密方式不同)，則採用了以上的實現方式，並擴展化了。

首先，以太坊的UDP通信的結構如下：

其中，sig是 經過 私鑰加密的簽名信息。mac是可以理解為整個消息的摘要， ptype是消息的事件類型，data則是經過RLP編碼後的傳輸數據。

其UDP的整個的加密，認證，簽名模型如下：

2. Quorum介紹

Quorum和以太坊的主要區別:

Quorum 的主要組件：

1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。

Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。

在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。

為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。

在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。

Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。

Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。

Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊

Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。

有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。

QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：

相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。

要想了解Raft-based Consensus，必須先了解Raft演算法

Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖

1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。

Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。

Raft的動態演示： http://thesecretlivesofdata.com/raft/

安全性保證，對於異常情況下Raft如何處理：

1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。

3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。

4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？

產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。

Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識

一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。

參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901

3. Quorum介紹（一）：Quorum整體結構概述

一句話概括，就是企業級以太坊模型。與傳統的以太坊模型不同，Quorum既然是企業級應用，那麼准入門檻、共識處理以及交易的安全機制上一定與傳統的公鏈模型不同。稍後我們也將從以下幾個方面詳細介紹Quorum的結構模型和核心功能特色。

Quorum本身支持兩種交易狀態

兩種交易核心不同就是內容是否加密。為了區別兩種交易的類型，Quorum在每筆交易的簽名中設置了一個特殊的value值，當簽名中的value值為27或28時，表示這是一筆公開交易，如果是37或者38則是一筆私密交易。私密交易的內容會被加密，只有具有解密能力的節點才能獲得具體的交易內容。

所以最終每個節點會有兩套賬本：一個是所有人都一樣的公有賬本，另一個是自己本地存儲的私有賬本。

所以Quorum的賬本狀態改變機制 允許以下幾種情況的調用

s 表示交易發起者，(X) 表示私密， X表示公開

上述公式可以翻譯為：

Quorum 不允許以下兩種情況的調用

Quorum具體的狀態狀態校驗（世界狀態）可以調用RPC方法 eth_storageRoot(address[, blockNumber]) -> hash

Quorum核心分為兩大塊：Node節點和隱私管理。

Quorum節點本身是一個輕量版的Geth。沿用Geth可以發揮以太坊社區原有的研發優勢，因此Quorum會隨著Geth未來的版本更新而更新。

Quorum節點基於Geth做了一下改動：

Constellation和Tessera（以下簡稱C&T）是一種用Java和Haskell實現的安全傳輸信息模型，他們的作用就像是網路中的信息傳輸代理（MTA, Message Transfer Agent）所有消息的傳輸都通過會話信息秘鑰進行加密

C&T其實是一種多方參與網路中實現個人消息加密的常用組件，在許多應用中都很常見，並不是區塊鏈領域專有技術（筆者注，其實區塊鏈本身就是各種技術的大雜燴，我們很難專門找到一門技術，說它就是區塊鏈 ）。C&T主要包括兩個子模塊：

交易管理模塊主要負責交易的隱私，包括存儲私密交易數據、控制私密交易的訪問、與其他參與者的交易管理器進行私密交易載荷的交換。Transaction Manager 本身並不涉及任何私鑰和私鑰的使用，所有數字加密模塊的功能都由The Enclave來完成。

Transaction Manager屬於靜態/Restful模組，能夠非常容易的被載入。

分布式賬本協議通常都會涉及交易驗證、參與者授權、歷史信息存儲（通過hash鏈）等。為了在加密這一方面實現平行操作的性能擴展和，所有公私鑰生成、數據的加密/解密都由Enclave模塊完成。

4. 以太坊錢包私鑰和地址丟失了怎麼辦

用電腦網盤可嘗試恢復。
第一步，打開電腦，可以看到插入的一個硬碟處於BitLocker加密狀態。
第二步，雙擊這個盤，輸入密碼進行解密操作。
第三步，當輸入完正確的密碼後，硬碟就能顯示大小和查看里邊的內容了。
第四步，這個時候，右鍵點擊硬碟，選擇管理BitLocker選項。
第五步，在彈出的窗口中選擇，再次保存或列印安全密鑰選項。
第六步，選擇，將密鑰保存到文件選項。
最後，密鑰就可以重新獲得了。
如何保存私鑰，1、備用Keyfile或JSON，2、掌握自己的助記詞檔，3、用擁有找回專利的數字錢包，4、錢包私鑰最好使用紙筆抄錄，同時自己保存起來，5、切勿相信一切以索取私鑰為理由的空投代幣行為，要時刻記住，世上沒有免費的午餐。

5. 以太坊錢包私鑰和地址丟失了怎麼辦

1. 嘗試通過電腦網盤恢復丟失的私鑰。首先，打開電腦並識別到您的硬碟處於BitLocker加密狀態。
2. 雙擊該硬碟以輸入密碼進行解密。
3. 成功解密後，您應該能夠看到硬碟的大小及其內部內容。
4. 接下來，右鍵點擊硬碟並選擇「管理BitLocker」。
5. 在彈出的窗口中，選擇「再次保存或列印安全密鑰」選項。
6. 最後，選擇「將密鑰保存到文件」以重新獲得您的密鑰。
關於私鑰的保存方法，請遵循以下幾點建議：
1. 創建並保存備份的Keyfile或JSON文件。
2. 記住並保管好您的助記詞。
3. 使用支持找回功能的數字錢包。
4. 手動抄錄錢包私鑰，並將其安全存放。
5. 不要輕信任何要求提供私鑰以領取空投代幣的信息，始終記住沒有免費的午餐。