Proof Over Promises

Transcript

[applause] >> Hey everyone. Uh thanks for being here. I am Dipti, co-CEO of O(1) Labs. We are the team behind Mina Protocol. Uh one of the first ZK zero knowledge blockchains out there. Um but this talk is not so much about blockchains. Um it's about a problem that many of us in this room will run into within a few years, right? Whether you're a security insecurity, whether you're in operations, or just running the business, right? You um increase There's an increase uh reliance on systems, vendors, and now AI

agents uh who you cannot really check, right? So, my argument for this talk kind of fits in one line, which is the the statement under the title, make trust verifiable. Right? Um it's you don't um you it's proof over promises because you want to move beyond promising what your systems can do, what your systems can provide, and instead of handing, you know, building more and more trust, you start handing over more proofs. So, let me um let me you know,

show you what it is. Let me dig deeper, and also share why now. Okay. Um first thing, I guess I want to address one concern when most people maybe uh hear about zero knowledge proofs is that maybe it's a cryptography paper, or maybe just like private tokens. But zero knowledge proofs, you know, has gone mainstream quietly, right? Google uh ships zero knowledge age verification in Google Wallet now, which lets you verify that you're above 18 years and without revealing who you are.

Microsoft is uh also integrating a ZK uh based credential system in their identity offering. And and EU is uh mandating digital identity for its member states, and they have a ZK based design in uh in their road map. And um in addition to this, like in crypto, it's been proven for many years, and it's continuing to be battle tested. So, you know, and that's where everything started right?

We know in crypto, zero knowledge proofs um have been used to achieve mainly two things, right? Privacy and scalability. Privacy lets you transact um without sharing who you're uh transacting with, without sharing what amounts. And so, you can have transaction level privacy, but also application level privacy. You can um build zero knowledge based applications, run it off chain, have your data private, and then verify public statements on chain.

So, that's privacy. And uh second use is scalability. So, ZK rollups um compress thousands of transactions into one proof, and then, you know, uh and then submit that proof on chain. So, this way you can really like scale um a lot of the um uh systems in Ethereum. Actually, Ethereum's uh large Some of the largest L2s are ZK based, right? So, we are proposing uh a third usage, which is verifiability, right?

And verifiability isn't something you need to bolt on into ZK systems. It's It's an inherent property of uh zero knowledge uh systems, right? A SNARK at its core is verifiable computation. You provide a proof that you executed a particular computation, and uh a third party can verify that proof and not have to compute, you know, run that computation themselves. So, it's um ZK gives you verifiable computation, and that's what enables, you know, some of these usages like privacy and scalability.

So um we want to propose using verifiability, but pointed to enterprise workflows, right? What we want to do is within enterprise systems, um identify workflows that involve policies, which end up uh governing high-stakes operations. And we want to start um using ZK to provide the same guarantees that blockchains and these other use cases have seen, but within within that problem space.

Um and so, it's you know, making enterprise operations more provable, not just fast or um private, but but provable. Okay, so why now, right? Um and for this, I want to say two forces kind of pushing in the same direction. Uh on one side, you have AI on the offense. Um threat actors now are using AI across the the whole life cycle of attacks, right? And the first AI-generated zero days are being reported, and there were so many reported last year, and more happening as we speak, right? Um the surface of

um systems are being probed faster than some of us can really respond to. Um and that's concerning. The second one is AI as an actor, right? We are now authorizing agents to do stuff on our behalf, to use our data, and go out there and do agentic things. Um and this for such a system existing um existing sis existing guardrails and trust mechanisms don't scale well because um you're you're dealing with softwares

that multiply by the week, right? So the common thread here is that you depend on actors that you cannot verify. And and the solution is not more trust, but um proofs that you can check. Cool. So what are we proposing? Um how do we use verifiability? What we're saying is move from this model where you trust systems, you trust agents, you trust operators to follow the rules who are then allowed to act um after that, right? And so we want to

move from this system to another system where the action that you want to guard is um logged until a proof shows up saying, "Okay, this is valid. We've executed um Um, all the policies, and here's a proof of that execution or the enforcement. And no matter who's asking, like something that helps me think of ZK is like this this notary who cannot be bribed. So, you just, you know, you encode the rules and you say like this has to be executed, then this has to be executed.

Um, and so the the shift here is that proof becomes part of like what authorizes these high-stakes operations. And um, and so you can think of it as an additional layer in your existing controls, um, in, you know, that guards high-stakes operations. Um one thing that I do want to mention a little bit here before I uh, talk more in in a later slide is that this is not really abstract, right? This um, it's it's happening now and so you can, for an example, think of this, imagine this world where you want to

transfer funds in your treasury. I'm sure every one of us here would have done some version of that. And of course, you have a a list of rules, policies, you know, who gets to authorize, who gets to set what limits are, and imagine all of that being proven in addition to like checked, you know, how it gets checked normally checked. So, in addition to that, you have a proof that these uh, policies were enforced and that's what will um, decide whether you want to execute a tran- transfer or not, right? So, that's hopefully that uh, use case is somewhat

closer to home. And this will all start making sense, but um, I'll talk more about that. Okay, so what is this, right? Um, it is essentially a verifiable workflow. What's mechanically it's really three steps. More like two. One is The third one is as it exists, but the first step is you have a an existing policy, your rulebook, your policy engines of your enterprise application um and or processes. You encode them or we encode them for you in a ZK application or a ZK circuit. So, you have this small component of prover that

