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.
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.
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.
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.
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.
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.
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:
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.
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:
One of the company’s clients got their car hit in a road accident and is now applying for indemnity for the suffered loss.
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.
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.
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.
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.
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).
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.
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 |
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:
At any time, a business object template can be updated when the business logic has to be changed, which follows this flow:
The diagram below shows the object design and registration flow.
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.
The diagram below illustrates this flow:
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:
The diagram below illustrates the verification flow:
The Router is used to aggregate and route data into the Router Database. It performs the following functions:
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.
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.
We consider security paramount since we deal with private data that can be sensitive. This is how we ensure data security:
3 months
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
Final Milestones - Stage 1
100,000 Mina.
B62qm5HhL5ESWzGMBRdzjVkRGD5ZzAf8YYErcXYyDbSy7o9EXUXMqnk
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
Minascan Team:
Mikhail Korotkikh:
Mitigation: Staketab’s experience in building distributed systems infra.
Mitigation: Close communication with real-world enterprises to utilize their experience and get valuable feedback.
Mitigation: We will prepare presentations explaining the technology and its advantages for non-technical executives.
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.
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.
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.
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
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:
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
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:
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.
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:
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.
Thanks for this! It’s an excellent proposal written with great detail in a way that even non technical people can understand. The user cases are especially helpful.
Good luck!
Great proposal! I can see how zkProver has the potential to bridge the gap between the capabilities of zkProofs in Web3 and practical applications in the broader business world, which would be really good for the overall space. I sometimes think we are just waiting for that killer app that could unlock the potential of zkProofs in the real world.
I have had some thoughts about the potential use cases that integrating zkProver with zkUSD, a native stablecoin on the Mina protocol, could open up.
Index-based insurance simplifies crop protection by automating payouts triggered by predefined conditions such as insufficient rainfall or poor vegetation health. This process eliminates the need for manual inspections and paperwork, making the system more efficient and accessible for farmers.
This is a super interesting, and powerful use case. zkProver could allow for collateral diversification as a potential way to scale zkUSD. zkProver can integrate off-chain Real-World Assets (RWAs), such as liquid financial instruments (e.g government bonds or treasury bills), as backing for the stablecoin. This ensures that zkUSD maintains its peg while unlocking additional liquidity.
zkUSD, integrated with zkProver, can serve as a universal, decentralised payment vehicle associated with programmable provable objects. This integration unlocks transformative applications across various industries by enabling secure, transparent, and automated transactions tied to object states or conditions.
These use cases highlight how zkProver and zkUSD could complement each other. By integrating zkUSD as a stable and programmable payment vehicle, zkProver’s framework could really expand its value proposition as an end to end solution for some of the use cases listed out in the proposal. I’m really interested to see how zkProver develops!
