在以太坊上发送交易的九种方式

本文的目的是为以太坊生态系统中用于发送交易的各种技术、模式和机制提供指南。 随着新技术层出不穷，本文也会随之更新，算是未完待续。

本文的目的是为以太坊生态系统中用于发送交易的各种技术、模式和机制提供指南。 随着新技术层出不穷，本文也会随之更新，算是未完待续。

针对这个公认的大话题，本文将包括以下内容：

背景知识 以太坊是一个基于账户的系统。 目前有两种类型的账户：普通账户和合约账户。 两种类型的账户都有自己的以太坊地址、交易计数器 Nonce 和余额。 合约账户也有不可变代码和相应的存储空间。 这是一篇介绍这些基本概念的好文章。

以太坊交易包含以下关键字段：

请注意，上面的关键点是没有“交易发起”地址，因为该地址可以从生成交易哈希签名的公私密钥对中推导出来，其中交易字段适当地使用 RLP（递归长度前缀）编码。 Gas使用量和Gas代币 从一个很通俗的角度来看，区块链可以看作是一个共享数据库。 每次从数据库读取或写入数据时，都需要消耗 gas 来防止垃圾邮件等恶意攻击。 具体来说，在以太坊上执行的每个计算步骤都会消耗 gas，以避免可能使以太坊陷入停顿的恶意攻击。 每个操作码的 gas 成本在以太坊黄皮书中都有描述。 但操作码的 gas 成本仍然是一个热议的话题，以太坊社区的成员正在研究引入存储租金机制的可能性，甚至是 gas 和操作码的动态定价方案。

在以太坊区块链中写入数据非常昂贵。 例如，创建一个非空存储单元需要 20,000 gas，这几乎相当于一次简单的 Ether 转账交易（即交易结构中数据字段为空时）的成本（21000 gas）。 作为缓解区块链数据存储爆炸的激励方案，以太坊协议将退还 10,000 gas 用于清空不再使用的旧存储单元。

这种Ether返还机制最多可以返还一半的合约交易消耗的gas（普通转账交易不能返还，因为已经用完了最低消耗的gas；但是批量调用合约可以享受这个返还机制）。 Gas Token 可以让开发者简单高效地使用这种返还机制，即通过 gas 的代币化，在 gas 价格低的时候囤货，然后在 gas 价格高的时候花掉之前储存的 gas token。

近期，部分交易所发现漏洞，未正确设置交易gas上限。 攻击方式很简单：在交易所申请提现，然后将提现交易的目标地址设置为攻击者部署的恶意合约。 它默认的回退函数（发送以太币到合约会触发函数调用）会借此机会锻造一个新的Gas Token（囤积gas）。 （校对说明：详见《蚁巢深处》文末超链接）

元交易 元交易是一种发送交易的模式：发送方先签署合法的以太坊交易，然后通过链下传输的方式将交易和签名转给中继方，中继方愿意承担gas交易的开销，最后将交易发送到以太坊网络。

640

-以太坊极客喜欢抽象-

这种元交易模型很有用，因为发送方不再需要在发送账户中拥有以太币，这从用户体验的角度来看是有益的。 我之前在这篇文章中提到过元交易及其对用户体验的影响。

元交易的最终目标地址通常是以太坊合约，在某种程度上，合约知道交易的签署者不是交易的实际发送者。 以太坊交易API的msg.sender字段会返回relayer的地址，但它很可能没有代表签名者的权限，所以在这个场景下（只看msg.sender字段）并没有很有意义。 因此，许多元交易依赖于链上签名验证（通过以太坊 API 的 ecRecover 函数）来确保签名者账户确实在适当的白名单中（有权操作交易要执行的指令）。

Submarine Send（不要与这个 Submarine Send 网站混淆）

矿工抢跑现象是基于区块链经济的交易市场难以根除的老问题，即矿工可以对交易进行重新排序，随意砍单，或者让自己的交易插队获利。 海底交易试图通过强大的保密特性为矿工抢先交易问题提供解决方案。 Submarine Transactions 不仅会隐藏交易金额，还会尝试完全隐藏交易的存在。 当然，如果一个交易总是隐藏起来，那就不是很有趣了。 潜艇交易允许发送方在未来某个时间点披露交易，这就是它被称为“潜艇”交易的原因。

640

-通过使用海底交易，用户的交易不会被矿工抢占-

