以太坊区块一直pending

① 我花了46美元在Uniswap上发了一个币

文 | 王也 编辑 | 郝方舟

出品 | Odaily星球日报（ID：o-daily）

Uniswap 带火了 DEX，也打开了“土狗”资金盘的大门。

这两天 Uniswap 上的暴富神话让 DeFi 出了圈。资本热钱纷纷押注去中心化交易所赛道，“三大”在内的 CEX 们也纷纷投身 DeFi，成立专项基金。

随之而来的就是“DEX 革命”、“CEX 必死的”高声呐喊。

但是 Odaily星球日报发现，Uniswap 火热的背后也埋藏着种种危机，诈骗和资金盘横行。

现在的 Uniswap 不比当年的 Uniswap，当年的 Uniswap 是极客和大户热衷的高级游乐场，现在的 Uniswap 被一堆连故事都不会讲、只会拉盘的“土狗”项目方和无脑梭哈的“淘金客”占领，与原本去中心化金融和普惠金融的设定着实不搭。

Odaily星球日报也体验了一把在 Uniswap 发币和上币，将在本文向大家展示现在诈骗和资金盘的作案成本有多低，揭露当前 Uniswap 爆火浪潮下 DEX 埋藏的风险，希望可以对读者起到一定的警示作用。

经过 Odaily星球日报的研究，我们发现在 Uniswap 上发币和上币的门槛极低，如果不将项目方的做市成本计入的话，全程只需 46 美元即可完成。

其实要在 Uniswap 上线一个自己的代币很简单，首先你要先在 Github 上创建一个自己的 ERC-20 token。

第一步，打开 ERC20-Generator，点击 Create a Token（创建一个 Token）。

往下来，你会看到，系统会让你填写关于你创建的 Token 的基本信息：

接着，我们需要耐心地等待交易确认，在这个过程中，我们可以点击 Transaction ID 的链接，跳转到 etherscan 上看一下部署状态，由于当前以太坊网络比较拥堵，目前还处于 Pending（待支付）状态。

当交易确认之后，我们就可以看到我们的 ERC20 Token 的合约地址了。

大概半小时后，属于我们自己的第一个 token 诞生了（难以抑制地激动和兴奋）：DEFI。

全程花费仅 46 美元。

可以看到，我们的 ERC20 Token 对应的智能合约地址为，现在我的钱包里面应该有了一些 DEFI 了，我们在浏览器上点击 MetaMask 图标，在弹出的窗口中，我们点击右上角，然后点击 Expand View，选择添加代币，输入 token 的合约地址。

然后就会出现我们创建的 DEFI token 了。

创建完 ERC-20 token 之后，下一步就是去 Uniswap 上币了。

打开Uniswap，选择 Add Liquidiy 一项，输入 DEFI 的合约地址：，就会出现 DEFI 了。

接下来就是给 DEFI 定价了。

因为 Uniswap 采用自动做市商机制，数学模型为 X*Y=K。X 是 ERC20 代币的数量，Y 是 ETH 数量，K 是常数。X 和 Y 是此消彼长的关系，有人在该合约中购买 ETH，那 X 的数量就会增加。

这个定价机制决定了，买入哪一边的数量多，与之相应的币种价格就会上升。

所以只要有人买入 DEFI，就会助推 DEFI 价格一直上涨。这也是为什么之前一些流通量很小的 DeFi 代币可以一天之内暴涨 40 倍。当时 Compound 就是放了 3000 枚 ETH 和一些 COMP 在池子里，然后就流动起来了。

我们现在把 DEFI 的价格定在了 1 DEFI=0.001 ETH，这样池子就运转起来了。

截止发稿时，ETH/DEFI已有成交单了（不排除有机器人刷单的可能，据Odaily星球日报了解，现在Uniswap上面已经出现了智能跟单机器人，看到有新项目就马上成交）：

