My hot take is that all ZK roll up teams are actually just roll
up teams and they should think of themselves as roll up teams,
not ZK team. With the technology we put out
there in SP1, ZK has become a commodity.
It is accessible to every single roll up team out there.
And actually recently we did an integration with OP stack, which
is traditionally an optimistic roll up stack and we made OP
stack into a ZK roll up. The integration is called OP
Succinct and it's like live and running and people can use it.
So if you want to prove some computation, you just write it
in Rust and then you can generate proofs with US P1.
Welcome to Epicenter, the show which talks about the
technologies, projects and people driving decentralization
and the blockchain revolution. I'm Federica Ants and today I'm
speaking with Umar Roy, the Co founder and CEO of Succinct.
Succinct are building a decentralized CKVM and Prover
network. And before we talk with Umar,
let me tell you about our sponsors this week.
This episode is proudly brought to you by Gnosis, a collective
dedicated to advancing a decentralized future.
Gnosis leads innovation with Circles, Gnosis Pay and Metri,
reshaping open banking and money.
With Hashi and Gnosis VPN, they're building a more
resilient, privacy focused Internet.
If you're looking for an L1 to launch your project, Gnosis
Chain offers the same development environment as
Ethereum with lower transaction fees.
It's supported by over 200,000 ballot errors, making Gnosis
Chain a reliable and credibly neutral foundation for your
applications. Gnosis Dow drives Gnosis
governance, where every voice matters.
Join the Gnosis community in the Gnosis Dow forum today.
Deploy on the EVM compatible Gnosis Chain or secure the
network with just one GNO and affordable hardware.
Start your decentralization journey today at gnosis dot IO.
If you're looking to stake your crypto with confidence, look no
further than course one. More than 150,000 delegators,
including institutions like Bit Go, Pantera Capital, and Ledger
Trust Course One with the assets.
They support over 50 block chains and are leaders in
governance on networks like Cosmos, ensuring your stake is
responsibly managed. Thanks to the advanced MEV
research, you can also enjoy the highest staking rewards you can
stake directly from your preferred wallet, set up a white
label note, restake your assets on Eigenia or Symbiotic, or use
the SDK for multi chain staking in your app.
Learn more at Chorus .1 and start staking today.
Uma, thank you so much for coming on.
Thanks for having me. Cool.
Uma, can you tell us a bit about your professional and
educational background before starting succinct?
So I've always done a lot of math.
In high school and college I did a lot of math research and after
school, well, during school I, I studied math and computer
science at MIT and I also got my master's there actually in
machine learning. And after school I was working
in machine learning research at Google Brain, and then after was
at a small start up doing machine learning stuff.
But my interest in math is what originally hooked me into ZK
because obviously it has a lot of math and it's a very math
heavy field. And I found ZK through a friend
who I met at MIT. And yeah, that's kind of like
how my background ties into ZK. Your foray into kind of like
blockchain was mostly prompted by your interest in zero
knowledge stuff. Yeah, that's, that's roughly
correct. I, I'd always been interested in
kind of like the ideas and concepts of blockchain broadly,
not just ZK. But when I finally like learned
about ZK, I kind of that got my interest enough that I realized
I wanted to like build in the space.
What was it about zero knowledge technology that kind of grew in
specifically? Probably like a lot of other
people, I was just really fascinated by the actual
technology. I think ZK is a very magical
concept. Like you can prove to someone
else that a certain computation is true without revealing what
the inputs are. That seems almost like it should
be impossible. And so it was just a puzzle to
me of like how to figuring out, like how that's possible,
understanding the map, understand the cryptography.
And yeah, that's like what really drew me in.
Cool. So you came for you came for the
tech. Tell us about how that kind of
transformed into a vision for Succinct?
Yeah. So we were building in the ZK
space for a while. So I met my Co founder at this
summer residency hosted by Xerox Park, which is this I guess
sister organization to the EF, the Etherium Foundation.
And they were hosting this like kind of Co working over the
summer together. So I met my Co founder there.
We were working on AZK project. Actually it was related to Nosys
and I think maybe that's one of the first times we interacted
was through that. But we are building AZK bridge
from Ethereum to Nosys chain and in particular building a
Ethereum ZK like client. So that was like our first
Orient to the ZK world was building this project.
How did the product offering evolve over time?
So Succinct was started out of that project.
So originally when we started Succinct, we were building AZK
bridge kind of with this end game thesis that the future of
bridging was all going to be ZK like clients.
And I still think that's actually true.
So we were really focused on building this bridge and making
all bridges ZK. We worked on that for maybe like
six months and actually shipped an Ethereum ZK like client and
it got integrated into the Nosus validator set as a ZK validator.
We shipped a few other ZK like clients, but then after some
point we realized that, you know, ZK was too hard.
Like building each of those like clients took, you know, several
months and many engineers and it's very, very complicated.
And we realized that, you know, ZK has a lot of potential, but
if it was always going to be so hard to use, it wasn't, it
wasn't going to go anywhere. And that's what inspired us to
build our ZKVM FP1, which makes ZK really easy.
So instead of spending months, you know, making a like client
and writing these like things called circuits, you just write
normal code and Rust and you still can use ZK.
And yeah, that was evolution from our early days in ZK as
like ZK builders to like building underlying ZK infra
that makes ZK accessible to everyone.
Quick, before we kind of dive into the ZKVM because I have so
many questions as let's kind of briefly clarify kind of what a
ZK like client does. So kind of like it's basically
it's, it's a client that can kind of verify the state of
another blockchain on chain, right.
So kind of can you talk about this a little bit and why, why
you think ZK like client bridges are kind of the end game of
bridges? Yeah.
So a like client is just a protocol to verify the consensus
of a particular chain. And so when you verify the
consensus of a particular chain, you can then you know,
understand if someone has like burned a token on that chain and
then you can mint them a token on the other side.
So kind of like classical bridging.
So AZK like client is just implementing that like client in
a zero knowledge proof and then verifying that proof on chain
instead of verifying like the whole like client functionality.
And the reason you'd want to do this is if you want to run a
like client on Ethereum, it'll be really, really expensive
because you'll have to verify a bunch of signatures, you'll have
to do a bunch of computation. Whereas if you have a ZK like
client, you just verify a proof of that computation and that is
just a lot more gas sufficient. So basically TLDR is a ZK like
client is a way to generate a zero knowledge proof of a like
client that makes it really gas sufficient to use in on chain
contexts for bridging. I think that's, that's, that's a
fantastic summary. So kind of let's move on to the
kind of ZKVM part. So you said that I'm kind of
like building the circuits was really hard.
How, how can we kind of like as someone who's never actually
written a circuit before, how do I go about it?
So kind of, I know what kind of the logic is I kind of want in
that circuit. What do I do?
Yeah. So to take a computation that
you want to generate AZK proof form, you have to write it in a
form that like you can actually do a ZK proof in.
And historically that meant taking your computation and
breaking it down until additions and multiplication.
So it's very primitive. You'd basically use a
specialized language or DSL. There's a bunch of other of
options out there including tools like cercom, which maybe
people have heard of, where you would make a computational graph
out of adds and multiplies that express your computation.
Obviously that's, you know, very, it's not very fun because
you're working with these very basic primitives and very basic
building blocks. And it's similar to like writing
assembly or writing a very very low level language instead of
writing something like Python. Why is it that in order for it
to kind of be incorporated into a into a ZK?
Second, why can you only use additions and multiplications?
Yeah, that's a good question. So the way ZK protocols
generally work is you take your computation and then you encode
it into polynomials and then you prove relationships between the
polynomials. And that's kind of where the
additions and multiplications come from.
Like in polynomial world, you can do additions and
multiplications and you can prove that polynomials are
related to each other by like those operations, I guess.
And so it has to do with like all the underlying math and
cryptography of how ZK actually works and kind of turning your
computation into something as polynomial friendly is the
reason you have to break it down into these very like primitive
relationships, if that makes sense.
I mean, you know, obviously there's a lot more math there
than I could dive into, but maybe that's like a simplified
explanation. I I think that's, that's fair.
Maybe we'll link to some resources in the show notes.
So the ZKVM is my understanding correct that kind of I can put
whatever rust code or piping code or whatever into it and it
did kind of automatically turn it into a ZK second?
So it is correct that you can put any Rust code into it.
So now if you want to prove some computation, you just write it
in Rust and then you can generate proofs with SP1.
You can't do Python because like we, you know, Python's like
interpretive language. But yeah, you can do Ross, which
is like, I guess the most, one of the most common languages
used in blockchain. It doesn't quite turn the code
into a circuit. What it does is it compiles the
code to an instruction set called RISC 5.
So that's like somewhere to EVM, you know, you have a bunch of OP
codes and then we prove the execution of that RISC five of
all those RISC 5 instructions. So we basically prove that like
when you execute the program and all the instructions in the
program correctly that it gives like a certain output and a
certain result. So we have a RISC five circuit
that is responsible for proving the execution of this RISC 5
bytecode and then your program gets run through that circuit,
if that makes sense. So that's we're not turning your
computation into a circuit, we're instead going through this
RISC 5 layer. What's a RISC 5 layer?
RISC 5 is like an instruction set.
So your program gets compiled to a bunch of instructions in a
row. So it might be like do an add,
do a multiply, do a subtract, you know, then do a jump or do a
branch or whatever. So that's like the underlying
instructions of your program. And then we prove that like the
instructions of your program are executed correctly, like in the
correct order and you know, end up touching memory correctly and
stuff like that and having this final output.
For those that are that are familiar with the EVM, it's very
similar. Like you take Solidity, it gets
compiled to EVM by code, which is a bunch of like EVM OP codes.
And then when you run a smart contract, you're just executing
a bunch of EVM op codes in a row.
So it's it's pretty similar mental model.
When you say we prove who was we in this, in this situation?
Yeah, like our Z KB M SP1 is proving the execution of the
RISC 5 code. OK, cool.
So it's it's it's a fully trustless set up, right?
Kind of like it's not you guys proving that.
OK, why hasn't this been done before?
So kind of like it seems like kind of turning it seems like
it's pretty well understood what kind of operations you can kind
of feed into a into a ZK proof. So why, and I assume there's
pretty good cookbooks how to kind of turn whatever you have
into that, why didn't what kind of you build exist before?
Yeah, it's a good question. So I think for a long time
people were really fixated on proving the EVM.
So there was a lot of ZKEVM teams.
And I mean, that makes sense because validity and all the
Ethereum stuff runs in EVM, so people are really fixated on
that particular objective. And then I think also it wasn't
super clear that proving risk 5 would be performance or doable.
Like people thought it would be really slow.
It's not an instruction set that's really designed for ZK.
It's actually a very common instruction set that's used by,
you know, in many other contexts.
So people just didn't think it'd be performant.
They'd be like, sure, you could do this, but it would just be
really slow. And I think 1 of SP1's major
innovations was that we actually showed that it could be fast for
workloads like like clients or roll ups that people care about.
And now there's, I mean, there's a lot of people trying to prove
this risk 5 instruction site these days.
And yeah, so these days there are more people trying to do
that. I think it's worth mentioning 2
teams. One is the Stark War team.
They didn't try to prove risk 5, but they wrote a ZKVM for Cairo,
which is like their instruction thought and it's like a, yeah,
it says instructions said that's optimized for ZK or like
designed for ZK. So they kind of like pioneered
in many ways ZKVMS way back, you know, 5-5 years ago.
And then the Risk Zero team was working on proving risk 5
execution. And then I think our major
contribution was kind of taking RISC 5Z KVMS and making them
really, really performant for Bola and showing that it's
actually like practical to use for a lot of workloads people
care about. Cool.
So I think kind of we've covered the basics of SP1.
The other key part of your offering is the Prover network,
right. So tell us about that and kind
of like how these two intact? Yeah.
So SP one is, you know, an open source project.
You can run SP1 and generate proofs on your laptop.
But I like to tell people that's not really a fun time because
proof generation is very intensive.
And so to actually make it very performant and really cheap, we
have a GPU implementation of SP1 where if you generate proofs on
a GPU, it's much faster and much cheaper.
But obviously I think most people don't want to like set up
that infrastructure themselves. And so our Prover network is a
way for, you know, anyone to outsource proof generation to
the Prover network. So instead of generating proofs
on your laptop, you generate them through the Prover network.
So you send it like, hey, I have a program, here's my inputs.
I want you to generate a proof. And then the Prover network
provides a protocol for anyone in the world to plug in their
GPU and contribute capacity. So it's kind of similar to
mining where like in the past anyone in the world could, you
know, mine Bitcoin blocks through the proof of work
mechanism. We have a similar kind of
concept or architecture where anyone in the world can generate
proofs and like earn transaction fees from the Prover network.
How does the consensus mechanism for the Prover network work?
Yeah, that's like work that's coming out soon.
So we're right now the Prover network doesn't exist.
It's just like a concept we've put out there, but it it it's
not actually like live or running yet.
There's no consensus mechanism for the Prover Network.
There's more like an allocation mechanism for like if there's a
bunch of proofs coming in, who gets the right to generate the
proof and earn the fees from that proof.
So the allocation mechanism that we have is this like auction
style mechanism that we're going to publish some more material on
thin and that's responsible for deciding like you know who gets
to generate the proof and at what clearing price the fees get
paid. What do you envisage as the use
cases for SP1 and kind of the proofs generated by the proof of
net quack? I think I'm really excited about
ZK roll ups in general. I think right now there's a lot
of talk about the Etherium fragmentation and all these
problems that the roll ups can't interoperate and talk to each
other. And I think the biggest flaw of
the optimistic roll up design is that withdrawals and bridging
takes 7 days. And fundamentally, I think that
leads to a lot of this fragmentation and
interoperability issues. So I think ZK is the best way
we're actually going to solve that in the Etherium ecosystem.
Every roll up, I think will be a ZK roll up and they will all be
able to talk to each other via, you know, verifying ZK proofs of
each other's state. And then there will be like
seamless purging at interop. So in the near term I'm most
excited about ZK roll ups using SP1 and turning every roll up
into a ZK roll up. In the longer term, I think
there's a lot of other really exciting applications even
outside of block chains. So for example, there's teams
that are doing ZK e-mail or ZK passport where they basically
prove, you know, passport attestation information or
e-mail information in a zero knowledge proof.
And then you can use that to bridge off changing the on
chain. Or you can kind of even use it
in non block chain context to prove that like you have certain
credentials or your certain nationality.
And I think that's really interesting.
Like basically ZK attestation, ZK identity is pretty exciting.
And then there's a bunch of other types of software broadly
that can be proven ZK that could benefit from verifiability that
I'm also excited about. South, I'm talking about ZK roll
ups. I mean, one of the core tenets
of kind of their existence is that they kind of produce these
ZK proofs. Kind of I earlier kind of got
the impression a little bit that this is infrastructure for
customers of what whatever feather that kind of are not
specialized in ZK or kind of don't want to kind of put in the
effort to kind of build their own ZK infrastructure.
This can't be set for ZK roll ups, right?
So kind of like if you look at the ZK roll ups that are
currently out there, are they interested in kind of using a
commoditized version of of AZK proof generator?
Surprisingly, yes. I think my hot take is that all
ZK roll up teams are actually just roll up teams and they
should think of themselves as roll up teams, not ZK teams.
I think with the technology we put out there in SP1, ZK has
become a commodity. It is accessible to every single
roll up team out there. And actually recently we did an
integration with OP stack, which is traditionally an optimistic
roll up stack and we integrated, we took their state transition
function. We stuck it in SP1 and we made
OP stack into a ZK roll up. It's called the integration is
called OP succinct and it's like live and running and people can
use it. So already we've kind of taken
existing stocks that are non ZK and innovative ZK into them.
And so it's just inevitable that every single roll up will be ZK.
So if you're a ZK roll up team, I think there's a lot to
building a robot that is very, very difficult and very
important. That's not on the technology
side. You know, it's like BD, you
know, exchange integrations, making your ecosystem great,
making your app developers lives great, you know, attracting
liquidity and stuff like that, attracting users.
And I think now that all the roll ups have ZKI, think all the
roll ups should like focus on basically like that more user
facing layer of the stock and just use whatever the easiest
best tool is for ZK, which in this case like sticking you know
your roll up state transition function and SP1 seems like a
pretty good option. If you look at the proofs that
ZK roll ups use, are they in any way geared towards the use case?
Because kind of SP1 is very general purpose, right?
So kind of I would have assumed that kind of like if I were to
build the ZK roll up, I would actually build it in such a way
that it's geared exactly towards my purpose and that would make
it more performing than kind of a general purpose machine.
That's also, yeah, really great question and observation.
So I think historically that is what ZK roll up teams have done.
They like hand coded this specialized custom circuit for
the EVM and for their roll up. There's two interesting things
though. One is actually SP 1 is very,
very performant. So we've actually seen it be
sometimes even more performant than custom solutions that teams
have created. And that's because a lot of
these ZK roll up teams started a few years ago and the the ZK
tech has improved a lot in the meantime.
And also SP 1 is really fast and we have a GPO implementation and
we have this system of like pre compiles that make it very, very
efficient. SO1 surprising fact is that
actually sometimes SP 1 can be more performant than a custom
stack for the EVM. And I think this was even
surprising to us and surprising to other people.
So that's like 1 interesting thing.
The other thing is even if SP 1 is a bit slower, say it's even
like you know, 50% or 25%, you know, more expensive or slower
because you can just take normal code and run it in SP1.
Life in all other dimensions gets a lot better.
So your because you can just reuse existing Rus tooling like
RAF and Rev M and Ethereum notes software because your developers
can update their state transition function whenever
Ethereum upgrades because you kind of have like all this
flexibility and you have really great tooling and it's so easy
to build. I think the cost basically or
sorry, the benefits basically vastly outweigh the costs and so
I think all teams are basically moving towards the ZKVM based
model. OK.
Let's talk about the Prover network in a little bit more
detail. So kind of like in order to kind
of become a Prover, I kind of need specialized hardware.
I get that because kind of like you, you're carrying this
towards GPU's and what else do I need to fulfill to kind of
become part of the Prover network and how do you make sure
that the proven network remains decentralized and incentivized
effectively? Yeah, it's.
So for the Prover network, as you mentioned today, people need
like GPU's to join and run proofs.
And again this our Prover network, like we've written up a
design for it and we're going to be publishing that's it.
And we'll probably have like a test net in the upcoming months
for it. And so we'll be able to like
test out a lot of these ideas and make sure that they actually
work. The mechanism we designed for
the Prover network in terms of allocating who gets what proof
and stuff like that was specially designed to keep
decentralization in mind. So normally you could just to
decide who gets approved, you could allocate it to, you know,
the person who offers to prove it the cheapest or you could
have some mechanism like this that's kind of a straw man.
Our mechanism is specially designed so that it still
maintains decentralization and prevents like prover
concentration. So more concretely, there's kind
of this parameter that you can tune up or down and depending on
what the value of that parameter is, prover, sometimes with some
probability, people who are a little more expensive than the
cheapest prover will still get selected to generate a proof.
And that's like important for making sure that a lot of people
can participate and it just doesn't concentrate towards like
one really big, large, dominant prover.
So yeah, we kept that pretty explicitly in mind when
designing the mechanism for the prover network.
Yeah, that's probably the biggest important thing for it.
This is a very new question, but is the output of the CKVM
deterministic? So kind of like if I put in some
sort of Rus code, will I always get the same output?
Yes, or people should only prove programs that are deterministic.
So yes, that's true. OK, so I can easily verify that
kind of the the quote that I'm getting back from the prover
network is sufficient and correct, right?
Yeah, the whole kind of point of ZK is that you can verify that
the proof and the computation was done correctly in much less
time to redo the computation. So I think that uniquely enables
the Prooper network. There's like no additional trust
assumptions. There's no yeah, there.
There's no additional like trust vectors.
You send it your request for proof, someone generates a proof
and then you can verify that the proof is valid and then the
money gets like sent out to them after the proof gets verified.
So I assume succinct business model is also somewhere in this
incentive layer, right? Yeah, Yeah, that's exactly
right. I think our thesis is that
people will want to use the Prover network because it'll be
much more cheap and much more efficient and much more easy
than, you know, them setting up their own infrastructure.
I think in practice, people that use SP1 today use our cloud
proving service instead of running it themselves.
We basically offer like a, we'd like to call it our Prover
network beta, but really it's just us generating proofs and
sending them back to people. And most people use SP1 through
that because setting up your own infrastructure really sucks.
So we imagine that, you know, people want to generate proofs
and pay for that. And yeah, that, you know, that
those fees will be directed to the Prooper network.
I kind of imagine it actually similar to DA where today, like
if you're a roll up, you pay Ethereum for settlements, you
pay Ethereum for DA 'cause you're posting your transactions
there. And I imagine in the future that
you'll part of each transaction will pay for proving and that
will like go towards our approval network.
When, when you say that that goes towards the prover network,
you, you yourselves, are you a privileged party in that
approver network kind of do you get kind of some basis points of
all transactions that are kind of settled on that prover
network or are you just one of the provers yourselves?
Oh, like our our company, yeah, No, no, I don't think we'll be a
privileged party like it's going to be a decentralized neutral
protocol and we will just participate in it probably is
like approver of last resort basically.
How does it work for you in business times though?
So kind of like if if you're only a proving participant in
your network and you kind of you get the fees that everyone else
who hasn't developed either SP1 or the Prover network also gets.
How is that? How's that work right for you
guys? Yeah.
Well, I think the network will also have some like marketplace
fee for, you know, facilitating kind of this interaction.
Yeah. OK.
So, so that way kind of you, you are kind of your company somehow
is a privileged party and that kind of like you're offering the
marketplace. And kind of like I, I kind of,
if you, if you're working under the assumption that kind of like
these, these CK proofs will be commoditized completely, then
obviously kind of the fees will be kind of like a race to the
bottom. So you kind of you need to be
able to kind of participate and kind of like the entire volume
and kind of make it worth your while, right?
Yeah, I think, yeah, exactly. Like, I think it's like any
other protocol. For example, Lido kind of
facilitates this interaction between people who want to stake
and then also like the professional note operators and
they have a 5% fee to the node operators, 5% fee to their
protocol. I imagine it being pretty
similar. OK.
And So what what blockchain applications are currently
supported by offering you? So you just talked about the OP
succinct offering. Is there is there anything else
or anything you're particularly excited that that that's
launching soon? Yeah.
So two bridges actually run on SP1, the Celestia bridge and the
Avail bridge are like SP1 programs and you know run
through SP1 and you know, our ZK by clients actually on Ethereum
that you know secure pretty big ecosystem.
Our original dream of every bridge being a ZK bridge came
true, but it is through SP1 instead of, you know, our
original approach of handwriting every single program.
So that's pretty cool to see. I'm very excited about the ZK
roll ups and OP succinct. They're a very popular roll up
stock. A lot of people use them like
base Unichain world, world chain as well.
So it's kind of exciting to one day have a path towards all
those ecosystems becoming ZK roll up.
There's also a lot of other people building very cool stuff.
Some in the Bitcoin ecosystem they're building like Bitcoin
roll ups or Bitcoin L twos, some Bitcoin bridging.
There's even some people in Solana that are building with ZK
with their new network extensions.
That's also quite interesting. There's all these application
specific block chains also for like trading that I think are
quite interesting. Basically, I, I have this thesis
that in the long term for very, very popular apps like trading,
it doesn't make sense to have the overhead of a general
purpose execution layer. You're going to have these like
specialized roll ups that are only built for one application
and are hyper, hyper optimized for it.
And some people are building basically these like
decentralized exchanges that are hyper optimized for trading with
us P1. So that's also another cool kind
of category. And then there's stuff outside
of blockchain, like ZK e-mail. Someone made this proof of
driver's license application with SP1.
That was cool. Like you verify your driver's
license and you can reveal information about that with the
ZK proof. So the ZK identity stuff is also
really interesting to me. Yeah, super interesting.
What do you see as kind of the the main bottlenecks in ZK
adoption? I think right now with SP1, ZK
is actually finally really easy. Like in a lot of the protocols
we talked to and work with for them using SP1 is often the
simplest part. It's really building up the rest
of their protocol that's hard. You know, building the on chain
smart contracts, even designing your protocol logic, building
out the front end, stuff like that.
So I think there's this new generation of like ZK native
protocols that are building with ZK from day one.
And actually ZK is the easiest part and getting their entire
protocol to mainnet is kind of like the biggest blocker to them
wanting a lot of proofs. I also think there's some like
kind of technical debt and emotional attachment to the old
way of doing things in the ecosystems as well.
So for example, you know, I think tomorrow every roll up
should be a ZK roll up and all the OP stock chains should
immediately use ZK because it's cheap, it's really fast, it
works. But you know, I think for a lot
of people, like they're used to the optimistic technology or in
many cases they don't even run fall proofs at all.
So they they're just using a multi sig and you know, that's
kind of easy enough. You know, while things are good,
obviously it's really bad when something breaks, but that
happens rarely. So I think ZK is kind of like
it's kind of similar to decentralization in a way.
It's like eating your vegetables like you kind of have to
decentralization is really important when something goes
wrong or there's, you know, some like breakdown in trust of the
centralized actors and that's when you're people are happy
they built a decentralized system, right.
So I think ZK is similar where it's like, so maybe using the
multi CIG is fine 99% of the time, but then there's this
catastrophic tail risk and you really wish you actually did
have full validity proof in those situations.
And so I think as an ecosystem, one of the biggest things today
is like, we're all just, you know, kind of living in the
happy path and living in this world where we don't worry about
those scenarios. And I think in general, there
needs to be like more of a push to like actually having
decentralized verifiable systems that operate that actually kind
of fulfill like the promise of all the stuff that we're doing.
Yeah, no, I I agree. I think people don't like
thinking about the failure modes kind of as long as things are
good, right? Yeah, they don't think about the
failure modes until it's like too late.
Yeah, absolutely. What kind of metrics do do you
look at for succinct to gauge your success?
So kind of like what? What are you optimizing towards?
I think one really concrete metric is just number of proofs
and also like you know, amount of computation.
So we call it like cycles, like how many risk 5 instructions are
we proving? So that's a really fun metric to
look at. I think recently, like in the
past month, we proved like trillions of cycles and that's
been going up into the right very quickly, especially as we
get more and more roll ups using it because they use a lot of
cycles. The other metric I think I
personally care a lot about is like kind of like the quality of
the usage. So it's like, are we
meaningfully moving the ecosystem towards more
verifiable systems and like, you know, more verifiable
applications in general? So for me, Obesisys Sync was
really exciting because it was like an opportunity where you
can now finally see a path for every roll up on Ethereum to be
a ZK roll up. And even though that doesn't
happen like today, it's kind of like the first step and then you
can fill in the dots. So yeah, that's like another
metric. It's like, oh like can this
thing be generalized to like and more instances?
So FP one's open source, right? Yeah.
So as a prover network, what's your Moat kind of like what
stops me from kind of just setting up a second prover
network that kind of just make sure there's a kind of fee raise
to the bottom? Yeah, that's a good question.
I think integrating with a Prover network, there's like a
developer integration cost and developer switching cost.
And then also like all the provers will be connected to our
network and generating proofs with our network.
And so if you want to access kind of all the provers in our
network then and you there, there becomes another competing
network, then you're not going to like want to switch over so.
I think the network itself kind of aggregates both the supply
side, so like all the provers and then also all the demand
side, which is like all the proof for costs.
And then with that there becomes this like flywheel that's like,
you know, the more demand there is and the more supply gets
built out, you know, and then the more supply that gets built
out, proofs get cheaper. So hopefully there's more
demand. And so I think it would, it
would be really difficult for another prover network I think
to come in and compete and like make sure all the provers are
integrated and make sure all the demand also gets routed there
and stuff like that. Which way do you see succinct
developing? So kind of like if you, if you
think about kind of succinct in the next say three to five years
or so, so something inordinately long, kind of like in blockchain
times, where are you going? I think for us, like we just
want ZK to be as widely adopted as possible and making, you
know, as many things verifiable as possible.
I think verifiability is this like very fundamental, new
primitive, and obviously in the context of block chains, it's
very powerful and needed because that's like one of the
fundamental premises is that you're building these like
verifiable, trustless systems. And so for systems to be
trustless, they have to be verifiable.
So I think it's very fundamental to blockchains.
So I really hope it gets adopted in all the blockchain contexts
that it should be. So that's like roll ups,
bridges, stuff like that. But then yeah, beyond that, I
think I'm also really excited about seeing these verifiable
systems more in the real world as well, beyond blockchains.
And I think that will be very, very interesting.
And I think that's uniquely kind of enabled by being able to
write normal code. Like I think it's hard to
imagine that normal people adopting this Decay stuff if
they had to go through all the pain of writing custom circuits
and doing all this cryptography and stuff like that.
But now that you can just take normal Rust code and generate
proofs of it, hopefully that enables a much larger class of
applications to become verifiable.
What new features or improvements can we expect or is
it, I mean, I, I assume kind of the stacks not ossified, right?
Kind of like it'll keep developing.
Yeah. We're, we're always trying to
make it faster and cheaper. So that's like our main series
of improvements is on the proof system side, kind of innovating
and figuring out how to make the underlying cryptography better.
Also in the engineering side, there's a lot more optimizations
that we're always working on to make it faster and cheaper.
So yeah, on SB1 side, that's like our North stars to make it
as fast and as cheap as possible.
And then I think a really big upgrade will be finally having
an actual prover network where anyone in the world can
participate in generating proofs.
And hopefully that also enables SP1 to get better and better as
well, because now it's not just us generating proofs.
It's like harnessing humanities collective intelligence and
optimizing the system. So I kind of view it somewhere
to like mining, where in Bitcoin mining you had this proof of
work game or proof of work puzzle and there became this
global scale hardware build out centre around it, right?
You had so many mining companies that were developing, you know,
their custom ASICS and then also deploying it in data centers
across the world. And it began this like global
movement to optimize computing a Shaw hash function.
And our hope is kind of like by having this prover network and
also setting up this very similar game and objective that,
you know, it'll be like this collective global race to also
improve SP1. If kind of SP1 and ZK tech kind
of gets integrated into other tech that kind of like you're
hoping it will, it will get integrated too.
How will the Internet be different in 5 or 10 years from
now to how it is today? Yeah, I think today, like if you
want verifiability on the Internet, there's two options.
One is you transact with like a decentralized system like
Ethereum or something like this, right?
You have this very expensive, like decentralized consensus
consensus or you have regulation.
So for example, like if I want to get a credit score, there's a
credit scoring agency that is responsible for, you know,
computing my credit score based on a bunch of statistics.
And then they're regulated by the government to make sure that
they're like, not doing anything racist or bad.
And then, yeah, we just have trust and verifiability through
basically regulation or trusting centralized intermediaries.
So I think in a world where verifiability is like very easy
and very ubiquitous, you can imagine instead that the same
credit scoring company instead has to posted DK proof that they
updated everyone's scores in a correct way according to a fair
model that we all agree on is like the correct model.
And instead of having regulation, you basically verify
a cryptographic computation and you can make sure that people
are doing the correct things and like, you know, respecting the
properties you might want of their systems.
So I think that's pretty exciting.
You can just have verifiability in a lot more places and you can
have it enforced with code instead of with like
regulations. So kind of like if you look at
metrics that pertain to the average user, how would they
notice that? Yeah, it's a, that's a good
question. I guess in this credit scoring
example, I think they would probably notice systems becoming
like more transparent. So you have just like more
transparency on like what's actually going on in like all
these currently regulated entities.
And right now you're like trusting that the government is
a reasonable job regulating, but in the future you can check
yourself. So I think you just get a lot
more transparency. And then I think if you have
more verifiability, then you know, it should also be a lot
more efficient, right? Because.
And I think that's also like one of the thesises of like crypto
broadly, right? Is like, OK, now we can have
this like trustless exchange and now we can have like trustless
exchange of like any asset. And that's kind of what lets us
have like all the millions of assets we trade today on chain,
like all the meme coins and like NFTS and stuff like that.
And so you can imagine that like, oh, now that verifiability
is really easy, maybe we have more expressive conditions that
we can use in our day-to-day lives, if that makes sense.
I mean, I guess this is a bit abstract, but I think you just
have more expressivity and then that leads to more efficiency
because you can just like do more complex stuff.
So and tell us about the timeline for the proven network
when, when is the test net going to come live and how can people
find out more about it? How can they be prepared to kind
of take part as the proof us? I think the kind of architecture
and design will be out in like the next few weeks.
And then after that, the test set will probably be out in like
the next few months. We already have like an internal
version working that we're testing out.
So maybe we have like a dev net internally that we use.
But yeah, the test net, that's like people can participate in
in in a full form. I'd be out in like the next few
months. And how do people stay abreast
of developments kind of where, where should they follow you on,
on Twitter or where do we send them?
Yeah, Twitter's great. Just as the same to Labs account
or my personal account is also a good resource.
Cool. Fantastic.
Uma, thank you so much for coming on today and telling us
about the Prover Network and SP1.
It's been a pleasure. Yeah, thanks for having me.