区块链安全问题应该怎么解决？

区块链项目（尤其是公有链）的一个特点是开源。通过开放源代码，来提高项目的可信性，也使更多的人可以参与进来。但源代码的开放也使得攻击者对于区块链系统的攻击变得更加容易。近两年就发生多起黑客攻击事件，近日就有匿名币Verge（XVG）再次遭到攻击，攻击者锁定了XVG代码中的某个漏洞，该漏洞允许恶意矿工在区块上添加虚假的时间戳，随后快速挖出新块，短短的几个小时内谋取了近价值175万美元的数字货币。虽然随后攻击就被成功制止，然而没人能够保证未来攻击者是否会再次出击。

创新互联是一家集网站建设,兰坪企业网站建设,兰坪品牌网站建设,网站定制,兰坪网站建设报价,网络营销,网络优化,兰坪网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

当然，区块链开发者们也可以采取一些措施

一是使用专业的代码审计服务，

二是了解安全编码规范，防患于未然。

密码算法的安全性

随着量子计算机的发展将会给现在使用的密码体系带来重大的安全威胁。区块链主要依赖椭圆曲线公钥加密算法生成数字签名来安全地交易，目前最常用的ECDSA、RSA、DSA 等在理论上都不能承受量子攻击，将会存在较大的风险，越来越多的研究人员开始关注能够抵抗量子攻击的密码算法。

当然，除了改变算法，还有一个方法可以提升一定的安全性：

参考比特币对于公钥地址的处理方式，降低公钥泄露所带来的潜在的风险。作为用户，尤其是比特币用户，每次交易后的余额都采用新的地址进行存储，确保有比特币资金存储的地址的公钥不外泄。

共识机制的安全性

当前的共识机制有工作量证明（Proof of Work，PoW）、权益证明（Proof of Stake，PoS）、授权权益证明（Delegated Proof of Stake，DPoS）、实用拜占庭容错（Practical Byzantine Fault Tolerance，PBFT）等。

PoW 面临51%攻击问题。由于PoW 依赖于算力，当攻击者具备算力优势时，找到新的区块的概率将会大于其他节点，这时其具备了撤销已经发生的交易的能力。需要说明的是，即便在这种情况下，攻击者也只能修改自己的交易而不能修改其他用户的交易（攻击者没有其他用户的私钥）。

在PoS 中，攻击者在持有超过51%的Token 量时才能够攻击成功，这相对于PoW 中的51%算力来说，更加困难。

在PBFT 中，恶意节点小于总节点的1/3 时系统是安全的。总的来说，任何共识机制都有其成立的条件，作为攻击者，还需要考虑的是，一旦攻击成功，将会造成该系统的价值归零，这时攻击者除了破坏之外，并没有得到其他有价值的回报。

对于区块链项目的设计者而言，应该了解清楚各个共识机制的优劣，从而选择出合适的共识机制或者根据场景需要，设计新的共识机制。

智能合约的安全性

智能合约具备运行成本低、人为干预风险小等优势，但如果智能合约的设计存在问题，将有可能带来较大的损失。2016 年6 月，以太坊最大众筹项目The DAO 被攻击，黑客获得超过350 万个以太币，后来导致以太坊分叉为ETH 和ETC。

对此提出的措施有两个方面：

一是对智能合约进行安全审计，

二是遵循智能合约安全开发原则。

智能合约的安全开发原则有：对可能的错误有所准备，确保代码能够正确的处理出现的bug 和漏洞；谨慎发布智能合约，做好功能测试与安全测试，充分考虑边界；保持智能合约的简洁；关注区块链威胁情报，并及时检查更新；清楚区块链的特性，如谨慎调用外部合约等。

数字钱包的安全性

数字钱包主要存在三方面的安全隐患：第一，设计缺陷。2014 年底，某签报因一个严重的随机数问题（R 值重复）造成用户丢失数百枚数字资产。第二，数字钱包中包含恶意代码。第三，电脑、手机丢失或损坏导致的丢失资产。

应对措施主要有四个方面：

一是确保私钥的随机性；

二是在软件安装前进行散列值校验，确保数字钱包软件没有被篡改过；

三是使用冷钱包；

四是对私钥进行备份。

