概述 | 实现 dApp 扩展的五大解决方案 (文末附V神等大咖 EDCON 演讲 PPT 资料包)
编译 | Jhonny & Iris
扩展性解决方案的实现已经到来!本文将探索一些当前已经可以实现的扩展性解决方案,不同方案的相对权衡折衷之处,同时分享一些可用于开发使用的开发者资源。
背景:扩展性问题
“为何扩展性很难实现?我经常谈论有关‘扩展性的三难困境’(scalability trilemma),即区块链系统必须在不同的特性之间进行权衡。它们很难同时都具备三个特性,其中之一就是去中心化,另一个就是扩展性,第三个就是安全性。"
-- Vitalik Buterin,2017年11月
诸如比特币 (Bitcoin) 和 以太坊 (Ethereum) 等无需许可的公链平台已经在第一层 (Layer 1) 选择了优化安全性和去中心化程度,而不是高交易吞吐量。任何想要成为验证者 (validator) 的人都可以参与,且成为验证者要求只需要相当少的时间和资金投入。
在 PoW 机制中参与挖矿的节点保护整个区块链网络免受 51% 攻击 (按照2019年4月份的价格计算,这种攻击在以太坊区块链和比特币区块链上的攻击成本分别为每小时约10万美元和超过35万美元)。
以太坊的真正无需许可的去中心化属性和高安全性使其成为全球经济信任层的首选平台,并确保了该平台上的区块链应用程序的安全。
然而,安全性和去中心化是以扩展性为代价的。当前以太坊每秒处理的交易量约为5笔,并且如果每秒处理的交易量为6笔就会出现超负荷问题,且理论上每秒处理的简单交易的限制为14-15笔。对于任何主流的现存消费者或金融应用来说,这个数字都是九牛一毛的。
“其核心限制是,像以太坊这样的公共区块链要求网络中的每个节点都要处理每一笔交易。”
--Josh Stark,2018年2月
在以太坊2.0阶段,以太坊基金会 (EF) 有着一个升级以太坊区块链基础设施的先进路线图,将在接下来的几年中大大地改善以太坊的扩展性。
但是,很多项目当前就在以太坊平台上搭建应用程序,这些程序现在就需要实现扩展!此外,基于这些应用的实际用例,即便 Serenity (Eth 2.0) 已经实现,那你可能也不希望所有的交易都运行在以太坊主网 (即第一层) 之上,而是选择第二层解决方案。
当前的主要挑战
缓慢 -- 交易吞吐量低,满块 (full block) 情况下的网络延迟依赖性;
昂贵 -- 用户必须为每笔交易支付 gas 费用
用户体验不佳 -- 用户必须为每笔交易进行签名并等待交易被确认,之后下一笔交易才能被执行。
扩展性方案
当前可以实现的用于扩展交易吞吐量的扩展性方案,当然还存在其他一些包含链下计算和其他扩展向量的解决方案,但本文将主要探讨以下扩展性方案:
链下消息签名 (元交易) -- 使用以太坊密钥对 (key pairs) 在链下对消息进行签名,存储并发出事件,或将事件传递给 P2P,然后根据这些消息上的内容和签名更新链上的状态;
支付通道 -- 交易双方之间实现价值交换的链下通道,并在链上对交易;
状态通道 -- 实现交易双方之间多次更新状态的链下通道,并在链上对这笔交易进行最终的状态更新;
侧链 x 桥接 (bridges) -- 功能齐全的侧链通过桥接只能合约和中继机制来锚定以太坊主网;
Plasma 链 -- 功能齐全的子链 (child chain) 会定期地将其状态树 (state tree) 提交至根链 (即以太坊主网) 之上。
扩展性方案的折衷之处
(点击图片可放大)
扩展性方案的描述 & 实现
下方的扩展性方案都是开源的,可用于开发者搭建应用程序,尽管所有的扩展性方案都处于发展中,并且在将应用部署到主网之间,强烈建议进行安全审计 (下方涉及到实现扩展性方案的项目,不包括尚未发布可用产品或者代币库的项目)。
01. 消息签名
用户通过密钥对 (公钥 + 私钥) 使用 keccak256 哈希算法,在链下对消息进行签名;
消息可以存储在 IPFS (星际文件系统) 或者 DB (数据库) 中,之后分批处理成一笔链上交易;
消息也可以通过 P2P 传递,并且一旦消息 (通过公钥) 被验证为来源于有效或者授权的一方,则该消息就可以被作为 oracle 输入到主网的智能合约中;
之后智能合约就会接收并执行该信息;
在 ETH Berlin 会议期间,MakerDAO 就使用消息签名的方法,提议了一个链下价格预测的解决方案。
相关资源:
Karl Floersch -- 哈希算法和消息签名基础知识:
https://cryptoeconomics.study/
Mario Conti -- 通过链下签名消息进行价格预测 (price oracle):
https://view.ly/v/Rt275OYzLCI1
Vitalik Buterin -- 预言机:
https://blog.ethereum.org/2014/07/22/ethereum-and-oracles/
02. 支付通道 & 状态通道
状态通道 (state channels) 包含三个主要步骤:
中国观察