以太坊節點同步時間

A. SIHB怎麼樣放以太坊錢包里

在本階段，以太坊只有命令行界面，所以許多人覺得它易用性「不夠好」，如果你非技術愛好者，可以不參與這個階段，等待下一個階段發布的圖形界面客戶端。其實，常用的操作使用命令行很容易搞定，一點也不繁瑣。

安裝Geth

現在最新的Geth，下載地址在這里

然後，解壓到桌面。

需要在命令行界面中打開此可執行文件。你需要找到命令提示符工具，在Windows8中。
在進行下面的正式操作前，關閉360衛士，因為它會阻止區塊同步。

在命令行提示符工具中，輸入 cd Desktop， 回車。輸入geth，回車。
界面會顯示以太坊的聲明，輸入y，回車，同意即可。

因為還沒創建賬戶，所以會有警告。等到同步完區塊，再來創建賬戶。

同步區塊的界面如下：根據反饋，電信網路用戶難以同步區塊，會一直處於fdtrack狀態：

可以嘗試加入高效節點。ctrl + c關閉geth， 輸入geth —bootnodes enode://@115.29.32.87:30303

同步需要花費一些時間。在這段時間，你可以熟悉下以太坊客戶端的數據文件所做位置，如圖：

如果你根據上圖紅框中的路徑找不到該文件夾，你需要設置顯示隱藏文件，如圖：

以太坊數據文件夾包括如下文件：

將你最新的區塊與這個網站顯示的最新區塊進行比較，確保更新到最新。我的已經同步到最新的第43414個區塊，如下圖：

創建賬戶

ctrl + c組合鍵，結束同步。輸入geth account new，回車。界面提示你為賬戶設置一個密碼，輸入密碼，回車。然後界面提示你，重復輸入密碼。注意，輸入密碼時，界面不會有反應。千萬不要忘記密碼！千萬不要忘記密碼！千萬不要忘記密碼！發送交易時，需要此密碼解密賬戶。成功創建出自己的以太幣地址，如下圖：

查詢已創建的賬戶，輸入geth account list，回車。如下圖：

許多時候需要輸入這個地址，例如發送交易時。右鍵，選擇「全選」，界面變白，如下圖：

滑動滑鼠選取地址，快捷鍵ctrl + c復制地址，【摘要】
SIHB怎麼樣放以太坊錢包里？【提問】
親~我正在編輯這道題的答案，還請您耐心等待一下。【回答】
在本階段，以太坊只有命令行界面，所以許多人覺得它易用性「不夠好」，如果你非技術愛好者，可以不參與這個階段，等待下一個階段發布的圖形界面客戶端。其實，常用的操作使用命令行很容易搞定，一點也不繁瑣。

安裝Geth

現在最新的Geth，下載地址在這里

然後，解壓到桌面。

需要在命令行界面中打開此可執行文件。你需要找到命令提示符工具，在Windows8中。
在進行下面的正式操作前，關閉360衛士，因為它會阻止區塊同步。

在命令行提示符工具中，輸入 cd Desktop， 回車。輸入geth，回車。
界面會顯示以太坊的聲明，輸入y，回車，同意即可。

因為還沒創建賬戶，所以會有警告。等到同步完區塊，再來創建賬戶。

同步區塊的界面如下：根據反饋，電信網路用戶難以同步區塊，會一直處於fdtrack狀態：

可以嘗試加入高效節點。ctrl + c關閉geth， 輸入geth —bootnodes enode://@115.29.32.87:30303

同步需要花費一些時間。在這段時間，你可以熟悉下以太坊客戶端的數據文件所做位置，如圖：

如果你根據上圖紅框中的路徑找不到該文件夾，你需要設置顯示隱藏文件，如圖：

以太坊數據文件夾包括如下文件：

將你最新的區塊與這個網站顯示的最新區塊進行比較，確保更新到最新。我的已經同步到最新的第43414個區塊，如下圖：

創建賬戶

