为什么在发送原始交易之前应将签名的交易编码为字节？

Question

我想用合约调用来编写以太坊区块链。我已经找到了两种几乎相同的解决方案，但其中之一是操纵签名的交易，在发送之前进行一些字节编码，我不明白为什么。我的问题是，为什么解决方案 #2和解决方案 #3与解决方案 #1相比使用额外的行？额外的字节操作部分的目的是什么？signedTx和 txToSend 都是*types.Transaction类型，我不明白为什么需要进行编码。go-ethereum 包的文档指出：

SendTransaction 将已签名的交易注入待处理池中以供执行。

它没有提供有关 tx 和types.SignTx()返回*types.Transaction类型的更多信息。

解决方案#1

这是最简单的解决方案，无需对 进行任何操作signedTx。

tx := types.NewTransaction(nonce, toAddress, value, gasLimit, gasPrice, data)
signedTx, err := types.SignTx(tx, types.NewEIP155Signer(chainID), privateKey)
if err != nil {
    log.Fatal(err)
}
txErr := client.SendTransaction(context.Background(), tx)
if txErr != nil {
    log.Fatalf("Error calling contract: %v", err)
}

解决方案#2

这是 Go Ethereum Book 的创建原始交易和发送原始交易部分所使用的实现。

tx_signed := types.NewTransaction(nonce, toAddress, value, gasLimit, gasPrice, data)

signedTx, err := types.SignTx(tx_signed, types.NewEIP155Signer(chainID), privateKey)
if err != nil {
  log.Fatal(err)
}

ts := types.Transactions{signedTx}
rawTxBytes := ts.GetRlp(0)
rawTxHex := hex.EncodeToString(rawTxBytes)
rawBytes, err := hex.DecodeString(rawTxHex)

tx := new(types.Transaction)
rlp.DecodeBytes(rawBytes, &tx)

txErr := client.SendTransaction(context.Background(), tx)
if txErr != nil {
    log.Fatalf("Error calling contract: %v", err)
}

解决方案#3

此实现与之前的实现几乎相同，但它使用更新的 EncodeIndex(i int, w *bytes.Buffer)函数进行字节操作。来源

tx_signed := types.NewTransaction(nonce, toAddress, value, gasLimit, gasPrice, data)

signedTx, err := types.SignTx(tx_signed, types.NewEIP155Signer(chainID), privateKey)
if err != nil {
  log.Fatal(err)
}

ts := types.Transactions{signedTx}
b := new(bytes.Buffer)
ts.EncodeIndex(0, b)
rawTxBytes := b.Bytes()

txToSend := new(types.Transaction)
rlp.DecodeBytes(rawTxBytes, &txToSend)
txErr := client.SendTransaction(context.Background(), tx)
if txErr != nil {
    log.Fatalf("Error calling contract: %v", err)
}

Answer 1

以太坊交易有不同类型：EIP1559、EIP2711、EIP2718

\n

并非所有geth客户端都支持每种交易类型。我认为您问题中编码的交易是 EIP2718。

\n

https://blog.mycrypto.com/new-transaction-types-on-ethereum

\n

从上面的文章来看：

\n

\n

EIP-2718 为类型化交易定义了一个新的通用信封。在新标准中，交易如下所示：

\n

交易类型 || 交易有效负载

\n

其中字段定义为：

\n

TransactionType：0 到 0x7f 之间的数字，总共 128 种\n可能的交易类型。TransactionPayload：任意字节数组，由交易类型定义。这些字段连接\n（组合）以形成类型化事务。该标准没有描述交易有效负载的格式；它可以是任何任意字节序列，使用新交易类型定义的任何编码器进行编码（例如，RLP、SSZ、\xe2\x80\xa6）。选择简单字节连接是因为读取字节数组的第一个字节很简单，不需要任何库或工具：您不需要 RLP 或 SSZ 解析器来检查事务类型。

\n

\n

或者可能是不同的 EIP 类型。检查您的 geth 客户端版本以及支持哪些版本

\n