Uniswap Incident | Decentralized Finance Moves into Regulatory Spotlight, How to Maintain Decentralization at the Frontend of DeFi?

share
Uniswap Incident | Decentralized Finance Moves into Regulatory Spotlight, How to Maintain Decentralization at the Frontend of DeFi?

Smart contracts running on the blockchain can provide censorship resistance and continuous operation capabilities, but how can users ensure that the front-end experience also offers the same decentralized features before accessing these smart contracts?

(This article is authorized to be reprinted from Chain News. The original title is "Decentralized Finance Becomes a Regulatory Focus, How to Decentralize DeFi Front-End?" Original article here)

Last week, Uniswap Labs, the development team behind the Uniswap protocol, under regulatory pressure, announced the review of the official website's front end and proactively delisted tokens with regulatory risks, especially tokens like sTSLA that track Tesla stock prices, which were recently "named" by the U.S. SEC Chairman Gary Gensler as "stock tokens," "securities-backed stable value tokens," and "virtual products providing underlying securities synthetic risks."

Advertisement - Continue scrolling down for more content

With the "decentralized" regulatory moment officially arriving, does "decentralization" fail as a result?

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

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

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

1. The prevalence of "front-end centralization" in DeFi applications

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

Businesses executed through smart contracts can ensure their decentralized characteristics, especially in terms of resistance to censorship and the ability to provide continuous uninterrupted services, where any transaction can be securely executed, and the business will continue to run permanently on the blockchain. Only a few applications that directly integrate censorship capabilities into smart contracts are exceptions, such as the stablecoins USDT and USDC, which have blacklisted some Ethereum addresses, but the vast majority of DeFi applications do not have this feature.

However, unlike the widespread decentralization of core logic, the front-end presentation of most on-chain applications currently still widely adopts forms from the era of 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 can provide more display functions to assist user decision-making (data, charts).

However, as most web front-ends are still implemented through traditional internet architecture, this leads to the emergence of the pain point of "front-end centralization," with the most typical components being domain names, web services, servers, storage services, etc., which are easily subject to regulation.

2. 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 part of centralized services will still be introduced to achieve a better user experience. However, with the continuous upgrading of infrastructure, it is possible to achieve a balance between a "completely decentralized front-end" and "better user experience."

For example, although currently accessing app.uniswap.org cannot trade XAUT, accessing uniswap.eth.link can submit XAUT exchange transactions on-chain. (The Uniswap team stated that XAUT was banned due to contract vulnerabilities.)

3. What is "uniswap.eth.link"?

In simple terms, it combines "decentralized domain name ENS," "decentralized storage IPFS," and "centralized access points (Cloudflare or eth.link, etc.)," enabling direct access to the decentralized version of the Uniswap front-end in all browsers.

The core difference between the "decentralized version" and the "centralized version" of the front-end lies in the fact that the "decentralized version" can be deployed by anyone, without a single node responsible for the deployment and maintenance of the page. These pages are publicly accessible, which also means they can provide censorship resistance.

As for why to include "centralized access points (Cloudflare or eth.link, etc.)," it is because current web browsers do not natively support "decentralized domains" and "decentralized storage" access capabilities, so these centralized services can enhance the user experience for existing web users.

However, some browsers have been striving in this area, gradually providing native access capabilities for decentralized services.

4. Components of a decentralized front-end

If we use existing internet analogies, decentralized versions can also be divided into components such as browsers, domain names, storage, and computation.

Browsers

Web browsers are essential tools for users to access the internet, and they are almost as critical as operating systems. Most browsers adopt a multi-platform strategy to support as many users as possible, including Linux, macOS, Windows, and even iOS and Android systems.

From a broader perspective in the cryptocurrency field, cryptocurrency wallets are also browsers because most wallets are not just private key managers but also gateways to various applications and services.

Among all web browsers, Opera and Brave have the best support for decentralized services. Some platform versions of these browsers already support native access to IPFS and ENS domains, and they will continue to expand to more platforms and services. Chrome and Firefox, with larger user bases, provide better adaptability through rich plugin ecosystems.

Decentralized domain names and domain resolution

Traditional domain names provide access service capabilities, such as users knowing that visiting google.com in a browser will access Google's search service. However, this access capability is completely centrally managed and maintained by ICANN.

On the other hand, "decentralized domain name" services run the domain completely in a decentralized network, where anyone can register a domain fairly and without censorship. Therefore, blockchain is a solution for decentralized domain names, starting from the earliest Namecoin, where many teams began attempts in this area.

The most widely used currently is the "Ethereum Name Service" (ENS) running on the Ethereum network. The registration, registration information, information changes, renewals, etc., of ENS domains are all implemented through smart contracts on Ethereum.

ENS chooses the domain name ".eth," consistent with Ethereum's token symbol.

Since ENS data is stored on the Ethereum network, the safest way for browsers to read this data is through an Ethereum full node. However, due to the slightly higher cost, the "centralized access points (Cloudflare or eth.link, etc.)" mentioned earlier help solve the experience problem for current Web2 users.

That is, when browsers do not natively support ".eth" resolution, the eth.link domain purchased by the ENS team (which can be resolved by ordinary browsers) can resolve all eth domains.

Reference: "A Name Resolver for the Distributed Web"

https://blog.cloudflare.com/cloudflare-distributed-web-resolver/

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

This path, through the "centralized access point," integrates with existing Web infrastructure. In addition to ENS, teams like Handshake, Unstoppable Domains, DAS, etc., are also providing similar functionalities.

Of course, it is possible in the future to remove the "centralized access points." One way is for more companies to provide such services (indirectly gaining censorship resistance), and another way is for browsers to obtain this data through their own running Ethereum full nodes (directly gaining censorship resistance).

Decentralized storage and computation

Storage and computation will also gradually become decentralized. For current decentralized applications, "decentralized storage" may be the most urgent, as lightweight computation can be handled by browsers.

In this field, IPFS is widely used because this protocol is entirely tokenless and blockchain-less, purer than Filecoin. To ensure long-term and effective storage, solutions like Filecoin and Arweave can also be considered. Currently, the web page resolved by uniswap.eth is stored on the IPFS network.

Reference: "Uniswap Interface + IPFS"

https://uniswap.org/blog/ipfs-uniswap-interface/

Opera and Brave have also implemented IPFS access capabilities through some collaborative "centralized access points." However, running an IPFS service costs much less than running an Ethereum node, but access speed still needs improvement, so currently, reliance on "centralized access points" is still necessary.

So, to add on: any user -> any browser -> uniswap.eth.link (implemented through centralized services) -> resources of uniswap.eth on IPFS (implemented through centralized services).

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

For heavy "decentralized computation," there are currently some solutions, such as DFINITY's "Internet Computer," GOLEM, etc., but they are still in the early stages.

5. Other solutions?

These solutions are sufficient to combine into some decentralized web front-ends. Apart from Uniswap.eth, many Ethereum DeFi applications, such as Synthetix (synthex.snx.eth), have also deployed decentralized front-end versions that can be used for censorship resistance.

Aside from these solutions, there are actually other solutions, such as full-stack DFINITY, which provides a full set of services from blockchain, transactions, servers, etc., but these solutions are still in earlier stages.

For existing teams, by combining components such as ENS, IPFS, etc., they can quickly achieve decentralized front-ends to address the urgent needs at hand.

Of course, regulatory efforts may continue to strengthen, and it is unclear what other means can be used in the future. Perhaps, as long as the pace of innovation is faster, regulation will only be relatively slower.