Deploy Rollups on a Celestia Light Node

All right, we're live. GM, GM, GM everybody. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute window for builders to showcase something they're passionate about or have been working on in Web3. This could be an awesome project they've been working on, demonstrating new testing best practices, automation goodies, smart contracts, how to structure a project, etc. Basically, if you've got a passion for something, this is your opportunity to share it with the Web3 community. And today I am ecstatic to have back on Josh, as well as a special guest Josh has brought on, Dev Bear. Welcome gang, welcome, welcome.

How's it going, Narb? Great, great to be on.

Yeah, GM, Narb, everyone who joined in. Thank you for being here.

Yeah, pleasure to have you on, boys. So I guess before we get going into the content real quick, do you guys want to give a brief background introduction about yourselves?

Yeah, sure. My name's Josh. I'm a solutions engineer at Celestia Labs, mostly working on demos with rollups and light nodes. And I guess something I've been working on recently is an app, to be named officially, currently called Quasar, that is a light node client for macOS. So I'll be showing that off and then we're going to talk a little bit about rollups.

And I'm Dev Bear, co-founder, one of the co-founders of Berachain. Basically, my background is software engineering by nature. I was a senior software engineer at Apple for a while and then left that to found Berachain and have been working very closely with Josh and a lot of the Celestia rollup ecosystem team for some integrations, which are EVM framework Polaris, which Josh will showcase some of that as well.

Fantastic gang. Yeah, and like I said, pleasure to have you on. I know we're jam-packed for content this DevNTell, so let's get right into it. I will add the stream here.

Sweet. So, yeah, I'll go ahead and get started on this. I'm going to try to speed through it kind of quickly. In the last DevNTell, I went over basically everything related to what light nodes are and how to run them. But I think I might have left out the why and what the purpose is and what you can do with a light node. So we did introductions. My name's Josh. And we're going to be going over a few topics in the slides.

First, we'll cover briefly what is a modular blockchain, then what is Celestia, and what is a light node. Lastly, we'll cover why you should run your own light node and what you can do with it. So first, what is a modular blockchain? You've probably heard this like quite a bit recently. But simply, a modular blockchain is a blockchain that decouples the core functions of a blockchain. And those are typically thought of as execution, settlement, consensus, and data availability. There's different ways that you can split this up, and sometimes consensus and DA get combined together. The same with execution and settlement. But broadly, the way that you can think about this is using an analogy to the OSI model of software development. And the way that I just think about it is when I go and send an email, I know that each layer of the stack is very specialized in order to allow me to do that, or accessing a website or something like that. But I don't really know what's going on under the hood, but all I know is that it works and it's efficient. So that's kind of like a good way to abstract modular blockchains and think about them. We're basically focusing on splitting apart the different layers and making each one of them more efficient.

So going a little bit deeper into that, what is Celestia? Celestia is a modular consensus and DA network, and data availability network specifically. And we're building Celestia, the blockchain, to enable anyone to easily deploy their own blockchain with minimal overhead. So, yeah, what is a light node? You've probably heard a lot about it recently. You've probably seen the tweets, the memes.

But broadly, there are two different types of traditional blockchain nodes. A full node downloads and verifies all of the blockchain data. So it's going to download all the transactions, re-execute them. But what this results in is a much higher barrier to entry, and a minority of users can actually run these full nodes. And as the network grows, the resource requirements do as well. So we also have light nodes in traditional blockchains. But these only download the block headers and they don't actually verify the data within those headers. So security assumptions are a little bit looser. But these light nodes do have a lower barrier to entry and allow a majority of users to run them.