分享以上我们在 Uniswap 上发币和上币的过程，并非为了教大家如何发币和上币，而是向大家客观且形象地展示项目方在 Unsiwap 上币的便捷性，以此说明现在资金盘在 Uniswap 上“作案”的成本有多低。

有的 DeFi 代币甚至连故事都不讲，直接以暴涨拉盘的方式吸引韭菜入场。

Uniswap 的欢乐海就是一个超级大赌场。

“新土狗一枚，刚发！“Uniswap 欢乐海社群又来喊单的了……

土狗宣传海报

2017 年的 1CO 降低了发币难度，一纸白皮书就可以发币，之后空气币、传销币和资金盘如“雨后春笋”般爆发，2020 年，以 Uniswap 为首的 DEX 的出现降低了新项目的上所难度，结果，一大波“土狗币”正在向你涌来。

什么是“土狗币”？

“土狗币”源于一个叫做“欢乐海”的微信社区，据称建群一天就满了。推荐的第一期项目 SXY，最高上涨700倍，后大跌92%，险些归零。

欢乐海社群群公告

由于上币简单、缺少审核，Uniswap 上的假币骗局俯拾皆是，投资者把这类国产新币称为“土狗”，不过这些“土狗”大都是"三证齐全"上岗，网站、Discord 和 Telegram 电报群一般是土狗们的三个标配。

Uniswap 欢乐海社群中的散户投资者黄宇（化名）对 Odaily星球日报表示，自己知道这些项目都是骗局，但是进群就是为了搏一搏，他这两天总是听到别人在 Uniswap 上“一万变二十万”故事，希望自己也能成为一个幸运儿。

“富贵在天，干就完了……”

“有新土狗就冲，搞一个以太，就当赌……”

“我就喜欢这样的空气，毫不掩饰……”

看完上面，你可能会感叹：Uniswap 变成了一个赌场！

一个空气项目+DeFi概念+喊单就能在 Uniswap 完成短期的暴涨。

以暴涨 30 倍的 SLP 为例，其本质上是一款宠物养成和战斗类型 游戏 的代币，代币的主要作用是繁殖宠物、购买道具。 游戏 的介绍里虽提及了 DeFi 的概念，但是 游戏 内容实际上却与 DeFi 没有任何关系，而代币 SLP 也并没有太大的价值。

不过虽然如此，经不住项目方的喊单和宣传，玩家们还是一涌而入，希望能够博得数倍的回报，最终导致 SLP 在短短 7 天时间上涨了 30 倍。

过去1个月SLP的价格变化走势

在暴富神话的刺激下，国内外大量的投资者开始成为 Uniswap 淘金客，看到有潜力、有热度的项目就迅速充钱，疯狂程度堪比当年的 1CO。甚至有人揶揄 Uniswap 已经成为一种新的资产发行方式，而不仅仅是一个交易平台，“以前 1CO 有个白皮书装装样子，现在你做个网站，甚至不用做网站，发个币就有人把钱压进去，总之，又是一个看谁跑得快的疯狂 游戏 ”。

大户在挖矿，散户在接盘，最终赚钱的还是跑得快的人。

从七月以来，Uniswap 每天上线的 pool 超过上百个，而最后不被 remove（注：移除）的 pool 不多。

据 dextools 数据显示，在刚刚过去的 1 小时，被 Uniswap remove 的 pool 就有 7 个之多。

DEX 本身就是无许可的，上线 uniswap 的门槛很低，所以需要耐心去调研项目，像 Balancer 有一个白名单机制，这样筛选的 token 就比较靠谱，而 Uniswap 的"三证齐全"并不代表靠谱，投资者们还是应该小心新网站、新推特、新电报，不要轻易重仓碰运气。

据 dForce 创始人杨民道透露，目前他们听到现在市场上有很多骗子正在排队分叉AMPL 及 Uniswap 等等，“这样类型的项目的资金池配比一般都是走最极端的 98/2，如果投资人对在类似 Uniswap 和 Balancer 上做流动性提供的风险不了解，不建议参与。”

