技术指南 | 理解零知识证明算法之Zk-stark

Concept:zk-stark vs zk-snark

谈到ZKP算法,大伙可能听过一些,比如zk-snark,zk-stark, bulletproof, aztec, plonk等等。今天,咱就给大伙聊聊这一对“表面兄弟”,zk-stark和zk-snark算法的异同之处。

不如,先让我们从名称说起? 毕竟,两个看起来都很厉害的亚子^_^ !

如下图所示,我们将名称zk-stark 和 zk-snark根据功能特点分别分成四个部分,然后逐个比较分析。

技术指南 | 理解零知识证明算法之Zk-stark

Zk-stark => zk – s t ark

  • zk:零知识,表明隐私的输入将会被隐藏,除了证明者,其他任何人不会看见;
  • s:可扩展的,和Replay Computation的验证耗时相比,zk-stark的证明和验证耗时分别与之呈拟线性关系和对数关系;
  • t:透明的,zk-stark算法没有CRS setup by Trusted party;
  • arg:知识论证,只有知道private input的prover,才能生成有效的proof;

Zk-snark => zk – s n ark

  • zk:零知识,表明隐私的输入将会被隐藏,除了证明者,其他任何人不会看见;
  • s:简洁的,指的是生成的proof足够小和验证时间足够短;
  • n:非交互式的,Prover生成证明的过程中和verifier没有交互;
  • arg:知识论证,只有知道private input的prover,才能生成有效的proof;

Compare

  • 相同点
  1. 都实现了将隐私的输入可靠隐藏;
  2. 都是基于知识论证,不知道private input的prover生成不了有效的proof;
  3. 都可以实现交互式与非交互式式的算法,只是取决于randomness是由谁来生成的;
  • 不同点
  1. zk-stark具有可扩展性,即证明和验证的耗时与原始计算的耗时分别呈拟线性关系(且线性因子为常量)和对数关系,这意味这,如果原始输入的数据集增大1000000倍,zk-stark的证明耗时增加线性倍数的时间,但验证时间仅仅增加21*log1000000 =~ 420倍。证明耗时呈线性关系基本满足所有的ZKP算法,但是验证时间呈对数关系,仅此一家,因此在扩展性上,zk-stark要胜一筹。
  2. zk-stark同样具有简洁性,但是是验证简洁性。所谓简洁性,通常是指即使验证程序很大,生成的proof size也不会很大,同时又能很快的完成验证(比native computation快很多)。相比对zk-snark,zk-stark的proof size要大的多,因此在简洁性上,zk-snark要胜一筹。

ALG compare

前面从概念上对zk-stark 和 zk-snark算法做了比较,其异同点可以笼统的概括为:

  • 都是基于知识论证的ZKP算法;
  • zk-stark不需要zk-snark的Trusted party 设置CRS,因此是Transparent;
  • zk-stark的验证耗时与native computation 耗时呈对数关系,因此是Scalable;

下面,我们将从算法层面,去做相对更深入一些的比较分析:

  • zk-snark ALG 【4】
  1. 算法思想:将证明CI statement成立问题转换成证明多项式等式成立问题,转换过程用到了算术环路和QAP方法;
  2. 多项式等式成立意味着什么?(图中黄色部分)
    1. 等式两边可以看作两个度相等的多项式,假设为n,其交点最多有n个,假如在一个很大的域范围内随机选一个点,如果的两个多项式在此点的值相等,则证明两个多项式是相等的。
    2. 我们可以看到,等式右边的多项式因子Z是目标多项式,它的零点就是右边整体多项式的零点,也就是等式左边整体多项式的零点,而等式左边的多项式在这些零点的取值,就转换成了一个个的算术电路里每个乘法门对应的一阶线性约束等式(R1CS)成立,即原始计算等式成立(注:R1CS由原始计算等式分解得到);
  3. 算法分为三个步骤,CRS生成;证明者证明;验证者验证;
  4. 可以看到prover生成证明过程中,没有与验证者交互,因此是non-interative;
  5. 如何保证prover用于生成证明的A/B/C/H是多项式且是小于某个度数呢?
    1. 通过trusted party 来保证,因为它是可信任的,因此它生成pk,vk用到的A/B/C等肯定是多项式并且是小于某个度的;
    2. 如果证明者作恶,那么验证者将会很大概率验证失败;
    3. 主要用到了同态加密HH和系数知识假设KCA和椭圆曲线双线性配对等数学知识;

