1. 首页
  2. 区块链资讯

引介 | StarkEx作为自主托管型方案

作者:  StarkWare

翻译&校对:闵敏 &阿剑

引介 | StarkEx 作为自主托管型方案,Part-1:弁言

引介 | StarkEx 作为自主托管型方案,Part-2:合约可升级性

Part-3:钱包支持

StarkEx 是一种自主托管式可扩展性引擎。我们已经先容过了自主托管式系统的各个方面,其中就包罗钱包。本文将要先容我们是若何与差别的钱包提供商互助,来确保 StarkEx 保持自主托管型系统的本色。

自主托管型系统的一大主要特征是,每次交互都需要用户署名。我们的主要原则是 “不只要署名,还要验证它。”—— 这是套用的区块链行业的老话:“不要信赖它,去验证它。” 换言之,要是用户不能验证,自主托管型系统只是徒有其名而已。用户要能够验证他们的钱包和自主托管型应用之间所举行的交互的参数。例如,若是一名用户向链上合约提供了署名,ta 的钱包显示的应该是经由优越剖析的可读新闻,而非一团高深莫测的数据。在用户需要签署链下买卖的时刻,二层应用也应遵照同样的原则。

为了恪守 “不只要署名,还要验证它” 这一原则,我们正在与多个钱包提供商互助,将我们的协议直接整合进他们的产物内。这一整合对零知识证实系统来说尤为主要。为了高效地验证署名,零知识证实二层系统所使用的曲线通常差别于尺度的以太坊曲线,使用的哈希函数也差别。一种简朴的方式是在浏览器中实现钱包。我们倾向于不这么做,主要有两点缘故原由:首先,StarkEx 的目的是让用户可以直接通过钱包在专业的买卖平台中买卖,无需再将资金转移到其他地方;第二,构建一个平安的钱包并非易事(路印最近被曝出的高危前端破绽就是一个很好的例子)。

下文列出了停止 2020 年 5 月支持 StarkEx 的钱包。

Ledger :完全整合

Ledger 是完全整合 StarkEx 的。无论是链上合约挪用照样链下订单提交,每一次交互都将由 Ledger 剖析,然后向用户显示。用户要先确认事后才能在 Ledger 中署名。用户将能验证每一次交互的参数。此外,Ledger 将在其原生以太坊应用中支持 StarkEx (用户甚至不需要通过 Ledger Live 安装特定的应用)。

为了整合 StarkEx ,我们必须将 STARK 专用曲线添加到 Ledger 的固件中 ,并在 Ledger 的应用中执行 StarkWare 的哈希函数(Pedersen 哈希函数)。通过 StarkWare 和 Ledger 的紧密结合,Ledger 成了首个应用于二层的硬件钱包。

WalletConnect:完全整合

WalletConnect 是完全整合 StarkEx 的。WalletConnect 是一个开放式协议,(通过二维码)将桌面应用连接到使用端到端加密手艺的移动钱包。我们与 Pedro Gomes 一起实现了 StarkEx 交互,创建了 StarkEx WalletConnect Provider 。DeversiFi 是首个构建在 StarkEx 上的自主托管型买卖所,也将 WalletConnect 整合进了它的应用中。移动钱包 Argent 现在正在整合 StarkEx WalletConnect Provider ,很快就会支持用户在 DeversiFi 上举行自主托管型买卖。

MetaMask:夹杂解决方案

现在,我们为 MetaMask 用户提供夹杂解决方案。所有链上买卖都将由 MetaMask 处置,所有链下买卖都将由浏览器内置钱包(第一种就是 DeversiFi 的钱包)处置。这一解决方案与现在绝大多数二层方案相同,而且可以让我们立刻支持 MetaMask 重大的基础用户。这一方案现在还做不到上面几个方案那样完善:用户既不能验证链上合约挪用,也不能验证他们的链下买卖。一旦 MetaMask 部署好 Snaps 插件系统,这一问题就能得到解决。我们将继续作为 Snaps 上的 Design Partner (设计同伴)与 MetaMask 团队密切协作(参见我们在 Devcon 5 上的团结演示),让 StarkEx 像我们所形貌的最优方式那样为 MetaMask 用户提供服务。

