您的位置:首页 > 编程语言 > ASP

参数化Casper:介于去中心化/最终化时间(finality time)/开销之间的权衡

2019-05-11 16:45 1661 查看

随着 Casper 协议持续达成一个越来越稳定的形式,人们对协议中将要被设置的各种各样的参数也越来越感兴趣,包括利率,费用,赎回期限,速度,需要用作股份的 ETH 最小数量,等等。这篇文章将是尝试描述协议中包含的各种各样权衡的系列文章的第一篇,并且将重点放在具有经济最终化的协议中的去中心化与效率上。

首先,我们将会简短地定义经济最终化(economic finality)(我们将会假设一个 2/3 的阈值;Vlad Zamfir 将很快会指出我们实际上想要节点能够设置他们自己阈值的能力)。

经济最终化,版本1:状态 H 是经济上最终化的,如果至少 2/3 的验证者签署了证明 H 的消息,并且在任何不包含 H 的历史中,他们会损失他们全部保证金。

经济最终化,版本2:状态 H1 是经济上最终化的,如果足够多的验证者签署了证明 H1 的消息,并且如果 H1 和一个冲突的 H2 同时被最终化,那么会有相关证据可以用来证明至少 1/3 的验证者是恶意的,并因此毁掉他们全部的保证金。

当前,我和 Vlad 都在致力于赞成版本2的协议。但是注意两个版本的经济最终化都需要(i)至少 2/3 的验证者签署某一消息,(ii)验证这些消息的网络*(在后面有一个巨大的星号,因为证明发现是有方法来解决这个问题的,只不过他们基本上是分片思想的形式,所以对于一个“最大化简单”版本的 Casper,我认为他们是带外的)。

现在的意思是,为了状态 H 能够被最终化,网络必须验证一个来自至少 2/3 的验证者池的消息。从这个简单的事实中,我们可以得到一个深刻的介于下列三种事情的权衡:

  • 最终化时间:在状态 H 被提议以后,经过多少秒,状态 H 被最终化?

  • 去中心化:这里定义为验证者池的大小,例如,一个区块链可能有容纳 1000 个活跃验证者的空间。注意这个直接与可访问性(即成为一个验证者,必需的最小数量 ETH)有关。但是随后关于这个会有更多信息。

  • 开销:每秒全节点(包括验证节点)需要验证多少消息?

理想情况下,我们想要最小化达成最终化所需的时间,最大程度的去中心化以及最小化的开销。但不幸的是,我们不能三者兼得。具体来说,从上述给出的验证者消息的事实来看,我们得到这个数学等式:

f*o≥d*2/3

其中,f 是以秒为单位的最终化时间,o 是开销,d 是验证者池的大小(去中心化)。这是来自物理学中“速度=距离/时间”这一著名定理的一个简单翻译:如果你需要在 f 秒(“时间”)内处理 d*2/3 的消息(“距离”),那么每秒处理的消息数量(“速度”)是 d*2/3 / f。注意在现实情况中,共识协议需要多轮消息的轮换,所以上述等式极有可能是 f*o≥d*2,并且在正常情况下,会有超过 2/3 的节点出现。因此,为了方便,我们就使用:

f*o≥d

现在,让我们列出一些参数来说明这个不等式。考虑类 PBFT 算法的协议,其中,区块 n 总是在开始下一个区块 n+1 之前被最终化,并且假定区块时间是 10 秒。假设你想支持 500 个验证者,那么,10*o≥500,所以开销至少是每秒钟处理50条消息。

现在,考虑一个基于链的使用5秒区块时间的权益证明协议,所以 o = 1/5,并且假设 10000 个验证者。那么,f/5≥10000,所以 f≥50000(例,14个小时)。一种中间途径是使用大概 1000 个验证者,每秒 1 条消息的开销,以及 1000 秒的最终化时间(大概15分钟)。你可以自由地在这个等式中设定你自己的参数,看看什么是可能的,什么是不可能的。再一次强调,重要的结论是,我们不能拥有这 3 种特性,至少同时达到不可能。

所以,有四条前进的路线:

  • 以高程度的去中心化与低开销为目标,让最终化时间特别长。交换用于超过一个小时的最终化时间,所以告知他们它仍然会是这样。

  • 以高程度的去中心化与短的最终化时间为目标,但是要求节点处理高开销。告诉全节点操作者面对现实并接受这个事实,并致力于改进轻客户端协议。

  • 以低开销与短的最终化时间为目标,使验证权利变得难以接近。致力于改进去中心化的权益池软件作为一个基本层次去中心化的次最好方案。

  • 丢弃经济最终化的目标。

注意在类型 1 的经济最终化的上下文中,你可以尝试得到“部分”的经济最终化(例,在你需要获取 67% 的验证者保证金的 1/20 时间里,获取到对同一个消息签名的 3.33% 的验证者保证金,这仍然是一大笔钱),但是在类型 2 的经济最终化的上下文中,你不能做上述事情,因为你根本得不到经济最终化,除非超过 50% 的验证者对同一个状态签名。同样,无论在哪一种上下文中,我们可以在三种特性之间寻找到权衡的方式。

对于权益池的确定性阈值签名