So thinking a little bit deeper into these light nodes, the basic light client or light node is going to trust the information in the body of the block that they get from the validator. Whereas a Celestia light node is going to use something called data availability sampling to download a tiny portion of the body of the block along with the header and then verify that that data is available. So a little bit tech-heavy. I wanted to put this in there in case anyone wants to go back and read. But you've heard about how to run it and how easy it is and how little resources it requires, but why should you actually run those? So light nodes use significantly less resources than full nodes do and they don't download and verify the entire blockchain. They're more accessible and convenient. They can actually be run on mobile phones and personal computers. I forgot to charge mine, but I have been running one on an Android recently. And then what this does for you as a user is it allows you to verify the data that you retrieve from the network. And this is what is happening when you're doing data availability sampling. So basically, you have a high level of security assumptions without verifying the entire blockchain because it's just not scalable. Some other advantages of running a light node are fast synchronization. They can synchronize with the network much faster than full nodes. I actually have one that I started here like within the last hour and it's almost caught up. Actually, it is caught up all the way.

A light node uses much less data because it doesn't download the full block, and this is ideal for people with mobile phones or people with limited internet bandwidth on a personal computer. So, yeah, light nodes can verify the authenticity of the data they receive, and this just gives you a better trust assumptions and you have to trust other people less, which is really what we want in a decentralized network. Go ahead and skip through this one.

So, yeah, I guess one of the core concepts that got me really interested in Celestia, the blockchain, was data availability sampling. And what this really allows at the end of the day is it allows for blocks to grow. So the more nodes that join the network, the network can support larger blocks and still ensure that all that block data is available to all the nodes. And the increase in number of light nodes increases the block size, and at the end of the day, like the end goal is that we can scale these blocks and process more transactions in every single block.

So this is a little visualization of what that looks like. In the monolithic blockchain world, or the traditional blockchains, the full node downloads the full blocks, re-executes all the transactions, so as the blocks grow, the hardware has to grow as well. And this is something that causes like significant, really significant cost increases on the validator side and full node side just because it uses so much bandwidth and compute power. So, yeah, in the modular world, and in the Celestia blockchain, these light nodes download a tiny portion of the block and that stays pretty much consistent. So as the blocks grow, the cost increase is minimal. Some tweets you've probably seen recently showing off like how light these nodes can get, but I did want to stop and see if there's any questions before I go any further.

Yes, we do have one question from Kempsterrrr. Is Celestia launching its own L1 or empowering folks to launch L2s on ETH?

Yeah, perfect, good question. So Celestia is launching a layer-one data availability and consensus network or blockchain. And what we're aiming to enable is for people to be able to deploy their own blockchains as easily as they can deploy a smart contract today on something like Ethereum. So I guess like the asterisk there is that while we are launching a layer-one, we're also empowering people to launch layer-twos on top of Celestia that can settle on Ethereum or things that are known as sovereign rollups which settle in their own execution environments, have their own execution environments and settle on their own. So I don't think I have the slides in this slideshow, but there is a good graphic that I can share later on that shows the different breakdowns of how these look.

And Josh, maybe I was going to say maybe it might be useful to kind of give a high level on how Celestia is able to verify or get a high degree of certainty that something's down with only a portion of the block. Is it something like all the different nodes get different portions of the block and then that's how they make up the full block or something like that?

Yeah, yeah, so that's I think that's something I took out of this these slides because I did them the last time, but that's a really good thing to cover. So I've added something into the docs recently that's called I'm calling CelestiaGPT and if you ask it to explain data availability sampling to a five-year-old or like I'm five, the way that it does that is you can think of it as if we were all going, like Dev and Narb and I were going to search the playground, we're trying to find our friend Kemp. And instead of Narb and myself and Dev all going and searching the playground the entire thing, we decide that we split it up into little three parts. So I go search the first part, Narb searches the second, Dev searches the third. And we come back and put our heads together and say that okay, we found Kemp, he's in the third, he's in like the third section of this playground. So instead of us all going and wasting our energy searching the whole thing and then all coming together and saying, hey, we all found this person in the third square, what we can do is split that up and only search a little piece of the playground and then come back together and agree that we can with a pretty high degree of certainty say that Kemp is in that third square. So, yeah, I would love to like say that I came up with that, but there's probably a number of analogies that you could use to kind of understand how data availability sampling works, but that's like the best one that I've heard so far.

