導航:首頁 > 以太坊區 > 以太坊交易簽名流程

以太坊交易簽名流程

 發布時間：2023-01-22 23:06:15

1. 以太國際空間誰知道怎麼玩。EIS幣怎麼交易

現在我們大家都很關注關於以太坊方面的問題，那麼關於以太幣怎麼交易?我想我們大家應該會很想了解一些內容，那麼下面就讓我們小編在這里就來為大家好好的介紹一下很多內容關於以太幣怎麼交易?以太坊的交易最直觀解釋：從外部賬戶發送到區塊鏈上的另一個賬戶的消息和簽名的數據包。

包含如下內容：
發送者的簽名
接收的地址
轉移的數字貨幣數量等內容
以太坊上的交易都是需要支付費用，和比特幣以比特幣來支付一定的交易費用不同，以太坊上固定了這個環節，那麼這個間接理解是以太坊的一種安全防範錯誤，防止了大量的無意義的交易，保證一定的安全性，特別是智能合約的創建、執行、調用都需要消耗費用，那麼也保證了整個系統的穩定性，防止了一些鏈上無意義的惡意行為。
交易手續費
以太坊的核心是EVM，以太坊虛擬機，那麼在EVM中執行的位元組碼都是要支付費用。也就是經常看到的Gas、Gas limit、Gas Price這幾個概念。
Gas：字面理解就是汽油，以太坊和日常的汽車一樣需要Gas才能運行。Gas是一筆交易過程中計算消耗的基本單位。有一個列表可以直觀看到在以太坊中操作的Gas消耗量：
操作Gas消耗具體內容
step1執行周期的默認費用。
stop0終止操作是免費的。
suicide0智能合約賬戶的內部數據存儲空間，當合約賬戶調用suicide()方法時，該值將被置為null。
sha320加解密
sload20在固定的存儲器中去獲取
sstore100輸入到固定的存儲器中
balance20賬戶余額
create100創建合約
call20初始化一個只讀調用
memory1擴充內存額外支付的費用
txdata5交易過程中數據或者編碼的每一個位元組的消耗
transaction500交易費用
contract creation53000homestead中目前從21000調整到53000
所以有些公司或者個人覺得區塊鏈技術去中介化，不需要中心伺服器，這種開發模式是比較便宜的，但是事實上區塊鏈的開發不比之前的那些傳統軟體開發來的便宜。
Gas Price：字面理解汽油價格，這個就像你去加油站，95#汽油今天是什麼價格。一個Gas Price就是單價，那麼你的交易費用=Gas*Gas Price，然後以以太幣來ether來支出。當然你覺得我不想支付費用，你可以設置Gas Price為0，但是選擇權在礦工手中，礦工有權選擇收納交易和收取費用，那麼最簡單的想想很難讓一個礦工去接收一個價格很低的交易吧。另外提一句，以太坊默認的Gas Price是1wei。
Gas Limit：字面理解就是Gas的限制，限制是必要的，沒有限制就沒有約束。這個Gas Limit是有兩個意思的。首先針對單個交易，那麼這個表示交易的發起者他願意支付最多是多少Gas，這個交易發起者在發起交易的時候需要設置好。還有一個是針對區塊的Gas Limit，一個單獨的區塊也有Gas的限制。
假設幾個場景來說明Gas的使用：
用戶設置Gas Limit，那麼在交易過程中，如果你的實際消耗的Gas used
用戶設置Gas Limit，那麼交易過程中，如果你的實際消耗的Gas used > Gas Limit，那麼礦工肯定發現你的Gas不足，這個交易就無法執行完成，這個之後會回滾到執行之前的狀態，這個時候礦工會收取Gas Price*Gas Limit。
區塊的Gas Limit，區塊中有一個Gas上限，收納的交易會出現不同的用戶指定的Gas Limit。那麼礦工就會根據區塊限制的Gas Limit來選擇，「合理」選擇打包交易。
具體交易
以太坊上交易可以是簡單的以太幣的轉移，同時也可以是智能合約的代碼消息。列個表格看下交易的具體內容：
代碼內容
from交易發起者的地址、不能為空，源頭都沒有不合理。
to交易接收者的地址(這個可以為空，空的時候就表示是一個合約的創建)
value轉移的以太幣數量
data數據欄位。這個欄位存在的時候表示的是，交易是一個創建或者是一個調用智能合約的交易
Gas Limit字面理解就是Gas的限制，限制是必要的，沒有限制就沒有約束。這個Gas Limit是有兩個意思的。首先針對單個交易，那麼這個表示交易的發起者他願意支付最多是多少Gas，這個交易發起者在發起交易的時候需要設置好。還有一個是針對區塊的Gas Limit，一個單獨的區塊也有Gas的限制。
Gas Price一個Gas Price就是單價，那麼你的交易費用=Gas*Gas Price，然後以以太幣來ether來支出。以太坊默認的Gas Price是1wei。
nonce用於區別用戶發出交易的標識。
hash交易ID，是由上述的信息生成的一個hash值
r、s、v交易簽名的三部分，交易發起者的私鑰對hash簽名生成。
交易分三種類型
轉賬：簡單明了的以太坊上的以太幣的轉移，就和比特幣類似，A向B轉移一定數量的以太幣。這種交易包含：交易發起者、接收者、value的數量，其餘類似Gas Limit、hash、nonce都會默認生成。所以你會看到一段代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", to：「交易接收者地址」, value: 數量});
智能合約創建：創建智能合約就是把智能合約部署到區塊鏈上，那麼這個時候to是一個空的欄位。data欄位則是初始化合約的代碼。所以看到代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", data: "contract binary code"});
智能合約執行：合約創建部署在區塊鏈上，那麼執行就是會加上to欄位到要智能合約執行的地址，然後data欄位來指定調用的方法和參數的傳遞，所以看到代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", to：「合約執行者地址」, data：「調用的方法和參數的傳遞」});
以上大致就是交易的類型。
交易的確認
和比特幣一樣，以太坊的交易需要後續區塊確認後，節點同步後、才能確認。簡單理解就是多挖出一些區塊來，通過驗證後這一筆交易才算確認，以太坊時常會出現擁堵的情況，所以有時候需要等待確認。
轉賬、合約交易流轉
首先交易發起者A發起一筆轉賬交易，那麼發送的格式如下：
代碼具體內容
from交易發起者的地址
to交易接收者的地址
value轉移的以太幣數量
GasGas的量
Gas PriceGas的單價
data發送給接收者的消息
nonce交易編號
節點驗證：以太坊網路中會有節點收到A發送出來的消息，那麼會去檢查這個消息格式時候有效，然後計算Gas Limit。這個時候回去驗證A的以太坊余額，如果余額不足，那麼就返回錯誤，不予處理。一旦A發送的消息通過了節點的驗證，那麼節點就會把這個交易放到交易存儲池中。並廣播到區塊鏈網路。
礦工驗證：那麼寫入區塊鏈必須要礦工打包，礦工在接收到A發出的交易，會和其他交易一塊打包，普通轉賬交易打包即可，那麼合約調用的交易則需要在礦工本地的EVM上去執行調用的合約代碼，代碼執行過程中檢查Gas的消耗。一旦Gas消耗完了，那麼就回滾，如果Gas足夠那麼返回多餘的Gas。並廣播到區塊鏈網路。
其餘節點：重復節點驗證步驟，然後合約也會在本地EVM上執行驗證。通過驗證後同步區塊鏈。
首先還是發起者A發起一個創建智能合約的交易請求。格式如下：
代碼具體內容
from交易發起者的地址
to0
value轉移的以太幣數量
GasGas的量
Gas PriceGas的單價
data合約代碼
nonce交易編號
節點驗證：
以太坊網路中會有節點收到A發送出來的消息，檢查交易是否有效，格式是否正確，驗證交易簽名。計算Gas，確定下發起者的地址，然後查詢A賬戶以太幣的余額。如果余額不足，那麼就返回錯誤，不予處理。一旦A發送的消息通過了節點的驗證，那麼節點就會把這個交易放到交易存儲池中。並廣播到區塊鏈網路。
礦工驗證：
礦工將交易打包，那麼會根據交易費用和合約代碼，來創建合約賬戶，在賬戶的空間中部署合約。這里說下合約地址(智能合約賬戶的地址是有發起者的地址和交易的隨機數作為輸入，然後通過加密演算法生成)。交易確認後會把智能合約的地址返回給A。且廣播到區塊鏈網路。
其餘節點：
重復節點驗證步驟，驗證區塊，在節點的內存池中更新A的智能合約交易，同步區塊鏈，且智能合約部署在自己本地的區塊鏈中。

