Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RFP: zkOracle Integration For o1js #22

Closed
teddyjfpender opened this issue Jan 22, 2024 · 8 comments
Closed

RFP: zkOracle Integration For o1js #22

teddyjfpender opened this issue Jan 22, 2024 · 8 comments
Assignees
@TyrellCorp2020
Labels
Ecosystem Advancement

Comments

@teddyjfpender
Copy link
Contributor

teddyjfpender commented Jan 22, 2024 •
edited by TyrellCorp2020
Loading

Ecosystem Advancement (RFP): zkOracle Integration for o1js

  • Intent: To integrate zkOracle functionality with o1js, enabling Mina zkApp developers to incorporate zk-oraclized data in their applications
  • Foundation or Organization Sponsor: Mina Foundation (MF) (contact: [email protected])
  • Submit by: February 7th, 2024
  • Selection by: Mina Foundation (MF)

Background

zkOracles provide a way to prove a statement about Web 2.0 data in a Web 3.0 application without revealing the full data set (selective disclosure). This RFP seeks proposals for introducing zkOracle features to o1js, enhancing the toolset Mina zkApp developers build their visions with and seamlessly integrate zk-oraclized data into their applications.

Attestation of Web 2.0 data in the form of credentials that are owned by wallet users enables end-users to bridge aspects of their Web 2.0 identity and activity into the world of Mina zkApps.

Requirements

Successful proposals should address the following key components:

  • Technical Feasibility: Demonstrate a clear understanding of the technical challenges and potential solutions for integrating a set of zkOracle features with o1js.

  • Proof System Compatibility: Clearly call out the proof system used in your solution and how this is (or will be made) compatible with the Mina proof system.

  • Comprehensive Plan: Develop a detailed roadmap with milestones for implementing a set of zkOracle features, including technical specifications, example flow diagrams of using the zkOracle between specific user personas, user experience considerations, and security measures/trust model.

  • Community Engagement: Engage with the community for feedback, discussions, and testing.

  • Documentation & Tutorials: Create comprehensive documentation and tutorials for developers to utilize the zkOracle functionality in their Mina zkApps.

  • Project Maturity: Is your project pre-alpha, alpha, beta, live in production (and how you define that)

  • Support: what support mechanisms do you have for Mina zkApp developers? (e.g. SDKs, documentation, tutorials)

  • Integrations: how are integrations monitored (if at all). For example, if the source data/flow changes, how will that be detected and fixed?

  • Example flow: describe how a a developer would add the ability to request the oraclized data (e.g. web components, API calls — the DX) and how the end-user would provide (the UX).

  • Commercial Terms: Please provide detailed information on the pricing structure for the system. This could include, but is not limited to:

    • A breakdown of all paid components of the system.
    • Specific pricing packages, if available.
    • Information on any tiered pricing models based on usage or features.
    • Details on any additional costs or fees that may be applicable.

  • Licensing: How is the software licensed? Include license per component of the system if there is a variety of licenses.

Core Features & Functionality

The proposed integration should enable:

  • User Experience Focus: Ensure a smooth and user friendly experience for oraclizing Web 2.0 data. This should include:
    • Prescriptive example code covering:
      • UI component (e.g. React, VueJS)
      • Incorporating the data into a proof
      • How a Mina zkApp can query the proven statement.
  • Security Model: Outline a robust security model that addresses potential risks and trust assumptions.
    • This should include information such as:
      • MPC vs Proxy vs other trust models
      • Details about the ZK implementation (interactive? non-interactive?)
      • What are the attack vectors you have considered?
  • Flexible Attestation Storage (optional but preferred): If your zkOracle plans to attest to Web 2.0 data in the form of credentials which can be held or accessed by a wallet, do you allow attestations to be stored in any wallet, accommodating a range of user preferences?
  • Common Use Cases: Enable proving social media accounts, GitHub commits, Google account ownership.
  • Extension Use cases:
    • Respondents should detail how a Mina zkApp developer could oraclize data that is not covered “out-of-the-box”. E.g. how to build an ‘integration’ with a new source.

Example Flow

The following diagram outlines one potential flow of zkOracles interacting with both Mina zkApp end-users and zkApps themselves. These interactions can include but are not limited to API calls, and user interface interactions.

graph TD
    A[Mina Developer] -->|develops| B(Mina zkApps in o1js)
    B -->|sends proof to| J{Mina}
    B -->|requests data| C{zkOracle SDK}
    C -->|proof| B
    C --> D>Integrations]
    D --> E[Social Network]
    D --> F[Web 2.0 Data Provider]
    C --> H(zkOracle UX)
    H --> I[Mina zkApp end-user]
    I --> H
Loading

Notes on the Example Flow

Assumptions:

  • a zkOracle provider has or maintains integrations with a set of Web 2.0 data providers
  • There are at least two potential user personas defined:
    • Mina zkApp end-users: Request oraclized data from the zkOracle provider API (e.g. attestation proofs for KYC verification, Web 2.0 social media data) & can use the proofs as arguments for smart contract or provable-program methods.
    • Mina zkApps: Request oraclized data from the zkOracle provider API (e.g. attestation proofs for price feeds) & can use the proofs as core features or components in their zkApp.

Suggested Project Milestones

The project could follow these phases:

  • Milestone 1: Research and Design

    • Deliverables:
      • An initial report on the scope, feasibility and different approaches for the set of zkOracle features to be integrated with o1js.
      • A design document outlining the proposed technical solution and user experience with the intended data provider integrations.

  • Milestone 2: MVP Development

    • Deliverables:
      • A working MVP demonstrating key features.
      • Initial community feedback sessions and MVP testing reports.

  • Milestone 3: Production Release and Documentation

    • Deliverables:
      • Finalized integration with comprehensive documentation.
      • Documentation & tutorials outlining example use cases.
      • Documentation outlining extensibility of the deliverables (e.g. how to expand to new types or sources of data)
      • Final report on community feedback incorporation and testing outcomes.

Impact Measurement

To enhance the ecosystem in the long term, an understanding of the effectiveness and reach of the zkOracle feature set in the developer community is necessary. As the ecosystem grows, new requirements will emerge, understanding the direct and indirect impacts of a zkOracle implementation can help iterate applications and the ecosystem to satisfy those requirements. The information gathered, after implementation, will help evaluate the success of the integration to identify and elicit areas for iteration. Key areas for such an analysis will include:

  • Community Feedback: Quality of community engagement and feedback.
  • Adoption Rate: Number of developers and projects utilizing the zkOracle feature set.
  • User Experience Quality: Feedback on the usability and smoothness of the integrated solution.

Application Instructions

To apply for this RFP, applicants are required to:

  1. Thoroughly review all listed requirements and deliverables to ensure a complete understanding of the RFP's scope and objectives.
  2. Complete the application form below, including all requested information and any preliminary ideas or proposals.
  3. Submit their detailed proposal in the specified format in this issue. Proposals should be structured and clear, with an emphasis on how the applicant intends to achieve the RFP's objectives.
  4. Engage with the Mina community through the designated discussion channels, sharing initial ideas and seeking feedback to refine the proposal before submission.

Applicants are encouraged to ask questions and seek clarifications as needed to fully comprehend the expectations and objectives of this RFP.

Proposals must be submitted as comments to this Github Issue.

Submission Form Template

Application Form

Ensure that all information provided is accurate and complete to best represent your proposal.

Team and Contact Information

  • Team Lead (Main Contact Person):

    • Name:
    • Position/Role:
    • Email:
    • GitHub Username:
    • Telegram/Discord Handle:

  • Mina Recipient Address (for potential funding):

  • Team Members:

    • Member 1:
      • Name:
      • Role:
      • Relevant Experience/Previous Work (with links):
    • (Add more members as needed)

  • Team Overview:

    • What makes you best-suited to execute this project?

      [Provide a comprehensive answer]

