干货|公有链的8大挑战及其解决方案

image

毫无疑问区块链技术有巨大的潜力。在 2017 年里,人们高昂的热情为 I-C-O 募集了数百亿资金,大大提升了加密货币市场的规模。

然而,另一面却没有得到足够重视:区块链存在一些技术壁垒(technical barriers),这导致难以有效地将它应用到主流人群里。这些技术壁垒包括:

  • 可扩展性的限制

  • 隐私保护的限制

  • 缺乏合约的形式化验证

  • 存储限制

  • 难以证明的共识机制

  • 缺乏治理和标准

  • 缺乏开发工具

  • 量子计算机的威胁

  • 还有…

在这篇文章里,我会一一阐述这些技术壁垒,并分享一些可行的解决方案。

1

可扩展性的限制

当前公有链的共识协议都存在这样的限制:网络中的全节点参与者需要处理全部交易。

为什么会这样?因为区块链本质上是「去中心化」——这意味着不存在一个中心团体来保护和维持系统。取而代之,网络的每个节点都会处理每笔交易并维持全状态副本,通过这种方式来保护系统。

去中心化共识机制的关键优势是安全保证、政治中立和抵抗审查等。然而,这是以扩展性为代价换来的,因为去中心化限制了区块链里全节点可处理交易的数量。

实质上这带来了两个影响:

  • 低吞吐量:区块链可处理交易的数量十分有限

  • 缓慢的交易速度:处理一个区块的时间很长。比如比特币的区块时间是 10 分钟,以太坊的区块时间大约是 14 秒。在高峰期里花费的时间甚至更长。相较之下,Square 和 Visa 等服务的交易是即时确认的。

因此,公有链需要在低交易吞吐量和高中心化之间做一个权衡。

换句话说,随着区块链大小的增加,网络里全节点所需的存储、带宽和计算能力也会增加。当到达某个时刻,就只有少数节点才能提供足够资源来处理区块——这会带来中心化风险。

在那时,我们会回到需信任少数大节点的中心化系统里。然而我们想要的系统是:它既能每秒处理上千笔交易,又能带来一定程度的去中心化。

可扩展性的解决方案

理想状态下,我们希望我们设计的区块链有着与比特币和以太坊相近或更好的安全性,但同时又不希望网络里每个节点都要处理超过一定比例的交易。换句话说,我们需要一种机制,来限制验证交易的节点数量(注:因为减少验证节点数量可以提高吞吐量),同时又保证网络里的每笔交易都是合法可信。这听起来很容易,但在技术上非常困难。

可扩展性是平台走向成功的一个巨大障碍。下面是一些不同开发团队正在努力研究的解决方案。

链下交易通道(off-chain payment channel)

该方案是在链下使用微支付通道网络处理大部分交易。区块链只作为清算层来处理一系列交易的最终清算,从而来减少底层区块链的负担。

这解决了我们前面讨论的吞吐量问题,区块链可处理交易的数量可提升一个量级。除此之外,由于交易都是在支付通道里处理的,无需等待区块确认,因此交易速度问题也得到了解决,消除了时延。

Raiden Network 和 Lightning Network 都是微支付通道网络的实例。

分片(Sharding)

分片的思想是把区块链的整体状态分割成不同的「片」,每部分状态都由不同的节点存储和处理。每个分片都只处理整体状态的一小部分,因此可以做到并行处理。区块链分片就像传统数据库的分片一样,但还需额外考虑如何在去中心化的节点集合里维持安全性和合法性。

链下计算(off-chain computation)

这个方案和状态通道很相似,但适用范围更广。其主要思想是以一种安全可证的方式,在链下处理一些在链上执行代价很高的计算。把计算和证明处理移到链下的独立协议里,可以提高交易吞吐量。一个实例是以太坊的 TrueBit。

DAG

DAG 是有向无环图(Directed Acyclic Graph)的缩写,这是一种有顶点和边的图结构。DAG 可以保证从一个顶点沿着若干边前进,最后不能回到原点。由此我们可以给顶点进行拓扑排序。

image

DAG

一些 DAG 协议,如 IOTA 的 Tangle,丢弃了全局的线性区块概念,使用 DAG 数据结构来维持系统状态。为了保证网络安全,这些协议需要用某种新方法,使节点不需要用线性方式处理每一笔交易。

另一种 DAG 协议 SPECTRE protocol,使用了区块的 DAG 技术,可以并行挖矿,从而带来更大的吞吐量和更快的交易确认时间。

DAG 技术还处在早期阶段。老实说,它们也存在一些需要被解决的底层限制和缺陷。

2

隐私保护的限制

