干货 - 以(yi)太坊上发送交易的九种办法

本文的目的是为以太(tai)坊生态系统中用(yong)于发送交易的各种技术、模式和机制提供指南。随着新技术层出不穷，本文也(ye)会相应更新，所(suo)以可以认为是一种未完(wan)待续的状态。

本文将包含以(yi)下内容：

以太坊交(jiao)易简介？以太坊交易简介(jie)：用气和gasToken？燃气和燃气令牌元交易的目的(de)？元交易潜水艇发送？潜艇交易的反事(shi)实例证？反事实合同(tong)实例化零确认交易？零确(que)认交易批量转移？基于(yu)短信的批量转账(zhang)支付？基于短信重复订购支付的支(zhi)付？通过Oracle contract为(wei)批量交易减少订购付款？通过Oracle contracts为批量交易保(bao)存带有一次性地址(zhi)的gasmultisends？使用一次性地址进行多次(ci)支付

以太坊是一个基于账户的系(xi)统。目前有两种账户：普通账户和合同账户。两个账(zhang)户都有自己的以太坊地址、交易计(ji)数器随机数和余额。契约账户也有不(bu)可变的代码和相应的存储空间(jian)。这里有一篇介绍这(zhe)些基本概念的好文章(zhang)。

以(yi)太坊交易包含以下关键(jian)字段：

Nonce，或交易计数器，即该账户发起(qi)的交易次数，从0开始计算(suan)气价，这决定了(le)该交易要支付的(de)以太量。gas Limit，即(ji)允许处理该事务的gas的最大数量(liang)的目标地址，即接受该事务的对象。如(ru)果为空，则交易将创建新的合同交易金(jin)额，即发送的以太量(liang)数据，它可以是任意的(de)文本消息、对合(he)同的调用或创建(jian)新合同的代码

。请注(zhu)意，上面的关键点是没有(you)“交易发起”地址，因为这个地址可以(yi)从生成这个交易的哈希值签名的(de)公钥-私钥对中导出，交易字段由适(shi)当的RLP(递(di)归长度前缀)编码。

站在一个(ge)很通俗的角度。区块链可以看作是一个(ge)共享的数据库。每次从这个(ge)数据库中读取或写入数据时，都需要花(hua)费gas来防止垃圾邮件之类的恶(e)意攻击。具体来说，在以(yi)太坊上执行的每一个计算步骤(zhou)都需要耗费gas，以避免可能导致以(yi)太坊停止的恶意攻击。各操作(zuo)码的气体开销在以太坊黄皮书中有解(jie)释。然而，操作代码的(de)气体开销仍然是一(yi)个热门话题，以太坊的社区(qu)成员正在研究引入存储租金机制的(de)可能性，甚至是气(qi)体和操作代码的动态定价方案(an)。

在以太坊区(qu)块链写数据是昂(ang)贵的。例如，创建一个非空的(de)存储单元需要花费20000 gas，这几乎相(xiang)当于一个简单的以太传输事务的成本(ben)(即当事务结构中的数据字段(duan)为空时)(21000 gas)。作为一项缓(huan)解区块链数据存储激增的激励计划，以(yi)太坊协议将为清空不再(zai)使用的旧存储单(dan)元退还1万燃气。

乙(yi)醚的这种退款机制，最多(duo)可以退还合同交易花(hua)掉的一半的气(普通的(de)过户交易因为已经用了最(zui)低消费的气，是拿不到退款的；但(dan)是批量调用合同可以享(xiang)受这个退款机制)。燃气代币可以让(rang)开发者简单高效地利用这种退款机制，即通过燃气代币，在燃气价格低的时候囤货，然后在(zai)燃气价格高的时候花掉之前存储的(de)燃气代币。

最近确实有交易所发现了一个没有正(zheng)确设置交易气上限的漏(lou)洞。攻击方法很简(jian)单：在交易所申请(qing)提现，然后将提现交易的目标地址设(she)置为攻击者部署的恶意契约，其(qi)默认的回退函数(向契约发送Ether会(hui)触发该函数的调用)会借机施放新的瓦斯令牌(pai)。(校对注：详见文末(mo)超链接《深处的蚁穴》)

元交易是一种发送交易的模(mo)式：发送方先签署一个合法的以太(tai)坊交易，然后通过链式传输将交易(yi)和签名转发给一个(ge)中继。中继愿意承担交易的气体开(kai)销，最终将交易发送到以太坊网(wang)络。