Proposed Solution

  • Proposed Solution Description:

    • Please describe your proposed solution based on the requirements and core features outlined in the RFP:

      [Provide a detailed explanation]

Execution Plan

  • Step-by-Step Plan:

    • Please outline your step-by-step plan to execute this project, including expected deadlines for each piece of work:

      [Provide a timeline with milestones]

  • Critical Milestones:

    • Please define the critical milestones that should be used to determine whether you've executed on this proposal:

      [List and explain the milestones]

Additional Support and Funding

  • Support Requirements:

    • Please list any additional support your team would require to execute this project (financial, technical, etc.):

      [Specify the support needed]

  • Grant Funding:

    [Explain your financial needs and conditions]

Community Engagement

  • Engagement with Mina Community:

    • How have you engaged with the Mina community to refine your proposal before submission?

    • How does your experience with Mina and the community increase the likelihood of success?

      [Describe the engagement]

Please ensure that you have reviewed all listed requirements, deliverables, and the provided resources to ensure a complete understanding of the proposals scope and objectives.
@lampardlamps
Copy link

excited to see this out, great work sir! @teddyjfpender
Is 7th Feb too soon for the deadline though?

@45930
Copy link

45930 commented Jan 22, 2024

Common Use Cases: Enable proving social media accounts, GitHub commits, Google account ownership.

As part of a previous hackathon I built Mina RNG. I ended up using it for multiple projects as a source of random data in a zkapp, but I was never able to attract another dev to use it in their project, though others have worked on similar problems.