ctrl + c組合鍵，結束同步。輸入geth account new，回車。界面提示你為賬戶設置一個密碼，輸入密碼，回車。然後界面提示你，重復輸入密碼。注意，輸入密碼時，界面不會有反應。千萬不要忘記密碼！千萬不要忘記密碼！千萬不要忘記密碼！發送交易時，需要此密碼解密賬戶。成功創建出自己的以太幣地址，如下圖：

查詢已創建的賬戶，輸入geth account list，回車。如下圖：

許多時候需要輸入這個地址，例如發送交易時。右鍵，選擇「全選」，界面變白，如下圖：

滑動滑鼠選取地址，快捷鍵ctrl + c復制地址，【回答】

B. 小狐狸錢包eth取消交易要手續費

以太坊錢包是一種幫助您與您的以太坊賬戶進行交互的工具。可以把它想像成一個背後沒有銀行的互聯網銀行應用。通過錢包您可以查看余額，發送交易或者鏈接到各種應用。您的錢包只是管理您以太坊賬戶的工具。這意味著您可以隨時更換您的錢包應用。許多錢包應用都支持同時管理您的多個以太坊賬戶。是您，而不是錢包實際控制您的資產。它們只是管理您資產的工具。
第一個要說的當然就是Ethereum官方錢包+瀏覽器Mist。Mist是一個全節點錢包（全節點錢包通俗的來說就是同步了全部的以太坊區塊信息的錢包）。也就是說打開錢包後，電腦會自動同步全部的以太坊區塊信息，如果設備和網路的條件過關的情況下，目前（17年9月8日）大概需要半天左右的時間。
優勢:安全度高，不需要經過第三方發起交易，節點未同步完成之前無法查看地址余額
劣勢:無法調整GasPrice對網路要求高，需要連接節點，才能發起交易

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

D. 以太坊12個網路確認是多久

與其說是 6 個區塊，倒不如說是 1 小時（6*10 分鍾），這個值的意義在於，即使算力第一名節點的算力再強，也不可能讓第二名提前 1 小時挖礦，然後自己還能比第二名先挖出來。



如果支出方想要進行雙重支付，他必須控制了非常大的算力，不然其他的挖礦者不會幫助它，因為他們都需要在最長的分支上工作才能得到獎賞。

E. ethereum node needs to sync，please wait 正常嗎

ethereum node needs to sync,please wait_有道翻譯
翻譯結果：
ethereum節點需要同步,請稍等
please
英 [pliːz]
美 [pliz]

int. 請（禮貌用語）
vt. 使喜歡；使高興，使滿意
vi. 討人喜歡；令人高興

Please 請,取悅,拜託
please hurry 請快些,請快點,請快點出牌

F. Quorum介紹

Quorum和以太坊的主要區別:

Quorum 的主要組件：

1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。

Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。

在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。

為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。

在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。

Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。

Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。

Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊

Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。

有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。

QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：

相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。

要想了解Raft-based Consensus，必須先了解Raft演算法

Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖

1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。

Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。

Raft的動態演示： http://thesecretlivesofdata.com/raft/

安全性保證，對於異常情況下Raft如何處理：

1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。

3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。

4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？

產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。

Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識

一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。

參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901

G. 以太坊錢包不更新

