eth打包查询

A. 以太坊ETH覆盖或删除处于pending状态交易

有人肯定遇到跟我一样的问题，账号里还有一些eth，但是有一笔交易一直处于pending状态，导致后续的交易全部卡死。除非这一笔pending状态的交易被矿工打包。请注意nonce，由于每一个账号的每一个交易nonce都是递增的，因此如果用已经成功的交易的nonce重新交易，一定会报错nonce too low。

1、发现有一笔订单一直处于pending状态，后续的所有交易都不能正常进行

2、解决方案，通过设置较高的gasprice来覆盖或替换该交易

3、接下来，该账号就可以正常转账啦。

目前市场上尚未找到能满足该功能的工具/钱包，如需提供技术服务，请联系作者，微信号：hqfeijian ，备注：以太坊替换交易

B. 如何批量查询ETH或ERC20代币钱包地址余额

批量查询ETH或ERC20代币钱包地址

1，打开连接工具地址： https://www.ztpay.org/tool.html

2，复制地址到输入框，一行一个地址；如下图

3、输入地址点击开始查询，最终结果只显示有余额的地址

C. 以太坊怎么查询账户使用的gas

调用 estimateGas 确实会返回一个 gas 耗费量,但这是该笔交易在当前状态下被打包会花费的 gas 量。

D. 用Go来做以太坊开发⑤事件日志

智能合约具有在执行期间“发出”事件的能力。 事件在以太坊中也称为“日志”。 事件的输出存储在日志部分下的事务处理中。 事件已经在以太坊智能合约中被广泛使用，以便在发生相对重要的动作时记录，特别是在代币合约（即ERC-20）中，以指示代币转账已经发生。 这些部分将引导您完成从区块链中读取事件以及订阅事件的过程，以便交易事务被矿工打包入块的时候及时收到通知。

为了订阅事件日志，我们需要做的第一件事就是拨打启用websocket的以太坊客户端。 幸运的是，Infura支持websockets。

下一步是创建筛选查询。 在这个例子中，我们将阅读来自我们在之前课程中创建的示例合约中的所有事件。

我们接收事件的方式是通过Go channel。 让我们从go-ethereum core/types 包创建一个类型为 Log 的channel。

现在我们所要做的就是通过从客户端调用 SubscribeFilterLogs 来订阅，它接收查询选项和输出通道。 这将返回包含unsubscribe和error方法的订阅结构。

最后，我们要做的就是使用select语句设置一个连续循环来读入新的日志事件或订阅错误。

我们会在下个章节介绍如何解析日志。

Commands

Store.sol

event_subscribe.go

智能合约可以可选地释放“事件”，其作为交易收据的一部分存储日志。读取这些事件相当简单。首先我们需要构造一个过滤查询。我们从go-ethereum包中导入 FilterQuery 结构体并用过滤选项初始化它。我们告诉它我们想过滤的区块范围并指定从中读取此日志的合约地址。在示例中，我们将从在 智能合约章节 创建的智能合约中读取特定区块所有日志。

下一步是调用ethclient的 FilterLogs ，它接收我们的查询并将返回所有的匹配事件日志。

返回的所有日志将是ABI编码，因此它们本身不会非常易读。为了解码日志，我们需要导入我们智能合约的ABI。为此，我们导入编译好的智能合约Go包，它将包含名称格式为 <Contract>ABI 的外部属性。之后，我们使用go-ethereum中的 accounts/abi 包的 abi.JSON 函数返回一个我们可以在Go应用程序中使用的解析过的ABI接口。

现在我们可以通过日志进行迭代并将它们解码为我么可以使用的类型。若您回忆起我们的样例合约释放的日志在Solidity中是类型为 bytes32 ，那么Go中的等价物将是 [32]byte 。我们可以使用这些类型创建一个匿名结构体，并将指针作为第一个参数传递给解析后的ABI接口的 Unpack 函数，以解码原始的日志数据。第二个参数是我们尝试解码的事件名称，最后一个参数是编码的日志数据。

此外，日志结构体包含附加信息，例如，区块摘要，区块号和交易摘要。

若您的solidity事件包含 indexed 事件类型，那么它们将成为 主题 而不是日志的数据属性的一部分。在solidity中您最多只能有4个主题，但只有3个可索引的事件类型。第一个主题总是事件的签名。我们的示例合约不包含可索引的事件，但如果它确实包含，这是如何读取事件主题。

正如您所见，首个主题只是被哈希过的事件签名。

这就是阅读和解析日志的全部内容。要学习如何订阅日志，阅读上个章节。

命令

Store.sol

event_read.go

