zkProver Engine

Mina Navigator Proposals
1

This topic is to discuss the proposal submitted by @DFST & @vhorba
Please see below for the details of the proposal and discussion.

18th November, 2024
Current status: Under Consideration.
Opened for community discussion on : 18th September, 2024.

1 Like
2

zkProver Engine

Project Background

We propose to create a framework for programmable objects in Web3 that stand for real-life things and contain fields that launch custom logic. This makes an object a smart contract or empowers it to call a smart contract deployed off-chain. This unlocks many real-life use cases, mainly associated with asset ownership and management: real-world assets (RWAs), certification, gaming objects, and more. Essentially, we’re developing an ERP for digital assets in Web3.
We effectively integrate zero-knowledge proof into digital asset management by creating a zkProver Engine - infrastructure to generate zk-proofs for operations with digital assets. The zkProver Engine is intended to bring ownership and management of digital assets into their owners’ hands. Now, a digital creator will easily prove the authenticity of their blog post, companies can manage their stocks through blockchains, and insurance companies will prove an insurance event.

Proposal Overview

Problem

The vision for a new internet powered by programmable cryptography promises efficiency, privacy, and cost savings through local code execution and various proofs. However, it requires a decentralized, censorship-resistant protocol like the Mina Protocol, which offers a secure, scalable, and intuitive platform for building and accessing these proofs. This article gives more details on the subject matter.

Some blockchains have a built-in object model that allows asset ownership and management functions to be implemented. Take, for instance, dynamic fields on Sui that behave as autonomous programmable entities. However, Mina is an account-centric blockchain and doesn’t support an object model. As a result, Mina doesn’t have programmable objects. Besides, there are currently only eight Fields on a zkApp account, which impedes enhancing programmability on Mina.

Use Cases

Below are several corner cases for our zkProver Engine.

Use Case 1 - Gaming
There’s a game with gaming items. These items can be created and mutated due to a set of rules. For example, a user goes to the blacksmith with their gaming sword and a magic stone. A blacksmith mints a new magical sword with the stone. The sword is a programmable object with a link to the frame in one of its properties. Once the necessary condition is met (the user has a magic stone), and the user initiates the object mutation, the script launches, and the programmable object gets mutated. This use case applies to a metaverse.

Use Case 2 - Car Insurance
Programmable provable objects are good with RWAs. Once an insurance event occurs, the insured person applies for indemnity to the insurer. The insurer needs proof that the insurance event is valid (the car was damaged in a road accident). The object representing the car has a property with a code link that defines the rules by which this object can be mutated. An expert proves the event’s validity, and a zk-proof is issued; then, the object is mutated, showing that an insurance event occurred with the car.

Use Case 3 - Supply Chain Management
The Procurement Department in a production company has completed the procurement list. For each position on the list, a programmable provable object is minted. Once a position is procured, the object’s property responsible for that is changed, mutating the object.

Use Case 4 - Asset Management
A company has many assets (buildings, machinery, vehicles, other infrastructure) with their estimated value reflected in the corresponding account of the ledger. For each such asset, a programmable, provable object is minted with properties that describe this asset. Once the value of an asset changes (due to market price fluctuations or as a result of wear and tear or a force majeure), the corresponding property of the object changes, mutating the object.

Use Case 5 - RWA Securities
Real-life securities: bonds, treasures, shares - may need authentication and verification of their status change. Once a bond is issued, a programmable provable object is minted with a set of properties, among which is latest_sell_timestamp. This field changes once a bond is sold and the object is mutated, representing the bond status change.

Use Case 6- Verify Stamps
This use case is akin to what notaries usually do - verify documents, signatures, and stamps. Once a stamp is placed on the document, a programmable, provable object is minted with a set of properties. One such property represents that the stamp is valid.

