ETH开发实践——批量发送交易

各位老铁们，大家好，今天由我来为大家分享ETH开发实践——批量发送交易，以及怎么查询ETH交易查询的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！

本文目录

1. 什么交易所能交易weth
2. 钱包有ETH但交易无法确认的原因是什么呢
3. ETH开发实践——批量发送交易

什么交易所能交易weth

RadarRelay交易所平台能够交易，weth是一种符合标准的ERC-20以太坊数字平台代币，可以和以太坊的ETH以太币进行智能合约完成的等量互换。因为ERC-20创建的时候ETH已经创建完毕了，两种平台代币的不兼容，于是便有了后来完善过后的WETH币，两个平台和平台的代币互相兼容。WETH币横空出世后，平台用户可以在各种平台所建立的去中心化平台上直接使用ETH币与其他的平台代币进行交易。货币是度量价格的工具、购买货物的媒介、保存财富的手段，是财产的所有者与市场关于交换权的契约，本质上是所有者之间的约定。它反映的是个体与社会的经济协作关系。货币的契约本质决定了它可以有不同的表现形式，比如一般等价物、贵金属货币、纸币、电子货币等。

拓展资料

货币本质

货币，就其本质而言，是所有者之间关于交换权的契约，不同形式的货币在本质上统一的。过去，由于人们对货币的本质认识不清，错误地从不同角度来将货币分为不同的种类，比如：根据货币的商品价值分为债务货币与非债务货币两大类，根据是否约定贵金属的兑换比例分为可兑换货币和不可兑换货币等等。

形式上，根据货币的商品价值可分为实物货币和形式货币，实物货币本身是一种特殊的商品，包含价值量，比如羊、贵金属等；而形式货币本身没有价值量，它的价值是契约约定的，只有契约价值。两者形式不同，但是本质上是统一的，即都被约定作为交换媒介，都存在契约价值。货币的购买力决定于货币的契约价值，但实物货币的购买力也会受到自身商品价值的影响，通常实物货币的商品价值小于其作为货币的契约价值。

高中教科书当中，货币的本质被解释为一般等价物。这个定义仅仅从职能出发，实际上没有说明货币的本质，也无法回答内在的逻辑问题，即货币为什么可以充当一般等价物。

钱包有ETH但交易无法确认的原因是什么呢

钱包有ETH但交易无法确认的原因如下：1.第一种原因是交易 Gas已用尽(Out of Gas)，简单说，这笔交易的计算量超过了用户所设定的 Gas Limit，并且用户所支付的 Gas不会被退还。2.第二种原因是当用户向智能合约发起交易转账，由于某些错误导致无法执行合约时，交易会返回 Bad Instruction。比如额度已满、用户未被列入白名单、用户超额认购代币等情况。3.第三种原因是用户钱包中 ETH的数量不足以支付 Gas费用时，交易也会被判定为失败。

我们通过以上关于钱包有ETH但交易无法确认的原因是什么呢内容介绍后,相信大家会对钱包有ETH但交易无法确认的原因是什么呢有一定的了解,更希望可以对你有所帮助。

ETH开发实践——批量发送交易

在使用同一个地址连续发送交易时，每笔交易往往不可能立即到账，当前交易还未到账的情况下，下一笔交易无论是通过 eth.getTransactionCount()获取nonce值来设置，还是由节点自动从区块中查询，都会获得和前一笔交易同样的nonce值，这时节点就会报错 Error: replacement transaction underpriced

在构建一笔新的交易时，在交易数据结构中会产生一个nonce值， nonce是当前区块链下，发送者(from地址)发出的交易(成功记录进区块的)总数，再加上1。例如新构建一笔从A发往B的交易，A地址之前的交易次数为10，那么这笔交易中的nonce则会设置成11，节点验证通过后则会放入交易池（txPool）,并向其他节点广播，该笔交易等待矿工将其打包进新的区块。

那么，如果在先构建并发送了一笔从地址A发出的，nonce为11的交易，在该交易未打包进区块之前，再次构建一笔从A发出的交易，并将它发送到节点，不管是先通过web3的eth.getTransactionCount(A)获取到的过往的交易数量，还是由节点自行填写nonce，后面的这笔交易的nonce同样是11，此时就出现了问题：

实际场景中，会有批量从一个地址发送交易的需求，首先这些操作可能也应该是并行的，我们不会等待一笔交易成功写入区块后再发起第二笔交易，那么此时有什么好的解决办法呢？先来看看geth节点中交易池对交易的处理流程

如之前所说，构建一笔交易时如果不手动设置nonce值，geth节点会默认计算发起地址此前最大nonce数（写入区块的才算数），然后将其加上1，然后将这笔交易放入节点交易池中的pending队列，等到节点将其打包进区块。

构建交易时，nonce值是可以手动设置的，如果当前的nonce本应该设置成11，但是我手动设置成了13，在节点收到这笔交易时，发现pending队列中并没有改地址下nonce为11及12的交易，就会将这笔nonce为13的交易放入交易池的queued队列中。只有当前面的nonce补齐（nonce为11及12的交易被发现并放入pending队列）之后，才会将它放入pending队列中等待打包。

我们把pending队列中的交易视为可执行的，因为它们可能被矿工打包进最新的区块。而queue队列因为前面的nonce存在缺失，暂时无法被矿工打包，称为不可执行交易。

那么实际开发中，批量从一个地址发送交易时，应该怎么办呢？

方案一：那么在批量从一个地址发送交易时，可以持久化一个本地的nonce，构建交易时用本地的nonce去累加，逐一填充到后面的交易。（要注意本地的nonce可能会出现偏差，可能需要定期从区块中重新获取nonce，更新至本地）。这个方法也有一定的局限性，适合内部地址（即只有这个服务会使用该地址发送交易）。

说到这里还有个坑，许多人认为通过 eth.getTransactionCount(address,”pending”)，第二个参数为 pending，就能获得包含本地交易池pending队列的nonce值，但是实际情况并不是这样，这里的 pending只包含待放入打包区块的交易，假设已写入交易区块的数量为20，又发送了nonce为21，22，23的交易，通过上面方法取得nonce可能是21（前面的21，22，23均未放入待打包区块），也可能是22（前面的21放入待打包区块了，但是22，23还未放入）。

方案二是每次构建交易时，从geth节点的pending队列取到最后一笔可执行交易的nonce,在此基础上加1，再发送给节点。可以通过 txpool.content或 txpool.inspect来获得交易池列表，里面可以看到pending及queue的交易列表。

启动节点时，是可以设置交易池中的每个地址的pending队列的容量上限，queue队列的上容量上限，以及整个交易池的pending队列和queue队列的容量上限。所以高并发的批量交易中，需要增加节点的交易池容量。

当然，除了扩大交易池，控制发送频率，更要设置合理的交易手续费，eth上交易写入区块的速度取决于手续费及eth网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。

OK，本文到此结束，希望对大家有所帮助。