-以(yi)太坊的技术人员都喜欢抽(chou)象——这种元交(jiao)易模式很有用，因为发送(song)方不再需要在发送账(zhang)户中有以太，从用户体验的角度来(lai)看是有益的。我之前(qian)在这篇文章中提到过元(yuan)交易及其对UX的影响。

元交易的最终目的地址一般(ban)是一个以太坊合同，在一定程度上(shang)，合同知道交易的签署方并不(bu)是交易的实际发送方。以太坊交易API的msg.sender字段(duan)会返回中继方的地址，但它(ta)很可能没有代表签约(yue)方操作的权限，所以在这个场景(jing)下没有太大意义(只看msg.sender字段)。所以很多元交易都是依靠链上的签(qian)名验证(通过以太坊API的ecRecover函(han)数)来保证签名人的(de)账户确实在一个(ge)合适的白名单中(拥有操作交易所需指(zhi)令的权限)。

(不要(yao)和这个潜艇交易网站说话？https://submarineswaps.org/？困惑)

矿(kuang)工抢注现象是基于区块链经济的交易(yi)市场中一个难以杜绝的老问题，即矿工(gong)可以重新排序自己的交易(yi)，随意插队或插队自己的交易来获利(li)。海底交易试图通过其强(qiang)大的保密性，为矿工的潜逃问(wen)题提供解决方案。不仅仅是隐藏(cang)交易金额，潜艇交易会试图完全(quan)隐藏这笔交易的存在。当然，如果一笔(bi)交易永远被隐藏起来(lai)，它将毫无意义。潜艇交易允(yun)许发送方在未来的某个时间点披露(lu)交易，这就是为什么它被称为“潜艇(ting)”交易。

——通过使用(yong)潜艇进行交易，用户的交易不会被(bei)挖矿者抢走——用户提交一个带有加(jia)密承诺的交易，交易中包(bao)含一些用户想发送给目标(biao)契约的应用数据，将交易中涉及的以(yi)太或令牌锁定在潜艇地址中，潜艇地址与一个全新的地址相同(因此(ci)很难被挖矿者识别)。此地址(zhi)中锁定的以太网或令牌只能(neng)由目标合同解锁。通过在承(cheng)诺交易中增加货(huo)币价值(除非用户完成了对承诺的(de)披露，否则额外的货币(bi)价值实际上被烧掉(diao)了，无法收回)，我们保证了(le)一个有效的经济约束，以防止(zhi)一些恶意用户选择性地披露他们的承诺(nuo)(即防止用户无成本地提交任何(he)承诺)。只要承诺的交易(yi)被成功封装并被(bei)足够多的区块确认，用户就可以向(xiang)目标契约公开自己的(de)加密承诺，然后(hou)契约(验证成功后)就会执行交易(yi)中包含的应用逻辑(ji)。反事实契约的实例化(hua)反事实一词源于哲学和思维中的一(yi)个概念。反事实陈述是一系列合理的推(tui)理和相应的结论，但陈述的前提(ti)是故意与事实相(xiang)反。除去这个与事实不符的前提(ti)，整个推理链都是合理的(de)，所以前提正确，最后的结论也就正确(que)。当应用于区块(kuai)链交易场景时，contract的(de)逻辑不仅会考虑区块链的当前状态(tai)，如果部署了合同，还会考虑区(qu)块链的状态。

更具体(ti)地说，在部署之(zhi)前获取协定的地址。这个(ge)模型被称为反事实契约实例化。这个理论由L4发表在他们的“反事实状态通道”论文中，受到以太(tai)坊社区的广泛欢迎。目前新的(de)契约地址是由Ethereum操(cao)作码CREATE生成的，可以(yi)通过契约创建者的账户(hu)地址(sender字段(duan))和创建者已经发出的交易(yi)数(nonce字段)明确确定，即sender和nonce字段会经过RLP编码，然后由Keccak256哈(ha)希算法生成。由EIP 1014推出？Skinny CREATE2？此外，操(cao)作码允许用户与链中(zhong)尚不存在的地址进行交互；虽然(ran)这个地址上还没(mei)有代码，但是可以保证它只(zhi)能包含一个特定初始代(dai)码生成的契约逻辑。与CREATE opcode不(bu)同，CREATE2 opcode通常使用sender-nonce，然后进(jin)行哈希运算来获得协(xie)定地址，它使用以下地址生成(cheng)公式：keccak256(0xff地址盐keccak256(init_code)))[12:]？这种模式对于涉及(ji)与尚不存在的合同进行交互的状态通道(dao)场景尤其重要。它允许以(yi)太坊主链成为争议(解决)层，不需要考虑契约部署的真实成(cheng)本。同样，这种模式也可以用在已(yi)知函数将创建新地(di)址的场景中，比如(ru)这里的贷款偿还地址。零确(que)认交易零确认交易来自于？比特币(bi)现金社区目前仍是一个有趣但未经证实(shi)的研究领域。在这样的区块链(lian)网络中，块释放的时间实(shi)际上可能更不利于用户体(ti)验(UX抑制)。确(que)认零交易的寄件人需要提交押(ya)金。如果有重复(fu)消费，寄件人会损失(shi)押金。在比特币现(xian)金中，可以通过重用UTXO的输入项来检测双花行为(wei)。任何人(一般假设是矿工)都可(ke)以提交找到的两个双花交易(yi)，然后获得押金奖励。在以(yi)太坊的账户网络中，与(yu)使用类比特币的UTXO不同，我(wo)们可以检查同一个(ge)发送者是否重用了同一个(ge)nonce。例如，一个已部署的协定(ding)提供了一个reportDoubleSpend方法，该方法接受两个要完(wan)成的已签名事务，然后该协定将检查其发送者和nonce，如果它们相等，它(ta)将奖励方法调用方一个差额。原理(li)很简单：如果保证金金额(e)足够大，这是防止交易发送方作弊(bi)(重复消费)的有力武器，因为他们(men)可能会失去支付的保证金。这种类型(xing)的交易被认为是最适合小额(e)一次性支付的场景，因为这种场景有(you)一系列潜在的攻击模式。批(pi)量转移与ERC20令牌交互的一个主(zhu)要问题是，一般需要两(liang)个不同的事务：一个是调用令牌契(qi)约的approve方法，另一个是实际调用目标(biao)契约(目标契约(yue)内部会调用transferFrom方法)并使用令牌完成特(te)定逻辑(doSomethingForTokens方(fang)法)。这种模式会导(dao)致非原子事务的一系(xi)列问题。在最简单的情况下，如(ru)果doSomethingForTokens调用事务失败(bai)，前面的approve调用将不会回滚，也就是说，approval方法允许契(qi)约所控制的令牌配额仍然(ran)有效。