2. 以太坊web3.sendRawTransaction離線簽名交易

工作中需要復現短地址攻擊和the重入攻擊，重入攻擊可以直接通過eth.sendTransaction和remix來發送交易，但是短地址攻擊由於錢包和remix這些都對input做了長度檢測，無法通過這些方式來復現，只能通過發離線簽名交易來實現。

1.環境依賴：nodejs , keythereum , ethereumjs-common , ethereumjs-tx 。

2.進入Node控制台，獲取相應賬戶私鑰。

3.簽名交易，進入Node,這里注意nonce問題，需要Nonce是實際可執行的nonce，Nonce不對會發送交易失敗,關於如何獲取input data網路比較多就不詳述了。

4.遇到的坑，網路出來的步驟是有問題的或者過時了，當時是參考的這篇文章， https://www.freebuf.com/articles/blockchain-articles/199903.html
，在控制台通過eth.sendRawTransaction發送簽名好的交易，我遇到了這個錯誤 ** sendRawTransaction invalid sender **

3. 以太坊交易(tx) 分析

更多請參考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相對應的，比如 60 對應就是 operation PUSH1,合約編譯後的位元組碼即為一組的 operation 。

合約部署其實就是實例化一個 contract 對象，並將 data 的值設給 Code屬性 。

創建合約的tx中，input欄位對應的是合約的位元組碼，即指令數組。