技术指南 | 理解零知识证明算法之Zk-stark

  • zk-stark ALG  【1】【2】【3】
  1. 算法思想:将证明CI statement成立问题转化成证明多项式小于某个度的问题,转换过程用到了多项式插值方法;
  2. 多项式等式成立意味着什么?(图中黄色部分)
    1. 思想与zk-snark一样,T同样为目标多项式,其零点已知且公开,也是等式左侧多项式Q的零点,多项式Q在每一个零点的取值都对应了一个execute trace的成立(没错,在zk-stark中,原始计算语句转化成了多个execute trace,这类似与zk-snark中的R1CS)。因此多项式相等,意味着execute trace 正确,说明原始CI成立。
  3. 多项式小于某个度意味着什么?
    1. 和zk-snark类似的是,两者都把CI statement转换成了证明多项式等式成立的问题(?可以这么抽象的认为,zk-stark不仅要证明多项式相等,还要证明相应多项式是小于某个度的,这是zk-stark算法的核心,所以才有了第一点的描述)。为了防止验证者作恶,必须要保证多项式是低于某个度的(?存在这样一种可能,攻击者可以特意生成满足验证等式的一些点,这些点并不是真正的多项式上的点,但是根据这些点生成的证据也能通过验证者验证)。不同的是,zk-snark使用了trusted party机制 和 同态加密等数学方法,而zk-stark使用了低度测试等数学方法。当且仅当多项式真正的小于某个度时,多项式的相等才是真实意义上的相等,说明生成轨迹多项式的execute trace 是正确的,即原始CI成立。
  4. 算法分为两大步骤,算术化和低度测试;
    1. 算术化:是把问题转化为多项式形式
    2. 低度测试:是证明组合多项式(图中黄色)和轨迹多项式(图中绿色)小于某个固定的度–>FRI算法
  5. 在生成证明的过程中,有交互(图中红线所示),所以图中描述的是交互式的零知识证明算法;

技术指南 | 理解零知识证明算法之Zk-stark

Summary

以上分别从概念和算法上介绍了zk-snark和zk-stark算法的异同之处,作为引文,后续发文将深入详细价绍zk-stark算法的原理。如有错误,麻烦批评指正,谢谢。

Appendix

  1. V神三部曲,含泪拜读 https://vitalik.ca/general/2017/11/09/starks_part_1.html
  2. zk-stark论文 chrome-extension://cdonnmffkdaoajfknoeeecmchibpmkmg/assets/pdf/web/viewer.html?file=https%3A%2F%2Feprint.iacr.org%2F2018%2F046.pdf
  3. starkware官方讲解系列 https://medium.com/starkware/stark-math-the-journey-begins-51bd2b063c71
  4. zk-snark论文 chrome-extension://cdonnmffkdaoajfknoeeecmchibpmkmg/assets/pdf/web/viewer.html?file=https%3A%2F%2Feprint.iacr.org%2F2013%2F879.pdf

清华大学国家金融研究院王言:云计算、区块链等技术已广泛应用于保险业务流程

据北京商报消息,11月29日,清华大学国家金融研究院中国保险与养老金研究中心研究总监王言发言表示,目前,对保险行业影响较为广泛的新科技主要包括云计算、大数据、人工智能和区块链技术。

干货 | Vitalik:Eth2 分片链简化提案