“大部分项目都是比谁跑得快，而且之前跑路的项目都有预置后门。对这类分叉币，大家对匿名团队的项目也要格外小心，这类型的项目匿名化，往往就是为跑路暗度陈仓做铺垫的。”杨民道表示。

以 Uniswap 和 Balancer 为代表的 DEX“走红”之后，币圈的项目方和山寨币又开始“妖”了起来，完全不同于上半年的沉寂之态。

据 Uniswap Listing 电报群显示，平均一个小时就有 6 个新项目上线 Uniswap，一天新上线项目高达三四百余个。

相比 CEX，DEX 直接省去了复杂的上币审核流程和天价上币费，而且用户不需要注册，也不需要 KYC 审核，一个 ETH 钱包就可以打通几乎所有的 DEX 和 DeFi 借贷等衍生品平台。

有了 Uniswap 这种免费发币的 DEX 平台，再借着流动性挖矿的火热，很多项目方就直接转战 DEX，前两天我们身边的一位朋友在 Uniswap 上发了一个 token，玩法也借鉴了流动性挖矿的模式。

此外，据 Odaily星球日报了解，许多在二三线 CEX 平台上线的 token，都是在 Uniswap 或是其他 DEX 已经活跃数周甚至数月的项目，上了 CEX 之后，价格变化并不大，甚至有些还跌了，比如流动性挖矿鼻祖 COMP 在上线 OKEx 之后，币价就一直呈现下跌趋势。

币安也上线了很多 DeFi 治理代币，最近上线的 RUNE，MKR，SNX 等 DeFi 明星项目，也已经在 DEX 渡过了价格发现阶段，上了币安之后价格波澜不惊，甚至开始缓步向下。

由此可见，大所效应在这些项目上没有体现出来。

CEX 更严谨的上币策略以及更高的上币费用，使得许多新的优质项目，选择在 DEX 去完成首发——价值发现的萌芽阶段。近期，单是明星项目，UMA、BZRX 首发 Uniswap，mStable 首发 Mesa，大火的 YFI、YFII 主战场均在 Balancer……

甚至就连已经上了 CEX 的币，很多都会选择再去 Uniswap 做一个流动池，比如币安的 IEO 项目 Cartesi 等。而 WANChain 上的 FNX 项目代币，则做了两套代币，一套基于 WANchain，一套基于 ERC-20，方便上 Uniswap。

估计短时间内，这种双代币模式可能会被已经在 CEX 上线的、其他主网代币仿效。

因为降低了新项目的上所门槛，DEX 受到一堆信奉去中心化理论的技术极客的追捧，他们认为 DEX 的出现就是为了要革 CEX 的命。DEX 让 CEX 核心的链下撮合业务回归到链上，这是区块链的一大进步，也是未来交易市场发展的主要趋势。

从 2018 年下半年开始，越来越多的资产回归到链上，例如锚定 ETH 的 WETH，锚定 BTC 的 WBTC，这些资产被挪到链上以后就被赋予了编程和调度的能力。

Uniswap 这类 DEX 也直接让很多三、四线的长尾 CEX 没有了存在的价值。币圈有一个怪现象，就是交易所比投资者多，各种乱七八糟的小交易所层出不穷。在 2018 年初时，就出现过超过一万家交易所的奇异景观。

这些三四线的 CEX 在流动性和安全性往往还不如 DEX，以 Uniswap 和 Balancer 为首的 DEX 在深度和安全性上都远胜这些小交易所。

但是，A coin has two sides，正是因为 DEX 本身就是无许可的，也为其招来了一堆空气币和传销币，当太多人为去中心化金融欢呼时，危险也靠近了……

现在舆论对于 DEX 的态度呈现出两极分化的极端现象，一边是喊着“DEX 革命，CEX 必死”的激进派，另外一边是“DEX 开启新一轮发币潮，即将走向 1CO 下坡路”的保守派，中间是连助记词都不知道是什么的“淘金客”。