用户提交包含加密承诺的交易，其中包含一些用户想要发送给目标合约的应用数据，并将交易中涉及的以太币或代币锁定在潜地址中，潜地址与全新的地址（因此很难被矿工识别）。 锁定在该地址中的以太币或代币只能由目标合约解锁。 通过为承诺交易附加币值（除非用户完成承诺的披露，否则额外的币值实际上被销毁且无法找回），我们确保有效的经济约束来防止一些恶意用户选择性地发布承诺（即阻止用户从能够免费提交任意承诺）。 只要承诺交易被成功打包并得到足够多的区块确认，用户就可以向目标合约公开其加密的承诺，合约（验证成功后）将执行交易中包含的应用逻辑。反事实合约实例化

反事实一词来自哲学和思辨中的一个概念。 反事实陈述是一连串有根据的推理和相应的结论，但陈述的前提故意与事实相反。 除了这个与事实不符的前提外，整个推理链条都是合理的，所以如果前提正确，最后的结论也就正确了。 应用到区块链交易场景，Conterfactual的逻辑不仅会考虑区块链当前的状态以太坊同签名下的子账号，还会考虑某个合约部署后区块链的状态。

640

更具体地说，在部署之前获取合约的地址，这种模式称为反事实合约实例化，该理论由 L4 在他们的“Counterfactual State Channels”论文中发表，并得到以太坊社区的支持。 广受欢迎。

目前，新的合约地址是由以太坊运行代码CREATE生成的，可以通过合约创建者的账户地址（sender字段）和创建者发送的交易数量（nonce字段）明确判断，即即，sender 和 nonce 字段将通过 RLP 编码和 Keccak256 哈希算法生成一个新的合约地址。

EIP1014 引入的 Skinny CREATE2 操作码更进一步，允许用户与链上尚不存在的地址进行交互； 虽然地址上还没有代码，但可以保证它最终可能只包含由特定初始代码段生成的合约逻辑。 与 CREATE 操作码一般使用 sender-nonce 然后哈希得到合约地址不同，CREATE2 操作码使用以下地址生成公式：keccak256( 0xff ++ address ++ salt ++ keccak256(init_code)))[12: ] 。

这种模式对于涉及与尚不存在的合约进行交互的状态通道场景尤其重要。 它允许以太坊主链成为争议（解决）层，而无需考虑合约部署的实际开销。 同样，这种模式也可以用于已知函数会创建新地址的场景，比如这里的还款地址。

零确认交易

零确认交易起源于比特币现金社区，并且仍然是一个有趣但未经证实的研究领域，在区块链网络中，块时间可能会大大抑制用户体验。 零确认交易的发送方需要提交保证金，如果出现双花行为，发送方将损失保证金。 在比特币现金中，可以通过重复使用 UTXO 条目来检测双重支出。 任何人（一般假定为矿工）都可以提交发现的两笔双花交易，然后获得押金奖励。

在以太坊的账户网络中，我们可以检查同一发送者是否重复使用了相同的随机数，而不是使用类似比特币的 UTXO。 例如，部署的合约提供了一个 reportDoubleSpend 方法，它接受两个已签名的交易来完成，然后合约会检查它的发送者和随机数，如果它们相等，它会奖励方法调用者一笔押金。 原理很简单：如果存款金额足够大，它是交易发送方防止作弊（双花）的有力武器，因为他们可能会损失所支付的存款。 这类交易被认为最适合小额的一次性单笔支付场景，因为针对该场景存在一系列潜在的攻击模式。

批量转账与ERC20代币交互的一个主要问题是，一般需要两种不同的交易：一种是调用代币合约的approve方法，另一种是实际调用目标合约（transferFrom方法将在目标合约内部调用）使用 Tokens 完成特定逻辑（doSomethingForTokens 方法）。 该模型会产生一系列非原子事务问题。 最简单的情况是，如果 doSomethingForTokens 调用交易失败，之前的 approve 调用不会回滚，即 approve 方法允许合约控制的代币配额（配额）仍然持有。

640

- ERC20 代币合约的 approve 和 transferFrom 方法是非原子的 -

Limechain 实现了一种特殊的批量转账方法。 借鉴元交易中的链上签名验证原理，失败的doSomethingForTokens调用交易将回滚相应的approve调用，从而改善了ERC20代币原有approve和transferFrom方法的非原子性。 基于短信的支付

CoinText 可能是最著名的基于短信的加密货币支付服务提供商，目前专注于比特币现金交易。 这种支付机制对发展中国家的移动设备特别有用。 Eth2 已经在以太坊上部署了类似的技术，该技术通过传统的基于移动应用程序的以太坊钱包（如 Trust）运行。

640

- eth2.io 基于短信的加密数字支付解决方案 -

