eth地址批量生成源碼

A. 如何用linux建立eth1

cp ifcfg-eth0 ifcfg-eth1
然後 vi ifcfg-eth1
按照 裡面的 參數 設置 就可以

最簡單 方法 如果你有 安裝upset
用upset吧

B. 比特派 ETH、ERC20 Token 批量轉賬教程，好用！

功能簡介：

比特派的批量轉賬功能可以將你的ETH或ERC20的TOKEN 同時發送到多個地址（當前最多支持255個）。

優勢：

節省操作時間，節省礦工費。

操作教程：

1、打開比特派，在左上角切換到「ETH體系」點擊 「批量轉賬」

2、進入操作頁面後，首先確認自己用來付款的的幣種、地址。然後點擊加號【+】來添加收款方信息。

3、你可以選擇【從剪貼板獲取】或者【手動輸入】收款方信息。

當你選擇從剪貼板獲取時：

你需要按固定格式提前復制好相關內容，再點擊此按鈕才可添加成功。

格式為：

地址,金額 （地址和金額之間用英文的逗號分隔，多組信息之間需要換行）

例如：

0xc35f4f66ef......20db8f7d , 0.001

0xfe4503c78......4e4ae1ae , 0.002

如果您要處理的地址較多，建議使用電腦表格軟體進行整理，格式如下。

當你整理的地址在表格內顯示異常時，選中所有異常的表格，右鍵選擇單元格格式，並將單元格格式選擇文本。（不同的軟體操作步驟略有差異，核心操作在於將單元格文本格式選擇成文本。）

整理完成後，可通過微信等其他軟體將內容發送到手機並復制，打開批量轉賬頁面點擊加號+，選擇從剪貼板復制，即可批量添加收款信息。

當你選擇手動輸入時：

可以手動輸入地址、金額。也可以通過掃碼、地址簿添加等方式添加地址。

4、地址信息添加完成並確認無誤後，點擊確認轉賬，核對好相關信息後點擊確認，即可發出。等待合約確認後，便可查看所有的轉賬詳情。

C. 我想用JavaScript寫一個ETH私鑰生成器，有沒有大神提供一下思路

作為業內人士，不鼓勵或支持編寫任何涉沒兄及加密貨幣的應用程序，因為這涉及到用戶隱私和資金安全等問題。此外，ETH私鑰生成器是一個非常敏感的應用程序，需要非常謹慎和謹慎地處理。如果您對加密貨幣的技術不熟悉或不了解ETH私鑰的生成和管理方式，請不要輕易嘗試編寫此類應用程序。
如果您仍然想編寫ETH私鑰生成器，建議您遵循以下步驟:
1. 確定您的技術能力和知識枯銷襲水平，了解JavaScript語言和ETH私鑰的生成演算法。
2. 學習使用JavaScript生成隨機數和哈希函數，以生成隨機的私鑰。注意要使用可靠的隨機數生成器和安全的斗散哈希演算法。
3. 學習使用ETH錢包庫，如web3.js或ethers.js，來管理私鑰和與以太坊網路的交互。這些庫提供了豐富的API和工具，可以輕松地處理ETH私鑰和交易等問題。
4.在研究ETH私鑰的安全和保護問題，如如何存儲和備份私鑰，如何加密和解密私鑰等。確保您的代碼和用戶數據得到充分的保護。
最後，我想再次強調，編寫ETH私鑰生成器是一個非常復雜和敏感的任務，需要非常謹慎和謹慎地處理。如果您不熟悉加密貨幣的技術或沒有足夠的經驗和知識，建議您不要嘗試編寫此類應用程序。同時，使用加密貨幣時請務必注意風險和安全問題，採取必要的措施來保護您的私鑰和資產。

D. 【深度知識】以太坊數據序列化RLP編碼/解碼原理

RLP(Recursive Length Prefix)，中文翻譯過來叫遞歸長度前綴編碼，它是以太坊序列化所採用的編碼方式。RLP主要用於以太坊中數據的網路傳輸和持久化存儲。

對象序列化方法有很多種，常見的像JSON編碼，但是JSON有個明顯的缺點：編碼結果比較大。例如有如下的結構：

變數s序列化的結果是{"name":"icattlecoder","sex":"male"},字元串長度35，實際有效數據是icattlecoder 和male，共計16個位元組，我們可以看到JSON的序列化時引入了太多的冗餘信息。假設以太坊採用JSON來序列化，那麼本來50GB的區塊鏈可能現在就要100GB，當然實際沒這么簡單。