除了上文我们提到的骗局太多，DEX 目前还面临着智能合约的安全性等其他无常风险的挑战。

从 bZx 到 dForce 被盗事件，DeFi 智能合约的安全性问题一直在外界所诟病，也是很多散户投资者不敢把资产放到 DeFi 或其他 DEX 平台上的主要原因。

而且现在的 DEX 越来越偏离普惠金融的初衷，更像是大户的赌场。

AMM 的初心是让大家都来提供一下流动性，然后给你奖励，让用户既是用户，又是流动性提供商。正如 POW，初心是每个用户既是用户，又是矿工。

然而到最后，看到比特币 ASIC 矿池把持的结局，便不难想象，AMM 的流动性供应商，也一定会收敛到几个大户或是巨鲸提供者那里，或者换句话说，收敛到资本那里，在大资本面前，散户所能提供的流动池占比，应该是微不足道。

到时候 AMM 的 DEX 想要操控一个币的价格，几个大的流动池一撤走，然后进行少量的买卖行为，就可以对币价造成较大拉升或是砸盘效果。

我们先不去轻言终局，可以肯定的是，这场 DEX 革命确实让散户投资者走进 DeFi，使用 DEX了，也造就了一些币民的暴富神话。

但我们是不是还记得，DEX 存在的初衷是为了打破 CEX 暗箱操作卖假币的局面，让资产真真实实地掌握在用户手中，而不是降低资金盘和传销币的跑路成本。

希望这不是又一个币圈屠龙少年变恶龙的故事。

参考资料：

白话区块链：《去中心化交易平台的崛起，二三线交易平台的尴尬》

深潮TechFlow：《币圈老虎机，Uniswap的红与黑》

② 以太坊源码分析--p2p节点发现

节点发现功能主要涉及 Server Table udp 这几个数据结构，它们有独自的事件响应循环，节点发现功能便是它们互相协作完成的。其中，每个以太坊客户端启动后都会在本地运行一个 Server ，并将网络拓扑中相邻的节点视为 Node ，而 Table 是 Node 的容器， udp 则是负责维持底层的连接。下面重点描述它们中重要的字段和事件循环处理的关键部分。

PrivateKey - 本节点的私钥，用于与其他节点建立时的握手协商
Protocols - 支持的所有上层协议
StaticNodes - 预设的静态 Peer ，节点启动时会首先去向它们发起连接，建立邻居关系
newTransport - 下层传输层实现，定义握手过程中的数据加密解密方式，默认的传输层实现是用 newRLPX() 创建的 rlpx ，这不是本文的重点
ntab - 典型实现是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 与其他节点建立连接时的握手信息，包含本地节点的版本号以及支持的上层协议
addpeer － 连接握手完成后，连接过程通过这个通道通知 Server

Server 的监听循环，启动底层监听socket，当收到连接请求时，Accept后调用 setupConn() 开始连接建立过程

Server的主要事件处理和功能实现循环

Node 唯一表示网络上的一个节点

IP - IP地址
UDP/TCP - 连接使用的UDP/TCP端口号
ID - 以太坊网络中唯一标识一个节点，本质上是一个椭圆曲线公钥(PublicKey)，与 Server 的 PrivateKey 对应。一个节点的IP地址不一定是固定的，但ID是唯一的。
sha - 用于节点间的距离计算

Table 主要用来管理与本节点与其他节点的连接的建立更新删除

bucket - 所有 peer 按与本节点的距离远近放在不同的桶(bucket)中，详见之后的 节点维护
refreshReq - 更新 Table 请求通道

Table 的主要事件循环，主要负责控制 refresh 和 revalidate 过程。
refresh.C - 定时(30s)启动Peer刷新过程的定时器
refreshReq - 接收其他线程投递到 Table 的 刷新Peer连接 的通知，当收到该通知时启动更新，详见之后的 更新邻居关系
revalidate.C - 定时重新检查以连接节点的有效性的定时器，详见之后的 探活检测