網路不順暢或其它。
節點同步慢原因以及解決方法：1、以太坊錢包節點同步需要聯網操作，如果你的網路不暢通就會造成同步慢這種情況，所以在同步之前請檢查好你的網路，確認網路狀況良好在進行同步。2、節點同步需要佔用大量的內存，如果你的電腦內存不夠就會造成階段同步慢甚至停止同步這種情況，建議用戶在同步節點之前清理一下電腦保證電腦內存充足，目前有用戶反映同步節點內存最高可佔用100G左右內存哦。3、可以在以太坊錢包中修改peer數，默認peer是25個，建議你可以修改成巨大的數值，例如9999個。4、同步階段還需要你的路由器支持uPnP。可以在路由器設置中修改。5、需要公網IP，如果你沒有的話就會慢很多，所以建議設置一個公網IP吧。6、也有網友反映是錢包本身的問題，以太坊錢包軟體本身並不是很成熟，在同步節點的時候會有很多問題出現，這個只有等待以太坊官方修改。7、電腦配置不能太低。8、第一次同步時使用--fast選項，可以更快地同步到最新塊。9、使用的是geth，運行時間長了可能會有問題，可以考慮每天重啟一次geth。10、及時更新geth到最新版本。11、硬碟空間要足夠大，建議至少1T以上。為了運行以太坊全節點，買了500G的硬碟空間，使用--fast同步完成後才佔40多G空間，之後正常模式同步硬碟佔用空間快速增長，3個月左右已經430G了，最近又買了500G磁碟空間。12、交易未被打包時，相同nonce值可以覆蓋之前的交易，覆蓋交易只看nonce值，至於交易的其它部分內容可以相同也可以不同。13、如果有低nonce值還未被打包，新的交易gasPrice再高，也需要先等低nonce值的交易被打包，如果低nonce值的交易因為gasPrice設低了而等待，需要先使用相同nonce值來修改gasPrice。
以太幣（ETH）是以太坊的一種加密數字代幣，被視為「比特幣2。0版」，創始人是傑弗里_維爾克。

H. 什麼是區塊鏈擴容

擴容，是當某個容器或承載物不足以支撐或承載現有事物需求時，我們通過擴大容器的容量或承載物的體積來滿足日益增長的需求，從而緩解當前容器或承載物所受壓力的一種手段。
在比特幣誕生之初比特幣創始人中本聰並沒有特意限制區塊的大小，區塊最大可以達到32MB，當時平均每個區塊大小為1~2KB。
時比特幣用戶少，交易量也沒有那麼大，並不會造成區塊擁堵，然而2013年至今隨著比特幣價格的直線上升，用戶越來越多因此造成比特幣網路擁堵，用戶交易費用上升的問題逐漸涌現出來。
到現在，比特幣區塊鏈上最高時有幾十萬筆交易積壓，比特幣的平均交易費用比 2010 年 9 月上漲了 376 倍，每秒 7 筆交易的處理速度已經明顯無法滿足用戶需求，比特幣社區開始探索如何給比特幣「擴容」。
通過修改比特幣底層代碼，從而達到提高交易處理能力的目的。
比特幣擴容本身發展和設計方案有兩種，即第一層和第二層擴容技術。
· 第一層擴容技術即改進區塊鏈自身，把區塊鏈自身變得更快、容量變得更大，總的來說就是改變區塊鏈共識部分的內容。
· 第二層擴容技術目的是把計算移到鏈下，即通過側鏈的技術加以解決問題。
擴容協議及結局
擴容協議一般需要礦工們的支持，大致可以分為修改區塊大小、軟分叉、硬分叉、隔離見證等方式。
以比特幣舉例：
比特幣現在分裂成為大區塊Bitcoin Cash(BCH)和隔離見證。隔離見證現在是市場上公認的比特幣，而大區塊幣被冠名為比特現金。可以預見的往後的發展方向，比特幣將會以鏈下交易為主。包括閃電網路、側鏈。這兩個新東西目前不成熟，但是被很多人寄予厚望的。
比特幣將會大量發展隔離見證交易，並在隔離見證的基礎上做更多的衍生技術。最有可能是以技術推動比特幣往前發展。
比特現金將會以鏈上交易為主，重點發展貨幣功能，以降低交易摩擦為主要方式，以獲利更廣泛的鏈上用戶量為主要發展方向。
鏈喬教育在線旗下學碩創新區塊鏈技術工作站是中國教育部學校規劃建設發展中心開展的「智慧學習工場2020-學碩創新工作站 」唯一獲準的「區塊鏈技術專業」試點工作站。專業站立足為學生提供多樣化成長路徑，推進專業學位研究生產學研結合培養模式改革，構建應用型、復合型人才培養體系。

I. 以太國際空間誰知道怎麼玩。EIS幣怎麼交易

現在我們大家都很關注關於以太坊方面的問題，那麼關於以太幣怎麼交易?我想我們大家應該會很想了解一些內容，那麼下面就讓我們小編在這里就來為大家好好的介紹一下很多內容關於以太幣怎麼交易?以太坊的交易最直觀解釋：從外部賬戶發送到區塊鏈上的另一個賬戶的消息和簽名的數據包。

