以太坊的自主托管型方案StarkEx 会带来哪些变化?

StarkEx是一个可扩展的引擎,它支持用户自行管理资金;它只是刚刚在以太坊主网上登陆。STARK验证系统(Zero-Knowledge Proof

ZKP)的零知识是 StarkEx实现的。独立托管功能的实现之路坎坷:托管方案将变得更加简单、更加廉价,并且(最重要的)更加容易理解——多年来,人们对托管型软件系统已习以为常。事实上,“自动托管系统”,或称为“非托管系统”,是一种相当广泛的应用。如果系统的使用者能够预先设定他们能够完全控制自己资金的系统,那么这个名字也可以叫做:免许可区块链最初是作为主机系统的替代品而出现的,想到这一点,你就会觉得现状好神奇。我们知道完全自主托管系统的建立是困难的,而且在这个圈子里搞创新有很多方面。随着时间的流逝,我们也会发现,迁移到一个更加自主的托管系统总是有用的。这一系列的博客文章将详细介绍我们所做的选择和我们为 StarkEx (在这一维度)设置的方向。这篇文章是我们系列博客的第一篇,准备讲述我们在保证 StarkEx是且将永远是自主托管模式方面所做的努力。第一,有必要定义什么是“自主托管(self-custodial)”。根据我们的观点,只有当一个系统满足以下属性时,才可以称为“自主托管型系统”:没有用户的明确签字,资金就无法转移;(通过钱包中的用户体验设计)在签名时,用户可以获得所有的信息;资金可以随时退出;代码升级机制即使被滥用也不能破坏上述机制。这篇文章试图解释:(1)为什么说证明系统最适合支持自主的托管模式;(2) StarkEx智能合约的审计、状态。随后的会议又讲到:(3)我们使用的智能合约升级机制;(4)钱包支持(STARK签名方案和整合方法);(5)数据可用性,(从我们第一个版本使用的数据可用性委员会方案到完全免信任链下的数据可用性方案)。自定义托管是一种神圣的理想,可以追溯到区块链最初的愿景,它的核心是:“没有带上你的私钥就不算你的货币(not your keys

not your coins)。早先,由于Layer-1的吞吐量受到限制,自动托管的理念常常被可扩展性(和流动性)所取代。这一妥协的结果就是集中的交易所:交易所托管了交易员的加密资产,交易员从流动性(以及对手方风险中获益)中获益。但是现在, ZKP系统背后的科学和工程技术已经成熟,特别是 STARK,我们已经完全达到了奇点,没有必要再做出这样的让步了。zkp系统的历史是美丽而复杂的。关键在于 ZKP系统可以避免信任模式,从而为公链提供可扩展性和隐私性。而且,自主托管型解决方案正好要求免信任的基础结构。换言之,如果一个实体需要被信任,那么即使它不能成为一个空洞的句子,它的意义也会被极大地削弱。一个 ZKP系统包括两个部分:一个基础层,它提供“计算完整性(CI)”,一个概率层,它保证零知识。实际上,我们只需要 CI层就可以实现可扩展性。第一 CI层可以帮助参与协议的一方(即证明人)在链上生成任意计算(或状态转换)的证明,而另一方(验证人)(任意数量)则可以在链上用很小的计算开销来验证证明,从理论上讲,当然,信任假设越少越好。对于 STARK,具体地说,不需要对验证者做出任何信任假设,既不需要实时信任关系,也不需要预先处理信任关系,因为 STARK不需要可信初始化设置(trusted setup)。极端地讲,即使有恶意团体使用恶意硬件作为证明人,不同的计算结果也会有所不同,由错误的计算产生的证明不能通过检验,验证程序在链上运行,需要保证资源充足,StarkEx是一个为交易所设计的扩展引擎,但是 STARK也可以被用来为其他应用提供扩展。当使用时,应用的部分逻辑要在链下实现,而需要与链上实体(智能合约、账户等)进行交互的逻辑则要在链上作为应用智能合约(ASC)实现。StarkEx的用户之一是我们的合作伙伴 DeversiFi,这是一家自动托管的交易所。DeversiFi将使用 StarkEx来扩大包括交易转移在内的交易操作的吞吐量。国家科学和技术委员会保证,没有使用者的签字资金是不能转移的(签字通过 STARK证据的验证)。StarkEx要求用户向 ASC存钱,这使得 ASC很容易成为黑客的目标。此 ASC代码已被审核并进行了高强度测试,以确保其正确性和安全性。另外,为了保证代码的正确性和安全性,我们还打算继续使用其他工具,例如形式化验证。审核不能保证系统的安全性,因为对合约的控制账户(admin)能够对合约进行一系列升级,使自主托管成为空中楼阁。对智能合同的升级(或者换句话说就是迁移)允许开发人员修复 bug和扩展功能。接下来,我们将在博客中讲述我们如何设计智能合约升级机制,以确保 StarkEx能够永远保持其自主托管能力。没错,还有一点要提醒的:大家通常用来描述“自主托管模式”的形容词是“非托管模式”,我们不喜欢这个词,因为它是否定的,而且似乎意味着,托管模式(如中央交易所)就是一个基准,是可以借鉴的。但是托管式解决方案违背了公链的精神。强迫托管方回归其最初的角色,正是比特币和以太坊的精神所在,这也是为什么我们更喜欢“自主托管”的原因。动力, StarkEx是一个自动托管的可扩展引擎。本文介绍了自主托管式系统的各个方面,可升级性也是其中之一。这篇文章将介绍我们为 StarkEx构建的提升机制,它是确保 StarkEx保持自主托管的关键。有两种情况需要对智能合约代码进行升级:添加新功能和修复安全漏洞。困难的是如何在不影响系统自托管性的情况下引入升级。假如 StarkEx逻辑被恶意替换,那么应用程序运营者可能会控制所有用户资产。StarkEx采用了一种新的提升机制来保护用户资产。简言之,这种机制利用了时间锁和三种临时智能合约(下文详细介绍)。StarkEx应用合约简介 StarkEx应用合约(ASC)是由 openZepplin (open-Zepplin)率先引入的代理模式,因此它包含了多个子组件。所有数据和资金都存储在代理合同中(通过一个指针),并且指向一个地址,地址定义了一个功能(即逻辑合同逻辑)。使用代理合约,我们将在代理合约环境中运行委托调用(delegate call)以调用逻辑合约。所以, StarkEx ASC逻辑由逻辑合同定义;整个系统通过在代理合同中部署新合同和更新指针来升级(逻辑)。验证机构(Verifier)合同和数据可用性委员会(Data Availability Committee

DAC)合同的地址都被逻辑合同所引用,而不是代理合同(如果你想看有关 StarkEx组件的介绍,请点击这里)。提升机制和保护自主托管,在第一阶段,我们分别为逻辑合同、验证合同和数据可用性委员会合同设置了提升机制。只有授权地址才能执行所有升级操作。1.逻辑合约升级:其他两个合约都提供了验证服务:一个用于验证 STARK证明(验证者合约),另一个用于验证数据可用性(DAC合约)。两者本质上是相似的,因此都由逻辑合约执行,并以相同的方式进行升级。2.,验证者合约升级:,3.