要点提炼

  • 永久性分片链(persistent shard chain)的概念将不复存在,相反,每个分片区块都直接就是一个交联(crosslink)。提议人发出提案,交联(crosslink)委员会负责批准,一锤定音。
  • 分片数量从之前的 1024 减少到 64,分片区块大小从(目标值 16,上限值 64)kB增加到(目标值 128,上限值 512)kB。分片总容量为 1.3-2.7 MB/s,具体值取决于时隙(slot time)。如果需要的话,分片数量和区块大小可随时间的推移而增加,比方说 10 年后最终达到 1024 个分片,以及 1 MB 区块。
  • 在 L1 和 L2 层实施了诸多简化方案:(i)所需的分片链逻辑更少,(ii)因为 “原生的” 跨分片通信可以在 1 个时隙内完成,所以无需通过 Layer-2 为跨分片通信加速,(iii)无需通过去中心化交易所来促进跨分片交易费手续的支付,(iv)执行环境能够进一步简化,(v)无需再混合序列化和哈希;
  • 主要劣势:(i)信标链的开销更大,(ii)分片区块产生时间更长,(iii)对 “突增性” 带宽需求更高,但对 “平均” 带宽的需求更低。

序言/理念

当前的以太坊 2.0 架构过于复杂,尤其是在手续费市场层面,有些人就想到要用 Layer-2 的应变方法来解决 Eth2 基础层的主要问题:虽然分片内的区块时间是非常短的(3-6s),然而分片间的基础层通信时间特别长,需要 1-16 个 epoch(如果超过 1/3 的验证者离线,则要花费更长时间)。这就亟待 “乐观” 的解决方案:一个分片内的子系统通过某种次等安全的机制(如轻客户端),“假装” 提前知道其它分片的状态根,并使用这些不确定的状态根来处理交易,以此来计算自己的状态。一段时间后,一个 “rear-guard” 进程遍历所有分片、检查哪些计算使用了其他分片状态的 “正确” 信息,并抛弃未使用 “正确” 信息的所有计算。

但这个过程是存在问题的,虽然它在很多情况下都能够有效地模拟出超高速通信时间,但是 “乐观” ETH 和 “真实” ETH 之间的区别衍生出了其他复杂情况。具体而言,我们不能假设区块提议者 “知道” 乐观的 ETH(译者注:即完全知晓乐观 ETH 的确定状态),因此,如果分片 A 上的用户向分片 B 上的用户发送 ETH,则分片 B 上的用户要隔一段时间才能收到协议层 ETH(也是唯一能用于支付交易手续费的 ETH)。如果想避免延迟,要么需要去中心化交易所(存在复杂性和低效率问题),要么需要中继市场(又使人担心垄断中继者可能会审查用户的交易)。

此外,目前的交联(crosslink)机制大大增加了复杂性,实际上它需要一整套区块链逻辑,包括奖惩计算、单独存储分片内奖励的状态以及分叉选择规则等,这些都需要被纳入分片链中作为阶段1的组成部分。本文档提出了一个大胆的替代方案,用以解决所有这些问题,使以太坊 2.0 能够更快地投入使用,同时降低风险,其中还有一些折中方案。

方案细节

我们把 SHARD_COUNT (分片数量)从 1024 减少到 64,并将每个时隙处理的分片数上限从 16 增加到 64。这意味着现在的 “最优” 工作流是:在每一次信标链生成区块的期间,每个分片都会产生一个交联(为了清楚起见,我们不再使用 “交联”(crosslink)一词,因为并没有 “连接” 到分片链,直接使用 “分片区块” 更合适)。

干货 | Vitalik:Eth2 分片链简化提案

请注意一个关键细节:现在任何分片位于时隙 N+1 处的区块都可以通过一条路径知道所有分片的在时隙 N 处的区块。因此,我们现在有了一流的单时隙跨分片通信(通过 Merkle 收据)。

干货 | Vitalik:Eth2 分片链简化提案

-现状(近似)-

干货 | Vitalik:Eth2 分片链简化提案

-新提案-