如何辩别真正的区块链数字货币

某个数字货币是否是一个有价值的币种，在目前基本属于“天使轮”阶段而言，判定标准有三个，一是团队，二是经济模型，三是行业需求。

团队的随机性太大，在此不进行讨论。本文首先对数字货币的经济模型进行一个详尽地分析，在随后的文章中，笔者会根据不同行业对部分数字货币进行剖析。

严格来讲，本文所涉及的经济模型，并不完全等同于经济学中所述概念。特指在数字货币中，货币的共识机制与激励机制。

一、共识机制

共识机制是区块链系统中各个节点达成一致的策略和方法，应根据系统类型及应用场景的不同灵活选取。

常用的共识机制主要有PoW、PoS、DPoS、PBFT（及其变种）等。另外，基于区块链技术的不同应用场景，以及各种共识机制的特性，本文按照以下维度来评价各种共识机制的技术水平：

a) 合规监管：是否支持超级权限节点对全网节点、数据进行监管；

b) 性能效率：交易达成共识被确认的效率；

c) 资源消耗：共识过程中耗费的CPU、网络输入输出、存储等计算机资源；

d) 容错性：防攻击、防欺诈的能力。

1、PoW(Proof of Work)工作量证明：依赖机器进行数学运算来获取记账权，资源消耗相比其他共识机制高、可监管性弱，同时每次达成共识需要全网共同参与运算，性能效率比较低，容错性方面允许全网50%节点出错。

优点：（1）安全性高，系统稳定性好；（2）节点间无需交换额外的信息即可达成共识；（3）破坏系统需要投入极大的成本；（4）算法简单，容易实现。

缺点：（1）需要投入硬件成本及能源成本；（2）区块的确认时间较长，而且需要等待多个确认；（3）由于比特币的先发优势，新的区块链必须找到一种不同的散列算法，否则就会面临比特币的算力攻击；（4）容易产生分叉。

2、PoS（Proof of Stake）权益证明：主要思想是节点记账权的获得难度与节点持有的权益成反比，相对于PoW，一定程度减少了数学运算带来的资源消耗，性能也得到了相应的提升，但依然是基于哈希运算竞争获取记账权的方式，可监管性弱。该共识机制容错性和PoW相同。

优点：（1）缩短了共识达成的时间；（2）不再需要大量消耗能源挖矿。

缺点：（1）还是需要挖矿，存在一定的资源浪费；（2）所有的确认都只是一个概率上的表达，而不是一个确定性的事情，理论上有可能存在其他攻击影响。

3、DPoS (Delegate Proof of Stake) 股份授权证明：与PoS的主要区别在于节点选举若干代理人，由代理人验证和记账。其合规监管、性能、资源消耗和容错性与PoS相似。

优点：（1）通过使用“代议制”，大幅提高达成共识的时间，为商业应用的开发提供了客观条件；（2）大幅度减少了资源消耗。

缺点：（1）存在“代表”作恶的情况，需要制定相应的约束条件及替代方案；（2）需要在总节点数量与“代表”数量之间做好平衡。

4、PBFT（Practical Byzantine Fault Tolerance）实用拜占庭容错：一种采用许可投票、少数服从多数来选举领导者进行记账的共识机制，但该共识机制允许拜占庭容错。该共识机制允许强监管节点参与，具备权限分级能力，性能更高，耗能更低，该算法每轮记账都会由全网节点共同选举领导者，允许33%的节点作恶，容错性为33%。

优点：（1）系统运转可以脱离币的存在，PBFT算法共识各节点由业务的参与方或者监管方组成，安全性与稳定性由业务相关方保证；（2）共识的时延大约在2~5秒钟，基本达到商用实时处理的要求；（3）共识效率高，可满足高频交易量的需求。

缺点：（1）当有1/3或以上记账人停止工作后，系统将无法提供服务；（2）当有1/3或以上记账人联合作恶，且其它所有的记账人被恰好分割为两个网络孤岛时，恶意记账人可以使系统出现分叉，但是会留下密码学证据。

二、激励机制

激励机制与共识机制有强关联性的，不夸张的说，在一定程度上，共识机制决定了激励机制的设计方式，也就是说，共识机制是激励机制的充分条件（规模极小的私有链除外）。就二者在区块链系统内的关系而言，共识机制的目的是产生区块，而激励机制则是给予区块生产者的奖励。

