Hosting static website in Fat Contract is possible. We got the building blocks, but don’t have a server working out-of-box.
To build a static website hosting service, we need to be able to deploy a web server, and serve the static sites from a filesystem.
SideVM is necessary to run a web server. Fat Contract supports two kinds of runtime environment. One is the default ink! contract, as mostly shown in the workshop and wiki docs. Another is SideVM. Compared with ink! contract, SideVM has the following differences:
- SideVM supports
stdrust and async runtime (semi-compatible with tokio)
- SideVM can host long running tasks in the background, decoupled from the contract lifecycle.
- SideVM can listen to TCP sockets, allowing to deploy a web server
- SideVM must be deployed by a ink! contract, not by pallet
SideVM enables the use of a lot of powerful libraries like the HTTP library Hyper. We even used to successfully build the following examples in SideVM:
The next question is the storage of the static website. Phala doesn’t provide storage. However, there are plenty of decentralized and centralized storage. Almost all the storage options are accessible via the de-facto S3-compatible API, which is accessible with standard HTTP requests. The S3-compatibility enables Fat Contract to easily access the storage at:
- Decentralized storage: Arweave (via 4everland bucket), Filecoin (via fs3), Storj, etc
- Centralized storage: AWS S3, Google Cloud Storage, etc
The Fat Contract team is working on a storage SDK that does all the boilerplate jobs for you, and expose a simple API to the developer to access the remote filesystem. Now we have finished the authentication and made a demo at here:
Despite the powerful SideVM features, it also brings a lot of challenges to the resource accounting and security concerns. Until these problems are solved, SideVM may only be deployed in local testnet and some designated contract clusters. This doesn’t mean it’s impossible to use it right now, but we suggest to have a chat with the Phala team to figure out the best way to deploy SideVM on production.
SideVM can consume much more resource than ink! contract in two ways. First is the RAM usage. The execution of Ink! contract calls are ephemeral, but SideVM programs run for a long time, and they hold the RAM usage from the worker until it fully exits. The second is the port. If a port is allocated to a SideVM program, it will not be usable for others. It becomes a bottleneck to deploy SideVM in scale. We just finished the tokenomic design of the ink! contract part, and started working on modeling RAM and ports.
Another concern is how the decentralized storage is really decentralized.
Of course people are interested in decentralized storage, since it can potentially minimize the dependency on centralized services. There are plenty of decentralized storage projects, and most of them have the S3-compatibility layer. It’s possible to use HTTP to read and write to the filesystem by S3 APIs.
However, how decentralized is the S3 API is still a question. Most of the S3 API is built on top of minio, the de-facto open source software that converts the underlying filesystem to a S3-compatible service. Minio itself is likely to be hosted by a centralized entity. Not to mention how to decentralize the payments. Although without a throughout survey on this, we can almost conclude this is a “semi-decentralization” solution.
I’d still say it’s not a huge problem. The Web3 industry is still young. People always build the MVP first, and refine it toward perfection later. This already happened in exchanges (dex replacing cex), and is happening in indexers (the gateway in The Graph). It will also happen in the storage. We expect the fully decentralized solution will emerge with better Web3 computation infrastructure like Phala.
- Write a guide for deploying SideVM programs in a local testnet
- Test the S3 storage demo in Arweave and Filecoin
- Turn the storage demo to a production level SDK
- Build a demo to run static website serving
- Figure out how to solve the SideVM resource accounting and sharing problem
- Launch SideVM publicly
- Build a public static site hosting service