Awesome. Yeah, for Kemp, Celestia is just a data availability and consensus network, and what that means really is you can post data to the network, you can have a proof that the data was posted, but they're just going to be ordered as they come in and made available. And that's really what the whole goal is, is to just make that transaction data available for like the most recent blocks. There is data storage as well, but, yeah. Beauty. Great questions.

Sorry, I wanted to go back to this graphic. On the bottom, we're building this consensus and DA layer. On top of that will be execution layers, and these execution layers can be all sorts of different flavors, so like Solana Virtual Machine, Ethereum Virtual Machine, Cosmos SDK, whatever you want to use. And on top of that, you can build your smart contracts and applications. So we've gotten the how and like a little bit about the network, but why should I run my own light node?

So as we've talked about, you can verify data. So let's say that I query my balance on the latest block using my light node. What I can do is verify that to a very high degree of certainty that the data is there. The big thing we're trying to enable is for people to run their own blockchains as easily as you can deploy a smart contract, so you can run a rollup. You can also participate in the network, meaning you're contributing to the decentralization of the Celestia blockchain and just generally accessing the blockchain without having to trust some entity like an RPC provider. You can actually query that data yourself and then verify it yourself. So verifiability's a big thing, but also running rollups is really what we're trying to enable here.

So I guess I wanted to show off something that I've been building. Oh, nice. So, yeah, I was doing like an internal knowledge sharing and having everyone go through the binary, and Mustafa, our CEO at Celestia Labs, recommended that I build a pre-compiled binary app. So I went ahead and started hacking on it. Calling it Quasar for now. Name is probably going to change eventually. But what we can do here is initialize a light node. It's going to have us save the mnemonic. I'm working on adding WalletConnect eventually, so you can just log in with a wallet that you already have. The next thing you can do is start the node. And what that's going to do is give us the height of the network and then it's going to give us the catch-up head. So these are the block headers and bits of the body that we've downloaded. And then the sampled chain head is actually the point of the chain that we've sampled up to. So as a real quick demo, I'm going to go ahead and copy my account address to the clipboard and go ahead and paste that in and it won't be immediately, but I can go ahead and check my balance. I'm going to first open the explorer and check that out. Yeah, it's actually a brand new address. You can see that there's 100 TIA in there. So normally you'd hook up to an RPC provider and you would just trust the data that you're getting from there, but here we're getting data from the core consensus network and then verifying it with data availability sampling on our light node.

So I want to go ahead and stop that now. If you want to help build this, it's just like a fun side project for me right now, but I'd love to have anyone who wants to helping with that. But I think I wanted to show off how to run rollups today, so we're going to go ahead and start that. In the meantime, are there any questions?

It doesn't look like it, but I'll let you know if something comes up.

So I have just started a light node. Everything up here is basically just the initial setup, but we can see that the node is started and it's receiving new headers and then sampling the little bits that it hasn't sampled. So what I'm going to do now is just make sure that my light node is actually caught up, and I can do that with the RPC CLI and I'm querying the sampling stats. So similarly to what you saw in the Quasar app, I have the head of the sampled chain, the head of the catch-up, and the network header all at the same time height. So that means my node is fully synced. When it's not synced, we're going to see quite a bit more about the different catch-ups that are happening at the same time.

So I think now is a good time to talk a little bit about Polaris. We're going to be starting a rollup on the light node. And basically what that's going to be doing is there's going to be a sequencer running and a rollup running and it's batching up its transactions and then posting that data to Celestia.

