⑴ Tendermint 共識演算法
分布式一致性演算法一般可以分為兩類：拜占庭容錯和非拜占庭容錯。
非拜占庭容錯演算法如 Paxos, Raft 等在當前的分布式系統中已經廣泛使用，而拜占庭容錯演算法的實際應用范圍相對來說小很多(特別是在區塊鏈問世之前)。
Tendermint 屬於拜占庭容錯演算法，它針對傳統的 PBFT 演算法做了優化，只需要有兩輪投票即可達成共識，目前 Tendermint 演算法主要應用在區塊鏈系統中，這篇文章就從原理上來介紹 Tendermint 的共識機制。
關於 Tendermint 演算法的完整描述在 這里 。
這里先介紹一下演算法的流程，理解了演算法流程之後，再來闡述該演算法的安全性證明 (Proof of Safty) 和活性證明 (Proof of Liveness)。
下面這張圖是 tendermint 狀態轉換圖
演算法主要有 NewHeigh -> Propose -> Prevote -> Precommit -> Commit 一共 5 個狀態（階段）。
上述每個狀態都被稱為一個 Step，首尾的 NewHeigh 和 Commit 這兩個 Steps 被稱為特殊的 Step，而中間加粗體的三個 Steps 則被稱為一個 Round，是共識階段，也是也是演算法的核心原理所在。
需要注意的是，一個塊的最終提交（Commit）可能需要多個 Round 過程，這是因為有許多原因可能會導致當前 Round 不成功（比如出塊節點 Offline，提出的塊是無效塊，收到的 Prevote 或者 Precommit 票數不夠 +2/3 等等），出現這些情況的話，解決方案就是移步到下一輪，或者增加 timeout 時間）。
這里，還要介紹一個重要概念：PoLC，全稱為 Proof of Lock Change，表示在某個特定的高度和輪數(height, round)，對某個塊或 nil (空塊)超過總結點 2/3 的 Prevote 投票集合，簡單來說 PoLC 就是 Prevote 的投票集。
Tendermint 中有兩種類型的節點，Validator 節點和 Non-Validator 節點，顧名思義，只有 Validator 節點會參與共識投票，而普通節點作為 Non-Validator 節點，不參與共識投票，只協助傳遞狀態或向 Validator 節點發送交易請求。
初始狀態下（創世塊），高度為 0， 此時，系統會基於 Round Robin 原則來選出一個 Validator（每個 Validator 都有一定的 Voting Power），由這個 Validator 打包一個新的 Block， 並向所有節點發出 Proposal，剩餘的 Validator 節點對該 Proposal 進行投票，最終達成共識。
以下，分階段來闡述各個階段:
當上一輪 Commit 結束，就會出現新高度，這是就需要進入下一輪共識了，也就是說，這就是新一輪共識過程的開始，這時候需要選出一個 Proposer。選擇演算法是 Round Robin，基於他們的 Voting Power（上一輪的選中的 Validator 節點會把其 Voting Power 值減去 Total Voting Power，也就是說上一輪的 Validator 在這一輪，其 Voting Power 會變成負數）。
在 Propose 節點開始的時候，該輪指定的 proposer 需要通過 gossip 廣播一條 proposal 到所有的 peers。如果此時這個 proposer 被鎖在上一輪的某個 block 上，那麼它就直接 propose 那個 block，同時包含一條 proof of lock 的信息。
Validator 節點收到 propose 信息之後就進入 Prevote 投票階段。投票時，如果 Validator 被鎖在之前一個 block 上，那麼還是給之前那個 block 投 prevote 票，否則就投當前的 block。同時，它會繼續收集對這個 block 的 prevote 投票，等輪到他 propose 的時候打包進 PoLC。
注意：
如果自己有 Lock-Block，這時又收到一個新的針對另外一個塊的 PoLC，並且滿足LastLockRound < PoLC-Round < 當前 Round，則解鎖 Lock-Block。
如果 timeout 期間沒收到 proposal，或者收到的 proposal 是無效的，那麼就投 nil 票。
在 Prevote 階段不會鎖住任何 block。
Prevote 超時或者收到的 Prevote 的 nil 票超過 2/3 時，就進入 Precommit 階段。
如果此時收到了 +2/3 的 prevote 投票，就廣播一條 precommit 投票，同時， 把自己鎖在當前的 block 上（把之前的都釋放掉） 。一個節點一次只能鎖在一個塊上。
如果收到 +2/3 的 nil 投票，那麼就釋放鎖。
當一個節點鎖在一個 block 上的時候（有 PoLC） ，它會將 LastLockRound 置為當前 Round，並對這個塊投 Precommit 票。
如果有針對 nil 票的 PoLC，則解鎖並且對 nil 投 Precommit 票；否則的話保持 Lock-Block 不變，並投 nil 。
如果在 timeout 期間內，沒有收到對某個塊的足夠的 +2/3 投票（prevote 或者 nil 都行），那麼就什麼也不幹。
最終，如果一個節點收到了 +2/3 的 precommit 投票，就進入 Commit 階段。否則，繼續進入下一輪的 Propose 階段。
Commit 階段是一個特殊階段，有兩個並行的條件必須滿足：
At any time ring the consensus process if a node receives more than 2/3 of commits for a particular block, it immediately enters the Commit step if it hadn』t already. Thus there are two ways to enter the Commit step. A commit-vote for a block at round R counts as prevotes and precommits for all rounds R0 where R < R0 . Commit-votes are gossipped to neighboring peers in the background re-gardless of the current round or step。
At any time ring the consensus process if a node is locked on a block from round R but receives a proof-of-lock for a round R0 where R < R0 , the node unlocks.
Tendermint 的安全性就是說，在對高度為 H 的塊達成共識之後，不可能會出現新的高度為 H 的塊，也就是說 Tendermint 保證不會分叉，保證不會分叉的主要角色就是 Lock-Block。
先看下wiki對於安全性證明的描述：
Assume that at most -1/3 of the voting power of validators is byzantine. If a validator commits block B at
round R, it's because it saw +2/3 of precommits at round R. This implies that 1/3+ of honest nodes are still
locked at round R' > R. These locked validators will remain locked until they see a PoLC at R' > R, but this
won't happen because 1/3+ are locked and honest, so at most -2/3 are available to vote for anything other
than B.
翻譯：
假定有最多小於總結點 1/3 的拜占庭節點。如果一個節點在第 R 輪提交一個塊，則表明此節點在第 R 輪收到大於 2/3 的針對此塊的 Precommit 投票。這也就意味有
大於1/3 的誠實節點在第 R』 (R' > R)輪仍然鎖定在這個塊上(因為大於 2/3 的 Precommit 投票必定包含大於 1/3 誠實節點的 Precommit 投票)。只有當遇到針對另一個
塊的 PoLC 時才會解鎖，但是在 R' 輪是不可能有針對某個塊的 PoLC，因為已經有大於 1/3 的誠實節點已經鎖定在這個塊上，所以就不可能有對另外一個塊大於 2/3
的 Prevote 投票。
下面給出較為詳細的證明過程，假設高度為 H 的塊 b 在第 R 輪達成共識。給出如下條件：
需要證明， 當 x 個節點 commit 之後，剩餘(也就是 y + z)的沒有 Commit 塊 b 的節點不會對另外一個塊達成共識。
也就是說需要證明：y + z - z0 < 2/3，假設所有的拜占庭節點都對 b 投了 Precommit，則滿足：x + y + z0 > 2/3。
簡而言之，要從 x + y + z0 > 2/3 證明 y + z - z0 < 2/3。
我們通過反證法來證明：
假設 y + z - z0 > 2/3，也就是在第 r 輪之後有可能造成分叉，則：
x + y + z - z0 > 2/3 + x => 1 - z0 > 2/3 + x => x + z0 < 1/3。
而上面我們提到了，因為x節點已經 Commit 塊 b，則 x + y + z0 > 2/3，且 y < 1/3，則說明 x + z0 必須大於1/3。由此證明，y + z - z0 < 1/3 成立，在第 R 輪之後無法對另一個塊達成共識，也就不可能出現分叉。
活性證明相對來說就要簡單一些，假設多於 1/3 的節點分別 Lock 在不同的塊上，則在 Prevote 階段的條件保證最終 round 較小的會 unlock，而且 proposal 的超時時間會隨著輪數的提高而提高。
在證明安全性的過程中提到，有可能會有部分節點由於沒有收到足夠的 Precommit 投票導致無法 commit，這個時候可以通過同步來使各個節點的狀態盡量保持一致，在wiki中提到一個 JSet 和 VSet 的概念，當節點已經 commit 時，就可以廣播一條消息攜帶 VSet 給其他節點，其他節點驗證對於塊的 commit 是否有效。這一點其實和 bft-raft （另外一個拜占庭容錯演算法，Raft 演算法的變種）的做法類似。
⑵ Quorum介紹（二）：Quorum共識
我們知道，公共區塊鏈是一個開放的社區，任何人都能夠成為一個節點加入網路，在網路中計算，提交交易到鏈上等，因此公鏈是沒有信任基礎的，所以公鏈的共識第一要義就是證明交易的合法性和真實性，防止惡意成員的搗亂，效率不是第一要義。
與公鏈的環境不同，有準入門檻的企業鏈或者聯盟鏈鏈上的所有成員在加入時實際上是已經獲得了某些認可和許可的，因此企業鏈/聯盟鏈上的成員是有一定信任基礎的。在企業級鏈上我們沒有必要使用POW或者POS這種浪費算力或者低效的交易共識。
Quorum提供了多種共識供用戶採用：
在講Raft前，有必要提一下Paxos演算法，Paxos演算法是Leslie Lamport於1990年提出的基於消息傳遞的一致性演算法。然而，由於演算法難以理解，剛開始並沒有得到很多人的重視。其後，作者在八年後，也就是1998年在ACM上正式發表，然而由於演算法難以理解還是沒有得到重視。而作者之後用更容易接受的方法重新發表了一篇論文《Paxos Made Simple》。
可見，Paxos演算法是有多難理解，即便現在放到很多高校，依然很多學生、教授都反饋Paxos演算法難以理解。同時，Paxos演算法在實際應用實現的時候也是比較困難的。這也是為什麼會有後來Raft演算法的提出。
Raft是實現分布式共識的一種演算法，主要用來管理日誌復制的一致性。它和Paxos的功能是一樣，但是相比於Paxos，Raft演算法更容易理解、也更容易應用到實際的系統當中。而Raft演算法也是聯盟鏈採用比較多的共識演算法。
Raft一共有三種角色狀態：
每個節點上都有一個倒計時器 (Election Timeout)，時間隨機在 150ms 到 300ms 之間。有幾種情況會重設 Timeout：
在分布式系統中，「時間同步」是一個很大的難題，因為每個機器可能由於所處的地理位置、機器環境等因素會不同程度造成時鍾不一致，但是為了識別「過期信息」，時間信息必不可少。
Raft演算法中就採用任期（Term）的概念，將時間切分為一個個的Term（同時每個節點自身也會本地維護currentTerm），可以認為是邏輯上的時間，如下圖。
每一任期的開始都是一次領導人選舉，一個或多個候選人（Candidate）會嘗試成為領導（Leader）。如果一個人贏得選舉，就會在該任期（Term）內剩餘的時間擔任領導人。在某些情況下，選票可能會被評分，有可能沒有選出領導人（如t3），那麼，將會開始另一任期，並且立刻開始下一次選舉。Raft 演算法保證在給定的一個任期最少要有一個領導人。
特殊情況的處理
在以太坊中節點本身並沒有角色，因此在使用Raft共識時，我們稱leader節點為挖礦節點：
Raft共識機制本身保證了同一時間點最多隻有一個leader，因此用在以太坊模型下也只會有一個出塊者，避免了同時出塊或者算力浪費的情況。
在單筆交易(transaction)層級Quorum依然沿用了Ethereum的p2p傳輸機制，只有在塊(block)層級才會使用Raft的傳輸機制。
其中需要注意到一點，在以太坊中一個節點收到塊以後就會立刻記賬，而在Quorum模型中，一個塊的記錄必須遵從Raft協議，每個節點從leader處收到塊以後必須報告給leader確認收到以後，再由leader通知各個節點進行數據提交（記錄）
在Quorum模型中新塊的信息是很有可能和已有塊的header信息不符的，最容易發生這種情況的就是選舉人更替(挖礦節點更替)，具體描述如下：
假設有兩個節點，node1和node2，node1是現有的leader，現有鏈的最新區塊是0xbeda，它的父區塊是0xacaa
對塊「Extends」或者「No-op」的標記是在更上層完成的，並不由raft本身log記錄機制實現。因為在raft內部，信息並不分為有效或無效，只有在區塊鏈層面才會有有效區塊和無效區塊的含義。
需要注意的是，Quorum的這種記賬機制和本身Ethereum的LVC（最長鏈機制）是完全不一樣的
Quorum的出塊頻率默認是50ms一個塊，可以通過 --raftblocktime 參數進行設置
投機性出塊並不是以太坊Raft共識嚴格必須的核心機制之一，但是是提高出塊效率的有效方式。
一個塊從產生到實際被記錄賬本，走完整個raft流程實際上是需要耗費一定時間的。如果我們在上一個塊被計入賬本之後才開始產生下一個塊，那麼一筆交易想要成功被記錄需要耗費較多的時間。
而在投機性(speculative minting)出塊中，我們允許一個新塊在它的父塊被記錄之前就產生。依次類推，在一段時間內，實際上會產生「投機鏈（speculative chain）」，在祖先塊沒有被記錄進賬本之前，一個一個新塊已經依據先後關系組成了一條臨時鏈片段，等待被記錄。
對於已經被記錄進投機塊的交易，我們會在交易池中標記為「proposed transaction」
在之前我們說過，raft機制中是存在兩個挖礦節點比賽出塊和記賬的可能的，因此，一條 speculative chain 中間的某一個塊很有可能不會被記錄到賬本中。在這種情況下我們也會把交易池中的交易狀態修改回來。( InvalidRaftOrdering event)
目前，Quorum並沒有對speculative chain的長度做限制，但在它的未來規劃中有講這一點作為一個性能優化項加入開發進程，最後能夠讓一個挖礦節點即使在raft共識層沒有連接上，它也可以離線一直出塊，產生自己的speculative chain。
一條speculative chain有以下幾個部分構成：
在塊傳輸上我們使用etcd Raft默認的http傳輸，當然使用Ethereum的p2p傳輸也是可以的，但是Quorum團隊在測試階段發現，高負載的狀態下，ETH p2p的性能沒有raft p2p性能好。
Quorum使用50400埠作為Raft 傳輸層的默認監聽埠，也可以通過 --raftport 參數自行設置。
一個集群默認的最大節點個數是25，可以通過 --maxpeers N 來設置，N是你的最大節點個數。
Quorum的IBFT其實就是PBFT，只不過摩根大通把它自己實現的PBFT叫做IBFT，所以IBFT的基本原理與PBFT是一樣的，所不同的是,IBFT中把出塊和共識的三階段結合在了一起。
Istanbul BFT修改自PBFT演算法，包括三個階段： PRE-PREPARE 、 PREPARE 以及 COMMIT 。在 N 個節點的網路中，這個演算法可以最多容忍 F 個出錯節點，其中 N=3F+1 。
Istanbul BFT演算法中的區塊是確定的，意味著鏈沒有分叉並且合法的區塊一定是在鏈中。為了防止一個惡意節點生成不同的鏈，在把區塊插入進鏈 之前 ，每一個validator必須把 2F + 1 個 COMMIT 簽名放進區塊頭的 extraData 欄位。因此，區塊是可以自我驗證的（因為有簽名）並且輕客戶端也支持。
然而動態的 extraData 也會造成區塊的hash計算問題。因為一個區塊可以被不同的validator驗證，所以會有不同的簽名，所以同一個區塊會有不同的hash。解決的方案是，計算區塊hash的時候把 COMMIT 簽名排除在外。因此我們任然可以在保證block hash一致性的同時進行共識驗證。
由於Ethereum POA共識在網上已經有大量介紹，筆者這里就不多做詳細介紹，只對重要特點和POA的工作流程做大致梳理和介紹
⑶ 極簡Grin挖礦指南（Win10）
Grin不多重復介紹了，近期很火的一個匿名幣（ https://grin-tech.org/ ），而且還能用CPU、GPU挖礦（N卡。目前似乎還不支持A卡），並且支持多個平台Linux、macOS等等。官網上說不支持Windows，但實際是可以跑的。下面是Windows 10上的部署過程小結。
Windows上用WSL來部署Linux的環境最為方便。在Microsoft Store中搜索Ubuntu即可安裝。
注意！ 裝完之後要修改一下注冊表。不然因為這個內嵌的Ubuntu會帶很多奇怪的Path，導致後面build會出問題，產生不了運行所需的plugin文件夾。
具體步驟是：運行regedit。在注冊表項中，找到 ComputerHKEY_CURRENT_ 將Flag的值改為 5 。
運行Ubuntu，新建用戶名、並輸入自己想要設置的密碼
Grin是用rust編寫的，安裝好相關環境
再安裝好其他依賴
Grin節點也和其他區塊鏈類似，可以自己部署也可以利用礦池。兩種方式選一即可。
如果要自己運行一個Grin節點，按照以下步驟：
target/release/grin 即為可運行文件
目前也有一些Grin的礦池可以鏈接，不想自己運行Grin的話，可以注冊一個。比較有名的是GRIN-Pool（ https://mwgrinpool.com/ ）
點右上角Login後按提示注冊即可。自己需要記住用戶名和密碼。
另開一個Ubuntu的終端，輸入：
檢查你CPU是否支持avx2
如果大於0，那麼輸入以下：
如果是多核，可以指定挖礦的核數（build後每次運行前也可以修改）
查看有多少個可用的CPU，並輸入想使用的CPU數量
如果是N卡，可以用GPU挖礦
然後輸入 nvidia-smi 運行後得到的Device ID
如果用的是礦池，還要額外配置一下礦池信息：
輸入在礦池裡注冊的用戶名和密碼
先build
然後運行
如果一切順利，現在已經可以挖礦了；如果不順利，那麼我也不知道了。
https://github.com/mimblewimble/grin
https://github.com/mimblewimble/grin-miner
https://medium.com/@blade.doyle/cpu-mining-on-mwgrinpool-com-how-to-efb9ed102bc9
https://medium.com/@blade.doyle/gpu-mining-on-mwgrinpool-com-how-to-72970e550a27
⑷ 鐭挎睜闅懼害鍊兼庝箞鏍風畻
鐭挎睜闅懼害鍊兼庝箞綆楃殑
鐭挎睜闅懼害鍊兼槸涓涓鐢ㄤ簬鎻忚堪鍔犲瘑璐у竵鎸栫熆闅懼害鐨勬寚鏍囷紝瀹冩槸鏍規嵁鍖哄潡閾懼崗璁鐨勮勫垯鍜岀畻娉曟潵璁＄畻鐨勩
鍦ㄦ瘮鐗瑰竵鎸栫熆涓錛岀熆奼犻毦搴﹀肩殑璁＄畻榪囩▼濡備笅錛
紜瀹氬尯鍧楅摼鍗忚涓瑙勫畾鐨勬寲鐭塊毦搴﹁＄畻鍏寮忋
姣旂壒甯佸崗璁涓鐨勬寲鐭塊毦搴﹁＄畻鍏寮忎負錛歞ifficulty=difficulty\_1\_target/current\_target
鍏朵腑錛宒ifficulty\_1\_target鏄涓涓甯擱噺錛岃〃紺烘寲鍒頒竴涓鏂板潡鎵闇鐨勬渶灝忓搱甯屽礆紱current\_target鏄褰撳墠鎸栧埌鐨勫潡鐨勫搱甯屽箋
紜瀹氳＄畻鍛ㄦ湡銆
鍦ㄦ瘮鐗瑰竵鍗忚涓錛岄毦搴﹀兼槸姣2016涓鍧楋紙澶х害涓ゅ懆錛夎皟鏁翠竴嬈°
緇熻¤＄畻鍛ㄦ湡鍐呯殑鍧楁暟鍜屾椂闂淬
瀵逛簬姣忎釜璁＄畻鍛ㄦ湡錛岀熆奼犻渶瑕佽板綍鏈鍛ㄦ湡鍐呮寲鍑虹殑鍧楁暟鍜屾寲鐭挎椂闂淬
璁＄畻鐭挎睜闅懼害鍊箋
鏍規嵁涓婅堪鍏寮忥紝灝嗘湰鍛ㄦ湡鍐呮寲鍑虹殑鍧楁暟鍜屾寲鐭挎椂闂翠唬鍏ヨ＄畻錛屽緱鍑烘湰鍛ㄦ湡鐨勭熆奼犻毦搴﹀箋
鐭挎睜闅懼害鍊肩殑璁＄畻浼氭牴鎹涓嶅悓鐨勫姞瀵嗚揣甯佸拰鍖哄潡閾懼崗璁鑰屾湁鎵涓嶅悓錛屼絾閮介伒寰綾諱技鐨勮＄畻鏂規硶銆
⑸ 小狐狸錢包怎麼添加BSC網路MetaMask添加幣安鏈教程
說起數字錢包，可能很多人都使用過那款會跟隨你的滑鼠伏叢物轉動腦袋的小狐狸錢包，沒錯，就是MetaMask。MetaMask的使用非常方便，它可以作為一個插件直接安裝在谷歌瀏覽器上，體量很小，又因其可愛的小狐狸logo廣受投資者的喜愛。除此之外，MetaMask還可以直接在你的電腦桌面上與很多DAPP進行交互，在你使用DAPP時還可以直接使用MetaMask支付，MetaMask會直接跳轉出來，很是方便。最近有很多人問小狐狸錢包怎麼添加BSC網路？幣圈子小編已經為大家准備好了MetaMask添加幣安鏈教程。缺液
小狐狸錢包怎麼添加BSC網路？
1. 安裝MetaMask(小狐狸)錢包
暢游DeFi世界第一重要工具鄭鏈：MetaMask(小狐狸)錢包，下面這個教程我覺得已經很詳細了，直接按照它來就行，記得一定要使用谷歌瀏覽器：
裝好小狐狸錢包之後，就可以用中心化交易所往錢包裡面轉ETH了，等錢包收到ETH，就可以開啟DeFi之旅。但對於新手來說，ETH的手續費實在讓人難以接受，所以教程用BSC舉例。ETH和HECO操作都類似。
2. 配置BSC環境
(1)設置成中文模式
點上圖紅圈進去後，Settings - General - Current Language 選擇中文就行。
(2)添加BSC網路
按順序點擊下面的紅圈
把下面的信息填入，點擊保存即可。
網路名稱：Binance Smartchain
RPC URL：https://bsc-dataseed.binance.org/
ID：56
符號：BNB
URL：https://.bscscan.com/
之後我們就可以看到
點擊，切換到BSC網路。到這里，BSC的網路就配置好了。
3. 從幣安往小狐狸賬戶裡面轉BNB和USDT
小狐狸賬戶的地址，點擊紅框就可以復制了：
bnb用來支付手續費，一般0.1個就夠。提幣時，記得選BSC
USDT也要選BSC
4.選礦
已經成熟的礦可以去 defibox.com 裡面找，這次教程，我們從BSC專區裡面選擇ACS。每個礦不同，之所以選這個是因為我挖過，比較熟。
5. 挖礦
從defibox跳轉進入ACS的頁面，先點連接錢包
之後選擇一個礦池，比如USDT，點擊存入：
注意，它這里有個提款費0.5%，是從本金裡面扣的，所以不要頻繁出入。每個礦的收費不同，挖之前一定要看清楚，不然可能遇到直接收99%的情況。
點擊存入後，在小狐狸中確認2次。
完事之後，點擊入流動資金池
也要在小狐狸中確認2次。然後就變成這樣了。
再之後就等著收ACS，等ACS大於0.03之後，就會有收取按鈕。
點擊收取，在小狐狸中確認，然後就獲得了ACS。
6. 使用pancake把收到的ACS賣掉
pancake的鏈接是：exchange.pancakeswap.finance
當然也可以從defibox.com裡面找到pancake跳轉過去
我們輸入ACS搜索發現並沒有
這個時候我們需要輸入合約地址搜索才行。基本上每個新礦賣的時候都需要找到它的合約地址，可以到官方文檔、官方電報群裡面找。
這里我們偷個懶，直接在ACS網站上跳過去：
這個跳轉時間需要比較長。等完成後，可以看到：
然後點下紅圈位置，換個位置，就可以把ACS換成BNB了
當然也可以換成其他，自己選就行了。
最後小編提醒投資者，在挑選數字貨幣錢包時必須特別謹慎，仔細了解某一個數字貨幣錢包工具的開發團隊、存續時間及網路評價等方面，這樣才有可能挑選到比較靠譜的數字貨幣錢包工具，當然，除了這幾個方面的因素之外，挑選貨幣錢包時還需要了解錢包的安全防護技術和手續費用的高低，盡量挑選安全且費用比較低的進行使用。
metamask錢包怎麼樣？
作為一款數字資產錢包，MetaMask 在使用上的注意事項和其他錢包相同，和現在很多手機錢包需要綁定用戶數據、郵箱相比，MetaMask 使用簡便，不需要綁定用戶信息便可創建錢包。官方視頻(https://metamask.io)也提供了詳細的使用說明，
除了錢包功能之外，對用戶來說，MetaMask 的獨到之處是可以直接和很多桌面端 DApp 進行交互，實現了一鍵登錄和互動，這一過程和微信或支付寶的第三方認證流程非常相似。我們先看一個 DApp 登錄流程示例(假設你已安裝了 MetaMask 控制項)：
打開 MakerDAO(一款穩定幣 DApp)的應用界面(https://cdp.maker.com/)，登錄時，頁面會提示你需要先連接到一個錢包(下圖左邊)，你會看到 MetaMask 是第一選項(其餘兩項為硬體錢包)，點擊 MetaMask 後，彈出的頁面請求將 MetaMask 和應用進行連接(下圖右邊)，確認連接後即成功登錄 MakerDAO，同時也正確顯示了錢包里的余額。
其他以太坊 DApp 的使用流程也都類似，可以說，MetaMask 已經成為以太坊 DApp 應用的接入標准了。
用這種方式成功登錄後，在使用 DApp 過程中如涉及到錢包轉賬，也都會觸發調用 MetaMask 的轉賬界面，交互過程自然順滑，完全不會有以前使用錢包轉賬的心理障礙。
Metamask 的一鍵登錄和交互用戶體驗直接簡便，不過因為簡便也存在著惡意欺詐的風險，所以 Metmask 在 2018 年底做了個改版，在跳交易頁面之前會先需要第三方確認 。
此外，MetaMask 對於以太坊開發人員來說也非常友好，不需架設以太坊全節點、或安裝專門的客戶端來對接以太坊區塊鏈，就能進行智能合約的開發，支持多個測試網的隨意切換，是以太坊 DApp 開發調試的必用工具。
和其他錢包相比，MetaMask 一直是瀏覽器控制項形式，直到 2018 年 11 月才推出自己的 App。由於形式簡單、使用簡便，MetaMask 的安全問題也常被拿來討論。
其實和其他數字錢包一樣，MetaMask 並不保管用戶數據，風險也主要來自用戶自己對私鑰的保管程度，以及網路釣魚和惡意軟體的攻擊。MetaMask 代碼開源，任何人可以檢查代碼，如果發現問題，可獲得團隊設置的獎勵。
MetaMask 目前推出近3年，下載量超百萬次，這只小狐狸早已成為以太坊上廣為人知的形象了，未來此類集錢包和身份認證於一身的應用也會越來越多。
綜上所述，就是幣圈子小編對於小狐狸錢包怎麼添加BSC網路這一問題的回答，希望可以幫到各位投資者。雖然MetaMask目前在市場上很火爆，但是還是有很多投資者都表示很擔心MetaMask錢包的安全性，其實大家不必過於擔心，MetaMask錢包和其他數字錢包是一樣的，並不保管用戶的數據，只要用戶保管好自己的私鑰，防範惡意軟體的攻擊就不會有什麼問題，還是很安全的。並且MetaMask錢包的代碼是開源的，誰都可以檢查其代碼，甚至有人發現了問題還可以獲得團隊的獎勵。
⑹ 淺析 Fabric Peer 節點
Hyperledger Fabric，也稱之為超級賬本，是由 IBM 發起，後成為 Linux 基金會 Hyperledger 中的區塊鏈項目之一。
Fabric 是一個提供分布式賬本解決方案的平台，底層的賬本數據存儲使用了區塊鏈。區塊鏈平台通常可以分為公有鏈、聯盟鏈和私有鏈。公有鏈典型的代表是比特幣這些公開的區塊鏈網路，誰都可以加入到這個網路中。聯盟鏈則有準入機制，無法隨意加入到網路中，聯盟鏈的典型例子就是 Fabric。
Fabric 不需要發幣來激勵參與方，也不需要挖礦來防止有人作惡，所以 Fabric 有著更好的性能。在Fabric 網路中，也有著諸多不同類型的節點來組成網路。其中 Peer 節點承載著賬本和智能合約，是整個區塊鏈網路的基礎。在這篇文章中，會詳細分析 Peer 的結構及其運行方式。
在本文中，假設讀者已經了解區塊鏈、智能合約等概念。
本文基於 Fabric1.4 LTS。
區塊鏈網路是一個分布式的網路，Fabric 也是如此，由於 Fabric 是聯盟鏈，需要准入機制，所以在網路結構上會復雜很多，下面是一個簡化的 Fabric 網路：
各個元素的含義如下：
對於 Fabric 網路，外部的用戶需要通過客戶端應用，也就是圖中的 A1、A2 或者 A3 來訪問網路，客戶端應用需要通過 CA 證書表明自己的身份，這樣才能訪問到 Fabric 網路中有許可權訪問的部分。
在上面的網路中，共有四個組織，R1、R2、R3 和 R4。其中 R4 是整個 Fabric 網路的創建者，網路是根據 NC4 配置的。
在 Fabric 網路中，不同的組織可以組成聯盟，不同的聯盟之間數據通過 Channel 來隔離。Channel 中的數據只有該聯盟中的組織才能訪問，每一個新的 Channel 都可以認為是一條新的鏈。與其他的區塊鏈網路中通常只有一條鏈不一樣，Fabric 可以通過 Channel 在網路中快速的搭建出一個新的區塊鏈。
上面 R1 和 R2 組成了一個聯盟，在 C1 上交易。R2 同時又和 R3 組成了另外一個聯盟，在 C2 上交易。R1 和 R2 在 C1 上交易時，對 R3 是不可見的，R2 和 R3 在 C2 上交易時，對 R1 是不可見的。Channel 機制提供了很好的隱私保護能力。
Orderer 節點是整個 Fabric 網路共有的，用來為所有的交易排序、打包。比如上面網路中 O4 節點。本文不會對 Orderer 節點進行詳細說明，可以把這個功能理解為比特幣網路中的挖礦過程。
Peer 節點表示網路中的節點，通常一個 Peer 就表示一個組織，Peer 是整個區塊鏈網路的基礎，是智能合約和賬本的載體，Peer 也是本文討論的重點。
一個 Peer 節點可以承載多套賬本和智能合約，比如 P2 節點，既維護了 C1 的賬本和智能合約，也維護了 C2 的賬本和智能合約。
為了可以更深入了解 Peer 節點的作用，先了解一下 Fabric 整體的交易流程。整體的交易流程圖如下：
Peer 節點按照功能來分可以分為 背書節點 和 記賬節點 。
客戶端會提交交易請求到背書節點，背書節點開始模擬執行交易，在模擬執行之後，背書節點並不會去更新賬本數據，而是把這個交易進行加密和簽名，然後返回給客戶端。
客戶端收到這個響應之後就會把響應提交到 Orderer 節點，Orderer 節點會對這些交易進行排序，並打包成區塊，然後分發到記賬節點，記賬節點就會對交易進行驗證，驗證結束之後，就會把交易記錄到賬本裡面。
一筆交易是否能成功是根據背書策略來指定的，每一個智能合約都會指定一個背書策略。
Peer 節點代表著聯盟鏈中的各個組織，區塊鏈網路也是由 Peer 節點來組成的，而且也是賬本和智能合約的載體。
通過對上面交易過程的了解可以知道，Peer 節點是主要的參與方。如果用戶想要訪問賬本資源，都必須要和 peer 節點進行交互。在一個 Peer 節點中，可以同時維護多個賬本，這些賬本屬於不同的 Channel 。每個 Peer 節點都會維護一套冗餘賬本，這樣就避免了單點故障。
Peer 節點根據在交易中的不同角色，可以分成背書節點（Endorser）和記賬節點（Committer），背書節點會對交易進行模擬執行，記賬節點才會真正將數據存儲到賬本中。
賬本可以分成兩個部分，一部分是區塊鏈，另一部分是 Current State，也被稱之為 World State。
區塊鏈上只能追加，不能對過去的數據進行修改，鏈上也包含兩部分信息，一部分是通道的配置信息，另一部分是不可修改，序列化的記錄。每一個區塊記錄前一個區塊的信息，然後連成鏈，如下圖所示：
第一個區塊被稱之為 genesis block，其中不存儲交易信息。每個區塊可以被分為 區塊頭 、 區塊數據 和 區塊元數據 。區塊頭中存儲著當前區塊的區塊號、當前區塊的 hash 值和上一個區塊的 hash 值，這樣才能把所有的區塊連接起來。區塊數據中包含了交易數據。區塊元數據中則包括了區塊寫入的時間、寫入人及簽名。
其中每一筆交易的結構如下，在 Header 中，包含了 ChainCode 的名稱、版本信息。Signature 就是交易發起用戶的簽名。Proposal 中主要是一些參數。Response 中是智能合約執行的結果。Endorsements 中是背書結果返回的結果。
WorldState中維護了賬本的當前狀態，數據以 Key-Value 的形式存儲，可以快速查詢和修改，每一次對 WorldState 的修改都會被記錄到區塊鏈中。WorldState 中的數據需要依賴外部的存儲，通常使用 LevelDB 或者 CouchDB。
區塊鏈和 WorldState 組成了一個完整的賬本，World State 保證的業務數據的靈活變化，而區塊鏈則保證了所有的修改是可追溯和不可篡改的。
在交易完成之後，數據已經寫入賬本，就需要將這些數據同步到其他的 Peer，Fabric 中使用的是 Gossip 協議。Gossip 也是 Channel 隔離的，只會在 Channel 中的 Peer 中廣播和同步賬本數據。
智能合約需要安裝到 Peer 節點上，智能合約是訪問賬本的唯一方式。智能合約可以通過 Go、Java 等變成語言進行編寫。
智能合約編寫完成之後，需要打包到 ChainCode 中，每個 ChainCode 中可以包含多個智能合約。ChainCode 需要安裝，ChainCode 需要安裝到 Peer 節點上。安裝好了之後，ChainCode 需要在 Channel 上實例化，實例化的時候需要指定背書策略。
智能合約在實例化之後就可以用來與賬本進行交互了，流程圖如下：
用戶編寫並部署實例化智能合約之後，就可以通過客戶端應用程序來向智能合約提交請求，智能合約會對 WorldState 中數據進行 get、put 或者 delete。其中 get 操作直接從 WorldState 中讀取交易對象當前的狀態信息，不會去區塊鏈上寫入信息，但 put 和 delete 操作除了修改 WorldState，還會去區塊鏈中寫入一條交易信息，且交易信息不能修改。
區塊鏈上的信息可以通過智能合約訪問，也可以在客戶端應用通過 API 直接訪問。
Event 是客戶端應用和 Fabric 網路交互的一種方式，客戶端應用可以訂閱 Event，當 Event 發生時，客戶端應用就會接受到消息。
事件源可以兩類，一類是智能合約發出的 Event，另一類是賬本變更觸發的 Event。用戶可以從 Event 中獲取到交易的信息，比如區塊高度等信息。
在這篇文章中，首先介紹了 Fabric 整體的網路架構，通過對 Fabric 交易流程的分析，討論了 peer 節點在交易中的作用，然後詳細分析了 peer 節點所維護的賬本和智能合約，並分析了 peer 節點維護賬本以及 peer 節點執行智能合約的流程。
文 / Rayjun
[1] https://hyperledger-fabric.readthedocs.io/zh_CN/release-1.4/whatis.html
[2] https://developer.ibm.com/zh/technologies/blockchain/series/os-academy-hyperledger-fabric/
[3] https://en.wikipedia.org/wiki/Gossip_protocol