包含如下內容：
發送者的簽名
接收的地址
轉移的數字貨幣數量等內容
以太坊上的交易都是需要支付費用，和比特幣以比特幣來支付一定的交易費用不同，以太坊上固定了這個環節，那麼這個間接理解是以太坊的一種安全防範錯誤，防止了大量的無意義的交易，保證一定的安全性，特別是智能合約的創建、執行、調用都需要消耗費用，那麼也保證了整個系統的穩定性，防止了一些鏈上無意義的惡意行為。
交易手續費
以太坊的核心是EVM，以太坊虛擬機，那麼在EVM中執行的位元組碼都是要支付費用。也就是經常看到的Gas、Gas limit、Gas Price這幾個概念。
Gas：字面理解就是汽油，以太坊和日常的汽車一樣需要Gas才能運行。Gas是一筆交易過程中計算消耗的基本單位。有一個列表可以直觀看到在以太坊中操作的Gas消耗量：
操作Gas消耗具體內容
step1執行周期的默認費用。
stop0終止操作是免費的。
suicide0智能合約賬戶的內部數據存儲空間，當合約賬戶調用suicide()方法時，該值將被置為null。
sha320加解密
sload20在固定的存儲器中去獲取
sstore100輸入到固定的存儲器中
balance20賬戶余額
create100創建合約
call20初始化一個只讀調用
memory1擴充內存額外支付的費用
txdata5交易過程中數據或者編碼的每一個位元組的消耗
transaction500交易費用
contract creation53000homestead中目前從21000調整到53000
所以有些公司或者個人覺得區塊鏈技術去中介化，不需要中心伺服器，這種開發模式是比較便宜的，但是事實上區塊鏈的開發不比之前的那些傳統軟體開發來的便宜。
Gas Price：字面理解汽油價格，這個就像你去加油站，95#汽油今天是什麼價格。一個Gas Price就是單價，那麼你的交易費用=Gas*Gas Price，然後以以太幣來ether來支出。當然你覺得我不想支付費用，你可以設置Gas Price為0，但是選擇權在礦工手中，礦工有權選擇收納交易和收取費用，那麼最簡單的想想很難讓一個礦工去接收一個價格很低的交易吧。另外提一句，以太坊默認的Gas Price是1wei。
Gas Limit：字面理解就是Gas的限制，限制是必要的，沒有限制就沒有約束。這個Gas Limit是有兩個意思的。首先針對單個交易，那麼這個表示交易的發起者他願意支付最多是多少Gas，這個交易發起者在發起交易的時候需要設置好。還有一個是針對區塊的Gas Limit，一個單獨的區塊也有Gas的限制。
假設幾個場景來說明Gas的使用：
用戶設置Gas Limit，那麼在交易過程中，如果你的實際消耗的Gas used
用戶設置Gas Limit，那麼交易過程中，如果你的實際消耗的Gas used > Gas Limit，那麼礦工肯定發現你的Gas不足，這個交易就無法執行完成，這個之後會回滾到執行之前的狀態，這個時候礦工會收取Gas Price*Gas Limit。
區塊的Gas Limit，區塊中有一個Gas上限，收納的交易會出現不同的用戶指定的Gas Limit。那麼礦工就會根據區塊限制的Gas Limit來選擇，「合理」選擇打包交易。
具體交易
以太坊上交易可以是簡單的以太幣的轉移，同時也可以是智能合約的代碼消息。列個表格看下交易的具體內容：
代碼內容
from交易發起者的地址、不能為空，源頭都沒有不合理。
to交易接收者的地址(這個可以為空，空的時候就表示是一個合約的創建)
value轉移的以太幣數量
data數據欄位。這個欄位存在的時候表示的是，交易是一個創建或者是一個調用智能合約的交易
Gas Limit字面理解就是Gas的限制，限制是必要的，沒有限制就沒有約束。這個Gas Limit是有兩個意思的。首先針對單個交易，那麼這個表示交易的發起者他願意支付最多是多少Gas，這個交易發起者在發起交易的時候需要設置好。還有一個是針對區塊的Gas Limit，一個單獨的區塊也有Gas的限制。
Gas Price一個Gas Price就是單價，那麼你的交易費用=Gas*Gas Price，然後以以太幣來ether來支出。以太坊默認的Gas Price是1wei。
nonce用於區別用戶發出交易的標識。
hash交易ID，是由上述的信息生成的一個hash值
r、s、v交易簽名的三部分，交易發起者的私鑰對hash簽名生成。
交易分三種類型
轉賬：簡單明了的以太坊上的以太幣的轉移，就和比特幣類似，A向B轉移一定數量的以太幣。這種交易包含：交易發起者、接收者、value的數量，其餘類似Gas Limit、hash、nonce都會默認生成。所以你會看到一段代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", to：「交易接收者地址」, value: 數量});
智能合約創建：創建智能合約就是把智能合約部署到區塊鏈上，那麼這個時候to是一個空的欄位。data欄位則是初始化合約的代碼。所以看到代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", data: "contract binary code"});
智能合約執行：合約創建部署在區塊鏈上，那麼執行就是會加上to欄位到要智能合約執行的地址，然後data欄位來指定調用的方法和參數的傳遞，所以看到代碼：
web3.eth.sendTransaction({ from: "交易發起者地址", to：「合約執行者地址」, data：「調用的方法和參數的傳遞」});
以上大致就是交易的類型。
交易的確認
和比特幣一樣，以太坊的交易需要後續區塊確認後，節點同步後、才能確認。簡單理解就是多挖出一些區塊來，通過驗證後這一筆交易才算確認，以太坊時常會出現擁堵的情況，所以有時候需要等待確認。
轉賬、合約交易流轉
首先交易發起者A發起一筆轉賬交易，那麼發送的格式如下：
代碼具體內容
from交易發起者的地址
to交易接收者的地址
value轉移的以太幣數量
GasGas的量
Gas PriceGas的單價
data發送給接收者的消息
nonce交易編號
節點驗證：以太坊網路中會有節點收到A發送出來的消息，那麼會去檢查這個消息格式時候有效，然後計算Gas Limit。這個時候回去驗證A的以太坊余額，如果余額不足，那麼就返回錯誤，不予處理。一旦A發送的消息通過了節點的驗證，那麼節點就會把這個交易放到交易存儲池中。並廣播到區塊鏈網路。
礦工驗證：那麼寫入區塊鏈必須要礦工打包，礦工在接收到A發出的交易，會和其他交易一塊打包，普通轉賬交易打包即可，那麼合約調用的交易則需要在礦工本地的EVM上去執行調用的合約代碼，代碼執行過程中檢查Gas的消耗。一旦Gas消耗完了，那麼就回滾，如果Gas足夠那麼返回多餘的Gas。並廣播到區塊鏈網路。
其餘節點：重復節點驗證步驟，然後合約也會在本地EVM上執行驗證。通過驗證後同步區塊鏈。
首先還是發起者A發起一個創建智能合約的交易請求。格式如下：
代碼具體內容
from交易發起者的地址
to0
value轉移的以太幣數量
GasGas的量
Gas PriceGas的單價
data合約代碼
nonce交易編號
節點驗證：
以太坊網路中會有節點收到A發送出來的消息，檢查交易是否有效，格式是否正確，驗證交易簽名。計算Gas，確定下發起者的地址，然後查詢A賬戶以太幣的余額。如果余額不足，那麼就返回錯誤，不予處理。一旦A發送的消息通過了節點的驗證，那麼節點就會把這個交易放到交易存儲池中。並廣播到區塊鏈網路。
礦工驗證：
礦工將交易打包，那麼會根據交易費用和合約代碼，來創建合約賬戶，在賬戶的空間中部署合約。這里說下合約地址(智能合約賬戶的地址是有發起者的地址和交易的隨機數作為輸入，然後通過加密演算法生成)。交易確認後會把智能合約的地址返回給A。且廣播到區塊鏈網路。
其餘節點：
重復節點驗證步驟，驗證區塊，在節點的內存池中更新A的智能合約交易，同步區塊鏈，且智能合約部署在自己本地的區塊鏈中。

