引介 | StarkEx 作为自主托管型方案，Part-3 & Part-4

引介 | 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 。这个方案需要投入非常有限的资源：或者将他们的数据放到链上，或者监控链下数据的进程（需要投入的资源远少于运营者）。我们将会发布新的文章来详细阐述这些概念。