所以，以太坊需要設計一種結果更小的編碼方法。

RLP編碼的定義只處理兩類數據：一類是字元串（例如位元組數組），一類是列表。字元串指的是一串二進制數據，列表是一個嵌套遞歸的結構，裡面可以包含字元串和列表，例如["cat",["puppy","cow"],"horse",[[]],"pig",[""],"sheep"]就是一個復雜的列表。其他類型的數據需要轉成以上的兩類，轉換的規則不是RLP編碼定義的，可以根據自己的規則轉換，例如struct可以轉成列表，int可以轉成二進制（屬於字元串一類），以太坊中整數都以大端形式存儲。

從RLP編碼的名字可以看出它的特點：一個是遞歸，被編碼的數據是遞歸的結構，編碼演算法也是遞歸進行處理的；二是長度前綴，也就是RLP編碼都帶有一個前綴，這個前綴是跟被編碼數據的長度相關的，從下面的編碼規則中可以看出這一點。

對於值在[0, 127]之間的單個位元組，其編碼是其本身。

例1：a的編碼是97。

如果byte數組長度l <= 55，編碼的結果是數組本身，再加上128+l作為前綴。

例2：空字元串編碼是128，即128 = 128 + 0。

例3：abc編碼結果是131 97 98 99，其中131=128+len("abc")，97 98 99依次是a b c。

如果數組長度大於55， 編碼結果第一個是183加數組長度的編碼的長度，然後是數組長度的本身的編碼，最後是byte數組的編碼。

請把上面的規則多讀幾篇，特別是數組長度的編碼的長度。

例4：編碼下面這段字元串：

The length of this sentence is more than 55 bytes, I know it because I pre-designed it
這段字元串共86個位元組，而86的編碼只需要一個位元組，那就是它自己，因此，編碼的結果如下：

184 86 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前三個位元組的計算方式如下：

184 = 183 + 1，因為數組長度86編碼後僅佔用一個位元組。
86即數組長度86
84是T的編碼
例5：編碼一個重復1024次"a"的字元串，其結果為：185 4 0 97 97 97 97 97 97 ...。
1024按 big endian編碼為004 0，省略掉前面的零，長度為2，因此185 = 183 + 2。

規則1~3定義了byte數組的編碼方案，下面介紹列表的編碼規則。在此之前，我們先定義列表長度是指子列表編碼後的長度之和。

如果列表長度小於55，編碼結果第一位是192加列表長度的編碼的長度，然後依次連接各子列表的編碼。

注意規則4本身是遞歸定義的。
例6：["abc", "def"]的編碼結果是200 131 97 98 99 131 100 101 102。
其中abc的編碼為131 97 98 99,def的編碼為131 100 101 102。兩個子字元串的編碼後總長度是8，因此編碼結果第一位計算得出：192 + 8 = 200。

如果列表長度超過55，編碼結果第一位是247加列表長度的編碼長度，然後是列表長度本身的編碼，最後依次連接各子列表的編碼。

規則5本身也是遞歸定義的，和規則3相似。

例7：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
的編碼結果是:

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
其中前兩個位元組的計算方式如下：

248 = 247 +1
88 = 86 + 2，在規則3的示例中，長度為86，而在此例中，由於有兩個子字元串，每個子字元串本身的長度的編碼各佔1位元組，因此總共佔2位元組。
第3個位元組179依據規則2得出179 = 128 + 51
第55個位元組163同樣依據規則2得出163 = 128 + 35

例8：最後我們再來看個稍復雜點的例子以加深理解遞歸長度前綴，