此特定解决方案采用托管合同。 交易发送方生成一个临时公私钥对，然后将以太币存入托管合约，之前生成的临时公钥附在转账上。 使用随机生成的对称密钥对私钥进行加密，然后通过链下方式（电子邮件、短信、Whatsapp 等）将密文发送到中心化验证服务器。 提现时，如果收款人手机号验证成功，验证服务器会将密文发送给收款人，收款人可以解密（即得到临时私钥），然后对提款交易报文进行签名，然后托管合约可以验证该签名，以确认它是由临时私钥签名的。

中心化服务器用于验证手机号和传递秘钥，但Eth2服务器无法控制托管合约中锁定的以太币。 如果中心化服务器被攻击，支付交易将失败，但以太币仍在托管合约中。 如果此时想要取回锁定的以太币，发送方可以通过调用托管合约取消支付。

订阅支付 基于选择退出订阅服务的支付是Web2.0时代互联网服务的主流变现方式。 例如，Spotify、Netflix、Headspace 和 Tinder 都建立了基于订阅付费的商业收入模式。

加密货币订阅支付的概念并不新鲜。 在比特币中，nLocktime 字段可以用来保证一个已签名的交易在指定的区块高度之前不会被打包（即消费）。 但在以太坊上，预签名交易对于未来的支付意义不大，因为账户的nonce会随着账户不断发送交易而增加，这会导致预签名使用的nonce过小，从而导致交易无效。

幸运的是，以太坊的图灵完备性提供了一个解决方案：有一些架构解决方案可以用于循环订阅类型的交易。 这些架构在保证金（流动性）、UX 复杂性、可选功能、gas 开销和可扩展性方面有不同的权衡。

另一种更特殊的基于oracle方法调用的交易发送方式是使用oracle服务，如Oraclize，通过适当的中心化来换取gas使用量的减少，参见这篇文章。

640

-使用Oraclize减少持续合约调用的gas使用量-

这种类型适用于非事务性（返回常量）方法调用。 已经与以太坊主网同步的节点可以通过以太坊JSON-RPC的eth_call接口调用上述方法。 只要继承了usingOraclize，就可以在你的合约中使用Oraclize的oraclize_query方法进行常量查询。 此外，你还必须在你的合约中定义回调函数__callback(bytes32 queryId, string results)。 Oraclize 查询会调用这个函数并保存查询结果。 直接进行链上查询以获取和计算这些状态常量可能比调用 Oraclize 更昂贵。 使用一次性地址进行多次支付 背景中提到，交易字段中没有“发起地址”。 这个地址可以通过 ecRecover 函数计算出来。 那么问题来了：我们能不能在交易签名中任意填写我们想要的数据呢？ 事实证明，一半的签名是正确的，即 ecRecover 仍然返回一个合法的公钥（以及相应的以太坊地址）。 由于我们无法控制生成的地址，通过设置字段值，我们实际上是在构建这样一个交易：交易可以在看似随机生成的地址中花费余额。

如果我们创建这样一个交易（发送方是我们要生成的地址），并向生成的地址充值一些以太币，那么这个交易就可以像普通交易一样执行。 通过这种方式，我们实质上创建了一个一次性地址，因为其中的余额只能由一次交易使用。 如果我们以某种可预测的方式选择交易签名中的字段值并发布交易，我们就可以向任何人证明发送到交易发送方地址的金额只能被本次交易使用，不能用于任何其他交易。

640

如上图所示，该场景尝试向11140个目标地址发送交易，由一系列向多个地址发送Ether的交易组成，每笔交易向110个地址发送，其中发送方的地址由以上方法。 对于签名字段，我们填入'0xDA0DA0DA0…'，这是一个可预测的值以太坊同签名下的子账号，这样我们就可以确定没有人能够得到这些签名对应地址的私钥。

这将创建一批具有“一次性地址”的交易，可用于为相应交易提供所需的交易金额。 但是104笔交易对于委托的自然人来说还是太多了，所以我们重复上面的过程，形成级联结构：我们先构造104笔交易，每笔交易都有其对应的唯一地址，然后构造转账发送以太币到相应的104地址。 经过验证，代码确实可以按预期运行，那么任何人都可以将这些构建的交易发送到以太坊网络，整个过程像多米诺骨牌一样自动进行：列表中的 11400 个地址将收到 Ether，但我们只使用了一次人类签名。

在以太坊上完成交易的方式有很多种！ ！ ！

如果我遗漏了什么，请告诉我，我会不时更新这篇文章。 在推特上关注我：

原文链接：作者：Aodhgan Gleeson 翻译校对：Ray & A Jian 来源：以太坊爱好者（微信公众号）