DAC合约升级:在模式和原理上与验证者合约相同,为了更好地理解这些验证合约的累加性质,将它们想象为一个筛子:验证者合约是一个仅允许有效语句通过的密密麻麻的筛子。StarkEx并没有用新的过滤器取代旧的过滤器,而是要求该语句同时通过前一个过滤器和新部署的过滤器。这个新过滤器不允许无效语句通过验证,只有在进一步限制后,才视为有效语句集合。多数比特币协议升级(软分叉)也是如此:软分叉执行后,以前被认为无效的区块仍然有效,而以前有效的区块也有可能变为无效。安全风险及其解决方案,就像我们前面提到的,智能合约升级的一个主要原因就是检测安全风险。安全风险可分为以下三类:1.资金锁定:,2.资金被盗:,3.验证者可靠性漏洞:,这种漏洞可能导致资金锁定和被盗,这是一个值得单独讨论的问题,因为 StarkEx是一个基于零知识证明的系统。StarkEx是一个自主的托管型可扩展引擎。本文介绍了自主托管式系统的各个方面,其中也包括钱包。这篇文章将介绍我们如何与不同的钱包提供商合作,以确保 StarkEx能够独立地管理系统。一个重要的特点是,一个独立的托管型系统需要用户签名来进行每次交互。最基本的原则是“不仅要签名,还要核实”。—这是应用于区块链行业的一句老话:“不要相信,要去验证。”换句话说,如果用户不能验证,自主托管系统就只是徒有虚名。使用者需要能够验证他们的钱包与自主托管应用程序之间的交互参数。举例来说,如果一个用户为一个链上的合约提供了签名, ta的钱包就会显示一个解析良好的可读消息,而不会显示一堆令人费解的数据。当用户需要签订链下交易时,二层应用也应该遵循这个原则,为坚持“不仅要签名,还要验证”的原则,我们正与多家钱包供应商合作,直接将我们的协议整合到他们的产品中。这种融合对于零知识证明体系尤其重要。为更有效地进行签名验证,零知识证明二层体系使用的曲线一般与标准以太坊曲线不同,使用的散列函数也不同。一个简单的方法就是在浏览器上实现钱包。人们之所以倾向于不这样做,主要有两个原因:第一, StarkEx的目标是让用户能够直接在专业交易平台上进行交易,而不需要把钱转到别处;第二,建立一个安全的钱包并不容易(最近路印发现的高风险前端漏洞就是一个很好的例子)。以下是到2020年5月为止 StarkEx所支持的钱包。完全集成:完全集成,完全集成了 StarkEx的全部集成。不管是链上合约调用还是链下订单提交, Ledger都会解析每个交互,然后显示给用户。在 Ledger中签署之前,用户需要进行确认。使用者可以检验每次互动的参数。另外, Ledger将在它的本地化以太坊应用中支持 StarkEx (用户甚至不必通过 Ledger Live安装特定应用),要合并 StarkEx,我们必须向 Ledger的固件添加 STARK专用曲线,并在 Ledger的应用中执行 StarkWare的散列函数(Pedersen散列函数)。由于 StarkWare和 Ledger的紧密结合, Ledger成为第一个应用于第二层硬件的钱包。完全集成:完全集成, WalletConnect完全集成了 StarkEx。WalletConnect是一种开放协议(QR码),它将桌面应用与使用端到端加密技术的移动钱包相连接。使用 Pedro Gomes实现 StarkEx交互,创建 StarkEx WalletConnectProvider。DeversiFi是第一家建立在 StarkEx上的自主托管式交易所,它也在其应用中集成了 WalletConnect。手机钱包 Argent目前正与 StarkExWalletConnectProvider进行整合,不久将支持用户通过 DeversiFi进行自主托管式交易,混合解决方案:目前,我们为 MetaMask用户提供的混合解决方案。所有的链式交易都会被 MetaMask处理,所有的链式交易都会被浏览器内置的钱包处理(首先是 DeversiFi钱包)。这个解决方案和今天的大多数二层方案一样,它让我们能够直接支持 MetaMask庞大的基本用户群。这个方案目前还不能像上面所说的那样完美:用户既不能验证链上合约调用,也不能验证链下交易。在 MetaMask部署 Snaps插件系统之后,这个问题就可以解决了。在 Snaps上,我们将继续与 MetaMask团队紧密合作(参见我们在 Devcon 5上的联合演示),让 StarkEx按照我们所描述的最佳方法工作。

提示:如果您觉得本文不错,请点击分享给您的好友!谢谢
相关推荐
新闻聚焦
猜你喜欢
热门推荐
 
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。