Use Case 7 - Music and Entertainment
Sometimes, performers write a cover version of an existing piece of music or several versions of one track. A programmable, provable object is minted for each track to differentiate between the original track and a version/cover of this track. Once a performed decides to write a new version of an existing track, the code embedded in the programmable object is triggered, and one of the properties of the object is mutated, thus creating a new object to represent the latest version of the track, while the original version is represented by the previous object.

Use Case 8 - Luxury Goods
Luxury goods like antiquity objects, yachts, and luxury or retro cars need proof of authenticity. Sometimes, they need to be restored, which should be proof of that since it affects the selling price. When a luxury good is registered, a programmable, provable object is minted to represent it. It has a property for the object’s version, which means the number of times the good has been restored, and a property for the latest restoration date. When the luxury good is restored, the programmable object is mutated by changing the said properties.

Use Case 9 - Identity and Certification
There’s an outsourcing software company. Each employee is outsourced to an external project. For each employee, a programmable, provable object is minted with properties representing their level, profile, skills, stack, language proficiency, etc. Once an employee gets through assessment and is upgraded (from Junior to Senior level), the property “level “changes its value, and the object is mutated.

Use Case 10 - Publishing, Media, and Blogging
There’s a media marketplace where authors write and sell their articles. Once an article is created, a programmable, provable object is minted to represent it. This NFT has properties representing the article’s metadata. An author decides to edit their article. Once the necessary corrections and changes are made, the properties that stand for the version and the latest version timestamp change, thus mutating the object.

Use Case 11 - Fundraising and Crowdfunding
There’s a crowdfunding platform. Once a project is listed, a programmable, provable object is minted to represent it. One of the properties represents the project status. Once the status changes from “Being Funded “to “Funded “, the object is mutated.

Use Case 12 - Supply Chain (Procurement)
The Procurement Department in a production company has completed the procurement list. For each position on the list, a programmable provable object is minted. Once a position is procured, the object’s property responsible for that is changed, mutating the object.

Use Case 13 - Asset Management
A company has many assets (buildings, machinery, vehicles, other infrastructure) with their estimated value reflected in the corresponding account of the ledger. For each such asset, a programmable, provable object is minted with properties that describe this asset. Once the value of an asset changes (due to market price fluctuations or as a result of wear and tear or a force majeure), the corresponding property of the object changes, mutating the object.

Use Case 14 - Governance
Governance and voting are among the most prominent and common programmable object use cases. As a voter registers, a programmable provable object is minted with a set of properties, one of which represents the vote status. This parameter changes when the voter casts a vote, and the object is mutated.

Impact

The internet’s development was driven by the need for secure communication, leading to advancements like HTTPS. Programmable cryptography, such as zero-knowledge proofs (ZKPs), enhances various applications’ security, privacy, and integrity. At O(1) Labs, the focus is on building ZKPs to address issues like data ownership and digital manipulation, restoring trust, and safeguarding user privacy.
Mina pioneers recursive ZK proofs in production developed the Snarky programming language, and has maintained a stable manner with no unplanned outages since launch (Our Focus, Our Future: o1Labs and the Journey to a Decentralized Internet with Mina). Recently, a new upgrade to enhance the protocol’s programmability was released.

In light of the above, our zkProver Engine will significantly contribute to the mass adoption of the technology endorsed by Mina by unveiling a vast array of practical use cases, thus empowering the Mina community to build a better Internet. That will be the first endeavor to bring the zk-proof technology that Mina endorses to mass use, which can unlock a vast market of real economics for Web3.

Solution

We offer zkProver Engine - a framework for creating and updating business objects representing real-life entities and an infrastructure for proving transactions with such objects. A user runs transactions with such business objects, the zkProver Engine produces proof for creating or updating the business objects, and the user verifies such proof.

Business Objects

A business object is the cornerstone notion in zkProver Engine. It represents real-world objects: bonds, cars, machinery, gaming objects, property, etc. A business object has fields with properties. One or several such fields contain a link to the frame in which custom logic is deployed. When a manager on the side of an Internal/External Party runs a transaction, a business object is created or updated according to the rules defined by an off-chain smart contract called in the transaction.

