⑴ 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