Decentralized finance has become a regulatory focus. How to decentralize the DeFi frontend?

This article is from Chain News, authored by Pan Zhixiong.

Last week, the development team behind the Uniswap protocol, Uniswap Labs, announced under regulatory pressure that it would review the official website front end and proactively delist tokens that pose regulatory risks, particularly "stock tokens," "stable value tokens backed by securities," and "virtual products that provide synthetic risks of underlying securities," such as the sTSLA token that tracks Tesla stock prices, which was recently "named" by SEC Chairman Gary Gensler.

The moment for regulation of "decentralization" has officially arrived, but does that mean "decentralization" has failed?

The answer may be negative. Because even if the Uniswap official website cannot facilitate trading of certain tokens, the Uniswap protocol itself remains "permissionless," which means that as a "protocol layer," it is still neutral, and users can still interact with the protocol itself to complete any necessary transactions.

To give a more extreme example, even if all front-end websites face regulatory risks in the future, as long as users run an Ethereum node, they can still conduct any transactions, provided there are enough miners.

However, this is still far from enough. Wouldn't it be better if the front end could also resist censorship? In fact, we already have some solutions.

The Common Situation of "Front-End Centralization" in DeFi Applications

Currently, many blockchain-based applications implement core business logic through smart contracts. For example, fund interactions in DeFi applications and asset calls in games or NFT markets need to be completed on-chain.

Business executed through smart contracts can ensure its decentralized characteristics, especially the ability to resist censorship and provide continuous, uninterrupted services. Any transaction can be executed securely and accurately, and the business will continue to run permanently on the blockchain. Only a small number of applications that have integrated censorship capabilities directly into their smart contracts are exceptions, such as the US dollar stablecoins USDT and USDC, which have blacklisted certain Ethereum addresses, but the vast majority of DeFi applications do not have this condition.

However, unlike the generally decentralized core logic, the vast majority of on-chain application front ends still widely adopt forms from the internet era, such as mobile apps or web pages. These web front ends not only assist users in submitting on-chain transactions but also have some purely front-end functions and positioning, such as whether the product is "user-friendly," and they can provide more display-layer functions to assist user decision-making (data, charts).

However, since the vast majority of web front ends are still implemented through traditional internet architecture, this has led to the emergence of the pain point of "front-end centralization," with typical components including domain names, network services, servers, and storage services, all of which can easily become targets for regulation.

Can the Front End Be Decentralized?

Of course, it can, but due to the need to consider "compatibility" with the current internet architecture, a small portion of centralized services will still be introduced to achieve a better user experience. However, with continuous upgrades to infrastructure, it is possible to achieve a balance between "completely decentralized front ends" and "better user experiences."

A simple example: although accessing app.uniswap.org no longer allows trading of XAUT, accessing uniswap.eth.link can submit on-chain transactions to exchange XAUT. (The Uniswap team stated that XAUT was banned due to a contract vulnerability.)

What is "uniswap.eth.link"?

In simple terms, it combines "decentralized domain ENS," "decentralized storage IPFS," and "centralized entry points" (such as Cloudflare or eth.link), allowing direct access to Uniswap's decentralized front end in all browsers.

The most core difference between the "decentralized front end" and the "centralized front end" is that the "decentralized version" can be deployed by anyone; it does not have a single node responsible for the deployment and maintenance of the page. These pages are shared by the network, which means they can provide resistance to censorship.

As for why "centralized entry points" (such as Cloudflare or eth.link) are included, it is because current web browsers have not yet natively supported the access capabilities of "decentralized domains" and "decentralized storage," so these centralized services can enhance the user experience for existing internet users.

However, some browsers have been working towards this field, gradually providing native access capabilities for decentralized services.

Components of a Decentralized Front End

If we draw an analogy with the existing internet, the decentralized version can also be divided into components such as browsers, domain names, storage, and computing.

Browser

Web browsers serve as the entry-level tools for users to access the internet, making them almost the most core application after the operating system. Most browsers adopt a multi-platform strategy to support as many users as possible, compatible with Linux, macOS, Windows, and even iOS and Android systems.

