Neo Live| Suterusu CTO 林煌:如何助力Neo开发Layer2隐私协议的解决方案

久违的Neo Live再次与大家见面啦!2020年的首期Neo Live,我们邀请到新伙伴 Suterusu 的 CTO 林煌,一起聊聊他们与Neo的深度技术合作「如何助力Neo开发Layer2隐私协议的解决方案」。

全程回顾本期Neo Live

以下是全场活动的文字版内容实录:

今天给大家介绍下Suter作为Neo Layer2 解决方案的架构。

如系统架构图所示,发送者将从他的钱包中选择NEO账户,并运行Fund智能合约,该合约将NEO转换为二层协议代币Suter。Fund合约将在主链网络上运行。

发件人通过运行CreateAddress创建一个Suter帐户,然后运行CreateFundTx算法来创建一个能运行Fund智能合约的交易,该交易将启动Fund智能合约,并在他的钱包中将NEO转换成Suter代币,然后将这些Suter代币转到新创建的Suter帐户中。

在NEO blockchain确认Fund合同后,将通过运行Suterusu匿名转账contract来匿名化对应Suter token,该合同将由Suter blockchain network确认。这里,Suter匿名转账contract将保证发送者和接收者的匿名性以及转让金额的保密性。发送者将通过运行CreateTransferTx来创建一个能触发Suter匿名转账contract的交易,即Transfer。

最后,Fund合同会将匿名的Suter token换回NEO,并将其存储在接收者的钱包中。发送者将运行CreateBurnTx交易以触发Burn contract,以将匿名化后的Suter帐户中的Suter token转换为接收者帐户中的NEO。

下面将介绍这些contract的细节以及各个用户算法与这些contract如何交互。

Suter支付框架

Suter支付框架主要包含以下三个智能合约,以实现智能合约平台的保密支付。

– Fund合约 –

任何人都可以通过指定公钥并转移一些NEO来为帐户注资。该合约将NEO转换为Suter。NEO被存储在智能合约中,而Suter将以同态的方式添加到y的余额中。如果该帐户尚不存在,该合约将会创建一个新帐户。该合同中的转账操作还附带有范围证明,以确保存款金额不超过Suter token的上限。

– Burn合约 –

Burn将Suter转换回NEO。它根据Fund声明的statement来验证Fund对应零知识证明,以确保发送者知道正确的私钥并burn了正确的金额。它还检查交易数据上的签名和计数器的当前值,以防止重放攻击。

– Transfer合约 –

通过此操作,可以在Suter blockchain中匿名转账Suter token。匿名转账对应零知识证明可确保密文具有正确的格式,并且发件人有足够的Suter token。

用户通过运行以下算法之一与智能合约交互。这些算法的输出是原始交易。它们将使用发送这些交易的NEO或者Suter帐户的私钥签名,并触发NEO或Suter blockchain的智能合约。

CreateAddress(sk,pk)为用户提供了一种向智能合约认证身份的方法。它以安全参数\ lambda作为输入,并输出一个私钥sk和相应的公钥pk。

CreateFundTx(pk,amt)向帐户添加资金,该算法的输入为公钥pk和金额amt。

CreateTransferTx(sk_ {from},pk_ {to},amt,st)将资金从一个帐户转到另一个帐户。它需要私钥sk_ {from},接收者公钥pk_ {to},转账金额amt以及某个特定block height h的智能合约的状态st 作为输入,最终输出tx_{trans}。(对于匿名转账,该算法还把匿名集合AnonSet作为输入,输入中还包括发送者和接收者的公钥。AnonSet也会包含在输出中。)

CreateBurnTx(sk,st)从帐户中提取全部余额。这个算法的输入是密钥sk和一个状态st。

ReadBalance(sk,st)读取帐户余额。该算法输入为密钥sk和状态st,输出整数b。

有关这些算法的更多详细信息,有兴趣的读者可以参考Suterusu黄皮书。请注意,发件人需要购买Suter token以支付匿名转账的费用。

我们在架构设计中还考虑了如何防止frontrunner攻击和重放攻击。

如何防止frontrunner攻击

这里描述下如何防止frontrunner攻击。当涉及到跨链功能时,这个是我们必须考虑的问题。Zether的论文提供了一个如何发起frontrunner攻击的详细案例:转账交易中的零知识证明需要证明余额为正。

用户Alice针对合约中以加密方式存储的金额为正的证明。但是,如果另一个用户Bob转移了一些ZTH到Alice,并且Bob的交易被blockchain network先处理,则Alice的交易将被拒绝,因为此时Alice账户余额由于Bob的操作而改变了,因此对应的零知识证明不再有效。请注意,Bob完全可能用心良好,而Alice却会因此失去了为处理交易而支付的gas费用。

为了解决frontrunner攻击,Suter框架将所有传入的transaction暂时保持为pending状态。系统时间分为多个周期,每个周期由k个连续的块组成。在每个周期结束时,未完成的转帐将被转入相应的帐户。预计用户将在一个周期开始时发布其transfer或burn交易。

然后,当收到来自该帐户的第一条消息时,我们会在一个时期内翻转一个帐户;因此,一条消息只会滚动到一个帐户。为了实现这一点,我们定义了一个单独的(内部)滚动方法,其他所有方法要做的第一件事就是调用该方法。

