交易签名为什么要在发送之前被编码为字节？

小伙伴们对Golang编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《交易签名为什么要在发送之前被编码为字节？》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

我想用合约调用来编写以太坊区块链。我已经找到了两种几乎相同的解决方案，但其中之一是操纵签名的交易，在发送之前进行一些字节编码，我不明白为什么。我的问题是，与解决方案#1相比，为什么解决方案#2和解决方案#3使用了额外的行？额外的字节操作部分的目的是什么？ 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)
}

正确答案

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

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

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

摘自上述文章：

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

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

其中字段定义为：

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

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

如果目标是创建交易并广播它，解决方案 1 就可以。在幕后，golang 库将交易编码为字节数组并将其发送到 geth 节点。

我认为这本书想要更精确并展示中间发生的事情（例如打印编码交易的十六进制）。这就是他进行这种编码的原因。是强制性的吗？没有。

能够对交易进行编码和解码可能会很有用，例如您在其他地方创建交易并且您只想在 go 程序中签名/广播它。在这种情况下，您必须解码字节数组并从中创建交易。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《交易签名为什么要在发送之前被编码为字节？》文章吧，也可关注golang学习网公众号了解相关技术文章。