Of course, in a broader sense within the cryptocurrency field, cryptocurrency wallets are also browsers, as most wallets are not just private key managers but also entry points for various applications and services.

Among all web browsers, Opera and Brave provide the best support for decentralized services, with some platform versions already supporting native access to IPFS and ENS domains, and they will continue to expand to more platforms and services. Meanwhile, the more widely used Chrome and Firefox browsers also offer good adaptation capabilities thanks to their rich plugin ecosystems.

Decentralized Domains and Domain Resolution

Traditional domains provide a means of access service; for example, users know that accessing google.com in a browser will lead to Google's search service. However, this access capability is completely managed and maintained centrally by ICANN.

"Decentralized domain" services operate entirely within a decentralized network, allowing anyone to register domains fairly and without censorship. Therefore, blockchain is one solution for decentralized domains; for instance, from the early Namecoin onwards, many teams have begun attempts in this area.

Currently, the most widely used is the Ethereum Name Service (ENS) running on the Ethereum network. The registration, registration information, modification information, renewal, and other services of ENS domains are implemented through smart contracts on Ethereum. The chosen domain for ENS is ".eth," which is consistent with the Ethereum token symbol.

Since ENS data is stored on the Ethereum network, the safest way for browsers to read this data is through Ethereum full nodes. However, due to the slightly higher cost, the previously mentioned "centralized entry points" (such as Cloudflare or eth.link) help solve the experience issues for current Web2 users.

In other words, when browsers do not natively support ".eth" resolution capabilities, the ENS team purchased the traditional domain eth.link (which ordinary browsers can resolve) to resolve all eth domains.

Reference reading: "A Name Resolver for the Distributed Web"

This path is: any user ------> any browser ------> uniswap.eth.link ------> resources of uniswap.eth.

This path integrates with existing Web facilities through "centralized entry points." In addition to ENS, teams like Handshake, Unstoppable Domains, and DAS are also providing similar functionalities.

Of course, there is a possibility of removing "centralized entry points" in the future. One way is that more companies providing such services emerge (indirectly gaining resistance to censorship), and another way is that browsers can obtain this data through their own running Ethereum full nodes (directly gaining resistance to censorship).

Decentralized Storage and Computing

Storage and computing will gradually achieve decentralization, but for current decentralized applications, "decentralized storage" may be the most urgent, as lightweight computing can be handled by browsers.

In this field, IPFS is widely used because this protocol does not involve tokens and has no blockchain, making it purer than Filecoin. To ensure long-term and effective storage, solutions like Filecoin and Arweave can also be considered. Currently, the webpage resolved by uniswap.eth is stored in the IPFS network.

Reference reading: "Uniswap Interface + IPFS"

Currently, Opera and Brave have also implemented IPFS access capabilities through some cooperative "centralized entry points." However, running an IPFS service costs far less than running an Ethereum node, but the access speed still needs improvement, and at this stage, it still relies on "centralized entry points."

So to add: any user ------> any browser ------> uniswap.eth.link (via centralized service) ------> resources of uniswap.eth on IPFS (via centralized service).

These front-end web pages generally do not require a large amount of storage and network bandwidth, but if there is a future need for greater bandwidth to provide more types of services, it can also be achieved through services like Meson or Theta.

As for heavy "decentralized computing," there are currently some solutions available, such as those provided by DFINITY's "Internet Computer," GOLEM, etc., but they are still in the early stages.

Other Solutions?

The above solutions are sufficient to combine into some decentralized web front ends. In addition to Uniswap.eth, many Ethereum DeFi applications like Synthetix (synthex.snx.eth) have also deployed decentralized front-end versions to achieve resistance to censorship.

Besides this set of solutions, there are actually other solutions, such as full-stack DFINITY, which implements a complete set of services from blockchain, transactions, to servers, but these solutions are still in earlier stages.

For existing teams, combining components like ENS and IPFS can achieve front-end decentralization more quickly, addressing the urgent issues at hand.

Of course, regulatory pressure may continue to strengthen, and it is unclear what other measures may be used in the future. Perhaps, as long as the pace of innovation is a bit faster, regulation will only be able to respond relatively slowly.