Business objects are created according to templates. A template should contain the following:

  1. Object fields - a set of fields with data type descriptions.
  2. Code link - one of the fields will contain a link to the frame where the custom logic is performed, as a result of which one of the fields will be updated.
  3. Proof Calculation Rules - the rules according to which a zk-proof is calculated provided by the zkProgram.
  4. Proof Sample - a JSON object provided by the zkProgram that’s a template for a zk-proof.

ZkProver Engine

ZkProver Engine bridges the Customer Service ERP on the side of Internal and External Parties that need to interact with their real-world assets through business objects and the Verification App on the End User’s end that verifies proofs about transactions with such business objects.

An Internal/External Party manages its assets in the ERP System. Business objects are created and updated as needed in the Customer Service App. zkCloudWorker runs a transaction and generates a zk-proof. The Verifier Service then verifies this proof for an End User. The End User can use their own Verifier Service or the Verification Service provided in the Customer Service App.

Gov_1
Gov_13554×2484 405 KB

Case Study

Let’s see a real-life example of how this should work in practice. Let’s imagine there’s an insurance company (External Party) that insures cars. A company manager uses the Customer Service App to create a “Car n “business object using the “Cars “business object template.
This business object will include the following fields:

  • model,
  • production year,
  • VIN,
  • license number,
  • insurance policy ID,
  • owner’s first and last name,
  • last insurance event date,
  • object version,
  • link field.
    The Object Version field is a counter showing how often the business object has changed its status. The Link field contains a link to the frame where the smart contract is called to execute the business logic.

One of the company’s clients got their car hit in a road accident and is now applying for indemnity for the suffered loss.

  1. The client provides all the required documents, and proof that it was an insurance event, and the company agrees to indemnify.
  2. The company manager sends the public input (information to be disclosed) and the private input (information NOT to be disclosed) to the Customer Service App.
  3. The Customer Service App uses private and public input to execute the logic; as a result, the business object representing the client’s car is updated, which means that the object version field is incremented by +1. The last insurance event date is recorded/updated.
  4. The zkCloudWorker generates a zk-proof and sends a transaction on-chain.
  5. A government authority (Police) must verify that the insurance event was lawful and due.
  6. An officer (End User) makes a verification request through the Verifier Service, which verifies the proof received from the zkCloudWorker and stores it in the database.

Architecture

The ZkProver Engine architecture embraces five environments: Customer Environment, zkCloudWorker, Marketplace Environment, Blockchain Environment, and End User Environment. This is what the architecture of zkProver Engine will look like.

2
24096×3764 828 KB

Customer Environment

The Customer Environment is intended to serve customers’ needs. Customers are companies and individuals that own business objects and provide public and private input for transactions to run with such objects. The customer Environment is where business object templates are created and updated, proof calculation rules are defined, and proofs are validated.

The Customer Service App is at the core of the Customer Environment. It has an application for creating business objects for Internal/External parties and an application for proof verification for end users.

The use case diagram below shows the role model in the Customer Environment.

3
34096×3651 865 KB

zkCloudWorker

zkCloudWorker is an infrastructure that runs transactions with business objects and produces zk-proofs. In other words, it’s an AWS for zk-proofs. This infrastructure includes Tx Builder, Validator set, Tx Compiler, Tx Prover, Tx Sender, Tx Monitor, and Tx Indexer. The use case diagram shows what each of these components does in zkCloudWorker.

4
41715×4096 316 KB

Marketplace Environment

We have two ideas about marketplaces: for zk-proofs and business objects. On the zk-proof marketplace, proofs will be listed, bought, and sold, while the business object marketplace will list business objects and templates. This means it will enable buying real-world assets on-chain, just operating business objects representing asset ownership. View the use case diagram to see what can be done in the Marketplace Environment.

5
54096×3041 503 KB

End User Environment

End users perform proof verification in the system. An end user may opt-in to request proof verification with the Customer Service App or verify proof in its own End User Environment using its own verification application or smart contract (see the use case diagram below).

