『壹』 以太坊多节点私有链部署
假设两台电脑A和B
要求：
1、两台电脑要在一个网络中，能ping通
2、两个节点使用相同的创世区块文件
3、禁用ipc;同时使用参数--nodiscover
4、networkid要相同，端口号可以不同
1.4 搭建私有链
1.4.1 创建目录和genesis.json文件
创建私有链根目录./testnet
创建数据存储目录./testnet/data0
创建创世区块配置文件./testnet/genesis.json
1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json
1.4.3 启动私有节点
1.4.4 创建账号
personal.newAccount()
1.4.5 查看账号
eth.accounts
1.4.6 查看账号余额
eth.getBalance(eth.accounts[0])
1.4.7 启动&停止挖矿
启动挖矿：
miner.start(1)
其中 start 的参数表示挖矿使用的线程数。第一次启动挖矿会先生成挖矿所需的 DAG 文件，这个过程有点慢，等进度达到 100% 后，就会开始挖矿，此时屏幕会被挖矿信息刷屏。
停止挖矿，在 console 中输入：
miner.stop()
挖到一个区块会奖励5个以太币，挖矿所得的奖励会进入矿工的账户，这个账户叫做 coinbase，默认情况下 coinbase 是本地账户中的第一个账户，可以通过 miner.setEtherbase() 将其他账户设置成 coinbase。
1.4.8 转账
目前，账户 0 已经挖到了 3 个块的奖励，账户 1 的余额还是0：
我们要从账户 0 向账户 1 转账，所以要先解锁账户 0，才能发起交易：
发送交易，账户 0 -> 账户 1：
需要输入密码 123456
此时如果没有挖矿，用 txpool.status 命令可以看到本地交易池中有一个待确认的交易，可以使用 eth.getBlock("pending", true).transactions 查看当前待确认交易。
使用 miner.start() 命令开始挖矿：
miner.start(1);admin.sleepBlocks(1);miner.stop();
新区块挖出后，挖矿结束，查看账户 1 的余额，已经收到了账户 0 的以太币：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')
用同样的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json
启动私有节点一,修改 rpcport 和port
可以通过 admin.addPeer() 方法连接到其他节点，两个节点要要指定相同的 chainID。
假设有两个节点：节点一和节点二，chainID 都是 1024，通过下面的步骤就可以从节点二连接到节点一。
首先要知道节点一的 enode 信息，在节点一的 JavaScript console 中执行下面的命令查看 enode 信息：
admin.nodeInfo.enode
" enode://@[::]:30303 "
然后在节点二的 JavaScript console 中执行 admin.addPeer()，就可以连接到节点一：
addPeer() 的参数就是节点一的 enode 信息，注意要把 enode 中的 [::] 替换成节点一的 IP 地址。连接成功后，节点一就会开始同步节点二的区块，同步完成后，任意一个节点开始挖矿，另一个节点会自动同步区块，向任意一个节点发送交易，另一个节点也会收到该笔交易。
通过 admin.peers 可以查看连接到的其他节点信息，通过 net.peerCount 可以查看已连接到的节点数量。
除了上面的方法，也可以在启动节点的时候指定 --bootnodes 选项连接到其他节点。 bootnode 是一个轻量级的引导节点，方便联盟链的搭建 下一节讲 通过 bootnode 自动找到节点
参考： https://cloud.tencent.com/developer/article/1332424
『贰』 2021-01-19 记录一次以太坊nonce值的问题
之前在做后端接口的时候，封装了构造交易及发送交易这一层，其中构造交易的时候，获取用户的nonce这里，没有自己维护，而是从链上获取，且之前由于一些业务这里没有做队列，导致前端并发调用的时候，会产生一个账户同时构造两个相同nonce值得交易，最终会导致失败一条。
Client.PendingNonceAt 是从pending中获取该账户的本次交易改用的nonce，本以为这里已经处理了就没管，不曾想，还是会出现上面的交易重复的bug。
经修改，如果是特殊账户，可在业务层自行维护计数器做nonce值，维护成本较大，且复杂。
第二种 就是这里加个队列，毕竟及时性不是区块链该有的东西。
『叁』 以太坊ete转账不到
因为网络有一定的延迟原因,所以会导致转账成功,但是没有到账。
以太坊投资者在某个交易所平台当中进行了以太坊提现，结果发现eth没收到；是一些投资者在进行购入以太坊购买交易过程中，已经按照提示支付了对应的购买价款和手续费，但是却发现eth没收到。网络上所反映的有关“eth没收到”的情况大致就如此，除此之外可能还存在其他的一些与“eth没收到”有关的咨询，但是大致仍然脱离不了这两类范畴。
我们在转账之后，有时会出现转账迟迟未到账的情况，很多用户十分着急，甚至认为自己的币丢失了。Tokenview收到了一封来自昵称为港湾用户的求助邮件。邮件中说，该用户在进行USDT转账时发生了USDT丢失的情况。用户提供了提币地址，交易ID，接收地址以及转账金额和转账时间，问是否可以找回。
『肆』 以太坊转账流程
发起:用户在本地的以太坊钱包软件中选择要发送的交易地址(From)、输入目标地址(To)、金额(Value)、是否部署或调用合(Data)、手续费单价(Gasprice)等,确认发送至以太坊节点节点和钱包可以是同一台
广播:节点收到(或自己发起)交易后,会对交易进行验证。验证:交易的签名、发起账号的余额是否能支付转账余额与手续费、Nonce是否为账号已发出的交易数。验证为合法后,将交易加入节点的交易池中交易池中存储着待打包的交
安装以太坊浏览器钱包插件,创建钱包,获取虚拟以太币,进行转账交易。 实验内容 学习 初识以太坊,发送交易 1.学习《初始以太坊,发送交易》,虚拟以太币交易。
『伍』 别人转账给我，结果显示资金冻结了24小时后，等待账户自动恢复，该怎么办
日常生活中的转账和区块链转账有着本质上的不同，这种不同造成了区块链转账状态理解上的复杂。
我们会看到「等待确认」「确认中」「交易失败」「成功」等状态，其中有些属于区块链转账的特有状态。
银行转账
日常生活中的转账往往有两个步骤：支付和清算。
平常我们通过支付宝消费、银行卡转账，都属于「支付」，本质是信息的记录，记下一个债权债务凭证。而这种凭证需要被落实，也就是「清算」，本质是资金的流动。
一个常见的情形：
从我的招行卡往你的工行卡上转账 200 块。
这个过程有两个步骤：
当我成功转给你 200 块，这一步对你和我来说是「支付」，本质是信息流；对招行和工行而言，则是建立债权债务关系，它记了一张欠条：招行欠工行 200 块。
然后是银行们定期在央行清算系统中落实彼此间复杂的债权关系（第一步中的「招行欠工行 200 块」是千丝万缕之一）。这时，就是通过「清算」将信息流变成了真实的资金流。
对我们来说，第一步中转账按钮一确定，你放心我也放心。可实际到这里，只是第一步，往后真正耗时的操作无声无息地隐藏在整个金融基础设施和系统的周期运转中。它们不为常人道，却是我们便利金融生活的基石。
Photo by José Martín Ramírez C on Unsplash
区块链转账
它有支付和清算吗？这个概念其实在这里不存在了。区块链转账将这两步骤合二为一，链上的每一笔转账都记录着真实的资金流动。
区块链作为一个公共账本，公开透明，不可篡改。
也正因此，在它上面的转账有更复杂的状态，这个账本不容有错，必须谨慎记录。
所以我们看到这些状态：「等待确认」「确认中」「交易失败」与「成功」
「等待确认」：等待矿工确认转账信息，打包到区块中；
「确认中」：一个区块确认不够安全，需要多些确认，这样我们就能理解为什么以太坊转账需要 12 个区块确认才算作成功；
「交易失败」：如果你给的矿工费不够，不足以让矿工确认转账信息，就会失败（也可能是其他原因导致）；
「成功」：此时，你的转账记录就在区块链账本上，不可篡改，记录可查。
『陆』 以太坊转帐二十小时没到帐
新手第一次转以太坊难免会紧张，因为不清楚以太坊转账多久到账，所以每一秒的等待都是焦急的。以太坊转账的网络速度比较快，因为以太坊网络解决了比特币网络中扩展性不足的问题，以太坊网络也比比特币网络速度快。通常情况下以太坊转账只需要几分钟就可以到账。若是你进行以太坊转账迟迟没有收到到账信息，你可以咨询客服，或者自己查找是不是其中某个流程出现了错误。不论是转比特币还是以太坊，都需要手续费。因为手续费是给矿工的一种鼓励，也是对矿工电费的一种补偿。矿工们要确认每一笔交易很不容易，所以他们也需要报酬
『柒』 以太坊转币失败
交易未被打包不会扣除矿工费，绝大多数未被打包的情况是矿工费设置的过低导致的。
转账失败大致分为两种情况：一种情况是交易未被打包导致转账失败，另外一种情况是交易在打包的过程中发生了错误导致交易失败。
转账时设置合适的矿工费。在imToken2。0国际版中，设置矿工费的滑动杆最大值和最小值都是从以太坊网络实时获取的，推荐的矿工费就是能够保证你这笔交易成功的最小值，所以只要按照App内部推荐的矿工费数值设置就可以了。
『捌』 以太坊ETH覆盖或删除处于pending状态交易
有人肯定遇到跟我一样的问题，账号里还有一些eth，但是有一笔交易一直处于pending状态，导致后续的交易全部卡死。除非这一笔pending状态的交易被矿工打包。请注意nonce，由于每一个账号的每一个交易nonce都是递增的，因此如果用已经成功的交易的nonce重新交易，一定会报错nonce too low。
1、发现有一笔订单一直处于pending状态，后续的所有交易都不能正常进行
2、解决方案，通过设置较高的gasprice来覆盖或替换该交易
3、接下来，该账号就可以正常转账啦。
目前市场上尚未找到能满足该功能的工具/钱包，如需提供技术服务，请联系作者，微信号：hqfeijian ，备注：以太坊替换交易
『玖』 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网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。
『拾』 跨行转账整整8天了仍未到帐，也没退款
我们在转账之后，有时会出现转账迟迟未到账的情况，很多用户十分着急，甚至认为自己的币丢失了。Tokenview收到了一封来自昵称为港湾用户的求助邮件。邮件中说，该用户在进行USDT转账时发生了USDT丢失的情况。用户提供了提币地址，交易ID，接收地址以及转账金额和转账时间，问是否可以找回。
首先，我们需要先确定没到账的原因。一般来说，转账没到账的原因有四个：
1、地址填错
2、网络拥堵，暂未到账
3、确认数未达标，暂未入账
4、手续费不足，交易被退回
我们一个个来分析。如果是第一种情况，地址填错。地址填错大约分二种情况，第一种情况是地址种类填错，或者格式错误。这种情况下，转账可能无法顺利进行，相应的钱包软件会进行提示，如果交易不能发起，也就不存在丢币的情况。但在种类填错的情况下也不是不可能发起交易的。举例来说，如果我们把USDT—OMNI提现到了USDT-ERC20，就会丢币，这样丢失的币是无法找回的。第二种情况就是地址张冠李戴，是对应的链上地址，但是错填成他人地址。这种情况交易将会顺利发起，而此时交易上链后，基于区块链不可逆的特性，任何人都无法对该笔交易进行撤回操作，除非接收方原因将币转回原地址。
如何判断接收地址是否填写错误呢？我们复制交易ID，或者直接复制自己的转出地址，通过Tokenview区块浏览器进行查询。我们通过查询该用户提供的交易ID，可以发现，该用户进行了火币的一笔提现操作，其转入地址与用户提供的转入地址不符，也就是说，出于某种原因，用户将USDT转去了错误的地址。
这种情况下，交易将是无法撤回的，除非改接收地址的持有人愿意将这笔“天降之财”原路退回。但由于区块链的匿名性，除了Tokenview标记出的交易所出入金地址及某些大户地址外，其余BTC、USDT地址我们是无法通过地址哈希定位其所有人的，因此可以说，在这种情况下，找回币的几率微乎其微。
第二种情况是网络拥堵。这种情况我们能做的就是等待交易打包上链。我们可以在tokenview.com的Pending交易池中看看交易是否存在。如：https://btc.tokenview.com/cn/pending。
第三种情况一般存在于交易平台充币。当交易上链时，确认数为1，但由于不同交易所对确认数的要求不同，例如大部分对比特币的确认数要求要达到6才会被确认充值成功，而以太坊则是12个。我们可以通过tokenview.com来查询交易数。如果交易数还没有达到要求，我们还需要再耐心等一下。
最后一种情况是手续费不足，交易被退回。这种情况交易会失败。拿以太坊的转账为例，如果手续费不足，此交易将扣取手续费，并将ETH退回到转出地址，并不存在丢币的情况。
转账未到账的几种情况我们已经介绍完毕了。其中最关键的是大家在转账之前一定要再三确认交易地址是否填写无误。如果是进行USDT的转账，一定要确认其USDT类型。是OMNI，还是ERC20，还是TRC20，避免发生填错类型而丢币的意外，从而造成损失。