-ERC 20令牌契约的approve和transferFrom方法是非原子Limechain？实现了一(yi)种特殊的批量传输方法。参(can)考元事务中的链签名验证原理，失败(bai)的doSomethingForTokens调用事务将回滚相应的(de)approve调用，从而提高(gao)了ERC20令牌的原(yuan)有approve和transferFrom方法的非原子性。基于短(duan)信的

CoinText？它可能是最著名(ming)的基于短信的加密货(huo)币支付服务提供商(shang)，目前专注于提供比特币现(xian)金交易。这种支付机制对于发展(zhan)中国家和地区的移动设备尤其有用。Eth2？类似的技术已经部署(shu)在以太坊上，它可以通过基于(yu)移动应用(如信任)的传统以太(tai)坊钱包工作。

-eth2.io基于短信的加密数字支付方(fang)案——该具体方案采用(yong)托管合同。发送方生成一(yi)个临时的公钥-私钥对，然后发(fa)送给托管契约？存放在以太网中，之前生成的临时(shi)公钥附加到该传输中。私钥用随(sui)机生成的对称密钥加密(mi)，然后密文通过链外手段(e-mail、SMS、Whatsapp等(deng))发送到集中验证服务器。).目前(qian)，如果接收方手机号(hao)验证成功，验证服务器会将密文发(fa)送给接收方，接收方可以解密(即得(de)到临时私钥)，然(ran)后在提现交易报文上签名。然后，托管契约可以验证(zheng)签名，并确认它是由临时(shi)私钥签名的。集中式(shi)服务器用于验证手(shou)机号码和交付密钥，但Eth2的服(fu)务器无法控制托管合(he)同中锁定的以太。如果集中式服务器(qi)被攻击，支付交易将失败，但以太仍在托管合同中。如果此(ci)时想取回锁定的(de)以太，发送方可以通过调用托管合同(tong)取消支付。订阅付费基于选(xuan)择退出的订阅服(fu)务付费是Web2.0时代互联网(wang)服务的主流实现方式。例(li)如，Spotify、网(wang)飞、Headspace和Tinder都是基于订阅(yue)付费建立自己的商业收入模(mo)式。加密货币中订阅支付的(de)概念也不新鲜。在比特币中(zhong)，nLocktime？字段可用于确保已签名的交(jiao)易不会在指定的块高度之前被打(da)包(即消费)。但在以太坊中，用于未来支付的预签名交易(yi)意义不大，因为账户的nonce会(hui)随着账户不断发出交(jiao)易而增加，导致预签(qian)名使用的nonce越小，则交易无效。幸运的(de)是，以太坊的图灵完备性提(ti)供了一个解决方案(an)：对于重复订阅类型的事务(wu)，有一些架构方案。这些架构在利(li)润(流动性)、用户体验的复杂性、可(ke)选功能、气体开(kai)销和可扩展性方面有不同(tong)的权衡。基于Oracle machine的方法调用另一种比较特殊的(de)事务发送方法是使用Oracle machine服(fu)务，比如Oraclize，以便通过(guo)适当的集中化来(lai)换取用气量的减少。可以(yi)看看这篇文章。

