Cheap transactions with Ethereum security

Transcript

[Music] Sounds like my everyone. Can you hear me? Okay, perfect. Hey everyone, uh it's so wonderful to be here. Um my name is Mar Kosvski and I'm one of the co-founders of Cello. Uh and you know today we're going to be talking about um building an L2 with INDA and a decentralized sequencer.

Um and uh I've challenged myself this year to try to give talks solely using emojis or at least mostly using emojis. Uh so if you like the format, let me know either afterwards or on Twitter. Um and yeah, I guess um you know, all of this is in the context of something that we announced earlier this week, which is uh kind of this proposal uh to turn Cello into an L2. Um just kind of curious, maybe show of hands, who here heard about the proposal earlier this week?

Cool. Okay, so that makes me happy um because you guys have the context. Uh, and I'm glad you guys actually did raise your hand, otherwise this slide would have been awkward. Um, and yeah, this is emoji number one. Um, so yeah, um, hopefully you guys, um, maybe checked out the forum and took a quick peek. Um, you know, today we're going to be talking in a lot more detail about how the proposal works um, and also some of the challenges and some of the thinking behind some of the the design choices we made.

So, but before we begin, um I just wanted to give like a 30 second overview of Cello just so we're on the same page. Um so, today, you know, pre-proposal, uh Cello is an EVM uh compatible proof ofstake layer one. Um, and it's EVM compatible because when we we launched it or we started working on it three years ago, it was um really after we tried building really easy to use mobile applications on Cello on top of Ethereum. uh and when we couldn't quite create something that was easy enough to use for everyone that took us down the path of of launching or building out a scalable kind of um EVM

compatible of course um proof ofstake network and you know a few interesting thing happened uh after that um literally the network was launched three years ago by a quorum of community validators and literally within the first week someone proposed making cello a carbon negative chain so having the cello um offset the carbon that it was contributing to. This was three years ago, way before uh Ethereum um did its merge while it was still proof of work. Um folks really wanted to put a stake in the ground and show that blockchains could be actually good for the environment. And so since then it's been programmatically buying carbon offsets, uh which is really cool. And starting with the next hard fork next month, it's also going to be using a portion of base

fees to buy carbon offset credits as well. So people, you know, really think of Cello as a really green chain. A lot of refi is happening on Cello, but it's also a mobile chain, right? That was the impetus initially for its existence. You know, we tried building a global Venmo wallet on top of Ethereum. We couldn't make it easy enough to use, and so we wanted to build something that had the features that um allowed you to build really easy to use mobile applications. So, we have this protocol called social um social connect, which lets you send value to phone numbers across wallets on the chain even before the recipient actually creates a wallet. And so this is just one of the many mobile features.

Um, another really nice one is a ZK Snark baselike client that lets you sync with just a few kilobytes of data. Um, and you know because of this mobile focus and just you know this origin um, you know where we wanted to create a platform that allowed you to build these really easy to use mobile wallets. you know, a lot of thought went into making uh Cello just really a good place to build really easy to use um enduser applications. Um and one of one of these um I would say um features is this ability to pay for gas with tokens on Cello. So even pre-account abstraction, this is fully native, even with EOA

accounts, you can you can pay for gas with tokens, which means that if you send the stable coin to someone, um you can pay for that transaction fee in the stable coin, they can send it on to someone else. You're never going to be stuck with this like situation where you're like, "Oh I have some USC and uh I can't move it." I don't know who here has had that happen to them. Yeah, I mean, me too, right? Like it's pretty much all of us. It's very very frustrating and normies you know it's one thing for us it's another thing for normies to have to deal with them. So that's you know cello in a nutshell. Um but we're here to talk about kind of the future of cell which is kind of this L2 proposal and so you know what does that look like? uh as I mentioned before um

