189 8069 5689
比特币区块链面向转账场景，支持简单的脚本计算。如果引入更多复杂的计算逻辑，将能支持更多应用场景，即智能合约(Smart Contract)。智能合约可以提供除了货币交易功能外更灵活的合约功能，执行更为复杂的操作。
引入智能合约的区块链，已经超越了单纯数据记录功能；可以为区块链加入权限管理，高级编程语言支持等，实现更强大的、支持更多商用场景的分布式账本系统。
区块链技术的三种典型演化场景如下:
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：空间域名、网络空间、营销软件、网站建设、周村网站维护、网站推广。
根据参与者的不同，区块链可以分为公有(Public)链、联盟(Consortium)链和私有(Private)链。
公有链，即任何人都可以参与使用和维护，参与者多为匿名。典型的如比特币和以太坊区块链，信息是完全公开的。
如果进一步引入许可机制，可以实现私有链和联盟链两种类型。
私有链，由集中管理者进行管理限制，只有内部少数人可以使用，信息不公开，跟传统中心化记账系统的差异不明显。
联盟链则介于两者之间，由若干组织一起合作(如供应链机构或银行联盟等)维护一条区块链，该区块链的使用必须是带有权限的限制访问，相关信息会得到保护，典型如超级账本项目。在架构上，现有大部分区块链在实现都至少包括了网络层、共识层、智能合约和应用层等分层结构，联盟链实现往还会引入额外的权限管理机制。
目前来看，公有链信任度最高，也容易引发探讨，但短期内更多的应用会首先在联盟链上落地。公有链因为要面向匿名公开的场景，面临着更多的安全挑战和风险；同时为了支持互联网尺度的交易规模，需要更高的可扩展性，性能瓶颈在短期内很难得到解决。
对于信任度和中心化程度的关系，通常非中心化程度越高，信任度会越好。随着节点数增加，前期的信任度往往会增长较快，达到一定程度后，信任度随节点数增多并不会得到明显改善。因为随着成员数的增加，要实现共谋作恶的成本会指数上升。
根据使用目的和场景的不同，可以分为以数字货币为目的的货币链，以记录产权为目的的产权链，以众筹为目的的众筹链等，也有不局限特定应用场景的所谓通用链。通用链因为要兼顾不同场景下的应用特点，在设计上需要考虑更加全面。
区块连常见共识算法包括Paxos、Raft、PBFT、POW、POS、DPOS等，但随着区块链技术的发展，不同区块链项目在不同应用场景下通过对基础的共识算法的相互融合、改进，诞生了多种新的共识算法，如DBFT、BFT-DPoS、SBFT、VBFT、Tendermint等。
（1）DBFT
DBFT(Delegated Byzantine Fault Tolerant)，即代理拜占庭容错算法，是基于PBFT改进的区块链共识算法。
DBFT的算法中，参与记账的是超级节点，普通节点可以看到共识过程，并同步账本信息，但不参与记账。总共n个超级节点分为一个议长和n-1个议员， 议长会轮流当选。每次记账时，先有议长发起区块提案(拟记账的区块内容)， 一旦有至少(2n+1)/3个记账节点(议长加议员)同意提案，那么提案就成为最终发布的区块，并且该区块是不可逆的，所有里面的交易都是百分之百确认的，区块不会分叉。
为了便于在区块链开放系统中应用，DBFT将PBFT中的将C/S(客户机/服务器)架构的请求响应模式，改进为适合P2P网络的对等节点模式，并将静态的共识参与节点改进为可动态进入、退出的动态共识参与节点，使其适用于区块链的开放节点环境。
由于BFT算法存在的扩容性问题，DBFT算法由权益持有者投票选举产生代理记账人，由代理人验证和生成区块，以此大幅度降低共识过程中的节点数量，解决了BFT算法固有的扩容性问题。
NEO项目使用了DBFT共识算法，NEO共识机制下只设置了7个超级节点，以一种弱中心化的模式实现较高的共识效率。目前，超级节点是静态选出的，并完全由项目方部署。
DBFT的优点如下：
A、效率高。
NEO每15~20秒生成一个区块，交易吞吐量可达到约1000TPS，优化后性能可达10000TPS；
B、良好的最终性。
区块不会分叉，以此来验证参与者的身份，保护网络安全，使区块链能够适用于对交易确认实时性要求高的真实金融场景。
DBFT的缺点如下：
A、较低的容错率。
当有1/3或以上超级节点为恶意节点或宕机后，系统将无法提供服务。
B、超级节点数量过少，中心化程度高。
（2）BFT-DPOS
BFT-DPOS（Byzantine Fault Tolerance - Delegated Proof of Stake），即带拜占庭容错的股份授权证明算法，是EOS项目通过引入PBFT算法对DPOS进行改进而来的共识算法。
在传统DPOS共识机制中，每个受托人在出块时向全网广播新创建区块，但即使其它受托人收到目前的新区块，也无法对新区块进行确认，需要等待轮到自己出块时，才能通过生产区块来确认之前的区块。
BFT-DPOS共识机制下，每个受托人出块时依然全网广播，其它受托人收到新区块后，立即对此区块进行验证，并将验证签名完成的区块立即返回出块受托人，不需等待其它受托人自己出块时再确认。因此，出块受托人生产了一个区块，并全网广播，然后陆续收到了其它受托人对此区块的确认，在收到2/3受托人确认的瞬间，区块（包括其中的交易）就不可逆。
在EOS中有21个超级节点，主要有两方面原因：一是由于用户很难对较多数量的超级节点充分了解，所以过多的超级节点会降低用户投票的活跃度；二是规模为20的节点数目可以在拜占庭问题中以更低的资源成本来获得高效的共识。
超级节点的主要职责是：提供相关计算资源和网络资源，保证节点的正常运行；当轮到某超级节点拥有出块权时，超级节点收集该时段内的所有交易，并对交易验证后打包成区块广播至其它超级节点，其它超级节点验证后把区块添加到自己的数据库中。在EOS中，每个出块间隔定义为3秒，由于在当前的网络环境下，一个超级节点打包区块并将其广播，绝大多数其它超级节点收到该区块的过程耗时最多3秒。只有下一个超级节点收到了上一个超级节点广播的区块时，再进行新区块的生成才不会造成对某个超级节点产生区块的忽略。而一个区块要成为不可逆区块需要超过三分之二的超级节点进行确认，在DPOS中只有超级节点产生一个新区块，才能对之前收到的区块链进行确认，所以一个区块产生后，其后续串联14（21个超级节点的2/3）个区块才表明该区块是不可逆区块，区块中的交易是不可逆交易，整个确认过程需要45秒（包括出块节点的区块生成时间）。
为了挖掘EOS系统的性能，Daniel Larimer对BFT-DPOS进行了优化，将出块速度由3秒缩短至0.5秒，理论上可以极大提升系统性能，但带来网络延迟问题：0.5秒的确认时间会导致下一个出块者还没有收到上一个出块者的区块，就要生产下一个区块，那么下一个出块者会忽略上一个区块，导致区块链分叉（相同区块高度有两个区块）。
为解决网络延迟问题，Daniel Larimer将原先的随机出块顺序改为由受托人商议后确定的出块顺序，网络连接延迟较低的受托人之间就可以相邻出块，大大降低受托人之间的网络延迟，使得0.5秒的出块速度具备理论上的可能。
为了保证万无一失，不让任何一个受托人因为网络延迟的意外而被跳过，Daniel Larimer让每个受托人连续生产6个区块，即每个见证人还是负责3秒的区块生产，但由最初的只生产1个变成生产6个。最恶劣的情况下，6个区块中，最后一个或两个有可能因为网络延迟或其它意外被下一个受托人略过，但6 个区块中的前几个会有足够的时间传递给下一个受托人。
BFT-DPoS的交易确认时间问题：每个区块生产后立即进行全网广播，区块生产者一边等待0.5秒生产下一个区块，同时会接收其它受托人对于上一个区块的确认结果。新区块的生产和旧区块确认的接收同时进行。大部分的情况下，交易会在1秒（包括0.5秒的区块生产和要求其它受托人确认的时间）之内确认（不可逆）。
EOS系统规定，一旦区块达到不可逆状态（2/3受托人确认），就无法在此之前进行分叉，保证交易的永久可信。即使多数见受托人想分叉区块链，也只能以相同的速度（0.5秒）与主链竞争，就算主链只剩下一个受托人，分叉链也永远不会追上主链，保证了系统的稳定。
EOS项目解决的区块链痛点如下：
A、应用性能低
比特币和以太坊都面临应用性能低的瓶颈。随着交易量和应用的增长，网络拥堵和手续费飞涨的问题日益凸显。从交易速度方面看，比特币为每秒7笔，以太坊交易速度为每秒30-40笔，而EOS则可以达到每秒数百万笔交易，可以满足商业级别应用的需要。
EOS基于石墨烯技术，通过并行链的方式达到毫秒级的确认速度和数百万TPS。
B、安全性差 （DPOS共识算法）
EOS采用的是DPOS算法，分叉基本不可能发生，。解决了比特币和以太坊的链分叉问题，从而保障了全网运行的安全性。因为块生产者生产区块的方式是合作性的而不是竞争性的。如果发生区块分叉，DPOS共识将自动切换到最长的链条。此外，不会发生块生产者同时在两个区块链分叉上生产块的情况。如果有，就可能被投票出局。
C、开发难度高
比特币只能作为货币交付使用，只满足交易的功能；以太坊实现了智能合约，突破了比特币的货币功能，向非金融领域迈出了一步，但由于其模块的复杂性，无法使得开发者轻松自如地创建自己想创建的应用；EOS处理了额外的复杂性，为开发者们提供了用户友好的底层模块，可以支持多种编程语言。
D、手续费高
EOS为用户提供了免费服务，相比较比特币和以太坊高昂的转账手续费，EOS公链用户无需支付手续费。开发者依据用户规模，创建对应的盈利模式。
（3）SBFT
SBFT（Simpled BFT），即简化拜占庭容错算法，是PBFT算法的简化版本。
在Fabric的提案中，采用SBFT（Simple BFT）算法。但Fabric0.6版本采用PBFT，Fabric1.0中移出了PBFT，而是使用Kafka、Solo进行排序，作为共识节点。Fabric应该会在后期版本实现SBFT。
（4）Tendermint
Tendermint是一个模块化的区块链应用框架，能够实现拜占庭容错 (BFT）。Tendermint主要包括两部分：
A、Tendermint Core
Tendermint Core实现了P2P网络，在节点之间共享区块和交易，实现了拜占庭容错的共识算法，确定了不可更改的交易顺序;
B、ABCI Interface
ABCI Interface负责处理具体的逻辑处理层，可以基于不同的语言 (Golang，JS) 来实现，可以实现交易的验证处理以及查询等操作。
Tendermint地址：https://github.com/tendermint/tendermint
Tendermint官方网站：https://tendermint.com/
（5）VBFT
VBFT算法融合POS、VRF以及BFT的思想。在VBFT算法中，节点需要通过权益抵押来申请参与网络共识。此后，系统通过可验证随机函数来随机从所有备选的共识节点中选择n个节点，并提出、验证备选区块，最终通过对验证结果进行背书投票来完成区块共识。
共识节点构成共识网络，负责对网络中的事务请求进行共识，生成区块；而备选的共识节点构成候选网络，不参与共识，但保持与共识网络同步的状态。此外，候选网络对共识网络进行监控，并对共识区块进行验证。
VBFT算法流程如下：
A、根据VRF从共识网络中选择备案提案节点，各个备选节点独立提出备选区块。
B、根据VRF从共识网络中选择多个验证节点，每个验证节点将从网络中收集备选区块，进行验证，然后对最高优先级的备选区块进行投票。
C、根据VRF从共识网络中选择多个确认节点，对上述验证节点的投票结果进行统计验证，并决定最终的共识结果。
D、所有节点接受确认节点的共识结果，开始下一轮共识流程。
在VBFT算法中，每一轮区块的VRF值都基于上一轮共识区块的易变信息，并通过计算该信息的哈希值来作为下一轮共识区块的VRF值。由此，每一个区块的VRF值都是可验证的。
根据VBFT文中介绍，依据VRF选定节点的同时，也确定了节点的排序顺序，即节点的优先级顺序。优先级顺序的存在，为节点应对主链分叉提供了参考方案。由于恶意分叉很难一直维持最高优先级，从而达到遏制恶意分叉的目的。
在区块链网络中，由于应用场景的不同，所设计的目标各异，不同的区块链系统采用了不同的共识算法。通常，在私有链和联盟链情况下，对一致性、正确性有很强的要求，要采用强一致性的共识算法；而在公有链情况下，对一致性和正确性通常没法做到百分之百，通常采用最终一致性（Eventual Consistency）的共识算法。
共识算法的选择与应用场景高度相关，可信环境使用Paxos算法或者Raft算法，带许可的联盟可使用PBFT算法，非许可链可以使用POW，POS，Ripple共识等，根据对手方信任度分级，自由选择共识机制。
隐私保护一直是分布式系统领域十分关键的问题。在分布式场景下，因为缺乏独立的管理机制，参与网络的各方无法保证严格遵守协议，甚至会故意试图获取网络中他人的数据，对于隐私的窃取行为都很难进行约束。
而分布式账本要在共享协同信息和隐私保护之间达到合适的平衡，是个不小的挑战，特别随着公有账本系统屡屡出现安全漏洞，动辄造成数千万美金的风险。随着《一般数据保护条例》(General Data Protection Regulation，GDPR)的落地，隐私保护的合规要求愈加严格。传统的信息安全技术、形式化验证技术在应对新的需求时暴露出实践性不强的缺陷，都亟待解决。尤其以医疗健康领域，对数据的隐私性需求最为强烈，要求严格控制数据的来源、所有权和使用范围，传统手段很难满足隐私保护特性需求，需要有机结合零知识证明、同态加密等新的密码学手段，但新技术在实际应用中还存在不少问题。
共识是分布式系统领域经典的技术难题，学术界和业界都已有大量的研究成果(包括Paxos、BFT系列算法等)。
分布式共识问题的核心在于确保某个变更在分布式网络中得到一致的执行结果，是被参与多方都承认的，同时信息是不可推翻的。
分布式共识在公开匿名场景下和带权限管理的场景下需求差异较大，从而导致了基于概率的算法和确定性算法两类思想。
最初，比特币区块链考虑的是公开匿名场景下的最坏保证。通过引入了POW工作量证明策略来规避少数人的恶意行为，并通过概率模型保证最后参与方共识到最长链。POW算法的核心思想是基于经济利益的博弈，让恶意破坏的参与者损失经济利益，从而保证大部分人的合作。同时，确认必须经过多个区块的生成后达成，从概率上进行保证。概率性算法的主要问题在于效率的低下和能源的浪费，如POW，POS和DPOS算法等。
区块链技术(如超级账本)在带权限许可的场景下，开始考虑支持更多的确定性的共识机制，包括BFT系列算法等，可以解决快速确认的问题。
共识问题在很长一段时间内都将是极具学术价值的研究热点，核心的指标将包括容错的节点比例、决策收敛速度、出错后的恢复、动态特性等。POW等基于概率的系列算法理论上允许少于一半的不合作节点，BFT等确定性算法理论上则允许不超过1/3的不合作节点。
通常，区块链并不适用于高频交易的场景，但由于金融系统的需求，业界目前十分关心如何尽量提高区块链系统的交易性能，包括吞吐量和确认延迟两个方面。
目前，公开的比特币区块链只能支持平均每秒约7 笔的吞吐量，安全的交易确认时间为一个小时左右；以太坊区块链的吞吐量略高，能达到几十笔每秒，但交易性能也是较大的瓶颈。
为了提高处理性能，一方面可以提升单个节点的性能(如采用高配置的硬件)，同时设计优化的策略和算法，提高性能；另外一方面可将交易处理卸载(off-load)到链下。只用区块链记录最终交易信息，如比特币社区提出的闪电网络等设计。侧链(side chain)、影子链(shadow chain)等思路在当前阶段也有一定的借鉴意义，可将整体性能提升1~2个数量级。
联盟链场景下，参与多方存在一定的信任前提和利益约束，可以采取更优化的设计，换来性能的提升。以Hyperleger Fabric项目为例，在普通虚拟机配置下，单客户端每秒可以达到数百次(Transactions per second，TPS)的交易吞吐量；在有一定工程优化或硬件加速情况下可以达到每秒数千次的吞吐量。
目前开源区块链系统已经可以满足不少应用场景的性能需求，但离大规模交易系统每秒稳定数万笔的吞吐性能还有较大差距。根据公开的数据，VISA系统的处理均值为2000 TPS，峰值为56,000TPS；某金融支付系统的处理峰值超过85,000TPS；大型证券交易所的处理均值在 80,000TPS左右。
常见的分布式系统，可以通过横向增加节点来扩展整个系统的处理能力。
大部分区块链系统的性能很大程度上取决于单个节点的处理能力，节点需要满足高性能、安全、稳定、硬件辅助加解密能力。例如，对于比特币和以太坊区块链，网络中每个参与维护的核心节点都要保持一份完整的存储，并且进行智能合约的处理。此时，整个网络的总存储和计算能力，取决于单个节点的能力。甚至当网络中节点数过多时，可能会因为共识延迟而降低整个网络的性能。尤其在公有网络中，由于大量低性能处理节点的存在，问题将更加明显。
要解决区块链系统的扩展能力，根本上是放松对每个节点都必须参与完整处理的限制(网络中节点要能合作完成完整的处理)，已经在超级账本项目中得到应用；同时尽量减少核心层的处理工作，甚至采用多层处理结构来分散交易。
在联盟链模式下，可以专门采用高性能的节点作为核心节点，用相对较弱的节点作为代理访问节点。
另外，未来必然会涉及到不同账本之间互通的跨链需求。超级账本的Quilt项目和W3C的Interledger Payments工作组已对此问题开展研究。
区块链目前最热门的应用场景是金融相关的服务，安全自然是最敏感也是挑战最大的问题。
区块链网络中的大量信息需要写到文件和数据库中进行持久化存储。
区块链的应用需要进行大量的读写操作、Hash计算和验证操作，跟传统数据库的行为十分不同。
LevelDB、RocksDB 等键值数据库，具备很高的随机写和顺序读、写性能,以及相对较差的随机读的性能，被广泛应用到了区块链信息存储中。但目前来看，面向区块链的数据库技术仍然是需要突破的技术难点之一，特别是如何支持更丰富语义的操作。未来将可能出现更具针对性的区块链数据库，专门服务区块链新型数据业务，其中每条记录将包括一个完整的区块信息，并天然地跟历史信息进行关联，一旦写入确认则无法修改。所有操作的最小单位将是一个块。需要原生支持高效的签名和加解密处理。
大部分企业内和企业之间都已经存在一些信息化产品和工具，例如处于核心位置的数据库、企业信息管理系统、通讯系统等。企业在采用新的产品时，往往会重点考察与已有商业流程和信息系统进行集成时的平滑度。
两种系统如何共存，如何分工，彼此的业务交易如何进行合理传递，出现故障如何排查和隔离，已有数据如何在不同系统之间进行迁移和灾备，都是很迫切要解决的实际问题。解决不好，将是区块链技术落地的不小阻碍。
虽然大部分区块链系统在平台层面都支持了非中心化机制，在运营和治理层面确往往做不到非中心化。以比特币网络为例，历史上多次发生过大部分算力集中在少数矿池的情况，同时软件的演化路线集中在少数开发者手中。运营和治理机制是现有区块链系统中普遍缺失的，但在实际应用中又十分重要。
如何进行合理的共识、高效的治理仍属于尚未解决的问题。公有链中试图通过将计算机系统中的令牌与经济利益挂钩，维护系统持续运行；联盟链中通过商业合作和投票等方式，推举联盟治理机构，进行联盟网络的维护管理。但相关机制仍需在实践过程中不断完善和改进。以供应链场景为例，动辄涉及到数百家企业，上下游几十个环节，而且动态性较强，都需要分布式账本平台能提供很强的治理投票和权限管控机制。