Alert Source Discuss
Standards Track: Networking

EIP-2976: 通过 Gossip 传输的类型化交易

增加了通过 devp2p 传输类型化交易的支持。

Authors Micah Zoltu (@MicahZoltu)
Created 2020-09-13
Requires EIP-2718

Table of Contents

摘要

类型化交易 可以作为 TransactionType || TransactionPayload 通过 devp2p 发送。 TransactionPayload 的确切内容由未来 EIP 中的 TransactionType 定义，客户端可以开始支持它们的 gossip，而无需增加 devp2p 版本。 如果客户端收到无法识别的 TransactionType，则应该断开与发送它的对等节点的连接。 在他们认为已经到达分叉区块之前，客户端不得发送新的交易类型。

动机

EIP-2718 为区块引入了新的交易类型（它以区块头部的交易根和收据根的形式呈现）。 然而，如果没有一种八卦这些交易的机制，实际上没有人可以将它们包含在区块中。 通过更新 devp2p 以支持类型化交易的 gossip，我们可以从这些新的交易类型中受益。

注意：有关类型化交易的其他动机，请参阅 EIP-2718。

规范

以下指定的所有更改都追溯适用于所有协议/版本。

定义

  • || 是字节/字节数组连接运算符。
  • | 是类型联合运算符。
  • DEVP2P_VERSION = TBD
  • Transaction 是 TypedTransaction 或 LegacyTransaction
  • TypedTransaction 是一个字节数组，包含 TransactionType || TransactionPayload
  • TypedTransactionHash 是 keccak256(TypedTransaction)
  • TransactionType 是一个介于 0 和 0x7f 之间的正无符号 8 位数字，表示交易的类型。
  • TransactionPayload 是一个不透明的字节数组，其解释取决于 TransactionType，并在未来的 EIP 中定义。
  • LegacyTransaction 是 [nonce, gasPrice, gasLimit, to, value, data, v, r, s] 形式的数组
  • LegacyTransactionHash 是 keccak256(rlp(LegacyTransaction))
  • TransactionId 是 keccak256(TypedTransactionHash | LegacyTransactionHash)
  • Receipt 是 TypedReceipt 或 LegacyReceipt
  • TypedReceipt 是一个字节数组，包含 TransactionType || ReceiptPayload
  • ReceiptPayload 是一个不透明的字节数组，其解释取决于 TransactionType，并在未来的 EIP 中定义。
  • LegacyReceipt 是 [status, cumulativeGasUsed, logsBloom, logs] 形式的数组
  • LegacyReceiptHash 是 keccak256(rlp(LegacyReceipt))

协议行为

如果客户端通过任何消息收到无法识别的 TransactionType，则应该断开发送它的对等节点。

如果客户端收到对 TransactionType 无效的 TransactionPayload，则应该断开发送它的对等节点的连接。

客户端不得在交易类型的介绍性分叉区块之前发送新的 TransactionType 交易。

客户端可以在新的 TransactionType 交易类型的介绍性分叉区块之前很久断开发送该交易的对等节点。

协议消息

Transactions (0x02): [Transaction_0, Transaction_1, ..., Transaction_n]

BlockBodies (0x06): [BlockBody_0, BlockBody_1, ..., BlockBody_n] 其中：

  • BlockBody 是 [TransactionList, UncleList]
  • TransactionList 是 [Transaction_0, Transaction_1, ..., Transaction_n]
  • UnclesList 在以前版本的 devp2p 规范中定义

NewBlock (0x07): [[BlockHeader, TransactionList, UncleList], TotalDifficulty] 其中：

  • BlockHeader 在以前版本的 devp2p 规范中定义
  • TransactionList 是 [Transaction_0, Transaction_1, ..., Transaction_n]
  • UnclesList 在以前版本的 devp2p 规范中定义
  • TotalDifficulty 在以前版本的 devp2p 规范中定义

NewPooledTransactionIds (0x08): [TransactionId_0, TransactionId_1, ..., TransactionId_n]

GetPooledTransactions (0x09): [TransactionId_0, TransactionId_1, ..., TransactionId_n]

PooledTransactions (0x0a): [Transaction_0, Transaction_1, ..., Transaction_n]

Receipts (0x10): [ReceiptList_0, ReceiptList_1, ..., ReceiptList_n] 其中：

  • ReceiptList 是 [Receipt_0, Receipt_1, ..., Receipt_n]

理由

为什么不在协议层指定每种交易类型？

我们可以选择让协议知道交易 payload 的形状。 作者认为，让每个新的交易类型都需要更新 devp2p 会带来太多的维护负担，所以我们只是定义了支持类型化交易。

为什么如果对等节点收到未知的交易类型要断开连接？

我们可以鼓励对等节点与提交未知交易类型的对等节点保持连接，以防该交易是接收者不知道的某种新的交易类型。 但是，这样做可能会使客户端容易受到 DoS 攻击，即有人会向他们发送未定义的 TransactionType 的交易，以避免因发送垃圾邮件而被断开连接。 此外，在大多数情况下，我们预计到新的交易类型通过 devp2p 发送时，几乎可以肯定即将发生硬分叉，要求所有连接的客户端都知道新的交易类型。

向后兼容性

仍然支持传统交易。

安全考虑

如果客户端选择忽略断开发送未知交易类型的对等节点的应该建议，他们可能会受到 DoS 攻击。 忽略此建议应仅限于受信任的对等节点，或其他 DoS 风险极低的情况。

版权

通过 CC0 放弃版权和相关权利。

Citation

Please cite this document as:

Micah Zoltu (@MicahZoltu), "EIP-2976: 通过 Gossip 传输的类型化交易," Ethereum Improvement Proposals, no. 2976, September 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2976.