跳至主要内容

1 篇文章 含有標籤「computer system design」

檢視所有標籤

· 閱讀時間約 7 分鐘
J.

banner

Hello friends and fellows of Chia, welcome back to another post from Hashgreen! It's been a while since we had an update. Please forgive us for not having as many updates recently, as the development of Hashgreen DEX has come to the point where we think current features should suffice for over-the-counter (OTC) trading purposes. What follows consecutively is the development of the first ever AMM in Chia that is currently underway. We believe the ability to trade at will independently from counter-parties is a critical primitive of on-chain decentralized finance.

In today's blog, looking back from the experience of launching Hashgreen DEX to the construction of AMM, we are going to walk you through the landscape of the existing development in Chia and introduce an easier development in which the services could function in a more responsive and scalable manner to meet the needs of both end users and developers.

The current development in Chia

There are many existing dApps around the concept of a peer-to-peer trading protocol called “Offers” now. While it is decentralized and secure, the wallet is responsible for, other than just storing your private keys securely, managing these transactions/trades against peers and tracking their statuses on the blockchain by continuously pulling data from full nodes and verifying them.

Below is a figure showing the general picture of the system design that are commonly seen in Chia:

Figure: The current development in Chia.

The system, at a brief glance, looks reasonable and works reasonably well: dApps and wallets independently communicate and interact with the blockchain, processing users' transaction requests. Together they support an array of functionalities, including but are not limited to smart contract ("smart coins" in Chia's case) management, transaction activity management, and analyses of the blockchain. Smart coin management ensures the states in which users are trying to change are up to date on the blockchain and hence the transactions are valid when submitted; activity management and chain analysis are means to ensure, while complicated operations are behind the scenes, users can rest assured and observe high-level abstraction of their own activities as seen below.

Figure: Transaction activities displayed in the wallet.

Yet, current dApps (and other dApps on the way) are replicating an overlapping set of logic with the wallet underneath, performing smart coin management and blockchain analysis parallel to the wallet. In a simpler sense, dApps have to spend resources to set up their infrastructure (i.e. Chia full nodes) to deal with the abundance of activities on-chain. This creates two problems:

  • Functionalities are very entangled that transactions may go through either the dApp's own infrastructure, or through wallet's infrastructure. This trilateral relationship is unfavored in computer system design as it ambiguates the responsibilities and roles of dApps and wallets.

  • Development effort of dApps is high owing to the nature of the complexity of blockchain node deployment. The need for a dedicated infrastructure unavoidably creates an incredible entry barrier for blockchain enthusiasts, whose desire is no more than a backend-less web3 application. We all agree this would hinder the ability for the Chia community to grow rapidly.

We have not even mentioned that current Chia wallets (including official PC wallets and browser extension wallets) have spent so much effort dissecting the whole blockchain simply to locate your transaction in the ocean of activities. This burns away much computational power and energy from your computer, and it bears asking if we can find a better design that hits two birds with one stonemaking dApps easier to develop and allowing wallet to offload most of the heavy lifting.

Web3 does not have to be inefficient

dApps or wallets do not necessarily have to deal with all the nuisances. We can build a supporting system for web3 projects to allow them to read from and write to the blockchain with APIs (application programming interface). The idea is that blockchain in itself does not require everyone to trustlessly maintain a replica of the chain, but rather, one should be able to fetch and verify any piece of information from the chain. With that in mind, users on the edge can save their precious computation power and device pattern if they choose so, accessing the web3 world through this supporting system.

Let me explain to you why and how exactly does having such a service, or a trusted gateway system to the blockchain, could improve the scalability of the system and thus provide a real-time experience to the end users.

A lightly trusted gateway to the blockchain

Figure: What the development would look like if we apply the gateway system.

A trusted gateway system to the blockchain is structurally decentralized in its backend and it provides endpoints users can call to execute their web3 business via APIs. It interacts with the blockchain, as well as the dApps and wallets. This system will focus on solving these problems:

  • With the help from the gateway system, dApps can deploy without their own infrastructure and communicate with the wallet directly for information on the blockchain. Some current wallets do not support or intend to support this feature owing to their own infrastructure implementation, but we envision a future where gateway systems are easily accessible to every developer through wallets.

  • Wallets can be a lot snappier now since a significant amount of computation has been offloaded to the gateway system, for all the web3 services (as shown in the figure above). The gateway system will also have a high-performance backend that is responsible for cashing, access control, and bi-directional communication via websocket.

The gateway system to the blockchain could be beneficial to the users and the developers for it could enhance the scalability and responsiveness of the system. It will achieve a greater level of convenience if the demand and usage of dApps in Chia grow higher. But the challenge for the system would be to earn trust from the users and other developers in the defi world.

Even more possibilities?

The aforementioned gateway system is just an idea that we envision and below are some more of the functionalities we can think of that also serve well:

  • An activity-based analysis of the whole blockchain can be easily carried out by the gateway system. For example, standard Chia farming and transfer events, CAT minting/melting/transfer events, NFT minting/transfer/royalty collection events, etc. This activity feed can be collected by wallet users or blockchain explorers, avoiding showing end users coin sets which are hard to parse for human eyes.

  • If the users provide an observable wallet public key, the gateway system can even effectively provide a non-SPV wallet to browser extension users. That means, you will have a seamless experience transitioning from Chia official wallets to extension wallets!

Summary

We talked about the current development in Chia and painted a picture of an easier development in which responsiveness and scalability are achieved via a lightly trusted gateway system. We believe that such a gateway system could be favorable to the users and developers, and maybe you have a better idea to foster the ecosystem!