通过比较发现 IPFS 是短期方案,ICP 更有利于长期的布局,并且更有利于实现前端自身商业变现。

原文标题:《两方案看 Dapp 如何应对前端托管的风险》
撰文:Yolo
来源:大脑杆菌

我们都知道常见的 DeFi 应用一般都采用三层架构,前端-中间件-后端(智能合约),而这个三层架构当中只有后端是部署在区块链上,一经部署不可更改。而前端和中间件都是部署在中心化的服务器上,这也意味着前端和中间件这些衍生的结构容易受到攻击和作恶。

简介:常见 DeFi 的架构

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

当我们使用 DeFi 应用的时候,各个环节是如何协作的呢?图上所示的是一个正常网络环境下的调用。当我们输入{website}的时候,用户的游览器会访问 DNS 服务器,去查询{website}对应的 IP。查到这个 IP 之后,对面 DNS 服务器会返回 IP 地址,游览器会再次根据 IP 地址去寻找 web 服务器。一般来说,我们的网址所需要的图片,文字,交互等内容会放在 web 服务器上(可能是真的物理服务器,也可能是云)游览器读到这些信息之后就会返回呈现给用户。之后用户的点击,都会经由游览器,Web 服务器,去和链上的智能合约进行交互。经过用户的签名之后,行为会经由共识机制和链上广播,变成可信的状态。

那么这个过程之中,项目和用户分别存在什么风险呢?

  • 托管平台的干预。早年应用部署在单个服务器上,单一服务器的物理状态成为风险之一。随着技术成熟,云逐渐出现,通过将计算分布在大量分布式计算机上,避免了单一服务器的物理风险。但是目前这种技术的仍然存在风险,这种风险就是云平台作恶的风险,前端的数据信息暴露在 big-tech 的视野之下,无从躲避。
  • 偷换前端。目前来看,大多数项目都会开源前端代码让用户独立审查,用户下载前端代码在本地运行之后,便可自行与托管在区块链上的智能合约进行交互。通过这一流程,用户可以评估前端的风险。但是由于实际前端仍然托管在中心化的服务器上,用户很难验证公开前端是否就是目前正在运行中的前端,前端仍然存在偷梁换柱的可能。举例来讲,正常前端连接到官方的智能合约,而恶意前端就可能连接到恶意合约,通过用户授权对用户造成伤害。

为了应对上述两类风险,市场上看到了一些实践,主要是 Uniswap 的 IPFS 方案和 Liquity 的 ICP 方案。

方案一:Uniswap 的 IPFS 的方案

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

Uniswap 直接将前端部署上 IPFS,他们具体是怎么做的呢?

  • 前端文件存放于 Github,通过 Github Action 向 IPFS 部署,每天至少一次。
  • 通过 pinata.cloud 用户的游览器可以获取前端的页面。

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

从用户视角来说来说,当他们在登录 Uniswap 的时候,互联网到底发生了什么呢?用户登录 app.uniswap.org,游览器查看 DNS 记录找到了前往 cloudflare-ipfs.com 的 CNAME,再通过 Cloudflare’s IPFS gateway 的云网关,查询 DNSLink record,找到存放在 IPFS 上的 hash 码,最终通过 hash 码获取前端的文件。

方案二:Liquity 的 ICP 方案

Liquity 是以太坊上的抵押型算法稳定币,该 DApp 拥有一个非常有趣的特性:开放式前端。开放式前端,指的是不同的前端运营商可以独立运行前端,并且设置自己的 kickrate (kickrate 会调节用户所得到的相关收入和奖励,如果 kickrate=99%,意味客户拿到 99%,前端拿到 1%)

在结构上,Liquity 分为前端界面和后端智能合约,在商业上,Liquity 也将由前端运营商和后端智能合约开发商,分开运作。Waterslide 是 Liquity 的前端运营商之一,也是第一个部署在 Dfinity 上的 DeFi 前端,下面介绍的实践主要来自于 Waterslide。

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

ICP 方案当中前端应用的主体身份是根据域名来的。也就是说域名和 Canister 的内容是永远联系在一起的,这一点适合传统互联网截然不同的。当项目组创造了自己 Canister,并将前端页面所需要的的文件托管在 canister 中,caniser 就会被分配特定的域名,用户会直接通过 DNS 访问特定域名 https://{website}.ic0.app (什么是 Canister?可以理解为分布式 Docker,详细细节可以参考)也因此用户和前端页面通过 Dfinity 紧紧地联系在了一起。那么具体 Canister 具体是怎么运行前端的呢?

运行 canister

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

运行 canister 的时候,系统会显示两个 Controller 和 Module hash,前者是治理容器对于运行容器管理的 ID,这个码一般情况是不可更改的,除非向治理结点提出提案;后者,是每一次 Wasm 部署完后的证明。

提交 Commit 更改

运行 Canister 以后,我们会需要升级,但这种升级是需要 NNS 来进行审批的。(NNS 可以简单理解为子网的创建者,他将管理整个网络的事务。详细参考 《完整解析 | 网络神经系统(NNS)是怎么运行的》 )我们会将所需更新的文件同步到 github,并将 Canister 更新的申请提交到 NNS 当中,申请文件当中包含几个要素:Commit ID,Controller,Module hash,Repo 的位置。

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

bd51eab 就是我们 Commit 的代码,NNS 的治理 Canister 会根据我们的 proposal 对 Canister 进行升级。

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

当我们再一次同步 canister 的时候,会发现 tag: mainnet-20210527T2203Z,这与我们提交的 Proposal 号相一致,也就证明 NNS 已经对我们的 proposal 已经进行了升级。

用户是如何连接到前端的?

Waterslide 网站前端托管在 Canister 之中,用户输入网址以后,通过 DNS 服务器会连接到 https://{specific}.ic0.app. 然后这个域名会通过 Certifying Service Worker 提供的 Controller (如 'rdmx6-jaaaa-aaaaa-aaadq-cai') 连接到对应的 Canister,那么也就读取到了 Canister 当中的网页文件。用户与 Canister 之间的交互是直接的,这些行为都会被完整的记录下来。

两种方案的对比与启示

DeFi 如何应对前端托管风险?了解 ICP 与 IPFS 托管方案

这张表格梳理了两种方案架构上的优劣,可以发现 IPFS 是短期方案,而 ICP 更有利于长期的布局。而在商业上,ICP 更有利于前端自身的商业变现,如果我们过去将 DeFi 后端智能合约等价于 DeFi,那么随着 ICP 的成熟,将使得前端运营成为独立于后端智能合约的另一股力量。为什么那么说呢?因为 ICP 将用户和前端页面之间的价值流可信化了。不可造假的流量和交互,成为了资产定价的重要基础,这也将大大提升前端页面的玩法和创造力。结合 Dfinity 和 ETH 的交互,价值层归价值层,应用层归应用层(参考 《ICP 与 ETH 互操作的原理与启示 》 )这将会为我们带来无穷的想象空间。

Tips: 截止目前为止,ICP 本身的容器并不能记录自身历史的数据,但是官方(nomeata 语)有意愿创建一个可以记录 wasm 部署 hash 的 Canister,这样一来就可以针对不可信主体提供可信的历史记录

从 ICP 论坛当中的沟通来看,目前 ICP 整体的开发任务量仍然很大。目前 Proposal 的处理感觉仍较为简陋。

参考材料:

《什麼是 DNS?》

《waterslide – the first DeFi Frontend running on DFINITY's Internet Computer》

https://www.reddit.com/r/dfinity/comments/n1xosf/value_proposition_in_comparison_to_market_leaders/

《The DeFi Stack》