moon

moon

Build for builders on blockchain
github
twitter
HomeArchivesNFT

How to manually construct and send Ethereum transactions

#以太坊456
AI Translation
This post is translated from Chinese into English through AI.View Original
AI-generated summary
When developing dapps or transaction scripts on Ethereum, developers often use libraries or frameworks to simplify the interaction with the Ethereum blockchain. These tools provide convenient API interfaces that allow developers to easily send transactions, read on-chain data, and perform other interactions with the blockchain. However, the internal transaction construction and sending mechanisms of these libraries or frameworks are often hidden from developers. To understand the internal mechanisms of transaction sending in these frameworks, this article explores how to manually initiate a transaction without relying on any frameworks. The core steps to send a transaction in a framework-less environment typically involve: 1. Building the transaction object: Creating a transaction object that includes transaction-related information such as sender, recipient, amount, gas price, etc. 2. Signing the transaction object: Using a private key to sign the constructed transaction object to ensure transaction security and integrity. 3. Sending the transaction: Sending the signed transaction object to the Ethereum network. The article then goes on to explain the different fields in the transaction object, such as "from" (sender address), "to" (recipient address), "nonce" (sender's nonce), "type" (transaction type), "value" (amount of ETH), "data" (transaction data), and others. It also provides examples of how to retrieve the nonce value and gas estimation using JSON RPC methods, as well as how to calculate the maxPriorityFeePerGas and maxFeePerGas values for EIP-1559 transactions. Finally, it explains the process of signing the transaction using a private key and encoding the transaction using RLP encoding algorithm. Overall, the article provides a concise summary of the steps and considerations involved in manually sending a transaction without relying on any frameworks.

When developing Ethereum dapps (decentralized applications) or transaction scripts, developers often rely on certain libraries or frameworks to simplify the interaction process with the Ethereum blockchain. These tools provide convenient API interfaces, allowing developers to easily send transactions, read on-chain data, and perform other blockchain interaction operations. While these libraries or frameworks can greatly simplify the process of creating and sending transactions, the internal transaction construction and sending mechanisms are often hidden from the developer's view.

To understand the principles of sending transactions within these frameworks, this article will delve into how to manually initiate a transaction without relying on any framework.

To send a transaction in a framework-less environment, the following core steps are typically involved:

  • Constructing a transaction object: Create a transaction object containing relevant transaction information (such as sender, recipient, amount, Gas price, etc.)
  • Signing the transaction object: Use a private key to sign the constructed transaction object to ensure the security and integrity of the transaction.
  • Sending the transaction: Send the signed transaction object to the Ethereum network.

Constructing a Transaction#

The raw data structure of a transaction

interface Transaction {
  from: Address // Sender of the transaction
  to: Address // Recipient of the transaction
  nonce: Hex // Nonce of the sender
  type: Hex // Transaction type, 0 (legacy) or 1 (EIP-2930) or 2 (EIP-1559)
  value: Hex // Amount of native currency in the transaction, in wei
  data: Hex // Data carried by the transaction
  maxPriorityFeePerGas?: Hex // EIP-1559: priority fee per unit of gas, provided when type=2
  maxFeePerGas?: Hex // EIP-1559: maximum fee per unit of gas, provided when type=2
  gas: Hex // Maximum amount of gas that can be used (gasLimit)
  gasPrice?: Hex // Gas price, provided when type!=2
  accessList?: [] // New attribute added by EIP-2930, a list containing addresses and storage keys, mainly to address the side effects brought by EIP-2929
}

The relevant fields need to be obtained through JSON RPC.

JSON RPC is essentially an HTTP post request, with the difference being that the request parameters have a fixed format, as shown below:

{
  jsonrpc: '2.0', // Specifies the JSON-RPC protocol version
  method: '', // Name of the method being called
  params: [], // Parameters required for the method call
  id: 1 // Identifier for this request
}

The response format is as follows:

{
  jsonrpc: '2.0', // Specifies the JSON-RPC protocol version
  id: 1, // Identifier for this request, consistent with the id in the request parameters
  result: '' // Result of the request
}

Next, we will detail each field in the transaction object.

from#

The sender of the transaction, must be an EOA address.

There are two types of accounts in Ethereum: external accounts and contract accounts.

  • External Account: Externally Owned Accounts, abbreviated as EOA, has a private key, and its codeHash is empty.

  • Contract Account: Contract Account, abbreviated as CA, does not have a private key, and its codeHash is non-empty.

to#

The recipient of the transaction, which can be either EOA or CA.

nonce#

The nonce of the transaction sender, which is a count of the number of transactions the account has sent, serving two main purposes:

  • Preventing double spending (replay attacks): In the Ethereum network, each transaction has an associated nonce value. The nonce is a number that can only be used once, ensuring that each transaction is unique. This way, the Ethereum network can prevent double spending attacks, meaning a user cannot use the same funds for two or more transactions.

  • Transaction order: When a user sends a new transaction, the nonce value of that account increments. Through this mechanism, the Ethereum network ensures that transactions are processed in the correct order, meaning earlier transactions are processed before later ones, maintaining the correctness of account states and the atomicity of transactions.

The nonce value can be obtained using the JSON RPC method eth_getTransactionCount.

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
}