在这个提议中我们改变了见证消息(attestation)所连接对象的结构:在原先的方案中,见证消息中包含着 “交联”(crosslink),交联中包含着以某种复杂序列化形式表示的许多分片区块的 “数据根”;但在新提案中,见证消息只包含着一个数据根,该数据根代表着一个区块内的内容(内容完全由“提议者”决定)。分片区块还将包括来自提议者的签名。为了促进 p2p 网络的稳定性,计算提议者的方式依然使用之前基于常设委员会的算法(persistent-committee-based algorithm)。如果没有可用提案,交联委员会成员也可以就 “零提案” 进行投票。

我们依然在状态中存储一个映射 latest_shard_blocks: shard -> (block_hash, slot) ,不同的是参数由 epoch 变为时隙。在理想状况下,我们希望每个时隙这个映射都能够得到更新。

将 online_validators 定义为活跃验证者的子集,活跃验证者即在过去 8 个时段(epoch)中至少有一个 epoch 包含其见证消息。只有 2/3 的 online_validators (以总余额计算比例)都对给定分片的同一个新区块达成共识,上述映射才会进行更新。

假设当前时隙是 n ,但对于给定分片 i,latest_shard_blocks.slot < n-1(即在前一个时隙中该分片有一个区块被跳过),我们则需要对该分片的见证消息来提供范围 [latest_shard_blocks.slot + 1….min(latest_shard_blocks.slot + 8, n-1)] 内所有时隙的数据根。

干货 | Vitalik:Eth2 分片链简化提案

分片区块仍需指向 “先前的分片区块”,我们还是要强制保证一致性,因此该协议就要求多时隙的见证消息来保证一致性。委员会采用以下“分叉选择规则”:

  • 对于每个有效且可用的分片区块 B(该区块的祖先区块也必须有效且可用),计算其最新消息支持 B 或 B 的后代的验证者总权重,暂且将该权重称为分片区块 B 的 “得分”。即使是空白的分片区块也可以有得分。
  • 在 latest_shard_blocks[i].slot + 1 处根据最高得分选出相应区块
  • 在 latest_shard_blocks[i].slot + k (k > 1)处选择区块时,也根据最高得分来选,但仅考虑其父块已在 latest_shard_blocks[i].slot + (k-1) 处被选择的区块

概述

从信标区块 N 到信标区块 N+1 的发布过程如下:

  1. 信标区块 N 发布;
  2. 对于任何给定的分片 i,分片 i 的提议者提议一个分片区块。该区块的执行过程可知信标区块 N 和先前区块的根(如果有需要,我们可以将可见性降到区块 N-1 和旧区块,这使得我们可以对信标区块和分片区块同时进行提议);
  3. 被分配到分片 i 的见证者提交见证消息,包括其对时隙 N 处的信标区块和分片 i 区块的意见(在特殊情况中也包括分片 i 中先前的分片区块);
  4. 信标区块 N+1 发布,其中包括对所有分片的见证消息。区块 N+1 的状态转换函数对这些见证消息进行处理,并且更新所有分片的 “最新状态”。

成本分析

请注意,参与者不需要随时主动下载分片区块数据。相反地,提议者发布提议时,只需要在 3 秒内上传上限为 512 kB 的数据(假设有 400 万个验证者,每个提议者平均 12.8 万个时隙才需要上传一次),随后委员会验证提议时,只需要在 3 秒内下载上限为 512 kB 的数据(要求是每个验证者要在每个 epoch 中下载一次数据,因为我们保留了一个属性:在任意给定时段中, 每个验证者都会在特定时隙中被分配到一个特定的交联)。

请注意,此操作的要求低于目前每个验证者的长期负载要求,即每个 epoch 约 2MB。然而,这对 “突增性” 负载的要求更高:之前是 3 秒内上限 64KB,现在 3 秒内上限会提高到 512KB。