At least one reason for this is that the signature output (the part that's usable in a zkapp) only comes in one format. The data that's being attested to can't be transformed after it's been signed. For something as generic as a random number, this was already a problem, so it will be 10x worse for something like tweets or github commits.

e.g. to answer the question of whether vitalik buterin tweeted an exact phrase, we want the oracle to sign the hashed contents of the tweet and affirm that vitalik was the author. To answer the question of how many tweets vitalik buterin made in the last 24 hours, we want the oracle to sign an unsigned int and a start and end timestamp over which it attests to the count of tweets. To make a zkoracle suited to a specific zkapp is almost trivial, but to make an SDK that is plug-n-play for a zkapp dev is difficult.

If I were to approach this, I'd probably start by looking into allowing a dev to configure their own datasource and format. Maybe even allow for some scripting so the zkapp dev can say: given these inputs, run this script and sign the output. Then the UI for end-users allows them to verify how the data is fetched and compiled, but the zkapp dev gets the oracle data in the exact format they need.

@teddyjfpender teddyjfpender moved this to RFP In Progress in Core Project Board Jan 23, 2024
@iam-dev
Copy link

iam-dev commented Feb 1, 2024

I'm considering a proposal to integrate a BANK API using PSD2 to facilitate real EUR transactions. Here's the envisioned workflow: zkOracle requests a payment from the end user and utilizes the PSD2 API to validate the user's bank account. Post-validation, as depicted in the flowchart, upon successful payment, zkOracle will generate a cryptographic proof which will then be recorded onchain within a zkApp. With this proof, users can mint EURc tokens using a designated payout method on the zkApp. This concept is built on our team's prior success with minting EURc on the EVM chain, detailed in our Simplicy infra GitHub repository. Would this be a suitable and eligible proposal for the Mina Foundation's current RFP?
zk Bank Oracle

@Subhash-Karri
Copy link

Here is our proposal for zkOracle integration

Team Details

Team Lead (Main Contact Person):
Name: Madhavan Malolan
Position/Role: CEO, Reclaim Protocol
Email: [email protected]
GitHub Username: madhavanmalolan
Telegram/Discord Handle: madhavanmalolan
Mina Recipient Address (for potential funding): TBD
Team Members:
We are a 25 member engineering heavy team including engineers and researchers with previous affiliations to Stanford, Microsoft, Meta and Google. Reclaim Protocol is a YCombinator backed company (W21).

Team Overview:

The Reclaim protocol team, with a proven track record of building products in Web3 and with deep expertise in zk tech, is uniquely positioned to fulfill this RFP’s objectives. Our team includes ZKP researchers and with previous affiliations to Stanford, Microsoft, Meta and Google.

The same team has previously built and scaled [Questbook.app](http://Questbook.app), a grants management tool used by Arbitrum, Compound, Polygon, TON, Aptos, Solana and many more ecosystems.

Reclaim protocol came out of a requirement in Questbook to enable pseudonymous builder profiles. That is, how can a developer prove that they have certain credentials like what university they went to, their work-ex, their github contributions - without doxxing themselves?

So, having the problem ourselves gives us an unfair advantage as being the developers and customers of Reclaim Protocol. We are able to quickly identify the wrinkles in the flow and iron them out. Afterall, we want to maintain a certain quality and reliability of our consumer facing product - Questbook.

Additionally, because of Questbook, we continuously work with early stage developers across ecosystems. Many of whom are integrating Reclaim already. We work closely with them to continuously improve our documentation and sdk. We believe anything more than a copy pasteable is too much dev-friction. We make it super simple to try out an integration, without compromising expressibility of the types of proofs the developer can generate using Reclaim’s SDK.

Proposed Solution

How does Reclaim Protocol Work?

Reclaim Protocol works using zkproofs on TLS data using a proxy model.

A non-technical explanation of how it works can be found here : https://blog.reclaimprotocol.org/posts/reclaim-explained/

A technical, in-depth explanation can be found on our whitepaper : https://link.reclaimprotocol.org/whitepaper-draft

UX

Screenshot 2023-12-25 at 7 50 29 PM

  • One of the most important things that we’ve focused on (and what likely sets us apart from other solutions in the market right now) is to not have the user install an app.
  • Most other solutions either expect the user to install a chrome extension and/or install a mobile app.
  • To generate proofs on a dapp using reclaim protocol, the user needn’t install anything. Just scan a QR code and get going.
  • Check out the demo video here : https://www.loom.com/share/15b503bcc5354595998f6579f8e81269
  • All of this is available to developers using

    • SDKs for Node, React, React Native, Flutter. These integrations are typically less than 20 lines of copy-pasteable code

    • We also have a dev tool that lets users create data providers for new websites. We already support about 200 websites, however there are way more than 200 websites out there. We don’t think we can ever create all the providers ourselves. our devtool https://dev.reclaimprotocol.org/ lets users build these data providers for website of their choosing using this tool. At the end of it, again, just copy paste the code.

    • The number one KPI internally is the number of new devs who are able to integrate Reclaim into a project and run it in less than an hour.

      • if it takes too long to build a provider and integrate - we’ve failed
      • if there are few devs integrating - we’ve failed

Security model
The approach that Reclaim uses is a proxy based zk-tls. There are three important vectors of attack, along with their mitigation.

  • MITM attack : this isn’t a real attack on Reclaim Protocol, however is the first question for many technically minded folks, so we thought it’s useful to address it upfront. All the https traffic is encrypted using TLS Session keys. These keys are never accessible to the proxy (aka attestor). All that the proxy sees is the encrypted traffic.
  • Fake key attack : the other potential attack is the client is able to generate a “fake” zkproof by generating a fake key that decrypts the encrypted data to a plain text to something other than what the original server sent. Though it is a known that it is possible to decrypt the same encrypted data to two different plain texts using two different keys - it is incredibly hard for the user to decrypt the data in a way that is not gibberish. Further more, the new decryption should have the same or similar structure (think json keys or xml fields) to the original plain text, making it an infeasible attack. We make a more formal argument here : https://blog.reclaimprotocol.org/posts/fake-key-reveal/
  • Collusion attack : this is probably the most relevant attack. If the client colludes with the attestor, they can generate proofs of fake data. This is a problem with all zkTLS based solutions - proxy based and mpc based alike. We recognize this and have spec’d out the decentralization to make sure the cost of colluding is impractically high. You can see more information about the slashing mechanism to avoid colluding here : https://blog.reclaimprotocol.org/posts/honey-pot

Flexible storage

  • The proof that Reclaim Protocol generates is, at the end of the day, a JSON blob.
  • This JSON blob is generated and stored on the client side. We don’t do anything with it, we let the application developer choose whether they want to persist it or discard it.
  • Because of this unopinionated data structure, the blob and thus the proof can be stored in the wallet specs laid out in [RFC0009](RFC 0009: Wallet API - Storing & Requesting Objects #12). The proof can be stored in a verifiable credential on any wallet. Once stored, it can be requested and queried by other dapps.
  • This lets the wallet store the information offchain in a self sovereign manner. Giving user full control on what to store and what to share with dapps.

Usecases

Execution Plan

  1. Integrate Reclaim SDK with o1js
    We will deploy Reclaim contracts on top of Mina, ensuring compatibility with Mina’s runtime environment. Currently, the Reclaim contracts are implemented in Solidity. The Solidity code can be found [here](https://github.com/reclaimprotocol/solidity-sdk/blob/main/contracts/Reclaim.sol#L229C11-L229C22). We will publish an article and conduct a workshop that explains this integration in detail. The proposed integration will be licensed under the GPL.

  2. Streamlining Developer Integration Experience

  • Optimising zkProofs
    We will optimize zkProof verification for Mina’s advantages and constraints, including time, gas, and computational resource efficiency

  • Optimizing UI
    We will build user interface components designed to enable developers to use the zkOracle. These components will allow end users to create and sign proofs, and the zkDapps will then be able to verify these proofs via Reclaim’s integration with Mina

  1. Integration and Testing
    We will develop and execute a suite of tests, including unit, integration, and stress tests, to validate the functionality and performance. Testing will be automated using a CI/CD pipeline to ensure that each build is verified, which will include code coverage and performance benchmarks

  2. Security Audit (If needed and recommended by the o1js team):
    We will contract a reputable third-party security firm to conduct an exhaustive security audit of the integration layers and smart contracts and publish a detailed report of their findings and remediation strategies.

For instance, [zkSecurity has audited the ChaCha20 circuits](https://blog.reclaimprotocol.org/posts/chacha-circuit-audit/) of Reclaim protocol and we are actively working with them to get other modules audited

  1. Detailed Documentation and Guides
    We will publish detailed documentation, and blogposts and participate in at least 2 community calls to educate, and seed ideas to the Mina developer community about how to use Reclaim Protocol inside their Dapps. Documentation will include a technical guide, API references, and example use cases to facilitate developer integration

  2. Community Engagement

We will work closely with the developer community to build/support at least 2 use cases uniquely because of Reclaim. We will be able to provide an SLA for any developers trying to integrate Reclaim from the Mina community.

Critical Milestones:

  1. Project Kickoff & grant approval
  2. Reclaim o1js Integration
    • Research o1js and Mina core protocol, its design, and architecture and share implementation specification documents with the o1js team for feedback and comments
    • Reclaim’s integration with o1js as zkOracle
  3. Integration and Testing of the Integration
  4. Security Audit
  5. Comprehensive documentation, blog posts, and participation in Mina’s developer community
  6. Launch of 2 Dapp on production within the Mina ecosystem that integrates Reclaim protocol

Additional Support and Funding

Total Funding Support Requested
$50,000

  1. Project Kickoff & grant approval - $5,000
  2. Reclaim o1js Integration - $30,000
    • Research o1js and Mina core protocol, its design, and architecture and share implementation specification documents with the o1js team for feedback and comments
    • Reclaim’s integration with o1js as zkOracle
  3. Comprehensive documentation, blogposts, and participation in Mina’s developer community - $5,000
  4. Launch of 2 Dapps on production within the Mina ecosystem that integrate Reclaim protocol or build at least 2 usecase unlocked uniquely because of Reclaim protocol - $10,000

Grant Funding:

To accomplish the milestones outlined above, the entire project will require 1 Project Manager, 3 Developers, 1 Dev Relations Lead, and 1 Integration Support Developer.

Integration - 3 Developers * 80 hrs * $125 = $30,000

Project Manager - 80 hrs * $120 ~ $10,000

Dev Relations & Post Integration Support - 2 * 50 hrs * $100 = $10,000

We will offer the Mina ecosystem ongoing development support for six months post-integration led by Integration Support Developer and provided by Reclaim Protocol. Additionally, after the integration is complete, we'll require assistance from the Mina team for joint marketing efforts to increase Reclaim’s visibility among developers and encourage developers to build novel use cases on top of Mina using Reclaim. Some of the use cases can be from the following - https://blog.reclaimprotocol.org/posts/usecases/

Community Engagement

  • Engagement with Mina Community:

We have shared our proposal for review and comments with multiple community members within the Mina ecosystem and have incorporated their inputs over several iterations. We are open to more feedback from the o1js, and Mina developer community and further refine our proposal based on their inputs. Moreover, we will share regular updates related to our progress for each specified milestone with the Mina community over forum posts, developer community calls if our proposal is accepted.

Our active involvement in gathering feedback and thoroughly understanding the technical aspects of the [RFP](#22), our proposal has deepened our understanding of Mina's specific requirements and its community dynamics. Engaging with key individuals from Mina Labs, involving both the engineering and product verticals, has allowed us to pinpoint use cases and Dapps such as SnickerDoodle that align with the current needs of the Mina ecosystem. These insights and our existing understanding of the Mina ecosystem and its community members are pivotal to our success.

Impact Measurement

  • We religiously track number of devs integrating Reclaim’s SDKs in less than an hour
    • For this RFP we will be tracking the number of developers being able to integrate using the o1js SDK in particular, and the time they take

@pudgyteddy
Copy link

pudgyteddy commented Feb 6, 2024 •
edited
Loading

RFP: enabling web private data with zkPass's transGate-js-sdk for the Mina ecosystem

Overview

zkPass is a private data protocol that enables privacy-preserving verification, It is built on the foundation of Multi-Party Computation (MPC), Zero-Knowledge Proofs (ZKP), and three-party Transport Layer Security (3P-TLS). zkPass provides TransGate, which enables users to selectively and privately validate their data on any HTTPS website to the web3 world. It can cover various data types such as legal identity, financial records, healthcare information, social interactions, work experience, education and skill certifications, etc. All these types of verifications can be done securely and privately without the need to disclose or upload any sensitive personal data to third parties.

zkPass can be readily incorporated into multiple application scenarios, including composable decentralized identity passes, DeFi lending protocols relying on off-chain credit, and verifiable zkSBTs or just acts as an Oracle etc. Wherever there is a need for trust and privacy, zkPass can provide a solution.

Proposed Solution

Leveraging advanced technologies like 3P-TLS, MPC, and ZKP, zkPass securely and privately converts data from HTTPS websites into zk proofs. This approach not only ensures user privacy but also protects against data forgery by malicious actors. By utilizing these technologies, zkPass empowers anyone to serve as an oracle for any website, thus removing the need for server-side cooperation and boosting data integrity and confidentiality.

To expand zkPass's utility within the Mina ecosystem, we propose three innovative integration methods between Mina's o1js and zkPass's transgate-js-sdk. These methods aim to support a broad spectrum of applications, from decentralized identity verification to advanced oracle services:

1. Straightforward SDK Integration into ZKApps

Developers can effortlessly integrate the transgate-js-sdk into their ZKApp projects, enabling direct access to data from third-party TLS servers, such as Twitter or Gmail. Acting as a zkOracle, the sdk ensures the authentication, confidentiality, and integrity of the data. Developers can then use o1js to generate proofs for this data, effectively bridging the gap between traditional web services and decentralized applications.

Untitled scene

2. Direct zkOracle Integration

The zkOracle framework can be directly integrated with the transgate-js-sdk by encapsulating its API within a minimalist layer. This approach simplifies the process of fetching and verifying data from external sources, facilitating the development of applications that depend on trusted data inputs.

3. Deep Integration between o1js and transgate-js-sdk

We propose a deeper integration between o1js and transgate-js-sdk to unlock advanced capabilities and optimizations. This integration requires a detailed discussion to outline the technical specifics, potential challenges, and integration scope, ensuring seamless interoperability and enhanced performance.

Execution Plan

Our execution plan is organized into three critical milestones: research and design, MVP development, and a comprehensive production release. Each stage is meticulously planned to ensure rigorous testing, community feedback integration, and comprehensive documentation, facilitating ease of use and extensibility for developers.

  • Step-by-Step Plan:

    We aim to create a demo using the transgate-js-sdk as a zkOracle within 8 weeks, possibly requiring some API modifications to align with zkOracle features. Our SDK is designed for simplicity. Below is a JavaScript snippet demonstrating its use as a zkOracle:

    const appid = "8fb9d43c-2f24-424e-a98d-7ba34a5532f5"
const connector = new TransgateConnect(appid)
const isAvailable = await connector.isTransgateAvailable()

if (isAvailable) {
  const schemaId = "516a720e-29a4-4307-ae7b-5aec286e446e"
	
	// you can think as the res is the data from zkOracle.
  const res = await connector.launch(schemaId)

  //you can generate proof for the res by o1js

} else {
  console.log('Please install TransGate')
}

    The variable res represents the data fetched from zkOracle, demonstrating how our SDK facilitates the integration with Mina's zkApps by allowing direct access to verified data.

  • Critical Milestones:

    • Milestone 1: Research and Design
      • Objective: To lay the foundational groundwork through comprehensive research and meticulous design planning.
      • Deliverables:
        • A comprehensive report on the project's scope, feasibility of integrating zkOracle features with o1js, and an exploration of various approaches.
        • A detailed blueprint outlining technical solutions and user experience, emphasizing seamless data provider integration.
    • Milestone 2: MVP Development
      • Objective: Develop a tangible, functional MVP based on our research and design.
      • Deliverables:
        • An MVP showcasing the core features of our solution.
        • Engagement sessions to collect community feedback, with detailed performance and reception reports.
    • Milestone 3: Production Release and Documentation
      • Objective: Finalize the solution for widespread adoption and provide comprehensive documentation.
      • Deliverables:
        • A fully integrated product with in-depth documentation for ease of implementation.
        • Extensive documentation and tutorials for extending our deliverables to new data types or sources.
        • A final report incorporating community feedback and detailing testing outcomes and future improvements.

Additional Support and Funding

  • Support Requirements and Grants:
    • Our team does not require any funding.
    • While our team does not require direct funding, we advocate for Mina Foundation to consider grants of $50K-$100K to support other developers integrating or building atop the SDK. This, combined with content support from the Mina team, would greatly enhance the development ecosystem.

Community Engagement

We will disseminate technical guidelines and SDK case studies within the Mina community to inspire potential creators and users. Further, we aim to collect more application scenarios to promote adoption. With extensive experience in studying the Mina Protocol, operating nodes, and developing applications using o1js, we are well-equipped to efficiently deploy and support this initiative.

Conclusion

This RFP outlines a visionary project that not only enriches the Mina ecosystem with privacy-preserving verification from any web private data capabilities but also sets the stage for widespread adoption and innovation in blockchain technology. Through strategic partnerships, community engagement, and the support of the Mina Foundation, we look forward to realizing the full potential of zkPass and its transgate-js-sdk.

@0x3V1
Copy link

0x3V1 commented Feb 7, 2024 •
edited
Loading

ZKON proposal to become a zkOracle on top of Mina Ecosystem

ZKON logo black

1) What makes ZKON best-suited to execute this project

  1. Open Source our Collaborative ZK implementation on top of the o1js framework for the rest of the Mina community: By adopting our collaborative Zero-Knowledge (ZK) approach, Mina community will be able to reuse decentralized o1js proofs being managed a verified through ZKON zkApps. This model adds value to mina's ecosystem by creating a unique approach to import off-chain data, ensuring data authenticity and integrity without revealing the underlying data. This collaborative effort not only distributes the workload, leading to a more scalable system, but also introduces redundancy and a consensus mechanism that could further secure the protocol against single points of failure or malicious actors running stand alone o1js circuits. For the Mina community, this means a richer set of off-chain data sources can be utilized with confidence, greatly expanding the potential use cases and applications within the Mina ecosystem.

  2. Integration with an Oracle Service provide that will enable not only new price feeds into Mina Network but also to provide verified price feeds through zkApp and collaborative ZK based on o1js

  3. Outlier Ventures Base Camp Success:

    Our team's recognition as the best team in the Outlier Ventures incubation under the ZK Cohort showcases our potential and credibility in the field.

  4. Dedicated and Specialized Team Composition:

    A full-time team of 7, encompassing roles like CEO, CTO, BD, Cryptographer, Senior Rust Developer, Junior Rust Developer, and Marketing Operations, demonstrates a well-rounded and dedicated team structure.

  5. Financial Stability and Runway:

    Having sufficient financial runway is crucial for the uninterrupted progress and scalability of the project. It reflects good financial planning and resource allocation.

  6. Mature and Tested Solution:

    • The maturity and tested nature of the solution indicate reliability and readiness for market deployment, it assures potential customers of the product's efficacy and minimizes the risks

  7. Established Customer Base and Real-world Applications:

    • Existing customers from day one provide a solid foundation for business growth and market presence also for Mina.
    • Sharing customer stories like the decentralized API connector and trading data validation on your website (https://www.zkon.xyz/documentation/ecosystem/customer-stories) highlights successful real-world applications of the technology.
    • The involvement with prominent projects like eGrains and DIA Data further showcases the versatility and market acceptance of our solution.

  8. Strategic Partnerships and Network Integration:

    We believe that with our current customer base and traction we will be able to add transactions to the Mina Network adding a strategic partnership for any further integration and customer that we add.

  9. Developer oriented

    We are constantly seeking developers and community feedback to improve our documentation materials here some of the key documents for our main products:

2) Please describe ZKON proposed solution based on the requirements and core features outlined in the RFP:

2.1) Background of ZKON Approach

Blockchain oracles play a pivotal role in the integration of blockchain systems with the external world, bridging the gap between on-chain and off-chain environments. They function as on-chain Application Programming Interfaces (APIs), facilitating access to external information for smart contracts. This capability is vital since Turing-complete systems inherently lack the ability to directly retrieve external or personal data. The presence of secure oracles is particularly crucial in DeFi.

Existing oracle solutions encounter challenges in effectively incorporating private web2 legacy data and establishing completely decentralized and trustless cross communication with the web3 ecosystem. Prominent players like Chainlink, Band Protocol, and API3 have successfully integrated real-world data, such as weather forecasts and asset prices, into the blockchain. Yet, a considerable challenge remains in securely and effectively connecting private and legacy data sources to the decentralized framework.

To address these limitations, ZKON introduces an innovative trustless decentralized network as a new form of zkOracles, that merges Multiparty Computation (MPC) with Collaborative Zero-Knowledge Proofs (Collaborative ZK). This groundbreaking approach allows multiple entities to collaboratively conduct computations and validate data integrity without the dependence on a centralized authority. Utilizing Collaborative ZK, the network guarantees the correctness and privacy of data, thus enabling Smart Contracts to securely verify and use data from diverse sources. This strategy not only bolsters the reliability and efficiency of data integration in DeFi but also heralds a new era of decentralized data processing and verification.

The integration of MPC and Collaborative ZK in this network represents a significant stride in overcoming the limitations of current blockchain oracles, fostering a more secure and efficient environment for data handling in the blockchain and DeFi spaces.

2.2) User Experience

Our user experience will flow through our zkApp that will act as a verifier of the collaborative proofs that our independent attestators will be providing, so in order to request a collaborative proof from our network of oracles the end zkApp will need to charge our zkApp with ZKON in order to incentives the attestators to provide their proofs.

More precisely, our User Persona are developers building zkApps for end-customers, the sequence diagram below shows how a user obtaining verifiable data on a give zkApp on Mina that uses ZKON with the help of two nodes part of the ZKON Netowrk. Initially, the user requests API keys and creates secure, divided data portions—shares—for the oracles, ensuring that no single ZKON oracle has complete information. The zkApp then sends these shares to the ZKON oracles and crafts a "Request Message." Each oracle contributes to the data processing without having full access to the information. They work together to generate a proof that the data processing is correct. One oracle requests the needed data from a data source, which after confirming the request's validity, sends the data back. The oracles process this data, and the user receives it with a proof of authenticity, verifying the data's integrity before using it. This method ensures a secure and verifiable data exchange, maintaining privacy and trust between all parties involved.

sequenceDiagram
    participant User
    participant Oracle1 as Oracle 1
    participant Oracle2 as Oracle 2
		participant ZKON zkApp
    participant OTHER MINA ZKAPP
		

    User->>User: Initiate request for API keys
    Note right of User: MPC: Generates shares for Oracle 1 and 2 (SDK or Widget)
		User->>Oracle1: Share_oracle_1
    User->>Oracle2: share_oracle_2
    User->>User: Generates "Request Message"
    User->>User: Initiates signing for "Request Message"
    User->>Oracle1: MPC: locally signs with user share
    Oracle1->>Oracle1: MPC: locally signs with share_oracle_1
    User->>User: Combines signatures and shares it along with "Request Message"
    Oracle1->>Oracle2: Generates Proof Pi collaboratively on Response data
    Oracle2->>ZKON zkApp: Sends Request Message
    ZKON zkApp->>ZKON zkApp: Verifies Oracles Proofs (o1js)
    ZKON zkApp->>OTHER MINA ZKAPP: Sends Verified data
Loading

Preferred Interface for Web2.5 Applications

ZKON has invested a lot of time for new applications to join easaly and start using ZKON infrastructure so that is why for web2.5 consumer applications that ones to provide data proofs onchain (Mina Protocol) they have two options:

Option 1) Widget: is designed to be straightforward and easy to integrate ZKON within the interface of the zkApp with a simple piece of HTML code or iFrame, please find our customizable Demo here: https://zkon-widget.web.app/

Option 2) SDK: is the library to access programmatically to ZKON Network so the zkApp can request automatically off-chain requests without the manual intervention of the end user and ensuring no single party have the full access requests.

Preferred Interface for zkApps (web3 applications on Mina)

For native zkApps that want to leverage ZKON data feeds and HMAC signing requests we also will provide all necessary information for these zkApps to access ZKON services through our ZKON zkApp that will activate any request.

ZKON will also be deploying a native token into Mina ecosystem in order to reward the Attestators or Oracles that computes and generate collaborative zk Proofs to the network.

2.3) Security Model

