如何手動構造以太坊交易並發送

在開發以太坊的 dapp（去中心化應用）或交易腳本時，開發者通常會借助某些庫或框架來簡化與以太坊區塊鏈的互動過程。這些工具提供了便捷的 API 接口，通過這些接口，開發者能夠輕鬆地發送交易、讀取鏈上數據、以及執行其他與區塊鏈互動的操作。雖然這些庫或框架能夠極大簡化交易的創建和發送過程，但其內部的交易構造和發送機制卻往往隱藏於開發者的視線之外。

為了解這些框架內部發送交易的原理，本文將深入探討如何在不依賴於任何框架的情況下手動發起一筆交易。

要在無框架的環境中發送一筆交易，通常需經歷以下幾個核心步驟：

構建交易對象：創建一個包含了交易相關信息（如交易的發送方、接收方、金額、Gas 價格等）的交易對象
對交易對象進行簽名：利用私鑰對構建好的交易對象進行簽名，以確保交易的安全性和完整性
發送交易：將簽名後的交易對象發送到以太坊網絡

構造交易#

交易的原始數據結構

interface Transaction {
  form: Address // 交易的發送者
  to: Address // 交易的接收者
  nonce: Hex // 發送者的nonce
  type: Hex // 交易類型, 0(legcy) 或 1(EIP-2930) 或 2(EIP-1559)
  value: Hex // 交易攜帶的主幣數量, 單位是 wei
  data: Hex // 交易攜帶的數據
  maxPriorityFeePerGas?: Hex // EIP-1559:每單位 gas 優先費用, type=2時提供
  maxFeePerGas?: Hex // EIP-1559:每單位 gas 最大費用, type=2時提供
  gas: Hex // 可使用的最大 gas 數量(gasLimit)
  gasPrice?: Hex // gas 價格, type!=2時提供
  accessList？: [] // EIP-2930新增屬性, 值為包含地址和存儲鍵的列表，主要為解決EIP-2929帶來的副作用問題
}

其中相關字段需要通過 JSON RPC 獲取

JSON RPC 本質為 HTTP post 請求，區別在於請求參數為固定的格式，如下所示

{
  jsonrpc: '2.0', // 指定 JSON-RPC 協議版本
  method: '', // 調用的方法名稱
  params: [], // 調用方法所需要參數
  id: 1 // 本次請求的編號
}

響應結果格式如下所示

{
  jsonrpc: '2.0', // 指定 JSON-RPC 協議版本
  id: 1, // 本次請求的編號, 和請求參數中的 id 一致
  result: '' // 請求結果
}

下面將詳細介紹交易對象中各個字段

from#

交易的發送者，必須是 EOA 地址

在以太坊中有 2 種賬戶：外部賬戶、合約賬戶

外部賬戶: Externally Owned Accounts 簡稱 EOA, 擁有私鑰，其 codeHash 為空
合約賬戶: Contact Account 簡稱 CA, 沒有私鑰，其 codeHash 非空

to#

交易的接收者，可以是 EOA, 也可以是 CA

nonce#

交易發送者的 nonce, 值為賬戶已發送交易數量的計數，主要有兩個方面的作用:

防止雙重消費（重放攻擊）: 在以太坊網絡中，每個交易都有一個與之關聯的 nonce 值。nonce 是一個只能被使用一次的數字，它能確保每筆交易是獨一無二的。通過這種方式，以太坊網絡能夠防止雙重消費攻擊，即用戶不能使用同一筆資金進行兩次或多次交易
交易順序：當用戶發送新的交易時，該賬戶的 nonce 值會自增。通過這種機制，以太坊網絡能夠確保交易按照正確的順序被處理，即先發送的交易先被處理，後發送的交易後被處理。確保賬戶狀態的正確性和交易的原子性

通過 JSON RPC 方法 eth_getTransactionCount 獲取 nonce 值

import axios from 'axios'

const rpc_url = 'https://rpc.ankr.com/eth_goerli'

const getNonce = async () => {
  const response = await axios.post(rpc_url, {
    jsonrpc: '2.0',
    method: 'eth_getTransactionCount',
    params: [account.address, 'pending'],
    id: 1
  })
  return response.data.result
}

eth_getTransactionCount 方法有以下兩個參數:

address: 賬戶地址
blockNumber: 區塊編號，可以是一個十六進制的區塊高度值，或是 latest、earliest、pending中的一個
- 特定的區塊號：查詢該區塊指定地址的交易計數
- latest：查詢最新區塊時指定地址的交易計數
- earliest：查詢創世區塊（第一個區塊）時指定地址的交易計數
- pending：查詢當前掛起區塊（尚未被礦工處理的區塊）時指定地址的交易計數

type#

交易類型，以太坊中存在三種交易類型，有以下取值:

0: legcy, EIP-2718 之前的交易，交易字段有

from, to, type, value, data, nonce, gas, gasPrice

1: EIP-2930, 新增字段 accessList

from, to, type, value, data, nonce, gas, gasPrice, accessList

2: EIP-1559, 移除了 gasPrice, 新增 maxPriorityFeePerGas 和 maxFeePerGas

from, to, type, value, data, nonce, gas, maxPriorityFeePerGas, maxFeePerGas, accessList

value#

交易攜帶的 ETH 數量，單位是 WEI($1\tt{ETH}=10^{18}\tt{WEI}$)

data#

交易攜帶的數據，如果是轉賬交易，該字段可為空。如果是調用合約的交易，data 則為合約函數的選擇器哈希值拼接上函數參數編碼

maxPriorityFeePerGas#

每單位 Gas 的優先價格，仅 type 為 2 時提供，這部分的費用將支付給礦工。

通過 JSON RPC 方法 eth_maxPriorityFeePerGas 獲取當前最新的 maxPriorityFeePerGas

const getMaxPriorityFeePerGas = async () => {
  const response = await axios.post(rpc_url, {
    jsonrpc: '2.0',
    method: 'eth_maxPriorityFeePerGas',
    params: [],
    id: 1
  })
  return response.data.result
}

該方法不是標準方法，通常由第三方節點服務商 (alchemy, infura 等) 提供，如果你使用的節點不存在該方法。則可以嘗試下面的備選方案

通過 JSON RPC 方法 eth_gasPrice 獲取當前最新的 gasPrice
通過 JSON RPC 方法 eth_getBlockByNumber 獲取當前最新的區塊信息 block, 區塊信息中存在 baseFeePerGas

將兩者相減可以獲得 maxPriorityFeePerGas

maxPriorityFeePerGas = gasPrice - block.baseFeePerGas

maxFeePerGas#

每單位 Gas 的最大價格，仅 type 為 2 時提供。該字段的目的是為了防止因 gasPrice 波動而導致交易被剔除出打包序列。通常計算公式為 baseFeePerGas 乘以一個倍數 multiple 再加上 maxPriorityFeePerGas

maxFeePerGas = block.baseFeePerGas * multiple + maxPriorityFeePerGas

當 multiple 為 2 時，可以保證連續 6 個區塊滿 Gas 的情況下仍在內存池中等待打包。

在不同的框架中 multiple 被設置成不同的值，在 viem 中值為 1.2，在 ethers.js 中值為 2

gas#

該字段意為該交易最多可花費的 gas 數量，即 gasLimit。轉賬交易時，該值固定為 21000

通過 JSON RPC 方法 eth_estimateGas 可獲取交易預估值作為該字段值

const estimateGas = async (originTransaction) => {
  const response = await axios.post(rpc_url, {
    jsonrpc: '2.0',
    method: 'eth_estimateGas',
    params: [originTransaction],
    id: 1
  })
  return response.data.result
}

const originTransaction = {
  form: '0x...',
  to: '0x...',
  nonce: '0x...',
  type: '0x2',
  value: '0x2386f26fc10000',
  maxPriorityFeePerGas: '0x3f7',
  maxFeePerGas: '0x42a'
}
originTransaction.gas = await estimateGas(originTransaction)

簽名#

為了確保交易是由私鑰持有者發出的，還需要使用私鑰對交易進行簽名。簽名前需要先經過序列化、編碼過程

交易編碼採用 RLP 編碼算法，根據交易類型的不同，遵循下列公式

legacy, type = 0