其中 input 欄位對應所要調用的函數簽名的前四個位元組（771602f7）以及對應的參數（1,2）

其中 input 欄位為所要調用的合約函數簽名的前四個位元組（72a099b7）

關於函數調用，Call會把對應的Code讀出來，依次解析，Code中會把所有的public簽名的函數標志（4位元組）push到棧里。然後依據 input 中需要調用函數的簽名標志（前4位元組）來匹配 Code， 匹配之後跳轉到對應的 opcode 。

4. 【ETH錢包開發03】web3j轉賬ETH

在之前的文章中，講解了創建、導出、導入錢包。
【ETH錢包開發01】創建、導出錢包
【ETH錢包開發02】導入錢包

本文主要講解以太坊轉賬相關的一些知識。交易分為ETH轉賬和ERC-20 Token轉賬，本篇先講一下ETH轉賬。

1、解鎖賬戶發起交易。錢包keyStore文件保存在geth節點上，用戶發起交易需要解鎖賬戶，適用於中心化的交易所。

2、錢包文件離線簽名發起交易。錢包keyStore文件保存在本地，用戶使用密碼+keystore的方式做離線交易簽名來發起交易，適用於dapp，比如錢包。

本文主要講一下第二種方式，也就是錢包離線簽名轉賬的方式。

交易流程
1、通過keystore載入轉賬所需的憑證Credentials
2、創建一筆交易RawTransaction
3、使用Credentials對象對交易簽名
4、發起交易

注意以下幾點：

1、Credentials
這里，我是通過獲取私鑰的方式來載入 Credentials

還有另外一種方式，通過密碼+錢包文件keystore方式來載入 Credentials

2、nonce