2.2.1) Securing Secret Sharing through MPC

Using Multiparty Computation (MPC), it is possible to safely transmit Secrets, like
API keys to an oracle through a cooperative procedure that protects the keys’ confidentiality. An overview of using MPC to safely provide API keys to an oracle is shown below Refer to Figure 1:

graph TD
API[API] -->|User_API_key| MPC[MPC_key_shred]
MPC -->|Share1_API_key Payload| Oracle1[Oracle 1]
MPC -->|Share2_API_key Payload| Oracle2[Oracle 2]

classDef api fill:#7b68ee,stroke:#333,stroke-width:2px;
classDef mpc fill:#f9f,stroke:#333,stroke-width:2px;
classDef oracle fill:#228B22,stroke:#333,stroke-width:1px;

class API api;
class MPC mpc;
class Oracle1,Oracle2 oracle;
Loading

  • Splitting the API key: The API key is split into several shares, often referred to
    as secret shares, in MPC. These shares are allocated to various participants in the computation, including the owner of the dApp or smart contract and the Oracle nodes. Each party has a separate, private piece of the API key Refer to Figure 2.

  • Communicating Payload and Shares: After computing the share, API owners send the shares to the Oracle along with the payload that needs to be signed before sending a request to the Exchange

  • Collaborative Signing: The oracles with their shares generate local signatures
    using distributed signing algorithm and send this signature to the API owner.
    The API owner sums up the local signature to get the final signature and sends
    a request to the exchange using the payload.

    graph TB
    Oracle1[Oracle 1] -->|Share1_API_key| MPC[MPC Sign]
    Oracle2[Oracle 2] -->|Share2_API_key| MPC
    UserAPIKeyShare(User_API_key_share) --> MPC
		MPC -->  OffChainRequest[Off-Chain request]
		OffChainRequest[Off-Chain request] --> |TLS CHECK| MPC

    classDef oracle fill:#228B22,stroke:#333,stroke-width:1px;
    classDef mpc fill:#fada5e,stroke:#333,stroke-width:1px;
    classDef keyShare fill:#fff,stroke:#333,stroke-width:0px;

    class Oracle1,Oracle2 oracle;
    class MPC mpc;
    class UserAPIKeyShare keyShare;

    linkStyle 0 stroke-width:2px;
    linkStyle 1 stroke-width:2px;
    Loading