6
63227×1937 173 KB

Blockchain Environment

We will use Mina as an L1 blockchain to run transactions and store transaction data. We will have a zkApp account through which the transactions will run. The MinaNFT V3 RWA contracts and metadata standards will be used, including ZkPrograms mutating the metadata and supporting ZkPrograms Plugins.

Modules

The table below shows the modules contained in the ZkProver Engine.

</tr
Module Functions Status
Business Object Designer Platform Create Business Object Templates MVP
Create Template Queries,
Create Business Objects,
Set Proof Rules,
Update Business Objects.
zkCloudWorker Sequence, order, and batch transactions, MVP
Validate transactions,
Produce proofs,
Compile transactions,
Send transactions on-chain,
Monitor transaction execution,
Index transactions for databases.
End User Verification App Verify proofs MVP
Router Service Register transactions with business objects MVP
Blockberry Platform API services MVP
Plugin Connector Platform Integrate plugins (external services) Future Stage
Decentralized Proving Protocol Generate zk-proofs Future Stage
ERP Integrator Integrate ERP of Internal/External Parties Future Stage
Proof Marketplace List proofs, Future Stage
Sell proofs,
Buy proofs
Business Object Marketplace List business objects and templates, Future Stage
Sell business objects and templates,
Buy business objects and templates.
DA Layers Decentralized Data Storage Future Stage

Platform Modules

The modules described below are the MVP of the zkProver Engine and will be implemented in the product’s first version.

Business Object Designer Platform

The Business Object Designer Platform is part of the Customer Service App and functions to build business objects and design business object templates.

A Manager of an Internal/External Party uses the Platform to create and update business objects via template queries. Designers use the Object Builder to create business object templates and template queries. Business object proofs are produced according to rules (business logic). ZkProgrammers in the zkProgram define each set of rules. Business objects created by Managers are stored in the Private Database.

This is the business object creation flow:

  1. A Designer creates a business object template in the Object Builder. The business object template is saved in the Private Database.
  2. The Designer creates a query template for the objects in the Object Builder. The query template is saved in the Private Database.
  3. A zkProgrammer designs the business rules in the zkProgram.
  4. An Object Creator/Editor (Manager on the External/Internal Party’s side) creates a business object using the previously created template.
  5. zkCloudWorker runs a transaction and creates proof.
    5.1. The transaction is recorded on-chain, and the business object state is saved in the Blockberry database.
    5.2. The Router on the Marketplace registers the transaction hash and status in the Router Database.

At any time, a business object template can be updated when the business logic has to be changed, which follows this flow:

  1. Business logic changes. The zkProgrammer updates the rules in the zkProgram.
  2. An Object Creator/Editor (Manager on the External/Internal Party’s side) updates
  3. The zkCloudWorker runs a transaction and creates proof.
    3.1. The transaction is recorded on-chain, and the business object state is saved in the Blockberry database.
    3.2. The Router on the Marketplace registers the transaction hash and status in the Router Database.

The diagram below shows the object design and registration flow.

7
7907×850 28.7 KB

zkCloudWorker

zkCloudWorker is an environment for generating zk-proofs for operations with business objects that run off-chain according to the rules. On the one hand, it is a prover machine that produces proof. On the other hand, it is a middleman between the customer environment and the Mina blockchain running on-chain transactions.

The table below shows zkCloudWorker components and their functions.

Role Functions
Tx Builder Sequence, order, and batch transactions.
Validators Validate transactions.
Tx Prover Produce proofs.
Tx Compiler Compile transactions and generate prover keys.
Tx Sender Send transactions on-chain.
Tx Monitor Monitor transaction execution.
Tx Indexer Index transactions for databases.

