Akash Network
Replies: 5 comments
|
ZestFlow: Comparison with Alternatives🔍 Problems Solved by ZestFlow
🔬 Workflows to Integrate (Estimated Current Users)🧬 Bioinformatics
🌍 Geospatial
🤖 AI / Data Science
🌦️ Climate
🌍 Market Potential: Domains & Use Cases🌾 AgriculturePotential Users: Researchers, agribusinesses, government agencies
Institutions:
🏥 Medicine & HealthcarePotential Users: Hospitals, research labs, pharmaceutical companies
Institutions:
🚢 Maritime & OceanographyPotential Users: Research institutes, shipping companies, environmental agencies
Institutions:
🌦️ Climate & Environmental SciencePotential Users: Meteorological agencies, environmental NGOs, universities
Institutions:
🧪 General Research & AcademiaPotential Users: Universities, research labs, students
Institutions:
🚀 Strategy to Prove MVP Utility1. Target Early Adopters
2. Create Simple Tutorials
3. Leverage GitHub & Community
4. Organize Workshops & Webinars
🏛️ Key Institutions for Partnerships🇫🇷 France
🇪🇺 Europe
🌍 International
|
Long-Term Vision: ZestFlow as an International Standard for Secure, Decentralized WorkflowsThe integration of Sardar et al. (2026)'s research on Intra-handshake.fail (CVE-2026-33697) into ZestFlow will enable cutting-edge security for data pipelines by combining post-handshake attestation with Confidential Computing (Intel SGX/AMD SEV). Collaborating with these authors will provide a scientifically rigorous foundation to ensure workflows are resistant to relay attacks, a critical requirement for compliance with the most stringent international data protection standards. Roadmap and Strategic Outreach:
Global Positioning and Compliance: Objective: Establish ZestFlow as the international benchmark for secure workflows, bridging academic research (INRIA, AMU, CNES) and industry (CMA CGM, agriculture). This approach will position Akash as a trusted, sovereign alternative worldwide, unlocking opportunities in markets currently dominated by U.S.-based providers. |
|
Hi! Thanks for this prop. I have a few comments and suggestions. Top Blocks:
So the honest answer is that this feature can't be built by ZestFlow alone. It needs a change to the Akash provider spec to carry verifiable compliance metadata, and that work isn't scoped, owned, or funded anywhere in this proposal, or Akash's own roadmap. Who owns that change, and is your plan blocked until it lands?
If the researcher brings their own Akash Console account and API key, that's the cleanest and lowest-risk option, and it's consistent with the BYOK direction our community has taken on Agents and Scribe. But it reintroduces exactly the setup step the pitch says doesn't exist, so the zero-config framing needs to be walked back to zero-config after a one-time account creation in this case. If ZestFlow acts as a billing intermediary that fronts the leases and invoices researchers, you get the frictionless UX, but you're now a managed service that custodies funds and moves money on behalf of users. That carries real operational and possibly regulatory weight, and it's a much bigger build than a CLI, none of which is scoped in this $3,200 ask. So the question back to you is which model Phase 1 actually ships, because it changes the scope, the risk profile, and the honesty of the headline claim. My read is BYOK is the right answer for an MVP, and if that's the plan, the proposal should say so plainly and adjust the "no setup" language to match.
Grant Specific Thoughts: If phase 1's ask is $3200 - what are the estimated asks for phase 2 and 3 so we can evaluate this project in its entirety vs potential ROI? Phase 1 is a small, contained bet, but the roadmap points at something much larger: additional runtimes, Slurm backends, TEE attestation work, a web dashboard, SecNumCloud integration, a REST API, and a cost estimation engine. That's a substantial amount of engineering, and if approving Phase 1 is effectively the first step toward funding all of it, we'd be evaluating the roadmap rather than just the MVP. Rough numbers for Phases 2 and 3 would let us judge the total investment against the return, which brings me to the other half of the question. On the ROI side, it would help to see how you're sizing the upside for Akash. The proposal says every zest run is a deployment, which is true, but scientific batch jobs tend to be bursty and individually small in dollar terms. A back-of-the-envelope estimate of expected deployments and lease revenue over, say, the first six to twelve months would ground the "high-value untapped market" claim in something we can weigh against the full multi-phase cost. Even a rough model with stated assumptions would make this much easier to say yes to. My Suggestion: The strongest part of this proposal is also the part you can fully deliver today: real access and portability for researchers working with open data. The friction you describe is genuine. Someone whose expertise is genomics or geospatial analysis, not DevOps, hits a wall at Docker, SDL, and wallet setup, and most never get past it. They wait in an HPC queue or pay AWS prices. A CLI that turns a workload into a running Akash job in one command removes a barrier that actually stops people right now. That's a good pitch on its own, and it doesn't depend on anything outside your control. The reason I'd lead with open data specifically is that the GDPR and patient-data angle, however impressive it sounds, depends on TEE and on provider compliance metadata that don't exist on Akash yet. So today it's a promise, not a feature. The open-data version works on the network as it is. And the addressable pool is still large: public reference genomes, published datasets, teaching and coursework, reproducibility runs, open satellite imagery, and the Global South institutions with no local hardware, which may be the most winnable segment since they have the least budget and the least DevOps support. Before building on that, I want to check a few assumptions with you, since you know the target users better than I do: Is it fair to say a meaningful share of your early adopters would be working with public or non-sensitive data? If the demand you're seeing is overwhelmingly sensitive-data institutions, that changes the picture and we should talk about that directly. Which single domain has the clearest, most reachable users for you right now, bioinformatics or geospatial? Where's your strongest existing contact? On payment, is BYOK with an Akash Console account something you're comfortable shipping in Phase 1? If those hold, my suggestion is to rescope Phase 1 to a tighter deliverable: the CLI plus two or three genuinely working tools in one domain, on public data, with BYOK payment. Drop GDPR, patient data, and TEE from the v1 scope and treat them as a later phase gated on the infrastructure landing. The advantage of doing it this way is not just that it's more honest. It's that it gives you something concrete to point back to for future funding. If the smaller MVP ships and generates real deployments and a handful of researcher success stories, that usage becomes the evidence for a larger Phase 2 ask. A rescoped v1 that delivers fully is a much stronger foundation than a broad v1 that partially delivers, both for the users and for your case to the community next time. Happy to help shape the rescoped version if that's a direction you're open to. |
1. TEE and Sensitive DataQuestion: Should we wait for TEE before building for sensitive data? How do you protect decrypted data in provider RAM without TEE? Answer:
2. GDPR Compliance and Provider MetadataQuestion: Akash does not verify GDPR compliance. Who owns the change to support verifiable GDPR metadata? Answer:
3. Payment Model (BYOK vs. Managed Service)Question: How will researchers pay? Will they create their own Akash Console account, or will ZestFlow act as a managed service? Answer:
4. Large Workloads (RAM vs. Disk)Question: How does the "RAM-only" model scale to large workloads (e.g., GATK, BLAST, Sen2Cor)? Answer: Workload Sizes and Strategies
Key Tools & Configurations
Tradeoffs & Mitigations
5. ROI and Multi-Phase FundingQuestion: What are the estimated asks for Phase 2 and 3? How do you size the upside for Akash? Answer: Phase 1 ($3,200 Ask)
Phase 2 (Estimated Ask: $15K–$20K)
Phase 3 (Estimated Ask: $30K–$50K)
ROI Justification:
6. Rescoping Phase 1Question: Is it fair to say early adopters would work with public or non-sensitive data? Would you rescope Phase 1 to focus on public data with BYOK? Answer:
7. Domain PrioritizationQuestion: Which domain has the clearest users for Phase 1: bioinformatics or geospatial? Answer:
8. Payment Model ConfirmationQuestion: Is BYOK with an Akash Console account acceptable for Phase 1? Answer:
Summary: Revised ApproachPhase 1: Public Data + BYOK ($3,200)
Phase 2: Agricultural/Biotech + Large Datasets ($15K–$20K)
Phase 3: Sensitive Data + TEE ($30K–$50K)
|
Uh oh!
There was an error while loading. Please reload this page.
[Grant Proposal]: ZestFlow CLI Open science
The Problem
Akash is cheaper than AWS/GCP but researchers, biologists, and data scientists can't use it. The barriers: Docker, SDL/YAML configs, wallet management.
Beyond cost, scientists face long queues to access HPC resources, slowing down research. Building private infrastructure is expensive, and many institutions are actively looking for alternatives. A decentralized provider network like Akash could solve this, but only if it's accessible. ZestFlow makes it accessible.
What ZestFlow Does
A zero-configuration Python CLI. One command to run any scientific workload on Akash, encryption, deployment, and retrieval handled automatically.
No Docker. No YAML. No wallet setup. From idea to cloud execution in under 5 minutes.
ZestFlow advances open science by making compute accessible to every researcher on the planet, regardless of their institution's infrastructure or budget.
Architecture, Direct Encrypted Tunnel
Data is encrypted before it leaves the researcher's machine, tunneled directly into the container's RAM, and never touches IPFS, S3, or any third-party storage.
A pluggable JobRunner interface abstracts every backend (Akash, Slurm...).
Priority after Akash is Slurm compatibility: researchers already use Slurm to submit HPC jobs. ZestFlow sits above it not to replace it, but to make workloads portable and reproducible across environments with a single unified command.
Why This Matters for Akash
ZestFlow opens a high-value, untapped market: the global scientific community.
--zone eu-auditedEvery
zest run= an Akash deployment. More researchers → more provider revenue → ecosystem growth.Phase 2 Confidential Computing (TEE)
The MVP eliminates third-party storage risk. Phase 2 closes the remaining gap: the rogue provider who controls the hypervisor and can read RAM.
When Akash's AEP-65 (Intel SGX / AMD SEV) matures, ZestFlow's tunnel terminates inside a hardware enclave requiring zero architectural changes:
This positions ZestFlow as a reference platform for decentralized confidential computing, not just a CLI tool.
Roadmap
Phase 1 MVP (this grant, 8 weeks)
--zone eu-audited)Phase 2
R, Julia, Bash runtimes · Slurm backends · TEE attestation research · job history
Expanded tool registry:
Phase 3
Web dashboard · SecNumCloud integration · REST API · cost estimation engine
Budget
$3,200 / 8 weeks funds completion of:
The CLI stays open source
Why Fund This
All reactions