见证消息(attestations)负载的信标链数据更改如下。

  • 每条见证消息有 224 字节的基本开销(其中 128 字节是 AttestationData,96 字节是签名数据),再加上见证者字段(attester bitfield)需要少则 32 字节(正常情况),多则 256 字节(最糟糕的情况)的数据。也就是说,一条见证消息需要 256-280 字节的开销。一个区块最多可以有 256 条见证消息,平均则是约 128 条(猜测),所以单个区块的消息开销在平均条件下是 32768 字节(约 0.03 MB),最糟糕的情况下是 122880 字节(约 0.1 MB)。
  • 每个分片状态更新消息需要:(i)区块体 chunk 数据根,每 128 kB 的区块数据(或其一部分)就需要一个数据根,所以平均需要 48 字节,最大需要 128 字节;(ii)分片状态根,128 字节;(iii)区块体长度,8 字节;(iv)custody bits,少则 32 字节,多则 256 字节。因此,平均来看需要 216 字节,最大需要 520 字节。单个区块最多可以有 256 条分片状态更新消息,平均是 64 条。因此平均需要 13824 字节(约 0.01 MB),最大需要 133120 字节(约 0.1 MB)。

每个证明有大约300字节的固定数据,加上一个位字段,即每个epoch 400万bit,每个时隙8192字节。因此,目前方案的最大负载为128 * 300 + 8192 = 46592,平均情况中的负载可能更接近32 * 300 + 8192 = 17792,即使这样还可以通过压缩证明中的冗余信息来降低负载。

出于效率考量,在一个区块中我们仅包含胜出见证消息(winning attestation)中的分片状态更新数据;对所有其它见证消息中的分片状态更新数据都仅保存其哈希值作为替代。这样就可以大幅节省数据开销。

还要注意的是,见证聚合在每个分片中每个时隙的成本为 65536 * 300 / 64 = 307200 字节。这对运行节点提出了一个天然的系统需求门槛,因此要再压缩区块数据的话也没有什么意义。

从计算层面来说,唯一大幅增加的花销是需要更多的配对(更确切地说,是更多的 Miller循环),每个区块的上限从 128 增加到 192,而这将使得区块处理时间延长 200ms。

“基础操作系统” 分片

每个分片都有一个状态,就是一个 ExecEnvID -> (state_hash, balance) 的映射。一个分片区块被分成一组 chunk,每个 chunk 指定一个执行环境。一个 chunk 的执行依靠状态根和 chunk 的内容(即分片区块数据的一部分)作为输入,并输出 [shard, EE_id, value, msg_hash] 元组的一个列表,每个分片最多拥有一个 EE_id( 我们添加两个 “虚拟” 分片:向分片 -1 的转账表示验证者在向信标链存储保证金,而向分片 -2 的转账是向提议支付手续费)。我们也会从该 EE 的余额中减去 value 的总数。

在分片区块头里,我们放置了一个 “收据根(receipt root)”,里面包含了一个映射: shard-> [[EE_id, value, msg_hash]…] (每个分片最多8 个 元素;在一个大多数大多数跨分片 EE 转账都是发往同一个 EE 的的转账中,甚至只需要更少元素)。

在分片 i 上的一个分片区块,应有一个默克尔分支,包含所有其它分片的收据,而这棵默克尔分支就是由其它分片的收据根生成的(因此任意分片 i 都可以知道其它任意分片 j 的收据根)。收到的价值会被分配到其 EE,且 EE 可以访问 msg_has 。

干货 | Vitalik:Eth2 分片链简化提案

这就使得不同的分片可以在 EE 间实现即时的 ETH 转移,此时每个区块的开销为 (32 * log(64) + 48) * 64 = 15360 字节。msg_hash 可以被用于减少伴随 ETH 转移所传递的跨分片信息见证内容的大小,因此在一个高度活跃的系统里,15360 字节数据是必不可少的。

主要益处:更简单的费用市场