you know when we were thinking about this proposal we were thinking about it in the context of the existing users that we have today the existing network that is running today which ultimately creates some constraints and some challenges for us um as we kind of thought about this design and so what are those challenges what are those constraints I would say there's two you know really big ones um the first of which is um that you know gas fees are very low on Cello. Um this is kind of by design. We worked hard to create a I would say a really nice um scalable consensus protocol, a proof ofstake consensus protocol that uses a lot of the same cryptography as ETH2, but you

know we launched it um three years ago. So two years roughly before the merge. Um and this has resulted in uh this and the ability to pay for gas with tokens and the mobile focus you know has just resulted in a lot of use cases that um are um more targeted to real world use cases use cases where people are for example doing P2P transactions between mobile phones payment use cases micro finance use cases if anyone here has used KA before there's a protocol that's very KA like but web 3 native on Cello.

Um and um there's folks who built applications that allow you to earn micro earn crypto for microtasks on your phone. So a lot of these types of use cases that really require transaction fees that are I would say sub one cent, right? I think the the 20 cent even 50 cent transaction fees that you sometimes have to pay on you know some of the L2s today because folks are doing um data availability using the Ethereum main chain you know that that wasn't going to work for these users and we didn't want to create something that would you know um basically make some of these applications obsolete so that's the first constraint um and so what's the solution? Well,

again for those who who saw the proposal and looked at it closely, um it's it's really IEN layer. You know, we we were really thrilled that I layer launched recently um because we were searching for a solution for this for a while and and uh we didn't want to do something, you know, where you just, you know, use a very small permissioned committee of um of trusted folks. Um it just didn't it just didn't sit right. It it didn't feel decentralized enough. And luckily I en layer um you know how many people here are familiar with IGEN layer just so I can give enough context most people here are familiar so as you know it's uh it's effectively a marketplace for trust uh in the Ethereum ecosystem and so uh

it it lets folks restake um their ETH that they're staking for uh running a validator in Ethereum um and it allows them to use that stake uh to offer additional services in effect selling their trust to others not just to the broader Ethereum chain for securing the chain but but potentially other things and you know as we all know uh Ethereum is highly decentralized and so that's a lot of trust right that's uh a really great place to look for um a you know very decentralized data availability protocol and what's really amazing is that it's not only are there a lot of people who can opt into this they also don't have to pay anything new

because they've already staked once and so the barrier for them to adopt IGEN layer and and all the middleares that will soon pop up um is is much lower and so that's really great and of course the middleware that we're particularly excited about is IGEND DA which is a middleware that um brings effectively a Danksharting alike protocol um to the Ethereum ecosystem you know potentially you know one two who knows how many years before Dank sharding ends up being released. Um, so that's really exciting. Um, and so we uh we're certainly um so the proposal talks a lot about kind of using IDA and we're going

to go into exactly how that looks like in a sec. Uh but before we do that, you know, there's challenge number two um which is that you know Cell is already a decentralized layer one, right? We have a lot of node operators that are um participating in the network that are validating the network that are running the consensus protocol the proof ofstake consensus protocol and it would be a real shame if we kind of just collapse that it's just one machine right um it took a lot of effort I would say to um to kind of build kind of this this community of really great folks we have some amazing solo validators we also have um incredible professional

validator shops as well as big corporates, right? Dutch telecom um is excited about kind of the mobile um uh um kind of direction of Cello and so they they actually very early on uh chose to to kind of join the ecosystem and they've been participating in validation ever since and there's many other you know really really great corporates as well that are participating. Um and so um it would just be you know sad if you know they all had to shut down and and kind of um move on. And so we wanted to find something that would um not only keep them um but also uh I think benefit from you know the decentralization that

they offer. And so that's the reason for um you know us really um focusing on on finding a path to turn this validator set into a decentralized sequencer set. Uh and that's exciting because as you know um decentralized sequencing is is relatively uh new. um um most of especially the big networks, you know, are still relying on centralized sequencers and some haven't even started actually designing and building out their decentralized sequencers. Um and so uh we're excited actually to um to take the work that we've done. Um Cello's proof ofstake consensus protocol has

