[Music] So, so why does it matter like we've seen like in the snark uh in the snarkified section projects we have like zkls passport projects even national identity card projects like anonadar and eu ID uh projects. So all of the projects have something in common which is like signed data and the signed data are like signed by uh official government or different entities. So one of the unexplored part was like PDFs. So so this project about like proving data rich statements within PDFs. So you could able to prove web two data into web three.
You could able to prove uh port web two data into web 3. So this like uh so yeah. So what are the use cases for zkdf? So the the important use cases for ZKPDFs are like finance and KYC's and the also like you could put web two data into web 3 and you could prove financial transactions. You could prove digitally signed documents by your government or any entities such as like diger or docyign.
So what are the example statement I could like prove right now? I can prove I I own a degree from like uh college without revealing the entire like full document. So you could like uh prove that you did a transaction from person A to person B with a some bank and you could do all of this stuff. So you could do age claims as well like let's say you have like a PAN card document and you wanted to prove with the PAN card is uh the age is above 18 you could do that right now uh with ZK PDF stack. So yeah so who why does it matter to like who signs this document?
So one of the important injunions for us to understand is like who signs this document. So for any like documents so the signer is uh the authority who signs the document let's say uh in in the case of DJ locker documents you could like download all the uh documents from financial documents from your uh financial legal all the driving license documents from DJ locker. So Indian government signed this docu uh sign all of the PDFs for you and they use the same key to sign the documents. So in theory you could just like port the uh public key out and you could like prove whether this document is signed by Indian government or not. So this uh opens like new era of like data statements.
Uh you could like prove all of this within the ZK PDF stack and financial institutions such as like banks uh banks like insurance provider they use this ZKPDF uh they use this uh signing uh mechanism uh all over the PDFs. So yeah, so how does the ZK PDF stack works? Generally when the user uh uploads a PDF into the app, so the PDF sends this input signals or inputs to the proer. In our case, the ZK PDF uh has the remote SP1 prover. And once the SP1 prover gets the inputs, now it will generate a proof for you.
You can generate a plon and groth 16 proof uh within the prover and you could generate uh proofs within the circuit. And once you get the proof, you could verify this proof in any EVM compatible blockchain such as like E, Arbitum, Ethereum. So the verify is a smart contract and the circuit uh the circuits are in like SP1 circuits. You could like uh put the S uh ZKPDF grates into uh SP1 circuits and you could like prove all of the statements uh inside ZK PDF stack and you could uh put all of these proofs into verifier contracts. So what are the current limitations for ZKPDF stacks?
Currently uh the proofs are generated over server side. So completely uh we have partnered with sustain labs for uh pro network access. So if you want to generate proofs uh you could currently you have to use SP1's pro network to you generate proofs and why so why not client side. So the uh there's like a heavy computation uh to perform the uh zkdf put the zkdf stack into uh cl clients are tech because we have to hash like megabytes of data and we have to prove all of this inside zk snack which is not feasible right now. So that's the reason we stick we are sticking to client side stack.
So in the upcoming months we actually working on u making the zk pdf stack completely client side. So yeah this is all about like zkdf. uh so so let's say you wanted to verify whether the PDF is signed by uh any entity or not and you wanted to verify which whether it's whether it is compatible with Zik PDF stack or not so this is a website uh which has this compatibility check where you could do there are two methods actually one is extract plus verify and the second method is substring with offset so what I have is like let's say I have this document called GS certificate Right generally. So currently what you can see is like uh it says like it is compatible with zkdf stack and the signature is valid and this is the same uh public key which is signed the uh document and you can see all of the extracted information which says like register number all of the legal name and like train name all of the information. So this PDF is digitally signed by Indian government and let's say I wanted to verify.
So the first part is like extract and verify. So what it does is like it extracts the signature from the PDF and it will verify the signature from the PDF content and it will throw it will send your output for all of the text. So if I click on so it it's also already verified. So what the second method is like let's say you wanted to prove some content. Let's say I wanted to prove uh this is the train name I wanted to use.
What I could use is like I could like keep it here and I wanted to select the page number because there are multiple pages to this PDF and let's say you wanted to verify whether this stop string is in the main PDF or not. You could like do verify check. So it says like text uh consumer entity and trust association found at offset 307. Generally offset is a index index of the string where this is the entire uh string. it is a offset where you wanted to check whether the substring is present the main string or not.
So this is the compatibility check where you could verify whether your PDF documents is like compatible with zkdf stack or not. The second part is like uh we have like bunch of circuits. Uh so this is the main repo and main repo has this package called zkdf uh lib. So you don't need to like set up the entire repo. You could just set uh set up uh the sp1 template.
So currently uh so the SP1 template looks something like this. So you need to set up uh ENV variables uh you need to get the uh network private key. So once you generate a private key for yourself you need to send me the public key address so where I can whit list you for the pro net access and you need to change this sp1 pro2 network and then it should be good to go. You could able to verify uh zipf proofs uh within this template. So I'll quickly explain what's the intuition behind like all of these things.
Let's say for any circuit you have inputs and you have outputs. So for inputs you have the input for the uh this certificate is like you have the entire PDF bytes. So the we are inputting the entire PDF bite and we are outputting the so we are outputting this truck which is like a GSC number and like a legal name and whether the signature is valid or not and with the document commitment and public key hash. So you could verify whether the document is signed by Indian government or not with this public key hash parameter. So so the lib is like a rust grade and program is for the circuits and samples is a GSC PDF.
This is a sample document which is signed by Indian government and these are the scripts and the scripts you so there are like two ways you could generate proof. One is like a core proof which uh generates within the local uh server side setup and the second is like a proet. So if you want to utilize the proet you I have like abstracted on the API server for you. You could just like run this command. It will create a API server for you where you could send a proof request to the uh sinking proven network.
Uh there's a little demo which I have. So right now it's like a HTML file. So, so this is a sample website. So, what I need to do is like I need to give uh the entire GCP certificate. Okay.
So, once you have the certificate, so what I'm doing is the verify and extract method instead of offset for the simplicity. So, let's say you click on generate proof. What it does is it sends the entire PDF inputs to proer network and it will compile the uh circuits and it will send to uh it will generate a proof for you. So you can see like uh there are like uh these are the like gas limits and this is a cycle. Uh so you could like you could see your proof requests in the explorer.
So it generally takes like around 20 to 25 seconds to generate like a uh groth 16 proof. So yeah, so once this proof is generated, you could like uh get the proof uh on the website and then you could with the proof you could like uh generate onchain commitments and you could verify whether the proof is valid within smart contracts and you could do verify proofs on the two methods. One is like onchain, one is offchain. Uh so yeah like you could verify this proofs. So so let's see uh whether the proof is generated or not.
So while the proof is generated I quickly explained like two methods. So we have a documentation for the all of the ZKP PDF API. So if you look at uh API references let's say there are like uh two important methods like uh we need to understand one is like a verify text and one is like a verify and extract. So let's say you wanted to build some custom circuits. Let's say you wanted to prove uh you did some bank transaction from person A to person B and with some specific amount.
In that case what you need to do is like you need to verify the signature the first step and then you need to extract the signature u you need to verify the sign uh extract the signature and you need to extract the commitments and then you need to extract the text as well. Once you have the text, you could like generate like string manipulation or reax techniques to uh scrape out the content you want to uh tackle. Something like here I'm like in the current certificate I'm like snark I'm I have this program where uh it takes this reax patterns it will get me like a exact string for GST number and like legal name. So once we get this uh parameters we could able to commit to onchain. So so as you can see we have a proof generated.
This is a gross 16 proof. So these are the public inputs and this is a encoder proof and you have like a raw proof which is like a this is a wiki hash and this is a verification key hash. So yeah so once you have this proof you could verify this proof uh within this contracts folder. So, so this is a simple contract uh which takes which verifies this GST pro which has this exposed method called GST uh verify GST method. It will take public values and prove bytes.
What it eventually does is like it will verify G 16 proof first with a verification key and the second it extract all of the public values. So once you have the public values like GST uh number, legal name, signature the signature is valid or not and the document commitment and the public key hash. So I'll quickly explain what are the uh commitments why we need to use this commitments. So let's see uh so here we could see like uh so document commitment let's say you have like multiple apps where you want you have like multiple poofs. So what we can avoid is like you could uh gate keep the proof to use like only once at a time with uh document commitments and if you see the construction of document committee it's like hash function of some uh message digest and signed data and like few uh nons.
So if you see uh document commitment it's like uh message digest GST number legal number and signature. So for every PDF this is like unique. So you could able to determistically generate like a commitment and you could able to use that commitment to uh avoid like uh avoid like multiple proof uh validations. So yeah this is pretty much uh about like SP SP1 ZK PDF template. So yeah so so there are like few other API methods as well.
is one is like extract and extract text which only extract the text from the PDF. It doesn't verify any signature and the second method is like verify signature. So the verify signature take all the PDF bytes. It will uh return a type called signature result. So this function verifies the signature and like it will tell you whether the signature is valid or not.
So there are like few uh supported the lib only supports like RSA with uh SHA and SHA 256 and 384 and 52L. Uh currently we don't support ECDS signature and like let's say if your PDF has like uh like the chain of authority. Let's say it's signed by two three public keys. We don't have support for that. So and so we'll quickly see what are the FAQs for that uh any FAQs.
So, so what are the PDF formats like we support? First thing the initial check should be that it should be digitally signed and the second should be like uh we don't support like images. We don't support uh form fields, ECDS and complex layouts like uh you have like a image you have some code like we don't support all of these things. The most of the things we support is like text section and like signature and like we have like multiple page document support and we have like complex seams and let's say if your document is like a different language like Chinese Japanese we do support that as well. So so these are the uh uh signature algorithms supported.
So so also like one of the important questions we got was can I run CKPF on the client side like somewhere like truly client side over mobile or browser. uh currently we uh we can't because of the hashing complexity in the circuits. So yeah so how could I like integrate zkdf within the application so at the end of the day you could like make a API simple API which takes a PDF input and it outputs a proof for you and you have like some smart contracts deployed over EVM chains and that should be good. So there are like few instructions for deploying your contracts as well. So so you have like you could so these are the pre-built contracts.
You could just uh use all of these contracts here. So so this is a link tree. We have like a telegram group and this is a compatibility check and we have like a documentation uh which has like all of the proving API. Uh let's say you wanted to get access to sassing pro network. There's a form as well.
So please fill the form and like you have to fill your team name and your public key details and once you you have that like you need to go to SP1's explorer page and so so you need to connect to SP1's explorer page and you you need to collect your wallet it. So there are like two websites actually one is like uh explorer.sussing.xyz and like explorer.reserve.
s. So we are using this network. So we'll quickly like So you need to like sign this request. So once you have signed into this. So so you could see all of the proofs and all the transactions you created.
So we have like a limited credits for uh hackers to play around with in the SP1 network. So on the regarding the benchmarks, so we do have like a benchmarks. I'll quickly show the So these are the benchmarks. This is a proof size and so what the PDF is like uh RSA with shavan and the second PDF is like panc document from DG locker. So it uses the same sessing version and it takes around 52 seconds and the second uh PDF takes like 31 seconds to generate the proof and the these are the number of cycles and this is a gas cost.
So you could like quickly go to the blog section. We have like bunch of docs and we have like a bunch of uh templates you could play around and we have like a set of like PDFs you could play around. Yep. I think this is pretty much it. [Music]
Automatic transcript — names and jargon may be misspelled.