我们可以接着修改执行环境(EE)系统:每个分片都有一个状态,该状态包含状态根和执行环境的余额。执行环境将能够发送收据,向其它分片的同一 EE 直接发送货币。这个过程将使用默克尔分支处理机制来完成,每个分片的 EE 状态储存着一个其余每个分片的 nonce,用以抵御重放(replay)攻击。EE 也可以用来直接向区块提交者支付费用。

这提供了足够强大的功能性,使得 EE 能够建立在这样的基础之上:允许用户在分片上存币,并将其用于支付交易手续费;在分片间转移币就如在同一分片内进行操作一样简便,从而消除了对中继市场需求的紧迫性,也不需要让 EE 来承担实现 optimistic 跨分片状态的负担。

完全的和压缩后的见证消息

出于对效率问题的考量,我们还进行了以下的优化。如前所述,指向时隙 n 的见证消息可完整地包含在时隙 n+1 中。但是,如果此种见证消息需要被包含在后续的时隙中,则必须以 “精简形式” 进行嵌套,仅包含信标区块(头部、target、source),而不包含任何交联数据。

这不仅起到了裁减数据的效用,更重要的是,通过强制 “旧见证消息” 保存相同数据,可以减少用于验证见证消息所需的配对数:在大多数情况下,所有来自相同时隙的旧见证消息都可以经由单一配对验证。如果链不分叉,那么在最坏的情况下,用以验证旧见证消息所需的配对数会被限制在 epoch 长度的 2 倍。如果链确实分叉,则要包含所有见证消息的能力就得依赖于一个更高的诚实提议者比例(譬如 1/32,而非 1/64),并且要将更早的证明也包含进去。

保证轻客户端的参与

每天,我们随机选择一个由大约 256 个验证者组成的委员会,这个委员会可以在每个区块上进行签名,其中签名被包含的验证者便可以在区块 n+1 中获得奖励。这样做的目的是允许计算能力不高的轻客户端参与。

题外话:数据可用性根

证明一个 128 kB 数据的可用性的操作是多余的,几乎没有价值。与此相反,有意义的是:要求一个区块能够提供该区块接受并组合在一起的所有分片区块数据的串联根(也许这个分片区块数据根以列表形式存在,其中每个根代表 64 kB 数据,这样使得串联更容易)。 然后可以根据此数据创建单个数据可用性根(平均 8 MB,最坏情况下达到 32 MB)。 请注意,创建这些根可能要花费比一个时隙更长的时间,因此,最好用于检查一个 epoch 前的数据的可用性(即,从这些数据可用性根中进行采样将是额外的“确定性检查”)。

其他可能方案

  • 时隙 n 的分片区块必须引用时隙 n-1的信标链区块,而不是时隙 n 处的信标链区块。此种措施将允许以时隙为单位的循环并行发生,而不是串联发生,从而减少时隙时间,这样做的代价是导致跨分片通信时间从 1 个时隙上升到 2 个时隙。
  • 如果一个区块提议者试图将区块大小扩大到 64KB 以上(备注:目标128kB),他需要首先生成 64kB 的数据,然后让交联委员会对其进行签名,接着,他们可以添加一个引用第一个签名的 64kB 数据,以此类推。这将鼓励区块创建者每隔几秒提交他们区块的部分完成版本,从而创建一种预先确认的机制。
  • 加快秘密领导人选举的发展(简单起见,即使一个约 8 到 16 人的匿名集环签名版本也能有所作用)。
  • 与其使用 “强制嵌入” 机制,我们不如寻求一个更简单的替代方案:每个分片为其余的每个分片维护一个 “inbound nonce” 和一个 “outbound nonce”(即 8 * 64 * 2 = 1024 字节的状态),一个分片制造的收据将需要手动进行添加,并由接收的分片按顺序进行处理。收据生成将受限于每个区块每个目标分片的少数收据,以确保一个分片能够处理所有传入的收据,即使是所有分片同时向它分送收据。

原文链接: https://notes.ethereum.org/@vbuterin/HkiULaluS?from=groupmessage&isappinstalled=0 作者: Vitalik