been live now for over three years. It's been, you know, rock solid. it's only had one production incident and so it's also like a really great foundation for a decentralized sequencer and it's one that we hope to contribute kind of to the broader community through kind of um a module that can be plugged into say the OP stack. Um now challenge number three and you know those of you who have been listening closely will say ah wait you said two challenges only uh and that's because you know life is never that simple. you always think it's only two or three or four and then suddenly you realize oh actually there's way more things we have to think about. Um and for us that kind of unexpected thing was one block finality. Um because of the ease of use because of the mobile focus

and because of the focus on kind of real world use cases uh has had a design from the beginning that offers one block finality. Um and and this is just something that's hard to implement in in something that is rolling up to a chain that doesn't have one block finality. Um and it's important, you know, I talked about how we don't want to kind of change fees for our users. I think we also don't want to change kind of their expectation of finality either. Um and you know quite frankly one block finality um is is quite uh quite useful. Um certainly if you're making a payment for something and you're getting a physical item in

exchange it's very uh difficult to recover from that kind of twoerson transaction if suddenly the payment gets reverted right you know the person has already the item you can't revert the item. Um and so uh we spent a lot of time looking at uh the solution here and um you know I think the uh most obvious solution um is to you know add slashing for equivocation. So uh we'll see this in a sec in a detailed diagram but uh in effect um when uh a chain if it to prevent reorgs you want to make it basically very expensive to uh to in in this case the decentralized sequencers

in the current case of cell the validators uh to equivocate on a certain block or on a certain transaction uh bundle. uh if they do that then they'll get slashed and it's not just one but actually as we'll see you'll end up being up to twothirds o of these uh folks who can get slashed and so there you add some economic security um and then the other thing you have to do is um you know some some of the existing L2 designs when you're depositing from the L1 to the L2 you um you don't always have to wait for finality on the L1 um and that's because the L2 is happy to reorg if the L1 ever reorgs. Um, and so if say your transaction gets reverted on

the L1, that's fine. It'll get reverted on the L2. Um, and that's nice because it gives you kind of um a shorter bridge latency when you're going from the L1 to the L2. But it does mean that if the L1 reorgs, the L2 will have to reorg. So if we want to prevent the L2 from having to reorgan these cases, then we have to um make it so that deposits and also forced transactions um really can only uh be um considered finalized um at the L2 level uh after kind of the Ethereum finality window. So roughly eight minutes or so. Um and so that's the other kind of change that we have to

make. Um, so how does everything look like together? Um, I kind of have this little build that kind of goes through the life cycle of a block. So hopefully this will kind of illustrate a little bit how this looks like. We have kind of the three main uh roles in the L2, the decentralized sequencers, uh, the DA nodes, um, and the L2 full nodes. and then kind of the Ethereum chain I'm just showing below. Um so um step one is uh the decentralized sequencer is running a BFTbased consens consensus. uh BFT uh typically elects a leader um and then um

that leader has you know some time window to um um perform some actions and those actions include you know starting off by proposing uh a transaction bundle and so that's what this leader here I don't know if you can see that clearly it's kind of glowing uh blue uh to denote kind of the the node that's kind of taking the action at this time step and so it proposes a transaction bundle um broadcast it out to the network uh all to all the other validators sorry validators today sequencers um uh tomorrow um and those sequencers look at the transaction bundle um in an L2 they

don't have to execute it so it's actually quite easy they can achieve consensus relatively easily uh and they do so by sending their signatures back uh to the leader. Uh on Solo, we use BLS um cryptography um BLS 12377 cryptography which allows you to aggregate all of these signatures into a single multisig um similar to Ethereum. Um so this is nice. It's small constant size. Um but because we need the ability to um we need attribution, we also include a bit vector of everyone who signed.

Um and so now we have kind of the transaction bundle. We have a BLS multi- signature um from the kind of BFT consensus and that bit vector. Uh and now um technically any node that's uh sequencing can do this, but for simplicity um we think it's best to have the um leader do this. And if the leader fails to do this, someone else to um jump in. um we we send um kind of the combination of these two things to DA um which um will effectively kind of shard this data across all the different IG dA nodes um