The API key is kept secret throughout the procedure by utilizing MPC. No entity holds the entire key, removing the possibility of a single point of failure or someone obtaining the key without authorization. For sending API keys to oracles, MPC offers an extra layer of security, reducing the dangers of key disclosure and unauthorized access. It allows for safe and private communication while upholding the necessary privacy and security of the API keys in a decentralized setting.
Further, we want to ensure that the API keys are not reconstructed without the consent of the API key owner. Therefore an access structure is constructed using MPC inside TEE such that without the consent of the owner of API keys malicious oracles cannot collaborate to reconstruct the keys.

2.2.2) Privacy through ZK Implementation

A zero-knowledge proof (ZKP) is a technique that allows a sender device (prover) to convince a receiver device (verifier) that a certain statement is true, without revealing any extra details or information about the statement itself.
A zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a type of zk proof system that offers a concise and easily verifiable argument that the prover possesses a witness to a public statement while keeping the witness itself hidden.
The primary strength of zk-SNARKs is that they do not disclose any information about the secret data except for its validity. Additionally, zk-SNARKs offer two key advantages. Firstly, they have broad applicability, as there exist zk-SNARKs that can prove any relationship that can be represented by a finite-sized arithmetic circuit.
Secondly, zk-SNARKs have efficient verification, with proof size and verification time scaling sublinearly with the amount of secret data (usually in the order of kilobytes and tens of milliseconds), and anyone can perform the verification.
However, there are also two important limitations associated with zk-SNARKs.
First, the process of generating a proof can be computationally expensive. It often takes thousands of times longer to generate proof compared to directly checking the underlying relationship. This can be a significant drawback in terms of computational resources and time requirements.
Second, zk-SNARKs are designed to work with secret data held by a single party.
They do not natively support scenarios where the secret data is distributed or shared among multiple parties. This limitation restricts the applicability of zk-SNARKs in situations where collaborative proof generation is required. The constraint of having the secret data held by a single party imposes restrictions on the range of applications that can benefit from zk-SNARKs. It prevents the use of zk-SNARKs in scenarios where the secret data is distributed among multiple mutually distrusting parties.
In distributed Oracles, it will be efficient for Oracles to collaboratively proof a statement rather than building individual proofs and comparing them**.**
Our approach is based on Collaborative zkSNARK proofs through o1js framework allowing the generation of proofs over the secrets of multiple parties who do not trust each other. This is achieved by extending traditional zk-SNARKs into secure protocols among N provers, enabling them to collectively create a single proof over a distributed witness. In the context of pairingbased zkSNARKs, the proof generation algorithm is optimized to leverage algebraic techniques for multiparty computation (MPC), resulting in efficient protocols for generating proofs.

