A. 挖礦接受率低怎麼回事
通過架設比特幣節點獲利的過程，被人們形象地稱為 「挖礦」（mining），而參與建設節
點的那些人被人們稱為 「礦工」（miners）。因為 「搶紅包」 是有一定運氣因素存在的
行為，所以，礦工們會集中挖礦，方式是把自己的節點算力集中到一個「礦池」（mining pool）之中，以便增加自己搶紅包時的運氣。
礦機挖礦接受率低通常有以下幾種情況：
1. 網路通信問題導致丟包、延時問題，請檢查網線和網路情況。
礦機通過連接礦池進行礦池，礦池定時給礦機分發job，礦機隨之將share提交給礦池，這個過程中涉及大量的數據傳輸。網路情況對礦機的算力和拒絕率有直接的影響。
您可以通過以下方法確認網路情況：
1）將電腦連接至礦機所在的區域網
2）在電腦上打開cmd命令提示符
3） 輸入ping+空格+幣印礦池某幣種挖礦地址，比如我想確認礦機連接幣印礦池大零幣ZEC北京節點的網路情況，可輸入ping zec-bj.ss.poolin.com，並按回車鍵獲取結果。
通常ping值在50ms內都是一個比較正常的范圍。
2. 礦機溫度過高
礦機溫度過高同樣會影響礦機的算力和拒絕率，特別是在炎熱的夏季。如下截圖中的溫度基本正常。不同的礦機對最高溫度適應情況不同，通常在90-100以下的溫度還是比較正常的。具體的需要根據不同的機型進行確認。
3.固件問題，部分礦機可能因為固件問題導致拒絕率普遍偏高。出現類似情況，可咨詢礦機廠商。
4.挖礦系統或軟體有問題，用原版Claymore軟體跑一下，看運行界面，有沒有紅色字提醒超頻過了或者其他錯誤的;
B. 挖礦延遲率高會影響收益嗎
有影響。一般來講，挖礦看中的就是速度快慢，如果一個礦池出現了延時的情況，那麼對於投資者來講影響還是比較大的。延遲是141.9000毫秒 這個延遲在廣域網中屬於正常現象。收益方面，Ezil.me通過無縫切換技術挖Zil來增加以太坊礦工的收入，注意這里不是傳統的雙挖，而是「一個接一個」 ，也就是在ETH或ETC開採回合結束以後（每兩到三個小時），礦池會自動切換到ZIL，在ZIL挖礦回合結束之後，礦池立即切換回ETH或ETC。
拓展資料
一、 哪個礦池比較好
1、螞蟻礦池。螞蟻礦池是比特大陸投入很多資源開發的高效的數字貨幣礦池，致力於為礦工提供更友好的界面、更完善的功能、更方面的使用和更豐厚透明的收益，並為數字貨幣的發展做出更多的貢獻。螞蟻礦池是一家高效的數字貨幣礦池，致力於為礦工提供更友好的界面、更完善的功能、更方便的使用和更豐厚透明的收益，螞蟻礦池提供比特幣、萊特幣、以太坊等多種數字貨幣的挖礦服務，並支持PPS、PPLNS、SOLO等多種付款方式。
2、F2Pool。魚池，2013年4月創立於北京，是全球領先的綜合性數字貨幣礦池。魚池擁有一支由高學歷、高技術、高素質的國內頂尖人才組成的團隊，創始人神魚、王純，作為國內首批從事區塊鏈行業的意見領袖，帶領團隊打造了領先的數字貨幣挖礦平台。業務遍布全球多個國家和地區，帶領了區塊鏈行業的快速發展。我們期待年輕而充滿朝氣的新成員加入，並肩為全球區塊鏈事業作出貢獻。
3、BTC.com。BTC.com是全球領先的比特幣數據服務商與礦池、錢包解決方案提供商。自2015年起，BTC.com團隊從區塊瀏覽器等行業基礎設施入手，致力於在各個細分領域建立新標准，錢包、礦池、行情、資訊等領域均能見到BTC.com品牌的身影。BTC.com團隊成員均來自於國內一線互聯網公司，近年來持續服務於比特幣礦機與挖礦行業，擁有多年系統設計、開發維護、運營管理經驗。伴隨著BTC.com團隊與品牌的成長，可以預見到，未來還將帶給比特幣用戶更多的驚喜。
4、微比特。微比特是一家專業的數字貨幣技術服務提供商，服務范圍包括數字貨幣交易平台以及數字貨幣礦池、雲挖礦合約等。其於2016年5月成立，同年6月上線比特幣礦池，11月上線雲挖礦產品。2017年3月，微比特獲得由比特大陸領投的2000萬人民幣A輪融資以拓展交易所業務。6月，微比特正式推出數字貨幣交易平台。
C. e池直連延時200毫秒以上影響收益嗎
超過200毫秒是有影響的。
礦池延時的正常范圍是141.9000毫秒，這個延遲在廣域網中屬於正常現象。超過200毫秒對於投資者來講影響還是比較大的，一般來講，挖礦看中的就是速度快慢，延時高意味著算力降低，同樣別人一分鍾挖到的礦也許你得五分鍾。
一般在家減少網路延遲採用的手段是。
1、電腦網線盡量短一些，水晶頭做的盡量好一些。
2、電話線要檢查一下，盡量減少接頭。但是這些僅僅就是理論方法。現在我們在家訪問網站的網路延遲比較大，基本原因都因為網路服務商的網路線路和網路設備的原因。
D. eth礦池延時是什麼
Eth礦池延時指的是以太坊挖礦過程中出現的延遲現象。
詳細解釋：
1. 礦池延時的概念：在以太坊的挖礦過程中，礦池延時是一個常見的現象。它主要指的是礦工將交易數據提交至礦池後，數據被礦池接受並處理所發生的延遲。這種延遲可能涉及多個環節，包括數據傳輸速度、礦池伺服器的處理能力等。
2. 產生原因：礦池延時有多種原因。首先，網路狀況是影響礦池延時的關鍵因素之一。網路擁堵或數據傳輸速度較慢時，可能導致數據提交延遲。其次，礦池伺服器的性能也是影響延時的因素之一。如果伺服器處理速度較慢或負載較重，就會影響到數據的及時處理，從而產生延時。此外，還有一些其他因素，如軟硬體故障等，也可能導致礦池延時。
3. 影響分析：礦池延時對礦工和整個區塊鏈網路都會產生影響。對於礦工而言，長時間的礦池延時可能會導致其挖礦效率降低，進而影響到收益。對於整個區塊鏈網路而言，礦池延時可能影響到網路的性能與穩定性。例如，大量的未及時處理的數據可能會堆積，進一步加劇網路的擁堵。因此，減少礦池延時是提高挖礦效率和保障區塊鏈網路穩定運行的重要一環。
總的來說，Eth礦池延時是挖礦過程中常見的現象，對礦工和網路運行都產生影響。因此，礦工和整個區塊鏈社區都需要關注這一問題，並尋求有效的解決方案來降低礦池延時，提高挖礦效率和網路性能。
E. 常見的共識演算法介紹
在非同步系統中，需要主機之間進行狀態復制，以保證每個主機達成一致的狀態共識。而在非同步系統中，主機之間可能出現故障，因此需要在默認不可靠的非同步網路中定義容錯協議，以確保各個主機達到安全可靠的狀態共識。
共識演算法其實就是一組規則，設置一組條件，篩選出具有代表性的節點。在區塊鏈系統中，存在很多這樣的篩選方案，如在公有鏈中的POW、Pos、DPOS等，而在不需要貨幣體系的許可鏈或私有鏈中，絕對信任的節點、高效的需求是公有鏈共識演算法不能提供的，對於這樣的區塊鏈，傳統的一致性共識演算法成為首選，如PBFT、PAXOS、RAFT等。
目錄
一、BFT（拜占庭容錯技術）
二、PBFT（實用拜占庭容錯演算法）
三、PAXOS
四、Raft
五、POW（工作量證明）
六、POS（權益證明）
七、DPOS（委任權益證明）
八、Ripple
拜占庭弄錯技術是一類分布式計算領域的容錯技術。拜占庭假設是由於硬體錯誤、網路擁塞或中斷以及遭到惡意攻擊的原因，計算機和網路出現不可預測的行為。拜占庭容錯用來處理這種異常行為，並滿足所要解決問題的規范。
拜占庭容錯系統是一個擁有n台節點的系統，整個系統對於每一個請求，滿足以下條件：
1）所有非拜占庭節點使用相同的輸入信息，產生同樣的結果；
2）如果輸入的信息正確，那麼所有非拜占庭節點必須接收這個信息，並計算相應的結果。
拜占庭系統普遍採用的假設條件包括：
1）拜占庭節點的行為可以是任意的，拜占庭節點之間可以共謀；
2）節點之間的錯誤是不相關的；
3）節點之間通過非同步網路連接，網路中的消息可能丟失、亂序並延時到達，但大部分協議假設消息在有限的時間里能傳達到目的地；
4）伺服器之間傳遞的信息，第三方可以嗅探到，但是不能篡改、偽造信息的內容和驗證信息的完整性。
拜占庭容錯由於其理論上的可行性而缺乏實用性，另外還需要額外的時鍾同步機制支持，演算法的復雜度也是隨節點的增加而指數級增加。
實用拜占庭容錯降低了拜占庭協議的運行復雜度，從指數級別降低到多項式級別。
PBFT是一種狀態機副本復制演算法，即服務作為狀態機進行建模，狀態機在分布式系統的不同節點進行副本復制。PBFT要求共同維護一個狀態。需要運行三類基本協議，包括一致性協議、檢查點協議和視圖更換協議。
一致性協議。一致性協議至少包含若干個階段：請求（request）、序號分配（pre-prepare）和響應（reply），可能包含相互交互（prepare），序號確認（commit）等階段。
PBFT通信模式中，每個客戶端的請求需要經過5個階段。由於客戶端不能從伺服器端獲得任何伺服器運行狀態的信息，PBFT中主節點是否發生錯誤只能由伺服器監測。如果伺服器在一段時間內都不能完成客戶端的請求，則會觸發視圖更換協議。
整個協議的基本過程如下：
1）客戶端發送請求，激活主節點的服務操作。
2）當主節點接收請求後，啟動三階段的協議以向各從節點廣播請求。
［2.1］序號分配階段，主節點給請求賦值一個序列號n，廣播序號分配消息和客戶端的請求消息m，並將構造PRE-PREPARE消息給各從節點；
［2.2］交互階段，從節點接收PRE-PREPARE消息，向其他服務節點廣播PREPARE消息；
［2.3］序號確認階段，各節點對視圖內的請求和次序進行驗證後，廣播COMMIT消息，執行收到的客戶端的請求並給客戶端以響應。
3）客戶端等待來自不同節點的響應，若有m+1個響應相同，則該響應即為運算的結果。
PBFT一般適合有對強一致性有要求的私有鏈和聯盟鏈，例如，在IBM主導的區塊鏈超級賬本項目中，PBFT是一個可選的共識協議。在Hyperledger的Fabric項目中，共識模塊被設計成可插拔的模塊，支持像PBFT、Raft等共識演算法。
在有些分布式場景下，其假設條件不需要考慮拜占庭故障，而只是處理一般的死機故障。在這種情況下，採用Paxos等協議會更加高效。。PAXOS是一種基於消息傳遞且具有高度容錯特性的一致性演算法。
PAXOS中有三類角色Proposer、Acceptor及Learner，主要交互過程在Proposer和Acceptor之間。演算法流程分為兩個階段：
phase 1
a) proposer向網路內超過半數的acceptor發送prepare消息
b) acceptor正常情況下回復promise消息
phase 2
a) 在有足夠多acceptor回復promise消息時，proposer發送accept消息
b) 正常情況下acceptor回復accepted消息
流程圖如圖所示：
PAXOS協議用於微信PaxosStore中，每分鍾調用Paxos協議過程數十億次量級。
Paxos是Lamport設計的保持分布式系統一致性的協議。但由於Paxos非常復雜，比較難以理解，因此後來出現了各種不同的實現和變種。Raft是由Stanford提出的一種更易理解的一致性演算法，意在取代目前廣為使用的Paxos演算法。
Raft最初是一個用於管理復制日誌的共識演算法，它是在非拜占庭故障下達成共識的強一致協議。Raft實現共識過程如下：首先選舉一個leader，leader從客戶端接收記賬請求、完成記賬操作、生成區塊，並復制到其他記賬節點。leader有完全的管理記賬權利，例如，leader能夠決定是否接受新的交易記錄項而無需考慮其他的記賬節點，leader可能失效或與其他節點失去聯系，這時，重新選出新的leader。
在Raft中，每個節點會處於以下三種狀態中的一種：
（1）follower：所有結點都以follower的狀態開始。如果沒收到leader消息則會變成candidate狀態；
（2）candidate：會向其他結點「拉選票」，如果得到大部分的票則成為leader。這個過程就叫做Leader選舉(Leader Election)；
（3）leader：所有對系統的修改都會先經過leader。每個修改都會寫一條日誌(log entry)。leader收到修改請求後的過程如下：此過程叫做日誌復制（Log Replication）
1）復制日誌到所有follower結點
2）大部分結點響應時才提交日誌
3）通知所有follower結點日誌已提交
4）所有follower也提交日誌
5）現在整個系統處於一致的狀態
Raft階段主要分為兩個，首先是leader選舉過程，然後在選舉出來的leader基礎上進行正常操作，比如日誌復制、記賬等。
（1）leader選舉
當follower在選舉時間內未收到leader的消息，則轉換為candidate狀態。在Raft系統中：
1）任何一個伺服器都可以成為候選者candidate，只要它向其他伺服器follower發出選舉自己的請求。
2）如果其他伺服器同意了，發出OK。如果在這個過程中，有一個follower宕機，沒有收到請求選舉的要求，此時候選者可以自己選自己，只要達到N/2+1的大多數票，候選人還是可以成為leader的。
3）這樣這個候選者就成為了leader領導人，它可以向選民也就是follower發出指令，比如進行記賬。
4）以後通過心跳消息進行記賬的通知。
5）一旦這個leader崩潰了，那麼follower中有一個成為候選者，並發出邀票選舉。
6）follower同意後，其成為leader，繼續承擔記賬等指導工作。
（2）日誌復制
記賬步驟如下所示：
1）假設leader已經選出，這時客戶端發出增加一個日誌的要求；
2）leader要求follower遵從他的指令，將這個新的日誌內容追加到各自日誌中；
3）大多數follower伺服器將交易記錄寫入賬本後，確認追加成功，發出確認成功信息；
4）在下一個心跳消息中，leader會通知所有follower更新確認的項目。
對於每個新的交易記錄，重復上述過程。
在這一過程中，若發生網路通信故障，使得leader不能訪問大多數follower了，那麼leader只能正常更新它能訪問的那些follower伺服器。而大多數的伺服器follower因為沒有了leader，他們將重新選舉一個候選者作為leader，然後這個leader作為代表與外界打交道，如果外界要求其添加新的交易記錄，這個新的leader就按上述步驟通知大多數follower。當網路通信恢復，原先的leader就變成follower，在失聯階段，這個老leader的任何更新都不能算確認，必須全部回滾，接收新的leader的新的更新。
在去中心賬本系統中，每個加入這個系統的節點都要保存一份完整的賬本，但每個節點卻不能同時記賬，因為節點處於不同的環境，接收不同的信息，如果同時記賬，必然導致賬本的不一致。因此通過同時來決定那個節點擁有記賬權。
在比特幣系統中，大約每10分鍾進行一輪算力競賽，競賽的勝利者，就獲得一次記賬的權力，並向其他節點同步新增賬本信息。
PoW系統的主要特徵是計算的不對稱性。工作端要做一定難度的工作才能得出一個結果，而驗證方卻很容易通過結果來檢查工作端是不是做了相應的工作。該工作量的要求是，在某個字元串後面連接一個稱為nonce的整數值串，對連接後的字元串進行SHA256哈希運算，如果得到的哈希結果（以十六進制的形式表示）是以若干個0開頭的，則驗證通過。
比特幣網路中任何一個節點，如果想生成一個新的區塊並寫入區塊鏈，必須解出比特幣網路出的PoW問題。關鍵的3個要素是 工作量證明函數、區塊及難度值 。工作量證明函數是這道題的計算方法，區塊決定了這道題的輸入數據，難度值決定了這道題所需要的計算量。
（1）工作量證明函數就是<u style="box-sizing: border-box;"> SHA256 </u>
比特幣的區塊由區塊頭及該區塊所包含的交易列表組成。擁有80位元組固定長度的區塊頭，就是用於比特幣工作量證明的輸入字元串。
（2）難度的調整是在每個完整節點中獨立自動發生的。每2016個區塊，所有節點都會按統一的公式自動調整難度。如果區塊產生的速率比10分鍾快則增加難度，比10分鍾慢則降低難度。
公式可以總結為：新難度值=舊難度值×（過去2016個區塊花費時長/20160分鍾）
工作量證明需要有一個目標值。比特幣工作量證明的目標值（Target）的計算公式：目標值=最大目標值/難度值
其中最大目標值為一個恆定值：
目標值的大小與難度值成反比。比特幣工作量證明的達成就是礦工計算出來的 區塊哈希值必須小於目標值 。
（3）PoW能否解決拜占庭將軍問題
比特幣的PoW共識演算法是一種概率性的拜占庭協議（Probabilistic BA）
當不誠實的算力小於網路總算力的50%時，同時挖礦難度比較高（在大約10分鍾出一個區塊情況下）比特幣網路達到一致性的概念會隨確認區塊的數目增多而呈指數型增加。但當不誠實算力具一定規模，甚至不用接近50%的時候，比特幣的共識演算法並不能保證正確性，也就是，不能保證大多數的區塊由誠實節點來提供。
比特幣的共識演算法不適合於私有鏈和聯盟鏈。其原因首先是它是一個最終一致性共識演算法，不是一個強一致性共識演算法。第二個原因是其共識效率低。
擴展知識： 一致性
嚴格一致性，是在系統不發生任何故障，而且所有節點之間的通信無需任何時間這種理想的條件下，才能達到。這個時候整個系統就等價於一台機器了。在現實中，是不可能達到的。
強一致性，當分布式系統中更新操作完成之後，任何多個進程或線程，訪問系統都會獲得最新的值。
弱一致性，是指系統並不保證後續進程或線程的訪問都會返回最新的更新的值。系統在數據成功寫入之後，不承諾立即可以讀到最新寫入的值，也不會具體承諾多久讀到。但是會盡可能保證在某個時間級別（秒級）之後。可以讓數據達到一致性狀態。
最終一致性是弱一致性的特定形式。系統保證在沒有後續更新的前提下，系統最終返回上一次更新操作的值。也就是說，如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性。
在股權證明PoS模式下，有一個名詞叫幣齡，每個幣每天產生1幣齡，比如你持有100個幣，總共持有了30天，那麼，此時你的幣齡就為3000，這個時候，如果你發現了一個PoS區塊，你的幣齡就會被清空為0。你每被清空365幣齡，你將會從區塊中獲得0.05個幣的利息(假定利息可理解為年利率5%)，那麼在這個案例中，利息 = 3000 * 5% / 365 = 0.41個幣，這下就很有意思了，持幣有利息。
點點幣（Peercoin）是首先採用權益證明的貨幣。，點點幣的權益證明機制結合了隨機化與幣齡的概念，未使用至少30天的幣可以參與競爭下一區塊，越久和越大的幣集有更大的可能去簽名下一區塊。一旦幣的權益被用於簽名一個區塊，則幣齡將清為零，這樣必須等待至少30日才能簽署另一區塊。
PoS機制雖然考慮到了PoW的不足，但依據權益結余來選擇，會導致首富賬戶的權力更大，有可能支配記賬權。股份授權證明機制（Delegated Proof of Stake，DPoS）的出現正是基於解決PoW機制和PoS機制的這類不足。
比特股（Bitshare）是一類採用DPoS機制的密碼貨幣。它的原理是，讓每一個持有比特股的人進行投票，由此產生101位代表 , 我們可以將其理解為101個超級節點或者礦池，而這101個超級節點彼此的權利是完全相等的。如果代表不能履行他們的職責（當輪到他們時，沒能生成區塊），他們會被除名，網路會選出新的超級節點來取代他們。
比特股引入了見證人這個概念，見證人可以生成區塊，每一個持有比特股的人都可以投票選舉見證人。得到總同意票數中的前N個（N通常定義為101）候選者可以當選為見證人，當選見證人的個數（N）需滿足：至少一半的參與投票者相信N已經充分地去中心化。
見證人的候選名單每個維護周期（1天）更新一次。見證人然後隨機排列，每個見證人按序有2秒的許可權時間生成區塊，若見證人在給定的時間片不能生成區塊，區塊生成許可權交給下一個時間片對應的見證人。
比特股還設計了另外一類競選，代表競選。選出的代表擁有提出改變網路參數的特權，包括交易費用、區塊大小、見證人費用和區塊區間。若大多數代表同意所提出的改變，持股人有兩周的審查期，這期間可以罷免代表並廢止所提出的改變。這一設計確保代表技術上沒有直接修改參數的權利以及所有的網路參數的改變最終需得到持股人的同意。
Ripple（瑞波）是一種基於互聯網的開源支付協議，在Ripple的網路中，交易由客戶端（應用）發起，經過追蹤節點（tracking node）或驗證節點（validating node）把交易廣播到整個網路中。
追蹤節點的主要功能是分發交易信息以及響應客戶端的賬本請求。驗證節點除包含追蹤節點的所有功能外，還能夠通過共識協議，在賬本中增加新的賬本實例數據。
Ripple的共識達成發生在驗證節點之間，每個驗證節點都預先配置了一份可信任節點名單，稱為UNL（Unique Node List）。在名單上的節點可對交易達成進行投票。每隔幾秒，Ripple網路將進行如下共識過程：
1）每個驗證節點會不斷收到從網路發送過來的交易，通過與本地賬本數據驗證後，不合法的交易直接丟棄，合法的交易將匯總成交易候選集（candidate set）。交易候選集裡面還包括之前共識過程無法確認而遺留下來的交易。
2）每個驗證節點把自己的交易候選集作為提案發送給其他驗證節點。
3）驗證節點在收到其他節點發來的提案後，如果不是來自UNL上的節點，則忽略該提案；如果是來自UNL上的節點，就會對比提案中的交易和本地的交易候選集，如果有相同的交易，該交易就獲得一票。在一定時間內，當交易獲得超過50%的票數時，則該交易進入下一輪。沒有超過50%的交易，將留待下一次共識過程去確認。
4）驗證節點把超過50%票數的交易作為提案發給其他節點，同時提高所需票數的閾值到60%，重復步驟3）、步驟4），直到閾值達到80%。
5）驗證節點把經過80%UNL節點確認的交易正式寫入本地的賬本數據中，稱為最後關閉賬本（Last Closed Ledger），即賬本最後（最新）的狀態。
在Ripple的共識演算法中，參與投票節點的身份是事先知道的。該共識演算法只適合於許可權鏈（Permissioned chain）的場景。Ripple共識演算法的拜占庭容錯（BFT）能力為（n-1）/5，即可以容忍整個網路中20%的節點出現拜占庭錯誤而不影響正確的共識。
在區塊鏈網路中，由於應用場景的不同，所設計的目標各異，不同的區塊鏈系統採用了不同的共識演算法。一般來說，在私有鏈和聯盟鏈情況下，對一致性、正確性有很強的要求。一般來說要採用強一致性的共識演算法。而在公有鏈情況下，對一致性和正確性通常沒法做到百分之百，通常採用最終一致性（Eventual Consistency）的共識演算法。
共識演算法的選擇與應用場景高度相關，可信環境使用paxos 或者raft，帶許可的聯盟可使用pbft ，非許可鏈可以是pow，pos，ripple共識等，根據對手方信任度分級，自由選擇共識機制。