单就激励机制而言，即数字货币如何发放。其中涉及到总量是否恒定，数字货币总量如何分配（投资人、团队、矿工等），激活/解锁/释放/回购机制，数字货币权益等。

从二者关系看，数字货币分为两种：一种是区块链项目，拥有区块链完整的架构，其经济模型由共识机制与激励机制组成；另一种是部署于区块链上的分布式应用所发行的数字货币，仅需要设计优化后的激励机制以维系整个应用的良性运转即可。

2.1 区块链项目的激励机制

激励机制的设计源于以比特币为代表的区块链1.0时代。

比特币是一个完全开源的公链项目，没有众筹，没有项目方，整个区块链运行的关键在于三点：

第一是底层代码的准确性（已经经过了时间的检验）；

第二是共识算法，采用PoW机制，简单易用，在前期运行比特币系统过程中，并无过多的资源浪费，这为大量普通网络节点接入比特币系统提供了便捷，然而在专业的比特币挖矿机器产生之后，难度系数增加，资源浪费在所难免，是为后话（中本聪可能低估了群体的智慧）；

第三是，激励机制的设计，基于开源的公链必须提供给网络节点持续运行所必要的动力。比特币约每十分钟出一个区块，前21万个区块，大概需要4年时间，第一个四年期每个区块的激励为：50个比特币与该区块内所有的交易费用，随后的每21万个区块，奖励减半，在2140年比特币区块奖励将完全由区块中的交易费用构成。

几个要素构成了比特币的激励机制：

（1）比特币的发行总量为2100万枚，不增发；

（2）PoW共识机制决定了比特币的分配方式为算力产生，100%分配给矿工；

（3 ）约每十分钟产生一个区块，区块初始奖励为50个比特币，每21万个区块之后产量减半，具有“通缩”属性，无回购销毁机制；

（4） 比特币交易需要支付给矿工一定的数据打包费用。

以上是第一套区块链的激励机制：稳定的数字货币供应，维持整个系统运转的矿工团体及数字货币分配方式，数字货币释放机制，数字货币交易方式。这也成为区块链项目中激励机制设计的基础框架。

随着比特币知名度的上升，用户群体日益扩大，资源浪费，效率偏低等问题逐渐凸显，后续区块链项目在激励机制设计上开始进行改进。

比如为了减少资源消耗而采取的PoS共识算法，在此种算法下新“挖掘”出的数字货币为全员共享而非矿工独享，客观上打压了矿工的积极性，从而采用了数字货币“通胀”的形式，即增发一定数量的数字货币，然而数字货币的增发必然会造成贬值，因此，需要将新增的一部分数字货币返还持币者作以补偿。

再比如为了提高效率而采取DPoS共识算法，设计机制与PoS类似，只不过将新增数字货币的分配方式从由代码约定改为了由超级节点主观分发。

总而言之，激励机制的设计是不断进化中的，但是仍然未摆脱经典模式的基本框架。

2.2 分布式应用的激励机制

分布式应用是指，部署与通用公有链或者行业公有链上的应用，如果把公链理解为操作系统，那么分布式应用就是适配于这个系统的Applications。通常情况下，这些应用都会在所部署的公链上发行数字货币，暂且称之为应用型数字货币。由于应用基于公链创建，所有特性受制于公链所能提供的功能。

应用型数字货币的经济模型中，不需要进行共识机制的设计，只需要设计健康的激励机制即可。

比如，头部数字货币交易所Binance发布了一种数字货币，简称“BNB”，它是基于以太坊区块链的ERC20标准数字货币。

BNB总量被限定为2亿个，并承诺永不增发。50%数字货币对外发售，40%团队持有，早期的天使投资人持有10%。持有BNB的用户，在Binance平台上进行交易，可享受用足额BNB抵扣并享受5年内手续费逐级递减的折扣；除了享受手续费折扣外，持有BNB的用户可以享受众多的空投活动。在这些权益之外，BNB项目团队会在每季度拿出当季净利润的20%用于回购BNB并销毁，直至所有BNB总量为1亿个为止，具备了“通缩”属性。

