How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

Loading

Through comparison, it is found that IPFS is a short-term solution, and ICP is more conducive to the long-term layout and is more conducive to realizing the front-end business realization.

Original title: “Two plans to see how Dapp responds to the risks of front-end hosting”
Written by: Yolo
Source: Cerebrobacter

We all know that common DeFi applications generally adopt a three-tier architecture, front-end-middleware-back-end (smart contract), and in this three-tier architecture, only the back-end is deployed on the blockchain and cannot be changed once deployed. The front-end and middleware are deployed on centralized servers, which also means that the derivative structures of the front-end and middleware are vulnerable to attacks and evil.

Introduction: Common DeFi architecture

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

When we use DeFi applications, how do all the links work together? Shown in the figure is a call under a normal network environment. When we enter {website}, the user’s browser will access the DNS server to query the IP corresponding to {website}. After finding this IP, the opposite DNS server will return the IP address, and the browser will find the web server again based on the IP address. Generally speaking, the pictures, text, interactions and other content required by our website will be placed on the web server (may be a real physical server, or it may be a cloud). After the browser reads the information, it will return and present it to the user. After the user clicks, they will interact with the smart contract on the chain via the browser and web server. After the user’s signature, the behavior will become a credible state through the consensus mechanism and broadcast on the chain.

So in this process, what are the risks of the project and the user respectively?

  • Intervention of the hosting platform. In the early years, applications were deployed on a single server, and the physical state of a single server became one of the risks. As the technology matures, the cloud gradually emerges, and the physical risk of a single server is avoided by distributing calculations on a large number of distributed computers. However, there are still risks in this technology. This risk is the risk of evil on the cloud platform. The front-end data and information are exposed to the vision of big-tech and cannot be avoided.
  • Secretly change the front end. At present, most projects will open source front-end code for users to independently review. After users download the front-end code and run it locally, they can interact with the smart contract hosted on the blockchain by themselves. Through this process, users can assess the front-end risks. However, since the actual front-end is still hosted on a centralized server, it is difficult for users to verify whether the public front-end is the currently running front-end, and the front-end may still be replaced. For example, the normal front end is connected to the official smart contract, while the malicious front end may be connected to the malicious contract, causing harm to the user through user authorization.

In order to cope with the above two types of risks, some practices have been seen in the market, mainly Uniswap’s IPFS scheme and Liquity’s ICP scheme.

Option 1: Uniswap’s IPFS solution

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

Uniswap directly deploys the front-end to IPFS, how did they do it?

  • The front-end files are stored in Github and deployed to IPFS through Github Action, at least once a day.
  • The front-end page can be obtained through pinata.cloud user’s browser.

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

From the user’s perspective, what happened to the Internet when they logged in to Uniswap? The user logs in to app.uniswap.org, the browser checks the DNS record and finds the CNAME to cloudflare-ipfs.com, and then through the cloud gateway of Cloudflare’s IPFS gateway, query DNSLink record, find the hash code stored on IPFS, and finally pass the hash code Get the front-end file.

Option 2: Liquity’s ICP solution

Liquity is a mortgage-based algorithmic stablecoin on Ethereum. This DApp has a very interesting feature: an open front end. Open front-end means that different front-end operators can run the front-end independently and set their own kickrate (kickrate will adjust the related income and rewards received by users. If kickrate=99%, it means that the customer gets 99%, and the front-end gets it. To 1%)

Structurally, Liquity is divided into front-end interface and back-end smart contract. In business, Liquity will also be operated separately by front-end operators and back-end smart contract developers. Waterslide is one of Liquity’s front-end operators and the first DeFi front-end deployed on Dfinity. The practices described below are mainly from Waterslide.

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

The subject identity of the front-end application in the ICP scheme is based on the domain name. In other words, the domain name and the content of Canister are always linked together, which is completely different from the traditional Internet. When the project team creates its own Canister and hosts the files needed for the front-end page in the canister, the caniser will be assigned a specific domain name, and the user will directly access the specific domain name https://{website}.ic0.app through DNS (What is Canister? It can be understood as distributed Docker, and you can refer to it for details.) Therefore, users and front-end pages are closely linked through Dfinity. So how exactly does Canister run the front end?

Run canister

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

When running canister, the system will display two Controller and Module hash. The former is the ID of the governance container for running container management. This code is generally unchangeable unless a proposal is made to the governance node; the latter is every Wasm Proof after deployment.

Commit changes

After running Canister, we will need to upgrade, but this upgrade requires NNS to approve. (NNS can be simply understood as the creator of the subnet, who will manage the affairs of the entire network. For details, refer to “Complete Analysis | How Network Neural System (NNS) Works” ) We will synchronize the files that need to be updated to github, And submit the Canister update application to NNS. The application file contains several elements: Commit ID, Controller, Module hash, and Repo location.

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

bd51eab is our Commit code, NNS governance Canister will upgrade Canister according to our proposal.

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

When we synchronize the canister again, we will find tag: mainnet-20210527T2203Z, which is consistent with the proposal number we submitted, which proves that NNS has already upgraded our proposal.

How do users connect to the front end?

The front end of the Waterslide website is hosted in Canister. After the user enters the URL, it will be connected to https://{specific}.ic0.app through the DNS server. Then this domain name will be passed through the Controller provided by the Certifying Service Worker (such as’rdmx6-jaaaa- aaaaa-aaadq-cai’) connect to the corresponding Canister, then the web file in Canister will be read. The interaction between the user and Canister is direct, and these behaviors will be fully recorded.

Comparison and enlightenment of the two schemes

How does DeFi deal with front-end hosting risks? Understand ICP and IPFS hosting solutions

This table sorts out the advantages and disadvantages of the two schemes. It can be found that IPFS is a short-term scheme, and ICP is more conducive to long-term layout. In business, ICP is more conducive to the commercial realization of the front-end itself. If we used DeFi back-end smart contracts to be equivalent to DeFi, then as ICP matures, front-end operations will become another independent of back-end smart contracts. Power. Why do you say that? Because ICP credible the value flow between users and front-end pages. Non-fake traffic and interaction have become an important basis for asset pricing, which will also greatly enhance the gameplay and creativity of the front-end page. Combining the interaction between Dfinity and ETH, the value layer belongs to the value layer, and the application layer belongs to the application layer (refer to “Principles and Enlightenment of ICP and ETH Interoperability” ), which will bring us endless imagination.

Tips: As of now, the ICP’s own container cannot record its own historical data, but the official (nomeata language) is willing to create a Canister that can record wasm deployment hash, so that it can provide a credible history for untrusted subjects recording

Judging from the communication in the ICP forum, the current overall ICP development task is still very large. At present, the handling of Proposal still feels relatively rudimentary.

References:

“What is 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”

Disclaimer: As a blockchain information platform, the articles published on this site only represent the author’s personal views, and have nothing to do with the position of ChainNews. The information, opinions, etc. in the article are for reference only, and are not intended as or regarded as actual investment advice.