eth節點地址

A. java中怎麼樣調用eth的智能合約

一般來說，部署智能合約的步驟為：
1啟動一個以太坊節點 (例如geth或者testrpc)。
2使用solc編譯智能合約。 => 獲得二進制代碼。
3將編譯好的合約部署到網路。（這一步會消耗以太幣，還需要使用你的節點的默認地址或者指定地址來給合約簽名。） => 獲得合約的區塊鏈地址和ABI（合約介面的JSON表示，包括變數，事件和可以調用的方法）。(譯註：作者在這里把ABI與合約介面弄混了。ABI是合約介面的二進製表示。)
4用web3.js提供的JavaScript API來調用合約。（根據調用的類型有可能會消耗以太幣。）

B. 以太坊區塊鏈之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

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

D. 2020年ETH升級2.0超級版本，會帶來什麼影響

原因：
Linux distribution使用udev動態管理設備文件，並根據設備的信息對其進行持久化命名。udev會在系統引導的過程中識別網卡，將mac地址和網卡名稱對應起來記錄在udev的規則腳本中。而對於新的虛擬機，VMware會自動為虛擬機的網卡生成MAC地址，當克隆或者重裝虛擬機軟體時，由於使用的是以前系統虛擬硬碟的信息，而該系統中已經有eth0的信息，對於這個新的網卡，udev會自動將其命名為eth1（累加的原則），所以在系統啟動後，使用ifconfig看到的網卡名為eth1。
解決方法：
在fedora中，udev記錄網路規則的腳本為：/etc/udev/rules.d/70-persistent-net.rules
[user@localhost ~]$ vi /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# PCI device 0x1022:0x2000 (pcnet32)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:5a:6c:73", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:a9:22:9d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
打開該文件，這時會發現，裡面有eth0，eth1兩個網卡的信息，但實際上ifconfig時只能發現eth1一個網卡的信息，這時因為eth0根本就不存在。
將其中eth0的信息刪掉，並將eth1信息中的設備名改為eth0，重啟系統，看到的網卡就是eth0了，或者刪掉其中所有的信息重啟系統udev會幫發現新的設備的。

E. 以太坊2.0質押地址余額現在是多少

以太坊2.0質押地址余額超過450萬枚

鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。

F. 2022以太坊節點數量

2022以太坊節點數量達到了2000多點，數量非常的穩定龐大，能夠體現出目前以太幣的強勢和利好，非常適合投資。

G. 1. 樹莓派：eth橋接到wlan口，共享上網

背景： 樹莓派外接5G無線網卡，推流器連接raspberry 3B lan口，共享上網。

驗證： raspberry 3B連接手機的熱點，PC通過網線與raspberry的lan口相連，實現上網。

思路:

1. 首先給raspberry的eth設置一個靜態ip地址。

2. 修改IP轉發規則，允許ip數據的轉發。（ip_forward的設置）

3. 路由設置，配置iptables，進行兩個網卡的橋接。

4. 開啟raspberry的DHCP服務，在eth口上開啟。

5. 開啟DNS服務。

詳細過程：

1. 給樹莓派的eth分配靜態地址。

暫時分配：

sudo ifconfig eth0 192.168.173.1 255.255.255.0 up

永久分配：

寫在配置文件里。

配置文件 /etc/network/interfaces，請注意此處wlan0的地址參數要和etc/udhcpd.conf相關參數相對應。

sudo vi  /etc/network/interfaces

#iface default inet dhcp

增加

auto eth0

iface eth0 inet static

address 192.168.173.1

netmask 255.255.255.0

注意：

2. 啟動IP轉發

有多種方法，建議使用sysctl的設置方式

方法1：sudo echo 1 > /proc/sys/net/ipv4/ip_forward

方法2：sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"

方法3：sudo sysctl -w net.ipv4.ip_forward=1

有的時候需要在/etc/sysctl.conf下添加一行：net.ipv4.ip_forward=1

3. iptables設置

     iptables -t nat -I POSTROUTING -o wlan0 -j MASQUERADE

4. dhcp服務

4.1 安裝udhcpd服務

    sudo apt-get update

    sudo apt-get install udhcpd

4.2 配置DHCP服務

    sudo vi /etc/udhcpd.conf

    1. 修改網路介面，設置成對應的網卡號

    2. 設置remaining，去除前面的#符號

    #remaining     yes    改為   remain    yes

    3. 設置樹莓派的IP地址

        修改opt router為192.168.173.1，那麼配置完成之後這個地址將作為網關，連接到raspberry eth口的設備網關需要設置為此IP.

        此處opt dns被修改為公共的DNS地址 114.114.114.114和 114.114.114.115

4.3 使能DHCP

     配置 /etc/default/udhcpd

    sudo nano  /etc/default/udhcpd

    使用#符號注釋DHCPD_ENABLED="no"

    DHCPD_ENABLED="no"    改為     #DHCPD_ENABLED="no"

4.4  啟動服務

    1. 啟動udhcp的服務：sudo service udhcpd start

    2. 設置開機啟動： sudo update-rc.d  udhcpd enable

5. dns服務

在進行調試的時候發現無法查詢到raspberry使用的dns地址，按照常規方法查到的dns地址為127.0.1.1。在網上查了一下https://segmentfault.com/q/1010000002443769 感興趣的可以參考一下這篇文章。

這就導致我在測試的時候遇到一個問題，pc可以通過ip地址訪問，但是通過域名無法訪問。然後我就在網上查了一些共用的dns伺服器，設置後一切正常。關於這些共用的dns信息參考如下：

/********************************************************************************************************************************************************/

A、DNSPod DNS+：DNSPod的 Public DNS+是目前國內第一家支持ECS的公共DNS，是DNSPod推出的公共域名解析服務，可以為全網用戶提供域名的公共遞歸解析服務！

DNS 伺服器 IP 地址：

首選：119.29.29.29        備選：182.254.116.116

B、114DNS：國內用戶量巨大的DNS，訪問速度快，各省都有節點，同時滿足電信、聯通、移動各運營商用戶，可以有效預防劫持。

DNS 伺服器 IP 地址：

首選：114.114.114.114        備選：114.114.114.115

C、阿里 AliDNS：阿里公共DNS是阿里巴巴集團推出的DNS遞歸解析系統，目標是成為國內互聯網基礎設施的組成部分，面向互聯網用戶提供「快速」、「穩定」、「智能」的免費DNS遞歸解析服務。

DNS 伺服器 IP 地址：

首選：223.5.5.5        備選：223.6.6.6

/********************************************************************************************************************************************************/

H. 一個以太坊節點最多可以有 幾個賬戶地址

一個以太坊節點最多可以有 幾個賬戶地址？
答：一般只有一個賬戶地址，否則會出現錯誤的！區塊鏈本身就是具有唯一性的，如果有多個賬戶地址在一個節點上，就違反了區塊鏈的根本！

I. 以太坊多節點私有鏈部署

假設兩台電腦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

J. 以太坊源碼分析--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 的信息