 I am Emily, I am the Truffle Developer Advocate. Today we're going to be talking about building a DAP on Optimism, specifically talking about how to incorporate bridging into your Optimism DAPs. Just want to give a brief disclaimer, I do not work for Optimism nor do I represent their opinions. However, I really love the project. Truffle and Optimism have been doing a hot collab and that is why I'm here today. Briefly touching on the agenda, I'm just going to give a crash course on L1s and L2s, assuming we have beginners in the audience. Touch a bit on bridges, go into Optimism contracts for bridging specifically, and then the best part of the demo, I guess a live demo maybe with DevCon Bogota Wi-Fi building a DAP together. Let's start off. Optimistic roll-ups here is a crash course. For those of you who don't know, just brief introduction. What's a layer one? What's a layer two? Layer one, Ethereum, Bitcoin, that base layer. Layer two, that separate blockchain that's focused specifically on increasing transaction speed, scalability, and what's really interesting here as well is utilizing Ethereum for data availability, so specifically the point of posting transaction data and getting it from Ethereum. I do want to note one specific thing you might wonder. Layer two specifically are defined by deriving its security from Ethereum. If you think about something like a side chain, for example, they don't. So those are not qualified as a layer two. So that is basically the key caveat you need to think about. So why do I even care about this? Why am I here? Again, if you've been around in the space, you've probably heard blockchain trilemma. It's a pick two out of three, decentralization, security, and scalability. For those of you who in the Ethereum community, I hope we have all agreed that decentralization and security is the most important thing. So what happens about scalability? Well, this is something we still really need to care about, because scalability affects gas costs, and gas costs is going to affect the adoption of Ethereum. So this is something we really need to think about, and who's here to help us? Layer two. Thank you. So definition again of a layer two is to decrease L1 congestion by bundling up transactions and submitting that to Ethereum. Again, things to note, right? Gets its data availability from Ethereum, specifically deriving its security from Ethereum, and helping us maintain that decentralized aspect. So next piece, we're going to talk about optimistic roll-ups because that's what we're focusing on today. I am not going to touch on zero knowledge. There are so many talks at Bogota about zero knowledge, so talk to them, not me. But to briefly touch about optimistic roll-ups, roll-ups again, pretty self-explanatory. You roll up a bunch of transactions and you submit it and post it once to the L1. Again, this comes in two primary flavors right now, optimistic roll-ups as well as zero knowledge. To touch upon optimistic roll-ups, what makes those different is they are optimistic. So when we submit these transactions to Ethereum, we just assume they are valid. You might say, wait, that seems kind of bad. Well actually, there's this thing called the challenge period. So essentially during this challenge period, anybody can come and say, hey, I think this is wrong. If they do that, they have to submit a fault proof. Basically, the fault proof basically either validates, hey, actually was correct, and then it gets submitted to the chain. Otherwise, no, actually, yeah, some shady person did something and this transaction is incorrect and so let's backtrack. So that's optimistic roll-ups. Again, the challenge period is the part we need to focus on here. Right now, for Mainnet, it is seven days which is kind of long, which is why people have started thinking about zero-knowledge roll-ups because that is something that you just post the validity proof for. So I think that's covered everything in optimistic roll-ups in hopefully less than two minutes because that's what I planned for. So let's talk about bridges now. Again, bridges, I think pretty self-explanatory if you've ever walked on a bridge before, connecting to blockchain ecosystems. Things to know about bridges, right? Again, is this transfer of assets and information. So a lot of times we talk about transferring ETH tokens but you can also transfer arbitrary data. The other piece is we're moving towards a multi-chain world. Basically, the point of that is to take in the pros of one chain to alleviate the cons. So when we're talking about L1s and L2s, we're talking about the pros of decentralization and security of Ethereum while alleviating the cons by using an L2 chain for that scalability aspect. The important part with bridges is it allows us to call an L1 contract function from the L2, and vice versa. So if I'm on optimism contract and I say, hey, Ethereum contract, I want to call your function. Bridges say, okay, we can do that. The typical way of doing this right now is this idea of locking assets. So it looks like user one will lock assets in a bridge contract. The equivalent amount of token will be, I guess, created on the L2. Then when we want to put it back, all of that is burned off and then released for the person on the L1. Again, big disclaimer, there is no bridging standard that exists yet. Again, a lot of research has gotten into this. I think also probably one of the reasons bridges are a little bit unsafe because it's totally a new frontier. So when we talk about unsafe or security, bridge hacks happen all the fricking time. I don't know, if you're on crypto Twitter, I'm like, okay, cool. I mean, as of August 2022, there is a study done basically 69 percent. I don't know if that was like fake number, but 69 percent of attacks have been on bridge hacks. Then very recently, actually, right before I was creating this presentation by a BSE bridge, rest in peace, but you did good for my presentation because I got to talk about you on the next slide. But anyways, why does this happen? Again, as I had mentioned in that previous section about how bridges are typically run, is it locks up liquidity. That is a prime centralized location for bridge hacks. So something people might also think about when creating bridges is the idea of decentralized bridges. I don't know too much about it, so I'm not gonna go into it, but you can kind of think about like that is a consideration you need to take and centralization is again, a big part of why bridge hacks are so intense. So how do you fix this? Again, disclaimer, I am no security expert, but number one, learn from BSE. So currently the way these bridges identify and authenticate target and source blockchains through its chain ID. And the BSE case specifically did not check the chain ID through the cross chain message. And again, something to think about. So obviously if you're building a bridge, maybe read up on all your predecessors and do everything they did, but better. Private keys again, that's something we really care about, different ways of handling it, hardware wallet, multi key chain system, et cetera. And then I think something people don't necessarily always think about is there's always that web layer, right? So the way bridges are surfaced right now is often through a UI, right? We talk about hardening your smart contract, maybe one way to also think about how you harden security is at that UI level. There's a lot more, I added a link of some research that people were doing, but you could probably just Google and then read every single page because it's intense guys. So anyways, yes, like I said, bridging is hard. What are we doing here? We're actually gonna go over Optimism's bridge contracts. They have already written a few contracts as well as provided at SDK for us to do this for a simple use case. Again, I think it's awesome because basically bridge contracts probably require a lot of security auditing, I am poor, I'm not a student anymore, but I'm poor, I can't do that. So Optimism kind of has provided that ability for us to incorporate bridging through battle tested contracts as well as an SDK if you don't wanna do any solidity at all. So let's actually walk through what Optimism has provided. So that first thing I talked about was transferring of data. So this is kind of the base level of what it looks like. There's two contracts called L1, Cross Domain Messenger, L2, Cross Domain Messenger. Again, these are pre-deployed by Optimism, so if you're bridging on Optimism, you will be interacting with these contracts. You can get their addresses from their GitHub repo. They will have one for each one for each chain ID. So there's an address for girly optimism, there's an address for girly, Ethereum, Mainnet, et cetera. Kind of diving into this deeper, the way this works is essentially we have, I'm gonna highlight the probably the two most important functions in this interface. Specifically, the first one is send message. So that is what allows us to say, hey, I'm L1 contract, but I wanna call contract function on L2. The way this works is, let's start over. I am Ethereum contract. I am calling L2 contract. That's the target address. So I'm gonna input that in there. The second piece is call data, right? So if you don't know how basically is literally calls functions right now, it's encoded into bytes, specifically by like the function string name as well as the inputs that go into it. So in order to call it on the L2, I have to encode that function name and inputs to be passed over to the L2 contract. And the gas limit actually is pretty complex. It seems simple to understand, but it's how much you're willing to pay. So I'm gonna go into the math here. Specifically, posting from L1 to L2 requires gas on the L2 section, right? In order to do that, optimism says, we will provide 1.92 million L2 gas for you for free. However, in the case, and this is pretty rare, assuming that like maybe you actually need to spend more gas than that, you actually would have to specify that ahead of time. And that gas is coming from your L1 gas at a one to 32 ratio. So in this specific example, right? So suppose the transaction actually took 2 million gas on optimism. You have 80,000 L2 gas you need to cover, which is equivalent to 2,500 L1 gas. I hope that made sense. If not, we can talk about it and I will just say the same thing over until you understand it. On the other hand, we moved from L2 to L1. This is gonna be more expensive because there's two transactions we're posting. Specifically, the L2 fee to post initialize the transaction and then the L1 fee to actually finalize it on the chain. So this is more expensive. L1 is significantly more expensive than L2, but that's because scalability. Wow. Okay, good. Next piece is cross domain messenger sender. Okay, again, for those of you who don't know, when you call contract functions on a smart contract, message.sender is how you know the address that is calling it, right? But for example, when we're thinking about bridging, right, say I'm like L1 contract calling L2 contract function. Message.sender is actually gonna, what do you call it? Surface the address of the L1 contract domain, cross domain messenger contract, right? I don't know if I said that correctly, but you know what I mean, the pre-deployed optimism one. So what do we want to know actually? I wanna know my address. I wanna know the L1 contract address. The way this is implemented actually allows us to say, okay, when I call X domain, blah, blah, blah, blah, I'm gonna return my address, not the address of the deployed messenger contract. Again, the next piece here is transferring ETH and ERC-20 tokens. This is probably the most common way of doing bridging, which is why optimism has kind of put that behind an SDK. I'm not gonna get into it because I only have 50 minutes. Thank you, DevVacoda or DevCon. But there is a really great Ethereum tutorial written by a person on there that actually steps through the contract step by step. So if you are interested in understanding how the token bridge works at a smart contract level, I suggest going there. If not, I will be diving into more of the part about using the SDK itself. I want to know as well, there are some things to know. You cannot bridge every ERC-20. So the way the token standard bridge works is it identifies both the, let's say ERC-20 token address on the L1 and then a token address on the L2. However, there are many ways you can, I guess you could have the ERC-20 token represented multiple times on the L2. So how does the Optimism Standard Bridge know which one to use? Well, that is specified specifically in this token list. So if you wanna add to that token list, you have to create a PR so that the token bridge knows which contract to bridge between. And then two keywords here, deposit. So deposit means I'm depositing ETH going from L1 to L2. Withdraw is gonna be withdrawing. So going from the L2 to the L1. Yeah, okay, so let's do the bill portion. What are we building? So starting off, I think one of the most common use cases where you might wanna embed a bridging UI is an NFT marketplace. So we're building one on Optimism and I wanna talk a lot about bridging because of the UX problem. So if you've interacted kind of with bridging right now, oftentimes it's a separate UI. So you go to another website or something, do the bridging and then come back. Or smart here, we're at DevCon, we understand how to do that, not necessarily the best UX for, I don't know, my mom. So what's the solution? Her name is Bridget, the bridge widget. Hopefully you understood that pun. If not, I will explain it to you many times until you understand it. But anyways, the point is to embed this kind of UI. It is just a component. So imagine if I took the time to put this on NPM, you could just NPM download into your app. I didn't do that, cause I don't have time. But anyways, this is kind of the UI of what it's gonna look like. You can create, mint and listen NFT, mint your NFTs, see what you do, you can buy them and specifically one of the views is gonna be that bridging component, which is what we care about today. So what you'll need is we're actually starting, this is where the Truffle collab comes in, guys. Okay, so Truffle has this thing called Truffle Boxes, which essentially create, I guess, scaffold code or educational code to help you start your dApps quickly. I wanted to talk today specifically about the Optimism Bridge Box because it is basically a empty project that configures a project ready to be deployed Optimism in addition to adding smart contracts that will do the transfer data portion as well as writing a script that will demonstrate how to do the SDK. And so, in part of the smart contract portion, what it does is it actually allows you to figure out how do I deploy across multiple chains in one go, right? I need to deploy on L1, L2, and then I'm calling a function on L1, and then I call a function on L2, how do you do that? Truffle Box. Right, okay, what else will you need? We are gonna be connecting to the Gurley Testnet as well as the Optimism Testnet because we are working with these deployed contracts. So you will need that information from Infura. You'll create a project separately to that because it's an NFT marketplace. We will be uploading metadata up to IPFS. You can do that through Infura as well. They have an IPFS dedicated IPFS gateway you can create for yourself. As always, MetaMath, you need that for everything. And then GurleyEase, Optimism, GurleyEase. And specifically, I was gonna mention GurleyDie. So when I was talking about the part where we're gonna do the script with the SDK, when we're transferring tokens, the one we decided to choose was Die. So if you want to actually run the scripts, you will need some die in your wallet in order to do that. The process for doing it, I'm just gonna quickly say is take GurleyEase, go to Uniswap, change your testnet over to Gurley, and then do the swap between GurleyEase and GurleyDie and that's how you do it. So are we doing this live? No, I'm just gonna walk through all the contracts and hopefully you will understand. If not, I can't explain it to you over and over again because the wifi is not my fault. So let's move forward. I'm gonna go ahead and open up the first part. So this is kind of small. Yeah, you're welcome. I'm unimpressed that your eyes are that bad. Anyways, okay, so like I said, the first thing you would do, assuming like let's say we're not in this UI, is a truffle unbox optimism bridge. And then if I wasn't here, I would have called it DEF CON demo and it would manifest this box, right? And so I wanna step through what's in this box that makes it optimism compatible. So the first part here is gonna be your contracts. So in a multi-chain world, you're gonna have different contracts. We should separate that logically into Ethereum contracts as well as our optimism contracts. This contract is a meaningless contract. We just have it there as an example for you to look at something. I will explain that later. Migrations is how we're gonna do our deployment. Specifically in truffle, you have the ability to number your migrations or your deployments. So which is really helpful for multi-chain deployments because then you can decide, I care about this migration in this order, et cetera, which is why they're prefixed by numbers. The next piece is scripts. So this script is actually just calling the different migration functions or doing the different deployments. I wanna speak specifically to the syntax right here, right? So the first thing that we're doing is gonna be deploying to L1. We choose the network, which I've defined in a truffle config. And by default, actually, you know what? Stop. This is really hard to explain until I've explained something else. So let's pretend that never happened and move on to this portion right here. Okay, truffle config. This is the last part for configuring a optimism depth. So we have two different configs. The first one is your vanilla config. This is what truffle will default to if you don't specify a network or a config. Essentially, all it does is define your build directories, whatever, and then your networks. I wanna note one thing. The default would just be like a build to normal contracts. But in this case, we have two different types of contracts. We will need to specify the build path. So that's build slash Ethereum contracts, as well as, hey, truffle, where do I even, what contracts do I use? Well, you pull it from slash contracts slash Ethereum. And then here is just identifying the network. And as always, specifying your private keys, that sucks, but I'm not gonna show you. But I can show you the way to circumvent it later, which is cool. That's a sneak peek. But anyway, so that is what our truffle config looks like. Let's move back into our migration script. Now that we understand that, this is the first part we're using our first truffle config. We are deploying to our L1 on the network girly. Like I said, with that one, two, three, four process, we actually have the ability to specify which deployment we care about. In this case, we clear about the first one. The second case, if you notice here, we are choosing optimistic girly as the network we're gonna deploy to. And then specifically specifying this configuration. So that way, when we run this migration, we know, hey, we're gonna pull our contracts from the optimism folder. Hey, we're gonna build everything into this build slash optimism. And again, kind of this specification of whatever. And then skip, dry run, self-explanatory, you're just skipping the extra part. These two pieces as well, I wanna do note is kind of anti-patterned, I am sorry. But this is the part where we will actually be calling the messages on each contract. So if you look in the actual deployment, you can see right here, we're getting the instance of the greeter contract on the other L1 and setting that greeting. Typically, stuff like this, where you're interacting with your contract might exist in your DAP or in a separate script. Migrations are for deployments. I just put it there to show you, hey, you can put four migrations in, right? So it still works, but don't do this. Anyways, so that's the structure of the Truffle box. Let's actually now talk about how to integrate optimism contracts into your DAP. So let's start with the contracts. This is the transfer data section, not the SDK. So optimism has already deployed this example contract onto their various test sets and main nets. So again, you can find those addresses in their GitHub. Essentially, this is super easy. All it does is this contract, which does a version exist on L1 and a version exists on L2, has the function set greeting. So if you set the greeting, say hello, and you call contract dot greet, it will say hello that you had put in there. Cool, and then this part here is just getting the appropriate cross domain messenger sender address. So each of these, what do you call it? Addresses are the cross domain, messengers, Solidity file that exists on each chain ID. I guess these kind of don't matter, because all of it's deprecated, but it doesn't matter. We only care about four 20 and five. And then this is gonna how you're gonna get the actual domain sender, so the OG contract that you care about. So that's kind of the base contract of what's already deployed. Now say we want to create contracts that interact with that. So we have this greeter, which exists on L1. Again, all it does is have this function called set greeting. So if somebody calls set greeting, what we care about is number one, the message. This is how you're gonna encode that message. So this is set greeting from that whatever message you're sending in. And then specifically, you could put a different contract address here. This is the permanent address of the greeter contract on the L2. So essentially if you call set greeting on greeter L1, it will call the set greeting function on greeter L2. Hopefully you digested that. L2 does the same thing. Again, talk to me afterwards. I have so much free time. Anyways, greeter L2 does the same thing. Set greeting again right here is gonna be calling this function on greeter L1 and telling it, hey, this is my target, blah, blah, blah. Oh, and then gas. Like I said, gas limit is irrelevant. We have up to 1.92 million gas for free. Calling set greeting on optimism. Hopefully I'm gonna say 100% does not take 1.92 million gas. So that's where we're at. Essentially to run this, we would have just done run the script. I'm not gonna run it, but you could see the output essentially looks like this where it will compile your contracts and then start the migrations. So this is the first one where we're deploying it, the L1 contract, and then deploying the L2 contract as well as then doing the fake part where you actually call the greetings. And what is interesting about this is it is calling the greeting on a deployed contract on the girly testnet as well as the optimism girly testnet. So what can we do when that happens? We can go to ether scan. Yay, and see it in action. I'm not gonna open up ether scan. I took a screenshot. That's what happens. We opened up one of the contracts on ether scan called the greeting function here. So it says greetings from Truffle. I do want to know if you do follow this tutorial, like I said, this is a public pre-deployed address. So if all of you decide to follow this tutorial afterwards and you decide to change the greeting, you might see somebody else's. I have definitely like gone to this and it's like all in Chinese and they're like, wow, one of three is global. But you can just go back and find your transaction hash in the history and then be able to read whatever you had specifically decided to set the greeting as. And just to prove to you, this is the one from L2 setting greeting on L1. That's what it looks like. It looks the same because it's basically the same contract. Where are we moving on? Okay, cool. Let's talk about the script. So this is complex, but I'm just gonna, I don't know how much time I have left. So I'm just gonna talk faster because that's my style. Okay, so here is basically a script of how we decided to use the SDK. I'm gonna point out a few important parts here, right? So the first part is pretty self-explanatory. We're just setting up all the things that we need to get our cross domain sender thing set up. So you're gonna need a signer for each L1, which is L1 signer, L2 signer, as well as here, this is specifically for if we wanted to do the SDK withdrawal and deposit functions for the ERC-20. So you're gonna have to pass in what ERC-20 addresses you care about. Like I said, we are interacting with die. So that die address for L1 address, die address for the L2 is from their list here. And so you can find it. It'll say like chain ID, five, die, and then there's the address and that is what you'll be using in the SDK if you specifically wanna do die, wanted to die. Okay, but anyways, before I dive into the functions themselves, let's actually talk about what this is gonna do in the end. Super simple. Like I said, it sets up stuff. We're gonna deposit ETH. So just calling the SDK.depositETH, SDK.withdrawETH, and then also deposit and withdraw ERC-20 and deposit whatever I said, both already. They're basically the same thing except for one caveat. So we'll dive into each of those functions and then we'll discover what's different. Cool. So after setup, I'm just gonna go from top to bottom even though logically that may not make the most sense, but that's okay. I am a bit frazzled. Report balances. Okay, this is just a helper function. All it's gonna do is log what your balances are for your ETH balance or your die balance. This is just for tracking purposes in the script so you can see that, hey, it actually transferred. Wow, good job, optimism. Okay, no one clapped. Cool. So that's kind of just helper methods. We're gonna actually dive into the deposit function. So specifically to deposit ETH, super simple. You just call deposit ETH and then put it on. One thing to note here, right, is there are these things called statuses. So the problem with bridging is it takes time to move back and forth. How do you know when it's done? So optimism will provide different types of statuses to allow you to know, hey, when it's done with relayed, that means it's been properly, I guess, committed or posted or whatever. So you need to watch out for that. And then you just report it before and after. Okay, guys, ready? What's different here? No one knows. Okay, cool, this is different here, right here. So again, like I said, we have that caveat of the L2, Optimism Standard Token Bridge needs to know what L2 address you are interacting with. And specifically in order to do this, you need to give approval to say, hey, I approve that we are using this L2 address. Because if you had given it a random address, it doesn't understand, all that token is gone. So this is a very manual step that you have to take in order to complete a ERC token transfer. And then we go into the withdrawal. This is exactly the same thing between the two. I just wanna call out specifically, we've added in a new status. So when we talk about going from L2 to L1, I had talked about that thing called challenge period, right? Cause that's when like things get real, right? It goes to mainnet. So that's kind of, I'm just logging that to say, hey, I'm in the challenge period. So if you run the script, once we get to the withdrawal part, that takes a lot longer than the part where we're just depositing because we have this part where we have to wait for people to be like, no, that's wrong. Or yeah, that's right. So yeah, that is using the SDK. Let's move on into actually building a DAP and seeing that how we can integrate the SDK into our application. Wow, I did so much live coding. Here it is. Okay. Essentially, I'll tell you two things I did. I did a lot more things than two things. First off, right? Now we have a client in. So when you're building like a full end DAP, you probably want to, not probably, you should be separating your folders into your client section and the part you care about, which is your contract session. So essentially what I had did in this process was just copy paste all the relevant smart contract or truffle code into this truffle folder. We didn't need any Ethereum contracts anymore because that was for the Greeter example. I just replaced them with optimism contracts. So this is specifically just a optimism NFT contract as well as a marketplace contract that handles all of the transfer of list by et cetera. One thing to note here is if you notice, nothing really looks any different. Optimism is EVM equivalent. So when you start writing your EVM or optimism DAPs, you can pretty much copy paste. There is a caveat though with like four op codes that are a little different. You might not run into them. I'm not going to get into it, but please be like aware. I'm not preaching like the golden standard of EVM equivalence. It's like the golden minus four op codes equivalent of EVM standards. Anyways, in this case, right? So now we actually have to deploy our contracts. I hope this will work. This is the part that I wanted to say was really cool. So I don't have to show you my environment keys. It specifically, there's this idea called truffle dashboard and it will open up this UI that basically allows you to connect to your MetaMask account. Wow, everything is so small. Hopefully you can see it. No, that didn't do any. Oh no. Okay, well anyways, dang, this is loading. Oh, okay, cool. Okay, so it's committed to my, oh man, this is going to take a long time. How much time do I have left? It's 11 30. Oh dang, I finished all of this in 30 minutes. Wow, we have 20 minutes for questions. Okay, sorry. I'm so surprised. It's not connecting. Okay, I'm just going to explain what would have happened here, right? So essentially, oh actually I never deployed it. That's why nothing has happened. Let me go backtrack. So truffle dashboard, this is usable with any project. If you notice it is open up on local host 24 012. I'm sorry, I see someone squinting in front of me. Yeah, whatever. Whereas it opens up on 24 012. So if you are using like a hard hat config, for example, the way you do it is you just specify one of your networks as dashboard and that local host and it will open up this UI. Specifically what's cool about this here, is this my terminal? Oh, it is my terminal. Nice, okay. I don't know where I am. I have truffle dashboard open somewhere. Okay, cool. So you would just do a truffle migrate and then this time we're choosing network dashboard and then the config is gonna be truffleconfig.ovm.js. And I think that's it. I do wanna know as part of this box that we have provided like NPM scripts that you can just run, but I always forget what they are. Dang, where am I? I don't know. I don't remember what I'm doing here. What is wrong here? I cannot find. Oh, did I not migrate it in? Oh, did I spell it incorrectly? Guys, did I spell it incorrectly? Truffle-config.ovm. Wait, what? Am I in the, oh, I'm not. Yay, live coding. Okay, so now if this works, I have 30 minutes for this to wait, guys. I really wanna show you this. Damn, something else happened. Please check that you're Ethereum. Oh, does my local host die? Oh, I did. I did. Oh, I did this on purpose so you guys know how to use it. Ha-ha, jokes on you. You thought I didn't know what I was doing. I do, because I work for truffle. Okay, so I think it's connected now and okay, no, what happened here? Oh, I heard someone like trying to suggest, like, hey, you just opened a new terminal. That's why it's not working. Okay, compiling your contracts, nice. Okay, mm, oh, wow, fancy. Ooh, forcing you, this is awesome. Okay, cool, and then if you notice here, actually I did wanna point out in this migrations contract, we are deploying both of them. The marketplace contract is dependent, or sorry, the NFT contract is dependent on the marketplace contract. I did that specifically because when we mint and transfer NFTs, you need to add approval for it to do that. I got lazy and said, hey, NFT, just set approval for anything that is a marketplace contract. And that is why that is there. And that is why we have a second transaction to approve. Nice, okay, very good. And then we deployed it, and oh, I forgot to mention one more thing. When we were doing this, right, if you remember the first time we did it, we specified the build path of contract, or build slash whatever, but now that we are using it inside of our client, you have to replace that build path to be used in your client directory. This was a preconfigured project, so I forgot to do that, but I remembered, and it's already done. Wow, okay, I'm not gonna make you clap again, even though I really like it. Cool, and so the client portion. This is also pretty, it's a lot of code, I'm not gonna dive into it. It is a Next.js project, just kind of the steps to do that would just be like a create next app, and then I'm using Tailwind, because I suck at CSS, so that's like in it Tailwind. I have instructions somewhere, I'm not gonna show you, I'm gonna blame it on the Wi-Fi again. But essentially what that looks like is we have a bunch of different pages, and I think because this is gonna be local, I can just actually just do this. Cool. Wow, local development is so good. If only there was something called good-nash forking that could fix this. Anyways, so this is kind of like the different views that we have, and I wanna talk specifically about the girly bridge. So I embedded it here, what does this actually look like in terms of code? So let's open up girly bridge, and actually let's also open up this guy right here. And you'll see the magic of how much code I did not write because of a truffle box. Let's say split left. So all we cared about in that bridge was transferring ETH between the two. So if we're here on the girly bridge, here's all the gross HTML stuff that I hate because I was never front-end dev, but we have two things we care about, depositing ETH and withdrawing ETH. So if we look at the deposit ETH function here and deposit ETH function here, don't they look almost the same? Yeah, wow, very cool. I copy and pasted that, except added some other things that you need because state matters and whatever, but you got a thing, right? It's exactly the same, right? The same thing with withdraw ETH here as well. Or I don't know where it is, ETH, yeah. And it looks virtually the same as well. The only piece I took out here is gonna be report balances as part of my UI. I pulled that out into just to get L1 ETH and to get L2 ETH, specifically so that we could demonstrate this information right here. I'm not, I guess we could try. Okay. Well, everyone pray for me. Why did I do this? Inspect. Okay, so if I do something like point zero one, my deposit, you can see like the console stuff that I had before was, damn it. Oh, this is something that, yeah, okay. Sorry, I forgot to configure some stuff. So let's pretend I configured everything properly and then it understands the RPC URL and everything, but I have a screenshot and that's all that matters. So Emily did everything correctly. This is what it looks like. And this specifically is the version of like moving it from, oh, that's highlighted in blue, awkward. Okay, anyways, this is the part where we're migrating over optimism, girly ETH over to girly ETH. I do wanna note one thing actually now that I remember when you're moving from L2 to L1. And you remember I said it's like more expensive because you have that double transaction, right? So in the script when we move it over, we actually add a little bit more ETH than we directly are transferring because otherwise that would be burned as part of the process and you would probably actually lose ETH. So that's one thing to notice, but anyways, this is when I did everything correctly this morning and it failed now, but that's what it looks like. And that is, I think, our full depth. How much time do I have left? Wow, good job, Emily, I have 20 minutes left so we can talk about what's next. So what's next? A crash course and what's next? Just kidding, that is not the definition of a crash course. So we're just gonna talk about it. I went through this really fast, right? And this was like the NFT marketplace utilizing the SDK scripts. I would challenge you guys to actually take this information and build something on your own, right? So maybe like a chat messenger between L1 and L2, right? Because you can transfer that data. In this case, you will be needing the truffle stuff to be deploying information back and forth. We have a vanilla optimism box that doesn't have any of these additional scripts and environment variables and everything. If you don't want that, it would just be a truffle unbox optimism. But other things is like Bridget, there's a whole bunch of bugs with Bridget. I didn't do any data validation fix those for me. Alternatively, it only does ETH right now, only on Gurly. You can configure it basically to select the network. And then always, I was talking about optimism because that's what we have. We have other L2 boxes, specifically Arbitrum exists right now. What's in the works is actually a stark net box, which is super cool. How is truffle working with a non-EVM compatible language? I don't know, we'll find out. That's in the future, but it's happening. And it's exciting. And then just in general, I want to talk about what our plans are for multi-chain. So again, like I said, multi-chain depths are hard, complex, I said a lot in 40 minutes. I don't know how I did that. But what are some kind of pieces that we thought was difficult about our demonstration that we are fixing? So first thing is declarative deployments. So if you remember in that scripting portion, it was very simple. I did an L1 and an L2, right? But imagine if now things were dependent on each other's addresses. Or now we've introduced like a new L1 or a new L2. These scripts like in production can get really intense. And that's hard to maintain. So declarative deployments is essentially you saying like, I have a JSON or a YAML file. We're still figuring out the actual structure of it yet. But you'll say like, this is kind of what I want it to look like. And then Truffle's like, wait, I'm so intelligent, I can do it for you. And that's kind of how it goes. And along those lines of what comes with development, declarative deployments is being able to declare environment-based configurations. So again, if you remember when I was talking about the network configs, it's just like a bunch of lists of like Gurley, Mainnet, Sepolia, et cetera. But what if you could actually bundle those up into your own environment? So you'll say, I care about these networks only in testing. I care about these networks only in production. Instead of doing like a Truffle Migrate and specifying every single network, you could just say Truffle Migrate Testing Environment. And that's how you would get there. So that's pretty cool. Gnash plugins, I'm actually probably the most excited about this because the Wi-Fi was bad here. It would have done everything locally, right? So the reason I had to go on Gurley and Optimism Gurley is because we were interacting with pre-deployed contracts. So if you do like Vanilla Mainnet, I mean, Ethereum development right now, we do have forking, right? Where you can basically copy the state of the chain, Mainnet, Gurley, whatever you want locally. You can unlock wallet addresses so you can pretend like you're somebody and interacting with those existing contracts on your local environment. But right now you can't do that for L2s because there are various slight differences that, I mean, you technically can, I would not recommend it because of those slight differences, right? And so imagine in a world where we have Gnash plugins and essentially you can say, hey, I wanna create this plugin to create a Optimism flavored Gnash or an Arbitrum flavored Gnash or whatever. And then because of that, you can bring up multiple instances of Gnash, your Optimism Gnash, your Mainnet Gnash, put those in a workspace that will interact with each other. All of those pre-deployed contracts were actually also copied locally because of the forking. And I could have just done this all on local host. And because it's not on local host, Gnash is compatible with our other development environments. So again, I'm here to say, we do not require you to work with other or be married to Truffle itself. We are, co-opetition is what I call it. And the last thing, I think in a caveat, there's so many times I am not an expert, but we are bringing on an expert. So if you don't know, I do this weekly live stream called Web3 Unleashed, where I basically say, hey, I'm interested in this. Who do I know or can I figure out? Will teach me about it. So we're bringing Annie, she does like partnership protocol partnerships with Optimism to come talk a bit, a little bit more about bridging security. And then specifically, if you guys don't know, Optimism had like a huge announcement about like bedrock changes. I don't know what's in it, Annie will tell you. But this is coming up on November 3rd. It will be, what do you call it, recorded. So you don't have to join live if you don't want to. But that is everything. So thank you so much for joining. Follow me on Twitter. That is a QR code to more of links that are important to me. Man, I'm so scared. I'm not ready for 13 minutes of questions. Usually I just take the full 16 minutes and then run. So if you have any questions about this, my life, okay. Yes. Yeah, you can talk a lot about calling the concert from one chain to a roll up and back way. So the question is, is it possible to call the concert from one L2 chain to another? Between L2s and L2s. Okay, I don't work for Optimism. So I don't know my guess. And I'm gonna actually, I'm gonna write this down. So I can ask Annie. My guess is probably no, because we are interacting with those pre-deployed cross-chain messengers. And that is what is doing like the communication, right? So maybe they have deployed ones on other L2s. The L2 space is really crowded and they're fighting each other. So I don't know if they would actually do that. Which is antithetical to the spirit of Ethereum. But yeah, that's my guess. Let me write this down. Oh my God, my notes are so messy. Where's my phone? I'll write it on my phone. So you guys don't see it. Oh shoot, where's my phone? Okay, I'll just remember it in my head. But yeah, cool. Do we have any other questions? Yeah. So is there a way to call like build directory for different chains? Yeah, yeah, yeah. So different build directories. So if I bring up the code again, basically for each chain, you would write your own truffle config. And then, why is this not opening? Oh yeah, it is here. Each config you would just specify which build directory. You would have different configs. And that's the problem, or that's what's painful about it, right? And that's what we're trying to fix with declarative deployments. Yeah. Yes. I should not use what? Okay. Oh, like when should we use L1 versus L2? I guess my specific thing is like, I think L2s are the future of Ethereum. The problem with L2s, like I had mentioned, is probably the UX problem, as well as the adoption problem. So when we are building like say your first DAP, right? The biggest kind of cohort of people you could take on is probably gonna be just main net, or Ethereum development, right? But if you're trying to do like plan ahead and stuff, I'm thinking L2s are important. Okay, wait, let me backtrack. Let me just talk about what I would think about when I'm choosing where to develop, right? So it's who is my audience? How big is that, right? The second piece is dev support. If I am building this, how good is that layer two at providing support? How good is their documentation, stuff like that? And then the third piece is also just like general adoption of developers, right? So if you look at that space, is there anyone who can even code with you? Is there anyone you can build with? And layer twos are new, right? And so there is gonna be some trade-offs there, but it's kind of what you want to do in the future. I know Optimism is doing really cool stuff with promoting L2 dApps. And I think in general, if you talk or, I'm not gonna say words for other people, but the general consensus, right? And the way I see the ecosystem moving is in this direction. So that's my opinion. Yeah, cool. Any other questions? Yeah. Yeah, the challenge period is a big con, right? I don't think it would change in the sense that if you want to interact with like a layer two, like a zero knowledge roll-up, right? You still care about where those contracts are coming from. So that build directory is still important. The network IDs are still gonna be different where you're deploying to. So all this different configuration is gonna change. Actually, I did mention, so we have, start net is zero knowledge. We are working on a ZK sync integration as well, which is also zero knowledge. So I think regardless of where you choose to go, this is gonna be a configuration that you still need, unfortunately. But I think hopefully if you have some missions or like what do you call it? Suggestions, whatever, like we're open source. Why don't you just contribute to our code base? Or create an issue. We have GitHub discussions as well. Jorn and I discord community, last me on Twitter. Whatever is most comfortable for you, but yeah. Yes. Yeah. Oh, sorry. Okay, you said I love, okay. Disclaimer, part of my personality is I really like fried chicken. It's on my Twitter. That's what he mentioned if you didn't hear that. So, okay, yes. Wow, we're getting professional, like personal here. Dang, okay, we have seven minutes to answer questions about Emily Lynn. Okay, why did I choose to go into DevRel versus be a core developer? That's a great question. So if you wanna talk a bit about my background. So I graduated college with a CS degree. I went immediately into backend development. I did that for like two years and then I was like, oh, this is kind of boring. What's cool and fancy? And I was like, wow, DevOps is such a sexy word. It is the worst word ever. I hate Kubernetes, but anyways. I moved into DevOps, right? And I think I was, so I'm in my 20s. I don't know why I'm getting into this tangent, but I was kind of in that space of like figuring out I'm not totally satisfied with my job. Part of the reason I moved into DevOps was one thing it was sexy at the time. But like also like I really wanted to learn something new, right? And I haven't got to the DevRel portion of it. I promise we'll eventually get there. I'm just filling seven minutes, but where was I? So I knew I wanted to do something where I was always learning something new, right? I felt like within my engineering job, there was a lot of like communication internally, like with my team and building projects. And I really liked that. But at the end of the day, I think when you are plugged into like a big tech company, for example, I felt to an extent like I was, I don't want to call it code monkey, but the impact I had was not as big as I would hoped, right? So when I was thinking about, you know, what are my next career steps? So I actually didn't get into Web three or DevRel until this year in March. So I'm relatively new. But the thing I cared about again was, you know, work environment, I wanted to be around builders. Like it was really important to me to be around people who like really passionate about their work. And like maybe unfortunately crypto is usually our 24 seven and not our nine to five, but I seek that kind of environment, you know what I mean? And the second piece was the thing I enjoyed the most about my engineering job was the cross collaborative communication when I got to kind of background wise. So my, when I joined the DevOps team, we were really focused on reaching SOC2 compliance and security. So I was working very closely with a security team. And so being able to translate technical concepts on our side to other team members was something I really enjoyed and knew I wanted to take into the next job. So when I was considering my different options, developer relations came up and I thought it was this perfect marriage of I get to keep my technical skills. I am required to learn something new all the time. So that's why I'm not an expert in anything, obviously, but I know a little bit about everything. And I think that is something I really liked. And then in terms of the impact part, just being able to interact with devs, like my job is figuring out like what people, what pain points people have, what they're working on, et cetera, and like trying to fix that, like felt more tangible to me, right? And I think that's why I kind of fell into dev rel. I'm going to say one more thing. And I always say this and she's in this room and she hates that I say this. My sister actually started in dev rel first and then also works in dev rel in web three. Yeah, wow, crazy. And she is like one of the biggest inspirations in my life. And so maybe that's part of my motivation as well. Or maybe I'm just like the bratty little sister. I think my tagline is like do everything she does, but better. So maybe that that's also why I got into dev rel. Cool, I don't know if we have any more time. We have, oh God, four more minutes. Dang it, okay. Otherwise feel free to go wait in line for other talks or come catch me wherever. Yeah, I mean, I'll be at like the conference, I'll be at near con consensus, which Truffle works for, is going to be having an event this Friday. So feel free to stop by. We have a lot of different panels and things like that. Yeah, cool. Thank you so much.