RLP.encode([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

EIP-2930, type = 1

0x01 || RLP.encode([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])

EIP-1559, type = 2

0x02 || RLP.encode([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])

序列化#

序列化的過程本質是將交易對象中的字段按照一定的順序排列

對於不同交易類型，按照上述公式存在不同的順序。(未簽名時，最後三個私鑰簽名字段可為空)

type=0: 順序為 [nonce, gasPrice, gas, to, value, data]
type=1: 順序為 [chainId, nonce, gasPrice, gas, to, value, data, accessList]
type=2: 順序為 [chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gas, to, value, data, accessList]

對於交易

{
  form: "0x2557D0d204a51CF37A0474b814Afa6f942f522cc",
  to: "0x87114ed56659216E7a1493F2Bdb870b2f2102156",
  nonce: "0x9",
  type: "0x2",
  value: "0x2386f26fc10000",
  maxPriorityFeePerGas: "0x3e6",
  maxFeePerGas: "0x482",
  gas: "0x5208"
}

在 goerli 網絡上序列化後的結果為

const serializedTransaction = [
  '0x5', // chainId
  '0x9', // nonce
  '0x3e6', // maxPriorityFeePerGas
  '0x482', // maxFeePerGas
  '0x5208', // gas
  '0x87114ed56659216E7a1493F2Bdb870b2f2102156', // to
  '0x2386f26fc10000', // value
  '0x', // data
  [] // accessList
]

編碼#

將序列化的結果進行 RLP 編碼，得到 Uint8 類型的字節數組，同時將交易類型加入到數組的第一個元素

import RLP from 'rlp'
const toRlp = (serializedTransaction) => {
  // 交易類型加入到數組第一個元素
  return new Uint8Array([2, ...RLP.encode(serializedTransaction)])
}
const rlp = toRlp(serializedTransaction)

按照上述公式，如果 type = 0, 則無需將交易類型加入數組

最後對 RLP 編碼結果應用 keccak_256 哈希函數，生成 32 字節的哈希值

import { keccak_256 } from '@noble/hashes/sha3'
const hash = toHex(keccak_256(rlp))

secp256k1 加密#

將哈希結果使用私鑰簽名

import { secp256k1 } from '@noble/curves/secp256k1'

const { r, s, recovery } = secp256k1.sign(hash.slice(2), privateKey.slice(2))
return {
  r: toHex(r),
  s: toHex(s),
  v: recovery ? 28n : 27n
}

得到簽名結果 r、s、v 後，按照公式重新將其加入到序列化數組中，並重新進行 RLP 編碼

serializedTransaction.push(
  signature.v === 27n ? '0x' : toHex(1), // yParity
  r,
  s
)
const lastRlp = toRlp(serializedTransaction)

得到最終結果 lastRlp 是一個 Uint8 類型的字節數組，每個元素佔用 1 個字節，範圍在 0 - 255。值表示為在長度為 256 按順序構成的 16 進制數組中的索引

// 將數字從 0 到 255 轉成 16 進制, 並存儲數組中
// [ "00", "01", "02", "03", "04", "05", "06", "07", "08", "09", "0a", "0b", "0c", "0d", "0e", ...]
const hexes = Array.from({ length: 256 }, (_v, i) =>
  i.toString(16).padStart(2, '0')
)

// 遍歷 lastRlp 數組, 將數組元素存儲的索引值，在 hexes 找到對應的值進行拼接
const signedTransaction =
  '0x' +
  lastRlp.reduce((prev, current) => {
    return prev + hexes[current]
  }, '')

最後得到簽名後的交易 signedTransaction，為一個 16 進制的字符串

發送交易#

通過 JSON RPC 方法 eth_sendRawTransaction, 將 signedTransaction 發送到節點

const sendRawTransaction = async (signedTransaction) => {
  const response = await axios.post(rpc_url, {
    jsonrpc: '2.0',
    method: 'eth_sendRawTransaction',
    params: [signedTransaction],
    id: 1
  })
  return response.data.result
}

eth_sendRawTransaction 方法將返回交易哈希

獲取交易回執#

發送交易後，為了確保交易完成。可輪詢調用 JSON RPC 方法 eth_getTransactionReceipt 獲取交易回執

const getTransactionReceipt = async (hash: string) => {
  const response = await axios.post(rpc_url, {
    jsonrpc: '2.0',
    method: 'eth_getTransactionReceipt',
    params: [hash],
    id: 1
  })
  return response.data.result
}

const interval = setInterval(async () => {
  const receipt = await getTransactionReceipt(hash)
  console.log(receipt)

  if (receipt && receipt.blockNumber) clearInterval(interval)
}, 4000)

eth_getTransactionReceipt 接收參數為交易哈希

完整代碼見 Github