Closed bitwiseguy closed 4 years ago
Given the title of this we can consider it to be completed as part of the init-core privacy work. Between the core/privacy
package and the examples/baseline-app
reference implementation, all of these considerations will have been accounted for when init-core review is completed and ships.
Overview
Currently, Radish34 utilizes zkp circuits that are specifically designed to enforce business rules for supply chains (i.e. tiering structure of MSA). To help accelerate the adoption of the
baseline-protocol
by enabling any document to be "baselined" between multiple parties, we need a generic zkp circuit that is not tied to a specific use-case. The structure of the circuit is supposed on the following "core" components/statements to be proved/verified about the exchange of a generic document object between 2 parties:a. The commitment of the document object is well formed, i.e., with the choice of the hashing scheme the commitment of the document can be proved to be the same as that computed outside the circuit b. The commitment is co-signed by both the parties and the signature is verifiable c. The root of the merkle tree calculated based on the commitment stored at a leaf index is consistent with the corresponding root on chain
Assumptions
Overall workflow considerations
General baseline document workflow requires the following steps:
Tasks
baselineDocument.zok
to model the business logic@baseline-protocol/privacy
module built as a typescript interface (test with leveragingzokrates-js
) with Rust@baseline-protocol/privacy
to bind rest calls made via golang to integrate with atomic functionalitiesWorkflow Integration Tasks
Based on
simplify-msa-process
branch andintegration/simple-test.js
, as an example workflowcreateAgreement
zkp circuit exists in zkp service libraryapi
service supports graphQLcreateAgreement
requestcreateAgreement
circuit viaenv.dev.env
filecreateAgreement
createAgreement
circuit