CAP 原理先由 Eric Brewer 在 2千年，ACM 在一个研讨会上提出来的一个猜想，后来 Lynch 等人进行了证明，是在分布式系统方面的一个重要的一个原理。当然定义分布式计算系统的时候确保不了一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition），设计中往往需要弱化对某个特性的保证。一致性（Consistency）：任何操作应该都是原子的，发生在以后的事件就可看到前面事件发生导致的结果，注意这里指的是强一致性；可用性（Availablity）：在有限时间内，任何非失败节点都会应答请求的；分区容忍性（Partition）：网络可能发生分区，即节点之间的这个通信是不可保障的。比较直观地理解，当网络要是出现分区时候，系统是无法同时保证一致性和可用性的。要么，节点发出收到请求后要是没有得到其他人的确认就不应答的，要么这个节点只是应答一个不一致的结果。好在大部分时候网络被是相对比较可靠的，因此系统可以提供一致可靠的服务；当网络出现了不可靠的时候，系统要么牺牲掉一致性（大部分时候都是如此），要么牺牲掉可用性。

应用场景：既然 CAP 不可同时满足，则当初弄系统就要弱化对某个特性的支持；弱化一致性：对结果一致性不敏感的应用，可以允许在新版本上线后过一段时间才更新成功，期间不保证一致性。例如网站里面的静态的内容页面、实时性较差的查询类数据库等，CouchDB、Cassandra 等为此设计；弱化可用性：对结果一致性很敏感的应用，例如银行取款机，当系统故障时候会拒绝服务。MongoDB、Redis 等为此设计。Paxos、Raft 等算法，主要处理这种情况；弱化分区容忍性：现实中，网络分区出现概率减小，但较难避免。某些关系型数据库、ZooKeeper 即为此设计。实践中，网络就要通过双通道等机制来增加可靠性，达到高稳定的网络通信。

ACID 原则：即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。ACID 原则描述了对分布式数据库的一致性需求，同时自然也付出了相对可用性的代价。Atomicity：每次操作是原子的，要么成功，要么不执行；Consistency：数据库的状态现在是一致的，无中间状态；Isolation：各种操作彼此互相不影响；Durability：状态的改变是持久的，不会失效。一个与之相对的原则是 BASE（Basic Availiability，Soft state，Eventually Consistency），牺牲掉对一致性的约束（最终一致性），来换取一定的可用性。

Paxos 与 Raft：Paxos 指的是指分布式的系统中里面的一些故障（fault），但不存在恶意（corrupt）节点场景（即可能消息丢失或重复，但无错误消息）下的共识达成（Consensus）问题。因为最早是 Leslie Lamport 用 Paxon 岛的故事模型来进行描述而命名；Paxos：1990 年由 Leslie Lamport 提出的 Paxos 共识算法，在工程角度体现了最大化保障分布式系统这种一致性（存在极小的概率无法实现一致）的机制。Paxos 被广泛应用在 Chubby、ZooKeeper 这样的系统中，Leslie Lamport 因此获得了 2013 年度图灵奖。故事背景是古希腊 Paxon 岛上的多个法官在一个大厅内对一个议案进行表决，如何达成统一的结果。他们之间通过服务人员来传递纸条，但法官可能离开或进入大厅，服务人员可能偷懒去睡觉。Paxos 是第一个被证明的共识算法，其原理基于 两阶段提交 并进行扩展。作为现在共识算法设计的一个领军，以最初论文的难懂（算法本身并不复杂）出名。

算法中将节点分为三种类型：proposer：提出一个提案，等待大家批准为结案。往往是客户端担任该角色；acceptor：负责对提案进行投票。往往是服务端担任该角色；learner：被告知结案结果，并与之统一，不参与投票过程。可能为客户端或服务端。并且，算法需要满足 safety 和 liveness 两方面的约束要求（实际上这两个基础属性是大部分分布式算法都该考虑的）：safety：保证决议结果是对的，无歧义的，不会出现错误情况。决议（value）只有在被 proposers 提出的 proposal 才能被最终批准；在一次执行实例中，只批准（chosen）一个最终决议，意味着多数接受（accept）的结果能成为决议；liveness：保证决议过程能在有限时间内完成。决议总会产生，并且 learners 能获得被批准（chosen）的决议。基本过程包括 proposer 提出提案，先争取大多数 acceptor 的支持，超过一半支持时，则发送结案结果给所有人进行确认。一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的 proposer 都恰好故障，系统可能就永远无法达成一致（概率很小）。Paxos 能保证在超过 二分之一的正常节点存在时，系统能达成共识。读者可以试着自己设计一套能达成共识的方案，会发现在满足各种约束情况下，算法自然就会那样设计。

Raft 算法：是Paxos 这个算法的一个简化实现。包括三种角色：leader、candidate 和 follower，其基本过程为：Leader 选举：每个 candidate 随机经过一定时间都会提出选举方案，最近阶段中得票最多者被选为 leader；同步 log：leader 会找到系统中 log 最新的记录，并强制所有的 follower 来刷新到这个记录；