Let’s see how zkCloudWorker operates in a real-life use case.

  1. A Customer Manager on the Internal/External Party’s side needs to update a business object. Then, the flow and interaction between zkCloudWorker components and other environments will look as follows:
  2. The Customer Manager checks the business object data by querying in the Private Database.
  3. The Customer Manager checks the object’s current state by querying the blockchain node.
  4. The Customer Manager sends private and public input to the zkProgram using the Customer Service API.
  5. The zkProgram generates proof and sends the public input with the proof to the Tx Builder component of the zkCloudWorker through the Service API.
  6. The Tx Builder generates and orders a transaction and puts it in a queue for execution. Then, it batches the transaction into a data block and sends it to the Tx Compiler and Tx Prover.
  7. The Tx Compiler generates prover keys and sends them to the Tx Prover.
  8. The Tx Prover proves the transaction to the Tx Sender.
  9. The Tx Sender sends the transaction to the blockchain, and the transaction hash is sent to the Tx Monitor. The transaction is validated on the L1 and enters the L1 blockchain.
  10. The Tx Monitor queries the transaction status in the External Monitor API.
  11. The Tx Monitor sends the updated object state to the Indexer Database through the zkProver API, the Private Database, and the object status to the Router Database.
  12. The Customer Manager gets the transaction status from the Router Database.

The diagram below illustrates this flow:

8
84096×1507 431 KB

End User Verification App

An End User can verify proof using either their Verifier Service or the Verification Service in our Customer Service App.

Let’s consider a case when an End User chooses to verify proof using their Verification Service. The flow will look like this:

  1. The End User selects the use case in the application.
  2. The Verifier Service requests config from the Query Template and receives it from the Verification Service.
  3. The End User gets a response and makes a config-based verification request with the parameters and selected use case.
  4. The Verifier Service sends the filled form to the Verification Service.
  5. The Verification Service generates proof.
  6. The End User checks the public and the private input and verifies the proof by signing it. Then, it sends all this to the Verifier Service.
  7. The Verifier Service sends the verification of the proof commitment to the blockchain and gets a result.
  8. The Verifier Service runs the proof validity check by scanning the use case verification parameters.
  9. The End User is given the end binary result of the proof verification in the form of a boolean value: true or false. If the value is actual, then the verification was successful. If the value is false, the verification fails.

The diagram below illustrates the verification flow:

9
94096×3936 525 KB

Router Service

The Router is used to aggregate and route data into the Router Database. It performs the following functions:

  • handle events for the Marketplace,
  • update Marketplace objects,
  • handle verification requests and save verified proofs in the Router Database,
  • handle requests.

Blockberry Platform

Blockberry is an API platform developed and provided by Staketab that allows users to get reliable blockchain data. We plan to integrate this platform with the zkProver Engine. We will launch endpoints for various business objects as we partner with more projects and businesses.

Future Stage Modules

These modules are included in the future versions of the zkProver Engine and are on our product roadmap.

Plugin Connector Platform
There are lots of projects out there that provide valuable services with whom we can partner. We will use then the products of such projects as plugins. We integrate projects that use a Zk Program. One of our key goals is to foster the composability of zkApps, which is currently challenged.
The Plugin Connector Platform will be used to deploy and manage plugins like wallets or zkEmail.

Decentralized Proving Protocol
We plan to scale the zkProver Engine into a decentralized proving protocol.

ERP Integrator
Companies using our zkProver Engine might have their own ERP to manage real-world assets. We plan to develop an environment for integrating custom ERPs with zkProver Engine.

Proof Marketplace
Proof generation can be effectively marketed. With this in mind, we intend to create a proof marketplace where zk-proofs will be sold and ordered.

Business Object Marketplace
We can market not only proofs but business objects, too. On our Business Object Marketplace, External and Internal Parties can list the business objects they created when they decide to sell their real-world assets. In such marketplaces, real-world objects can be effectively sold and bought.

Business Object Template Marketplaces
It’s possible to market business objects and templates that designers create. It’s more about building business models and processes. Companies can create and sell or buy templates to tailor to their business needs.

zkProgram Marketplace
A library of ready-made solutions (samples, templates) with particular objects associated with a specific Customer.

