以太坊消息簽名

❶ 以太坊區塊鏈之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

❷ 以太坊的ABI編碼

ABI全稱Application Binary Interface, 是調用智能合約函數以及合約之間函數調用的消息編碼格式定義,也可以理解為智能合約函數調用的介面說明. 類似Webservice里的SOAP協議一樣；也就是定義操作函數簽名，參數編碼，返回結果編碼等。

使用ABI協議時必須要求在編譯時知道類型,即強類型相關.

當一個智能合約編譯出來後, 他的abi介面定義就確定了. 比如下面的智能合約:

生成的位元組碼:

生成的abi定義:

可以看出, 生成abi包含了2個定義: 函數 lotus , 事件 Log_lotus , 各個欄位含義見上. 根據該abi定義,就可以生成調用該智能合約函數的abi格式的數據了.

格式簡單的可以表示為: 函數選擇器+參數編碼

一個函數調用的前四個位元組數據指定了要調用的函數簽名。計算方式是使用函數簽名的 keccak256 的哈希，取4個位元組。

函數名如果有多個參數使用,隔開，要去掉表達式中的所有空格。在geth客戶端,通過命令可以得到hash:

由於前面的函數簽名使用了四個位元組，參數的數據將從第五個位元組開始。

根據參數類型,編碼規則有所區別:

除了bytes,和string, 其他類型的數據不足32位元組長度的需要加0補足32位元組. 動態長度的編碼在例子中介紹.

函數: function baz(uint32 x, bool y) :

調用: baz(69, true)

生成的數據如下:

返回結果是一個bool值，在這里，返回的是false:

函數: f(uint,uint32[],bytes10,bytes)

調用: (0x123, [0x456, 0x789], "1234567890", "Hello, world!")

函數選擇器: bytes4(sha3("f(uint256,uint32[],bytes10,bytes)"))

對於 固定大小的類型 值 uint256 和 bytes10 ，直接編碼值。

對於 動態內容類型 值 uint32[] 和 bytes ，我們先 編碼偏移值 ，偏移值是整個值編碼的開始到真正存這個數據的偏移值（這里不計算頭四個用於表示函數簽名的位元組）。

所以參數編碼數據依次為：

尾部部分的第一個動態參數， [0x456, 0x789] 編碼拆解如下：

最後我們來看看第二個動態參數的的編碼， Hello, world! 。

所以最終結果是:

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

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

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

❹ 27歲以太幣創建者獲利11億美元，以太坊現在還能挖嗎

近日，一則“27歲以太幣創建者獲利11億美元”的消息，引發了廣大網友們的熱議，在網上鬧的沸沸揚揚。我們知道隨著社會的發展，現在的科技水平也是越來越發達，近幾年呢，數字貨幣更是非常的火爆，在十幾年前，一枚比特幣也就不到一分錢，而現在卻需要30多萬的人民幣才能夠買到一枚。而因為比特幣的興起呢，人們認識到數字貨幣的魅力，於是紛紛都在往數字貨幣方面進攻，先後開發出了很多不同的數字貨幣，以太幣，狗狗幣等等非常多的種類，最近呢，是傳出了消息說27歲的以太幣的創建者呢，是獲利了11億美元，大賺了一筆。那麼以太幣現在還能夠挖嗎？我們來了解一下。

一.以太幣還能夠挖嗎

首先這個回答是肯定的，現在仍然能夠挖以太幣。

以上就是我對於這個問題所發表的看法，純屬個人觀點，僅供參考，大家有什麼不同的看法都可以在評論區留言，大家一起討論一下。

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

交易

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

• 由於公共區塊鏈分布式和無需許可的性質，任何人都可以簽署交易並將其廣播到網路。

• 根據區塊鏈的不同，交易者將被收取一定的交易費用，交易費用取決於用戶的需求而不是交易中資產的價值。

• 區塊鏈交易無需任何中央機構的驗證。僅需使用與其區塊鏈相對應的數字簽名演算法（DSA）使用私鑰對其進行簽名。

• 一旦一筆交易被簽名，廣播到網路中並被挖掘到網路中成功的區塊中，就無法恢復交易。

以太坊交易結構

• 以太坊交易的數據結構：交易0.1個ETH

  {
  'nonce':'0x00', // 十進制：0
  'gasLimit': '0x5208', //十進制： 21000
  'gasPrice': '0x3b9aca00', //十進制1，000，000，000
  'to': '' ，//發送地址
  'value': '0x16345785d8a0000',//100000000000000000 ，10^17
  'data': '0x', // 空數據的十進製表示
  'chainId': 1 // 區塊鏈網路ID
  }

  這些數據與交易內容無關，與交易的執行方式有關，這是由於在以太坊中發送交易中，您必須定義一些其他參數來告訴礦工如何處理您的交易。交易數據結構有2個屬性設計"gas": "gasPrice","gasLimit"。

• "gasPrice": 單位為Gwei, 為 1/1000個eth,表示交易費用

• "gasLimit": 交易允許使用的最大gas費用。

• 這2個值通常由錢包提供商自動填寫。

  除此之外還需要指定在哪個以太坊網路上執行交易（chainId）: 1表示以太坊主網。

  在開發時，通常會在本地以及測試網路上進行測試，通過測試網路發放的測試ETH進行交易以避免經濟損失。在測試完成後再進入主網交易。

  另外，如果需要提交一些其它數據，可以用"data"和"nonce"作為事務的一部分附加。

  A nonce（僅使用1次的數字）是以太坊網路用於跟蹤交易的數值，有助於避免網路中的雙重支出以及重放攻擊。

以太坊交易簽名

以太坊交易會涉及ECDSA演算法，以Javascript代碼為例，使用流行的ethers.js來調用ECDSA演算法進行交易簽名。

• const ethers = require('ethers')


• const signer = new ethers.Wallet('錢包地址')



• signer.signTransaction({


• 'nonce':'0x00', // 十進制：0


• 'gasLimit': '0x5208', //十進制： 21000


• 'gasPrice': '0x3b9aca00', //十進制1，000，000，000


• 'to': '' ，//發送地址


• 'value': '0x16345785d8a0000',//100000000000000000 ，10^17


• 'data': '0x', // 空數據的十進製表示


• 'chainId': 1 // 區塊鏈網路ID


• })


• .then(console.log)

可以使用在線使用程序Composer將已簽名的交易傳遞到以太坊網路。這種做法被稱為」離線簽名「。離線簽名對於諸如狀態通道之類的應用程序特別有用，這些通道是跟蹤兩個帳戶之間余額的智能合約，並且在提交已簽名的交易後就可以轉移資金。離線簽名也是去中心化交易所（DEXes）中的一種常見做法。

也可以使用在線錢包通過以太坊賬戶創建簽名驗證和廣播。

使用Portis，您可以簽署交易以與加油站網路（GSN）進行交互。

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

❻ 以太坊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 **