runs in parallel to your policy enforcement. So, you have an existing policy enforcement, you have you run another one in parallel, which is ZK based. And that produces a proof. It's a self-contained artifact which you can then um submit it to another component of your flow of your workflow where which actually verifies if um if the rules have been held. Right? And that's where that's the second step. You have another component um that would verify that the proof is valid. And um it's not only that it's valid, there is uh the statement that it validates is

also what you are expecting. Right? And then that's what would then execute the high-stake operation, whatever that is, whether that's a transfer or an agentic step. Um That's the the That's the final step. Cool. So, um what can we do with with this new um additional layer that you would have in in your existing workflow? Right? First one is you have a receipt. It's a cryptographic receipt that uh shows approves that the rules were enforced.

Right? And like I said, it's it's a self-contained piece of artifact. It's a proof and there is a statement about that proof and you can ship that proof to whoever wants to verify it. Right? And in one case, it's your own system because you want to verify the proof and then execute the action, but in another case, you uh send that proof to your auditors, maybe even your customers to show um you know, to give them additional assurance that you have executed um all of the policy that you agreed with your customers.

Um it gives you an audit trail per action. Right? This is for each transaction, you would execute this workflow. So, every transaction or every um every instance of a workflow will go through this and so you have a an audit trail of a a finer detailed audit trail compared to something like, you know, sample checks over some X days. Right? So, you you do have a finer detail.

And this again can be used for audit purposes, more assurance, same thing. And finally, this one um is probably not as explored, but ZK is used in the blockchain setting because it, you know, there are there's the inherent trust assumptions and so when you cross that trust boundary, you want you want more assurance. So, when you when you take that similar concept out to enterprises, there may be workflows um within your organization that spans um multiple organizations. Right?

And if you want an end-to-end proof of all of the policies that have been enforced, then you can start incorporating multiple parties within this workflow and they provide a proof along with a statement of what policy has been enforced. And and you can combine them into a single proof that then gets checked at the very end. This sort of composability is you know, achieved using the ZK infrastructure. I don't want to go too deep into the technicals, but if you're interested, definitely come and talk to us and we can share more.

So yeah. Now, like I said, sorry, I think Okay. Now, one thing that um objection that I get when I speak to people is that um you know, you're you're suggesting rip and replace, replacing an existing attack surface with a new one, but that's you know, that's not what we're proposing and ZK makes it very easy actually. What we're proposing is an additional layer, right?

We want this to be additive to your existing flows and so adding this is an additional layer, it gives you a different kind of of workflow than any systems exist out there. So, you have like heterogeneity of you know, the security systems that you put in place. Um and even better is how incremental ZK can be or does this framework can be because you can pick one very narrow, high value flow encode that into ZK, execute execute a proof, generate a proof, verify it and incorporate into your workflow. If that

works, start adding more and more policies into that system. And so now you have like a whole uh or layer of all of the policies that you've built. So, it's it really allows you to It's the composability aspect or aggregation of proofs that allows you to do that. So, it's um I would say it's easier to adopt such a system even though it's it's um uh it's it's new in in enterprise setting. Okay. Now, um this pattern um I gave you like a glimpse very small use case of how you can imagine it, but it kind of reshapes a lot of domains,

right? If you take off If you If you uh talk about institutional finance, anytime there is money movement, for sure there is a rulebook, for sure there is a policy. And depending on how um how big the transaction is, you have stricter rules. And so, you you know, you And there's like all of these processes set in place to make sure those policies are enforced. And so, ZK-based um policy engines can be like really useful in in institutional finance.

AI and agents Let your AI agent prove that it followed policy without sacrificing the data it acted on. And this becomes more prominent when you start having systems with multiple AI agents. They're all interacting. One AI agent delegates to some other agent, so you start seeing um delegation of workflow of information. And now you're back to like, you know, existing systems trying to apply them to agentic systems, and they don't really work well. So, um AI agents identity Identity I In my opinion, is the simplest use case of this. You You verify and your identity, you get access to some You get access to your system or

you get access to some data. So, it's it's the simplest example of how you can enforce a policy which in this case is identity based to into your enterprise workflow. And you can combine other policies with identities and identity and other credentials to make start making complex policies. And then more broadly in in the enterprise operations like anytime there's either a vendor integration or any policy that needs to be enforced, um you can run a para- parallel uh verifiable workflow along with it.

All right. So, if there's one thing that um I want you all to take away from uh this talk is that whenever there's in any system there is a high-stakes operation that you want to protect and guard and you have a set of rules that govern them, then you want to build an additional layer of uh assurances and guarantees using a ZK-based uh verifiable workflow.

Right? So, next time you encounter such a problem where you have a consequential action and you have policies, they may be they may exist you know, systems or processes to enforce those policies, but you can add a ZK layer to make those um policies verifiable to produce an end-to-end uh proof that your policy has been enforced. Uh and when you do that, definitely come find us. Um if this resonates with you, um definitely come to us, you you bring a real workflow that uh that you have encountered and we will um show you where verifiable proofs can

be added, where uh and what you get out of that, right? Based on your existing systems, what value you would get out of that. And so, we have a booth here, so definitely come talk to us. And uh if if not, if that doesn't work, uh you can also email us at partners@omenlabs or um contact me on Twitter. All right. Thank you. >> [applause]