以太坊采用不同的事务类型来定义不同的操作，例如，将以太币发送至某个地址、部署合约等等。

在最近的柏林升级之前，以太坊主要有4种不同的事务“类型”：

带有收款方地址、数据字段的常规事务

不带有收款方地址的合约部署事务，其数据字段填写的是合约代码

签名v值不含链ID的事务（EIP155实行之前）

签名v值含有链ID的事务

上述事务类型都采用相同的格式。不同的以太坊客户端、库和其它工具必须分析每个事务来判断它属于哪个类型。这四种不同的事务类型引入了很多复杂的情况。我们需要查看事务的所有字段来判断其所属类型。这是人们在提议新的事务类型（如元事务、多签事务等）时不得不面对的重大难题，直到EIP 2718出现才打破这一困境。以太坊现在有了新的事务标准Typed Transaction Envelope（类型化事务封套），由EIP 2718的提议者Micah Zoltu定义。该标准为以太坊上的一些新功能和即将开发的功能奠定了基础。在本文中，我们将回顾柏林升级引入的一些标准以及未来有可能引入的其它标准。

标准化的事务封套

过去，以太坊的事务都采用同一种格式。每个以太坊事务都有6个字段：nonce、gasprice、gaslimit、to address、value、data、v、r和s。这些字段需要经过RLP编码，如下所示：RLP([nonce,gasPrice,gasLimit,to,value,data,v,r,s])

EIP 2718为类型化事务定义了一种新的通用封套。在新的标准下，事务如下所示：TransactionType||TransactionPayload

上述字段的定义是：

TransactionType：0至0x7f范围内的某个值，最多可代表128种事务类型。

TransactionPayload：由事务类型定义的任意一个字节数组。

将上述字段连接（合并）起来，即可得到一个类型化事务。EIP 2718没有为事务的有效负载定义格式。因此，事务的有效负载可以是任意一段经过编码的字节序列，只要采用符合新的事务类型（如RLP、SSZ等）定义的编码器即可。之所以选择简单的字节相连方式，是因为读取字节数组的第一个字节非常简单，无需使用任何库或工具。也就是说，你不需要使用RLP或SSZ解析器来判断事务类型。这个方法可以避免新的EIP在引入新的事务类型时增加现有事务格式的复杂性，并让不同的以太坊工具（客户端、库）更容易区分不同的事务。在增加复杂性这一点上，EIP-155就是一个很好的例子。它通过在事务中引入链ID来实现重放攻击保护。由于在事务参数中增加新的字段会破坏向后兼容性，链ID被编码进了事务签名的恢复参数（v），就像我在上一篇关于数字签名的文章中解释的那样。实行EIP 2718后，我们可以在不影响向后兼容性的情况下定义新的事务类型。

向后兼容性和传统事务 (责任编辑：admin)