应用型数字货币的经济模型大体如下：数字货币总量一般恒定；数字货币分配方式为：早期投资者与项目团队持有一定比例的数字货币（约50%）；持有数字货币享受该分布式应用的部分权益。

当然，在数字货币数量（是否增发需根据所部属平台和项目需求而定）、分配方式、比例和持币权益方面都能依据项目需求进行调整。

三、如何设计数字货币的经济模型

在这里，应该明确一个理念，价值回归。我们可以将它延伸理解为互联网下的共享经济模式在区块链领域的扩展。即区块链项目的价值是由参与者共同创造的，应该由区块链参与者共享。

那么如果要为一个区块链项目或者分布式应用设计一个合理的经济模型，应该从哪些方面加以考虑呢？

3.1 共识机制的选用

对区块链项目而言，经济模型的设计比较难，即便现有的几大区块链项目，其经济模型的设计也并非尽善尽美的。

在共识算法的选择上，要参照符合监管，利于性能效率提升，尽量避免过度的资源消耗，具有一定的容错性四个方面加以考虑。

结合主流的共识算法如PoW、PoS、DPoS、PBFT（及其变种）等，其中DPoS、PBFT（及其变种）两种算法在上述四方面能够做到一个较好的平衡。目前国内的区块链项目多采用PBFT及其变种算法作为共识机制即是例证。

当然，随着未来人类科技的不断进步，更新的、更能够得到有效监管、效率更高的算法可能会逐渐被人发现并加以运用。

3.2 激励机制的设计

激励机制的重要性无需赘言。在确定采取何种共识机制之后，下一步就需要设计合理的激励机制以保证区块链项目的良好运转和持续发展。

下面将从数字货币总量、分配方式、释放/回购机制、持币权益四个方面进行探讨。

（1）数字货币总量供应

数字货币的总量依据所属行业及项目需求而定，避免预期价格异常而导致与法币兑换差额较大：例如，一个关于资产管理的区块链项目，预期资产管理市值为50亿美元，发行数字货币的数量应不少于50亿枚为佳。

（2） 数字货币分配方式

这里的分配方式是指，在所发行数字货币的总数中，早期投资者、团队、社区等分别持有的数量。

在当前市场中，为了维持价格的稳定，防止游子恶意做空，促进区块链项目生态健康，团队持有一定比例的数字货币是十分必要的。

（3） 数字货币释放/回购机制

在比特币中即“挖矿”，在非PoW共识机制的区块链项目中，数字货币的有三种形式释放：一种是前期预售；第二种就是行为（包括但不限于：交易、运动、内容生产）释放；最后一种为线性释放，即固定周期内释放固定数量的数字货币，直至全部释放完毕（三种方法也可同时使用）。

回购机制是项目方对持币者的回馈措施之一，使用回购销毁的方式对市值进行管理，对所有持币者进行“分红”。

（4） 数字货币权益

根据区块链赋予不同的行业来看，一般具有交易、应用中消费、持币享受平台利润分成（类似于持股）、空投等福利。

四、案例示范

项目名称：X

代币名称：XT

核心产品：基于AI大数据的数字货币智能投顾平台

1 行业背景

寻找行业痛点：资产管理需要专业的团队与知识，然而现在大多数数字货币投资者并不具备；数字货币市场行情波动巨大，在行情下挫中，投资者无法对资产进行保值。

2 自身优势

在股票、期货市场深耕多年，有成熟、高素质资产管理团队；AI大数据团队技术实力强劲。

3 市场调研

进行市场调研之后，预估未来5年内，资产管理的市值约为10亿美元。

4 数字货币总量

在考虑预期资产管理市值、开发周期与难度后，考虑发行基于以太坊ERC20数字货币XT，数量20亿枚，永不增发。

5 分配方式

早期投资人持有10%，团队持有20%，商务运营10%，社区建设10%，投资者持有50%。

6 数字货币释放/回购机制

释放机制分为三类：

第一类：商务运营持币部分为全部解锁，用途限定为商务及运营活动；

第二类：社区建设部分的释放机制为，社区成员发布独家资讯、合作平台发布独家项目进展等行为，根据参与ID数，释放相应比例XT（发布者与参与者各获得50%），直至全部释放完成（释放完成之后，后续奖励来源于平台利润池）；