["abc",["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]]
編碼結果是：

248 94 131 97 98 99 248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
列表第一項字元串abc根據規則2，編碼結果為131 97 98 99,長度為4。
列表第二項也是一個列表項：

["The length of this sentence is more than 55 bytes, ", "I know it because I pre-designed it"]
根據規則5，結果為

248 88 179 84 104 101 32 108 101 110 103 116 104 32 111 102 32 116 104 105 115 32 115 101 110 116 101 110 99 101 32 105 115 32 109 111 114 101 32 116 104 97 110 32 53 53 32 98 121 116 101 115 44 32 163 73 32 107 110 111 119 32 105 116 32 98 101 99 97 117 115 101 32 73 32 112 114 101 45 100 101 115 105 103 110 101 100 32 105 116
長度為90，因此，整個列表的編碼結果第二位是90 + 4 = 94, 佔用1個位元組，第一位247 + 1 = 248

以上5條就是RPL的全部編碼規則。

各語言在具體實現RLP編碼時，首先需要將對像映射成byte數組或列表兩種形式。以go語言編碼struct為例，會將其映射為列表，例如Student這個對象處理成列表["icattlecoder","male"]

如果編碼map類型，可以採用以下列表形式：

[["",""],["",""],["",""]]

解碼時，首先根據編碼結果第一個位元組f的大小，執行以下的規則判斷：

1.如果f∈ [0,128),那麼它是一個位元組本身。

2.如果f∈[128,184)，那麼它是一個長度不超過55的byte數組，數組的長度為 l=f-128

3.如果f∈[184,192)，那麼它是一個長度超過55的數組，長度本身的編碼長度ll=f-183,然後從第二個位元組開始讀取長度為ll的bytes，按照BigEndian編碼成整數l，l即為數組的長度。

4.如果f∈(192,247]，那麼它是一個編碼後總長度不超過55的列表，列表長度為l=f-192。遞歸使用規則1~4進行解碼。

5.如果f∈(247,256]，那麼它是編碼後長度大於55的列表，其長度本身的編碼長度ll=f-247,然後從第二個位元組讀取長度為ll的bytes,按BigEndian編碼成整數l，l即為子列表長度。然後遞歸根據解碼規則進行解碼。

以上解釋了什麼叫遞歸長度前綴編碼，這個名字本身很好的解釋了編碼規則。

（1） 以太坊源碼學習—RLP編碼( https://segmentfault.com/a/1190000011763339 )
（2）簡單分析RLP編碼原理
( https://blog.csdn.net/itchosen/article/details/78183991 )

E. 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網路的擁堵狀況，發送每筆交易時，設置合理的礦工費用，避免大量的交易積壓在交易池。

F. ETH開發實踐——合約地址是怎麼得來的

在把智能合約成功部署到ETH網路時，會得到合約地址，那麼，這個合約地址是由什麼決定的呢？合約地址由合約創建者的地址(sender address)和這筆部署交易中的nonce(發送者的累積交易次數)決定，將 sender 和 nonce 經過RLP編碼後，再進行Keccak-256(SHA3)散列， 最後裁掉前面12個位元組即得到合約地址。

example in js:

G. 各種區塊鏈瀏覽器的地址總匯

一.USDT-BTC瀏覽器:
1. https://www.omniexplorer.info/
2. https://www.oklink.com/usdt

二.BTC瀏覽器:
1. https://btc.com/
2.比特幣/交易 https://blockchair.com/
3.btc JSON-RPC: https://github.com/btcsuite/btcd/blob/master/docs/json_rpc_api.md#getbestblockhash

三.ETH瀏覽器:

H. 在Linux中要臨時配置網卡的IP地址和掩碼如何實現要永久配置網卡的IP地址和掩碼如何實現

在linux當中，第一塊網卡的設備名是eth0，文件是ifcfg-eth0，保存在了/etc/sysconfig/network-scripts/這個目錄下面x0dx0a1. 臨時配置：x0dx0a ifconfig eth0 192.168.1.1 netmask 255.255.255.0x0dx0a2. 永久生效：x0dx0a vi /etc/sysconfig/network-scripts/ifcfg-eth0x0dx0a打開這個文件後，裡面寫入以下內容：x0dx0a DEVICE=eth0 定義設備名稱x0dx0a ONBOOT=yes 開機是否自動激活x0dx0a BOOTPROTO=static 獲得IP的方式x0dx0a IPADDR=192.168.1.1 IP地址x0dx0a NETMASK=255.255.255.0 子網掩碼x0dx0a GATEWAY=192.168.1.100 網關（根據需求，不一定要寫）x0dx0a然後保存退出，重啟服務 service network restartx0dx0a注意： 這裡面的BOOTPROTO=static意思是IP地址為手動配置，那麼後面的內容也要寫了，如果你是自動獲得IP地址，那麼把這段改為BOOTPROTO=dhcp，然後把後面內容全部刪除就可以了，同樣也要重啟服務。x0dx0a提示： 注意大小寫。

I. 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日