引介

StarkEx 作为自主托管型方案,Part-4:链下数据可用性

Ajian   |     |   601 次阅读

StarkEx 作为自主托管型方案,Part-1:引言
StarkEx 作为自主托管型方案,Part-2:合约可升级性
StarkEx 作为自主托管型方案,Part-3:钱包整合


动因

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

(完)


原文链接: https://medium.com/starkware/data-availability-e5564c416424
作者: StarkWare
翻译&校对: 闵敏 & 阿剑

 
0 人喜欢