首先，创建ERC-20智能合约的事件日志的interface文件 erc20.sol :

然后在给定abi使用 abigen 创建Go包

现在在我们的Go应用程序中，让我们创建与ERC-20事件日志签名类型相匹配的结构类型：

初始化以太坊客户端

按照ERC-20智能合约地址和所需的块范围创建一个“FilterQuery”。这个例子我们会用 ZRX 代币:

用 FilterLogs 来过滤日志：

接下来我们将解析JSON abi，稍后我们将使用解压缩原始日志数据：

为了按某种日志类型进行过滤，我们需要弄清楚每个事件日志函数签名的keccak256哈希值。 事件日志函数签名哈希始终是 topic [0] ，我们很快就会看到。 以下是使用go-ethereum crypto 包计算keccak256哈希的方法：

现在我们将遍历所有日志并设置switch语句以按事件日志类型进行过滤：

现在要解析 Transfer 事件日志，我们将使用 abi.Unpack 将原始日志数据解析为我们的日志类型结构。 解包不会解析 indexed 事件类型，因为它们存储在 topics 下，所以对于那些我们必须单独解析，如下例所示：

Approval 日志也是类似的方法：

最后，把所有的步骤放一起：

我们可以把解析的日志与etherscan的数据对比: https://etherscan.io/tx/#eventlog

Commands

erc20.sol

event_read_erc20.go

solc version used for these examples

要读取 0x Protocol 事件日志，我们必须首先将solidity智能合约编译为一个Go包。

安装solc版本 0.4.11

为例如 Exchange.sol 的事件日志创建0x Protocol交易所智能合约接口:

Create the 0x protocol exchange smart contract interface for event logs as Exchange.sol :

接着给定abi，使用 abigen 来创建Go exchange 包：

Then use abigen to create the Go exchange package given the abi:

现在在我们的Go应用程序中，让我们创建与0xProtocol事件日志签名类型匹配的结构体类型：

初始化以太坊客户端：

创建一个 FilterQuery ，并为其传递0x Protocol智能合约地址和所需的区块范围：

用 FilterLogs 查询日志：

接下来我们将解析JSON abi，我们后续将使用解压缩原始日志数据：

为了按某种日志类型过滤，我们需要知晓每个事件日志函数签名的keccak256摘要。正如我们很快所见到的那样，事件日志函数签名摘要总是 topic[0] ：

现在我们迭代所有的日志并设置一个switch语句来按事件日志类型过滤：

现在要解析 LogFill ，我们将使用 abi.Unpack 将原始数据类型解析为我们自定义的日志类型结构体。Unpack不会解析 indexed 事件类型，因为这些它们存储在 topics 下，所以对于那些我们必须单独解析，如下例所示：

对于 LogCancel 类似：

最后是 LogError ：

将它们放在一起并运行我们将看到以下输出：

将解析后的日志输出与etherscan上的内容进行比较： https://etherscan.io/tx/

命令

Exchange.sol

event_read_0xprotocol.go

这些示例使用的solc版本

E. ETH发错了钱包地址可以找回吗

可以。

ETH发错了钱包地址是可以找回的。找回是需要联系工作人员，反馈后让工作人员协助找回，这种情况是需要时间进行找回的，需要提供大量的交易过程信息。

但是要注意的是一般自充出现这种情况平台是不负责找回的，但是联系工作人员如果充值时间较短，处理简单的话一般是可以找回的，但需要花费一定的时间以及人力和物力。

(5)eth打包查询扩展阅读：

如ETH等，充值错了币种，需要去咨询平台那边，看能否找回。每个平台都掌控了所有充值地址的私钥，如果转账完成了，那币肯定是在充值地址里面，主要看平台是否愿意帮找回。

小额的平台大概率是不会愿意的，因为涉及到导出私钥等，风险很大，所以充值前一定要仔细看清楚。如果自己转币转错地址了的。比如BCH转到BTC地址里面去了，实际上把那个比特币地址的私钥导入BCH钱包就可以了，其他的币也是类似。

如果是转到错误的地址了，如ETH转账转到别人的地址了，可以先去查看这笔转账有没有被确认，矿工是否已经打包。如果矿工已经将交易打包完毕，ETH已经从你的钱包中转出了，那么交易是无法撤销的。

F. eth打包中多久会失败

1、交易送出后会被丢到一个交易池中等待被矿工打包，决定先后顺序的主要因子为单位GasPrice（GWEI）给的多寡。
2、发送交易时可以到ETHgasstation参考即时的交易池状况再来决定要设多少GWEI以能在预期的时间内被打包上链。
3、若发现交易持续滞留在交易池中等待被处理，可以加速交易或取消交易。