Plugin Marketplace
A marketplace for zkProver integrations. Projects will participate in an online auction of integrations. Integration opportunities can also be sold to third parties.

DA Layers
We can effectively integrate zkProver Engine with already existing DA layers or build our own DA layer on Mina that can be used both by our product and external projects to store business object data.

Platform Security

We consider security paramount since we deal with private data that can be sensitive. This is how we ensure data security:

  1. Storing and processing private data in all modules in all steps.
  2. Possible solutions:
    • fully isolated customer and user environments
    • zkProgram on the Customer’s end.
  3. Cloud platforms with data center certificates.
  4. Change Trace for Auditing all the process stages
  5. Contract audits with MDA (Mina Developer Alliance)
  6. Transaction inclusion into blockchain state audit (reconciliation of Private Database and blockchain state)
  7. BOD Platform: authentication and authorization for all users and administrators.
  8. Compliance with European Laws (SOC 2, GDPR, ISO 27001)

Existing Work

  1. zkCloudWorker - a fast cloud-proving service designed for zkApps (zero-knowledge applications). It helps developers by providing a cloud-based environment to efficiently run and verify zero-knowledge proofs.
  2. Blockberry API - a data-rich multi-blockchain API platform provided by Stak
  3. MinaNFT Contracts & Proving Service - proof-of-concept NFT minting platform on Mina.

Budget and Milestones

Development Period

3 months

Stage 1

The goal of Stage 1 is to develop a proof of concept of the Customer Service application, which can interact with the zkProver environment and perform proving cycle operations.

Midpoint Milestones - Stage 1

  1. zk Cloud Proving Service Worker implementation.
  2. Blockberry Environment: zkProver API implementation.
  3. Blockberry Environment: Object State Database implementation.

Final Milestones - Stage 1

  1. ZkProver Customer Service App design.
  2. POC: Customer Service App Frontend - a web-server application run in a local host environment.
  3. POC: Customer Service App Backend - the backend application runs in a local host environment.

Budget Requested

100,000 Mina.

Budget Breakdown

  1. zk Cloud Proving Service Worker implementation (20,000 Mina).
  2. Blockberry Environment: zkProver API implementation. (10,000 Mina).
  3. Blockberry Environment: Object State Database implementation. (12,000 Mina).
  4. ZkProver Customer Service App design. (10,000 Mina)
  5. POC: Customer Service App Frontend - a web-server application run in a local host environment. (28,000 Mina).
  6. POC: Customer Service App Backend - the backend application runs in a local host environment. (20,000 Mina).

Wallet Address

B62qm5HhL5ESWzGMBRdzjVkRGD5ZzAf8YYErcXYyDbSy7o9EXUXMqnk

Team Info

Mikhail Korotkikh - smart contract developer

Vitali Horba - project manager

Ducca - solution architect, devops

Dzmitry Sakalou - analyst

Ilya Peker - analyst, designer

Evgeni Haurushou - front-end developer

Vitali Karpuk - front-end developer

Artem Brodski - back-end developer

Denis Streltsou - back-end developer

Proposer GitHub

Proposer Experience

Minascan Team:

  • Minascan;
  • Minascan Custom GraphQL;
  • Blockberry API platform;
  • Zekoscan;
  • Suiscan;
  • Staketab - AA-rated Verified Staking Provider.

Mikhail Korotkikh:

  • MinaNFT project;
  • zkCloudWorker;
  • Graduated from the Encode Club ZK bootcamp (October 2023);
  • Graduated from the Encode Club AI bootcamp (July 2024).

Risks and Mitigations

  1. Distributed Environment

Mitigation: Staketab’s experience in building distributed systems infra.

  1. Design Complexity

Mitigation: Close communication with real-world enterprises to utilize their experience and get valuable feedback.

  1. There are no similar systems on the market, and potential customers do not understand the features of ZK solutions.

Mitigation: We will prepare presentations explaining the technology and its advantages for non-technical executives.

3

