以太坊區塊一直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