本文由 ECN 以太坊中国 社区翻译,EthFans 经授权使用译本。再出版时,根据原文的改动更新了译本。

Vitalik:论eth1与eth2的双向桥接

原作者 | Vitalik Buterin
本文目的在于阐述在 eth1 链和 eth2 链之间建立双向桥接的一些挑战 (例如,支持 ETH 的双向转换),以及如何实现。
Eth2 提案中已经包含 eth1-> eth2 的单向桥接,这对能够把 Eth1 中的 ETH 抵押到 eth2 中是必要的。这种单向桥接通过 eth1 数据投票机制[1]来实现。请注意,该机制假设大多数的 PoS 验证者是诚实的,同时 PoW 链没有受到攻击(具体来说,就是 PoW 链中回滚不会超过5个小时)。如果这两个假设中的任一假设失败,那么 eth1 和 eth2 这两条链将不再彼此“一致”。其中一开始便存在一条隐式的“社会合约”,即如果发生任何一种意外都有补救措施,很可能通过 PoS 链的软分叉来补救;然而也有可能如果 PoW 链回滚确实超过5个小时,那么社区可能会达成攻击链无效的共识。需要注意的是,不管在哪种情况下,PoS 链的故障是不可能需要 PoW 链进行软分叉的。

而如果我们希望 eth1 链知道 eth2 的状态(也即实现两条链的双向桥接,这是允许 ETH 从 eth2 链转移回到 eth1 链的前提),有两种方法可以实现:

  • 一种是使 PoW 链接受一个 PoS 链的轻客户端
  • 另一种是使 PoS 终态也敲定 PoW 链

第一种方法要求 eth1 中实现 eth2 客户端 (见下图)这将需要对 BLS-12-381 验证的 webassembly 或者原生支持,不要期望这种支持能够很快实现。另外,这种方法仅提供轻客户端级别的安全性

Vitalik:论eth1与eth2的双向桥接

第二种方法可以通过添加这一机制来实现,即如果一个经由 eth1_data 投票的 PoS 区块 Bs 包含一个指向 PoW 区块 Bw 的引用(reference),当区块 Bs 确认后,Bw 区块也可视为被确认 (见下图)。不过这意味着 PoW 矿工(和客户端)也要运行 eth2 实现版,以便他们知道哪些 eth2 链被确认。Vitalik:论eth1与eth2的双向桥接
第二种方法更有趣,因为它为 eth1 提供了“原生”版回滚限制(通常称为“终态小工具提议(finality gadget proposal)”)。请注意,这与第一种方法有所不同,因为虽然它确实使 eth1 的分叉选择知道 eth2,但并没有立即使 eth1 知道 eth2 的状态。例如,理论上有可能两条竞争的 eth2 链确认同一个 eth1 区块 (这意味着 eth2 已经出故障,但从理论上讲还是有可能出现的)。更常见的情况是 eth2 链确认的两个区块,其中一个区块是另一个的子区块,而这两个区块都支持相同的 eth1 区块,从而有些矿工可能知道这两个 eth2 区块的最近状态,而另一些矿工不知道。这对“eth2 作为终态小工具”来说不是问题,但这确实意味着我们需要更多底层设计,使 eth1 清楚知道 eth2 的区块状态,以便允许从抵押合约(Deposit Contract)中提取 ETH。

一种可能方案是在 eth1 中简单地创建一个 eth2_data 投票机制;本质来说,就是复制使 eth2 知道 eth1 状态的同一种机制。可将其与上文方案结合起来确保一致性:eth1 矿工仅会为 eth2_data 区块进行投票,条件是只有当这些区块满足(i)已确认,以及(ii)引用的 eth1_data 区块是矿工正在打包的 eth1 区块的祖块(ancestors)。

 

面临的挑战