graph LR
    Response1[Response from offchain] --> Oracle1[Oracle 1]
    Response2[Response from offchain] --> Oracle2[Oracle 2]
    Oracle1 -->|collaborative_proof| Gen[ZKON zkApp]
    Oracle2 -->|collaborative_proof| Gen
		Gen --> |collaborative_verification| MinaProtocol[Mina zkApps]

    classDef oracle fill:#f4cccc,stroke:#333,stroke-width:1px;
    classDef gen fill:#93c47d,stroke:#333,stroke-width:1px;
    classDef response fill:#fff,stroke:#333,stroke-width:0px;

    class Oracle1,Oracle2 oracle;
    class Gen gen;
    class Response1,Response2 response;
Loading

Please find more information on our Cryptographic Paper: https://assets-global.website-files.com/6596c4c0471448237e44b834/65a552ed5905cc04c3709157_ZKON Cryptographic Paper.pdf

2.2.3) Considered Attack Vectors

  • Secret sharing with MPC: Api secret keys / session keys are not exposed to oracles with the help of MPC inside TEEs . Each oracle receives an additive key share which is used for HMAC signature generation. Privacy through zk implementation: Anyone can verify the data received by the oracle originates from the particular session key / api key. Collaborative zk snarks utilize the distributed proof generation technique to generate proof collaboratively proving that they have the correct key shares required to get the data from a particular source.
  • Malicious Provers: On a 3Gb/s link, it is possible to achieve security against a malicious minority of provers while maintaining a similar runtime as that of a single prover. Even when dealing with N-1 malicious provers, the slowdown required is only around 2 times. This efficiency is uncommon because secure distributed computations typically experience significant slowdowns, often by orders of magnitude. The efficiency of collaborative proofs means that most applications that can handle the cost of a single-prover proof should also be able to handle the cost of a collaborative proof. For ZK Miners, Oracles can proof the correctness of the data received from a given exchange or data source using collaborative zkproof.
  • Adversarial Setting: We assume the adversarial model to be the dishonest majority in an active adversary setting where a malicious participant has the capability to corrupt messages exchanged between them.
  • Coalition of parties: is considered both for MPC as well as collaborative zk. Both mpc and collaborative zk security assumptions take in consideration that if n-1 parties are dishonest the protocol will abort

2.4) Flexible Attestation

ZKON does not only provide flexible Attestation but unparallel independent attestation system. By using MPC randomly selected ZK Oracles are available to witness different data points using SnarkyJS without ever holding the full secret for accessing the underlaying data.

Ones the oracles achieve enough consensus (at least 3-n agreeing on the data output), the Smart Contract requester can use the output answer in any Smart Contract, either updating any user wallet interacting with your dApp or updating any other smart contract.

2.5) Current ZKON Use Cases

Verified Price Feeds together with Oracle Service provider

We offer the generation of Decentralized Trustless Price Feed Verification to Oracle Service provider, our offering to them leverages our expertise in Multi-Party Computation (MPC) and Zero-Knowledge Proofs (ZKP) to deliver a pioneering solution that enhances data authenticity and security. Our decentralized WebSocket connector enables Oracle Service provider to access and verify trading history with unmatched precision, ensuring the integrity of data through advanced TLS key management and certificate verification processes. By incorporating a collaborative ZKP framework and a robust threshold agreement protocol, we ensure the transparency and reliability of trading data, setting new industry standards for security and trust.

Proof of Reserves with e-Grains

ZKON's innovative proposal for the "Decentralized & Trustless Proof of Reserves of Soja Grains" project aims to revolutionize the agricultural sector by introducing a cutting-edge system that ensures the authenticity and quantity of soja grain reserves. Utilizing a sophisticated integration with IoT devices and leveraging Multi-Party Computation (MPC) alongside advanced cryptographic techniques, our solution guarantees real-time verification of grain quantities with unmatched security and integrity. By incorporating TLS certificate verification and deploying Collaborative Zero-Knowledge Proofs (ZKP), we offer a transparent, secure method for e-grains to authenticate data sources and validate grain reserves without compromising sensitive information. More information about the project here: https://www.zkon.xyz/blog/agricultural-commodity-tokenization

Proof of Trading with Zuus Ai

ZUUS Trading Bot Platform's integration with ZKON's d-Auth Decentralized API Connector marks a significant advancement in secure and efficient cryptocurrency trading. Addressing the critical challenge of security risks associated with centralized API key management, ZUUS AI leveraged ZKON's innovative d-Auth technology. This decentralized approach, utilizing Multi-Party Computation (MPC) to shard and distribute API key fragments across a network, ensures no single point of failure, drastically reducing the risk of breaches and unauthorized access. The d-Auth widget not only enhances the platform's security but also maintains the essential low latency for effective trading strategies, reinforcing ZUUS AI's commitment to providing a secure, reliable, and user-friendly trading experience as well as incorporating proofs of trading activity into Mina protocol. Learn more here: https://www.zkon.xyz/documentation/ecosystem/customer-stories/decentralized-api-connector

Extended Use Cases

As you have seen ZKON can provide a wide range of solutions to multiple customer types, we are also really excited on our future around key areas such are:

  • SocialFi: Develop new smart contract based social use cases (quests, reputation, loyalty…) by proving any data from off-chain applications like social media, CEXes, traditional banks, fintech (like Paypal, VISA…) or work management apps (like Asana, Notion…).
  • KYC/ID: Prove your humanity and adulthood by generating a zkProof of a KYC you passed in any centralized institution like CEXes, banks…
  • Gaming: Connect your game to the blockchain and transfer any data generated in local servers to smart contracts seamlessly.
  • DAOs: Vote on DAO proposals with tokens holded on centralized exchanges.
  • RWA & Insurance: Enhance insurance policies by integrating off-chain data such as historical crop yields, detailed weather reports, soil quality assessments. This data provides insurers with a comprehensive view and potential risks.
  • Payments: Privacy layer on off-chain and on-chain payments. Initiate fiat payments based on your off-chain exchange balances by imitating withdrawals and settling with the end PoS with Fiat.
  • Off-Chain Lending: As DeFi seeks to add new lending offerings, integrating the depth and breadth of web2 financial data as a collateral can be a game-changer.
  • Credential verifications: Verify credentials seamlessly & represent them in web3, reducing friction to decentralized job platforms and academic networks.
  • And many more!

To learn more about other Customer Stories here: https://www.zkon.xyz/documentation/ecosystem/customer-stories

To learn more about other potential use cases that could be deployed with ZKON https://www.zkon.xyz/use-cases

