Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
o1Labs Partner Program: Episode #1 with Veridise
Recorded: Nov. 29, 2023 Duration: 0:48:33Space Recording
Full Transcription
John, can you hear me?
Yeah, I can hear you.
Cool.
That's a good point.
Hey, by the way, we've got listeners who are going to join LA, I'm sure, because they're
diligent.
So, I'm just going to put my ear pods on, bear with me.
Pete, as co-hosts as opposed to speakers, is there anything we need to do?
No, I think you're okay.
You can just talk.
I think we can just have two co-hosts.
I might be wrong.
So, I think you can all just chat between yourselves without any problems.
Okay.
And then, presumably, we have the power to allow people to be speaking to them.
I think you can ban people and kick people off and stuff like that.
Hopefully, you won't need to do that.
I should admit the opposite.
Let them speak.
Let's see.
Can you hear me as well?
Yeah, it's pretty muffled, though, at the moment.
Do you want to try again?
Hello, hello, hello?
Yeah, it's quite tinny.
I can't even give me a second.
Don, do you want to try your line, by the way?
Yeah, sure.
Can you hear me all right?
Yeah, perfect.
That's great.
What about now?
Yeah, much better.
Yeah, that's better.
Yeah.
So, what about now?
Yeah.
I don't know.
Oh, I should mute everybody, like, right, and then unmute speakers.
John and Florian, you just want to check you can unmute yourselves?
Yes.
Yeah, yeah, cool.
I think I can.
John, you able to unmute?
Maybe not.
Pete, can you unmute John?
I'm going to unmute everybody for a second here.
Yeah, there you go.
Everybody's unmuted.
Okay.
Yeah, it just had a thing that said muted by host, so I wasn't able to unmute myself.
All right.
You might need to do that.
Mute everybody else.
All right.
John, can you unmute now?
All right, Pete, I think we might have the same issue.
Yeah, I think that's one thing.
Because John's a speaker, I'm not sure he can unmute himself, so he can just keep an eye on that.
It's fine.
I can't unmute him individually, apparently.
All right, well, we may just have to go with an open call.
Do you want to do that?
Okay, I can unmute myself again now.
Okay.
Pete, if you've got any ideas, let me know.
But I don't see any option other than to mute everybody, and then John can't unmute himself, so.
Yeah, I think when you're unmuting everybody, I think it's just the speaker, so I think we're okay.
Okay, all right.
Yeah, everyone else other than the four of us are just listeners, so I don't think that anyone else would be able to talk.
All right.
It's been a long day already.
Good point.
All right.
Okay, well, why don't I get started here?
So, just give me one second.
I'll be all right with you.
Cool.
All right.
So, I'm going to kick off here with a quick formal introduction, and then we can get into the meat of the real conversation today.
So, we're talking to John Stevens, who is the CTO of Veridice, on the topic of building a ZK application with O1.js.
O1.js is the SDK that O1 Labs has released.
I'm Phil Kelly.
I lead business development at O1 Labs, and I'm here with my engineering colleague, Florian Kluger.
We're planning on talking for about 30 minutes before opening up the conversation for wider participation.
And, excitingly, John just published the code that we're talking about here on GitHub, so that's exciting.
We'll probably drop the link into Twitter later.
And, yeah, it's really great work, John.
We've seen partners obviously build SDK-based code to POC level and even beyond.
And, you know, yours is really great and very rich, so we appreciate the work there.
All right.
So, just a little bit of background.
This is the first in a new series of weekly Twitter spaces with projects in the O1.js partner program.
The partner program is here to help existing Web3 projects as they get experience building ZK applications.
And you may already know, but just a reminder, ZK applications are applications where you can build code that runs on the client side.
So, built on the client side in ZK code, and you can then execute it and prove correct execution back on a blockchain.
And so, that's how you get privacy, for example, in the Web3 world, finally.
And it's also how you avoid gas costs and latency and data challenges that we've seen that working entirely on-chain can bring.
But, on the other hand, it's still trustless.
So, that's the exciting thing about ZK applications.
It's kind of a new construct to the Web3 world.
And so, you know, hopefully it makes sense from a conceptual level, but we really want to bring it to life with some practical examples.
So, that's what we're trying to do with this series of conversations and also with our work around the partner program.
And then, just a quick reminder for anybody who's new to this as to what O1 Labs does.
So, first of all, we built O1.js, the SDK, that allows you to build client-side ZK applications.
And we made a big focus on making it highly usable, both for developers and users.
So, on the developer side, you can develop with TypeScript.
And it really is TypeScript.
It's not a derivative of it.
So, that means that you can use TypeScript tooling.
It's a high-level language.
So, you don't have to be a cryptographer.
And we've seen people build proof of concepts, like good proof of concepts, in 20, 30 hours with our help.
It has recursion built in.
And it deploys without trusted setup.
So, you know, you can build ZKAP and deploy it immediately.
And you can make changes and redeploy it.
So, it's a really good developer experience, we believe.
And then, from the user's perspective, you can deploy in a browser.
You can run it in a browser.
It deploys with WASM.
So, that means, as a user, you can keep all your data private locally.
And you can just send statements about your data to somebody else.
And that's how you get privacy.
You can also run it on a server.
And that's probably a more realistic scenario for some of the use cases that we're talking about.
So, we built O1.js.
We're also the engineering team behind the META protocol, which was the first ZK-based L1 and is now in the late stages of testnet for an upgrade that will make it a great place to verify and settle the ZK applications that you can build with O1.js.
And then, finally, I'd say we're looking at new approaches to client-side ZK.
So far, we've been focused on circuits.
But people have probably heard about ZK VMs.
So, we're starting to do some work around that.
And a good example of that is the work that we're doing with Optimism to put their fraud-proof engine, their fault-proof engine, in a ZK wrapper.
And the results of that should be very synergistic with our work on MENA's ecosystem and roadmap overall and should extend the use of our plunkish-proofing system in the market.
Okay.
So, that's the introduction.
Thanks for bearing with me through that.
And let's turn to Veridice.
And, John, I should say that the application you've built here, which is for proof of liabilities to help address accounting integrity issues, it's actually not your core business, is it?
So, would you like to let me introduce yourself and talk a little bit more about Veridice and what your motivation was for building with this code?
Sure.
So, Veridice is actually a blockchain security company.
And so, what we mainly do is many of the people at Veridice, including myself, come from a particular area of academia called Formal Methods, where usually what we do is we're developing infrastructure that is capable of identifying bugs within software in a way that is mostly automatic.
And so, that's typically what we do.
Here, though, you know, we basically wanted to learn more about the ecosystem.
And typically, when we do so, we need some way of engaging with that ecosystem.
Typically, this is by reading documentation and also by developing some small model applications.
So, for most of the ecosystems that we've been engaging with, we've developed similar, you know, small model applications in order to get a better idea of the language features and the potential pitfalls that there might be for developers.
But this is the first time that we've really made it available.
In the past, typically, these model applications we've used as challenges both internally and at workshops that we've hosted like at Securium rather than as actual applications that we're releasing publicly.
So, this application is a proof of liability app.
Essentially, what a proof of liability is going to do is when you're working with an exchange, typically an order book exchange, when users end up depositing their funds on that exchange, that exchange now has a liability to that user.
And so, we've recently seen a lot of exchanges post a proof of solvency, and a proof of solvency is going to include both a liability, which is going to be the funds that are owed to users, as well as the amount of funds that they have, which prove that they can cover all of their liabilities.
And so, this particular portion is just that liability part where an exchange can then take this and create a proof of solvency by adding in information about their funds.
And so, if all of their funds are living on the blockchain, then obviously this becomes very easy.
The harder part has to do with funds that live off of the blockchain in fiat currency.
And so, what we wanted to do is currently, the way this is done, is exchanges will post information about their solvency relatively infrequently.
So, this is typically because doing or posting this on a blockchain is typically expensive, because if you try to post all of this information on a blockchain, every single time someone interacts with your exchange,
you're likely going to be incurring a lot of fees, you're likely going to be incurring a lot of fees, and so that's one thing that we've tried to address.
But also, the logic corresponding to the actual proof of liability has to be designed in such a way where it takes into account the possibility of the exchange trying to reduce their liabilities,
as well as users trying to prove greater liabilities.
And I think we'll talk about the threat model, which is what this corresponds to a little bit later in this discussion.
Thanks. Yeah.
So, accounting is kind of a dry subject, but this is actually kind of an interesting construct, right?
Because you're essentially allowing a user to see a total liabilities figure that an exchange has published,
and without actually seeing the underlying detail, prove that what's owed to them is including that liability.
Is that a fair representation?
Yeah.
Yeah, and it's kind of a protocol in order to hopefully keep all parties honest.
Yeah, like adversarial.
Right.
And so the interesting thing about this is that even its existence, I think, creates a very strong incentive for the exchange to be honest.
So, you know, they don't know which users might prove their balances, and so it's kind of high jeopardy if they're not honest all the time.
So you don't actually need everybody to prove all of their balances all the time.
You just need some users and, you know, random factor in there to prove their balance sometimes,
and then you've got a big disincentive for the exchange to cheat.
Right.
So just to give a little bit of context about how this works, basically, the exchange is going to post something called the liability tree,
which is going to be a Merkle tree with information about account information.
And then typically a user can then go in and actually ensure that their account information is up to date in this tree.
And so we've seen a couple of exchanges use this method in the past in order to show users that, yes,
the exchange is actually accounting for their funds correctly.
But like I said previously, it typically is not something that is updated frequently or with quite as much clarity or because, you know,
the code is not hosted on the blockchain.
You can't go and actually inspect the code yourself.
And just in terms of practicality, I mean, there's probably a number of ways in which this could be administered,
but a user could, for example, that their login process could trigger that the proof that the balance they see is included in the total liability figure,
or I guess there could be a standalone application or widget that just allows the user to go and prove on an ad hoc basis that they're still counted.
Right.
Yeah.
And, you know, before we, Florian's going to talk a little bit more with you about the technical approach
and some of the details and, you know, experience of using O1JS.
But before we do that, I was just going to say that a lot of the conversation in the market has been very specifically about centralized exchanges
and, you know, the issues that we've seen with them.
And as you pointed out earlier, you know, this is kind of a two-sided equation.
There's proof of liabilities and there's proof of assets.
And I actually think proof of assets has got a lot more attention because, you know, it's very directly Web3.
Proof of liabilities is actually a Web2 issue.
Like, the books and records are off-chain.
And so it's a really interesting use case that is useful for proving the integrity of the finances of a centralized exchange,
but is massively generalizable.
And, you know, there may be uses for this in accounting and auditing in the Web2 world in general.
So, for example, you know, you might trust a large business to be, that's regularly audited, to be correctly stating things about its accounts.
But if you're dealing with small or medium-sized businesses as a counterparty or a customer,
you know, you might, for example, in the future want them to prove things with ZK
without requiring them to go and, you know, send you their old books and records.
And that, you know, may not be an industry that sets the world on fire with excitement, but it's huge.
I think the Web2 financial auditing business is somewhere, I've seen figures between $50 and $150 billion a year.
So the applicability of this, although it's like very specifically a centralized exchange use case in the framing and the Web3 world,
I think is enormous.
So, yeah.
Shall I let you guys talk a little bit about the architectural approach here?
I'll hand over to Florian.
Yeah, thank you very much.
And thanks, John, for joining us on this Spitter Space today.
Yeah, so you published the code of the proof of concept.
And I think we will share the link later so that the people who are interested in the technical implementation can take a look as well.
But, yeah, so while you were working on the proof of concept, you worked on essentially two different approaches.
Number one being a smart contract-only focused approach, and the second one being a combination of recursive proofs.
Can you talk us through the implementation about the disadvantages and the differences between both of these approaches and just overall your thought process?
Sure.
So just as a bit of a disclaimer, the code that's going to be posted later is still under development.
The main thing that's in there is the actual liability tree.
But there's a list of things that I have yet to implement yet which would hopefully be available before anyone started using this.
However, as Florian said, there are two aspects to this.
So one is just a liability proof that lives in the smart contract and another case where you're modifying it using a ZK circuit.
So in the smart contract case, which is what I'll start with, basically what you have is you essentially just have a miracle tree.
And with that miracle tree, you're allowing certain users, in the case of what is posted online, it's just the exchange, to update that miracle tree with information about actions that were performed on behalf of the user.
So essentially, a user will sign an action that they want to perform, such as depositing funds, withdrawing funds, swapping funds, and so on.
And then with that signature, the exchange can then check this in, and that will modify this liability tree to give an accurate accounting of those funds.
And then what it also allows the exchange to do is because they have now updated the blockchain with this information, they can then provide the user proof that their balance is correctly recognized within this on-chain miracle tree by just giving them the path from the miracle root to the leaf of the user that corresponds to their account, and then the user can validate that, yes, their account information is correct.
The problem that the problem that you could run into this, or with this, is it really requires the exchange to interact with this on-chain miracle tree every time a user performs some interaction with the exchange.
And so in that case, the exchange is incurring fees every time, and obviously that would be not ideal for a lot of reasons.
One, most of those fees are probably going to be passed off to the user, and so on.
And so the ideal case would be to allow the exchange to update this tree less frequently, so like once a day, or once every few hours, or something like that.
Doing so with an on-chain-only approach, however, requires that the miracle tree modifications are somehow bundled.
And bundling those modifications and validating that only modifications that came from the user can be difficult, because you then have a lot of signatures that might need to be checked and so on.
And so this is where the ZK proof comes in.
And so instead, in this application, there is a version that will allow the exchange to interact with this ZK proof and say, okay, this is the current state of the miracle tree that I have off-chain that I am going to check in.
And it proves that the exchange correctly updated the tree according to this interaction that the user wanted to perform.
And then the exchange can provide proof that they updated the tree correctly to the user as some sort of a receipt.
And so in this case, the exchange is going to be generating these receipt proofs, which is what they're called in the application.
And over time, when the exchange wants to check everything in, they just need to bundle all of those up, which is what the roll-up ZK proof does, which is just a recursive ZK proof, which will verify that, yes, the receipts are correct in order to take all the receipts and bundle them up into one, and then they check that into the smart contract.
And so at that point, all the smart contract needs to do is say, yes, I know that this came from this particular ZK proof, so it verifies the verification key and validates that, yes, this came from this proof, so therefore I know that the tree was updated in a way that was consistent with the intended behavior.
And then once it does that, it can simply update everything in one go, and users can therefore trust that, yes, when the tree is updated in this way, everything was actually updated in a way that is consistent with how the liability tree should actually be updated.
And so it allows fees to be distributed, because everyone who interacts with the exchange over that entire day would essentially get a small portion of the fee to update this liability tree, rather than the exchange charging everyone for every interaction.
So, you know, it basically just makes everything a bit more distributed and a bit more clear as to how the exchange is actually performing these updates.
Thank you, yeah.