第三类：投资者持主流数字货币，在平台中进行资产管理，根据兑换比例，释放一定数量的XT，早期投资人与团队持有部分同步，按比例解锁；

回购机制为：所得利润（以XT计）的50%返还给持币者；剩余进入平台利润池中，按月对利润池中的50%的XT进行销毁，直至XT总量为10亿枚；其余作为平台生态建设基金；

7 数字货币权益

利润分成：持有XT，是为平台用户，可以享受平台利润50%的分成；

平台治理：参与平台活动享受XT奖励、其他项目方的空投活动；

功能定制：可基于平台AI大数据，投资者可购买针对个人交易策略进行优化的服务

拜占庭容错和PBFT共识算法

实用的拜占庭容错算法

BFT 是区块链共识算法中，需要解决的一个核心问题。比特币的POW，eos的dpos，以及共识算法pos，这些公链算法，解决的是共识节点众多情况下的bft问题。

拜占庭将军问题。也称为拜占庭容错。

用来描述分布式系统一致性问题。

背景如下：

拜占庭帝国想要进攻一个强大的敌人，为此派出了10支军队去包围这个敌人。这个敌人虽不比拜占庭帝国，但也足以抵御5支常规拜占庭军队的同时袭击。这10支军队在分开的包围状态下同时攻击。他们任一支军队单独进攻都毫无胜算，除非有至少6支军队（一半以上）同时袭击才能攻下敌国。他们分散在敌国的四周，依靠通信兵骑马相互通信来协商进攻意向及进攻时间。困扰这些将军的问题是，他们不确定他们中是否有叛徒，叛徒可能擅自变更进攻意向或者进攻时间。在这种状态下，拜占庭将军们才能保证有多于6支军队在同一时间一起发起进攻，从而赢取战斗？

单从上面的说明可能无法理解这个问题的复杂性，我们来简单分析一下：

先看在没有叛徒情况下，假如一个将军A提一个进攻提议（如：明日下午1点进攻，你愿意加入吗？）由通信兵通信分别告诉其他的将军，如果幸运中的幸运，他收到了其他6位将军以上的同意，发起进攻。如果不幸，其他的将军也在此时发出不同的进攻提议（如：明日下午2点、3点进攻，你愿意加入吗？），由于时间上的差异，不同的将军收到（并认可）的进攻提议可能是不一样的，这是可能出现A提议有3个支持者，B提议有4个支持者，C提议有2个支持者等等。

再加一点复杂性，在有叛徒情况下，一个叛徒会向不同的将军发出不同的进攻提议（通知A明日下午1点进攻， 通知B明日下午2点进攻等等），一个叛徒也会可能同意多个进攻提议（即同意下午1点进攻又同意下午2点进攻）。

叛徒发送前后不一致的进攻提议，被称为“拜占庭错误”，而能够处理拜占庭错误的这种容错性称为「Byzantine fault tolerance」，简称为BFT。

使用密码学算法保证节点之间的消息传送是不可篡改的， 通过下面的算法我们可以保证A将军收到B将军发来的消息确实是B将军本人的真实请求 。

我们采用的是哈希函数（散列算法）SHA256 -- 从数据（byte）值中创建独一无二的hash值，并压缩成摘要，将数据格式固定下来。通过这个摘要与个人私钥生成Digital Signature 和个人公钥Public-key certificate，接收方验证签名和摘要，如果是通过验证，即证明摘要内容没有经过篡改。

pbft容忍无效或者恶意节点数量 e 。为了保证整个系统可以正常运作，需要有2f+1个正常节点，系统的总结点数为 ：3f+1。即pbft算法容忍小于1/3的恶意或者无效节点。 原因见节点作恶的极端情况

pbft是一种状态机副本复制算法，所有副本在一个view轮换过程中操作，哪些是主节点（进攻的提议者的大将军们，轮流当）通过view中其他节点（其他将军）赋予的编号和节点数集合来确定，即：主节点p=v mod |R| 。 v：view编号，|R|节点个数，p：主节点编号。 关于状态机复制算法、view change的意义（主要是防止主节点作恶），主节点详见论文。

