LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 行情分析 > Vitalik反对信标链的喂价服务提案

Vitalik反对信标链的喂价服务提案

2020-05-13 蜜蜂查 来源:火星财经

5月12日,以太坊2.0研究者Justin Drake在以太坊的ethresear.ch论坛中提出了基础层价格预言机提案,提案其建议在信标链中添加一个简单的喂价服务,跟踪关键资产的价格以为需要喂价服务的场景提供价格信息。例如每个验证者打包的块中的价格信息。原本以太坊出块中的价格信息都来源于多个节点的获取价格的平均值。

而对此,以太坊创始人Vitalik Buterin表示坚决反对,并提出六大反对理由:

1.这是对区块链技术特性的一个根本性改变。

2.该提案依赖于多数诚实假设,但在以太坊2.0上面所做的很多事情,从根本上讲是要摆脱多数诚实的假设,并试图在多数诚实假设失败的情况下创建“第二道防线”。

3.损害了协议的中立性,并为进一步的中立性妥协开辟了一条道路。

4.关闭了预言机设计创新的大门。

5.增加了staking验证者中心化的风险。

6.与基于应用层token的预言机(例如Augur等)相比,其实际上并没有提供更多的安全性。此外他还表示,以太坊生态系统得益于强大的应用层代币生态系统,而不是通过L1层垄断所有重要功能。

以下为Vitalik的意见原文:

我绝对反对!

首先,这是对区块链试图做的技术特性的根本改变。现在,我们具有可以完全以编程方式验证区块链进度正确性的属性。有效性是一种确定性功能,可用性(即非审查性)可以通过在线节点进行验证,让低延迟的在线节点就区块链是否审查交易达成共识。另一方面,该建议旨在引入即使在原则上也无法通过任何程序验证的链的属性。甚至在可能存在的未来世界中,对于要输入的正确值也没有明显的共识(例如,上述国家之一发生内战,双方都声称要维持“实际”美元/日元)。

第二,它依赖多数诚实的概念,但是我们在eth2上所做的很多努力从根本上讲就是摆脱多数诚实概念的假设,并试图在多数诚实概念失败的情况下建立“第二道防线”。例如:监管证明,数据可用性证明和欺诈证明,审查检测技术等。

第三,它损害了协议中立性,并为进一步损害中立性开了一个“斜坡”。该建议将“ defi”提升为特权应用程序类别,并且提升特定的一组资产/价格指数。对更多资产的需求将不可避免地出现,最终将导致对除价格以外的其他事物的预言需求。它还使基础层治理面临政治风险;基本层治理将必须判断哪些货币“足够重要”,哪些应用程序类别足够重要,如何裁定紧急情况……

第四,它关闭了Oracle设计创新的大门。这种设计的自然替代方法是,仅应在时间T+1天商定时间T的价格,以便为链上攻击、交易所长时间停止工作以及通常具有功能的API留出空间,设计Oracle的方法有很多,而L1用一种方法支配生态系统似乎并不正确。

第五,这增加了将验证程序集中化的风险,因为客户将需要更多的自动更新来维护其Oracle,从而增加了验证程序仅盲目遵循客户开发人员指示的风险(否则人们将完全放弃并转向池)。

第六,与基于应用程序层的基于token的oracle(例如Augur等)相比,它实际上没有提供更多的安全性。MKR市值约为200万ETH,因此应用层代币可以明显获得重要市值。我们预计初始抵押ETH也将在约200万范围内(可能更长的时间约为1000万)。因此,从根本上说,基层Oracle的安全级别根本没有比流行的应用层Oracle高得多。充其量似乎更像是一个数量级的差异。

实际上我认为我们应该朝相反的方向发展,明确限制和限制基础层的功能,以便为应用层生态系统故意留出空间来使用其他工具。Augur作为一个oracle一直运行良好,并且存在其他设计(UMA,MKR,Chainlink等)。

以太坊生态系统受益于强大的应用层代币生态系统,而不是在所有重要功能上的L1 / ETH垄断。这是因为以太坊生态系统对公共财务的需求很大,并且提供这些公共财务的ETH的供应有限(EF中约有590k ETH加上一些鲸鱼持有的),而且修改以太坊协议以获得更多ETH在政治上是困难的。但是,应用层token可以提供这些公共物品;例如。Gnosis在智能合约钱包中已经做了很多工作,现在已经维护了openethereum等。应用层代币甚至可以直接通过二次融资来资助公共财务。因此,我们应该刻意地寻求和设计与此类应用程序层token共生的工具,而不是将它们视为基础层的试验场。

本文来源:蜜蜂查
原文标题:Vitalik反对信标链的喂价服务提案

—-

编译者/作者:蜜蜂查

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...