Host a static website on Phala

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.

Web Server

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:

1. SideVM supports std rust and async runtime (semi-compatible with tokio)
2. SideVM can host long running tasks in the background, decoupled from the contract lifecycle.
3. SideVM can listen to TCP sockets, allowing to deploy a web server
4. 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:

• A Web server with routerify
• MQTT broker
• Discord and telegram bot framework

Storage

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:

Short term limitation of SideVM

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.

Decentralized storage concern

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.

TODOs

• 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

Incredible stuff, I just use Cloudflare worker to host my personal home page. It’s time to think about building it with FatContract and SideVM . So compare to the enterprise-grade solution provided by Cloudflare, we are earlier but enough to build some experiments. I think the following features are developers who care about most(luckily we already covered most of them):

• Easy to get started

We need to provide developers an out of box template project which contains both server&client codes, basically, they just need to compile and deploy. This can be integrated into our CLI commander, like fat-contract new --site-template. Like I said earlier when I finished the workshop, we could have a CLI to make user easy to interact with our workers.

• View the site immediately somewhere

When developers deployed the sites to our worker(cluster). It’s better that we can provide a link to let them view and debug their website. I am not an expert on this but looks like much stuff needs to be done, but is worth doing.

• Provide storage interface on both SideVM & FatContract

Not sure the SDK you mentioned has covered this. Building a unified storage interface for decentralized storage is not easy, we may need to handle fee payments according to a different network. However, developers, always hope we hide all the technical details. I remember when I use Cloudflare worker, I don’t need to be aware of the storage of my site file(like style files and images), I can directly use them for my client just like building a normal website.

And I guess their still some scenarios that the site needs to fetch/push data from/to other parachains. It’s good to use the XCM message underneath. I am building the bridge to let FatContract send XCM messages to other parachains. Also, we still need some functionalities to be provided by upstream, e.g. support use XCM query the state of parachain.

• Security concerns

Developers have different security concerns when deploying their projects on an entire public network. Basically they neither trust other projects may be deployed on the same cluster with their project nor thrust the host machine that runs their service. Thankfully our building block is based on TEE, which naturally can protect the running program from many vulnerabilities. Even though we still pay more attention to this sector, if we have this ability, we still need more documentation to tell developers why we can.