这两种方法都需要对 eth1 方面进行改动。目前在eth1-> eth2的“最终转换”之前,eth2 路线图对 eth1 方面没有改动。而如果 eth2 中断,这两种方法都需要 eth1 采取紧急补救措施。第二种方法将要求所有 eth1 矿工也要运行 eth2 节点。因此,尽管这两个中方法都是绝对可行的,但并不会很快实现。但是,随着 eth2 持续运行并证明其稳健性,那么肯定会到一个实现这种双向桥接很有意义的阶段。为了降低风险,可以做一些事情:

  • 在 eth1 上运行 eth2 投票时有一周的投票时间,以便在出现问题时有时间进行人工干预;
  • 由于同样的原因,eth1 通过轻客户端知道 eth2 中已敲定的区块时,ETH 的提取也会有一周时间的延迟;
  • 当抵押的 ETH 数量足够多(如大于500万)的时候才开启这种桥接;
  • 将投票阈值设置为高于50%(例如80%);并使系统更倾向于不包含任何 eth2 区块 (除非这些区块获得了很强的共识)。

 

原文链接:

https://ethresear.ch/t/two-way-bridges-between-eth1-and-eth2/6286

参考链接:

[1]:https://github.com/ethereum/eth2.0-specs/blob/fffdb247081b184a0f6c31b52bd35eacf3970021/specs/core/0_beacon-chain.md

巴比特晚间要闻一览

1.俄罗斯或禁止加密货币支付。
2.日本央行发布央行数字货币研究报告:CBDC的具体设计会根据目的而有所不同。
3.原浙商银行行长刘晓春:如果中国央行首先推出数字货币,无疑具有重大的示范意义。
4.范一飞:粤港澳大湾区贸易金融区块链平台目前业务量已超过700亿元。
5.IDAX发布紧急公告:IDAX Global CEO已失踪5日,暂不能访问交易所冷钱包。
6.最高法党组副书记:积极推进互联网、区块链等现代科技在司法领域的应用。
7.日本东北电力启动太阳能电力共享试用,将利用区块链记录所测数据。
8.IBM获区块链相关新专利,防止盗贼利用无人机盗窃物流包裹。

雪松国际信托林伟龙:区块链技术将重构供应链金融

据央广网消息,11月28日,由新财富和雪松国际信托联合主办的“韧性与重构——全球变革中的‘少数派’金融方法论”高峰财富论坛在深圳召开,雪松国际信托董事长林伟龙在论坛上表示,金融的核心是风控,区块链技术具有去中心化、不可篡改、集体维护性等多种特性,能帮助供应链金融在交易场景中提升风控能力;而且,从区块链技术的具体商用落地场景看,供应链金融也是最成熟的领域之一。

报告:成都区块链人才需求居全国第五

据川报观察消息,智联近日发布的《2019年区块链人才供需与发展报告》显示,在今年前三季度,成都市对区块链人才的需求量位居全国被调查城市的第五位。2019年三季度,区块链招聘需求城市分布中,深圳、上海、北京位于第一梯队,招聘人数占比分别达到21.07%、16.07%、13.9%,广州和成都紧随其后,分别占比5.79%、5.34%。

IDAX发布紧急公告:IDAX Global CEO已失踪5日,暂不能访问交易所冷钱包

11月29日,IDAX官方发布关于IDAX Global现状的紧急公告。公告指出,自11月24日IDAX发布关于提币通道拥堵的公告以来,IDAX Global CEO已经失踪,且原因不详,IDAX Global员工与CEO未能取得联系。因此,目前不能访问交易所冷钱包,也无法提供存提服务。IDAX Global正在制定有关平台服务(包括存款/提款服务)的紧急计划,因此建议不要使用平台所有的服务。

林洋能源:目前已实现实验室阶段的区块链智能电表研究测试

林洋能源(601222)在互动平台表示,公司非常关注基于区块链的用电信息采集数据可信性的相关技术,并在积极推进相关产品技术的试点试用,南京林洋专设区块链研究团队,目前已实现实验室阶段的区块链智能电表研究测试。