nonce是指發起交易的賬戶下的交易筆數，每一個賬戶nonce都是從0開始，當nonce為0的交易處理完之後，才會處理nonce為1的交易，並依次加1的交易才會被處理。

可以通過 eth_gettransactioncount 獲取nonce

3、gasPrice和gasLimit
交易手續費由gasPrice 和gasLimit來決定，實際花費的交易手續費是 gasUsed * gasPrice 。所有這兩個值你可以自定義，也可以使用系統參數獲取當前兩個值

關於 gas ，你可以參考我之前的一篇文章。
以太坊（ETH）GAS詳解

gasPrice和gasLimit影響的是轉賬的速度，如果gas過低，礦工會最後才打包你的交易。在app中，通常給定一個默認值，並且允許用戶自己選擇手續費。

如果不需要自定義的話，還有一種方式來獲取。獲取以太坊網路最新一筆交易的 gasPrice ,轉賬的話， gasLimit 一般設置為21000就可以了。

Web3j還提供另外一種簡單的方式來轉賬以太幣,這種方式的好處是不需要管理nonce，不需要設置gasPrice和gasLimit，會自動獲取最新一筆交易的gasPrice，gasLimit 為21000（轉賬一般設置成這個值就夠用了）。

這個問題，我想是很多朋友所關心的吧。但是到目前為止，我還沒有看到有講解這方面的博客。

之前問過一些朋友，他們說可以通過區塊號、區塊哈希來判斷，也可以通過Receipt日誌來判斷。但是經過我的一番嘗試，只有 BlockHash 是可行的，在web3j中根據 blocknumber 和 transactionReceipt 都會報空指針異常。

原因大致是這樣的：在發起一筆交易之後，會返回 txHash ，然後我們可以根據這個 txHash 去查詢這筆交易相關的信息。但是剛發起交易的時候，由於手續費問題或者乙太網絡擁堵問題，會導致你的這筆交易還沒有被礦工打包進區塊，因此一開始是查不到的，通常需要幾十秒甚至更長的時間才能獲取到結果。我目前的解決方案是輪詢的去刷 BlockHash ，一開始的時候 BlockHash 的值為0x00000000000，等到打包成功的時候就不再是0了。

這里我使用的是rxjava的方式去輪詢刷的，5s刷新一次。

正常情況下，幾十秒內就可以獲取到區塊信息了。

區塊確認數=當前區塊高度-交易被打包時的區塊高度。

5. 以太坊區塊鏈之Bug --2020/05/19

為了防止交易重播，ETH（ETC）節點要求每筆交易必須有一個nonce數值。每一個賬戶從同一個節點發起交易時，這個nonce值從0開始計數，發送一筆nonce對應加1。當前面的nonce處理完成之後才會處理後面的nonce。注意這里的前提條件是相同的地址在相同的節點發送交易。

以下是nonce使用的幾條規則：

● 當nonce太小（小於之前已經有交易使用的nonce值），交易會被直接拒絕。

● 當nonce太大，交易會一直處於隊列之中，這也就是導致我們上面描述的問題的原因；

● 當發送一個比較大的nonce值，然後補齊開始nonce到那個值之間的nonce，那麼交易依舊可以被執行。

● 當交易處於queue中時停止geth客戶端，那麼交易queue中的交易會被清除掉。

         第一個欄位 AccountNonce ，直譯就是賬戶隨機數。它是以太坊中很小但也很重要的一個細節。以太坊為每個賬戶和交易都創建了一個Nonce，當從賬戶發起交易的時候，當前賬戶的Nonce值就被作為交易的Nonce。這里，如果是普通賬戶那麼Nonce就是它發出的交易數，如果是合約賬戶就是從它的創建合約數。

為什麼要使用這個Nonce呢？其主要目的就是為了防止重復攻擊（Replay Attack）。因為交易都是需要簽名的，假定沒有Nonce，那麼只要交易數據和發起人是確定的，簽名就一定是相同的，這樣攻擊者就能在收到一個交易數據後，重新生成一個完全相同的交易並再次提交，比如A給B發了個交易，因為交易是有簽名的，B雖然不能改動這個交易數據，但只要反復提交一模一樣的交易數據，就能把A賬戶的所有資金都轉到B手裡。

