# 关键问题和挑战 从技术角度讲，区块链所涉及的领域比较繁杂，包括分布式系统、密码学、心理学、经济学、博弈论、控制论、网络协议等，这也意味着我们在工程实践中会面临大量的挑战。 下面列出了目前业界关注较多的一些技术话题。 ## 隐私保护 隐私保护一直是分布式系统领域十分关键的问题。在分布式场景下，因为缺乏独立的管理机制，参与网络的各方无法保证严格遵守协议，甚至会故意试图获取网络中他人的数据，对这些行为都很难进行约束。 要在共享协同信息和隐私保护之间达到合适的平衡是个不小的挑战，目前，公有账本系统屡屡出现安全漏洞，动辄造成数千万美金损失的风险。随着欧盟《通用数据保护条例》（General Data Protection Regulation，GDPR）的落地，隐私保护的合规要求愈加严格；传统的信息安全技术、形式化验证技术在应对新的需求时暴露出实践性不强的缺陷，都亟待解决。 尤其是医疗健康领域，对数据的隐私性需求最为强烈，要求严格控制数据的来源、所有权和使用范围。传统的基于加密的手段很难满足这些要求，需要结合零知识证明、同态加密、隐私查询等新的密码学手段。而这些新技术在实际应用中还存在不少问题。 ## 分布式共识 共识是分布式系统领域经典的技术难题，学术界和业界都已有大量的研究成果（包括 Paxos、拜占庭系列算法等）。 问题的核心在于确保某个变更在分布式网络中得到一致的执行结果，是被参与多方都承认的，同时这个信息是不可推翻的。 该问题在公开匿名场景下和带权限管理的场景下需求差异较大，从而导致了基于概率的算法和确定性算法两类思想。 最初，比特币区块链考虑的是公开匿名场景下的最坏保证。通过引入了“工作量证明”（Proof of Work）策略来限制少数算力的恶意行为，并通过概率模型使有效网络最终收敛到累计工作量最大的链。算法的核心思想是基于经济利益的博弈，让恶意破坏的参与者承担算力、电力和机会成本，从而激励大部分算力合作。同时，确认必须经过多个区块的生成之后达成，从概率上进行保证。这类算法的主要问题在于效率低下和能源浪费。类似地，还有以权益为抵押的 PoS 和 DPoS 算法等。 后来更多的区块链技术（如超级账本）在带权限许可的场景下，开始考虑支持更多的确定性的共识机制，包括改进的拜占庭算法等，可以解决快速确认的问题。但已有算法往往在大规模和动态场景下表现不佳。 共识问题在很长一段时间内都将是极具学术价值的研究热点，核心的指标将包括支持规模、容错的资源比例、决策收敛速度、出错后的恢复、动态特性等。PoW 等基于概率的系列算法通常按算力或权益等资源占比分析安全边界，而不能简单按节点数量计算；PBFT 等确定性算法理论上则允许不超过 1/3 的不合作节点。 ## 交易性能 一般情况下，区块链并不适用于高频交易的场景，但由于金融系统的迫切需求，业界目前积极探讨如何提高其交易性能，包括吞吐量（Throughput）和确认延迟（Latency）两个方面。 目前，公开的比特币公有区块链只能支持平均每秒约 7 笔的吞吐量，常见高价值交易会等待约一小时的多个区块确认。以太坊在 2022 年合并后已转为 PoS，但其一层吞吐量仍受区块 gas、区块时间和去中心化约束，难以直接满足高频交易类应用。2017 年底，游戏应用 CryptoKitties 就造成了以太坊网络的严重堵塞。 *注：这些限制主要针对一层（Layer 1）链上交易。截至 2026 年 4 月，比特币闪电网络、以太坊 Rollup（Arbitrum、Optimism 等）和 StarkNet 等二层（Layer 2）方案已经在生产环境中使用，主要通过链下执行、批量提交或状态通道等方式降低成本并提升容量。但不同方案的安全假设、数据可用性、退出机制和实际吞吐量差异很大，不宜笼统宣称都能达到数千或数万 tps。* 这种场景下，为了提高处理性能，一方面可以提升单个节点的性能（如采用高配置的硬件），同时设计优化的策略和并行算法而提高性能；另外一方面可将交易处理卸载（off-load）到链下，只用区块链记录最终交易信息，如比特币社区提出的 [闪电网络](https://lightning.network/lightning-network-paper.pdf) 等设计。类似地，侧链（side chain）、影子链（shadow chain）等思路在当前阶段也有一定的借鉴意义。实际性能提升取决于应用模式、资产桥接、数据可用性和最终结算方式。 联盟链场景下，参与方在共同的信任前提和利益约束下，可以采取更激进的设计，换取性能的提升。以超级账本 Fabric 项目为例，普通虚拟机配置即可达到每秒数千次的交易吞吐量；在进一步优化或硬件加速情况下可以达到每秒数万次的处理性能。 整体来看，开源区块链系统已经可以满足一部分支付、资产登记、供应链协作和审计追踪等应用场景的性能需求。对于高频交易、实时零售支付或大规模撮合等场景，仍需要结合 Layer 2、联盟链、链下系统或传统数据库进行架构取舍。 *注：传统支付网络、证券交易所和互联网支付系统的吞吐量口径并不一致，区块链 Layer 2 的“理论峰值”“批处理能力”和“实际用户交易吞吐量”也不是同一指标。做工程选型时，应比较端到端确认延迟、可用性、结算终局性、合规和灾备能力，而不是只比较 tps。* ## 扩展性 常见的分布式系统，可以通过横向增加节点来扩展整个系统的处理能力。 对于区块链网络系统来说，跟传统分布式系统不同，这个问题往往并非那么简单。实际上，大部分区块链系统的性能，很大程度上取决于单个节点的处理能力。对这些系统来说，节点需要满足 **高性能、安全、稳定、硬件辅助加解密能力**。 例如，对于比特币和以太坊区块链而言，网络中每个参与维护的核心节点都要保持一份完整的存储，并且进行智能合约的处理。此时，整个网络的总存储和计算能力，取决于单个节点的能力。甚至当网络中节点数过多时，可能会因为共识延迟而降低整个网络的性能。尤其在公有网络中，由于大量低性能处理节点的存在，问题将更加明显。 要解决这个问题，根本上是放松对每个节点都必须参与完整处理的限制（当然，网络中节点要能合作完成完整的处理），这个思路已经在超级账本等项目中得到应用；同时尽量减少核心层的处理工作，甚至采用多层处理结构来分散交易。 在联盟链模式下，还可以专门采用高性能的节点作为核心节点，用相对较弱的节点作为代理访问节点。 另外，未来必然会涉及到不同账本之间互通的需求（跨链）。目前无论是基于公证人（Notary）、侧链/中继链锚定（Sidechains / Relays）还是哈希锁定（Hash-locking）机制，在实践中仍存在一些不足。公证人机制往往需要依赖第三方的公证人，存在中心化的弱点；侧链/中继链锚定机制目前应用在资产类转移场景，依赖不同链之间的合约配合；哈希锁定在闪电网络中最早提出，并应用在 W3C 的 Interledger 协议中，目前只支持支付类交换操作，而且要求双方账本理解彼此合约。 超级账本的 Quilt 项目和 W3C 的 Interledger Payments 工作组已对此问题开展研究，但离通用的跨链需求还有距离。目前来看，要想解决跨链的扩展性问题，需要有办法打通不同框架，类似路由器来沟通不同的子网。 ## 安全防护 区块链目前最热门的应用场景是金融相关的服务，安全自然是最敏感也是挑战最大的问题。 区块链在设计上大量采用了现代成熟的密码学算法和网络通信协议。但这是否就能确保其绝对安全呢？ **世界上并没有绝对安全的系统。** 系统越复杂，攻击面越多，安全风险越高；另外系统是由人设计的和运营的，难免出现漏洞。 作为分布式系统，区块链首先要考虑传统的网络安全（认证、过滤、攻防）、信息安全（密码配置、密钥管理）、管理安全（审计、风险分析控制）等问题。其次，尤其要注意新场景下凸显的安全挑战。 首先是监管和责任边界。对区块链系统如何进行监管？攻击区块链系统是否属于犯罪？不同司法辖区的答案并不完全相同。以美国为例，涉及黑客入侵、诈骗、勒索、洗钱或制裁规避的数字资产案件已经可以被既有刑事和民事执法工具追究；但公有链协议本身、去中心化治理、跨境资产追索和智能合约责任归属等问题仍在演化中，不能作绝对化表述。 其次是代码实现的漏洞管理。考虑到使用了几十年的 openssl 还带着那么低级的漏洞（[heart bleeding](https://heartbleed.com/)），而且是源代码完全开放的情况下，让人不禁对运行中的大量线上系统持谨慎态度。而对于金融系统来说，无论客户端还是平台侧，即便是很小的漏洞都可能造成难以估计的损失。 另外，公有区块链所有交易记录都是公开可见的，这意味着所有的交易，即便被匿名化和加密处理，但总会在未来某天被破解。安全界一般认为，只要物理上可接触就不是彻底的安全。实际上，已有文献证明，比特币区块链的交易记录大部分都能追踪到真实用户。 公有链普遍缺乏有效的治理和调整机制，一旦运行中出现问题难以及时修正。即使是有人提交了修正补丁，只要有部分既得利益者联合起来反对，就无法得到实施。比特币社区已经出现过多次类似的争论。 最后，运行在区块链上的智能合约应用五花八门，可能存在潜在的漏洞，必须要有办法进行安全管控，在注册和运行前进行形式化验证和安全探测，以规避恶意代码的破坏。运行智能合约的环境也会成为攻击的目标。近些年区块链领域的安全事件大都跟智能合约漏洞有关。 2014 年 3 月，Mt.gox 交易所宣称其保存的 85 万枚比特币被盗，直接导致破产。 2016 年 6 月 17 日，发生 [DAO 系统漏洞被利用](https://blog.daohub.org/the-dao-is-under-attack-8d18ca45011b) 事件，直接导致价值 6000 万美元的数字货币被利用者获取。这一事件催生了智能合约安全审计行业的发展。尽管对于这件事情的反思还在进行中，但事实再次证明，目前基于区块链技术进行生产应用时，务必要细心谨慎地进行设计和验证。必要时，甚至要引入“形式化验证”和人工审核机制。（详见第三章“[失败案例分析](/blockchain_guide/03_scenario/failure.md)”中的深入讨论。） 2018 年 3 月，币安交易所被黑客攻击，造成用户持有比特币被大量卖出。虽然事后进行了追回，但仍在短期内对市场价格造成了巨大冲击。 *注：著名黑客凯文•米特尼克（Kevin D. Mitnick）所著的《反欺骗的艺术——世界传奇黑客的经历分享》一书中分享了大量的真实社交工程欺骗案例。* ## 数据库和存储系统 区块链网络中的大量信息需要写到文件和数据库中进行存储。 观察区块链的应用，大量的读写操作、Hash 计算和验证操作，跟传统数据库的行为十分不同。 当年，人们观察到互联网场景中大量非事务性的查询操作，而设计了非关系型（NoSQL）数据库。那么，针对区块链应用的这些特点，是否可以设计出一些特殊的针对性的数据库呢？ LevelDB、RocksDB 等键值数据库，具备很高的随机写和顺序读、写性能，以及相对较差的随机读的性能，被广泛应用到了区块链信息存储中。但目前来看，面向区块链的数据库技术仍然是需要突破的技术难点之一，特别是如何支持更丰富语义的操作。 正如此前预测，目前已经出现了引入区块链特性的“账本数据库”，包括甲骨文等产品。它们通过签名来防抵赖，并追溯数据修改历史，提供审计功能。亚马逊曾推出 Quantum Ledger Database（QLDB），但 AWS 已公告其支持截至 2025 年 7 月 31 日结束，新项目不应再将其作为可持续选型。 此外，在高吞吐量的场景下，本地账本结构会快速累积大量数据。这些数据的保存、索引、清理，发生故障后的恢复，新加入节点的数据获取等，都是值得探索的开放问题。 ## 互操作和运营治理 大部分企业内和企业之间都已经存在了一些信息化产品和工具，例如，处于核心位置的数据库、企业信息管理系统、通讯系统等。企业在采用新的产品时，往往会重点考察与已有商业流程和信息系统进行集成时的平滑度。 两种系统如何共存，如何分工，彼此的业务交易如何进行合理传递？出现故障如何排查和隔离？已有数据如何在不同系统之间进行迁移和灾备？这些都是很迫切要解决的实际问题。解决不好，将是区块链技术落地的不小阻碍。 另外，虽然大部分区块链系统在平台层面都支持了去中心化机制，在运营和治理层面却往往做不到那么去中心化。以比特币网络为例，历史上多次发生过大部分算力集中在少数矿池的情况，同时软件的演化路线集中在少数开发者手中。运营和治理机制是现有区块链系统中普遍缺失的，但在实际应用中又十分重要。 如何进行合理的共识、高效的治理仍属于尚未解决的问题。公有账本试图通过将计算机系统中的令牌与经济利益挂钩，维护系统持续运行；联盟账本通过商业合作和投票等方式，推举联盟治理机构，进行联盟网络的维护管理。这些机制仍需在实践过程中不断完善和改进。以供应链场景为例，动辄涉及数百家企业，上下游几十个环节，而且动态性较强。这些都需要分布式账本平台能提供很强的治理投票和权限管控机制。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yeasy.gitbook.io/blockchain_guide/02_overview/challenge.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.