Can you please describe what this frame is ? Is it a link to a zkprogram? How does it load it into context for any verification?

Can you elaborate on this, please? Is this the proof required for the correct state transition using the rules set out in the code link?

Is this a template to return the generated proof in?

How would the verification request look, and is it regulatory compliant in any jurisdiction to provide proof without the actual data? from @zk_kirol

I understand how business objects fit, but I don’t understand why the ‘proofs’ would be sold on the marketplace. Could you please elaborate? - from @zk_kirol

Is MinaNFT V3 RWA also part of this proposal? - from @zk_kirol

Do we allow backward compatibility and how do we manage in cases it breaks it? i.e if we remove an attribute from a data or add a new attribute to the template.

What if these two states are not in sync ? i.e private data and blockchain. It could be due to reasons of data loss, forks.

Could you please describe what query templates enable?

What proof is this? As I understood - the end user is using the verification service to attest some mutation or data values.

4

How do you envision the assets being exchanged and these rules being still applied? At the moment the focus is quite on the validation of the asset mutation/proof of valid transition.

5

Can you please describe what this frame is ? Is it a link to a zkprogram? How does it load it into context for any verification?

We mean a iframe in web browser: Frame (World Wide Web) - Wikipedia
Iframes start a separate process (not thread!) in the browser, thus protecting our main site. This process loads the site from the link provided, can do calculations, show information, and can be written in any language.
Therefore, we embed the site specific to the Business Object in our AI, and this site can calculate the proof and send it to update the business object.
An example of the implementation of running o1js in Iframe:
minatokens/src/app/page.tsx at dc07416548934e55c93984fb964650ff7dd193dc · zkcloudworker/minatokens · GitHub
It can be tested at https://two-o1js.minatokens.com/ by pressing Load Iframe with o1js button

Can you elaborate on this, please? Is this the proof required for the correct state transition using the rules set out in the code link?

The rules are defined by ZkProgram that is updating the state of the object. Therefore, the proof has to be generated for the correct transition between the states. We plan to use new NFT standard that define the states, and we will develop custom ZkPrograms for each Business Object. The example of the ZkProgram that can update the metadata by inserts only (“insert only” rule) is at
nft-standard-draft/src/zkprogram/update.ts at 6193f89113a3244b86d6bf64f337179f87551697 · dfstio/nft-standard-draft · GitHub,
the relevant test is at
nft-standard-draft/tests/contract.test.ts at d32db9c065e10961e35b42c74588c44b5cc32412 · dfstio/nft-standard-draft · GitHub

Is this a template to return the generated proof in?

Yes, it is the template that describes, in technical terms, publicInput, privateInputs, publicOutput, and auxiliary data of the proof calculation result as in the example nft-standard-draft/src/zkprogram/update.ts at 6193f89113a3244b86d6bf64f337179f87551697 · dfstio/nft-standard-draft · GitHub

It is the interface for the Business Object update, similar to ABI in Ethereum.

How would the verification request look, and is it regulatory compliant in any jurisdiction to provide proof without the actual data? from @zk_kirol

In many (but not all) countries, self-certification is practiced. For example, in Italy, there is autocertificazione: Italian law allows individuals to submit self-declarations instead of providing certified documentation from a government office. These are legal statements in which the individual declares certain facts to be true, without the government initially verifying them. However, there are serious (even criminal) consequences if a person lies or makes a false declaration. The examples are residency, personal data, income, educational qualifications.

In our example, it can look like this:
-The officer submits a verification request through the Verifier Service to check autocertificazione.

  • The service generates the proof to confirm that the insurance company has this incident record without disclosing confidential information
  • The officer receives a confirmation

It is recursive, so the officer can check the validity and availability of insurance company data.

I understand how business objects fit, but I don’t understand why the ‘proofs’ would be sold on the marketplace. Could you please elaborate? - from @zk_kirol

Yes, we can give an example of a specific use case for purchasing proof.