3) Please outline ZKON step-by-step plan to execute this project, including expected deadlines for each piece of work

  1. Design and Planning Phase Completion (1-2 weeks)

    • Focus on evaluating the compatibility of o1js zk circuits with your existing infrastructure.
    • Identify potential integration challenges and develop strategies to address them.
    • Collaborate with technical teams to ensure a clear understanding of the project's requirements and objectives.
    • Establish a comprehensive roadmap detailing each step of the integration process, including timelines and resource allocation.

  2. o1js ZK Circuits Integration (2-3 weeks)

    • Integrate o1js zk circuits on the Testnet, ensuring seamless interaction with your existing systems.
    • Conduct extensive testing to assess the performance, scalability, and security of the integration.
    • Engage with at least one customer to participate in the testing phase, gathering feedback to refine and optimize the implementation.
    • Document and address any issues or bugs encountered during the testing phase.

  3. Smart Contract to Execute d-Auth connections (for each signing request) (1-2 weeks) and ZKON token deployment

    • Migrate the existing contract to TypeScript
    • Develop and deploy a payment smart contract on the Testnet that facilitates secure and efficient data requests and MPC connections.
    • Incorporate features to handle various payment scenarios and ensure transaction security.
    • Test the smart contract rigorously to ensure its reliability and compliance with relevant standards.
    • Prepare documentation and user guides to assist customers in understanding and utilizing the payment system.

  4. Staking Smart Contract to Become Part of the Network (2-3 weeks)

    • Design a staking smart contract that clearly defines the criteria and process for oracles to join the network.
    • Implement mechanisms within the contract to manage staking, rewards, and penalties, ensuring network integrity and performance using TypeScript and Mina resources.
    • Conduct thorough testing to validate the smart contract's functionality and security.
    • Provide comprehensive documentation and training materials to facilitate the onboarding of new oracles.
    1. Security Audit (3-4 weeks)

    Smart contract code review and security analysis reports.

  5. Mainnet Integration (2 weeks)

    • Transition from the Testnet to the Mainnet, ensuring all components are fully operational and optimized.
    • Collaborate closely with at least two ZKON customers to facilitate their integration and provide support throughout the process.
    • Monitor the network's performance and address any issues promptly to maintain a high level of service quality.
    • Gather feedback from customers and continuously improve the network based on their insights and experiences

4) Please define the critical milestones that should be used to determine whether ZKON have executed on this proposal

  • Milestone 1: Migration Design (1-2 weeks)
    • Deliverables:
      • Design a report on how to migrate our current Collaborative ZK approach to o1js and how the system can be adapted to a Collaborative framework.
  • Milestone 2: MVP Development (6-7 weeks)
    • Deliverables:
      • Smart Contracts migration to zkApps: Token Deployment, Payment zkApp, Staking process.
      • A working MVP demonstrating key features: MPC + TLS Sessions.
      • Initial community feedback sessions and MVP testing reports.
  • Milestone 3: Production Release and Documentation (5-6 weeks)
    • Deliverables:
      • Finalized integration with comprehensive documentation.
      • Documentation & tutorials outlining example use cases.
      • Documentation outlining extensibility of the deliverables (e.g. how to expand to new types or sources of data)
      • Final report on community feedback incorporation and testing outcomes.

Please list any additional support ZKON team would require to execute this project (financial, technical, etc.)

Technical Support from O1 Labs

  • Continued collaboration with experts from O1 Labs, ensuring valuable technical guidance and alignment with the Mina ecosystem. as well as access to cutting-edge development tools, libraries, or frameworks from O1 Labs
  • It will be key to designate a strategy to implement a collaborative SnarkyJS approach to provide trustless verified data on our Collaborative zkApp approach.
  • Access to the Community Developer that is building the system that enables o1js to verify proof groth16

Financial support

  • Grant for System Migration: We request financial assistance from the Mina Protocol Foundation in the form of a grant. This support is crucial for the smooth transition of our systems onto the Mina Protocol. The grant would cover various costs, such the ones listed on the next section

Explain your financial needs and conditions

We are budgeting $65,000.00 Grant not only for the execution but also for the commercialization of the project. The budget will be allocated as follows:

  1. At the approval of the grant: $10,000
  2. Public Protocol design to adapt o1js to Collaborative zero knowledge proofs. $10,000
  3. o1js integration with our zkApp Collaborative approach $20,000
  4. Full integration example with one of our existing customers $10,000
  5. Security Audit $5,000
  6. Documentation & Open Source ZKON Collaborative ZK approach for the rest of the Mina Community: $5,000
  7. $5,000 in Mina tokens to incentivize new zkApps deploying on top of ZKON.

ZKON network is commited to add value to Mina Community that is why will be offering an airdrop of $10,000.00 ZKON token for the first 2 zkApps that build on top of ZKON infrastructure.

How have ZKON engaged with the Mina community to refine your proposal before submission?

Since our participation in the Outlier Ventures zero knowledge acceleration program sponsored by Mina, we have worked alongside the Mina and O(1) Labs teams to bring our technology to Mina and support the ecosystem with proposals that generate added value. The Mina and O(1) Labs teams have provided feedback on our proposal, and we have refined our proposal to meet the requested needs, also creating value thanks to the versatility of our solutions.

Our active participation in the zkIgnite program and consistent interaction with o1js team has been pivotal for refining our proposal. Through different conversations with the core o1js Team and Mina Foundation, we've tuned our collaborative ZK approach to meet Mina's technological needs and community vision. This hands-on engagement has deepened our integration within the ecosystem, allowing us to craft a community-endorsed, value-adding proposal.

A good example of our dedication to the community is the open discussions that we had through our zkIgnite application

https://zkignite.minaprotocol.com/zkignite/dev-tooling-infra-cohort-3_104/feedbackandrefinement/suggestion/628

And our engagement with the Discord community through multiples threads regarding our zkIgnite application and making sure the community was engaged with us!
discord

How does ZKON experience with Mina and the community increase the likelihood of success?

Working alongside the Mina and O(1) Labs teams and the Mina community drastically increases the likelihood of success for our proposal due to several factors: their extensive knowledge of Mina's architecture, their eagerness to innovate and embrace new proposals, and the diverse backgrounds of the people in the community. At ZKON, we have spent two years developing the technology we want to implement in Mina, and having an extended team that supports us and helps in critical processes is of great value to us and will undoubtedly help us deliver the product with all the necessary security and quality.

Also being able to get open feedback from the community during our zkIgninte application forces us to simplify our interface to communicate with other members from the Mina community.

It has been a great exercise to help us reducing complexity and being able to share our added value in simple terms. so Thanks!

@pascuin
Copy link

pascuin commented Feb 7, 2024

Acurast x Mina zkOracle

Team and Contact Information

Team Lead (Main Contact Person):

  • Name: Pascal Brun
  • Position/Role: Co-Founder
  • Email: [email protected]
  • GitHub Username: pascuin
  • Telegram/Discord Handle: to be provided privately

Team Members:

  • Alessandro De Carli, (Co-Founder). Alessandro led the Security Mobile Application Framework Team at Credit Suisse before founding Papers. Excelling in mobile security with global Fortune 500 clients. Pivoted to blockchain with 'AirGap,' securing $250M+ in assets and growing to 25 employees. Founded Acurast in 2022, focusing on a disrupting cloud with mobile hardware.
  • Pascal Brun (Co-Founder). Pascal has a technical background in System Engineering at a Fortune 500 company, before Co-Founding Papers with a focus on User Experience before taking on a more operational role such as Business Development and Project Management. He has built up a large network in the Web3 space over the last few years.
  • Mike Godenzi (CTO) Mike had leading roles for iOS security at Credit Suisse and Swiss Re before becoming CTO of Papers where he leads mobile security and blockchain research and development. Under his lead Papers built AirGap, the most secure self-custody solution on the market.
  • Dr. Christian Killer, (Head of Research) Christian holds a PhD in Blockchain Voting, advanced the status-quo of voting systems with his novel research on decentralizing electoral procedures. Published cutting-edge research in interdisciplinary top-tier venues covering Blockchains, Applied Cryptography and Information Security.

