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

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

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

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

简介：常见 DeFi 的架构

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

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

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

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

方案一：Uniswap 的 IPFS 的方案

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

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

从用户视角来说来说，当他们在登录 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。

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

运行 canister

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

提交 Commit 更改

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

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

当我们再一次同步 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 之间的交互是直接的，这些行为都会被完整的记录下来。

两种方案的对比与启示

这张表格梳理了两种方案架构上的优劣，可以发现 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》

来源：

创业不易，用心坚持，希望您多多支持！

打赏

感谢您的支持，我会继续努力的!

扫码打赏

打开支付宝扫一扫，即可进行扫码打赏哦