A corporation or individual buying something usually conducts due diligence, which can be costly for certain assets, such as real estate. Purchasing proof that verifies the asset’s condition would reduce the buyer’s risk and help save on due diligence costs.
The good example is Representations & Warranties Insurance: https://woodruffsawyer.com/sites/default/files/document/Guide%20to%20Representations%20and%20Warranties%20Insurance%202024.pdf

Is MinaNFT V3 RWA also part of this proposal? - from @zk_kirol

This proposal does not include the MinaNFT V3 contracts.
We will rely on the new NFT standard, developed based on MinaNFT V2. We will prepare an additional MinaNFT proposal incorporating the new NFT standard and including metadata, zkPrograms, and a new frontend.

Do we allow backward compatibility and how do we manage in cases it breaks it? i.e if we remove an attribute from a data or add a new attribute to the template.

The data is stored typically as MerkleTree, with the interpretation of the data left to the definition of the Business Object. When we upgrade the business object template, in technical terms, we change the verification key of the sideloaded ZkProgram, and the new ZkProgram can have an incompatible representation of the data, as you pointed out.

If it simply adds the data, like new keys to the MerkleMap, then at the moment of the upgrade, we have an object representation compatible with both old and new ZkProgram.

If not, then ZkProgram should have a method that converts in a provable way the old data representation to the new data representation once.

What if these two states are not in sync ? i.e private data and blockchain. It could be due to reasons of data loss, forks.

It can be solved in two ways:

  1. A Typical way is to have regular backups and reconciliations of the data in the private database and the blockchain and organizational measures to prevent it. Using a database structure that keeps all the history (commit-like) will also help. It is possible right now.
  2. The better solution would be to use DA layer. We are actively looking at the various DA layers, to find the layer that supports the Poseidon hash or agrees of adding the Poseidon hash. Another variant is to use Blake hash which is present both in o1js and sui, to use sui or DA layers based on sui as data availability layers. We also have the expensive option of using DA proofs on Celestia.
    As soon as one of those alternatives becomes feasible, we will use it.

Could you please describe what query templates enable?

Query templates describe the fields that can be requested to be proved, or inclusion or exclusion proof can be created for the field. Those are Business Object-specific fields and typically are the properties of the object.

What proof is this? As I understood - the end user is using the verification service to attest some mutation or data values.

Yes, it proves the state of the object, or, in case of update, the mutation of the state according to the rules defined by ZkProgram

6

How do you envision the assets being exchanged and these rules being still applied? At the moment the focus is quite on the validation of the asset mutation/proof of valid transition.

We have two cases here:

  1. Changing the ownership of one asset. As new NFT standard will be used as the base, we can use the owner field that is being changed as the result of L1 transaction or as the result of the valid ZkProgram proof presented. In case the owner is defined in the metadata (like tax number of the owner and not the public key), only ZkProgram proof is applicable.

  2. Exchanging the assets where we should have atomic operation on two different Business Objects. Technically, we are unable to do it now as one L1 tx that updates two Business Objects; for example, it is not possible to implement in one tx now Fungible Tokens swap due to the limit of 5 AccountUpdates with proof authorization. It means that we need to split such operations to several transactions, effectively creating escrow arrangements in some way similar to the Escrow example in Fungible Token. The mechanism will be as follows:

  • Escrow Business Object is being created and deployed (tx1)
  • Asset 1 is transferred to Escrow (tx2) by Owner1
  • Asset 2 is transferred to Escrow (tx3) by Owner2
  • Escrow confirms that conditions precedent are met and the asset exchange is executed (tx4)
  • Asset 1 is taken from the Escrow by Owner2 (tx5)
  • Asset 2 is taken from the Escrow by Owner1 (tx6)

In a more complicated scenario, some parts of the Assets (guarantee deposit) will be held in Escrow for 12 or 18 months, and at the same time, the payment for Representation and Warranties Insurance will be made out of the Assets to the Insurance Company. More details on the M&A process applicable in this case can be found in the report I have shared above.