and uh return a threshold um signature um which we can call an Igen DA certificate and that's over the hash of the data um and one of the really nice things that uh ID offers is that you know because you can effectively um um shard this across the uh entire DA kind of um validator set if you want to call it that. Um uh it's actually very very cheap from a cost perspective and so this is kind of one of the uh reasons why we're very excited about IDA IVA uh

and about DAN sharding. um you know uh in distributed systems uh data availability is actually not too difficult of a of a problem. It's one that paralyzes quite nicely. Uh consensus is one that doesn't paralyze quite nicely. And so that's that's the expensive one. And so that's why today for many roll-ups that are using Ethereum for data availability, they're paying kind of 90% of that transaction fee that you're paying to the L2 is actually going primarily to cover data availability on the L2. And so if you use something like DA, you can actually lower that and in the future if you use DNS sharding, you can lower that significantly uh which is really nice um because then it allows you to keep

transaction fees cheap. Uh and so you get this IGA certificate back. Um and now you know the decentralized sequencer is sequencing and and the L1 is the source of all truth here. And so we need to post that uh certificate to Ethereum um so that we can sequence all of these different transaction bundles. Um and so again this leader in this BFD consensus protocol can do this and if they fail to do this anyone can do this because IDA certificates are deterministic. You can get them um from the IGDA network. So any other uh validator can do that as well. Um now once it's on Ethereum uh and once it's finalized on Ethereum then any full

node in in the L2 network can download the certificate um and fetch the data uh corresponding to it from IGDA. Um and then you end up getting uh what that um what the decentralized sequencer placed into IGNA which is kind of the transaction bundle and the BLS multisig um as well as that bit vector. And so here the key thing that you have to do is um validate that um this BLS multi- signature and bit vector is correct. Um and um and that's I would say an interesting point because a lot of people when they talk about decentralized sequencers they

talk about having a smart contract that verifies um the correctness of um the data and and the fact that it was agreed upon by um these decentralized sequencers. They they talk about doing it in the smart contract level in Ethereum, but that's actually quite expensive and it turns out it's actually not needed. Um if you have full nodes simply do that verification at this step um then you don't have to pay kind of the extra gas cost to do it in in in Ethereum. Um and it has some implications for the bridge but for the actual just core um you know finality protocol for the L2 you don't need it at all. Um and um

what's interesting is this isn't just trivially checking oh there's a permission set of decentralized sequencers uh did they correctly sign this um in in Cell today and in in this proposal uh that set of sequencers can change at any point in time and so um you you actually have to run like um look at the current state of the chain to see who is currently elected who is currently allowed to sequence these transactions And then you verify um that those signatures match. And so you can think of this as actually running something that looks like a like line protocol uh to verify that this is actually correct.

Um and so once you do all this then you actually can derive you know the L2 block. Um and from then on you have kind of an L2 block. Um and you can sync the chain. And this is in effect kind of the um the way that these these nodes get the the source of truth for what is happening in the network. Now um if you guys are familiar with kind of the inner workings of some of the existing L2s today, you'll know that um you know this is a bit of a slow path, right? You have to wait for Ethereum and sometimes it's nice to be able to sync more quickly. Um and so what many people um are doing is gossiping

um blocks directly in a P2P network. Uh we call um OP stack calls these things unsafe blocks. Um and so these full nodes can get these unsafe blocks directly from the decentralized sequencer sooner. Um and that's nice. Um but uh it does present an issue which is you know what happens if these two things don't match? Um right that uh sequencer could have uh created one transaction bundle um and the whole decentralized sequencer could agreed on it um and could have posted it to Ethereum and then they could have got created another one and then gossiped that twothirds

would have had to have acted maliciously but it is feas you know not unfeasible for that to happen. Um and so in that case um you know there's a solution um oh and you know you might say okay well you know this will just create a reorg and we just always trust um you know what's happening in the L1 um but you know that would mean that it could create a reorg right and you know we talked about the importance of one block finality um we we really want a solution for this and so the solution is you know one that we talked about before uh if you ever discover that this is happening. Um well, it's actually really easy to tell that this happened and it's really easy to attribute um which of