准备阶段：提案者发送自己计划提交的提案的编号到多个接受者，试探是否可以锁定多数接受者的支持。接受者时刻保留收到过提案的最大编号和接受的最大提案。如果收到的提案号比目前保留的最大提案号还大，则返回自己已接受的提案值（如果还未接受过任何提案，则为空）给提案者，更新当前最大提案号，并说明不再接受小于最大提案号的提案。提交阶段：提案者如果收到大多数的回复（表示大部分人听到它的请求），则可准备发出带有刚才提案号的接受消息。如果收到的回复中不带有新的提案，说明锁定成功，则使用自己的提案内容；如果返回中有提案内容，则替换提案值为返回中编号最大的提案值。如果没收到足够多的回复，则需要再次发出请求。接受者收到接受消息后，如果发现提案号不小于已接受的最大提案号，则接受该提案，并更新接受的最大提案。一旦多数接受了共同的提案值，则形成决议，成为最终确认的提案；我先说到这吧明天再说，以前的文章大家可以自行翻看

我之前有一些文章讲到了一些开发方面的一些大体需要的一些方法知识和技巧，开发这个货币交易所涉及的开发语言也很多，需要的注意的也很多，下面的文章我将会按照顺序来讲，今天先说一下PKI 体系和闪电网络和共识机制这三个方面，话不多说看下面的文章 交易要经过的记账流程是这样的 大家看图片

RSMC：Recoverable Sequence Maturity Contract，中文可以翻译为“可撤销的顺序成熟度合同”。这个词很绕，其实主要原理很简单，就是类似准备金机制。我们先假定交易双方之间存在一个“微支付通道”（资金池）。双方都必须要放一些资金到“微支付通道”里，之后每次交易，就对交易后的资金分配方案共同进行确认，同时签字作废旧的版本。当需要提现时，将最终交易结果写到区块链网络中，被最终确认。可以看到，只有在提现时候才需要通过区块链。任何一个版本的方案都需要经过双方的签名认证才合法。任何一方在任何时候都可以提出提现，提现需要提供一个双方都签名过的资金分配方案（意味着肯定是某次交易后的结果）。在一定时间内，如果另外一方提出证明表明这个方案其实之前被作废了（非最新的交易结果），则资金罚没给质疑成功方。这就确保了没人会拿一个旧的交易结果来提现。另外，即使双方都确认了某次提现，首先提出提现一方的资金到账时间要晚于对方，这就鼓励大家尽量都在链外完成交易。

HTLC：微支付通道是通过 Hashed Timelock Contract 来实现的，中文意思是“哈希的带时钟的合约”。这个其实就是限时转账。理解起来其实也很简单，通过智能合约，双方约定转账方先冻结一笔钱，并提供一个哈希值，如果在一定时间内有人能提出一个字符串，使得它哈希后的值跟已知值匹配（实际上意味着转账方授权了接收方来提现），则这笔钱转给接收方。不太恰当的例子，约定一定时间内，有人知道了某个暗语（可以生成匹配的哈希值），就可以拿到这个指定的资金。推广一步，甲想转账给丙，丙先发给甲一个哈希值。甲可以先跟乙签订一个合同，如果你在一定时间内能告诉我一个暗语，我就给你多少钱。乙于是跑去跟丙签订一个合同，如果你告诉我那个暗语，我就给你多少钱。丙于是告诉乙暗语，拿到乙的钱，乙又从甲拿到钱。最终达到结果是甲转账给丙。这样甲和丙之间似乎构成了一条完整的虚拟的“支付通道”。
HTLC 的机制可以扩展到多个人，大家可以想象一下，想象出来了就理解了闪电网络。

共识机制：数字货币比特币的网络是公开的，因此共识协议的稳定性和防攻击性十分关键。数字货币的鼻祖的区块链技术采用了 Proof of Work（PoW）的机制来实现共识，该机制于 1998 年在 B-money 设计中提出。目前，Proof of 系列中比较出名的一致性协议包括 PoW 和 PoS，都是通过经济惩罚来限制恶意参与。
PoW：工作量证明，Proof of Work，通过计算来猜测一个数值（nonce），得以解决规定的 hash 问题（来源于 hashcash）。保证在一段时间内，系统中只能出现少数合法提案。同时，这些少量的合法提案会在网络中进行广播，收到的用户进行验证后会基于它认为的最长链上继续难题的计算。因此，系统中可能出现链的分叉（Fork），但最终会有一条链成为最长的链。hash 问题具有不可逆的特点，因此，目前除了暴力计算外，还没有有效的算法进行解决。反之，如果获得符合要求的 nonce，则说明在概率上是付出了对应的算力。谁的算力多，谁最先解决问题的概率就越大。当掌握超过全网一半算力时，从概率上就能控制网络中链的走向。这也是所谓 51% 攻击 的由来。参与 PoW 计算比赛的人，将付出不小的经济成本（硬件、电力、维护等）。当没有成为首个算出的“幸运儿”时，这些成本都将被沉没掉。这也保障了，如果有人恶意破坏，需要付出大量的经济成本。也有设计试图将后算出结果者的算力按照一定比例折合进下一轮比赛考虑。
我今天就先说道这里，以前的文章大家可以自行翻看

前面我写过很多文章关于怎么开发语言开发货币交易所的，包括要用到什么代码，什么步骤需要什么方法等等，由于篇幅很长，开发这个不是一键简单的事情，我平时也比较忙，所以也都是大致讲一下开发这个需要一整套的技术不是单独开发一个东西这么简单，也是不是单独使用一个开发语言就可以完成的事情，当然了大家可以相互交流，我们自己写这个也是出于一中热爱吧希望可以帮助到大家，我今天和大家说一下怎么搭建货币钱包的需要什么怎么分辨钱包的，还有一些命令符分享给大家