當使用賬戶Nonce之後，每次發起一個交易，A賬戶的Nonce值就會增加，當B重新提交時，因為Nonce對不上了，交易就會被拒絕。這樣就可以防止重復攻擊。當然，事情還沒有完，因為還能跨鏈實施攻擊，直到EIP-155引入了chainID，才實現了不同鏈之間的交易數據不兼容。事實上，Nonce並不能真正防止重復攻擊，比如A向B買東西，發起交易T1給B，緊接著又提交另一個交易T2，T2的Gas價格更高、優先順序更高將被優先處理，如果恰好T2處理完成後剩餘資金已經不足以支付T1，那麼T1就會被拒絕。這時如果B已經把東西給了A，那A也就攻擊成功了。所以說，就算交易被處理了也還要再等待一定時間，確保生成足夠深度的區塊，才能保證交易的不可逆。

Price 指的是單位Gas的價格，所謂Gas就是交易的消耗，Price就是單位Gas要消耗多少以太幣（Ether），Gas * Price就是處理交易需要消耗多少以太幣，它就相當於比特幣中的交易手續費。

GasLimit 限定了本次交易允許消耗資源的最高上限，換句話說，以太坊中的交易不可能無限制地消耗資源，這也是以太坊的安全策略之一，防止攻擊者惡意佔用資源。

Recipient 是交易接收者，它是common.Address指針類型，代表一個地址。這個值也可以是空的，這時在交易執行時，會通過智能合約創建一個地址來完成交易。

Amount 是交易額。這個簡單，不用解釋。

Payload 比較重要，它是一個位元組數組，可以用來作為創建合約的指令數組，這時每個位元組都是一個單獨的指令；也可以作為數據數組，由合約指令來進行操作。合約由以太坊虛擬機（Ethereum Virtual Machine，EVM）創建並執行。

V、R、S 是交易的簽名數據。以太坊當中，交易經過數字簽名之後，生成的signature是一個長度65的位元組數組，它被截成三段，前32位元組被放進R，再32位元組放進S，最後1個位元組放進V。那麼為什麼要被截成3段呢？以太坊用的是ECDSA演算法，R和S就是ECSDA簽名輸出，V則是Recovery ID。

R,S,V是交易簽名後的值，它們可以被用來生成簽名者的公鑰；R，S是ECDSA橢圓加密演算法的輸出值，V是用於恢復結果的ID

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

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

在學習的過程中主要是採用單個模塊了學習了解的，包括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的整個的加密，認證，簽名模型如下：

7. 使用Nodejs部署智能合約

實現智能合約的方式很多種，可以用truffle框架來實現，編譯，部署。
這里介紹一種簡單的使用nodejs來實現，編譯，部署的方法。
創建一個nodejs項目，實現一個簡單的智能合約。

這個合約實現了一個造幣和轉幣的邏輯。
我們的合約是運行在evm上面的位元組碼，solidity是靜態語言，需要通過編譯器生成evm的位元組碼。

調用 node compile.js ,對BaseToken進行編譯，生成位元組碼。web3中提供了一個部署合約的介面，使用如下，

利用編譯生成的abi和bytecode，創建一個合約對象，然後進行發布，等待著非同步執行的方法輸出合約地址 contractAddress ，這樣就完成了部署。不過這種方式有一個問題，就是在發布合約時，你的私鑰處於聯網狀態，
處於安全策略，我們需要盡量避免私鑰在聯網狀態。

以太坊上部署合約是向空地址發送一個附有位元組碼的簽名交易，其中發送者就是這個合約的擁有者。因此我們只需要將合約構建成一筆交易，我們在無網狀態下對這筆交易進行簽名，然後將簽名發送到以太坊網路中。這樣能夠降低我們私鑰被泄漏的風險。
對合約的簽名方法如下：