So, yeah, I guess a little bit of background on Polaris. Polaris is a Cosmos SDK based EVM. And this is something that will be running on, like the Berachain network will be running with Polaris, but it's also something that you can use to spin up your own rollups. So, in order to get started, you'll need a light node running. I'll go ahead and share the link to this as well. And I've already cloned the repository. So I'm going to go over here and just do Git show and we can see that I am on the latest commit. I already have the light node running. The important thing to do here is to make sure that your node is funded. It will need to be funded with tokens in order to post data. So go ahead and check my balance. It's taking longer than it should. Yep. Tragic. Anyways, I'm going to go ahead and just kill that right now.

So I'm going to go ahead and list my address real quick and just head over to the faucet and load that up to make sure that I have some funds. We're going to hop back to that page. All right. Got to go tab jumping. Yeah. All right. So in order to interact with the light node, you actually need the auth token. So what I'm going to do is generate that from the light node that's running using the account that it's running on.

And I'm going to copy that to my clipboard. I'm then going to open up this Polaris repo and I'll drop in our auth token into this startup script that we have for Polaris. If only Diego was here, he'd be so proud, Josh. I know, right? I was that's what I was joking about friends she got a video of me live coding at Modular Summit and it just I it broke. I deleted dependencies and it didn't work. That's amazing. All right. So basically what I just did is I generated the auth token from the node. I added it into this startup script that we have for Polaris. And then the next thing we can do is start the chain. So just going to make sure Foundry's installed and then we're going to CD into Polaris, which is within this repo, and then run Mage start and that's going to run our start script.

So the Cosmos SDK is building the chain and then we also have some smart contracts that are being compiled. We're also going to begin to see some logs show up on the light node once the chain is running. These are expected errors. They don't look pretty, but we know about that. And what we have now, I actually think Dev, if you want to tell us a little bit more about what's starting up, that would be awesome. We have an RPC for the EVM that's running, but we also have the Cosmos SDK kind of running underneath of that.

Yeah, so the way you want to think about the architecture of Polaris is you can think about it as like there's a Cosmos SDK chain that's like orchestrating an EVM chain. So you can kind of think about it in the sense that like transactions come in from the Cosmos chain, they're passed to the EVM chain, and then the EVM chain will execute those transactions and then report them back to the Cosmos chain. So kind of by proxy what it allows you to do is if you have a Cosmos chain that's running on Rollkit, you're able to have an EVM chain that's being kind of secured by that Cosmos chain, which is then posting its data to the DA layer. Sweet. Yeah, so I guess I managed to forget that this is using Rollkit and Rollkit is a holy Rollkit is an open framework for sovereign rollups and this allows you to build your own blockchain without having to bootstrap a whole consensus network and under the hood that's what Polaris is using to post data to Celestia.

All right, so now that we have this running, we're going to go ahead and peek at these logs. We can see that it's looking for a blob a little bit too soon, but the data is getting posted correctly, so we'll stay over here. The next thing we're going to do is CD into the GM portal directory. This is really just a smart contract test that I've been using recently to test out EVMs. So I'm going to go ahead and export the private keys that are set up by default whenever you start a Polaris rollup. And then we're going to deploy the contracts as well. So right now the contract was just deployed to Polaris or it's being deployed to Polaris. We're waiting on that confirmation receipt. And the next thing we'll do is just export the contract address, which is right here. And we can interact with the contract using the same private key and the RPC URL is going to be at our local host. We're coming up on time too, so I guess if there's any questions, would love to help answer them.

And I guess a little fun fact, this rollup is actually running on our Arabica devnet for Celestia and it's actually posting data. So if we wanted to, we could go find this address on the explorer and see that it's been posting some transactions. The last thing we'll do is just get total GMs. So I've sent a GM once, sent one again, and we'll just go ahead and see those transactions actually went through really quickly and we can query them as well right after. Yeah, live coding is risky but it keeps you on the edge. Exactly. I was just going to say, whenever it works though, it looks extra baller than a video. Yeah, I know. I think we're just we sent the last one at the end of a block. So yeah.