Part-4:链下数据可用性

动因

StarkEx 是一种自主托管式可扩展性引擎。这已经是我们的《StarkEx 作为自主托管型方案》系列的第四篇也是最后一篇文章了。本文将要先容 StarkEx 这个自主托管型系统的最后一部分内容:数据可用性方案的部署以及它将若何引领我们走向加倍免信托的未来。

比特币通过第一次压力测试,摩根大通完成了比特币转型

在公开批评比特币多年之后,摩根大通对比特币的态度已经发生完全转变。

我们先来回首一下知识点。在 StarkEx 中,买卖是批量处置的,然后在链下验证,并天生一个 STARK 证实。我们将这一历程称为有用状态转换。这个证实会和系统新状态的答应一起被发送到区块链上,然后由区块链验证证实并存储答应。批量买卖的数据存储在链下或链上皆可。若是选择链上数据可用性,买卖就会被记录成挪用数据(calldata)。若是选择链下数据可用性,买卖就会被记录在链下。链下数据可用性更具可扩展性:无论 StarkEx 上有若干流动,消耗的区块链资源都是牢固的。

首个部署完成的 StarkEx —— 用于支持 DeversiFi 去中央化买卖所 —— 将选择链下数据可用性。DeversiFi 之所以做出这样的选择,一方面是由于可扩展性优势,另一方面是由于这会为其用户提供更好的隐私性,可以辅助用户隐藏其买卖计谋。因此,想要接见自己账户余额的用户可以从 StarkEx 运营者处获得:应用运营者(Application Operator)和证实运营者(Proof Operator)(在首个部署完成的 StarkEx 项目中,这两个角色分别由 DeversiFi 和 StarkWare 担任)。要验证自己的账户在某个时刻的状态时,用户可以凭据自己账户在相关默克尔树上的默克尔路径完成验证。关于用户对运营者的信托,需要注重的一点是:用户不需要基于对运营者的信托来信赖系统状态是有用的,由于状态转换的有用性是由 STARK 证据来保证的。用户只需信赖运营者会实现数据可用性即可。

数据有用性委员会(DAC)

为了让用户完全不需要信托 StarkEx 运营者,我们已经组建了数据有用性委员会(DAC)。DAC 成员的职责是保留链下数据的副本,并在紧要情形下将这些副本放回公共域。紧要情形指的是 StarkEx 运营者不响应用户提款要求的情形。在紧要情形下,应用智能合约(ASC)将不再接受新的状态更新,而是只允许能够提供最新状态的默克尔证实的用户直接取款。

DAC 成员的职责

在正常情形下

吸收每一次状态转换,盘算新的状态,签署新状态的答应为链下数据保留私密且平安的副本

只有当签署对应的状态答应的 DAC 成员到达一定数目之后,ASC 才会接受 STARK 证实。

在紧要情形下

将它们保留的数据副本公然。在这种情形下,用户可以接见通往他们账户的默克尔证实,使用这条证实直接从 ASC 那里取回他们的资金,完全不需要信托运营者。

通往未来之路

我们以为,将对 DAC 的信托最小化是异常主要的。

首先,我们计划将 DAC 存储的数据加密,以此确保 DAC 成员不再掌握任何有关 StarkEx 用户的数据。加密可以确保委员会成员不会透露敏感信息,从而削减他们的责任,也可以免去用户对他们的信托。因此,加密可以让 StarkWare 大幅增添委员会的人数,从而削减在紧要情形下对个体成员履行职责的依赖。

之后,我们将实现一个完全免信托的方案,可以让相关方完全不需要信托 DAC 。这个方案需要投入异常有限的资源:或者将他们的数据放到链上,或者监控链下数据的历程(需要投入的资源远少于运营者)。我们将会公布新的文章来详细论述这些观点。

(完)

(文内有许多超链接,可点击左下 ”阅读原文“ 从 EthFans 网站上获取)

原文链接:

[1]: https://medium.com/starkware/wallets-c5a9c4e35c02

[2]: https://medium.com/starkware/data-availability-e5564c416424

原创文章,作者:链大大,如若转载,请注明出处:http://www.chaindada.com/chain/5172.html