为了防止重放攻击,Suter框架具有另外一个重要功能:将帐户锁定到智能合约里。将一个随机数与每个Suter帐户相关联,该随机数将随该账户所处理交易数目增加而增加。来自帐户的新交易必须签署与该帐户关联的最新随机数以及交易数据(其中包括对应的零知识证明)。这种方法将交易的所有内容,包括随机数和零知识证明绑定起来,并确保freshness。因为攻击者无法在恶意交易中导入合法的零知识证明,也就无法实现重访攻击。

这个系统架构大概就是这样了。

Q&A问答环节

✔️ Suterusu最近在市场层面频繁的发声,是不是在技术上取得了领先的优势性的进展?

林煌目前我们密码模块和客户端基本已经调试完毕,现在在进行密码模块和区块链网络的对接,预计三月份测试网上线。

✔️ 作为Suterusu roadmap中的一环,与Neo这样的公链进行技术合作是目前比较重要的事情,Suterusu最终的定位和愿景是什么样的呢?项目最大的价值体现在什么地方?

林煌目前我们项目还是专注于做服务于公链的二层协议,一个能匿名化任何底层密码币的二层协议。短期来看我们为智能合约平台设计的匿名支付方案为各大公链生态系统提供一流的隐私保护服务,长期看我们希望能填补密码理论和隐私保护技术实践之间的鸿沟。

✔️ 匿名币在早期的加密社区就很受大家重视,门罗,大零,小零,和从去年开始比较火热的grin等等,林博士可以不可以深入浅出的为我们解释一下Suterusu Zk的核心优势点相较于其他的匿名币解决方案究竟优秀在哪里?

林煌目前的隐私币要不就需要可信初始化(如zcash),这将允许攻击者不被察觉的情况下发行不限量的zcash,要不然就可扩展性不强(如monero)。我们所提出的高效的保密支付方案能保证我们的隐私保护blockchain协议能在安全性和可扩展性之间获得最佳平衡,也就是既无需可信设置同时证明大小还是常数的。

另外,和大部分不提供智能合约功能的隐私币相比,suter的智能合约允许我们提供更为丰富的金融功能。另外,我们还提供了一个Suter虚拟机基于我们的zk-consnark提供各种隐私保护的服务,包括隐私保护的pos和匿名认证等。

✔️ 能不能简单说一下Suter虚拟机。

林煌Suter虚拟机是我们初步的设想,在我们zk-consnark在测试网测试运行靠谱以后,我们会在这上面着力多些。

另外,因为现在用户对隐私问题越来越重视,另外区块链中有很多隐私相关的问题亟待解决,所以我们相信这样一个专门针对隐私服务的虚拟机是有他的市场的。

✔️ 说回与公链合作,在技术层面之外,大家最关心的是,隐私协议+公链所能造就的应用场景是什么样的,除了转账这样的底层需求之外,林博士有没有观点想要分享一下?

林煌这个应用场景很多,因为区块链技术最主要的应用还是去中心化金融,而对于金融服务而言,因为涉及的数据极为敏感,隐私保护应该是个必要条件,所以这个问题解决好了,众多之前只能谈谈而已的应用场景比如dex什么的就有了可以落地的一个必要前提了。

✔️ 林博士可以简单介绍一下Suterusu的通证经济模型是如何设计和运作的吗?

林煌这个问题你可能得问Suterusu的首席经济学家郭大治老师,因为我本人不是经济学家,对这方面了解得也比较少。但我清楚我们的代币发行总量为100亿,而且是通缩模型。

✔️ 林博士对隐私与监管的平衡问题有什么看法?

林煌我觉得区块链现在还处于起步阶段,对于这种新生事物的监管,相信有关部门也正处于摸索阶段,这个应该会逐步成熟起来吧。

✔️ 林博士您提到为了防止frontRunner攻击,您使用了比较复杂的交易状态管理,但是为了防止重放,您又对交易编了号,我比较疑惑的是,为什么对交易编号本身为什么不能用来防止frontrunner呢?

林煌嗯?frontrunner主要和交易以及合约被执行次序有关,而交易编号是用来区分协议的freshness的,这两者应该是互不相关的,因为有可能被frontrun的协议和frontrun的协议都是fresh的。

✔️ 这个架构就是为了匿名转账设计出来的吗?

林煌主要是这个目的,但我们使用的零知识证明代码库可以扩展成通用的,这方面的研究工作我们一直在做,另外我们也会考虑做些针对零知识证明的ddl,以保证零知识证明协议的可用性。

✔️ 请问,Suter本身作为Layer2的解决方案,将来拓展到多条链的时候,是否有对不同类型的代币之间进行区分的机制?因为NEO在您的链上需要兑换成Suter,别的代币也会兑换成Suter,那在转账的时候,如何区分呢?

林煌这个问题很好,其实转账时候货币的所有权还是由对应Suter的私钥定义的,所以即使一堆的Suter在转账所有者还是清楚那一部分是自己的NEO转过来的。

换句话说只有你知道私钥的那部分Suter才真正是你的,这也符合整个加密货币的基本原则,私钥即所有权。

✔️ 那我拥有的那部分由NEO兑换来的Suter是否可以兑换成别的代币呢?入股我自己不可以,那我把Suter转给别人,别人是否可以自由兑换成任意的代币呢?

林煌那当然可以。

发表评论

Top