J. 輕用戶是什麼意思

什麼是輕客戶端？為什麼你需要了解它

播報文章

在以太坊的案例中，過去只有一種類型的節點，現在稱為全節點。這個軟體負責驗證和轉播網路上的交易和區塊。由於無信任環境（開放的互聯網）和區塊鏈的性質，每個全節點需要下載並驗證每個區塊，所以就是在每個區塊中驗證每一筆交易。

Parity Ethereum 和 Geth 這兩個最受歡迎的以太坊客戶端，今天都可以在一台中等功率的筆記本電腦上運行。然而，下載和驗證整個區塊鏈的區塊是需要時間和資源的。例如，現在需要使用 SSD 來完全同步以太坊區塊鏈。HDD 無法跟上每秒所需的輸入/輸出操作。

全節點使用案例

現在，組織和個人運行全節點是因為他們的業務需要。想想礦工、區塊瀏覽器、交易所。個人用戶可能希望運行全節點，因為這是與區塊鏈交互的最安全方式。在一個更小的范圍內，他們也可能是純粹的利他主義來幫助網路。7*24 小時全天候的運行一個全節點需要良好的知識和資源水平，大多數用戶不願意投資是可以理解的。除了礦工，沒有什麼內置的激勵來運行一個全節點，盡管這部分基礎設施對網路至關重要。

