江苏龙网

  1. 首页 > 人文 > >

InfoQ以太坊都这么堵了，Eth 2.0 在干嘛呢？( 三 )


执行时应启用多少个分片？
对于其他分片 ， 是否应该选择 EVM 或 eWASM 作为虚拟机方案？
我们该如何有效组织并处理跨分片交易？
我们需要对现有 EVM 者哪些变更 ， 以使其支持跨分片交易？
执行与账户结构能否 / 应否具备通行的可扩展能力？
eWASM（EF）与 Quilt（ConsenSys）团队正在这些领域投入大量研究资源 。 事实证明 ， 可行的解决方案多种多样 ， 而目前的头号难题就是挖掘出更简单、更务实的解决办法 ， 以便快速进行测试、建立设计原型并有针对性地做出讨论 。 eWASM 的 Eth1 x64 项目也正是由此诞生 。
将抽象的跨分片思维引入具体规范、据此展开讨论并构建设计方案的实践方法 ， 帮助团队在探索中取得了快速进步 。 DApp 开发人员在接下来的几个月中需要密切关注这方面动向 。
无状态以太坊与 Eth 2.0 的关系
与 Eth 2.0 并行推进的另一项重大研究工作是“无状态以太坊” 。
无状态以太坊的核心是解决状态规模持续增长的难题 。 在它的帮助下 ， 参与者既能够完成区块验证 ， 又无需在本地存储完整区块链状态 。 如今 ， 以太坊状态转换函数中新增一项隐式输入：整体状态 。 使用无状态以太坊后 ， 区块内部将包含必要的状态证明（见证） ， 借此保证区块可以作为纯函数进行转换 / 验证 。
对用户来说 ， 这意味着以太坊将成为一个环环相扣但又互不影响的世界 ， 我们只需要关注其中需要关注的一部分状态 。 某些网络参与者可能会存储所有状态（例如区块生成器、区块资源管理器、按需收费的状态提供程序等） ， 但绝大多数参与者只需要掌握整体状态中的一部分 。
对于 Eth 2.0 ， 这将是一项重要的技术机制 ， 能够保证节点与验证器成功验证并保护整体协议 ， 同时无需在每个分片上存储完整的用户状态 。 相反 ， 验证器可能选择接入某些分片的区块生成器 ， 而基准验证器可能单纯验证无状态区块 。 无状态以太坊将成为 Eth 2.0 发展愿景中的重要补充 ， 负责保证该分片协议的轻量化优势 。
当然 ， 如果事实证明无状态发展路线最终不具备可行性 ， 团队也准备了其他一些替代性选项 。
Eth 2.0 的挑战
Eth 2.0 目前工作中 ， 遇到的挑战主要是要引入过多的验证器、分片和客户端 。
分片机制的关键在于共识参与者（即验证器）必须以随机抽样的形式加入委员会 ， 并对协议中的特定部分（例如分片）进行验证 。 如果特定协议中包含足够的验证器 ， 那么即使攻击者控制的参与者数量达到最高（例如全部验证器中的 1/3） ， 后者在数学意义上仍然不可能控制委员会并破坏整套系统（成功的几率一般在 1 / 2^40 左右） 。 为了达成这个目标 ， 团队需要对系统进行设计 ， 保证用户能够使用消费级计算设备（例如笔记本电脑甚至是旧手机）充当验证器（各验证器将被分配给系统中的各个子部分 ， 并单一设备的计算资源足以完成对该子部分的验证） 。
正是这样的设计思路 ， 让分片机制既功能强大又难于实现 。 首先 ， 我们必须拥有充足的验证器以保证随机抽样不受恶意人士控制 。 换句话说 ， eth2 天然要比大部分其他权益证明协议具有更多的潜在验证器 ， 而这将在流程中的各个阶段给系统带来挑战——包括共识机制的研究与规范制定、网络、资源消耗以及客户端优化等等 。 每新增一个验证器 ， 都会在系统的各个步骤中带来系统负载 ， 这些影响因素显然需要得到重视 。
除了验证器过多 ， 另一项基本决策同样提升了构建难度 。 在以太坊中 ， 团队希望在增强可扩展性的同时 ， 尽可能降低对去中心化原则的影响 。 基于这个理念 ， 团队必须要建立起分片共识机制并借此将系统拆分为一个个体量较小的可验证区块 。 设计并实施这样的共识机制将极为困难 。
强调自身的协议属性是以太坊核心宗旨之一 。 以太坊代表着组成协议的抽象规则集 ， 而非这些规则集的任何特定实现 。 为此 ， 以太坊社区在建立之初就鼓励用户们开发出各类客户端实现方案 。


推荐阅读


上一篇：36氪消息称网易丁磊将在快手直播带货，此前与抖音也有接触

下一篇：北京日报客户端一颗足球场大的小行星以每小时20000英里的时速和地球擦肩而过