udp 负责节点间通信的底层消息控制，是 Table 运行的 Kademlia 协议的底层组件

conn - 底层监听端口的连接
addpending － udp 用来接收 pending 的channel。使用场景为：当我们向其他节点发送数据包后(packet)后可能会期待收到它的回复，pending用来记录一次这种还没有到来的回复。举个例子，当我们发送ping包时，总是期待对方回复pong包。这时就可以将构造一个pending结构，其中包含期待接收的pong包的信息以及对应的callback函数，将这个pengding投递到udp的这个channel。 udp 在收到匹配的pong后，执行预设的callback。
gotreply - udp 用来接收其他节点回复的通道，配合上面的addpending，收到回复后，遍历已有的pending链表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一个 Table

udp 的处理循环，负责控制消息的向上递交和收发控制

udp 的底层接受数据包循环，负责接收其他节点的 packet

以太坊使用 Kademlia 分布式路由存储协议来进行网络拓扑维护，了解该协议建议先阅读 易懂分布式 。更权威的资料可以查看 wiki 。总的来说该协议：

源码中由 Table 结构保存所有 bucket ， bucket 结构如下

节点可以在 entries 和 replacements 互相转化，一个 entries 节点如果 Validate 失败，那么它会被原本将一个原本在 replacements 数组的节点替换。

有效性检测就是利用 ping 消息进行探活操作。 Table.loop() 启动了一个定时器（0~10s），定期随机选择一个bucket，向其 entries 中末尾的节点发送 ping 消息，如果对方回应了 pong ，则探活成功。

Table.loop() 会定期（定时器超时）或不定期（收到refreshReq）地进行更新邻居关系（发现新邻居），两者都调用 doRefresh() 方法，该方法对在网络上查找离自身和三个随机节点最近的若干个节点。

Table 的 lookup() 方法用来实现节点查找目标节点，它的实现就是 Kademlia 协议，通过节点间的接力，一步一步接近目标。

当一个节点启动后，它会首先向配置的静态节点发起连接，发起连接的过程称为 Dial ，源码中通过创建 dialTask 跟踪这个过程

dialTask表示一次向其他节点主动发起连接的任务

在 Server 启动时，会调用 newDialState() 根据预配置的 StaticNodes 初始化一批 dialTask ， 并在 Server.run() 方法中，启动这些这些任务。

Dial 过程需要知道目标节点( dest )的IP地址，如果不知道的话，就要先使用 recolve() 解析出目标的IP地址，怎么解析？就是先要用借助 Kademlia 协议在网络中查找目标节点。

当得到目标节点的IP后，下一步便是建立连接，这是通过 dialTask.dial() 建立连接

连接建立的握手过程分为两个阶段，在在 SetupConn() 中实现
第一阶段为 ECDH密钥建立 ：

第二阶段为协议握手,互相交换支持的上层协议

如果两次握手都通过，dialTask将向 Server 的 addpeer 通道发送 peer 的信息

③ 以太坊一个区块计算时间长

一年3150万秒（365x24x60x60），每产生一个新区快就会奖励5个以太坊。
1、与比特币相反,以太坊并不追踪所有权,而是基于其去中心化计算架构来追踪交易数据(任何数据都可以看作关键值对)。从这个角度看,以太坊区块链是用来同步和存储系统的状态改变。
2、与biteb作对比后我们可以发现,以太坊建立一种新式的加密技术,对于其的程序开发难度与biteb相比要更为简单。这一突破对于应用区块链技术的开发者来说,大大的减轻了开发成本。
3、：有些区块被挖得稍晚一些，因此不能称为主区块链的组成部分。比特币称这类区块为“孤块”，并且完全舍弃它们。但是，以太币称它们为“uncles”，并且在之后的区块中，可以引用它们。如果uncles在之后的区块链中作为叔块被引用，每个叔块会为挖矿者产出大约4.375个以太坊。目前每天有大约500个叔块被创建，每年产量为70万以太坊。