区块链上的交易并没有直接关联到你的身份,这看起来似乎是可以具有隐私保护的。每个人都可以匿名地生成钱包,并进行交易。

然而,事实远没有这么简单。

区块链技术的巨大前景之一是假名(pseudonymity)的使用:交易被记录在公共账本里,但是它们又与由数字和字母组成的地址保持关联。因为无需将真实世界的身份信息关联到地址上,交易的发起者似乎是不可能被追踪的。

然而,这种想法是错误的。没有将假名关联到个人信息,这确实可以保护隐私。然而只要有人建立了链接,则隐私就不再是秘密。一个例子是执法机构坦言他们在调查时,可以识别比特币用户,对他们进行反匿名(deanonymizing)。

这是怎么发生的呢?

商业网站的 Web Tracker 和 cookies 会轻易泄露与交易相关的信息。任何人,包括政府、执法机构和恶意用户都可以利用这些信息。

此外,区块链平台(如以太坊)的用户与智能合约进行着复杂交互。智能合约的所有细节,包括发送者和接受者、交易数据、执行的代码和合约内部存储的状态,都是公开。

大部分公司都不会考虑把重要的商业数据上传区块链中,因为黑客、竞争者和其他非授权组织都可以轻易看到这些信息。思考一下:

  • 电子医疗记录是十分隐私和敏感的信息。

  • 身份识别数据如身份证不能在智能合约上公开。

  • 凭证管理如密码和密钥都不能放在公开和不安全的智能合约中。

  • 金融文件如股权结构表或员工薪资都不能公开。

  • 这样的例子不胜枚举

隐私保护对于个人、组织和企业来说,都是一个本质挑战。许多人为区块链和数字货币着迷,是因为这个去信任和抵抗审查的系统能带来金融上的变革。矛盾的是,我们在使用的是一个公开且容易被追踪的账本。

隐私保护解决方案

下面是一些不同开发团队正在努力实现的方案。

Elliptic Curve Diffie-Hellman-Merkle (ECDHM) addresses

理解 ECDHM 地址之前,你需要理解 Diffie-Hellman 密钥交换,其背后的思想在于双方之间建立一个共享的秘密。在公开网络里,这可以被用于交换秘密信息。

这是如何做到?

发送方和接收方共享 ECDHM 地址,然后通过共享的秘密将其转化成比特币地址。该比特币地址只会被拥有该秘密的人知道。唯一公开的东西只有可重复使用的 ECDHM 地址。因此,用户不用担心交易会被追踪。

image

