Introduction
TxPipe is an open source software company that develops infrastructure solutions for the Cardano ecosystem. They are the ones responsible for Scrolls, Oura, Pallas, Aiken and Demeter.run a full suite of tools for building dApps with less than 3 clicks from your web browser. This proposal is looking to create a federation of frontend hosting providers leveraging the infrastructure and capabilities of stake pool operators (SPOs). Since even permissionless dApps are subject to censorship if the frontend (user interface) is hosted on a centralized provider.
Impact
A frontend is the UI/UX (user interface and user experience) of a web or mobile application that provides users with a friendly way to interact with the backend (what happens behind the scenes). End users interact with dApps through a frontend and a wallet. Without a frontend, interacting with the dApp would require advanced knowledge to manually craft complex transactions and indexing large volumes of on-chain data locally. Therefore, frontends are a critical component of any dApp and they need to be reliable, efficient, have global reach and easy to maintain. Today, most frontends are hosted on centralized server farms such as Amazon, Microsoft and Google.
The current approach taken by dApp developers of hosting their frontends on centralized server farms is not ideal in an ecosystem that thrives for decentralization. We have seen for example the OFAC sanction that tornado.cash received in August 2022. The frontend hosting was taken down by authorities but the code still exists on the Ethereum blockchain. This is a clear case on the importance of decentralizing frontends, just like freedom you only notice its absence once it’s taken from you. Other solutions like IPFS (InterPlanetary File System) are censorship resistant but extremely limited in capabilities.
Another problem with the oligopoly of centralized server farmers is the poor competition they generate in the market. Developers end up having to choose from a very short list of providers, who have little incentives to standardize their features so customers often end up locked-in into particular vendors. These providers also don’t provide any Cardano specific components and need to be manually implemented, adding complexity and over time.
For these reasons, the accomplished team at TxPipe is proposing an open source hosting platform that provides developers the opportunity to build their frontends and publish them with a simple command. Independent stake pools operators distributed across the globe will then run and monitor an instance of the open source hosting platform. A load balancing mechanism will distribute end user’s web requests to the different available SPOs, taking into account past-performance reputation scores. Meanwhile, a book keeping mechanism will take care of charging and compensating the different actors using an on-chain smart contract. SPOs could also provide Cardano specific services, like access to DBSync, as an extra revenue stream.
Since the scope of this proposal is very ambitious, the objective is to build a proof of concept with a minimum of two SPOs participating as infrastructure providers. A MVP (minimum viable product) of the bookkeeping and load balancing mechanisms will provide the required functionalities for a small scale group of trusted entities. Personalized training will also be necessary to onboard SPOs to run their instances of frontend hosting. Grants will be shared with dApp developers to bootstrap the initial service, allowing them to lower their operating expenses at the same time that SPOs are rewarded for their work.
The project success will depend on several dimensions. In particular, the team will need to evaluate technical and business feasibility which will require a combination of hard data and qualitative analysis. A set of metrics will be used to assess the performance and effectiveness of the system. These metrics include the number of frontends hosted in the platform, the number of requests received by the frontends, the throughput processed by the infrastructure, the uptime of the frontends measured against a maximum timeout threshold, the quality of service for end-users measured by request latency, and the error rate of requests measured by HTTP status codes greater than 500.
To gain insights into the operational aspects of the system, the team will collaborate with the infrastructure providers. These SPOs will be required to provide certain data related to their involvement in the system. Including the initial investment required to provision their partition of the system, the day-to-day operational costs of running their partition, and a qualitative survey describing the complexity associated with maintaining their portion of the system.
Additionally, the team will gather feedback from dApp developers who utilize the frontend hosting service. These developers will be asked to provide their perspectives on the overall development experience compared to similar systems such as Firebase, Vercel, and Fly.io. Additionally, the team will seek any available end-user feedback pertaining to the perceived performance of the frontends hosted by the SPOs.
The proposed project entails the development of several crucial software components. Firstly, a Kubernetes operator will be created to handle the orchestration of necessary compute primitives for frontend instances. This operator will also interact with Hydra nodes to achieve consensus among different system partitions. Additionally, a command line interface (CLI) will be designed to serve as an entry point for frontend developers, enabling them to build and deploy the required artifacts for their frontends. The system will incorporate a build system utilizing Cloud Native Buildpacks to generate the necessary OCI (docker) artifacts for runtime. Furthermore, a DNS server will be implemented, capable of comprehending the entire network topology to resolve custom subdomains associated with the hosted frontends.
As part of the commitment by the team to open source development, the custom components developed for this system will be made available to developers within the ecosystem. The latest version of the source code will be accessible through a GitHub repository, and source code changes will be applied via a pull-request process. Throughout the development process, alpha and beta versions will be released at significant milestones, ensuring ongoing progress and community involvement.
Upon completing the development phase, the project will provide Docker images for the backend components, including the operator, build system, and DNS server. A CLI binary will be made available as an entry point for developers, accompanied by a documentation website containing comprehensive usage and deployment instructions. Additionally, a tutorial video will be provided, demonstrating how to deploy a frontend using the CLI effectively.
Once the PoC phase concludes, the project will offer raw, anonymous metrics regarding the system’s performance. A comprehensive report will be compiled, featuring a quantitative and qualitative analysis of the metrics, surveys conducted among SPOs and dApp developers. This report will evaluate the success of the PoC, highlighting its achievements and areas for improvement. Furthermore, a written roadmap will be presented, outlining future plans for the system based on the insights gained throughout the PoC phase, ensuring the project’s continued evolution and development.
Feasibility
The TxPipe team is composed of experienced software developers with a track record of delivering open source products for the Cardano ecosystem.
Santiago Carmuega is the main applicant, co-founder and CEO of TxPipe. He has many years of professional experience as developer, QA, architect, manager, consultant and product owner. Will be in charge in this proposal of system architecture and part-time Rust developer.
Federico Weill is co-founder and COO at TxPipe. Will be responsible for the project management.
Alejandro Avagnina is VP of engineering at TxPipe, he will be responsible for Rust development and part-time site-reliability engineer.
Rodrigo Santamaria is CPO at Txpipe, who will be responsible for UI / UX and frontend development.
Florencia Luna will be responsible for technical writing of tutorials and documentation.
Since Fund 10, proposers of Project Catalyst need to provide a detailed explanation of the project’s milestones and the main tasks or activities to complete them. This proposal has an expected development lifecycle of eight months with ten distinctive milestones.
Milestone #1: Distributed Kubernetes Operator
During the first milestone, which spans one month, a distributed Kubernetes operator will be developed to handle frontend workloads. It will be open-source, integrating a distributed consensus mechanism and tested in a two-party staging environment with simulated workloads. The desired outcome is to create an accessible operator with associated code, available through a public repository. Provisioning scripts and tutorials will also be provided to aid adoption and understanding.
Milestone #2: Distributed Load Balancer
During the second milestone, which also has a duration of one month, a distributed load balancer mechanism will be developed by integrating a DNS component and a reverse-proxy component into the existing operator. This enables global topology awareness and efficient routing. The load balancer’s effectiveness will be validated through long-running operation tests in the updated 2-party staging environment. The milestone’s output includes the source code, provisioning script, and tutorial for the updated feature of the operator, ensuring accessibility and ease of implementation.
Milestone #3: Distributed Bookkeeping
The third milestone has an expected duration of one month. During this time a distributed bookkeeping mechanism will be developed, consisting of credit and usage-tracking components. The credit component manages credits, while the usage-tracking component monitors resource usage. The 2-party staging environment will be updated to incorporate these components, and long-running tests will be conducted. The milestone’s output includes source code for the updated operator feature, enabling developers to implement the distributed bookkeeping mechanism.
Milestone #4: SPO Onboarding
The fourth milestone has a duration of two weeks, SPOs will be onboarded for the PoC phase. This involves reaching out to interested SPOs, providing technical training, and continuous support during infrastructure provisioning. A distributed staging environment will be established using infrastructure from participating SPOs. The desired outcome is the successful onboarding of at least two SPOs actively participating in the PoC, managing their allocated infrastructure partitions.
Milestone #5: Frontend CI Pipelines
For the fifth milestone, which will take one month, the main focus is on implementing automated CI pipelines for frontend builds. This streamlines the build process and ensures efficient delivery of artifacts. The milestone involves integrating the CI pipeline into the existing operator and updating the staging environment to support build jobs. Integration testing will be conducted to ensure smooth integration and operation. The milestone’s output includes the source code for the updated feature, integrating the automated CI pipeline for frontend builds..
Milestone #6: Frontend Developer Tooling
The sixth milestone, will last for one month as well, the focus is on improving frontend developer tooling. This includes developing an API for RPC execution and a CLI application for frontend deployment management. The desired outcome is the source code for both the API and CLI, enabling streamlined builds and deployments. Binary releases of the CLI will be provided for ease of use, alongside comprehensive end-user documentation for frontend deployment guidance.
Milestone #7: dApp Onboarding
During the seventh milestone, which spans two weeks, the focus is onboarding dApps for the PoC phase. This involves inviting interested developers to join and providing comprehensive training on frontend deployment. Continuous support will be offered throughout the onboarding process, addressing technical challenges and guiding developers through deployment. Staging versions of dApps’ frontends will be deployed for testing. The desired outcome is to onboard at least five trained dApp developers proficient in utilizing the system for frontend deployment, providing valuable insights into usability and functionality.
Milestone #8: Stress & Penetration Testing
In Milestone #8, lasting two weeks, the focus is on stress and penetration testing. Integration tests will be conducted on the bookkeeping subsystem and CI pipelines, while stress tests will evaluate frontend request throughput, concurrent frontends, and API endpoints. Additionally, penetration tests will be performed on API endpoints. The expected output is comprehensive reports from all the tests, ensuring the system’s security, scalability, and robustness by mitigating potential risks and vulnerabilities.
Milestone #9: Production Release
During Milestone #9, which spans one month, the focus is on the production release of the system. A distributed production environment will be set up, and dApps will be instructed to deploy their production frontends and partially redirect traffic. This milestone aims to capture real-world usage and measure key metrics, including HTTP request metrics and compute resource metrics. The desired output is a fully functional distributed production environment, and the ultimate outcome is the successful deployment of production frontends by dApps, leading to the measurement and evaluation of important performance and resource metrics in a real-world scenario.
Milestone #10: Real-world data gathering and analysis
The last milestone has a duration of two weeks, the main focus is on gathering real-world data and conducting analysis. This includes performing surveys with SPOs and dApp developers, as well as analyzing raw metric data. The milestone culminates in the preparation and sharing of a final report. The desired output consists of survey results, analyzed metric data, and the final report. The outcome of this milestone is the acquisition of valuable insights into the system’s real-world operation, which will inform further development efforts and foster community engagement.
Value for money
Another modification for Fund 10 is that the budget is now in ADA and not in USD. This makes sense from the perspective that we are working to develop a new decentralized financial operating system but at the same time most projects need to pay for goods and services in fiat money. This brings a new challenge to the table since now teams need to ask for a coherent budget in a volatile currency.
The team is asking for a total budget of 407,857 ADA which at the time of writing this article has a market value of 125,212 USD. This budget is broken down by resource type in the following manner:
A rust developer covering a full time position for five months requires 160,714 ADA or 49,339 USD at current market value. Which means a monthly salary of around 6,168 USD.
A front-end developer covering a full time position for two months requires 28,571 ADA or 8771 USD. Which translates to a monthly salary of 4,385 USD.
A technical writer covering a full time position for two months requires 21,429 ADA or 6578 USD. For a monthly salary of 3,289 USD.
The project manager will be a part-time position for eight months, requiring 21,429 ADA or 6578 USD. The monthly salary stands at 822 USD.
Site-reliability engineer is a full-time position for three months, requiring 85,714 ADA or 26,314 USD. Setting the monthly salary at 8,771 USD.
The hosting grants for dApp developers aims to provide 200 frontends for six months at a cost of 85,714 ADA or 26,314 USD. Placing the cost of hosting one frontend for one month at 21.92 USD.
Lastly, the staging environment for six months has a cost of 4,286 ADA or 1315 USD.
The allocation of resources throughout the development process will yield open-source code that can be widely utilized by teams and members within the Cardano ecosystem. Additionally, the resources allocated for grants will not only provide direct revenue to participating infrastructure providers, but also offer value to dApps through free hosting for a period of six months. Additionally, the resources invested in generating comprehensive reports will provide valuable insights to the Cardano ecosystem, specifically to TxPipe, Demeter.run, and SPOs, potentially paving the way for larger-scale projects that bring real-world use and increased traffic to the blockchain. These combined efforts contribute to the growth and advancement of the Cardano ecosystem as a whole.
Q&A with TxPipe
Q1: The team is composed of experienced developers and TxPipe has a track record for delivering open source products and solutions to the Cardano ecosystem. However, this is a very ambitious project which will require a significant amount of time to complete. Given the amount of projects already in TxPipe portfolio and a relatively small team, is there a risk that the project could stall or delay? If so, what are the plans to mitigate this risk?
A1: Unfortunately, the risk of delays in software development is always high. However, there’s a silver lining: the base Demeter platform, which currently operates as a centralized service, has its dedicated team of front-end and back-end developers, as well as SREs. This team will continue enhancing the base layer. The team designated to the proposal has a very defined scope: ensuring that multiple Demeter instances can operate in tandem. I’m not suggesting that it’s a ‘simple’ task, but we aren’t starting from square one; we already have a strong foundation and a one-year head start.
Regardless of the above, we agree that end goal is very ambitious. Creating a distributed computing grid capable of serving frontends globally, offering outstanding performance and competitive pricing, will require more than a Catalyst proposal. That’s why we aim to take small steps toward the goal. The first step is establishing a proof-of-concept environment, a small-scale setup that will allow us to demonstrate the potential of the idea. This’s our goal for Fund10.
Many things could go wrong, but I remain confident because we have a secret weapon, a group of decentralized entities that are experts at managing server and cloud infrastructure: the Cardano SPOs.
Q2: In the proposal the demand for decentralized infrastructure is described as a “chicken-and-egg problem”. Which will be addressed by the grants for hosting dApps’ frontends for free during a six month period. However, in the case that these grants fail to attract dApps developers is there a plan b? Could this decentralized hosting be used for other actors in the ecosystem?
A2: Yes, the underlying principle of what we’re building primarily involves running arbitrary workloads through a distributed network of infrastructure providers. We’re starting with Web Frontends because we believe it’s a use-case that can drive adoption more swiftly than others, but it’s certainly not the only one. Another compelling use-case is machine learning. As you probably know, training ML algorithms requires GPUs, which are quite expensive when operated through traditional cloud providers. With a decentralized version of Demeter, we could envision SPOs with bare metal GPUs contributing computational power to the grid during periods when those GPUs are not in use for other purposes. Machine learning is just one example; we have several other use-cases in mind, such as CI build pipelines, data batch processing, backend hosting, and more. In fact, many of the tools that we currently offer in Demeter could be reimagined as distributed services (e.g., Ogmios, Kupo, DBSync). However, tackling all these ideas simultaneously would be unmanageable. Our approach is to start with as narrow a scope as possible to demonstrate value, and then move on to the next use-case.
Q3: This fund iteration brings new challenges for proposers since the budget is in ADA and not USD. Since this project will last for eight months, the volatility of the price of ADA is hard to predict. In case that ADA/USD drops below your expected price, is the project in jeopardy of being completed? In the same way, if ADA/USD appreciates above your expected price, are there bonus functionalities that could be added?
A3: Managing budgets in ADA introduces a great deal of uncertainty. I imagine this holds true for all serious projects in Fund 10. We did incorporate a margin of error into the budget, but we kept it minimal to avoid negatively impacting the overall perception of the proposal. In a highly pessimistic scenario, our contingency plan is to continue development but with reduced bandwidth. This approach might result in additional delays for the project, but we hope it doesn’t come to that. In an optimistic scenario, assuming we have an unspent budget, we would use it to improve adoption. This could mean increasing the total amount of grants or enhancing the visibility of the project (i.e., investing in marketing). The greatest and most complex challenge we face with this project is securing adoption.
Q4: Aside from the grants for dApp developers, has the team considered other alternatives to attract potential developers? The budget doesn’t consider a marketing expenditure, how is TxPipe planning to reach the highest amount of interested actors?
A4: Our strategy is to leverage all the tools already at our disposal. Firstly, the grant itself serves as a marketing tool. We plan on using our existing outreach to the Cardano developer community to announce the grant. There are many projects that would benefit financially from free hosting. Demeter already has more than 2,000 developer accounts. We intend to offer the frontend hosting service to this existing user base. From the perspective of a developer already using Demeter, deploying a frontend to the distributed network should feel seamless. Lastly, we hope to see SPOs becoming partners in this endeavor. We believe that if we can align incentives correctly, every participant in the system will benefit. Thus, driving adoption becomes a shared responsibility.
Q5: One part of the proposal is to utilize Hydra nodes for consensus between partitions of the system. However, Hydra is still in development at the moment and not many production applications exist yet. Is there a risk that the intention of using Hydra at this stage fails to meet expectations? If so, how would TxPipe mitigate this risk? Are there alternatives to use of Hydra?
A5: You are correct, this is a calculated risk that we have chosen to take. The Hydra team is diligently working to develop a solid L2 solution for Cardano. We believe that the maturity of this solution can only be reached by testing Hydra in real-world scenarios. Our selection of Hydra for the Demeter project is not just a technical choice, but also a vote of confidence in our ecosystem. It is our way of contributing to Cardano by providing a real-world use case that leverages as much of the tech stack as possible.
Link to Ideascale proposal: https://cardano.ideascale.com/c/idea/104411