That's really all I had prepared. If you want to go through this yourself, I think we can share the link to this. And I also have a little portion that you can update the frontend with the ABI from the contract and actually interact with the GM portal on there. I'm going to go ahead and skip that right now unless anyone's dying to see it. But, yeah, that's pretty much it. I guess another thing that's worth showing off is an integration with the OP stack that we worked on recently and this allows you to deploy your own OP stack testnet or devnet with Celestia. And actually, unless there's any questions, I guess I'll go ahead and just spin that up real quick. First, I need to shut the other half down.

We do actually have a question from Kemp. What are the benefits for deploying a rollup like this versus how they are deployed currently to say ETH, Ethereum?

So the real benefit is that you don't really get constrained to Ethereum as an execution environment. A lot of the bottlenecks that we're trying to solve with this modular blockchain model is that a lot of the execution environments and settlement layers get clogged up because everything is coupled together. And, yeah, really like allowing for interoperability is something that is like a big part of our vision and not constraining people just to that one execution environment is a big part of it. So sovereignty is a good way to think about that and being able to deploy a rollup that is just kind of lives on its own as opposed to having something that is tied to Ethereum. That being said, you can also build something that's called a Celestium and it basically settles on Ethereum, but execution can be off off of Ethereum. And that really just like saves a lot of call data. Interesting. Maybe a topic of a future DevNTell. Yeah, I think we can go deeper into different like rollup architectures.

I think it is actually interesting to just touch a little bit on the Optimism integration. I'll send the docs to that. So yeah, that was that's all I had prepared. The rollup is not running anymore, but it did get to about 10 blocks, which is always fun. Are there any last questions here?

I guess one would be what kinds of things you need help with to continue building out the Quasar app? You mentioned that people could contribute on GitHub. I believe I've shared the link as well in the chat, but we'll also share it in all the other post-content after this as well. But yeah, if people are interested or want to ask you more questions, you or Dev more questions, how can they how can they reach out as well?

Yeah, I guess I would say just like reach out on Twitter. If you want to go directly and like pick up an issue and make a PR that would be great, but it's written in Swift and I don't know how many like Swift devs there are out there. Something I've been thinking about actually is making the actual like desktop application something that's built with like Electron or Flutter even. But I'm still kind of weighing the options of like the best way to do that. So I guess if there are any like application developers out there that want to help out, it's really just kind of like for fun on the side for me right now, but it's something that I'm definitely interested in continuing working on. So, yeah, I would go ahead and say just check out the website and that'll take you to the GitHub where you can see the issues that I've been putting in there.

And then as far as Dev goes, I'll let him kind of do that if you want. But I think, yeah.

Oh, all good, all good. Yeah, in terms of on the Polaris side as well, if anyone's interested in getting involved, we're trying to work with lots of teams so that not only Berachain can utilize Polaris but other chains as well. So if you're interested in building a layer-two that uses Celestia and Polaris, definitely reach out to either Josh or myself. Narb, if you could drop my Twitter in the chat, I can't type. That would be awesome. Reach out to me on Twitter, GitHub, Telegram, all the same handle, and I'd love to kind of help you guys out and get you guys in touch with our team.

Excellent. Yes, and I will also be sure to share all the all this all these links as well in the post-content that comes out as well. But unfortunately that brings us to time. Thank you so much gang for coming on. Really appreciate you taking the time to come teach us all this and live coding, live coding like we said is extra baller when you get it to work. But before everybody leaves, just want to share the QR code to claim your kudos for being an attendee today to DevNTell. And Dev, Josh, I have a separate one that I'll share with you after the fact. But folks, if you're still here and you watch the whole thing, please scan this QR code and claim your kudos for being an attendee today. You will have one hour up to the top of this hour to be able to claim that. And with that, I just want to wish everyone a very happy Friday, happy weekend, and we'll catch you back here next week.

All right all. Peace. Thanks, Narb.

My pleasure. Thank you.