④ 在区块链中以太坊（eth）目前有哪些问题

在区块链中以太坊（eth）目前有哪些问题？
以太坊区块链目前暴露出三大问题，长时间以来其创始人Vitalik
Buterin一直无力解读。第一是以太坊区块链整体很低的性能和TPS；第二是资源不隔离，CryptoKitties虚拟猫咪的事件，一度占据了整个以太坊
20%
的流量，直接造成以太坊网络用户无法展开及时的交易，就是资源不隔离最大的痛点；第三个问题在于以太坊治理结构的体现，区块链作为去中心化的分布式账本，以太坊过去以来，创始人团队主导了其网络发展，过于中心化的治理模式，让目前的以太坊出现了ETH、ETC、ETF等分叉，以太坊社区目前进入四分五裂的治理状态。而以太坊网络目前出现的各种弊病，在「aelf」创始人与CEO马昊伯看来，这是无法接受的。于是，「aelf」定位，就是为对标以太坊的下一代去中心化底层计算平台，重点解决目前以太坊存在的性能不足、资源不隔离、治理结构三方面的问题而诞生的。

⑤ luno发送ETH对方还没确认可以取消吗

luno发送ETH，对方还没确认是可以取消的。如果交易提交了但还没被确认则可以取消。以太坊是一个基于区块链的开源软件平台，拥有数以千计的去中心化应用程序 (DApp)，为其原生加密货币以太 (ETH) 提供支持，可以在全球范围内发送和接收，而不受任何第三方干扰。

取消的操作：

取消待处理的以太坊交易有两种主要方法：应用程序内取消和设置自定义随机数。通常，当用户以较低的 gas 价格提交时，以太坊交易会挂起数小时或卡住。 因此，用户经常发现有必要更改以太坊交易。

在解决这个问题时，用户需要记住只有当交易仍在网络上未决时才能尝试取消。 他们需要采取的第一步是在区块浏览器中验证交易是否仍在等待中。 主要是粘贴交易哈希，也称为以太坊交易 ID，如果区块浏览器显示“待处理”，用户仍然可以尝试取消它。

取消卡住的以太坊交易的最简单方法是应用程序内取消，这需要用户退出以太坊钱包应用程序并关闭浏览器，重新打开并重新登录应用程序。

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

⑦ 以太坊GasLimit的计算方法

以太坊黄皮书上说的gasLimit的计算方法：

gasLimit = Gtransaction + Gtxdatanonzero × dataByteLength

需要注意的是这只是静态的gas消耗，实际gas消耗还需要加上合约执行的开销。

计算 IntrinsicGas的源码位置 core/state_transition.go

相关源码位置：internal/ethapi/api.go

EstimateGas 采用二分查找法获取要评估交易的gas值。二分查找的下限是 param.TxGas , 如果 args 参数指定 Gas 大于 param.Gas ，那么二分查找的上限就是 args.Gas ，否则以当前pending块的block gas limit(后面简称BGL)作为二分查找的上限。 doCall 函数模拟智能合约的执行，经过多次尝试找到智能合约能够成功运行的最佳gas值。

由于二分查找的上限和BGL有关，而BGL和不是固定不变的，因此每次gas评估的结果不一定都是相同的，可能每个区块周期就会变动一次。

在实际进行gas评估的时候，可能会出现类似下面的错误

该错误出现的最可能是合约执行中出错。

How do you calculate gas limit for transaction with data in Ethereum?

⑧ 2021-01-19 记录一次以太坊nonce值的问题

之前在做后端接口的时候，封装了构造交易及发送交易这一层，其中构造交易的时候，获取用户的nonce这里，没有自己维护，而是从链上获取，且之前由于一些业务这里没有做队列，导致前端并发调用的时候，会产生一个账户同时构造两个相同nonce值得交易，最终会导致失败一条。 

