本文参考文件为：Conflux白皮书，CFX黄皮书导读 直观地理解共识机制带来的tps、存储上的消耗，以及conflux中block和trans的具体执行时间差异。
CFX声称在共识层面提升区块链的吞吐率，减少区块确认的等待时间，
Conflux 的网络参数
Q1:Conflux的TPS能跑到多少 ?
- 全节点验证
- 部分节点验证,交易分片
在比特币中，每一个区块都需要广播给所有矿工，每一笔交易都被所有人验证过，我们称之为一个交易得到的“全节点验证”。在一些 Sharding方案的实验中，所有的交易被分成 30 份, 每个节点可能只验证其中一份。这样的交易称为“部分节点验证”。很显然，“部分节点验证”交易的总 TPS 是可以成倍于 “全节点验证” 的。
Conflux 在共识层面可以做到 4000-6000 TPS 的“全节点验证”, 如果考虑合约执行、状态读写等因素，实际部署可能会低一些。Sharding 技术是共识层技术一个很好的补充，Conflux 有计划在未来实现 Sharding, 提供更高的 “部分节点验证” TPS。
为什么快？
更充分地利用网络中分叉区块对系统安全性和吞吐率的贡献
Q2:Conflux的一个块多大 ?
200~300KB。
| Parameter | Value |
|---|---|
| Block time | 0.5 s |
| Maximum block size bound | 200 KB |
| Starting coinbase award | 7 CFX |
| Starting diffificulty (d0) | 3×10(4) = 30000 |
| Starting block gas limit | 3×107 = 30000000 |
| Anti-cone penalty factor (γ) | 100 |
| Deferred execution | 5 epochs |
| Mining reward freezing time | 12 epochs |
| Snapshot period | 100000 epochs |
| AdminControl Contract Address | 0x0888000000000000000000000000000000000000 |
| SponsorControl Contract Address | 0x0888000000000000000000000000000000000001 |
| Staking Contract Address | 0x0888000000000000000000000000000000000002 |
| tps | 4000~6000 |
比特币一个区块大小为1MB，比特币对每笔交易的大小没有限制，一个区块一般可包含2000~3000笔交易。
当前正在运行的CFX网络，平均每秒生成 4 个区块，每个块中大约有1600个交易，每个区块大小约为 300KB。
但是，对于交易的确认，在没有坏人攻击的情况下，5s 一个 4MB 大小的区块，确认时间约 8 分钟。在有 30% 算力攻击的情况下，确认时间约 16 分钟。
那么在满载的情况下，一秒的吞吐量为 1.2MB，一天约 100GB，每年新增的交易历史数据可达 30TB。
- 确认交易的TPS：实验数据4000~6000tps；实际能达到3000+
- GPU挖矿，Pow证明
对于在 Conflux 上运行的 DApp 来说，如果其本身需要保存和随时访问的数据量不是很大 —— 比如说每年新增 1MB 数据，则这些业务数据完全可以存储在智能合约的内部状态里。存储于合约内部状态的数据会作为世界状态的一部分被每一个全节点保存和同步，无需自己运行档案节点也可以保证最高程度的可用性。
Q3：Conflux的一个交易记录多大？
Q4:Conflux的一个块中最多可包括多少笔交易 ?
Q5：CFX对存储空间消耗
认证数据存储（CFX的创新点）
Q6：CFX对算力消耗（能耗）
Q7：CFX对带宽消耗
整个网络中有多个区块在并发地广播
交易转发协议（CFX的创新点）
Q8：id是怎么确立的？
Q8：哪些块有效
Q9：部分有效块内的交易执行吗？
执行。
Q10：blaming机制什么时候启动？
Q11：启动后被标记的块有效吗？其中的交易呢？
Q12：CFX的交易类型
交易是一个签名数据包，用于从一个账户向另一个账户或者向一个合约转以太币、调用合约方法或者部署一个新合约。
2.CFX预防双花攻击
在这个图中，我们首先来看一下一个攻击者如何能够逆转在账本中的一个交易，比如交易4。为了做到这一点，一个攻击者需要产生一个交易4的双花交易，打包到一个区块里面，并且将这个区块在区块的全序中插入到区块B的前面。
但攻击者很难做到这一点，主要有两个原因。第一个就是除非攻击者能够改变主链，不然他不能够逆转交易，因为交易的顺序是由主链来决定的。比如一个攻击者想把一个块插在靠前的位置，他能做就是在一个很早的Epoch里面的区块后面接着产生新块。但是只要这个块不在主链上，它就最终还是会属于一个很晚的Epoch。因为当一个诚实的新块产生以后，它会通过引用边把这个攻击者的区块给拉到新的Epoch里面。
2.2 CFX为什么采用PoW
引入了很多新的攻击情形和安全性威胁。针对PoS的攻击有，无利害攻击（Nothing-at-Stake Attack）长程攻击（Long-Range Attack）
所以CFX的性能提升还是靠DAG，而非不用PoW。
第三章 基本组件
轻节点没有能力维护当前整个共识系统里所有账户的状态，比特币以SPV验证受双花攻击的代价为限制，使得轻节点不用担心在金额不太大的交易中因为采用 SPV 确认规则而被骗。
对于状态根的判断比较容易理解：打包新区块的矿工节点需要沿着枢轴链执行每个 Epoch 中的交易，在这个过程中自然会知道每个处在枢轴链上的“主链区块”应该有什么样的状态根，因此就可以判断出实际处在枢轴链上的区块是否填对了这一项。而且因为按照枢轴链指定的顺序执行所有交易本来就是每个全节点都应该做的，所以上述检查并不带来额外的负担。
由于 Blaming 域是在每个区块的区块头部分的，所以轻节点也可以很容易看到矿工们对于其它区块的状态根是否正确的看法。根据这些信息，轻节点就可以比较容易地判断哪些区块的状态根是值得信任的，哪些区块的状态根有问题了。然后只需选择相信基于值得信任的状态根做出的证明即可。
3.2网络延迟执行策略
打包、执行、回滚、Stateroot
交易吞吐量提高后，让节点更有效率地执行交易
Conflux 的共识：交易的执行和打包相分离。即矿工在打包新区块的时候只需要验证被打包的交易形式上合法即可，而不需要实际执行这些交易。
在传统的区块链系统中，打包即执行。矿工往往需要执行自己打包的区块中的所有交易，再将执行交易以后的状态根（State root）一并放在区块头里。
首先，任何区块链都难免出现回滚的现象，出块速度越快则回滚也越容易发生。
诚然，长度比较短的回滚并不会对区块链的安全性构成任何威胁。但是每次回滚发生的时候，都意味着当前的世界状态也要跟着回滚，之前执行过一遍的交易在回滚后都要重新执行。这无疑会浪费计算资源。
CFX网络的并发区块对应的区块链历史往往是互不包含的，因此，验证每个区块内状态根的正确性也将是一件非常耗费计算资源的任务。
与其在打包的时候就执行所有交易，不如“让子弹先飞一会儿”，等到区块稍微稳定一点（甚至被初步确认以后）再执行更有效率。实际上，最有效率的执行方式无疑是等一个区块被确认以后再执行区块里面的交易，这样可以保证不会因为回滚而重复执行交易；但是考虑到，通常我们都希望尽早确定交易执行的结果，执行的步骤可以稍微提前一点，保证在区块被最终确认的时候可以拿到区块内交易执行的结果，这样就不会耽误任何后续的使用。
例如，延迟5个epoch区块执行。根据测试网的实验结果，Conflux 中的枢轴链时不时会回滚两到三个区块，但是鲜少出现连续回滚四个或更多区块的情况
另一方面，为了减少检查每个区块内的状态根带来的计算负担，Conflux 采用了一种比较“节俭”的检测规则，即只检查位于枢轴链（主链）上的区块的状态根是否正确。对于别的区块，除非它们因为某次回滚而落在新的枢轴链上，否则就不检查其状态根是否正确。这样就大大减少了单纯为了检查正确性而花费计算资源执行交易的情况，将宝贵的计算资源用在执行影响共识状态的有用的交易上（交易决定状态），同时也让区块回归其最初的“打包交易”的作用。
至于安全性方面，即便有一部分矿工偷懒填了错误的状态根，也不会影响别的全节点对于当前共识状态的判断。只要这些矿工依然遵照共识协议检查区块间的引用关系和正确地选择引用的区块，他们的算力依然为系统的安全性作出贡献。
总结来说，Conflux 通过将交易的打包与交易的执行相分离的方式，避免了短回滚和重复执行交易造成的浪费，实现了更高的计算资源利用率。这也是 Conflux 在提高交易执行效率的方面除了重写 Solidity 虚拟机以外做出的最重要的改进。
第四章 共识协议
关键词：DAG,GHAST,CheckPoint，Confirmation Rule
检查内容？
1.区块间的引用关系和正确地选择引用的区块
2.Nonce
3.Stateroot
4.1最长链规则的优势与不足
mp.weixin.qq.com/s/cf6uODQDCN_wj6Db9m6-pQ
从比特币开始，无论是最初的只是改改参数的莱特币，还是后来提出的 Bitcoin-NG [1], 以及采用了 DAG 结构的 OHIE [2]，众多公链共识算法的核心理念都是最长链规则。
OHIE 的论文 [2] 提到了很重要的一点：对于一个区块链系统，最重要的是一个“端到端”的安全性证明
被研究最多的最长链规则，其安全性的完整证明也要晚至 2016 年 9 月才由康奈尔大学的密码学教授 Rafael Pass 等人首次完成 [3]
相比之下，其它的共识算法包括最重链规则在 2019 年以前都没有一个完整的安全性证明，甚至有些共识算法连在限定条件下的安全性证明都没有。
“孤块”是指那些形式上合法但是最终没有进入主链（最长链）的区块。在理想的情况下，诚实节点每次生成区块都会将最长链的长度增加一。但是，如果两个诚实节点近乎同时挖出了两个区块，互相都没有引用对方作为父亲区块，那么这两个区块就形成竞争关系。相互竞争的区块最终至多只有一个进入最长链中，其余的都会成为不对最长链做出任何贡献的“孤块”。
一旦系统中的“孤块”过多，最长链的增长速率就会受到影响，进而给攻击者可乘之机。例如在 50% 的诚实区块成为“孤块”的情况下，最长链的平均增长速度就只有诚实节点出块速度的一半，此时攻击者只需要 34% 的总算力（多于诚实算力的一半）就可以对任意早的交易发起双花攻击。
孤块”的出现频率与一个比值有关：平均生成一个区块所需的时间 / 区块在点对点网络中广播需要的时间，我们暂且称为安全性系数。这个比值越高，则孤块出现的频率越少，相应的也就更安全。根据文章 [3] 中的分析，在这个比值大于 7 时，双花攻击所需算力的理论阈值是 45% 左右；比值大于 60 时，双花攻击所需算力的理论阈值是 49.5% 左右。目前比特币的比值在 60 左右。
安全性系数 = 平均生成一个区块的时间 / 区块广播时间
网络带宽系数 =区块大小 / 区块广播时间 多少时间内广播一定大小的块
单笔交易负载 = 区块大小 / 每个区块交易数量
TPS = 每个区块交易数量 / 平均生成一个区块的时间
也就是说，
安全性比值 单笔交易负载 TPS = 网络带宽系数
在最长链规则下提高 TPS 的切入点
\1. 降低安全性系数：简单地改比特币的参数，牺牲一部分安全性以换取更高的效率。例如缩短出块时间或者增大区块尺寸（相当于增加区块广播时间）。
\2. 降低单笔交易负载：使用致密区块（compact block）技术，把完整传输每笔交易（约数百 KB）变成传输交易的短 ID（4～6 B）。
\3. 提高网络带宽系数：提高共识节点的加入门槛，牺牲去中心化程度以换取更高的效率。极端情况下可以只保留少量光纤直连的超级节点（比如说 21 个）。
在提高 TPS 这条路上，尽管最长链规则受到以上分析的制约，但通过合理的设计，这个天花板还是可以绕开的。
最长链规则的不足
最长链规则最大的弱点，是区块的确认时间。
如果把安全性系数设为 10，则等待 6 个确认区块的平均时间是 60 * 区块广播需要的时间；如果需要在两分钟内确认一笔交易，就需要把区块广播时间控制在 2 秒内。
实际上，在区块广播中的每一跳，每个节点都需要进行验证和执行等一系列操作之后才能向下一跳转发。在节点数较多的时候，即使是不大的区块想要在 2 秒内传遍全网所有（或绝大多数）节点也是一件非常困难的事情。从目前的网络环境来看，3 到 5 分钟的确认时间基本上已经是最长链规则的极限。
Conflux 的原型版本（也即目前公开的版本，新版本的文章和技术规范尚未公开发布）中区块的确认时间是 4 到 7 分钟，看起来也没有做得更好。实际上，随着我们对最重链规则进行更深入的研究并进一步发掘其特有的潜力，在 PoW 链的确认时间这点上CFX已经取得了惊人的突破，实现了远超最长链规则的确认速度……
4.2 最重链规则的优势与隐患（1）
如果孤块出现过于频繁，最长链增长的速率就会降低。一旦这个速率低于攻击者生成区块的速率，攻击者就可以从任意早的地方发起攻击，最终追上最长链，从而改写区块链上的历史。
最重链规则在设计的时候，刻意削弱了“孤块”的影响。
在最重链规则下，如果从某一时刻开始，所有诚实者生成的区块都将一个区块 A 作为自己的祖先。
也就是说，这些新区块都在以区块 A 为根节点的子树中。那么，无论这些新生成的块中有多少“孤块”，区块 A 的子树权重增长的速率都不会打折扣。
对于区块 A 所有兄弟区块，只要攻击者的总算力低于诚实者的总算力，那么无论攻击者做什么，它的子树权重增长速率都很难赶上子树 A 的权重增长速率。最终攻击者没有能力改变 “区块 A 打败了它的所有兄弟” 这一事实。
对于 A的父亲区块、祖父区块等等，类似的结论同样成立。这样，区块 A 就成为了一个进入“最重链”的区块，且这个事实无法被攻击者逆转。
从以上分析可以看出，最重链规则完全不关心新生成的区块中有多少孤块，并具有这样的性质：“无论出块速度多快，最重链规则的攻击阈值都是>50%（即通常说的51%）”。
交易确认时间
1.假设了诚实节点新生成的区块都在区块 A 的子树中
交易确认与抛硬币的例子非常相似：硬币抛出正面对应着诚实节点生成了一个区块，抛出反面对应着攻击者生成了一个区块。如果攻击者和诚实节点生活在一个没有网络延迟的世界中，区块 A 以多大概率被确认完全取决于：
区块A的子树权重 - 区块A竞争兄弟的子树权重
(更严格的说，在“最重链规则”里，对于区块 A 到创世块这条链上的每一个区块，它和它的竞争兄弟的权重差值都会影响确认概率)
考虑网络延迟，
交易区块的子树权重† - 竞争兄弟的子树权重† - 还没有传遍全网的区块
† 计算子树权重时，只考虑已经被所有节点收到的区块
CFX在论文和实验中确认，在出块速度为 4 区块/秒 时，Conflux 可以在 30 秒之内得到等同于比特币 6 个确认块的安全性！将 PoW 链确认时间压缩进一分钟内
2.诚实节点新生成的区块不一定在区块 A 的子树中
4.3最重链规则缺陷1：“公共祖先区块”的“王储之争”
在树图结构中，我们不要求待确认区块是公共祖先，但要求待确认区块所在epoch中的主链区块是公共祖先。
以太坊采用了最重链规则的一个变种，我们就将以太坊当做最重链规则一个实际部署的例子。
在以太坊中，我们可以看到，多数区块都进入了主链，然后只需等待几分钟甚至更短的时间，所有新生成的诚实区块都会出现在这个区块的子树中。也就是说，这个区块成为了公共祖先。然后所有新的诚实区块齐心协力增加它的子树权重。使得占有少数算力的攻击者无法再“扶植”一个兄弟作为竞争者。
存活性攻击中的平衡攻击
通过一些分析可以得到，在出块速度足够快的时候，哪怕算力很小的攻击者，都有一定的概率让诚实节点永远无法打破这个困局。
如果攻击者只平衡两棵子树的算力和网络，不进行“藏块”的操作，诚实节点还是有能力打破这个困局的。
而如果攻击者还会在每个分支上挖一些块藏起来，那么每次诚实节点即将打破困局的时候，攻击者可以“主动干预”，放出一些藏在弱势分支上的区块，来继续维持平衡（就像三国杀里的内奸一样）。
4.4 最重链规则缺陷2：你的主链我做主
分割攻击
40%，20%，20%，20%。
第六章 交易处理
介绍了 Conflux 网络的交易执行流程。
Conflux 网络兼容以太坊虚拟机（EVM），在确定所有交易的全序并移除无效交易之后，余下的所有合法交易将如同以太坊链上的打包顺序一样在以太坊虚拟机上执行。Conflux 虚拟机 CVM 与 EVM 最大的不同点在于 Conflux 支持代付费机制。
6.2 代付费机制
方便新用户体验区块链，特别是让账户余额为 0 的新用户也可以使用链上的智能合约。CFX省却了发起交易前必须先把账户余额从 0 变成 1 这一步，让Sponsor为调用智能合约的交易代付交易费，从而允许余额为 0 的账户直接调用智能合约。
羊毛出在猪身上狗来买单
互联网应用获客的最大秘诀：尽量降低用户的使用成本，尤其是新用户第一次使用的成本。
多次小额付费给人带来的痛苦感往往远超过实际付费的金额。
区块链的认知成本：
- 首先需要了解一些基本的密码学知识和区块链原理，
- 用户管理账户地址和密钥
- 熟悉基础操作
- 支付交易费
用户在链上的是活动，无论是转账还是调用智能合约，都要发起交易然后由矿工去打包和执行之后才能生效。用户想要自己的交易生效，就必须支付给矿工打包和执行交易的费用。
合约钱包
简化合约手续。
目前市场上对于初次使用区块链的用户最友好的应该算是合约钱包了。例如以太坊上的 Argent 钱包，EOS 上的 Mykey 钱包，就可以帮助用户摆脱“私钥”、“助记词”、“手续费”等脑细胞杀手，通过钱包内深度集成的接口与区块链上的 Compound 和 Kyber 等 DeFi（去中心化金融）应用交互，且由 Argent/Mykey 公司承担这些交互产生的手续费。
但另一方面，合约钱包在集成特定应用的同时也限制了用户自由访问各类智能合约，使“智能钱包”变得不再智能。在遇到拥堵时，合约钱包不透明的交易处理机制也降低了用户对交易的控制能力。例如前段时间 3 月 13 日以太坊交易费率暴涨，Argent 为用户代发交易的账户有一笔交易的费率设置得过低，以致于通过这个账户代发的后续交易被阻塞了两个多小时。
此外，通过合约钱包进行交易比通过普通钱包直接进行要多一个步骤，因此消耗更大、成本也更高，进一步降低了整个网络的效率。
更重要的是，合约钱包支持的 DApp 也非常有限，用户想要使用更多 DApp ，操作也有诸多不便。
CFX的Sponsorship
每个智能合约的（关于交易费的）赞助情况可以由如下几个参数描述：
· 赞助者（Sponsor）：记录提供了当前赞助金的提供者；
· 赞助金余额（Sponsor balance）：记录了当前赞助金的余额；
· 单笔交易资助金额上限（Sponsor limit per transaction）：这是赞助者愿意为每笔交易提供的资助上限；
· 用户白名单（Whitelist）：这个名单记录了合约愿意资助的账户列表，也可以设置为资助所有账户。
用户 A 发起了一笔调用合约 C 的交易，交易费的来源将是合约 C 的赞助金。矿工检查C是否愿意（白名单、上限）且有能力（余额）；C的赞助金来自DApp的开发者和Conflux 生态基金。
赞助者和赞助金的管理：任何人只要肯出钱就可以成为新的赞助者。用户可以向任何合约捐一笔赞助金并声明愿为每笔交易提供的资助上限，只要捐的钱超过该合约当前的赞助金余额且单笔交易资助上限不减少，则合约的赞助者就会被替换成新的金主——之前的赞助金余额会被原路退回给上一个赞助者。
更详细情况见CFX5-2
单笔交易资助金额的上限只有在当前资助金余额已经小于单笔交易资助上限的情况才可以减少。