these decentralized sequencers contributed to this um because we have that bit vector that shows exactly who signed and who equivocated. Um and so if the two things don't match um then you can you have all the evidence that you need to create a proof that you know a certain twothird majority of these sequencers needs to be slashed. Um and so this is how we we kind of solve this this issue. Um yeah and so maybe just to conclude around finality you know with this type of slashing and with um the changes that make it so that all transactions that are being kind of forced into the L2

from the L1 and all deposits uh if those have to wait for finality on Ethereum then you end up having a a slower bridge um but you end up having you know much better UX for developers and for users. Um and it's true that right now this is secured this one block finality is secured with the uh economic guarantees of the cell network and so all of the solo stake uh that's put to use but uh it really opens a door for us to um extend this to offer additional economic security and so I en layer um allows you not just to have you know DA as a

middleware you can have other middleares and so we've been chatting with the IGEN layer team about also having kind of finality gadget middlewares as well that can kind of really um let the the whole um uh let you kind of tap into kind of all of that economic security of all of the uh layer validators who are opting into the service and you know all of the incredible amount of stake that they have collectively. Um, so that's really exciting and you know what this ultimately means for developers and and and builders, you know, certainly better UX uh for end users, certainly easier uh time for developers because you don't have to think about the UX in the case of a reorg um but also um it it ends up

making salo a really nice place for L3s to roll up to um because you can just take an offthesh offtheshelf um uh L2 system uh and it will just not reorg. Uh and so then you just don't have to actually think about reorgs. Um and so that's really nice and so it makes cello kind of a really nice place potentially for L3s. Um so yeah, I think that's the kind of everything I wanted to cover. This is the last uh emoji. Uh I'm really excited for this. Uh it seemed like the reception generally from the the uh folks looking at the proposal online was also really positive. So, you know, we're really really pumped. Uh we're

going to have a governance vote on it next week and if it passes, um yeah, expect to see as an L2 coming to you soon. Thank you so much. [Applause] Any question like okay coming Uh thank you for the talk. So how does it compare to existing solutions for example mantle uh with using DA or the technology similar to DA?

Yeah. So, Mantle um is an L2 that is kind of I think working uh on also using uh IGN DA. Last I heard they they may end up actually using a fork of igen DA and not DA itself. Uh and so it may end up looking uh a little different from this. Um but um I think the main difference is you know the fact that that we're working on that decentralized sequencer uh and also um the all of the effort that we're putting into one block finality. Uh so I would say those are the two big differences. I mean I think also Cello is an established network.

It's um you know available on a whole bunch of exchanges and amazing custodians. is it's being used actively in in a lot of uh markets especially in emerging markets for P2P payments and so I think um you know just from that perspective it's it's just already very different. Hey uh thanks I'm super excited about this and my question is when L2 so when is when is that going to materialize what do you expect in terms of timeline? Yeah, the most important question. Um, so uh first of all, we have to wait for the governance proposal. Um, you know, we have started some work on this obviously even just coming up with this design and and uh getting feedback and

making sure that it's um um um implementable easily uh was the first step and we feel pretty good about that. Uh and but of course um you know we're still waiting for the governance vote. Uh once that lands uh if it if it's uh positive um then we're going to be full of steam ahead. Um we we expect this to take two hard forks. I think it's you know it's a bit of an effort to turn L1 into an L2. It's you know it is u something that's operating alive. We we don't want to just take it down. Um we can't take it down. Um so um I think that's going to take some effort. But uh the current plan is to have uh two hard forks. the first of which is already

slated for August. Um, and so that will happen soon. Uh, and then the second of which, um, you know, it's really hard to estimate, but we're, you know, optimistically aiming for the end of the year, beginning of next year, and so hopefully we'll be able to hit that. Thank you. Thank you so much. I'll be outside if anybody has any questions. [Music]