• 关键问题和挑战
    • 隐私保护
    • 分布式共识
    • 交易性能
    • 扩展性
    • 安全防护
    • 数据库和存储系统
    • 互操作和运营治理

    关键问题和挑战

    从技术角度讲,区块链所涉及到的领域比较繁杂,包括分布式系统、密码学、心理学、经济学、博弈论、控制论、网络协议等,这也意味着工程实践中大量的挑战。

    下面列出了目前业界关注较多的一些技术话题。

    隐私保护

    隐私保护一直是分布式系统领域十分关键的问题。在分布式场景下,因为缺乏独立的管理机制,参与网络的各方无法保证严格遵守协议,甚至会故意试图获取网络中他人的数据,这些行为都很难进行约束。

    而分布式账本要在共享协同信息和隐私保护之间达到合适的平衡,是个不小的挑战。特别随着公有账本系统屡屡出现安全漏洞,动辄造成数千万美金的风险;随着欧盟《通用数据保护条例》(General Data Protection Regulation,GDPR)的落地,隐私保护的合规要求愈加严格;传统的信息安全技术、形式化验证技术在应对新的需求时暴露出实践性不强的缺陷,都亟待解决。

    尤其以医疗健康领域,对数据的隐私性需求最为强烈,要求严格控制数据的来源、所有权和使用范围,传统手段很难满足这些特性,需要有机结合零知识证明、同态加密等新的密码学手段。而这些新技术在实际应用中还存在不少问题。

    分布式共识

    共识是分布式系统领域经典的技术难题,学术界和业界都已有大量的研究成果(包括 Paxos、拜占庭系列算法等)。

    问题的核心在于确保某个变更在分布式网络中得到一致的执行结果,是被参与多方都承认的,同时这个信息是不可推翻的。

    该问题在公开匿名场景下和带权限管理的场景下需求差异较大,从而导致了基于概率的算法和确定性算法两类思想。

    最初,比特币区块链考虑的是公开匿名场景下的最坏保证。通过引入了“工作量证明”(Proof of Work)策略来规避少数人的恶意行为,并通过概率模型保证最后参与方共识到最长链。算法的核心思想是基于经济利益的博弈,让恶意破坏的参与者损失经济利益,从而保证大部分人的合作。同时,确认必须经过多个区块的生成之后达成,从概率上进行保证。这类算法的主要问题在于效率的低下和能源的浪费。类似地,还有以权益为抵押的 PoS 和 DPoS 算法等。

    后来更多的区块链技术(如超级账本)在带权限许可的场景下,开始考虑支持更多的确定性的共识机制,包括经典的拜占庭算法等,可以解决快速确认的问题。

    共识问题在很长一段时间内都将是极具学术价值的研究热点,核心的指标将包括容错的节点比例、决策收敛速度、出错后的恢复、动态特性等。PoW 等基于概率的系列算法理论上允许少于一半的不合作节点,PBFT 等确定性算法理论上则允许不超过 1/3 的不合作节点。

    交易性能

    一般情况下,区块链并不适用于高频交易的场景,但由于金融系统的需求,业界目前也十分关心如何尽量提高区块链系统的交易性能,包括吞吐量和确认延迟两个方面。

    目前,公开的比特币区块链只能支持平均每秒约 7 笔的吞吐量,安全的交易确认时间为一个小时左右。以太坊区块链的吞吐量略高一些能到几十笔每秒,但交易性能也被认为是较大的瓶颈。2017 年底一款名为 CryptoKitties 的游戏应用造成以太坊网络的严重堵塞。

    这种场景下,为了提高处理性能,一方面可以提升单个节点的性能(如采用高配置的硬件),同时设计优化的策略和算法,提高性能;另外一方面可将交易处理卸载(off-load)到链下。只用区块链记录最终交易信息,如比特币社区提出的 闪电网络 等设计。类似地,侧链(side chain)、影子链(shadow chain)等思路在当前阶段也有一定的借鉴意义。类似设计可将整体性能提升 1~2 个数量级。

    联盟链场景下,参与多方存在一定的信任前提和利益约束,可以采取更优化的设计,换来性能的提升。以超级账本 Fabric 项目为例,在普通虚拟机配置下,单客户端每秒可以达到数百次(Transactions per second,tps)的交易吞吐量;在有一定工程优化或硬件加速情况下可以达到每秒数千次的吞吐量。

    客观地说,目前开源区块链系统已经可以满足不少应用场景的性能需求,但离大规模交易系统每秒稳定数万笔的吞吐性能还有较大差距。

    注:据公开的数据,VISA 系统的处理均值为 2,000 tps,峰值为 56,000 tps;某金融支付系统的处理峰值超过了 85,000 tps;某大型证券交易所号称的处理均(峰)值在 80,000 tps 左右。

    扩展性

    常见的分布式系统,可以通过横向增加节点来扩展整个系统的处理能力。

    对于区块链网络系统来说,跟传统分布式系统不同,这个问题往往并非那么简单。实际上,大部分区块链系统的性能,很大程度上取决于单个节点的处理能力。对这些系统来说,节点需要满足 高性能、安全、稳定、硬件辅助加解密能力

    例如,对于比特币和以太坊区块链而言,网络中每个参与维护的核心节点都要保持一份完整的存储,并且进行智能合约的处理。此时,整个网络的总存储和计算能力,取决于单个节点的能力。甚至当网络中节点数过多时,可能会因为共识延迟而降低整个网络的性能。尤其在公有网络中,由于大量低性能处理节点的存在,问题将更加明显。

    要解决这个问题,根本上是放松对每个节点都必须参与完整处理的限制(当然,网络中节点要能合作完成完整的处理),这个思路已经在超级账本等项目中得到应用;同时尽量减少核心层的处理工作,甚至采用多层处理结构来分散交易。

    在联盟链模式下,还可以专门采用高性能的节点作为核心节点,用相对较弱的节点作为代理访问节点。

    另外,未来必然会涉及到不同账本之间互通的需求(跨链)。目前无论是基于公证人(Notary)、侧链/中继链锚定(Sidechains / Relays)还是哈希锁定(Hash-locking)机制,在实践中仍存在一些不足。公证人机制往往需要依赖第三方的公证人,存在中心化的弱点;侧链/中继链锚定机制目前应用在资产类转移场景,依赖不同链之间的合约配合;哈希锁定在闪电网络中最早提出,并应用在 W3C 的 Interledger 协议中,目前只支持支付类交换操作,而且要求双方账本理解彼此合约。

    超级账本的 Quilt 项目和 W3C 的 Interledger Payments 工作组已对此问题开展研究,但离通用的跨链需求还有距离。目前来看,要想解决跨链的扩展性问题,需要有办法打通不同框架,类似路由器来沟通不同的子网。

    安全防护

    区块链目前最热门的应用场景是金融相关的服务,安全自然是最敏感也是挑战最大的问题。

    区块链在设计上大量采用了现代成熟的密码学算法和网络通信协议。但这是否就能确保其绝对安全呢?

    世界上并没有绝对安全的系统。

    系统越复杂,攻击面越多,安全风险越高;另外系统是由人设计的和运营的,难免出现漏洞。

    作为分布式系统,区块链首先要考虑传统的网络安全(认证、过滤、攻防)、信息安全(密码配置、密钥管理)、管理安全(审计、风险分析控制)等问题。其次,尤其要注意新场景下凸显的安全挑战。

    首先是立法。对区块链系统如何进行监管?攻击区块链系统是否属于犯罪?攻击银行系统是要承担后果的。但是目前还没有任何法律保护区块链(特别是公有链)以及基于它的实现。

    其次是代码实现的漏洞管理。考虑到使用了几十年的 openssl 还带着那么低级的漏洞(heart bleeding),而且是源代码完全开放的情况下,让人不禁对运行中的大量线上系统持谨慎态度。而对于金融系统来说,无论客户端还是平台侧,即便是很小的漏洞都可能造成难以估计的损失。

    另外,公有区块链所有交易记录都是公开可见的,这意味着所有的交易,即便被匿名化和加密处理,但总会在未来某天被破解。安全界一般认为,只要物理上可接触就不是彻底的安全。实际上,已有文献证明,比特币区块链的交易记录大部分都能追踪到真实用户。

    公有链普遍缺乏有效的治理和调整机制,一旦运行中出现问题难以及时修正。即使是有人提交了修正补丁,只要有部分既得利益者联合起来反对,就无法得到实施。比特币社区已经出现过多次类似的争论。

    最后,运行在区块链上的智能合约应用五花八门,可能存在潜在的漏洞,必须要有办法进行安全管控,在注册和运行前进行形式化验证和安全探测,以规避恶意代码的破坏。运行智能合约的环境也会成为攻击的目标。近些年区块链领域的安全事件大都跟智能合约漏洞有关。

    2014 年 3 月,Mt.gox 交易所宣称其保存的 85 万枚比特币被盗,直接导致破产。

    2016 年 6 月 17 日,发生 DAO 系统漏洞被利用 事件,直接导致价值 6000 万美元的数字货币被利用者获取。尽管对于这件事情的反思还在进行中,但事实再次证明,目前基于区块链技术进行生产应用时,务必要细心谨慎地进行设计和验证。必要时,甚至要引入“形式化验证”和人工审核机制。

    2018 年 3 月,币安交易所被黑客攻击,造成用户持有比特币被大量卖出。虽然事后进行了追回,但仍在短期内对市场价格造成了巨大冲击。

    注:著名黑客凯文•米特尼克(Kevin D. Mitnick)所著的《反欺骗的艺术——世界传奇黑客的经历分享》一书中分享了大量的真实社交工程欺骗案例。

    数据库和存储系统

    区块链网络中的大量信息需要写到文件和数据库中进行存储。

    观察区块链的应用,大量的读写操作、Hash 计算和验证操作,跟传统数据库的行为十分不同。

    当年,人们观察到互联网场景中大量非事务性的查询操作,而设计了非关系型(NoSQL)数据库。那么,针对区块链应用的这些特点,是否可以设计出一些特殊的针对性的数据库呢?

    LevelDB、RocksDB 等键值数据库,具备很高的随机写和顺序读、写性能,以及相对较差的随机读的性能,被广泛应用到了区块链信息存储中。但目前来看,面向区块链的数据库技术仍然是需要突破的技术难点之一,特别是如何支持更丰富语义的操作。

    大胆预测,未来将可能出现更具针对性的“块数据库(BlockDB)”,专门服务类似区块链这样的新型数据业务,其中每条记录将包括一个完整的区块信息,并天然地跟历史信息进行关联,一旦写入确认则无法修改。所有操作的最小单位将是一个块。为了实现这种结构,需要原生支持高效的签名和加解密处理。

    互操作和运营治理

    大部分企业内和企业之间都已经存在了一些信息化产品和工具,例如处于核心位置的数据库、企业信息管理系统、通讯系统等。企业在采用新的产品时,往往会重点考察与已有商业流程和信息系统进行集成时的平滑度。

    两种系统如何共存,如何分工,彼此的业务交易如何进行合理传递?出现故障如何排查和隔离?已有数据如何在不同系统之间进行迁移和灾备?这些都是很迫切要解决的实际问题。解决不好,将是区块链技术落地的不小阻碍。

    另外,虽然大部分区块链系统在平台层面都支持了非中心化机制,在运营和治理层面确往往做不到那么非中心化。以比特币网络为例,历史上多次发生过大部分算力集中在少数矿池的情况,同时软件的演化路线集中在少数开发者手中。运营和治理机制是现有区块链系统中普遍缺失的,但在实际应用中又十分重要。

    如何进行合理的共识、高效的治理仍属于尚未解决的问题。公有账本中试图通过将计算机系统中的令牌与经济利益挂钩,维护系统持续运行;联盟账本中通过商业合作和投票等方式,推举联盟治理机构,进行联盟网络的维护管理。这些机制仍需在实践过程中不断完善和改进。以供应链场景为例,动辄涉及到数百家企业,上下游几十个环节,而且动态性较强。这些都需要分布式账本平台能提供很强的治理投票和权限管控机制。