Proposal for misc. contributions and creating a new auditor with open-source tooling

[piber-dev]

Proposal Research

The following research has been made on the technical feasibility and on the market/user demand of this proposal:

• A Google Form for market research was created and shared on Discord, Reddit, and in different SIG calls. Out of this, an average of 9/10 are supportive of this tooling being necessary. These numbers can be verified by Adam, Head of Community, on Overclock Labs.
• Multiple live demos and Q&A's in the Office Hours and SIG calls where suggestions have been made by users but nobody has rejected the idea.
• Releasing a GitHub Discussion detailing the rough idea and requesting feedback. Here, users have been asking questions and/or been supportive. Here, users have confirmed that the requested pay is fair.
• Technical research has been done on the feasibility of the tooling and the functionality of it by a member in p-i-3 with over two years of experience of Akash.
• With the help of Max from the Cloudmos team, the proposal has been able to have been turned into a collaborative effort between Cloudmos & p-i-3. Thanks to Max, it has also been somewhat optimized into something smaller than previously thought.
• One member will be attending the next Steering Committee.

Proposal Outline

The proposal is created to request funding for the following topics, services, and contributions. More details in the previous discussion.

• Contributions related to benchmarking providers, testing RPC nodes, and tracking uptime made to the Cloudmos indexer.
• Contributions related to filtering based off Cloudmos API and previous contributions made to the Cloudmos website.
• Implementation of KYC into an auditor, bringing audited providers and tenants to the network via signedBy fields & another set of API.
• Implementation of automation to an auditor, bringing benchmark & other API metrics to the network via signedBy fields and another set of API.

The estimated and billed times are: 100 hours for benchmarking, 20 hours for testing RPC nodes, 120 hours for building a tier-based auditing system, 10 hours for building the general auditing service, 100 hours for building the KYC auditor on providers and tenants, another 100 hours for integrating filtering and API usage to the Cloudmos frontend, and 45 hours for previous work from the hackathon. We are not counting any time for SIG calls or Office Hours calls. For every line item with an estimated number of hours, there is one milestone.

The estimate to complete all services and contributions are between 3-6 months, and we place the deadline at 6 months. Every milestone not reached after the deadline will have its funding returned to the community pool. We will begin our work sometime between the 15th and 31st of January when we have more time.

Proposal funding

We are requesting $50/hr in AKT with a total of 495 hours of work, for a total request of $24750 USD worth of AKT at the time of submitting the proposal.

[Dimokus88]

Hey @piber-dev !
This looks interesting and really necessary now.
How about some additional feedback on the work of providers (although admittedly, this may be a subjective opinion)?

In general, we are ready to support this proposal.

[piber-dev]

hello @Dimokus88, thank you for your comment,

a review system like this where tenants can leave feedback on their experience with a provider is planned as something to expand upon later, but is outside of the scope of this proposal

[Aihonaken]

Great proposal, this is the service Akash needs. I support this

[cloud-j-luna]

This has green light from us. How would creating a schema (could be JSON-schema) for provider attribute fit in this? I think we lack an auditor that makes sure that providers have a schema compliant set of attributes so that not only humans but also machines can integrate with these providers and perform operations. This data can be, GPU models used, Architecture, Region, Certifications, Hardware, Tier, etc... As discussed before, the provider attributes from Cloudmos are not machine friendly and are not based on a formal schema that can be used by systems to verify provider attributes.

[piber-dev]

hello @cloud-j-luna, thank you for your response,

this definitely fits in and we would love to work on building a schema like this with you -- this is something that i have personally wanted for a very long time. if the proposal passes, i suggest that we create a working group where we can discuss how to do this best. once something is established, it is easy to simply make systems that follow these schemas.

[brewsterdrinkwater]

This proposal will be discussed as a part of the agenda during the Steering Committee Thursday, December 6th, 2023.

Link to that meeting can be found here.

[brewsterdrinkwater]

Benjamin (piber-dev) discussed the Proposal with the Akash Steering Committee on December 7th, 2023. Quick TLDR below:

• Greg asked Benjamin about the specific deliverables in the proposal. Benjamin gave specifics, and referenced the pre draft proposal with specific deliverables.
• Greg also asked how Benjamin plans to manage the business of the auditor after the initial community pool funding. Benjamin mentioned that they will only ask for community pool spend once for this project, and have been exploring different ways to build a business after launch. Cheng and Greg showed an interest to get involved in helping to figure out a path towards sustainability for an Akash Provider Auditor.
• Greg wanted to make sure the proposal was open source. It is. Greg wanted to know that there was a path towards project sustainability, which Benjamin and his brother have top of mind.
• Greg put his support behind this proposal.

Please feel free to watch the Steering Committee video here. Discussion of this proposal starts around 30:00 minute mark.

Please check the steering committee readme to stat up to date on all Steering Committee meetings.

[anilmurty]

Super well written and needed. Looking forward to the discussion during the steering committee.

[CaptainSplince]

Nice work @piber-dev.

Biggest question from me (and I think Greg) is how will this be supported and updated after the 3-6 month build period?

[piber-dev]

hello @CaptainSplince, thank you for your comment,

you are correct - greg did ask this in the steering committee - but to summarize and to further explain the answer:

1. we will develop the software and make it open-source, making anyone able to spin up the same tools regardless of our future intentions. this means that if we go away from the expected path, other users can spin up the same services.
2. if we are looking to make more money, we can expand on the pre-existing tools and introduce business plans (using e.g. fees or paid subscriptions). we have future ideas in mind mentioned in this thread and those not yet formalized.
3. we are not interested in "double dipping" in the community pool for this project, even if we expand on this, unless pressure is made to continue with more expansions from other parties. our goal is to create a long-term business plan for this project.
4. for as long as it makes sense, we will host the auditor. cloudmos will be hosting most of the other services, which already has user demand to continue operating even if our auditor would fail on this end.
5. we will try to work together closely with providers and other community members to make everything work out well. there is no point in developing software that is useful, if nobody wants to use it because of X, Y or Z.

[31trainman]

Great idea @piber-dev. This brings the potential for creating a schema that other decentralized cloud providers could use thus allowing interoperability between different platforms etc.

[piber-dev]

This proposal passed! Thanks to everyone who helped shape this proposal and thanks for all of your support. We will start our project soon and share updates on Discord in our own channel and the #sig-providers channel.

// p-i-3