注意,我们关于椭圆曲线配对预编译的研究工作是很重要的,因为与 zk-SNARKs (零知识证明)算法一起,早期的这些研究工作可以用来实现确定性阈值签名。因此,我们可以有一个这样的系统,在该系统中,我们在基本层面也许只有100个验证者,但是期望这些验证者中的大部分都是以池的形式出现。这些验证者的验证代码将会是一个阈值签名的证实者(可以在常数时间内计算出),并且这个阈值签名证明池中至少 2/3 的参与者赞成给定的哈希值。每一个池自身也许有几十个甚至几百个参与者。

我们为什么不能在高层面就使用确定性阈值签名?首先,他们不会披露谁参与其中,仅仅是足够的人参与其中。所以我们不知道奖励谁,惩罚谁。第二,他们与密码学抽象的目标相悖,之所以是密码学抽象,是我们想要协议中的每一个用户,包括验证者,能够使用他们想要使用的密码学。

理论上,这些验证者池可以以许多不同的方式管理。两个最显而易见的范例是:

  • 全开放:存在一个智能合约,任何人都可以通过该智能合约加入验证者池。

  • 封闭的:验证者池是由一组彼此了解的朋友构成的。

全开放的验证者池是有风险的,因为一个攻击者可以以大量身份加入该池,大体上可以发起 51% 攻击;因此,全开放验证者池中的参与值有着不是由于自己错误而导致财产损失的风险。然而,攻击者也将损失与他们的受害者同样多的资金(例,悲伤因子(griefing factor)的界限大约是 0.5-2 )。封闭的验证者池是更安全的,但是当然他们依赖于人们拥有信得过的不会共谋伤害他们的朋友。在现实中,可论证地,这种类型的验证者池允许一个更加可容忍的去中心化水平,只要在基础的验证者集合中有足够的“槽”,允许大量不同的验证者池能够被创建。

有另外一种类型的权益池,它使用可信的硬件而不是确定性阈值签名;看Loi Luu 最近的博客获取更多信息。再一次注意,这样一个设计不要求整个网络信任一个特殊品牌的可信硬件;相反,它只要求在那个特定池中的参与者这样做,一个鲁棒的重度使用这种模式的网络极有可能包含大量使用不同可信硬件解决方案的不同验证者池,还有青睐于确定性阈值签名的用户以及仅仅“自己单干”的。

除了效率,权益池有另外一个优势:它移除了个人参与者的负担:(i) 100% 的在线时间以及(ii)不被黑客攻击。

从验证者数量到最小权益ETH

给定一个验证者数量(例,d = 1000),接下来的问题是:这个如何转换成对于用户个人来说很重要的另一个变量 – 他们需要多少 ETH 来成为一个(基本层面)验证者?对于此,有一些方案:

  • 设置某个最低保证金规模(例,500 ETH),让作为权益的 ETH 数量,还有总的验证者数量(因此,要么最终化时间,要么开销)浮动。

  • 设置一个最大的验证者数量,随着当前活跃的验证者数量接近最大值,增加最低保证金规模直到无穷大。

  • 介于两者之间的一些中间策略,例,你可以考虑设置最低保证金规模到等于当前权益验证者的数量。

为了检查最坏的情况,我们得到这么一个简单的数学公式:
总的作为保证金的以太币 = 最低保证金规模 * 验证者的数量
原因是很明显以及无争议的。现在,我们能够做的就是允许拥有超过最低保证金规模的人们存一个更大的保证金,并且计算此次存款一次。如果这个发生了,然后现实中,我们将会得到一个比最坏情况更好的结果。假设 Zipf’s 定理是正确的,那么一个给定保证金规模处的乐意的验证者数量与那个规模是呈相反比例的,所以例如,在 1000 ETH 处的乐意的验证者数量10倍于在 10000 ETH 处的验证者数量。一种快速方法是假设对于每一个整数 n>= 1存在一个规模为最大验证者保证金规模/n 的乐意验证者,其中最大验证者保证金规模本身是这个模型的一个输出。

现在,固定某个验证者数量。最大 k 个验证者存储的总的 ETH 数量,例如,对于所有 1<=n<=k 的最大验证者保证金规模/n的和大概接近于最大验证者保证金规模*(ln(k) + 0.5)(其中 ln 是自然对数,即求解最大验证者保证金规模 * ,这是调和级数,其中 0.5 为欧拉-马歇罗尼常数,参见wiki),所以我们得到以下等式:

验证者数量 = 最大验证者保证金规模 / 最低保证金规模

总的保证金以太币 = 最大验证者保证金规模 * (ln(验证者数量) + 0.5)

如果我们固定任何两个变量,然后我们就可以解出另外两个变量的值。假设我们固定最小保证金规模到 500 ETH,并且假设 1000 万 ETH 的总存储规模。那么我们可以解上述等式,得到下列结果:

  • 2412 个验证者

  • 最大的验证者有 1206000 ETH 的保证金规模

如果我们约减最低保证金规模到 50 个ETH,那么我们会得到 19291 个验证者;如果我们增加它到 1500 个ETH,那么我们得到 911 个验证者。可选地,我们能够从另外一个方式解决这个数学问题:如果我们想要 1000 个验证者的目标值,那么最低保证金规模为一个均衡的大约 1350 个ETH。注意,全部这些都假设使用你想要的超过最低规模的保证金加入是可能的;如果我们没有这个特性,那么权衡方案会由于作为拥有更大保证金的验证者的一个大约 log(n) 的因子变得更加糟糕,将不得不分裂他们自己到许多账户,每一次一个状态最终化时都会生成许多签名。为了这个原因,支持可变的超过最低保证金规模的保证金被认为是一件有益的事情。

引用: https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735#.x89q103aj
 

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