Please describe your proposed solution.
What's a frontend?
- A frontend is a web app or a mobile app that provides a friendly user interface. End-users interact with dApps through a frontend + wallet.
- Without a frontend, interacting with the blockchain would require manual crafting of really complex transactions and indexing large volumes of on-chain data locally.
- Frontends are key components to any dApp and as such, they need to be: reliable, performant, have global scale and easy to develop / maintain.
- Today, most frontends are hosted in one of a small set of big cloud providers such as AWS, Azure, Google Cloud, Vercel, etc, because they are the best available option to achieve the levels of reliability and performance required.
Problems with current approach
- Not censorship resistant: if the cloud provider decides (or is coerced) to shutdown the frontend, interacting with the dApp would be drastically affected.
- Using solutions like IPFS for content distribution would be censorship-resistant but they are extremely limited in capabilities: no server-side processing, no database, no load-balancing, no in-place updates, no detailed monitoring, etc.
- Poor competition: to get the benefits of the cloud, developers end up having to choose from a very short list of providers. These providers have little incentive for standardisation of their features, so developer often end up locked-in into particular vendors.
- Too generic: common cloud providers don't provide any Cardano-specific components (eg: Cardano Node, DBSync, Kupo, etc) and need to be manually implemented / managed by the dApp team. This adds complexity and increases the TCO.
Solution
- An open-source hosting platform (Demeter.run) that provides a developer experience similar to Vercel or Firebase. Developers build their React, NextJS or Remix frontend and then run a
publish
command. - A set of independent stake pool operators distributed across the globe where each one runs and monitors an instance of the open-source hosting platform.
- A fair load-balancing mechanism that distributes end-user's web requests to the different available SPOs, taking into account a past-performance reputation score.
- A bookkeeping mechanism on top of a distributed ledger that takes care of charging and compensating the different actors using an on-chain smart contract.
- Although the system would not be limited to Cardano dApps, SPOs could provide Cardano-specific services (access to Cardano Node, DBSync, etc) as an extra revenue stream. This simplifies operations for dApps and reduces costs by allowing sharing of common instances.
Scope for this Proposal
The solution described above is very ambitious. The scope of this proposal is to build a PoC (proof of concept) implementation with the following characteristics:
- Include a minimum of 2 SPOs participating as infrastructure providers. This will give a total of 3 different entities providing infrastructure (since TxPipe will remain as provider).
- Include between 10 and 200 real-world frontends hosted in the platform.
- An MVP version of the bookkeeping mechanism that is suitable for a small scale group of trusted entities. Scaling the bookkeeping process to a larger group of entities will require some improvements which are out of the scope for this proposal.
- An MVP version of load-balancing mechanism that will provide all the required features
- Personalized training for participating SPOs so that they can run their partition of the system.
- Provide infrastructure grants to pioneer dApp developers wanting to use this service. This will incentivize usage, lower dApp operating expenses and provide direct revenue to participating SPOs.
Technical Details
On our public RFC (Request For Comment) we provide some insights regarding the technical implementation of the platform.
How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?
Our proposal will provide:
- A real-world use-case for the Cardano blockchain: The consensus and bookkeeping mechanism that governs the hosting platform would be implemented as an Hydra state channel using Cardano as L1. More transactions on L1 means more fees for the protocol.
- A new revenue stream for Cardano SPOs: Cardano has a very rich and diverse group of SPOs which are cloud and networking experts. A federated hosting protocol would allow them to utilize their existing expertise for an extra revenue stream.
How do you intend to measure the success of your project?
Our PoC requires validation of several dimensions. In particular, we need to evaluate technical and business feasibility, this will require a combination of hard data and qualitative analysis.
The following metrics will be used for data analysis:
- The number of frontends hosted in the platform
- The number of requests that frontends receive
- The throughput processed by the infrastructure
- The uptime of the frontends measured by a max timeout threshold
- The quality of service for the end-user measured by request latency
- The error rate of requests measure by HTTP status code >500
The infrastructure providers (SPOs) will be required to provide some data regarding their operation:
- Initial investment required to provision their partition of the system
- Day-2 operation costs to run their partition of the system
- Qualitative survey describing the complexity of maintaining their partition
The dApp developers using the frontend hosting service will be required to provide some feedback regarding their experience:
- Overall development experience satisfaction as compared to similar systems (Firebase, Vercel, Fly.io, etc)
- Any available end-user feedback regarding the perceived performance of the frontends hosted by the system.
Please describe your plans to share the outputs and results of your project?
The proposal requires the development of the following software components:
- A Kubernetes operator that will be responsible for orchestrating the compute primitives required for running an instance of a frontend (containers, deployments, ingress, certificates, etc). This component will also be responsible for interacting with Hydra nodes for consensus between other partitions of the system.
- A CLI (command line interface) responsible for providing frontend developers with an entry point for building and deploying the required artifacts to run their frontend.
- A build system built on top of Cloud Native Buildpacks that will generate the required OCI (aka: Docker) artifacts required for runtime.
- A DNS (Domain Name System) server that is aware of the whole network topology with the goal of resolving custom subdomains pointing to the frontends hosted by the system.
Custom components developed for this system will be open-source, the outputs will be available to any developer in the ecosystem at every step of the development process:
- Latest version of the source-code will be available in the Github repository.
- Source code changes will be applied through a pull-request process.
- Alpha and Beta versions will be released at every milestone.
Upon reaching the end of the development process, we’ll provide:
- Docker images for the backend components (operator, build system, DNS)
- A CLI (command line interface) binary to serve as entry point for developers
- A documentation website with instructions for usage and deployment
- A tutorial video showing how to deploy a frontend using the CLI
Upon reaching the end of the PoC, we’ll provide:
- Raw, anonymous metrics regarding performance of the system
- A report showing our analysis of the success of the PoC. It will include both a quantitative and qualitative analysis of the metrics, SPO surveys and dApp developer surveys.
- A written roadmap describing the future plans for the system taking into account all of the information gathered throughout the PoC.