[Music] And for this one, I'd like to bring on Mark to tell you about an incredible thing that they've managed to make go live on the solo network. So to talk about the test net, please give Mark a big round of applause. Thank you. Hey everyone, it's uh it's wonderful to be here. Um, and it's I think extra fun to be uh following Sergey with some 8-bit graphics, some 8-bit JPEGs that I will not be selling to you.
So, don't worry. Um, but you know, I like to try to make my talks fun. And so, this is a talk in the style of Zelda. Any Zelda players here growing up?
Okay, a few of you. Um, and so I'm here to celebrate with you guys uh a pretty exciting milestone. Um and so just yesterday we launched the Cello Eclair test net uh which is really a first of its kind. It's uh it's the first public network uh to be using uh SP1 in combination with uh IGENDA specifically IDA v2. And so if you like this talk um you know definitely come come find me afterwards.
You can ask me some questions but I'm also available on Twitter. Uh my DMs are open at_. And so we're really excited to be um uh talking about a CLA right now. Uh because uh as many of you probably know, Cell just transitioned from an L1 to an L2 earlier this year. Um we transitioned to an OP stackbased uh L2 uh using IDA for data availability.
Um and and you know we haven't been you know sitting idly since. Uh the team's been really hard at work thinking about what's next. Um and so Claire is really the the kind of preview of where Cello is going uh now that we become an L2 and now that we're in kind of the Ethereum family. And along kind of the way to becoming an L2, um you know, I got a lot of questions um from a lot of people asking, you know, why are you going with an optimistic stack? Why are you not um uh going straight to the ZKVM route?
You know, when we announced that we wanted to transition to become an L2, that was roughly two years ago. Um at that point already there were some um you know early pioneering ZKVMs that were just just going into production and a lot of people were asking us why are we going with kind of yesterday's technology and not looking at the future and kind of leaning into ZK. Uh and the reason for that is you know we looked really really closely at some of these ZK systems uh and we realized that you know they were actually very very complicated and very difficult to maintain. A lot of them had obviously a lot of handwritten circuits, but they also had um their own bespoke assembly languages and oftentimes the EVM itself was written in that assembly language. And so a lot of people had to write handwrite you know assembly language the whole like imagine re-implementing all the GU in in assembly and then maintaining that through every Ethereum hard fork.
that looked like a big nightmare for us. And so instead, you know, we had this hypothesis that um ISA based proving systems would become efficient over the course of the next few years. Again, this was two years ago. Um and you know, if you fast forward to today, um you know, the hypothesis has has really played out. I'm sure many people here are familiar with succinct and risk zero.
You know, I would say about half a year ago, these systems finally became uh cheap enough that you can actually use them economically for a ZK EVM. And that means, you know, you no longer have to write um your ZKVM in this complicated uh assembly language. You can simply write it in Rust, compile Rust to say Risk 5, which both succinct and risk zero uh can improve with. And then you can use one of these two systems to effectively prove your machine code. And that makes it so much easier to um maintain your code and to continue to track Ethereum as it continues to get better and and hard fork every year.
And you know what's even more exciting I would say than uh the fact that um you know uh this hypothesis has played out is the fact that we now as of really only a few weeks ago have uh something called real time proving. Anybody here following this trend? It's pretty exciting. So, you know, as of um really again only a few weeks ago, um it's now possible SP1 kind of announced their hyper cube proving system that can actually prove Ethereum blocks in under 12 seconds. So, previously, you know, it could take like initially like half an hour to prove a block.
And all of these uh systems and succinct especially have been working really hard to lower these latencies and they've lowered them down to the point where you can actually prove a block faster than the slot time of Ethereum. Um and so that means of course that you could then submit these proofs for every block so that your L2 could have you know near instant withdrawals through the native bridge. But it also unlocks something called synchronous composability uh which will effectively allow uh anyone to transact across um roll-ups and L2s and between mainet and uh roll-ups and L2s uh effectively uh synchronously. So you'd be able to submit transactions on two networks and have them be guaranteed to execute atomically. And so that will allow a level of composability across all of Ethereum that, you know, we're all really excited for and I think ultimately will help us make Ethereum feel like one, you know, giant chain instead of kind of this amalgamation of many different chains.
And so we're really excited for this future. Um, you know, it's it's coming, you know, I think faster than we even uh expected and predicted. Uh and so in order to get ready for this future, we wanted to start leaning in and start doing more and more with ZK. And so, you know, since there is no uh aclair emoji, uh we took a chocolate bar emoji uh we combined it with a hot dog emoji uh and this is how we got a clair. And so we just launched the Aclair test net yesterday.
Uh it's a shortlived test net. We're really excited about it. Um if anybody here uh saw our prior year's uh shortlived test net Dango, we announced it last year at ECC. A few people raised their hands. So you can think of a Claire as similar to Dango last year, which is really a showcase of where Cell is going.
Um we're going to continue working on on the code. We're going to continue to get it um audited and then have it go through our typical release process going through our two public test nets and eventually to mainet. uh hopefully hopefully later this year and as I mentioned you know a clair is uh unique in that it's really the first public test net to be combine combining succinct sp um kind of proving technology uh into a zkVM that is also using iena for data availability and I think the combination is is both unique and actually quite difficult from a technical perspective um and you know because this is a seller test net um eclair has a bunch of cello features. So cello has um is fully EVM compatible but it has a few bonus extensions that allow you to pay for gas for example with stable coins and that also allow you to use Cello as a ERC20 token and as a native asset and so a clair features some of these features um and then it uses um specifically opin uh on the zk side. So op succinct we'll talk a little bit more about what what this is and how it differs from op succinct but at a very high level opsync light is the optimistic variant of uh op succinct and so it still is an optimistic chain uh but you are actually proving uh these fault proofs using zk using the syncs proven network and then for da uh we're using iigen da v2 uh this is a new da product by the IGEN layer team that just launched just a few weeks ago.
Uh, and so we're really excited to be one of the first to be playing around with it. And so I'm going to go into more detail for how all of this works. But before I do that, I thought I'd do a live demo. You know, I don't have a, you know, a black board behind me that I can draw on uh for a beach wedding. So instead, I'm just going to use my um kind of transparent keyboard over here.
Uh, and I'm gonna do something pretty fun. Uh so this network is live uh and I am uh here I decided you know why not stress the system why don't we challenge uh one of the state routes that the proposer recently uh proposed uh and see if we can trick the network uh into accepting my fraudulent um state route uh that uh is different from the one that the proposer is proposing. Um and so this is what uh that looks like. Uh I just started the challenger. I just posted a bond.
Uh and now the proposer has to respond uh to this challenge and convince me and honestly, you know, uh the whole network that the original state route that the proposer posted on the L1 is correct. And so we're going to let this sit here uh during the course of this talk and we'll come back later and we'll see what happens. Creating this uh response obviously takes a little bit of time. Uh and so let's give it a moment to keep working on that. And so in the meantime, uh we can kind of go into a little bit more details for what this network looks like.
Um once again, uh we're using both succinct and iigen da. And on the succinct side, you know, as I me mentioned before, we're using this light version of op succinct. Uh this is again similar to op succinct regular uh but optimistic. uh and what that means is that you only have to use the ZK system when there is a challenge uh to uh the proposer who is submitting optimistically these state roots to the L1. And the nice thing about this is because we're only using uh ZK when there's a challenge, we're not incurring all of the he you know large CPU costs of constantly proving every transaction.
And so the end result is that the transactions that end users pay don't have to pay uh for this extra compute which means that we can keep transaction fees uh low certainly lower than if you were doing this uh constant validation constant proving and so you get the benefits of ZK while keeping transaction fees still low. The other thing that's really nice is instead of having to go through this very long interactive proving game that's common in these optimistic systems where you're proving effect where you're basically uh doing a binary search through the execution trace of the ZKVM. Uh here we can actually do something uh with just one round of interactivity, right? Someone challenges you and then the proposer can basically construct a valid proof uh and then submit it. uh there's only basically two rounds.
Uh that means that you can complete the whole process in the span of a talk instead of in the span of a week. And so that means that you can actually um uh get much faster finality out of your native bridge. You can withdraw funds more more quickly uh directly out of your native bridge. Uh and then finally, you know, I think proving costs keep going down. Every year they get cheaper and cheaper.
And so it won't be long before uh moving to a just a typical ZKVM that does full validation will be uh efficient and cheap enough for everyone to pay. And so this also provides a really nice upgrade path to to that blow. On the IGEN v2 da V2 front um uh this is a pretty exciting upgrade from the IGEN layer team. uh iigen da v2 uh effectively moved the validation of their uh quorum certificates uh from the L1 to the derivation pipeline in the L2. So in the past every time uh you wanted to put some data into igen da uh v1 you had to wait until they had enough data uh aggregated together so that they can amortize the cost of writing to the L1 and verifying that signature.
Now you don't have to do the amortization. So they give back a certificate to your data really quickly within the span of just a few seconds. Um they've also increased their network throughput. they have more efficient chunk distribution. Uh and critically they've also implemented uh this thing called um Hokulea uh which is basically a reimplementation of their portion of their derivation pipeline that's currently implemented in Go.
They've reimplemented in Rust so that you can prove it in uh in the succinct prover as well. And so we've integrated hokulea into uh eclair so that we can prove not just the uh state transitions of our EVM blocks but we can also prove the authenticity of the block data itself that is actually being then executed. Now, since this is a Cello network, um you know, we have some Cello extensions as well. Um and so, you know, I mentioned this ability to pay for gas uh with tokens that we support in Cello and the ability to also interact with the Cello token both as a ERC20 token and uh natively. Um all of this is implemented in our uh Go Ethereum client.
Um but uh succinct is much more efficient if you prove rust code versus go code. Uh and so we've had to actually uh port some of this code into rust in order to make this work. Uh and what's nice about that is this al also opens the door for us to be able to use ref in the future either to have multiple clients on the cell network or to increase transaction throughput even beyond you know the very high throughput that we support today. Okay, so let's go back to this demo. I'm curious how it's progressing.
Uh let's take a look. So it looks like the proposer um got back. It generated a proof using SP1. Um that proof you can actually look at on the succinct uh um explorer. Uh, and then that proof showed that the previous state route that the proposer proposed was in fact valid.
And so the proposer won the game. Um, and so that's bad news for me because I just lost my bond. But, you know, it was worth it to show you guys. Uh, and it's also good news for the security of the network because it means that, you know, my bogus state route that I tried to trick everyone into accepting wasn't accepted by the orbital network. The network kind of did the right thing.
it remains secure. Um, and you know, all of this happened in the span of, you know, less than 10 minutes. I think in reality it kind of took less than four minutes. Um, and so it was really, really quick without kind of many rounds going back and forth uh that would be otherwise necessary for an optimistic uh rollup. So, here's the um um page on the succinct explorer that that's tied to that proof.
You guys can go and look this up by by just going to explore.sync.xyz. Uh you can see how many credits it took and also how long it took. Uh although on this screen it's covering the part that says how long it took so I can't read that out for you.
Uh but uh it was pretty quick. Um oh no, it's up there. 54 seconds. Yeah, less than a minute. So very very very quick.
And so you might be wondering, okay, what did all of this look like? And so I have a little block diagram here to kind of explain it for you. Uh so here we have the L1 chain and the L2 chain kind of progressing. um at some point the proposer wants to move the or to capture the state route that exists on the L2 chain uh on the L1 chain and it wants to do that again optimistically and so it's just writing the state route to the L1. Um but you know someone like me can decide to do a demo on stage and challenge this proposal.
uh and if that were to happen, the proposer has to quickly uh uh get into proving mode and and actually come up with a proof to respond to this challenge because if it doesn't then the challenger wins and the challenger state route becomes uh the valid state route. And so in this case, you know, we fire up SP1 and we start generating those proofs. And we're doing a couple of things. We're we're proving the uh state transition of all of the blocks on the bottom. So we're proving every transaction.
We're proving uh every state change that's happening, every update to the patricia tree. All of that is now happening um you know using the SP1 prover. But the other thing we have to do is we have to verify the validity of the actual data going into these blocks from ien DA. And I mentioned that this is the kind of the complicated piece. Uh that data is stored offchain.
Um but uh the um the public keys of the operators that are signing those certificates that I talked about before, those are stored onchain in the L1. And so we actually need to read from the L1 as well. And we need to construct a proof that proves that the uh public keys that exist on the L1 uh in aggregate uh match the uh signature that exists on the data that's coming from DA. So we actually are checking that a quorum of those operators signed off on that data and then uh that data was used to create these blocks that again we're we're running these state transition proofs on uh down below. And so once we do that, we can construct a proof.
We can respond to that challenge again on the L1. Uh and that proof can then be verified um you know in in a constant amount of time on the L1. And uh and that effectively allows us to then um respond to that challenge with hard evidence uh that the challenge was wrong and in fact the previously supplied proposal uh was correct. And so that's in effect what I just showed you uh with that demo uh again running kind of in the background over the course of this talk. Um it's pretty cool that it's that quick.
Again much much faster than what you're seeing with a traditional optimistic uh rollup today. And then once that's done then you know the check marks below kind of correspond to kind of the state uh of the chain that is visible through the L1. And so we basically now assume that all of those blocks now are represented in the L1. So yeah, I think that's really everything I have for you today. You know, we're super excited about this.
Again, it's it's a big milestone for us. Um we worked really hard ever since the L2 transition uh to to ship this and we're so excited to have done that. Uh this week here, we got to celebrate with some actual French eclairs, which was pretty fun. Uh, and we're really excited about, you know, bringing this to production. So, just like last year with the Dango network, uh, we're gonna go through the standard audit processes, uh, release this through all of our test nets and and hopefully by the end of the year ship it to mainet.
Um, we're super excited and we hope you are too. Thank you. [Music]
Automatic transcript — names and jargon may be misspelled.
