- A+
交易执行
交易执行是以太坊协议中最复杂的部分：它定义了状态转换函数 。
所有交易在执行时, 都要先通过内部的有效性测试, 这些包含：
(1) 交易是 RLP 格式数据，没有多余的后缀字节；
(2) 交易的签名是有效的；
(3) 交易的随机数是有效的（等于发送者账户的当前随机数）;
(4) 燃料上限不小于实际交易过程中用的燃料 g0;
(5) 发送者账户的余额至少大于费用 v0, 需要提前支付。
子状态. 从交易执行过程来看，伴随交易会产生一些特定的信息, 我们称为交易子状态。
执行. 执行过程中需要的燃料需要在交易进行之前支付
有效交易的执行起始于一个对状态不能撤回的改变：发送者账户 S(T ) 的随机数会加 1, 账户余额扣减部分预付费用 Tg Tp
细微之处. 有一种情况需要注意, 当初始化代码正在执行时，新创建的地址出现了, 但还没有内部的代码时。在这个时间内, 任意消息调用不会引起代码执行。如果这个初始化执行结束于一个 SELFDESTRUCT 指令，这个账号会在交易执行完前将被删除, 这个行为是无意义的。对于一个正常的 STOP 指令代码，或者返回的代码是空的, 这时候会出现一个僵尸账户，而且账户中剩余的余额将被永远被锁定在这个僵尸账户中。
消息调用
当执行消息调用时需要多个参数：发送者（s）、交易发起人（o）、接受者（r）、执行代码的账户（c, 通常就是接受者）、可用的燃料（g）、转账额度（v）、燃料价格（p）、函数调用的一个任意长度字节的数组 d 的输入数据以及消息调用/合约创建的当前栈 (e) 深度。除了转变到新的状态和交易子状态外，消息调用还有一个额外的元素 — 用字节数组 o 表示的输出数据。执行交易时输出数据是被忽略的, 但在消息调用时, 输出的数据可以由虚拟机代码执行时进行初始化, 在这种情况下也使用了这些信息。
消息调用执行框架 中有 4 个特例: 这四个是‘预编译’合约，作为最初架构中的一部分后续可能变成本地扩展。这四个合约地址分别为 1、2、3 和 4，分别是用来执行椭圆曲线公钥恢复函数、SHA2 256 位哈希方案、RIPEMD 160 位哈希方案和身份函数。