以上對一個合約簽名，這里需要注意的問題是，to的地址需要是，空地址。
完成簽名之後，我們把這筆交易發送出去就好，最簡單的方法就是使用 etherscan的發送Tx的方式 ，一旦發送完成，部署完成，就可以看到合約地址。

8. 如何創建和簽署以太坊交易

交易

區塊鏈交易的行為遵循不同的規則集


鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。

9. 以太坊錢包Mist多重簽名

個人如果錢包中有幾個以太幣，保管好私鑰，做幾個備份也沒有什麼好擔心的，但是要是像我這樣手握成千上萬個幣，能不擔心嗎，哈哈哈。。。

一般大量持幣的機構，都會使用多重簽名機制來保證幣的安全，所謂多重簽名就是多於一個人同意交易才生效，為了弄清楚實際過程，來實操一下。

主賬戶需要多於1個ETH才能新建合約，至少需要3個賬戶才能完成多重簽名錢包

OK，輸入完密碼後看到錢包正在創建，這里我們設置了發送任意的幣都需要至少兩個錢包賬戶同意

耐心等待一會即可看到多重簽名錢包創建好了，創建好後也有一個地址，可以像正常轉幣一樣將ETH從其他地址存到多重簽名地址，這里我們存入100個，可以看到賬戶內現有100個ETH，每次轉出需要至少2人同意

我們這里創建了多重簽名賬戶的3個管理地址，那麼其他的地址需要手動添加改地址到錢包，即可查看或操作此賬戶了。

選擇從多重簽名的錢包轉出，會有提示，每日超過限額，需要其他一個賬戶確認

先按正常的流程走吧，輸完發起賬號的密碼，交易歷史中會看到區塊確認中，當有確認的時候，發現所有多重簽名賬號的Mist中都多了一個提醒

PS：由於多重簽名地址底層使用了以太坊的智能合約，所以每次發起（包括其他人批准）都需要消耗gas，也就是說需要保證管理賬號中有足夠的ETH才行。

10. 以太坊轉賬流程

發起:用戶在本地的以太坊錢包軟體中選擇要發送的交易地址(From)、輸入目標地址(To)、金額(Value)、是否部署或調用合(Data)、手續費單價(Gasprice)等,確認發送至以太坊節點節點和錢包可以是同一台
廣播:節點收到(或自己發起)交易後,會對交易進行驗證。驗證:交易的簽名、發起賬號的余額是否能支付轉賬余額與手續費、Nonce是否為賬號已發出的交易數。驗證為合法後,將交易加入節點的交易池中交易池中存儲著待打包的交
安裝以太坊瀏覽器錢包插件,創建錢包,獲取虛擬以太幣,進行轉賬交易。 實驗內容 學習 初識以太坊,發送交易 1.學習《初始以太坊,發送交易》,虛擬以太幣交易。

閱讀全文

與以太坊交易簽名流程相關的資料

熱點內容
免費看wap電影 瀏覽：605
和色戒差不多的電影推薦 瀏覽：777
比特幣帝國 瀏覽：599
林正英血魔叫什麼名字 瀏覽：49
愛奇藝喪屍電影 瀏覽：669
網路虛擬貨幣派 瀏覽：889
冒險與挖礦先手 瀏覽：697
可在線搜索觀看的嗎網址 瀏覽：49
迷戀世界挖礦大作戰 瀏覽：404
冰雪奇緣2電影免費 瀏覽：865
吻戲床戲較多的電影 瀏覽：176
人蛇大戰懷孕 瀏覽：767
黑人的英語課作弊bd 瀏覽：260
以太坊美金行情 瀏覽：55
七拾年代的電影 瀏覽：288
小電影從哪看 瀏覽：465
李麗珍徐錦江拍過什麼電影 瀏覽：88
韓國車震片 瀏覽：229
中京電子數字貨幣 瀏覽：479
s9礦機重做系統 瀏覽：949