Team Overview:

The team behind Acurast has been working together for over 12 years. With experience ranging from building mobile security frameworks for financial institutions such as banks, insurance companies as well as Fortune 500 companies. And a deep knowledge in the blockchain space, being actively developing applications and developers tooling since 2016. Acurast is the culmination of the two, mobile security and blockchain.

Other projects developed by the team include:

  • AirGap, a secure self custody wallet solution comprising of AirGap Vault and AirGap Wallet. The Vault securely stores your private keys on a spare offline phone and the Wallet interacts with the online world. Communication between the two apps are made vie QR code scanning.
  • Beacon, a customizable method to connect to multiple wallets over a decentralized network. Beacon powers every dApp on Tezos.
  • Youves, the biggest DeFi platform on Tezos, with more than USD 50M TVL.

With Acurast, the team already gathered a lot of experience developing off-chain data sensitive tooling and allowing for a generic oracle creation.

Proposed Solution

Acurast

Introduction

Acurast responds to the ever-growing centralization among cloud providers of tech giants. This centralization of compute poses a bigger and more significant threat to humanity regarding security risks, data privacy, data sovereignty, and the economic issues arising from monopolistic market conditions. Furthermore, given the current geopolitical landscape we are convinced a decentralized compute infrastructure network is the only sustainable solution going forward.

Acurast changes the games’ rules by leveraging hardware superior in many aspects: the smartphone. These technological wonders we carry around and rely upon daily have constantly been challenged by various constraints: power consumption, the lack of physical security and the need for versatility in the tasks it can be used for. These constraints have led to technological advances and manifold improvements in power consumption. I.e, smartphones achieve superiority in compute-per-watt, by a factor of over 50.

Further, it has led to the most secure hardware security modules available on the market. In short, smartphones are the perfect backbone to power a genuinely decentralized cloud which can offer more secure and resilient computing at a fraction of the running costs, leading to a future-proof and affordable solution for developers to deploy their workloads.

Acurast Secure Hardware Runtime

The Acurast Secure Hardware Runtime (ASHR) is a generic approach to achieve a confidential execution layer while assuming a timely threat model, thus ensuring the highest possible level of security. The current ASHR implementation is based on coprocessors provided by the Google Titan chip.

Ambition

Leverage Acurast's decentralized cloud for providing a decentralized and trustless approach at creating zk proofs within the confidential computing context of Acurast Processors, to create a trustless “notary” for zkOracles. Giving developers the proper tooling to seamlessly create their own zkOracles for their zkApps within the Mina ecosystem.

In addition, due to Acurast's nature as a decentralized cloud, developers gain the ability to leverage the compute Acurast provides for other use cases. Enabling developer to get unfettered access to the full extent of compute that Acurast offers through its versatility to execute apps defined by developers in e.g., Javascript, NodeJS etc. completely trustless.

Goals

  • Ability to create generic zkOracles executed in Acurast's confidential compute environment
  • Setup and interaction of new zkOracles in o1js
  • Interaction with the Acurast SDK in o1js, establishing direct websocket connections
  • Access to Acurast's generalized compute for use cases outside of zkOracles

User Experience

Generic zkOracle within a confidential compute environment

Acurast Processors become the “notary” between a user’s request and the provided data by e.g., an API without revealing the computation and the result to the owner of this “notary”, the Acurast Processor. Acurast’s architecture comes into play here, where Acurast Processors, these mobile devices with their dedicated hardware chip and its Trusted Execution environment can be utilized to create these proofs completely confidentially.

image

The created and “notarized” proof can be directly injected to the Mina protocol, by the Acurast Processor in a signed transaction. For Transport Layer Security (TLS) secured endpoints it is possible for the trusted execution environment to observe the handshake and certificate pin the received response to a specific server (e.g., Binance), this allows the developer to proof that the data was really observed at the specified source and has not been tampered with.

zkApps with zkOracle

Alternatively, the created and “notarized” proof can either be requested through a websocket communication channel directly from the Acurast Processor and sent back to the user that requested this notarization.

image

Giving zkApp developers the ability to leverage sub-second communication times for real time observation, this can enable e.g., DeFi application to lower the risk and automation of their protocol better.

Execution Plan

The execution plan spans 14 weeks from initial requirements engineering to finalization.

  • Approval & kick-off
  • Requirements engineering
  • Development
  • Testing
  • Communication

Critical Milestones:

The implementation sees three milestones:

Milestone 1: Requirements Engineering: 2 weeks

During the requirements engineering phase, the zk proof generation is being researched and defined:

  • Mina protocol support on Processors
  • zk-proof generation on Acurast Processors

Milestone 2: Software Development Development: 10 weeks

Development of the required components:

  • Acurast Processor support for Mina
  • Acurast Processor’s capabilities to create zk proof for Mina
  • Acurast zkOracles support in o1js
  • Interaction with the Acurast SDK in o1js, establishing direct websocket connections
  • zkOracle “notary” in Acurast Processors
  • Mina support on Acurast Orchestrator

Milestone 3: Testing & Deployments: 2 weeks

  • Testing of Mina zk-proof generation on Acurast Processor
  • zkOracle example implementation testing
  • Developer documentation
    • zkOracle examples
    • How to access Acurast resources from Mina

Additional Support and Funding

Especially during the requirements engineering phase, direct interaction with key stakeholders e.g., o1js team is crucial to provide the best possible developer experience for zkOracles that leverage Acurast as an execution environment with the main goal, providing seamless and generic approach at zkOracles.

Grant Funding:

The timespan of a completed Acurast Mina integration with zkOracles is 4 months. We are asking for grant funding in the amount of USD 116’160.

  • Milestone 1: USD 14'080
  • Milestone 2: USD 84'480
  • Milestone 3: USD 17'600

Community Engagement

We have been actively communication with various stakeholders in the Mina community to further establish the feasibility of the proposed approach. Further outreach to the broader community will be a key part of the requirements engineering process, communicating the approach of utilizing Acurast for zkOracles.

Feedback of the community will be considered during the complete development process, to establish the best possible developer experience.

Conclusion

With the development of zkOracles with Acurast and its integration, not only a generic approach at zkOracles can be provided to developers, giving them full flexibility and control but also executing these requests in an environment that is completely confidential and secured.

On top of that, with this integration, Acurast decentralized cloud and its provided compute becomes accessible to developers within the Mina ecosystem for use cases outside of zkOracles.

@teddyjfpender
Copy link
Contributor Author

Thanks all for the submissions! 🚀

@TyrellCorp2020 TyrellCorp2020 moved this from RFP In Progress to Proposal in Review (MF) in Core Project Board Feb 21, 2024
@TyrellCorp2020 TyrellCorp2020 moved this from Proposal in Review (MF) to Done in Core Project Board Apr 10, 2024
@TyrellCorp2020 TyrellCorp2020 moved this from Done to Implementation in Progress in Core Project Board Apr 10, 2024
@TyrellCorp2020 TyrellCorp2020 self-assigned this Apr 22, 2024
@TyrellCorp2020 TyrellCorp2020 mentioned this issue Jul 30, 2024
Open
@TyrellCorp2020 TyrellCorp2020 moved this from Implementation in Progress to Done in Core Project Board Jul 30, 2024
@TyrellCorp2020 TyrellCorp2020 mentioned this issue Jul 30, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@TyrellCorp2020 TyrellCorp2020

Labels
Ecosystem Advancement
Projects
Core Project Board
Status: Done
Milestone
No milestone
Development

No branches or pull requests
9 participants
@lampardlamps @pascuin @iam-dev @45930 @Subhash-Karri @teddyjfpender @TyrellCorp2020 @pudgyteddy @0x3V1