因此，大多數與區塊鏈交互的用戶，不管是否自願，都會使用一個中心的基礎設施。最流行的軟體錢包默認依賴於第三方託管的節點。這些客戶端連接到遠程節點，並以非密碼驗證的方式完全信任其響應。它的積極方面顯然是增強了用戶體驗，因為這些錢包的用戶不需要運行自己的節點。但是，它們被迫信任第三方節點。默認情況下，Metamask、MyEtherWallet 和 MyCrypto 連接到遠程節點，但如果用戶願意，仍然允許他們連接到自己的本地節點。這不是 Jaxx 或 Exos 錢包的情況，它們默認連接到遠程節點，而沒有連接到用戶自己的本地節點的選項。這里沒有提到移動錢包，因為手機無法運行全節點。

像 Infura 這樣的公司致力於運行全節點，並免費提供給那些需要它們的人。抽象出同步一個全節點的麻煩，允許任何用戶輕松地訪問區塊鏈。這樣的解決方案有助於讓更多用戶能夠訪問以太坊。然而，盡管這一舉措是對生態系統的一個重大補充，但它代表了一個中心化的單一失敗點，與去中心化的區塊鏈理念背道而馳。直到幾個月前，錢包開發商還沒有其他選擇。

「我們的目標是創建一個兼容不同程度『輕』的協議，從幾乎不存儲任何內容的客戶端到幾乎存儲所有內容的客戶端。」

— PIP, Parity Light Protocol（https://wiki.parity.io/The-Parity-Light-Protocol-%28PIP%29）

輕量級替代方案：輕客戶端

輕客戶端或輕節點是連接到全節點與區塊鏈交互的軟體。與全節點對應節點不同，輕節點不需要運行 24/7 或讀寫區塊鏈上的大量信息。事實上，輕客戶端並不直接與區塊鏈交互，而是使用全節點作為中介。輕客戶端依賴於全節點去執行許多操作，從請求最新的區塊頭到請求帳戶中的余額。

輕客戶端協議的設計方式允許它們以最小信任的方式與全節點交互。這是一個需要理解的關鍵方面，因此讓我們回顧一下以太坊區塊鏈的基礎知識：

1. 普通用戶使用全節點、輕節點或受信任的遠程節點在網路上發送交易。

2. 全節點從網路上的對等節點接收交易，檢查這些交易的有效性，並將它們廣播到網路。