Conceptual diagram that illustrates the general idea of the key exchange by using colors instead of very large numbers (Source: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

ECDHM 地址方案包括 Peter Todd 提出的 Stealth Addresses,Justus Ranvier 提出的 BIP47 Reusable Payment Codes 和 Justin Newton 提出的 BIP75 Out of Band Address Exchange。然而,没有一个方案得到实际应用。

混合器(Mixer)

混合器的思想是把交易混到一个池里,收支平衡由池中的私有账本来记录。当池中的资金被花费后,原始交易就变得难以追踪了。观察区块链的人可以看到池的支付金额和收款人,但是无法追踪交易的发起人。混合器服务的一个例子是 CoinJoin。

image

Source: https://en.wikipedia.org/wiki/CoinJoin

不幸的是,混合器不是一个可靠的解决方案。研究者可以确定 CoinJoin 里的交易,他们证明,攻击者只要花费 $32,000,就能以 90% 的成功率识别交易。并且,研究者还证明混合器几乎无法抵御女巫攻击(Sybil attacks)和拒绝服务攻击(Denial-of-Service attacks)。

另一个令人不安的地方是,需要通过一个相对中心化的实体来维护混合器的私有账本,这意味着需要一个可信第三方来“混合”交易。

CoinJoin 不是默认交易方法,因此很少人参与到进混合池里,这导致匿名集合十分小。在人数少的集合里,可以很容易确认交易的来源。

另一种混合器方案是 CoinShuffle,这是德国萨尔布吕肯大学研究团队设计的去中心化混合协议。CoinShuffle 尝试解决 CoinJoin 里需要可信第三方来混合交易的问题。

门罗币(Menoro)

不同于其他的山寨币,门罗币不是比特币的分叉,而是基于另一种协议 CryptoNote。门罗币的最大特色是环签名(Ring Signature)方案。

环签名是一种群签名,群里的每个签名者都拥有一对私公钥对。不像传统的加密签名证明交易是单个签名者用私钥签的,群签名证明交易是群里的某个人签名的,但不会暴露具体是谁签的。

零知识证明(Zero-knowledge proofs)

零知识证明是指,在不揭露特定知识的情况下,证明者(prover)可以说服验证者(verifier)他们知道该知识。换句话说,零知识的输入是秘密的,证明者不会向验证者揭露任何知识。零知识证明可以被用在隐私保护方案里。例子包括:

  • 例子1:质询/响应比赛

在计算机安全里,质询-响应认证(challenge-response authentication)是一个协议族。在协议里,一方进行提问(“质询“),另一方给出正确的答案(”响应”)以获得授权。在区块链里,这个“比赛”能被用于验证交易。如果某一交易是非法的,其他节点会注意到其非法性。这就需要提供可验证的证明(verifiable proof),来证实交易是非法的。如果验证失败,则会产生一个“质询”,要求交易的发起人生成一个“响应”,来证明交易是合法的。

这里有一个例子:假设只有 Bob 可以访问某些资源(如他的车)。Alice 现在也想访问它们(如开这辆车去杂货店)。Bob 发起一个质询,假设为“52w72y“。Alice 必须用一个字符串来响应 Bob 发起的质询。使用一个只有 Bob 和 Alice 知道的算法,这是找到答案的唯一方式。此外,Bob 每次发起的质询都会不一样。知道先前正确的响应,并不能给 Alice 带来任何的优势。

image

质询/响应比赛已经被使用在区块链,如以太坊里了。然而,我们需要相应的函数库和工具,来使这一类的认证方案更容易被使用。

  • 例子2:zkSNARKs

zkSNARKs 到底是什么?让我们来逐步分解其定义:

zk=zero-knowledge(零知识)。不需要信息本身的条件下,可以证明该信息存在。

  • SNARK:Succinct Non-interactive Adaptive ARgument of Knowledge

  • 简洁(Succinct)表示证明简洁,可以被快速验证。

  • 非交互(Non-interactive)表示验证者不需要和证明者进行交互。取而代之,证明者会预先公开它的证明,而验证者可以检查它的正确性。

  • 适应性知识论证(Adaptive argument of knowledge)表示某些计算的证明。

尽管我希望有一天可以写一篇文章介绍 zkSNARKs,但这里我会跳过技术细节。zkSNARKs是一个的构建隐私保护的组件,它令人振奋且具有远大前景,但有几点需要注意:

  • SNARKs 是资源密集型的

  • SNARKs 能让用户证明他们拥有访问某个秘密的权限。但用户有职责维护秘密,让它在需要的时候能被访问到。

  • SNARKs 需要一个启动阶段,来准备需要证明的电路或运算。该阶段由一组可信团体预先进行。这不仅意味着你需要信任进行该启动阶段的团体,还意味着不适合用 SNARKs 进行任意的运算,因为总需要一个准备阶段。

  • 例子3:zkSNARKs + Zcash

Zcash 是基于 zk-SNARKs,具有隐私保护特点的加密货币。在 Zcash 所谓的“私密交易(shielded transactions)”里,每一个被使用的币都带有一组匿名集合。私密交易使用“私密地址(shielded addresses)”,它要求发送方或接收方生成一个零知识证明,以在不泄露交易信息的情况下,允许其他人验证交易。

image

Zcash transaction diagram

Zcash 无疑是一个值得关注的有趣项目。

  • 例子4:zkSNARKs + Ethereum

在以太坊下一个要升级的协议 Metropolis 里,开发者将可以在链上高效地验证 zk-SNARKs。

我们可以在支持 SNARKs 的以太坊里做什么呢?可以把某些合约变量被设为不可见。秘密信息可以与那些遵守使用 SNARKs 的合约规则的用户存储在一起,而不是直接存储在链上。每一组用户群自身都需要一个可信的启动阶段,这会增加一些用于准备阶段的开销。但一旦电路被设置好,它就可以被任意数量的交易使用。

在支持 SNARKs 的以太坊里,你无法把隐私与用户分开,即做不到自治性隐私(autonomous privacy)。由于以太坊的 SNARKs 依赖用户在链下维护密钥,因此如果没有这些用户,就没有地方可以找到这些秘密。

  • 例子5:zkSTARKs

ZK-SNARKs 有一个更年轻更闪耀的同胞兄弟:ZK-STARKs,其中“T“表示”透明(transparent)“。ZK-STARKs 解决了 ZK-SNARKs 的一个主要缺陷:需要依赖一个可信的启动阶段。由于 ZK-STARKs 只依赖哈希和信息论,因此它更简易;由于不再使用椭圆曲线和指数假设,面对量子计算机时它更加安全。

总而言之,尽管在上述的零知识证明隐私保护方案的前沿研究中,我们取得了惊人的进步,但仍然有许多工作需要去做。我们需要对零知识证明的函数库进行实证研究和实践检测,使其成熟。我们需要在不同公链上对 zkSNARKs 和 zkSTARKs 进行实验。在真实世界的场景里,Zcash 则需要在扩展性上给出令人满意的使用案例。我们离这些仍有很长的路要走。

代码混淆(Code Obfuscation)

另一种隐私保护机制是代码混淆。该方案要找到一种方式来混淆程序 P,混淆器(obfuscator)会产生第二个程序 O(P)=Q,使得在给 P 和 Q 相同的输入时,产生相同的输出。但是 Q 不会揭露与 P 内部构造相关的任何信息。这使得我们可以在 Q 内部隐藏如密码和身份证等的私密信息,但同时在程序里使用这些信息。

虽然研究者已经证明完全的黑盒混淆器是不可能实现的,但不可区分混淆器(indistinguishability obfuscation)是可以实现的,这是一种概念上弱化的混淆器。不可区分混淆器 O 的定义是,如果你使用两个同等的程序 A 和 B(如把相同值输入到 A 或 B 里去产生相同的输入)计算得到 O(A)=P 和 O(B)=Q,则在无法进入程序 A 或 B 的情况下,则在计算上分辨 P 来自于 A 还是 B 是不可行的。

image

最近,研究者 Craig Gentry, Amit Sahai 等人完成了不可区分代码混淆器。然而,该算法的计算开销十分高昂。

如果开销问题可以得到改善,则能带来巨大的潜在好处。

举个例子,假设以太坊的智能合约里有  Coinbase 的密码。则我们可以写出这样一个程序:当智能合约满足了特定条件后,合约通过中间节点初始化与 Coinbase 的 HTTPS 会话,使用密码进行登录,然后执行交易。由于合约里的信息被混淆了,因此中间节点或区块链的其他参与者都没法修改发出的请求和获取用户密码。

预言机(Oracle)

在区块链世界里,预言机是指在智能合约和外部数据源之间传递消息的角色。它在链上智能合约和链下外部数据源之间充当数据的运输者。因此,一种保护信息隐私性的方法是使用预言机从外部数据源中取出隐私数据。

可信任执行环境(Trusted Execution Environments)

可信任执行环境(TEE)是位于主处理器里的一个安全区域。在 TEE 里加载运行的代码和数据会得到隐私性和完整性的保护。TEE 可以与面向用户的操作系统并行运行,但比后者具有更好的隐私性和安全性。

image

Source: https://www.slideshare.net/JavierGonzlez49/operating-system-support-for-runtime-security-with-a-trusted-execution-environment-phd-thesis

3

缺乏合约的形式化验证

智能合约的形式化验证仍然是一个未解决的巨大问题。首先,让我们通过“形式化证明(formal proof)”来理解“形式化验证(formally verify)”的意思。在数学上,“形式化证明”是一种数学证明,计算机可以通过基本的数学公里和推理规则(inference rules)来证明它。

在程序方面,形式化验证是一种判断程序是否能按预期运行的方法。具体的规约语言可以来描述输入和输出之间的函数关系。也就是说,如果声明了关于程序的一个不变式(invariant),则我们应该证明声明的确实是不变式。

规范语言的一个例子是 Isabelle,它是一种通用证明辅助,可以在形式化语言里表达数学公式,还提供了工具在逻辑运算上来证明这些公式。另一种规范语言是 Coq,这是一种用来书写数学定义、可执行算法和定理的形式语言。

对于编码在智能合约里的程序来说,为什么形式化验证十分重要?

一个原因是智能合约是不可逆的,这意味着一旦将它们部署到主网络里,你就无法升级或修改它们。因此在部署和使用智能合约之前,需要保证一切都不会出错。而且,智能合约是可公开访问的,存储在智能合约里的内容对任何人可见;每个人都可以调用智能合约里的公开方法。这带来了开放性和透明性,但也会吸引黑客攻击智能合约。

无论你多么小心谨慎,写出一个没有 bug 和完全可信的智能合约都是十分困难的。此外,在以太坊上,由于 EVM 指令的设计方式,验证 EVM 代码也很困难。因此在以太坊上很难找到一种形式化验证的解决方案。但无论如何,形式化验证都是一种减少 bug 和攻击的强有力手段。比起传统方法(如代码测试和同行审查),它在很大程度上可以保证正确性。我们急切地需要一种更好的解决方案。

4

存储限制

公有链上的大部分应用都需要解决存储问题(如用户身份、金融信息等)

然而,在公有链上存储信息意味着数据:

  • 被网络里的每一个全节点存储着

  • 被无限期存储着,因为区块链数据只增不减,且不可逆。

在去中心化网络里,每一个全节点会存储越来越多的数据,因此数据存储带来了巨大的开销。这将导致存储变成区块链应用的巨大瓶颈。

存储解决方案

下面介绍一些项目,它们使用不同的策略将数据分割成分片(shard),并以去中心化的方法将其存储在参与节点里。这些方法的基本前提是不让每个节点都存储所有数据,而是将数据分散后,存储在一个节点集合里。一些工程实例:

  • Swarm:Swarm 是以太坊上的 p2p 文件分享协议。你能将程序代码和数据存储在主链之外的 swarm 节点里,这些节点与以太坊主链会保持连接。你可以在链上交换这些数据。

  • Storj:文件和数据一开始会被分片和加密,然后被分散并存储到多个节点里,每个节点只存储数据的一小部分。这是一种“分布式存储”。Storj 代币(SCJX)被用来支付存储和激励存储文件和数据的节点。

  • IPFS:这是一种 p2p 超媒体(hypermedia)协议,它的特点是高吞吐量,基于内容寻址(content-addressed)的区块存储模型和超链接。本质上,它能以一种持久化和去中心化的方式存储文件,同时还有历史版本控制和减少相同文件副本的特点。

  • Decent:Decent 是一个去中心化的内容分享平台,允许用户在没有可信第三方时上传和分享它们的作品(如视频、音乐和电子书等)。存储内容的节点会被奖励手续费,用户可以跳过中介,经济实惠地接触到这些内容。

  • … 还有更多

5

难以证明的共识机制

区块链具有”去信任(trustless)“的特点。用户不需要信任任何人。无需信任带来了自治、抵抗审查、真实性和无需授权等一系列引人注目的性质。

这种用来保证区块链不易受攻击者破坏的机制,被称为“共识协议”。对于比特币和其他区块链来说,共识协议并不是一个新东西。

在 1992 年,Dwork 和 Naor 就创建了第一个“工作量证明(proof-of-work)“系统,用来在无需任何信任的情况下访问资源。这个系统被用来解决垃圾邮件问题。Adam Back 后来在 1997 年创建了名为 Hashcash 的相似系统。 在 2003 年,Vishnumurthy 等人首次采用 proof-of-work 来保护货币,但其代币不是作为通用货币来使用,而是用于维护点对点文件的交易系统。

5 年后,中本聪(Nakamoto)用 proof-of-work 机制发明了一种有价值的货币,即比特币。这种底层共识协议使得比特币成为第一个在全球使用的去中心化账本。

工作量证明(proof-of-work)共识

PoW 机制的思想是让问题很难解决,但验证很容易。矿工需要使用算力来进行巨大开销的计算,而比特币系统用比特币和交易费来奖励给出答案的矿工。矿工拥有的算力越多,则他们在共识上的“贡献”越大。

PoW 共识使得比特币成为第一个在全球使用的去中心化账本。它无需可信第三方就能解决“双花”问题。然而,PoW 不是完美的,仍然有许多人从事着研究和开发,试图去构建更可靠的共识算法。

PoW 存在什么问题呢?

  • 定制化硬件存在优势

PoW 的缺点是定制化硬件的使用。在 2013,一种名为专用集成电路(application-specific integrated circuits, ASICs)的设备被设计来专门挖比特币,可以将效率提高 10-50 倍。从那时起,使用普通计算机的 CPU 和 GPU 来挖矿便变得无利可图,挖矿的唯一方法是使用 ASIC 设备来挖。在区块链里,每个人都应该能为网络的安全做贡献,而 ASIC 的出现背离了“去中心化”的特点。

为了缓解这个问题,以太坊选用的 PoW 算法(Ethhash)是线性内存困难(sequentially memory-hard)的。算法被设计成需要大量的内存和带宽才能算出一个 nonce 值。即使是超高速计算机,也无法在需要大量的内存和带宽的条件下同时计算出多个 nonce 值。这减少了中心化的风险,为节点创建一个公平竞争的环境。

当然,这不表示未来不会出现针对以太坊的 ASIC。定制化硬件对 PoW 算法仍然存在着巨大的威胁

  • 矿池中心化

用户单独挖矿时,收到区块奖励的机会是很小的。取而代之,他们都为矿池挖矿。矿池按比例给矿工持续的回报。矿池算力在网络里占的权重大,大矿池所得回报的方差比单一矿工低得多。随着时间推移,少数矿池将控制大部分网络,而中心化的矿池控制的算力随着时间又进一步增加。现在,前 5 个矿池拥有接近 70% 的全网算力,这很吓人。

  • 浪费电力

矿工消耗大量电力来计算 PoW 问题,然而对于社会来说,这些计算都是无价值的。根据  Digiconomist’s Bitcoin Energy Consumption Index 所示,当前比特币每年消耗的电力约为 29.05TWh,大约占全球消耗电力的 0.13%,超过了 159 个国家。

使用 PoW 共识的公有链消耗的电费都会越来越多。不可持续的电力浪费和 PoW 计算开销不利于公有链将规模扩展到成千上万的用户和交易。

共识的解决方案

有意义的 PoW

一种解决电力浪费问题的方法是用 PoW 函数来解决某些有意义的问题。比如,让矿工用计算资源去解决困难的 AI 算法,而不是解决随机的 SHA256 问题。

Proof-of-stake

另一种解决挖矿中心化的问题是完全抛弃挖矿,在共识里引入另一种机制来每个节点的贡献。这就是 PoS 要做的事。

不像矿工使用算力,这里使用”权益(stake)“。如 Vitalik 所说,将“一单位算力一张票(one unit of CPU power, one vote)“变成“一块钱一张票(one currency unit, one vote)“。

PoS 消除了对硬件的需求,因此不再有硬件中心化的问题。而且,矿工再也不用消耗大量电力来解决 PoW 问题,PoS 本质上更节能。

然而,天下没有免费的午餐。PoS 算法也有自身的挑战,它们包括:

  • Nothing-at-Stake Problem:在 PoS 共识下,如果存在分叉(无论是因为意外或攻击),节点最好的策略都是同时“挖”每条链。节点不需要消耗计算资源,只需要使用自己的钱来投票。这意味着无论哪条链胜出,矿工都会得到奖励。

  • Long-range attacks:如果矿工想在 PoW 链里分叉,它得在主链最新区块前几个区块开始挖。矿工往回得越多,就越难追上主链,这需要超过网络一半的算力才能做到。然而,在 PoS 里,由于挖矿所需的东西只是权益,即钱,矿工可以从成千上万个块之前开始分叉。矿工可以轻易生成成千上万的区块,而用户很难发现哪一条链才是“正确”的链。

  • Cartel formation:在由经济激励治理的去中心化系统里,一个真实存在的风险是共同合作(coordinated efforts)和寡头的出现。就如以太坊研究者 Vlad Zamfir 所说,“数字货币都很集中,挖矿的算力也是这样。在”真实世界“的市场中,寡头竞争是常态。比起大量相对贫穷的验证者,少数相对富有的验证者之间的合作十分容易。卡特尔(Cartel)的出现是完全可以预期到的。”

为了可以有效地替代 PoW,我们需要一种算法来解决 nothing-at-stake 问题和 long-range attake 问题,同时不引入新的共谋风险。

一些团队,如 Tendermint 和以太坊,在解决这个问题上已经取得了许多进展。Tendermint 是通过设计 PoS 共识引擎将传统的 BFT 算法应用到区块链里。然而,Tendermint 也有自身的缺陷。统一,以太坊也在 PoS 的实现上取得了很大的进展,但是在网络里仍没有运行。

不像 PoW,PoS 未经检验且难以理解。为了理解各类设计里的不同权衡,需要进一步的研究和实验。正因如此,我们应该在前人的工作之上共同合作,研究出一个更有效、更快和更安全的共识系统。

6

缺乏治理和标准

在去中心化的公有链,不存在中央集权和组织来做决策,这是毋庸置疑的。在另一方面,每个人都是管理者——这是一个完全去信任、开发且无需授权的系统——然而在另一方面,又不存在能够安全升级协议的方法,没有人负责维护协议标准。

在维持区块链技术的去中心化的同时,我们仍然需要一个由生态里开发者和其他成员组成的组织,来对新标准、特性和升级达成共识。如何在没有中心化组织(如以太坊基金会)的带领下实现这个目标,仍然是个未知数。

例如,以太坊当前的特定标准和特性只由一两个开发者来指导和决策。尽管这个模式可行,但仍存有缺陷。其中之一是不够效率——如果领头开发者太忙,或几天几周内忘记回应,则标准的推进就会陷入停滞,不管这个标准对其他参与构建区块链的人来说是多么重要。在没有明确领导下制定标准,将带来混乱,很难快速即使地对问题达成共识。在社区越大时,这种情况越严重。

另一种方法是完全开放和去中心化区块链。然而,这会使得自治十分低效,将带来长久的危害。

我们需要一种更好的方法。

Tezos 试图通过链上治理(on-chain governance)让区块链拥有升级协议的能力,但这仍是构想,还未被实现,也未被证明合理。

总之,治理区块链是一个棘手的问题。在治理控制权的集中和分布之间做好权衡,这是维持发展的关键所在。

7

缺乏开发工具

制造充足的开发工具,这实际上是开发者的职责,尤其是对于想高效完成工作的开发者来说。

在当前区块链生态系统里,开发工具显然无法让人满意。即使是经验丰富的开发者,在区块链之上开发功能性协议或去中心化应用也是一项艰巨的任务。

我从一个 Solidity 和区块链开发人员的角度,列举了一些生态里缺乏的工具:

  • 能够检查代码错误,且集成开发智能合约和区块链分析所需插件的 IDE。

  • 有完整文档,且容易使用的构建工具和编译器。

  • 持续更新的 API 和框架技术文档。

  • 测试框架。以太坊里有一些可用的测试框架,如 Truffle,但我们急需能提供更多选项和实验的测试框架。我看到过许多智能合约未经过测试,却存着数以万计的美元。在任何情况下,缺乏测试都不是一个可以令人接受的选择,尤其是与大额资金相关时。举例来说,BAT 的代币销售合约里就没有测试套件,但它却在 24 秒内募集了 3600 万美元。任何理性的人都明白,如果合约可以移动那么多钱,那它很可能会遭受攻击。

  • 调试工具。调试 Solidity 代码就像在黑暗隧道里蒙着眼睛寻找金子。在开发网站时,我可以使用调试器一行一行单步调试代码。但是 Solidity 开发环境里没有类似的工具,这令人沮丧。我们急需一种可以隔离和诊断问题的易用工具。

  • 日志工具。与上述相同。

8

量子计算机的威胁

量子计算机是密码学和加密货币的潜在威胁之一。

尽管量子计算机目前只能解决特定类型的问题,但这种情况不会一直持续。量子计算机可以有效地攻破当前流行的公钥算法,这听起来很可怕,但事实如此。

在设计区块链和底层的加密算法时,我们应该考虑怎么使它拥有抗量子的特性,这是很重要的。

抗量子解决方案

在我有限的认知里,后量子算法的研究有六个不同的方向: Lattice-based cryptography, Multivariate cryptography, Hash-based cryptography, Code-based cryptography, Supersingular elliptic curve isogeny cryptography, 和 Symmetric key quantum resistance systems(如 AES 和 SNOW 3G)。

不管最终方案是什么,探寻一种抗量子的密码解决方案都是我们首要关注的重点。

9

其他挑战

我们需要一种跨链通信的解决方案,使得我们能在不同链(如比特币、以太坊和莱特币等)之间无缝进行通信和转账。

我们需要打造一套更好的密钥管理系统,让应用程序基于之上运行。

我们需要更高效的签名方案和密码系统,使得它们可以在低运算资源的设备上运行,同时又保证安全性。

还有…

10

总  结

I-C-O 吸引了太多的注意力和资金。与此同时,一些全身心投入解决这些问题的研究者和开发人员却得不到足够的支持。这不是一件好事。

更令人遗憾的是,许多人,包括一些领域内有影响力的开发人员和领袖在内,都因为金钱而选择忽略这些问题。

在接下来一年里,我的目标会:

  • 持续关注这些问题

  • 投入时间去思考解决方案

  • 鼓励其他研究者和开发者做同样的工作

不管当前的投资环境是否存在泡沫,我都是区块链坚定的信仰者。作为开发者,我们有义务投入精力去解决这些问题,将区块链带向主流人群。同时我们也需要投资者,来挖掘和支持这些工作。

(内容来源:知乎-趁风卷。文章首发:每日币吹 
 本文是 Fundamental challenges with public blockchains 的非完全翻译。
原文作者 Preethi Kasireddy 是 Coinbase 的前员工,她写的技术文章非常适合新手阅读。)

以下是我们的社区介绍,欢迎各种合作、交流、学习:)