基于拜占庭将军问题，PBFT算法一致性的确保主要分为这三个阶段：预准备（pre-prepare）、准备(prepare)和确认(commit)。流程如下图所示：

[图片上传失败...(image-e3329d-1562488133052)]

首先解释一下上面各个符号表达的意思：

下面结合上图，详细说一下PBFT的步骤：

根据上述流程，在 N ≥ 3F + 1 的情况下一致性是可能解决， N为总计算机数，F为有问题的计算机总数 。

下面所有的校验流程略去对消息内容、签名和身份的验证，即已经保证了节点之间消息传播是不可篡改的

上述算法中，比较重要的一个点是view change，为了能恢复之前的请求，每一个副本节点收到消息之后或者发送消息的时候都会记录消息到本地的log记录中。当执行请求后，副本节点需要把之前该请求的记录消息清除掉。最简单的做法是在reply消息后，在执行一次当前状态的共识同步，但是为了节省资源，一般在多条请求K后执行一次状态同步。这个状态同步就是checkpoint消息。

为了节省内存，系统需要一种将日志中的 无异议消息记录 删除的机制。为了保证系统的安全性，副本节点在删除自己的消息日志前，需要确保至少 f+1 个正常副本节点执行了消息对应的请求，并且可以在视图变更时向其他副本节点证明。另外，如果一些副本节点错过部分消息，但是这些消息已经被所有正常副本节点删除了，这就需要通过 传输部分或者全部服务状态实现该副本节点的同步 。因此，副本节点同样需要证明状态的正确性。

在每一个操作执行后都生成这样的证明是非常消耗资源的。因此，证明过程只有在请求序号可以被某个常数（比如100）整除的时候才会周期性地进行。我们将这些请求执行后得到的状态称作 检查点（checkpoint） ，并且将具有证明的检查点称作 稳定检查点（stable checkpoint） 。

上述情况是理想情况，实际上当副本节点i向其他节点发出checkpoint消息之后，其他节点还没有完成K条请求的相互共识，所以不会立即对i的请求作出响应。其他节点会按照自己的处理步骤和顺序，向前行进和共识。但是此时i发出的checkpoint没有形成stable，为了防止i太快，超过自己太多，于是被便会设置一个高水位H=h+L，其中L就是我们指定允许的高度差，等于checkpoint周期处理数K的整数倍，可以设置为L=2K。当副本节点i处理请求超过高水位H时，副本节点即使接受到请求也会视为非法请求。等待stable checkpoint发生变化，再继续向前推进处理。

如果主节点作恶，它可能会给不同的请求编上相同的序号，或者不去分配序号，或者让相邻请求的序号不连续。备份节点（备份主节点）应当有职责来主动检查这些序号的合法性。如果主节点掉线或者作恶不广播客户端的请求，客户端设置超时机制，超时的话，向所有副本节点广播请求消息。副本节点检测出主节点或者下线，发起view change流程。

我们在上面讲到，当网络中有F台有问题的计算机时，至少需要3F+1台计算机才能保证一致性问题的解决，我们在这里讨论一下原因。

我们可以考虑：由于有F个节点为故障或被攻击的节点，故我们只能从N-F个节点中进行判断。但是由于异步传输，故当收到N-F个消息后，并不能确定后面是否有新的消息。（有可能是目前收到的N-F个节点的消息中存在被攻击的节点发来的消息，而好的节点的消息由于异步传输还没有被收到。）

我们考虑最坏的情况，即剩下F个都是好的节点，收到的中有F个被攻击的节点，故我们需要使得收到的中好节点的数量 (N-F)-F 大于被攻击节点的数量 F ，于是有 N-2FF ，即 N3F ，所以N的最小整数为 N=3F+1 。

pbft是需要参与认证的节点进行的。所以一个完整的共识算法包括DPOS+PBFT。其速度是可以达到1500tps左右的。

参考文献：

Practical Byzantine Fault Tolerance

Miguel Castro and Barbara Liskov Laboratory for Computer Science, Massachusetts Institute of Technology, 545 Technology Square, Cambridge, MA 02139 castro,liskov @lcs .mit.edu

部分论文翻译

分享文章：pbft代码分析java,pb 编译
文章链接：http://myzitong.com/article/hohhpp.html