区块链的可拓展性研究【03】扩容整理
为什么扩容:在layer1上,交易速度慢,燃料价格高
 扩容的目的:在保证去中心化和安全性的前提下,提升交易速度,更快确定交易,提升交易吞吐量(提升每秒交易量)
 目前方案有:
 on-chain链上扩容
 更改现有区块链结构
 off-chain链下扩容
 不更改layer1区块链结构
on-chain链上扩容,对区块链本身性能进行提升
 一层解决方案:
 1·更改共识机制:PoW->PoS
 2·分片:横向分割数据库
 3·扩大区块规模
可能会导致硬分叉
off-chain链下扩容:无需更改现有以太坊协议
 1·侧链 Side chains
 定义:独立的区块链,与以太坊并行独立运行,不会将状态更改和交易数据发布回以太坊主网;牺牲安全性和去中心化换取高吞吐量
 方法:双向锚定的跨链桥
 
 主链资产锁定,侧链铸造相同的资产
 侧链种类
 1·单一托管模式 Centralized (basic third partyauthority)
 
 存在交易所,过于中心化
 2·联盟模式 Federation - multisig federation中心化
 
 公证人多签
 3·简单支付验证 SPV(simple payment verification)去中心化
 
 (不重要)驱动链模式 Drivechain
 (不太重要)混合模式驱动链 +公证人/侧链
侧链安全性自身协议保证
项目:Polygon POS,Polygon POS,Gnosis Chain, Skale, Palm.Ronin,分片链(ETH 2.0)
优点
 兼容性高,支持智能合约
 性能高,TPS高
 低费用
 用于探索和测试
 缺点
 安全性不受保障
 去中心化程度低
 隐私性较弱
 侧链上的交易公开可见
 2·二层解决方案Layer2(直接从第一层以太坊共识中获得安全性,二层执行交易,数据/结果锚定会主链)
 1·Channel
 特点:
 更注重安全性,而非可用性
 通道采用多签合约,使参与者能够在链下快速自由地进行交易,然后再与主网结算
 数据可用性:所有的数据存在Layer2,由Channel双方保证DA状态
 有效性**:挑战期(参与者质押)、(参与者内部) 欺诈证明 Fraud Proof**
 通过质疑者质疑扣除质押
 a1.支付通道 Payment Channel
 a2.状态通道State Channel
 优点
 适合高频、小额支付
 交易成本低
 状态有效性高
 隐私性强
 具有即时的最终确定性
 缺点
 提币慢
 不适用于偶尔转账给对方的用户
 不支持开放参与
 TPS一般
 不支持智能合约
 所有者需100%在线
 不能用于表示没有明确逻辑所有者的对象
 通道上的交易公开可见
 2·Plasma:解决了将资产可以发送给任意目标人
 因为通道无法支撑大规模,大资金和复杂交易的局限性
 特点:
 解决了channel的局限性(结合了侧链的设计:解决了将资产发送给任意目标人的问题,同时也能够确保TPS的提升)
 Plasma 链是独立的区块链,但它们锚定在以太坊主网上 (安全性)。也可以称为子链,因为它们是以太坊主网的较小副本
 不支持智能合约,仅支持基本的代币转移、交换和其他一些交易类型
 可以无限创建“链中链”
 
 运营商提供周期性的“状态承诺”
  也是merkle树保证,但是只用提交状态根
也是merkle树保证,但是只用提交状态根
  1任何一个状态的变化都会导致Root hash发生变化
1任何一个状态的变化都会导致Root hash发生变化
 2如果两棵树的根哈希值相同,那说明他们的叶子结点存储的信息完全一致了
 3可以确认某一个状态信息存在于某个哈希树中
如果发现和自己交易的merkle树根不一样,就可以提交欺诈证明,扣除欺诈人的押金
观察期:用户需要每隔一段时间记录一次等离子链,作为验证者,提交欺诈证明,哪怕就只有一个诚实节点,就可以提交欺诈证明,维护安全
 数据不可用,如果运营商作恶,就没有办法,因为他可以不公开交易
 大规模退出方案,发现作恶,自动提款
 项目:matic
 优点
 吞吐量高
 交易成本低
 适用于任意用户之间的交易
 不需要提前锁定资金
 安全性高
 缺点
 无法运行智能合约
 固定提交周期
 提款慢(观察区,欺诈证明导致)
 需要定期观察网络
 依靠一个或多个运营商来存储数据并根据要求提供服
 大规模退出问题
3·rollup
 Plasma运营商负责发布交易的状态根,他可能作恶,不上传所有交易,运行商数据有效性,权力过大