The eth_getTransactionCount method has the following two parameters:

  • address: Account address.
  • blockNumber: Block number, which can be a hexadecimal block height value or one of latest, earliest, pending.
    • Specific block number: Queries the transaction count for the specified address at that block.
    • latest: Queries the transaction count for the specified address at the latest block.
    • earliest: Queries the transaction count for the specified address at the genesis block (the first block).
    • pending: Queries the transaction count for the specified address at the current pending block (blocks not yet processed by miners).

type#

Transaction type, there are three types of transactions in Ethereum, with the following values:

  • 0: legacy, transactions before EIP-2718, transaction fields include:
from, to, type, value, data, nonce, gas, gasPrice
  • 1: EIP-2930, adds the field accessList:
from, to, type, value, data, nonce, gas, gasPrice, accessList
  • 2: EIP-1559, removes gasPrice, adds maxPriorityFeePerGas and maxFeePerGas:
from, to, type, value, data, nonce, gas, maxPriorityFeePerGas, maxFeePerGas, accessList

value#

The amount of ETH carried by the transaction, in WEI ($1\tt{ETH}=10^{18}\tt{WEI}$).

data#

The data carried by the transaction; if it is a transfer transaction, this field can be empty. If it is a contract call transaction, data will be the hash of the contract function selector concatenated with the encoded function parameters.

maxPriorityFeePerGas#

The priority price per unit of Gas, provided only when type is 2; this fee will be paid to miners.

The current latest maxPriorityFeePerGas can be obtained using the JSON RPC method eth_maxPriorityFeePerGas.

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

This method is not a standard method and is typically provided by third-party node service providers (such as Alchemy, Infura, etc.). If the node you are using does not have this method, you can try the following alternatives:

  • Use the JSON RPC method eth_gasPrice to get the current latest gasPrice.
  • Use the JSON RPC method eth_getBlockByNumber to get the current latest block information block, which contains baseFeePerGas.

Subtracting the two can yield maxPriorityFeePerGas.

maxPriorityFeePerGas = gasPrice - block.baseFeePerGas

maxFeePerGas#

The maximum price per unit of Gas, provided only when type is 2. This field aims to prevent transactions from being excluded from the packaging sequence due to fluctuations in gasPrice. The usual calculation formula is baseFeePerGas multiplied by a multiple multiple plus maxPriorityFeePerGas.

maxFeePerGas = block.baseFeePerGas * multiple + maxPriorityFeePerGas

When multiple is 2, it can ensure that even with 6 consecutive blocks full of Gas, the transaction will still be waiting in the memory pool for packaging.

Different frameworks set multiple to different values; in viem, it is set to 1.2, while in ethers.js, it is set to 2.

gas#

This field indicates the maximum amount of gas that the transaction can spend, i.e., gasLimit. For transfer transactions, this value is fixed at 21000.

The estimated value for the transaction can be obtained using the JSON RPC method 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 = {
  from: '0x...',
  to: '0x...',
  nonce: '0x...',
  type: '0x2',
  value: '0x2386f26fc10000',
  maxPriorityFeePerGas: '0x3f7',
  maxFeePerGas: '0x42a'
}
originTransaction.gas = await estimateGas(originTransaction)

Signing#

To ensure that the transaction is initiated by the holder of the private key, the transaction must be signed using the private key. Before signing, it must go through serialization and encoding processes.

Transaction encoding uses the RLP encoding algorithm, following the formulas below based on the transaction type:

  • 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])

Serialization#

The serialization process essentially arranges the fields in the transaction object in a specific order.

For different transaction types, there are different orders according to the formulas above. (When unsigned, the last three private key signature fields can be empty.)

  • type=0: Order is [nonce, gasPrice, gas, to, value, data].
  • type=1: Order is [chainId, nonce, gasPrice, gas, to, value, data, accessList].
  • type=2: Order is [chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gas, to, value, data, accessList].

For the transaction

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

The serialized result on the goerli network is:

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

Encoding#

The serialized result is then RLP encoded to obtain a Uint8 type byte array, while the transaction type is added as the first element of the array.

import RLP from 'rlp'
const toRlp = (serializedTransaction) => {
  // Add the transaction type as the first element of the array
  return new Uint8Array([2, ...RLP.encode(serializedTransaction)])
}
const rlp = toRlp(serializedTransaction)

According to the formulas above, if type = 0, there is no need to add the transaction type to the array.

Finally, apply the keccak_256 hash function to the RLP encoded result to generate a 32-byte hash value.

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

secp256k1 Signing#

Sign the hash result using the private key.

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
}

After obtaining the signature results r, s, and v, re-add them to the serialized array according to the formulas and re-encode using RLP.

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

The final result lastRlp is a Uint8 type byte array, where each element occupies 1 byte, with values represented as indices in a hexadecimal array of length 256.

// Convert numbers from 0 to 255 to hexadecimal and store them in an array
// [ "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')
)

// Iterate over the lastRlp array, concatenate the corresponding values found in hexes based on the stored index values
const signedTransaction =
  '0x' +
  lastRlp.reduce((prev, current) => {
    return prev + hexes[current]
  }, '')

Finally, the signed transaction signedTransaction is obtained as a hexadecimal string.

Sending the Transaction#

Use the JSON RPC method eth_sendRawTransaction to send the signedTransaction to the node.

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
}

The eth_sendRawTransaction method will return the transaction hash.

Getting the Transaction Receipt#

After sending the transaction, to ensure its completion, you can poll the JSON RPC method eth_getTransactionReceipt to obtain the transaction receipt.

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)

The eth_getTransactionReceipt method takes the transaction hash as a parameter.

For the complete code, see Github.

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.