在《以太坊實戰之如何正確處理nonce》一文中我們介紹了nonce的基本概念和使用方法。也提到了它能夠覆蓋之前交易的特異功能。但是那只是nonce的冰山一角。今天再給大家分享在熱點賬戶下nonce會出現的問題。
所謂的熱點賬戶就是頻繁被使用的賬戶，在以太坊中比如交易所的統一出幣賬戶，在短時間內頻繁發起交易的賬戶，均可被稱作熱點賬戶。
如果系統中的熱點賬戶或普通賬戶發起交易時出現error: replacement transaction underpriced異常，那麼就需要考慮nonce使用是否正確。
引起此異常原因主要是當乙個賬戶發起一筆交易，假設使用nonce為1，交易已經傳送至節點中，但由於手續費不高或網路擁堵或nonce值過高，此交易處於queued中遲遲未被打包。
同時此位址再發起一筆交易，如果通過eth_gettransactioncount獲取的nonce值與上乙個nonce值相同，用同樣的nonce值再發出交易時，如果手續費高於原來的交易，那麼第一筆交易將會被覆蓋，如果手續費低於原來的交易就會發生上面的異常。
通常發生此異常意味著：
- 你的ethereum客戶端中已經有一幣處於pending狀態的交易。
- 新的一筆交易擁有pending狀態交易相同的nonce值。
- 新的交易的gas price太小，無法覆蓋pending狀態的交易。
通常情況下，覆蓋掉一筆處於pending狀態的交易gas price需要高於原交易的110%。
針對此問題在不同的使用場景下有不同的解決方案。
如果該熱點賬戶的私鑰資訊等都存放在ethereum客戶端中，那麼在傳送交易的時候不傳遞nonce值，ethereum客戶端會幫你處理好此nonce值的排序。
當然，此方案有兩個弊端。第乙個是安全性無法保障（未進行冷熱賬戶分離），第二，在熱點賬戶下如果想覆蓋掉一筆交易，需要先查詢一下該交易的資訊，從中獲取nonce值。
自行管理nonce適用於冷熱賬戶模式，也就是適用sendrawtransaction傳送已經簽名好的交易時，此時nonce值已經存在於交易中，並且已經被簽名。
這種模式下，需要在業務系統中維護nonce的自增序列，適用乙個nonce之後，在業務系統中對nonce進行加一處理。
此種方案也有限制條件。第一，由於nonce統一進行維護，那麼這個位址必須是內部位址，而且發起交易必須通過統一維護的nonce作為出口，否則在其他地方發起交易，原有維護的nonce將會出現混亂。第二，一旦已經發出的交易發生異常，異常交易的nonce未被使用，那麼異常交易的nonce需要重新被使用之後它後面的nonce才會生效。
nonce的使用有很多坑需要踩，大家在具體實踐過程中一旦發現問題需要及時查詢原因，防止大面積的問題發生，導致整個系統的賬務或資金的錯亂。
更多交流技術資訊請掃碼加入知識星球（小密圈）
有關以太坊nonce問題
節點a和節點b集群 節點b連線到節點a 為了防止交易重播，eth etc 節點要求每筆交易必須有乙個nonce數值。每乙個賬戶從同乙個節點發起交易時，這個nonce值從0開始計數，傳送一筆nonce對應加1。當前面的nonce處理完成之後才會處理後面的nonce。集群環境下，不同節點共同維護同乙個使...
geth 以太坊錢包 以太坊錢包Geth使用命令
鏈客，有問必答！一 啟動以太坊錢包geth 開啟乙個控制台，執行同步區塊命令 同步測試鏈 geth fast cache 512 rpc rpcapi personal,db,eth,net,web3 testnet datadir e projecttestgeth 如果為了讓區域網中其他節點訪問...
geth 以太坊錢包 以太坊錢包Geth使用命令
一 啟動以太坊錢包geth 開啟乙個控制台，執行同步區塊命令 同步測試鏈 geth fast cache 512 rpc rpcapi personal,db,eth,net,web3 testnet datadir e project testgeth 如果為了讓區域網中其他節點訪問到服務，請設定...