image

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: Spark Streaming 和 Flink 都是流处理框架,但在一些方面有所不同。 1. 数据处理模型 Spark Streaming 基于批处理模型,将流数据分成一批批进行处理。而 Flink 则是基于流处理模型,可以实时处理数据流。 2. 窗口处理 Spark Streaming 的窗口处理是基于时间的,即将一段时间内的数据作为一个窗口进行处理。而 Flink 的窗口处理可以基于时间和数据量,可以更加灵活地进行窗口处理。 3. 状态管理 Spark Streaming 的状态管理是基于 RDD 的,需要将状态存储在内存中。而 Flink 的状态管理是基于内存和磁盘的,可以更加灵活地管理状态。 4. 容错性 Flink 的容错性比 Spark Streaming 更加强大,可以在节点故障时快速恢复,而 Spark Streaming 则需要重新计算整个批次的数据。 总的来说,Flink 在流处理方面更加强大和灵活,而 Spark Streaming 则更适合批处理和数据仓库等场景。 ### 回答2: Spark Streaming 和 Flink 都是流处理框架,它们都支持低延迟的流处理和高吞吐量的批处理。但是,它们在处理数据流的方式和性能上有许多不同之处。下面是它们的详细比较: 1. 处理模型 Spark Streaming 采用离散化流处理模型(DPM),将长周期的数据流划分为离散化的小批量,每个批次的数据被存储在 RDD 中进行处理,因此 Spark Streaming 具有较好的容错性和可靠性。而 Flink 采用连续流处理模型(CPM),能够在其流处理过程中进行事件时间处理和状态管理,因此 Flink 更适合处理需要精确时间戳和状态管理的应用场景。 2. 数据延迟 Spark Streaming 在处理数据流时会有一定的延迟,主要是由于对数据进行缓存和离散化处理的原因。而 Flink 的数据延迟比 Spark Streaming 更低,因为 Flink 的数据处理和计算过程是实时进行的,不需要缓存和离散化处理。 3. 机器资源和负载均衡 Spark Streaming 采用了 Spark 的机器资源调度和负载均衡机制,它们之间具有相同的容错和资源管理特性。而 Flink 使用 Yarn 和 Mesos 等分布式计算框架进行机器资源调度和负载均衡,因此 Flink 在大规模集群上的性能表现更好。 4. 数据窗口处理 Spark Streaming 提供了滑动、翻转和窗口操作等灵活的数据窗口处理功能,可以使用户更好地控制数据处理的逻辑。而 Flink 也提供了滚动窗口和滑动窗口处理功能,但相对于 Spark Streaming 更加灵活,可以在事件时间和处理时间上进行窗口处理,并且支持增量聚合和全量聚合两种方式。 5. 集成生态系统 Spark Streaming 作为 Apache Spark 的一部分,可以充分利用 Spark 的分布式计算和批处理生态系统,并且支持许多不同类型的数据源,包括Kafka、Flume和HDFS等。而 Flink 提供了完整的流处理生态系统,包括流SQL查询、流机器学习和流图形处理等功能,能够灵活地适应不同的业务场景。 总之,Spark Streaming 和 Flink 都是出色的流处理框架,在不同的场景下都能够发挥出很好的性能。选择哪种框架取决于实际需求和业务场景。 ### 回答3: Spark Streaming和Flink都是流处理引擎,但它们的设计和实现方式有所不同。在下面的对比中,我们将比较这两种流处理引擎的主要特点和差异。 1. 处理模型 Spark Streaming采用离散流处理模型,即将数据按时间间隔分割成一批一批数据进行处理。这种方式可以使得Spark Streaming具有高吞吐量和低延迟,但也会导致数据处理的粒度比较粗,难以应对大量实时事件的高吞吐量。 相比之下,Flink采用连续流处理模型,即数据的处理是连续的、实时的。与Spark Streaming不同,Flink的流处理引擎能够应对各种不同的实时场景。Flink的实时流处理能力更强,因此在某些特定的场景下,它的性能可能比Spark Streaming更好。 2. 窗口计算 Spark Streaming内置了许多的窗口计算支持,如滑动窗口、滚动窗口,但支持的窗口计算的灵活性较低,只适合于一些简单的窗口计算。而Flink的窗口计算支持非常灵活,可以支持任意窗口大小或滑动跨度。 3. 数据库支持 在处理大数据时,存储和读取数据是非常重要的。Spark Streaming通常使用HDFS作为其数据存储底层的系统。而Flink支持许多不同的数据存储形式,包括HDFS,以及许多其他开源和商业的数据存储,如Kafka、Cassandra和Elasticsearch等。 4. 处理性能 Spark Streaming的性能比Flink慢一些,尤其是在特定的情况下,例如在处理高吞吐量的数据时,在某些情况下可能受制于分批处理的架构。Flink通过其流处理模型和不同的调度器和优化器来支持更高效的实时数据处理。 5. 生态系统 Spark有着庞大的生态系统,具有成熟的ML库、图处理库、SQL框架等等。而Flink的生态系统相对较小,但它正在不断地发展壮大。 6. 规模性 Spark Streaming适用于规模小且不太复杂的项目。而Flink可扩展性更好,适用于更大、更复杂的项目。Flink也可以处理无限制的数据流。 综上所述,Spark Streaming和Flink都是流处理引擎,它们有各自的优缺点。在选择使用哪一个流处理引擎时,需要根据实际业务场景和需求进行选择。如果你的业务场景较为复杂,需要处理海量数据并且需要比较灵活的窗口计算支持,那么Flink可能是更好的选择;如果你只需要简单的流处理和一些通用的窗口计算,Spark Streaming是更为简单的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值