-使用Oraclize减(jian)少常量契约调用的gas使用量——这种类型适用于(yu)非事务性(返回(hui)常量)方法调用。已经与以太坊(fang)主网同步的节点可(ke)以通过以太坊JSON-RPC的eth_call接口调用上述方(fang)法。只要继承usingOraclize，就可以使用Oraclize的oraclize_query方法在契约中进行常量查询。此(ci)外，必须在契约中定义_ 尚(shang)力财经小编2022 _ callback (bytes32queryid，string results)的回调函数，Oraclize query将调(diao)用该函数并保存查询(xun)结果。与调用Oraclize相比，直接在链上查询来获取和计算这(zhe)些状态常数的代价可能更大。使(shi)用一次性地址进行多次支付如背景介(jie)绍，交易字段中没有“始发地址”。这(zhe)个地址可以通过ecRecover函数来计算。那么问题来了：我们(men)可以随意在交易签名中填写我们(men)想要的数据吗？事实表明(ming)，一半的签名是(shi)正确的，即ecRecover仍然返回合法的公钥(因此也对应于以(yi)太坊地址)。因(yin)为我们不能控制生成的地址，所以(yi)我们传递设置字段值(zhi)，其实是在构建这样一个交易：该交易可以花费看上去是一个随机生成(cheng)的地址中的余额。如果我们创建了(le)这样一笔交易（发送方是我们(men)想要生成的地址），并给生成的地址充值了若干Ether，那么该笔交易就可以(yi)像一般交易一样执行。这样我们(men)实质上创建了一(yi)个一次性的地址，因为其中(zhong)的余额只能被一笔交易使用。如果我们以某种可预测的方式选择交易(yi)签名中的字段值并公布该笔(bi)交易，我们就可以向任何人证明(ming)，发给交易发送方地(di)址的金额，只能被该笔交(jiao)易使用，而不能被其它任(ren)何交易使用。

如上图所述(shu)，该场景尝试发送交易至11140个目标地址，由(you)一系列发送 Ether 至多个地址的交易组成(cheng)，每个交易发送到 110 个地址，其中发送方的地址(zhi)通过上述方法生成。对于签名字段，我(wo)们填入‘0xDA0DA0DA0…’?，这是一个可预测(ce)的值，这样我们确定，没有人能拿到(dao)这些签名所对应地址的(de)私钥。这尚力财经小编(bian)2022就创建了一批拥有“一次性地(di)址”的交易，这些地址可以(yi)用来给相应交易提供所需交易金额。但 104 个要签名的交易对(dui)于受托自然人而言还是太多了，所以(yi)我们重复一次上述过程，形成一个级联结(jie)构：我们先构造 104 笔交易，每笔交易都有其(qi)对应的唯一地址，然后再(zai)构造一笔发送 Ether到(dao)对应的 104 个地址(zhi)的转账。通过验证，代码确实可以按照(zhao)预期运行，那么任何人就可以这(zhe)些构建好的交易发送到以太坊网络(luo)中，整个过程就像(xiang)多米诺骨牌一样自动进行了：名单上(shang)的 11400 个地址都会(hui)收到 Ether，但我们仅仅用了一(yi)次人工签名。以太坊上完成交易居然有(you)这么多不同的方式！！！如果有什么遗(yi)漏，请告诉我，我会时不(bu)时地更新本文。欢迎在(zai)推特上关注我：https://twitter.com/gawnieg本文来(lai)源：以太坊爱好者Ethfans原文链接:?https://medium.com/coinmonks/the-business-of-sending-transactions-on-ethereum-e79fd9a2b88作者:?Aodhgan Gleeson翻译&校对:?Ray & 阿剑