Roll-Up(在第一层之外执行任务,并在达成共识时,在第一层公开数据。 由于交易数据包含在第一层区块中,因此可以通过原生的以太坊安全性来保证卷叠的安全性)
和plasma相同:主链之外执行交易,将交易成批处理,最后将状态发回主网
 和plasma不同:将交易数据提交给主链
 和plasma不同:最大限度压缩交易数据,同时基于自身的特性适当删除和缩减部分数据
 State Root状态根(默克尔树 Merkle Tree概念)
 Batch批次
 
压缩
 
 种类
 Optimistic Roll-Up乐观卷叠
 假设所有交易都是有效的,并在没有任何初始证明的情况下提交批次
 欺诈证明:任何人可以在挑战期内,检测并证明有数据是虚假的

 项目
  优点
优点
 高吞吐量
 低交易成本
 安全性高,依赖于主网的安全性和共识
 保证了去信任的最终性,
 状态的有效保证了数据的可用性
 EVM的兼容性(solidity)
 缺点
 提款慢
 安全模型依赖于至少一个诚实节点
 必须在链上发布交易数据,也需成本
Zero Knowledge Roll-Up零知识证明卷叠
 零知识证明 (ZKP):证明者能够在不向验证者提供任何有用的信息的情况下,使验证者相信某个论断是正确的
 与OP Rollup相同: Rollup也是将交易捆绑成批次,链下执行,一同上链
 与Optimistic Rollup不同: ZK Rollup 提交者多提交一个“有效性证明
 证明可以在提交batch几分钟后完成
 省略掉了验证者保存数据,在挑战期提交欺诈证明的环节
 也不再需要在提交后再等待7-14天来做验证
  智能合约进行验证(但是证明过程不兼容evm)
智能合约进行验证(但是证明过程不兼容evm)
压缩
 1,生成的证明体积远远小于证明内容的体积(因此比op 上传到主网的字节要小很多)
 2,如果事务的一部分仅用于验证,并且与状态更新无关,那么该部分可以下链,从而减少字节。但这不能在optimistic roll-up中完成因为该数据仍然需要包含在链上,以防以后需要在欺诈证明中进行检查(比较zk不需要挑战期和欺诈证明)
生成、验证一个zk证明需要非常非常大量且复杂的计算,因此研发进度和实际应用非常慢
 EVM不兼容
 
 zk-SNARK (Succinct Non-Interactive Argument ofKnowledge)简洁非交互式知识论证
 ZK-STARK(Scalable Transparent Argument ofKnowledge) 可扩展的透明知识论证
  优点
优点
 正确性高
 交易快
 数据可用性依赖代码和密码学而非经济激励机制
 安全性高
 效率优化度高(目前最高)
 交易费用低
 缺点
 开发速度慢
 应用不广泛
 EVM不兼容
 硬件方面的中心化风险
Validium
 类似于ZK rollup (零知识证明) ,不同之处在于数据被保存在链下
 吞吐量不受以太坊数据处理能力的限制、提高扩展性、交易速度、降低用户费用
 存款和取款类似rollup
  纯链下:运营商无需发布交易数据
纯链下:运营商无需发布交易数据
 数据可用性问题:运营商作恶,隐藏链下数据而用户无法过的具体交易数据,用户就没有办法计算merkle证明
 因为是提交有效性证明进行提款,所以运行商作恶,用户无法得到hsah root,就无法提款
而Plasma中,运营商作恶可以盗取用户资金,因为使用的是欺诈证明,用户又无法证明自己欺诈了,因为运行商不给所有正确的交易数据
 
 链下数据可用性管理方法:
 1)数据可用性委宏会数据可用性委员会
 指定一组受信任的实体(统称为数据可用性委员会)来存储链下数据副本
 紧急情况下将链下数据副本变为公开可访问
 用户可以无需通过运营商,直接调用主合约的提款功能,将他们的资金提回。
 +ve: 容易实施并且只需较少的协调
 -ve:集中化风险
 2)绑定数据可用性
 通过经济激励机制和去中心化的形式来保证链下数据的可用性
 质押代币、分配存储链下数据
 扩大人数,减少集中性风险,更去中心化
 项目
 

 优点
 有效性证明防止运营商作恶
 交易速度快
 适用于特定用例 (eg 隐私交易、可扩展应用)
 高吞吐量
 交易费用低
 可扩展性
 缺点
 开发速度慢
 应用不广泛
 EVM不兼容
 硬件方面的中心化风险
 安全性低(赖于信任假设和加密经济激励)
 链下数据可用性问题: (运营商作恶),用户可能无法从链上合约中提取资金
总结
 1.各方案对比,rollup有效地保证了状态有效性+数据可用性,保留了先前方案的优势,同时解决了他们的局限性。从而成为目前扩容领域的的龙头。
2.在roll-up方案中,短期optimistic roll-up;长期ZK roll-up
 
 https://www.youtube.com/watch?v=I598C9GFDvk
 说明:
 笔记总结为了方便学习
 对作者RJ小姐姐Twitter: https://twitter.com/0xRJ_eth表示感谢🙏.
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!