Building on Scroll: Getting started & exploring L1SLOAD

[Music] okay are we good to start okay hello hello um this is kind of a two-part presentation because we don't know the makeup of the audience so I'm going to pull you guys for kind of what I need to explain and what I don't and depending on how it goes I might disappear immediately um so we'll start off does everyone here know like who here knows how like rollups work kind of okay cool um I will try to start from the beginning but talk super fast because we are super intense on time so we have building on scroll today we're talking about the intro to scroll as well as exploring l1s load we do a lot of internal research so today's bouny is that we'll be doing kind of covers both sides um so I'm going to start off with like the basics right like what are rollups well why do we even have them ethereum is [ __ ] slow and expensive right exactly why we're going to talk about the blockchain trilemma so basically it's a pck two situation between scalability security and decentralization right you can't have all three together so what do we do I mean ultimately at the end of the day ethereum's like principles are security and decentralization so how do we solve that and so that's where l2s come in um so l2s are basically um what they do is we take the execution offchain right so rather than having to do all that expensive compute on ethereum we actually do it in a separate Network which is the L2 it's called a rollup because we basically roll up all these other transactions and and then post them to ethereum what that means here I specifically specify here is data availability so we inherit the security and decentralization of ethereum because all of that data gets posted back so I think another thing that I want to clear about a lot that I think people get confused about is if you know polygon proof of stake polygon proof of stake is a scaling solution it is not a layer two and it is specifically because they don't post their data back to ethereum so that's like an important thing to kind of differentiate um now we dive into like the different types of rollups so in kind of the history of rollups you might have heard of optimistic rollups they're kind of the ones who came first um and they differentiate themselves basically on how they prove so when we post that data back to ethereum we want to verify that it's true we can't just like post random [ __ ] right so what that looks like is with a fraud proof we just optimistically assume that it's true there's like cryptoeconomic incentives that basically make it like so that you don't want it to not be true um but what that means is we have like I guess something called The Challenge period right so we need to set aside time for people to come and say hey that looks kind of strange let's do a fraud proof um and then actually check whether or not this is correct or false right um so what this means is we have like what we could say like slower finality finality being like the like it's time to finalize on the L1 right um which also means withdrawal times or so withdrawal means pulling from the L1 so getting your funds out right um so there's like a little bit of liquidity fragmentation if you interact with rollups you probably actually don't experience that because you're using third party trusted Bridges to basically give the feeling of instant finality um but obviously we know oh hopefully you know Bridges have been I think the major hacking point that uh We've touched so anyways that was the first iteration what what's the next iteration we talked about ZK proofs right so instead of proving uh like having a challenge period let's say let's be proactive about it let's mathematically prove this first and then submit the proof of verification first um the other thing that I always like to note here as well is with ZK proofs people often think privacy with ZK we don't use it for privacy we use it for scaling and what that means specifically is proofs CK proofs have the smallest amount of data that we can post back what makes a rollup expensive is that data size that we're posting back as well as like the verification compute time anyways so that's the quick overview and now we're going to dive into a little bit like okay wow there's so many ZK Roll-Ups how do we decide between all of them right so um if you're not familiar with the different types of ZK EVMS basically there's four different types the KMS being at a very high level kind of the the way you translate uh code into math in order to make it provable right um so type four is going to be the farthest away from a ZK evm so or like a pure evm so what that looks like is a ZK sync or a stark net what that means for you as a developer it's high level language equivalent it is not bite code equivalent so you're going to have to download plugins it's not going to look exactly the same um we can kind of scroll down to type two so that's kind of where scroll sits we are bite code equivalent so what that means is you know it compiles down the same your pre-compiled off codes are covered um it should feel uh developer experience wise exactly the same so normally you deploy you're like oh my network is aola you literally just switch the words to say scroll um and it should work right uh and then type one is going to be ethereum equivalence um we're uh basically the main difference here is like the way state is hashed and stored is a little different um but for the most part as a developer type two is kind of the seamless experience that you'll get the trade-offs here are going to be like type four because you're the farthest away it is easier to be faster and cheaper whereas type one is going to be like the hardest to become fast and cheap um but that being said technology is ever moving and I think the assertion that a type four will always be faster and cheaper not necessarily true so anyways move on we talk about scroll how does it fit into the picture um I don't know how much time we have left so I'm going to talk about this really fast so like I said we are evm compatible we're type two what that means is we leverage the network effects of ethereum oh we have five minutes [ __ ] okay we have 10 minutes oh oh God oh God um we're secured by ZK proofs I think the other thing that I want to touch about was security especially when we think about bik code compatibility um how many of you guys are familiar with a Viper hack nobody okay so basically Viper right is a high level language right so you can write smart contracts in Viper what happened was I don't remember which protocol but they lost a bunch of money and why was it it wasn't because the code smart contract code had a bug the Viper language itself the compilation had a bug right so that's not like something you can really protect yourself from so when I talk about like bite code equivalence I think something I also like to think about when it comes to like a type two is because it mimics the behavior of ethereum like the ebm like you have that additional level of security that you wouldn't otherwise cuz from a smart contract auditor point of view the farther you are away the more kind of layers you have to think about which could potentially open up uh more attack vectors um anyways so scroll is this so we talk about I think someone always asked me like okay there's so many rollups what are we thinking about um the spicy answer is Tech doesn't matter ecosystem is the only thing that is there right um I don't necessarily think that true I think it's a a marriage of the both but if we're going to talk about what srel looks like on the ecosystem side um you know I think we have we'll talk about grants a little later if you want but I think we're really focused on like definitely like supporting Builders um like a lot of one-on-one interactions uh what I say when someone is thinking about like where do I to build the things that you to think about for a chain is longevity and legitimacy so there's a lot of different like technology coming out is what you're building on going to last um in scroll we have like a really strong name um and so yeah the other thing is I really I think we have a really great support for emerging markets so if any of you guys are from there please talk to me I want to figure out how to help build your uh Community anyways growth is insane those are big numbers anyway so that that was the part one to the deploy kind of casual I think we're going to dive into like I said Scrolls really heavy on the research side uh you have a question we can talk afterwards um Daniel is going to come up and talk about something really cool called l1s load that you guys could also potentially hack on all right thank you Emily I don't have quite Emily's energy but we'll get into this anyways um cool so that's the background on scroll I'm going to talk to you about something that we have only on our devet so we have our sepolia test net that you can hack on for the hackathon for this hackathon we also have a devet that has a special feature called l1s load going to be a little bit lower level probably but we're going to dive in here the idea is that we want to have a contract we want L2 contracts to be able to directly read L1 State okay that's about it and we're going to look at like why that's may be valuable why that's interesting how to use it um and it's a uh it's something we're introducing to try to get all the rollups in the ecosystem to align around because we need this to be a standard uh across L2 ecosystems so why well there's plenty of reasons to read uh L2 or from L1 into L2 there's a lot of value in the ethereum storage slot right it has the best security and decentralization guarantees it is a kind of politically common ground but amongst all these l2s has a lot of credible neutrality it's the default for protocols and also like past activity on ethereum there's lots of valuable and interesting data there both on sapoia and mainnet and every rollup has a canonical bridge that finalizes its state there what that means is the state route contains a lot of information that you can extract out of it and if that's sitting on the L1 you can start reading about other l2s from your L2 by getting that off of the L1 we'll kind of see that a little bit but um I think we'll have to push to have some conversations outside as well one thing that we've been uh looking at for this is the key store the idea here is that your verification Logic for your smart contracts can live on the L1 and you're able to reference it from all your smart contracts on the L2 um think oh data on L1 is expensive though um we've been kind of like working on a proposal where you read it off the L1 but you can delegate to update it from any of these l2s also happy to talk about this at any point uh this weekend I'll be around why are we doing this because direct reading from the key uh from the L1 is like way easier and cheaper for users and there's a lot less infro work required for app developers wallet developers or anything else there's lots of other ways to prove State um including all these paths here but they're complicated they're burdensome and instead we get to do something like this as smart contract developers uh this is a full contract that we'll read from l1s for from the L1 you pass it your contract address you pass it the storage slots in that contract and it will return that back to your contract so you can use it for whatever you need to we'll talk about some of those use cases um so this is uh the Crux of it here you pass it the pre-compile address you make a static call to that and you pass it the arguments um cool I skipped a few slides one kind of interesting demo that we did last month in uh Berlin was we worked with the safe team to where if I have a safe wallet on the L2 it will read the signers and how many signers are necessary from an L1 so that way if we have a treasury on L1 it's being managed by some folks every time that gets updated I don't have to go to Every L2 and update the list of signers and go ask everyone to go do additional signatures like all of this stuff can now become seamless cross chain so that's kind of one of the things that this unlocks but when you start doing cross chain stuff it might get complicated we might be doing Merkel trees we might be calling eth get proof RPC methods you might have to deal with like Scrolls ZK try and our ZK TR verifier so there are resources that you'll have to dive into if you want to get really complic at with these architectures but you can also just read a storage slot you can read the name of a erc20 token or something else um and I'm happy to like sit down at our booth and kind of walk through some of these resources if uh the documentation that we've provided doesn't get you there what does this enable well we can now have trustless cross chain coordination this is something that's like not necessarily possible using um the other kind of tools and bridges that you're imagining uh that are accessible to devs we can start building asynchronous composability we can do things like the key store um we can have ecosystem agnostic minimal rollups that's a mouthful but the idea is that you can devote just a really simple rollup to doing one behavior and then just utilize that from other chains we can think about bootstrapping new rollups by reading from L1 Oracle data into the l2s we can think about verifying asset or nft ownership to uh from a different network because you know often times people want to keep their nfts on the L1 and then if you want to get uh really fancy you can think about using uh l2s to do the ZK verifiers and co-processors for L1 protocols and then Bridge the state back and forth um there's lots of there's lots of design room here when you're thinking about the patterns and architectures for your hack uh and we would love to see all sorts of wild and crazy ones uh for me the weirder the better we have introduced this as an rip to the ecosystem we're looking for feedback so if you're also like on deeper into the research side or just have comments on how it worked um please give us feedback on this uh in the fellowship of ethereum magicians and help us iterate on it uh for rollups in ecosystems we really want people to either get behind the RP or give us reasons why they won't be able to implement it um but for apds it's more about testing ideation feedback and for hackers here we have two prizes at $2,000 each and remember you can just read any state from aoia so if all your hack project is on sepolia and you find an interesting reason to like pull that into an L2 um make it happen so this QR code will get you to a kind of hacker Resource page with information on our prizes there's a link to both a telegram bot that has a faucet uh for the devet and for scroll sapoia and um there's also a link to what we call a hackathon cheat sheet that should tell you all sorts of different projects that scroll sapoia supports so if you're looking to hack on three or four sponsors at a time uh scroll suppo is a good option for that as well you wanting to wrap this up or should I take the rest of these slides cool all right wrap it up here um so hack with us we've got 10K in prizes uh I already told you about the l1s load ones but additionally we have best project on scroll um how much was l1s Lo 4,000 that means there's a remaining 6 ,000 for best projects on scroll um I don't remember I think we have a winner and two Runners up maybe um so you know that can be on l1s load or not um we're just looking for Creative projects weird projects Innovative projects technically wild projects uh or just really good applications and use cases for problems that you kind of see in your own life so we also have a brand new grants program um there's plenty of more information here but we have a deadline on August 7th so if you're a builder looking for funding either you're just kind of getting started or you're needing support to like get your project to that next level and get really get it launched check this out we have up to $110,000 on one track and a 100,000 on another and we'd love to have you building with us building with scroll thank you and this is a QR code again for the the ECC URL one more thing one more thing two minutes read the requ and contract address in the GitHub verified on the Explorer always a good thing um I guess we have like one minute any questions uh the question is do we have block hashes on scroll um do you mean like every single block is there a block hash that represents the header ah yes there are challenges with that but I can't give you the off the top of my head the actual answer to it so I'm going to show you where to selfservice which is on the developers area of our documentation you can see that block has returns uh it's so basically it's not a proper block hash but it is a value representing the block uh that is going to be unique to the chain so yep cool thanks everyone for your time appreciate it [Music]