3. 礦工是連接到特定軟體的全節點。他們像一個普通的全節點一樣從網路上接收和驗證交易，但是會額外投入大量的精力來尋找問題的解決方案，才會被允許生成下一個區塊。礦工使用的全節點通過應該將哪個區塊添加到區塊鏈並構建在其上達成共識。任何在其上構建了至少 10 個塊的塊都被認為是安全的，因為它包含的交易被還原的概率非常低。

現在，回到我們的輕客戶端。作為起點，輕客戶端需要下載區塊鏈的區塊頭。輕客戶端不需要為它對全節點的每個請求去信任全節點。這是因為區塊頭包含一個名為 Merkle 樹根的信息。Merkle 樹根就是區塊鏈上有賬戶余額和智能合約存儲的所有信息的指紋。如果有任何微小的信息改變，這個指紋也會改變。假設大多數礦工都是誠實的，那麼區塊頭和他們所包含的指紋就被認為是有效的。輕客戶端可能需要從全節點請求信息，例如特定帳戶的余額。輕客戶端知道每個區塊的指紋，就可以驗證全節點給出的答案是否與其擁有的指紋匹配。這是一個強有力的工具，可以在事先不知情的情況下證明信息的真實性。

由於輕客戶端需要發送多個請求來執行簡單的操作，因此所需的總體網路帶寬高於全節點的帶寬。另一方面，所需的資源和存儲量比全節點的資源和存儲量低幾個數量級，同時實現了非常高的安全級別。只需要大約 100MB 的存儲空間和較低的計算能力，輕節點就可以在移動設備上運行！這意味著手機可以以去中心化的方式訪問區塊鏈。

因為只需要一個全節點的一小部分信息，所以一個輕節點可以更快地與區塊鏈同步。目前，將整個以太坊主網區塊鏈同步，輕客戶端大約只需要一個小時，但節點同步超過幾秒對任何應用程序來說都太多了。為輕客戶端開發的解決方案可以快速與區塊鏈頂部同步，盡管這些解決方案通常需要權衡。目前，輕客戶端在其代碼中內置了一個可信的區塊鏈檢查點。正因為如此，客戶端只需要下載最新的區塊頭文件，就可以在幾秒鍾內實現同步。輕客戶端用戶信任客戶端開發人員集成有效的檢查點。這種折衷被認為是可以接受的，因為用戶已經需要信任客戶端實現的開發人員。為了以去中心化的方式快速執行同步，Parity Technologie 目前開發了一種替代解決方案，允許輕客戶端以與全節點類似的方式執行扭曲同步（https://wiki.parity.io/Warp-Sync）。

未來，輕客戶端會遍布各地。 — Marty McFly

輕客戶端的挑戰

輕客戶端非常適合主流應用，例如發送一些交易和驗證帳戶余額。對輕客戶端的主要批評是，輕客戶端不能直接幫助網路。它們不驗證除自己需要的信息以外的任何其他信息，也不從網路向其他對等節點提供或轉播信息，它們使用來自全節點的資源，而不提供任何的回報。

與全節點相比，輕客戶端提供了更好的最終用戶體驗，同時允許最終用戶以去中心化的和安全的方式訪問區塊鏈。關鍵是要找到一種激勵個人和機構的方式去運行全節點、服務輕節點、懲罰服務壞數據的惡意全節點。使輕客戶端可持續發展的一種方法是讓他們對全節點發出的每個請求執行小額支付。在不久的將來，輕客戶端將在以太坊分片中扮演重要角色，讓驗證節點快速同步不同的分片。輕客戶端還可用於報告惡意參與者（驗證節點或 plasma 許可權）。輕客戶端對全節點的激勵是一個活躍的研究領域，因為激勵是生態系統穩定的關鍵。

有一些很有前途的想法可以讓輕客戶端快速同步，同時避免前面提到的折衷方案。一種想法是允許全節點提供最新的已知區塊頭的零知識證明（例如，zk-STARK https://eprint.iacr.org/2018/046.pdf）。然後，輕客戶端可以驗證它並與鏈的頂部同步，而無需事先知道區塊鏈的狀態。

總之，在短期內，輕客戶端將成為去中心化應用程序的骨幹，這對用戶友好的分布式生態系統來說是一個非常好的消息。