以太坊rlp源碼分析

⑴ 【深度知識】以太坊數據序列化RLP編碼/解碼原理

RLP(Recursive Length Prefix)，中文翻譯過來叫遞歸長度前綴編碼，它是以太坊序列化所採用的編碼方式。RLP主要用於以太坊中數據的網路傳輸和持久化存儲。

對象序列化方法有很多種，常見的像JSON編碼，但是JSON有個明顯的缺點：編碼結果比較大。例如有如下的結構：

變數s序列化的結果是{"name":"icattlecoder","sex":"male"},字元串長度35，實際有效數據是icattlecoder 和male，共計16個位元組，我們可以看到JSON的序列化時引入了太多的冗餘信息。假設以太坊採用JSON來序列化，那麼本來50GB的區塊鏈可能現在就要100GB，當然實際沒這么簡單。

所以，以太坊需要設計一種結果更小的編碼方法。

RLP編碼的定義只處理兩類數據：一類是字元串（例如位元組數組），一類是列表。字元串指的是一串二進制數據，列表是一個嵌套遞歸的結構，裡面可以包含字元串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一個復雜的列表。其他類型的數據需要轉成以上的兩類，轉換的規則不是RLP編碼定義的，可以根據自己的規則轉換，例如struct可以轉成列表，int可以轉成二進制（屬於字元串一類），以太坊中整數都以大端形式存儲。

從RLP編碼的名字可以看出它的特點：一個是遞歸，被編碼的數據是遞歸的結構，編碼演算法也是遞歸進行處理的；二是長度前綴，也就是RLP編碼都帶有一個前綴，這個前綴是跟被編碼數據的長度相關的，從下面的編碼規則中可以看出這一點。

對於值在[0, 127]之間的單個位元組，其編碼是其本身。

例1：a的編碼是97。

如果byte數組長度l <= 55，編碼的結果是數組本身，再加上128+l作為前綴。

例2：空字元串編碼是128，即128 = 128 + 0。

例3：abc編碼結果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。

如果數組長度大於55， 編碼結果第一個是183加數組長度的編碼的長度，然後是數組長度的本身的編碼，最後是byte數組的編碼。

請把上面的規則多讀幾篇，特別是數組長度的編碼的長度。

例4：編碼下面這段字元串：

The length of this sentence is more than 55 bytes, I know it because I pre-designed it
這段字元串共86個位元組，而86的編碼只需要一個位元組，那就是它自己，因此，編碼的結果如下：

184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三個位元組的計算方式如下：

184 = 183 + 1，因為數組長度86編碼後僅佔用一個位元組。
86即數組長度86
84是T的編碼
例5：編碼一個重復1024次"a"的字元串，其結果為：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian編碼為004 0，省略掉前面的零，長度為2，因此185 = 183 + 2。

規則1~3定義了byte數組的編碼方案，下面介紹列表的編碼規則。在此之前，我們先定義列表長度是指子列表編碼後的長度之和。

如果列表長度小於55，編碼結果第一位是192加列表長度的編碼的長度，然後依次連接各子列表的編碼。

注意規則4本身是遞歸定義的。
例6：["abc", "def"]的編碼結果是200 131 97 98 99 131 100 101 102。
其中abc的編碼為131 97 98 99,def的編碼為131 100 101 102。兩個子字元串的編碼後總長度是8，因此編碼結果第一位計算得出：192 + 8 = 200。

如果列表長度超過55，編碼結果第一位是247加列表長度的編碼長度，然後是列表長度本身的編碼，最後依次連接各子列表的編碼。

規則5本身也是遞歸定義的，和規則3相似。

例7：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的編碼結果是:

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前兩個位元組的計算方式如下：

248 = 247 +1
88 = 86 + 2，在規則3的示例中，長度為86，而在此例中，由於有兩個子字元串，每個子字元串本身的長度的編碼各佔1位元組，因此總共佔2位元組。
第3個位元組179依據規則2得出179 = 128 + 51
第55個位元組163同樣依據規則2得出163 = 128 + 35

例8：最後我們再來看個稍復雜點的例子以加深理解遞歸長度前綴，