G. 【ETH钱包开发03】web3j转账ETH

在之前的文章中，讲解了创建、导出、导入钱包。
【ETH钱包开发01】创建、导出钱包
【ETH钱包开发02】导入钱包

本文主要讲解以太坊转账相关的一些知识。交易分为ETH转账和ERC-20 Token转账，本篇先讲一下ETH转账。

1、解锁账户发起交易。钱包keyStore文件保存在geth节点上，用户发起交易需要解锁账户，适用于中心化的交易所。

2、钱包文件离线签名发起交易。钱包keyStore文件保存在本地，用户使用密码+keystore的方式做离线交易签名来发起交易，适用于dapp，比如钱包。

本文主要讲一下第二种方式，也就是钱包离线签名转账的方式。

交易流程
1、通过keystore加载转账所需的凭证Credentials
2、创建一笔交易RawTransaction
3、使用Credentials对象对交易签名
4、发起交易

注意以下几点：

1、Credentials
这里，我是通过获取私钥的方式来加载 Credentials

还有另外一种方式，通过密码+钱包文件keystore方式来加载 Credentials

2、nonce

nonce是指发起交易的账户下的交易笔数，每一个账户nonce都是从0开始，当nonce为0的交易处理完之后，才会处理nonce为1的交易，并依次加1的交易才会被处理。

可以通过 eth_gettransactioncount 获取nonce

3、gasPrice和gasLimit
交易手续费由gasPrice 和gasLimit来决定，实际花费的交易手续费是 gasUsed * gasPrice 。所有这两个值你可以自定义，也可以使用系统参数获取当前两个值

关于 gas ，你可以参考我之前的一篇文章。
以太坊（ETH）GAS详解

gasPrice和gasLimit影响的是转账的速度，如果gas过低，矿工会最后才打包你的交易。在app中，通常给定一个默认值，并且允许用户自己选择手续费。

如果不需要自定义的话，还有一种方式来获取。获取以太坊网络最新一笔交易的 gasPrice ,转账的话， gasLimit 一般设置为21000就可以了。

Web3j还提供另外一种简单的方式来转账以太币,这种方式的好处是不需要管理nonce，不需要设置gasPrice和gasLimit，会自动获取最新一笔交易的gasPrice，gasLimit 为21000（转账一般设置成这个值就够用了）。

这个问题，我想是很多朋友所关心的吧。但是到目前为止，我还没有看到有讲解这方面的博客。

之前问过一些朋友，他们说可以通过区块号、区块哈希来判断，也可以通过Receipt日志来判断。但是经过我的一番尝试，只有 BlockHash 是可行的，在web3j中根据 blocknumber 和 transactionReceipt 都会报空指针异常。

原因大致是这样的：在发起一笔交易之后，会返回 txHash ，然后我们可以根据这个 txHash 去查询这笔交易相关的信息。但是刚发起交易的时候，由于手续费问题或者以太网络拥堵问题，会导致你的这笔交易还没有被矿工打包进区块，因此一开始是查不到的，通常需要几十秒甚至更长的时间才能获取到结果。我目前的解决方案是轮询的去刷 BlockHash ，一开始的时候 BlockHash 的值为0x00000000000，等到打包成功的时候就不再是0了。

这里我使用的是rxjava的方式去轮询刷的，5s刷新一次。

正常情况下，几十秒内就可以获取到区块信息了。

区块确认数=当前区块高度-交易被打包时的区块高度。

H. ETH 查询某个钱包的所有代币以及地址

思路：

1、获取钱包W的所有交易记录

2、把from、to记录到数组A中

3、根据ABI规则，input去掉前面8字符大小的方法名，剩下的依次按64字符进行分割，得到参数列表。因为地址都是居右的，所以取出居右的参数后，对比ETH地址长度，一致则存到数组A中待用

4、遍历数组A，调用ERC20的标准合约方法symbol、decimals，如果都存在则表示该元素为代币，将塔存到数组B待用

5、遍历数组B，调用ERC20合约方法balanceOf获取代币余额，存到数组C中

6、此时，我们就成功获取到钱包W的所有代币B，及其余额C

2022年02月15日

I. 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网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。

J. weth代币合约地址怎样查询

打开浏览器输入地址：https://etherscan.io/在右上角的方框内输入你要查询的合约地址，输入地址后点击“GO”。
含义与以太坊网络的原生代币以太币(ETH)可以进行互换,可以将1ETH兑换为1WETH,同时也可以将1WETH兑换回1ETH,兑换是基于智能合约完成的。 Golff支持使用WETH挖GOF,所以用户需要提前准备好WETH。