Client.PendingNonceAt 是从pending中获取该账户的本次交易改用的nonce，本以为这里已经处理了就没管，不曾想，还是会出现上面的交易重复的bug。

经修改，如果是特殊账户，可在业务层自行维护计数器做nonce值，维护成本较大，且复杂。

第二种  就是这里加个队列，毕竟及时性不是区块链该有的东西。

⑨ 以太坊区块链之Bug --2020/05/19

为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。注意这里的前提条件是相同的地址在相同的节点发送交易。

以下是nonce使用的几条规则：

● 当nonce太小（小于之前已经有交易使用的nonce值），交易会被直接拒绝。

● 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；

● 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。

● 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。

         第一个字段 AccountNonce ，直译就是账户随机数。它是以太坊中很小但也很重要的一个细节。以太坊为每个账户和交易都创建了一个Nonce，当从账户发起交易的时候，当前账户的Nonce值就被作为交易的Nonce。这里，如果是普通账户那么Nonce就是它发出的交易数，如果是合约账户就是从它的创建合约数。

为什么要使用这个Nonce呢？其主要目的就是为了防止重复攻击（Replay Attack）。因为交易都是需要签名的，假定没有Nonce，那么只要交易数据和发起人是确定的，签名就一定是相同的，这样攻击者就能在收到一个交易数据后，重新生成一个完全相同的交易并再次提交，比如A给B发了个交易，因为交易是有签名的，B虽然不能改动这个交易数据，但只要反复提交一模一样的交易数据，就能把A账户的所有资金都转到B手里。

当使用账户Nonce之后，每次发起一个交易，A账户的Nonce值就会增加，当B重新提交时，因为Nonce对不上了，交易就会被拒绝。这样就可以防止重复攻击。当然，事情还没有完，因为还能跨链实施攻击，直到EIP-155引入了chainID，才实现了不同链之间的交易数据不兼容。事实上，Nonce并不能真正防止重复攻击，比如A向B买东西，发起交易T1给B，紧接着又提交另一个交易T2，T2的Gas价格更高、优先级更高将被优先处理，如果恰好T2处理完成后剩余资金已经不足以支付T1，那么T1就会被拒绝。这时如果B已经把东西给了A，那A也就攻击成功了。所以说，就算交易被处理了也还要再等待一定时间，确保生成足够深度的区块，才能保证交易的不可逆。

Price 指的是单位Gas的价格，所谓Gas就是交易的消耗，Price就是单位Gas要消耗多少以太币（Ether），Gas * Price就是处理交易需要消耗多少以太币，它就相当于比特币中的交易手续费。

GasLimit 限定了本次交易允许消耗资源的最高上限，换句话说，以太坊中的交易不可能无限制地消耗资源，这也是以太坊的安全策略之一，防止攻击者恶意占用资源。

Recipient 是交易接收者，它是common.Address指针类型，代表一个地址。这个值也可以是空的，这时在交易执行时，会通过智能合约创建一个地址来完成交易。

Amount 是交易额。这个简单，不用解释。

Payload 比较重要，它是一个字节数组，可以用来作为创建合约的指令数组，这时每个字节都是一个单独的指令；也可以作为数据数组，由合约指令来进行操作。合约由以太坊虚拟机（Ethereum Virtual Machine，EVM）创建并执行。

V、R、S 是交易的签名数据。以太坊当中，交易经过数字签名之后，生成的signature是一个长度65的字节数组，它被截成三段，前32字节被放进R，再32字节放进S，最后1个字节放进V。那么为什么要被截成3段呢？以太坊用的是ECDSA算法，R和S就是ECSDA签名输出，V则是Recovery ID。

R,S,V是交易签名后的值，它们可以被用来生成签名者的公钥；R，S是ECDSA椭圆加密算法的输出值，V是用于恢复结果的ID