["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
編碼結果是：

248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一項字元串abc根據規則2，編碼結果為131 97 98 99,長度為4。
列表第二項也是一個列表項：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根據規則5，結果為

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
長度為90，因此，整個列表的編碼結果第二位是90 + 4 = 94, 佔用1個位元組，第一位247 + 1 = 248

以上5條就是RPL的全部編碼規則。

各語言在具體實現RLP編碼時，首先需要將對像映射成byte數組或列表兩種形式。以go語言編碼struct為例，會將其映射為列表，例如Student這個對象處理成列表["icattlecoder","male"]

如果編碼map類型，可以採用以下列表形式：

[["",""],["",""],["",""]]

解碼時，首先根據編碼結果第一個位元組f的大小，執行以下的規則判斷：

1.如果f∈ [0,128),那麼它是一個位元組本身。

2.如果f∈[128,184)，那麼它是一個長度不超過55的byte數組，數組的長度為 l=f-128

3.如果f∈[184,192)，那麼它是一個長度超過55的數組，長度本身的編碼長度ll=f-183,然後從第二個位元組開始讀取長度為ll的bytes，按照BigEndian編碼成整數l，l即為數組的長度。

4.如果f∈(192,247]，那麼它是一個編碼後總長度不超過55的列表，列表長度為l=f-192。遞歸使用規則1~4進行解碼。

5.如果f∈(247,256]，那麼它是編碼後長度大於55的列表，其長度本身的編碼長度ll=f-247,然後從第二個位元組讀取長度為ll的bytes,按BigEndian編碼成整數l，l即為子列表長度。然後遞歸根據解碼規則進行解碼。

以上解釋了什麼叫遞歸長度前綴編碼，這個名字本身很好的解釋了編碼規則。

（1） 以太坊源碼學習—RLP編碼( https://segmentfault.com/a/1190000011763339 )
（2）簡單分析RLP編碼原理
( https://blog.csdn.net/itchosen/article/details/78183991 )

⑵ rlp代表什麼呢

RLP（Radio Link Protocol，無線連接協議），是一種嚴格的糾錯方式。

當數據在接收端被 「查出」有錯後，接收端可要求電話重新進行數據傳輸，如有必要，反復進行，直至接收數據完全正確為止。

RLP (遞歸長度前綴)提供了一種適用於任意二進制數據數組的編碼，RLP已經成為以太坊中對對象進行序列化的主要編碼方式。

RLP的唯一目標就是解決結構體的編碼問題；對原子數據類型（比如，字元串，整數型，浮點型）的編碼則交給更高層的協議；以太坊中要求數字必須是一個大端位元組序的、沒有零佔位的存儲的格式（也就是說，一個整數0和一個空數組是等同的）。

對於在 RLP 格式中對一個字典數據的編碼問題，有兩種建議的方式，一種是通過二維數組表達鍵值對，比如[[k1,v1],[k2,v2]...]，並且對鍵進行字典序排序；另一種方式是通過以太坊文檔中提到的高級的基數樹編碼來實現。

⑶ 區塊鏈加密網路效應是什麼(區塊鏈加密解密)

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

在學習的過程中主要是採用單個模塊了學習了解的，包括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演算法-KeyAgreement)。然後利用該對稱秘鑰對數據進行加密，針對共享秘鑰這里的流程如下：

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

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

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

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

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

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

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

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

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

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

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

握手/網路協商階段：

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

身份認證階段：

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

消息加密階段：

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

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

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

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

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演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密，對稱加密和簽名的功能。

metacharset="utf-8"

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

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

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

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

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

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

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

在這個曲線上，我隨機選取兩個點，這兩個點的乘法怎麼算呢？我們可以簡化下問題，乘法是都可以用加法表示的，比如22=2+2，35=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

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

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

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

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

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

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

由於2P=-Q所以這樣就計算出了kP。這就是點倍積演算法。所以在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上的例子說明如何生成共享秘鑰，也可以參考AliceAndBob的例子。

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=kaKB=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-.其模型如下：

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

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

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

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