最近关于交易格式的详细思考带来的一个积极结果——不仅仅是8141，还有“状态的未来”讨论，例如UTXOs、PBT、键控随机数（keyed nonces），以及递归STARK内存池 ——是我们对交易如何具有“动作”和“依赖”的理解更加明确，并且我们可以围绕优化这两者分别进行设计。 动作是交易产生的效果。 依赖是关于交易和/或状态的事实，这些事实必须为真才能使交易有效。 例如，签名是依赖，UTXO的Merkle证明是依赖，ZK-SNARK（或STARK）是依赖，发送ETH的调用是动作。 依赖可以并行处理。涉及状态的依赖可以通过内存池进行推理，特别是如果访问的具体状态是静态声明的。纯依赖（不允许调用状态）可以在内存池层处理一次，并且不需要再次处理——甚至可以用验证它们的STARK替代，不仅允许执行，还允许数据被省略。 原则上，依赖和动作都可以表达为调用（如果需要，可以调用预编译）。这将使交易格式本身非常简洁和极简化（一个调用列表，每个调用的类型标志，例如依赖是静态或纯调用，以及来源、随机数等），并允许最大程度的跨兼容性，即使不同的EVM链具有不同的功能。 在2015年以太坊时代，明确思考这些差异并不重要：执行就是执行，交易数量少到我们可以全部串行处理，单密钥ECDSA账户对所有人来说已经足够。 然而，以太坊当前的扩展策略需要超越这种范式。以太坊受到许多开发者的喜爱，因为其执行和状态模型非常动态和灵活。但动态和灵活对扩展并不友好。幸运的是，以太坊按交易量计算的活动中超过90%并不需要任何动态和灵活。因此，我们需要合约、账户和交易更明确地指定哪些是动态和灵活的，哪些是更静态可分析但更受限制的，而更静态可分析的内容将获得最低的Gas成本，从而实现最大程度的扩展。实际上，从2015年以太坊模型和更类似比特币的模型中学习（提醒一下：比特币从一开始就拥有我称之为账户抽象的功能），并提供两者的混合（实际上是两者之间的完整光谱），根据涉及的扩展级别分配适当的Gas成本。 新的状态类型、递归STARK内存池、键控随机数等都朝着这个方向发展。 这一切都与交易类型相关，因为通用交易类型是一个非常自然的接口层，所有这些都可以在其上实现，而当前围绕EIP-8141交易类型的思考正朝着这种对未来泛化友好的方向发展。 从这个意义上说，8141如果做得好，不仅是10年账户抽象工作的巅峰，也是为未来几年负责任的去中心化友好型超扩展做准备。