《区块链原理、设计与应用》一2.3 关键问题和挑战-阿里云开发者社区

开发者社区> 华章出版社> 正文

《区块链原理、设计与应用》一2.3 关键问题和挑战

简介: 本节书摘来自华章出版社《区块链原理、设计与应用》一 书中的第2章,第2.3节,作者:杨保华 陈昌,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.3 关键问题和挑战

从技术角度讲,区块链所涉及的领域比较繁杂,包括分布式系统、存储、密码学、心理学、经济学、博弈论、控制论、网络协议等,这也就意味着大量工程实践上的技术挑战。
下面列出了目前业内关注较多的一些技术话题。
1.?抗抵赖与隐私保护
怎么防止交易记录被篡改?
怎么证明交易双方的身份?
怎么保护交易双方的隐私?
密码学的发展为解决这些问题提供了不少手段。传统方案包括 Hash 算法、加解密算法、数字证书和签名(盲签名、环签名)等。
随着区块链技术的应用,新出现的需求将刺激密码学的进一步发展,包括更高效的随机数产生、更高强度的加密、更快速的加解密处理等。同时,量子计算等新技术的出现,也会带来更多的挑战,例如,RSA 算法等目前商用的加密算法,在未来可能无法提供足够的安全性。
能否满足这些新的需求,将依赖于数学科学的进一步发展和新一代计算技术的突破。
2.?分布式共识
这是个经典的技术难题,学术界和业界都已有大量的研究成果(包括Paxos、拜占庭系列算法等)。
问题的核心在于如何解决某个变更在分布式网络中得到一致的执行结果,是被参与多方都承认的,同时这个信息是被确定的,不可推翻的。
该问题在公开匿名场景下和带权限管理的场景下需求差异较大,从而导致了基于概率的算法和确定性算法两类思想。
最初,比特币区块链考虑的是公开匿名场景下的最坏保证。通过引入了“工作量证明”策略来规避少数人的恶意行为,并通过概率模型保证最后参与方共识到最长链。算法在核心思想上是基于经济利益的博弈,让恶意破坏的参与者损失经济利益,从而保证大部分人的合作。同时,确认必须经过多个区块的生成之后达成,从概率上进行保证。这类算法的主要问题在于效率的低下。类似算法还有以权益为抵押的 PoS、DPoS 和 Casper 等。
后来更多的区块链技术(如超级账本)在带权限管理的场景下,开始考虑支持更多的确定性的共识机制,包括经典的拜占庭算法等,可以解决快速确认的问题。
共识问题在很长一段时间内都将是极具学术价值的研究热点,核心的指标将包括容错的节点比例、决策收敛速度、出错后的恢复、动态特性等。PoW 等基于概率的系列算法理论上允许少于一半的不合作节点,PBFT 等确定性算法理论上则允许不超过 1/3 的不合作节点。
3.?交易性能
虽然一般来说,区块链不适用于高频交易的场景,但由于金融系统的需求,业界目前十分关心如何提高区块链系统交易的吞吐量,同时降低交易的确认延迟。
目前,公开的比特币区块链只能支持平均每秒约 7 笔的吞吐量,一般认为对于大额交易来说,安全的交易确认时间为一个小时左右。以太坊区块链的吞吐量略高一些,但交易性能也被认为是较大的瓶颈。
实际上,小额交易只要确认被广播到网络中并带有合适的交易服务费用,即有较大概率被最终打包。
区块链系统跟传统分布式系统不同,其处理性能很难通过单纯增加节点数来进行横向扩展。实际上,传统区块链系统的性能,在很大程度上取决于单个节点的处理能力。高性能、安全、稳定性、硬件辅助加解密能力,都将是考查节点性能的核心要素。
这种场景下,为了提高处理性能,一方面可以提升单个节点的性能(如采用高配置的硬件),同时设计优化的策略和算法;另外一方面试图将大量高频的交易放到链外来,只用区块链记录最终交易信息,如比特币社区提出的“闪电网络”等设计。类似地,侧链(side chain)、影子链(shadow chain)等思路在当前阶段也有一定的借鉴意义。类似设计可以将交易性能提升 1~2 个数量级。
此外,在联盟链的场景下,参与多方存在一定的信任前提和利益约束,可以采取更优化的设计,换来性能的提升。以超级账本 Fabric 项目为例,在普通虚拟机配置下,单客户端交易吞吐量可达几百次每秒(transactions per second,tps);在有一定工程优化或硬件加速情况下可以达到每秒数千次的吞吐量。
客观地说,目前开源区块链系统已经可以满足不少应用场景的性能需求,但离大规模交易系统在峰值每秒数万笔的吞吐性能还有较大差距。
据公开的数据,VISA 系统的处理均值为 2000tps,号称的峰值为 56?000tps;某金融支付系统的处理峰值超过了 85?000tps;某大型证券交易所号称的处理均(峰)值在 80?000tps 左右。
4.?扩展性
常见的分布式系统可以通过增加节点来横向扩展整个系统的处理能力。对于区块链网络系统来说,根据共识机制的不同,这个问题往往并非那么简单。
例如,对于比特币和以太坊区块链而言,网络中每个参与维护的核心节点都要保持一份完整的存储,并且进行智能合约的处理。此时,整个网络的总存储和计算能力取决于单个节点的能力。甚至当网络中节点数过多时,可能会因为一致性的达成过程延迟降低整个网络的性能。尤其在公有网络中,由于存在大量低性能处理节点,导致这个问题将更加明显。
要解决这个问题,根本上是放松对每个节点都必须参与完整处理的限制(当然,网络中节点要能合作完成完整的处理),这个思路已经在超级账本中得到应用;同时尽量减少核心层的处理工作。
在联盟链模式下,还可以专门采用高性能的节点作为核心节点,相对较弱的节点仅作为代理访问节点。
5.?安全防护
区块链目前最热门的应用场景是金融相关的服务,安全自然是讨论最多、挑战最大的话题。区块链在设计上大量采用了现代成熟的密码学算法。但这是否就能确保其绝对安全呢?
世界上并没有绝对安全的系统。
系统是由人设计的,系统也是由人来运营的,只要有人参与的系统,就难免出现漏洞。如下几个方面是很难避免的。
首先是立法。对区块链系统如何进行监管?攻击区块链系统是否属于犯罪?攻击银行系统是要承担后果的。但是目前还没有任何法律保护区块链(特别是公有链)以及基于它的实现。
其次是软件实现的潜在漏洞。考虑到使用了几十年的 OpenSSL 还带着那么低级的漏洞(heart bleeding),而且是源代码完全开放的情况下,让人不禁对运行中的大量线上系统持谨慎态度。而对于金融系统来说,无论客户端还是平台侧,即便是很小的漏洞都可能造成难以估计的损失。
另外,公有区块链所有交易记录都是公开可见的,这意味着所有的交易即便被匿名化和加密处理,但总会在未来某天被破解。安全界一般认为,只要物理上可接触就不是彻底的安全。实际上,已有文献证明,比特币区块链的交易记录很大可能是能追踪到真实用户的。
作为一套完全分布式的系统,公有的区块链缺乏有效的调整机制。一旦运行起来,出现问题也难以修正。即使是让它变得更高效、更完善的修改,只要有部分既得利益者联合起来反对,就无法得到实施。比特币社区已经出现过多次类似的争论。
最后,运行在区块链上的智能合约应用可能是五花八门的,可能存在潜在的漏洞,必须有办法进行安全管控,在注册和运行前需要有合理的机制进行探测,以规避恶意代码的破坏。
2016 年 6 月 17 日发生的“ DAO 系统漏洞被利用 ”事件,直接导致价值 6000 万美元的数字货币被利用者获取。尽管对于这件事情的反思还在进行中,但事实再次证明,目前基于区块链技术进行生产应用时,务必要细心谨慎地进行设计和验证。必要时,甚至要引入“形式化验证”和人工审核机制。
可以参考著名黑客米特尼克所著的《反欺骗的艺术——世界传奇黑客的经历分享》,其中介绍了大量的实际社交工程欺骗场景。
6.?数据库和存储系统
区块链网络中的大量信息需要写到文件和数据库中进行存储。
观察区块链的应用,大量的读写操作、Hash 计算和验证操作,跟传统数据库的行为十分不同。当年,人们观察到互联网应用大量非事务性的查询操作,而设计了非关系型(NoSQL)数据库。那么,针对区块链应用的这些特点,是否可以设计出一些特殊的针对性的数据库呢?
LevelDB、RocksDB 等键值数据库,具备很高的随机写和顺序读、写性能,以及相对较差的随机读的性能,被广泛应用到了区块链信息存储中。但目前来看,面向区块链的数据库技术仍然是需要突破的技术难点之一,特别是如何支持更丰富语义的操作。
大胆预测,未来将可能出现更具针对性的“块数据库”(BlockDB),专门服务类似区块链这样的新型数据业务,其中每条记录将包括一个完整的区块信息,并天然地跟历史信息进行关联,一旦写入确认则无法修改。所有操作的最小单位将是一个块。为了实现这种结构,需要原生支持高效的签名和加解密处理。
7.?集成和运营
即便大量企业系统准备迁移到区块链平台上,但在相当长的一段时间内,基于区块链的新业务系统必将与已有的中心化系统集成共存。
两种系统如何共存,如何分工,彼此的业务交易如何进行合理传递?出现故障如何排查和隔离?已有数据如何在不同系统之间进行迁移和灾备?区块链系统自身又该如何进行运营(如网络的设计选择、状态监控、灾备等)?
这些都是迫切要解决的实际问题。若解决不好,将是区块链技术落地的不小阻碍。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接