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.  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.  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.  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.  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.  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.  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 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.  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.  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.  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.  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?  It is the worst word ever.  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 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.


Hi everyone Hi, I'm Joe for jazby's case breaks calm up there is Nick. He's opening up He's opening up that break right now 2020 bowman sterling baseball six-box half case pick your team number four You can see four. I marked that on the previous break right there And here are the teams who people who picked their teams on a Saturday Thanks for spending your Saturday with us folks. We got the UFC fight on baseball is on basketball was on I mean everything is so So many things going on, but we had an incredibly busy day, so I appreciate everybody, you know really Spending some of their Saturday evening with us. Thank you. We've got some baseball on Dodgers angels Freeway series tied at 5 top of the 7th. They're in and I'm top of the 7th Dodgers have runners on second and third Chris Taylor's gonna drop one. Oh Dodgers have runners aren't second and third but two outs Chris Taylor up to bat. Nick said if the Dodgers win he'd cover my shift next week All night all next week John go go 24 hours all week put in a hundred hour week Now now the angels bullpen like You geared up for the Dodger game There he is. There's Garza right there. Thanks for grabbing the Yankees man. Good luck Coming up after this will be two boxes of finest flashback baseball. I haven't done that in a while So I'm looking forward to that. We'll be giving away the the white socks in that break And then I said if that tier one sells out, I'd be down to do it, but no one's biting on that offer I don't know. We'll see we still have the rest of this. Yeah 12 boxes random teams All right, good luck. Thank you for filling up this one Dre Jameson mmm Jameson Arthur Peru With that one and Christian Robinson for Arthur 39 out of 75. Yeah, let's knock out that tier one There's Quinn Prester to 150 Robert G with the buckos pirates. All right, you'll see it Dan Kind of redundant if we tell him right three out of 50 Chris Brian gold and Abraham Toro bowl Josh Bruce Nice rebel you got your first Super Factor tonight In one of our in a personal pretty nice Chris Brian gold And I thought that was it. That's still a hit though. Ken Smith that goes to Garza and the Yankees Bobby with junior to 199 On Instagram live That's on Instagram live only at Jasper's breaks on Instagram if you follow us on Instagram Then they'll be at the top of the Instagram page There'll be little circles that says live and you see the Jaspies the that that Jaspies logo and you don't have one There's JJ Bladet My name is Marlon's Matt. So it's 2020 Dan. Just download it on your phone. It's a small footprint We're not even asking you to use it. We're not even asking you to use it Yeah, you can just you can just use it as a Just use it as a YouTube Player Yeah, you might have to use an account.  You can just be a burner. Yeah, make a burner You don't have to use your you could just make it Kyle Lewis make it wander Frank. Oh, yeah at Kyle Lewis You can just do that you just put it you can just make it the doll Bruhan Dan That's the 25 that'll go to the raise You your burner account could be to wreak school balls To 25 That's true. Yeah, that's true. It has to be Kyle Lewis Like it has to be like a generic name Robert G with the Tigers Kyle Lewis one two three There's another to wreak school ball this time base one you got the out of 25 now you got the base That could have been a bad accident. I don't know I didn't hear any crashing There's Robert G. We there's there's a major the Pacific Coast Highway is right there major highway oh Man, we might win cases for something some day Robelle Garcia to 75 and Andy Pogus for the Dodgers Michael G with that and Galato Apparently, I think a big prospect for the Dodger. Maybe from Cuba. I want to say I'm surprised that we don't hear more accidents out front to be honest Like Yeah Dylan Carlson to 199 and Jordan Alvarez autograph who got the Astros in this one Josh Bruce nice a Little weak on the why there on the pen me should have pressed down a little bit harder Maybe the pen was drying out a little bit, but it's pretty nice There you go, Josh. I feel like you had a nice. Oh, I'm Luis Robert right here, too I get a decent night with the baseball It's Dylan Carlson Cardinals that'll go to Ryan and a will Wilson the updated Giants edition used to be angels This will go to Daniel and the Giants She has 30 message from us. What do you mean? I don't understand that. Oh Oh, oh thirsty dudes are messaging her. Is that what you're saying?  Don't do that. You're gonna get the wrong kind of mess I'm you can get the wrong kind of messages from the wrong kind of It's been a long week folks don't do Don't do fat bear looking for cubs one two three Get the wrong kind of messages folks don't do that Christian Pash to one night Bladet is a top 10 pick top I pick maybe Matt's double field of that autograph Christian Pash reveals a Michael Toglia That goes to Sean Maddock and the Rockies All right, we'll tell Abby I apologize on behalf of well, it's kind of a younger audience over there So I guess that makes sense You're on Alvarez rookie card going to Josh Christian Pash for the Braves For Ryan Gamsby and all-card ship in case you're wondering this is such nice stuff that everything ships So but I mean I'm setting these numbered ones aside just to protect them and what not but you guys get it Brock Burke for the Rangers then we got Matt Luvo speckle going to Josh and the Red Sox nice Josh She made you buy who made you buy your girlfriend Abby made you buy cat the cabbage patch dolls. Yeah, that's a thing 80s 90s nostalgia is real Candy they got to work on this here. That's 78 out of 99. I think there it is Kind of see it there. Well, I know he's the Marlins number one pick He's up there and we've got Riley green refractor wave autograph to 191 25 Wait till they bring back. I don't know. What can they bring back like my little ponies are still a thing Bronies are a thing There's Jordan Yamamoto to 75 and Sammy Siani So Jordan's gonna go to Matt's double field and for the Pirates Robert G with that one What are some what are some other 80s toys?  Didn't they bring back a Teddy Ruxpin? Remember Teddy Ruxpin? Which was like the prototype for that teddy bear in the the Kubrick Spielberg movie AI Kyle Lewis and Brett Beatty's to 75 Mets Sam Keese Sorry store You walked out of what you walked out of AI. I thought I love AI. I thought that was a great movie although There's a distinct Kubrick part of the movie that I really like and then the last like 45 minutes. There's a distinct Spielberg vibe to it, which I think kind of ruined it There's Alec Manoa for the Blue Jays that'll be for Sean Maddock. I really like the the teddy bear in that movie though Maybe that maybe maybe that Jazz Chisholm to 99 and Glenn Allen Hill Jr another autograph for Arthur and the Diamondbacks nice Son of Glenn Allen Hill for those who remember him Where did his dad play diastros? I feel like remember Glenn Allen Hill with the astros for a little bit Jazz Chisholm 47 out of 99 speckle for Matt Sebelfield Brennan Malone autograph another Diamondback for Arthur. That's right. Stephen K. He was pretty yeah, that those are gonna be toys someday sentient dolls Like pre-programmed artificial intelligence. Oh, look at this Nice out of 199 refractor Jason Dominguez 56 out of 199 now No ink, but I'm sure that'll still sell pretty decently you would imagine right Garza I would hope so and Shea Lang Lears That is for Ryan Gamsby and the Bravo's All right, here's the next box and here's the last box Careful here. I like the stackery to him in here Nick It's good. I dig that another Tariq Scoobal So Robert Garicki you're starting your Tariq Scoobal Personal collection whether you intended to or not If you intended to then you're in good shape another Kyle Lewis and another will Wilson for the Giants Daniel Ruiz you are gonna see some repeats here and there folks if you study the checklist You can see that it's very very small checklist very short checklist Which is actually probably good news for if you're hunting for parallels Andy Pagas for the Dodgers Michael Galata with that Dodgers still tied at fives going into the we're in the top of the eighth Dodgers have won out Hopefully the angels bullpen will fall apart There's Jackson Rutledge Although I do have Hansel Robles on my fantasy team for the angels decisions That's for the Nats Daniel Ruiz great Gansby. What's going on? Yeah, Mookie Betts is pretty good. I'm very very happy the Dodgers locked him up There's Trent Grisham to 199. He's been hitting the ball. Well, there's Daniel Espino Refractor wave to 125 that will be for Kevin and the Indians Trent Grisham refractor will go to Rhea and the Padres and the final box. Good luck We got Nick Solak for the Rangers to 199. That'll be for Mark and Jacob Amaya for the Dodgers Also dust off your Kiebert Ruiz cards ladies and gentlemen Dodgers fans and anyone who has Kiebert Ruiz I hear that he might he may be called up soon. I think Will Smith might be on the IL Forgot what happened to him something tweaked something. So I often barns have been getting a lot of starts And then I think Kiebert Ruiz may be maybe added to the roster as the backup catcher Dustin May speaking of the Dodgers with a nice break to Michael Dustin May to 150. Drop drop drop drop drop drop. Yes, nice Dustin May. Oh Gamsie says he's gonna start tomorrow.  We've got Mauricio Dubon 64 out of 75 for my rivals the Giants That's gonna be for Daniel Ruiz Hansel Robles out, huh? He's not happy. He's just like oh, he's like I Joe I can get him. Let me let me face the best Me same Another Jason Dominguez right here nice and the Jazz Chisholm to five Matthew Stubblefield with the Miami Marlins gets the Jazz Chisholm one out of five and out of five and under get the old train whistle All aboard the Big Hit Express Yeah, I thought it was at the dime back there you go. That's how that's that's how it happened And we got a Brennan Davis autograph nice for the cubbies Mark Passett And Garza with the Jason Dominguez Will there be ink back there? Maybe one more auto Focus yeah, there we go Remember all card ship. All right last autograph right no more but yeah last auto It's gonna be Luis Patino Padres Ria Mitchell on the board There you go You all thank you very much for getting in Sean Murphy and rookie Justin Dunn at the end That was pick your team for 2020 Bowman certainly baseball. I think that's it for now We're gonna just we'll try to get some more. It's pretty hard to get but we'll do our best Might be a different price point might be a higher price point But keep your eyes on Jasper's case breaks calm and I'll see you next time for the next break. Bye. Bye


So, could you give a warm welcome of applause to Stephen Grunke, who will be talking to you in one minute. So, hi everybody. My name is Stephen Grunke. I'm a software developer since about 15 years, working in sole projects and larger teams and smaller teams. So, mostly my development stack was JavaScript, and you will find some of the tools that I mentioned coming from this world, but I'm very sure you can also find something for your project that applies here. Here's my email address, my PGP key, and my favorite social network account. Yeah, so a little spoiler what will happen today. I will talk about development process exploitation. So that means if you are developing your software and somebody joins your team and sends you code for a review, it could happen that it executes code in your machine without your knowledge. There are a few things that are really hard to catch, or I find hard to catch and I want to share. Maybe you have the same problems and you find that the same mitigation supply for your project as well. Yeah, I will then continue, and let's start with the software development process. That's a small cycle. So, first of all, it starts with an operating system. You need to have a computer to write the software, and that's something you need to trust first off. If you... Yes, so your operating system contains keys and credentials. It contains the source code you want to develop and your tools that you have in place. And the major risk is that the tools are vulnerable to some exploitation or that your host is already compromised and you write the software committed to your coworkers, and it isn't what you intended to write. That's a larger problem here. After you start writing code, the editor is kind of the interface that I have to write the files and edit the code. I find it kind of complex to use an editor. On the left you can see that many of the editors come with a package manager included, which is a good sign for the complexity that these tools have. I don't know what tools you need, but they support you in development, so it's very good to, for example, have code linters and auto-completion in place to write better code. At the same time, it can be a problem because they can execute code unattendedly. We will see in a moment. The mitigation I came up with for the editor part is that you have a virtualized environment where you run your editor, so when something happens and it is compromised, not your root system is also compromised as well. You want to monitor all your config files that you have in the project and you want to get awareness of what exactly happens on my system when I run the due this code. Yeah. The next part you will probably use as a shell integration, so as soon as you open your repository, some of the shells I saw just tell you what branch you're working in, what files were changed, and so on. But it's something that comes very neat if you're developing, but it can be a risk as well. Yeah. So my opinion on the shell integrations is mostly that it's made for software development on your own system, so when you write the code and you can trust it, it's not a problem to use these tools at all, but as soon as you get sources from foreign developers, it can be a problem. So choose your tools wisely and don't execute code from others if possible. The versioning system that you commit your code to is also a very good choice. For example, Git can execute hooks on different occasions. For example, when you check out new code, if you commit and so on, that means if you manage to clone a repository and a Git folder is included or an HG folder is included, it could mean that your operating system decides to execute whatever is in the hooks. It's not possible to store a .git folder within the Git repository, but it's possible to store it in a mercurial repository or in the SVN or something, and then your shell integration won't know what the original source was and will execute it anyway. The second thing that was introduced, for example, from Visual Studio Code this October is that they now support Git hooks, which is a great feature, right? The mitigations against this are pretty easy. You can either set a different hooks path, which is not within this project repository so that you don't execute Git hooks at all, or you can use that little wrapper here that you see to, for example, check at least that there is no file that is a Git hook within that folder or you execute Git. It's a very good choice if you want to protect yourself from that vulnerability. So after you committed the code and shared it to the versioning server, you probably are going to build it automatically. So some services like Travis CI will run it for you, so they will run tests, they will compile the software, and also they do the package versioning and deployment to some other places. It becomes a problem if you can't reproduce the results from your build runner because it's a system you don't control sometimes, and as soon as you get the binary result from it, if you compile the software that compiles the binary, you need to check that result somehow because somebody could have authored it without your knowledge and then you will ship it to your users. Also a problem on many of these build workers is you want to have this process very fast, so that means you don't want to wait until all the dependencies are installed and the great service is that you have caching in between these projects. This means that, for example, if somebody managed to inject the version to the cache of some CI system, then it will eventually show up in other projects as well and you can pivot across the projects. Usually if you have a build environment, it has access to some kind of development key. Mostly if you get pull requests from external, the keys are stored encrypted and you don't have access to them, but as soon as somebody has right access to your repository, also the keys could be leaked. Let's make an example. You have somebody offering your software and you don't give permission to edit the master branch of the repository, but as soon as you open a branch anywhere and make a pull request, Travis CI or other build runners will use that and decrypt the passwords for you and give you access to the credentials, which you can then print or do whatever you intend to. For me, the best option here would be to have reproducible builds because then you can use different of the build workers and compare the results somehow so that you see if one gets compromised, the other two will tell you, hey, that's a different result, have a look please. That would be great. Also, the build steps, I mentioned building, testing, and packaging the software are totally different steps, so what you can do is you can have one compartment per step so that you can have it at a final level and see what happens here. After you compile the software, you build the software, you need to ship it to the user somehow. So either you store it in your own server or most often you use a CDN, you just put it there and it's the asset that's lying around. Your users will come around, download it from here and execute it. So what is the problem here? The problem is that if you have a URL, it's very hard to prove that it's actually from the real maintainer. If you call your account like a different project, then people won't be able to notice the difference somehow. What you can do to mitigate this is to publish the URLs that you're literally using and also sign your assets so that users can check is that something that the developer intended to give me or is it something that is really not intended? And the next part is you need to reach out to your users so you make people aware that there is a project they can check out, they can clone and usually you have the package registries. A few slides back you saw that the package managers are also included in the editors. So that's also something where you can ship the software but the package manager I was mostly looking at was, for example, NPM. There was an interesting occasion where somebody had a project called Kick. The company Kick then tried to take it down and the person just ignored it for the moment but then Kick reached out to NPM directly and they deleted the repository. In consequence, the developer removed all his projects from the versioning server and a few hours later they were showed up with the same project names. So that means if you have a software that uses that dependencies and somebody freed up the names, it would affect your repository as well and compromise it. That's something that needs mitigation. I think the best idea here is to not only identify the project by a unique identifier but also have a GUID or a unique identifier per project that does not change so that you can make a difference. That's something that's up to the package registries to implement. That's not something we can do as a user but it's a very common case that this package is fluctuate. For example, if somebody deletes it, you don't have a backup of that. A very good idea is also to store offline backups of every package that you check out and that you install to your software because it's very bad if you want to maintain your software and you figure out there's something missing in your country cover because it's deleted. Software developers have some needs during their work. I want my tooling to perform. If my code editor, for example, is in the VM and the VM is slow, that's something that's annoying all over the process. On the other hand, the velocity is something that your manager will require from you if you write commercial software or you try to get something done and you can't spend all day to work on chores and improve your repository, the versioning and so on. That's something you need to deal with. Another big factor for me is the reliability. As soon as your software goes down and you are on holiday or something, anybody else from the company or from your team should be able to recover what was there before, also known as the bus factor. If you have convenience, like for example, Ruby on Rails gives you a very good, very easy start in the project and that's something you don't want to break by making it too complicated with the development environment. Also something I found to be more annoying than helpful is if you want to pair program and you have a very compartmental environment, it's very hard to share the resources that you need to talk about with other developers, expecting you're not in the same room but working remotely, what is for me most often the case. Yes. Yeah. A large problem that I saw is if you underhand somebody code, if you go ahead and check out code from any online resources, it's sometimes very hard to tell if the code that you see in your, for example, GitHub is what you really would expect to see. I have some examples here which can show how this could work and how this could look like if somebody tries to inject code to your repository that you don't see. First of all, let's start with something easy that's phishing. What you see here on the slide on the left side, maybe you see the cursor, that's not the full path that is just the domain name. The slashes in here are UTF-8 characters so that thing here resolves to a host name and if you control this host, you can get a certificate for it and then the example below, you see how it would look like if you install it. First, I have a host that's just running a web server on port 80 so that you can see the result. Okay, I was cheating a little bit. I was putting the domain in the ETC host so that I don't have to buy it for just showing it. It's strange that .zip is a domain, actually. But then if you install it, you would see that, yeah, you can send somebody a very nice-looking link which looks like a totally different project but it's pointing to your server instead. And I found many of the package managers having the nice feature of executing postscript hooks so that means if you have installed it, it will run some commands afterwards for you. Yeah. So then there is invisible code. If you go online somewhere, find in the forum or in a blog, you find an article and see, that code is actually solving my problem. You go ahead and copy-paste it. So on the left, you see the source code, how this would look like in HTML for the blog. On the right, that's the result. So you can go ahead, you can copy-paste from it and if you paste it to a text area, you will see that the result is something that you didn't expect. For example, if you copy a large chunk of code, you won't go ahead and review it on your local system again and that could be the compromise for your project. So another example, here, is you can use ASCII characters, the control characters to influence the output in your terminal. So if your terminal also supports the legacy of ASCII control characters, you can use that to just revert the line and override it with something you wouldn't expect. What you see on top here, that harmless script is the file. It's a little larger than you would expect for just the eco-foo, but not something you would notice when you just see it. Looking at it from a hex editor, you can see that there is something more going on than just the foo. And if you actually execute it, it will not print something, it will create a pwned text, which is a good example for you that your host was compromised in this moment. Another example I found online, so credit to area for this. So there is a byte sequence you can use so that this even works in a good diff. So when you're working exclusively in your terminal and you're not doing reviews on GitHub or some graphical tool, it could be the case that you don't notice what was going on. What you can see here on the left is I created an empty repository. I added a small script and in the next step down here, I added some improvement to the script, which is actually the malicious commit that's here in red. Afterwards, I just run a git diff on the code and I see that there is only no backdoor. Oh, sorry, that should be okay in the updated slides. So you don't see the evil.sh that it's executed as well if you run it. That's something I consider very dangerous. Yeah. So, some mitigations. The best thing you can do is to make it expensive for your attackers to compromise or try to. So as soon as you have the chance to notice what is going on, also retrospectively, you can at least burn the capabilities and tell others how your project was attempted to compromise. And that's something that is, in my opinion, the best mitigation against this complexity. What you can also do is you can test your software from external services directly, which will tell you if some compromise happened. For example, Git has newly introduced, they will check your packages, the dependencies, and will warn you about some dependencies that are commonly known. The best thing you can do on your local system is to build small compartments so that if some compromise happens, it doesn't affect your full host. Also, not all your projects that you have access to. And it's very important that you have backups on a different system than the host you're working on. So if the compromise happens, you still have access to the original data and can compare it and do some forensics on this. Yeah, so the intrusion detection in forensics, there are some great tools available. For example, my favorites are Detrace and OpenSnoop. You can monitor changes and access on the file system or on your system at all. And you can, for example, set some routes for your projects that are specifically matching. So I'm not going to share some routes that match for all projects. But you will figure out what is, for example, important. Very good starters, for example, to OpenSnoop for ETC Passweedy. If there was some access, then you can, for example, say that it's not something what my software would do. And again, it's very important to have the backups of this because in the moment where you execute it, you can't trust your host at all. The idea how to achieve this is if you have a VM per project, for example, you let it run for half a year, you don't approve the situation. Instead of having one system that you need to update the software to, you need to update afterwards all the projects that you're working on frequently and that's something that's easy to forget, so it's dangerous. If you assume that every time you run some command or every time you work in a project, you spin up a new server entirely from scratch, install the dependencies and so on, that's something that's not a risk for you. Also, if you have, for example, a virtualized server environment, you can have memory dumps at any time. You can monitor the network and you can also diff the file system. For example, you stop the server and just compare it to previous version and see, hey, here's something that was changed that I didn't plan. It's great to know. Yeah. Very important is also to separate your accounts. For example, if you see large GitHub accounts, people are making contributions every day since the years. So it shows that the people have access to many projects from the same machine. So, and the permission model from GitHub, for example, allows you to store an SSH key for write access, but it automatically has access to all the repositories you control. So the best idea you can have here is to make a project, to make a new GitHub account for, or to make a new account on that versioning system that only has exclusively write access to that single repository. So when you work in your compartmented system and you want to upload or pull changes, you don't, you can't influence other repositories. That means compromise doesn't spread across all your projects and so on, which would be an invitation for malware somehow, or ransomware. And you get a better permission model if you create a GitHub organization. In this case, you can also limit your own access in a better way. So my recommendation is not to work in your personal GitHub account, but create an organization for your project. So something many projects are missing are defined responsible persons for security and to clearly communicate what is the plan for incident response. A small example, if you have a new project and you find a vulnerability you would like to commit it, but you don't open an issue publicly because then every user would be affected. You try to reach out to some developers and if you don't have any clue how to securely achieve this that can get you into trouble. And there are quite a few projects which don't communicate this and some of them don't even respond to their security at email address which is bad. Okay. And in this case, I told you what I saw from my experiences working on the projects. So that's basically my summary of what can be harmful and what can be good for your project. Thank you. And we now have time for Q&A. In the room you can line up behind the microphones and I can see we have a question from the internet already. What about Git signed comments? Any thoughts on that? So as soon as you have signed comments and I find that you also email with the same PGP key, it's very interesting that you have the PGP key on the same host probably then you have to get executable. So if somebody executes Git hooks they can steal your PGP keys from this. I didn't find any tutorial online which explains you how to make it manually so that you don't use the Git for signing the commits but I think it can be very good to sign the commits but it can be also dangerous because your email communication can be compromised. Microphone number 4? In the Git diff you showed us there were some control characters. I think Git diff pipes to less by default so shouldn't they appear there somewhere? No they don't. I just checked with the latest version today so that's something that we can also click on the block and see if there is the video available. Yeah it's very hard to show from my HTML slide how this works so this video animation maybe you can touch it a bit. That's how it would work. So most often yes if you pipe to less or you use a hex editor to review then you would notice yes. I somehow remember that maybe it only shows for longer diffs but I think when I type Git diff I can scroll around. That's interesting okay? I need to try. Microphone number 1? You mentioned Travis having access to hidden variables and you being able to leak those variables during pull requests what are your suggestions to mitigate that? Don't give people right access to your repository not even to branches that you don't trust so as soon as they have right access they would also know the secrets behind the variables in this case. I like the security model because if you for example get contributions from outside nobody can trigger that and steal your keys. But as soon as you build it on your own branch somewhere in the repository that changes. Yes but if you submit a pull request you don't necessarily have to have right access to that repository. Yes that's what I mean. If you come from outside and it's not within the same repository the secrets are not decrypted so you can't run the steps for example you would not like to deploy directly from a foreign branch somewhere. We have a question from microphone number 4. You mentioned the problem with different compartments and how to exchange those environments with other people. I think that problem has already been solved with Vagrant and some kind of provisioning software like Ansible. Do you have any experience with checking those results of Vagrant boxes that are automatically provisioned like having some service back software to check those environments afterwards so having some kind of hashing and how to find out if they have been reproduced the same way and or if they have been any exploit used to in that process of setting up the Vagrant environment. Yes so different levels you can look at this there was let me try to find it. You can for example memory dump at any time if you have the host trying somewhere or was your question exactly that you want to check if your environment that was spawned up was not compromised yet? Yes there has to be some kind of process how to verify that the produced environments are the ones you expect them to be or if they have been compromised and the problem is I have used those environments and I first tried for this encryption for the Vagrant boxes but the problem is it's always the same the same key for the encryption so that doesn't work and even as you mentioned you can have a memory dump so you can read out that key so there is no real possibility to set up a Vagrant box that can be tempered with afterwards so there has to be some kind of hash sum to compare those produced results. As soon as you have a reproducible build for example script languages are much easier to achieve because then you can just div the file system directory and see if there was some change. What I would do in this case is to run multiple services and compare the results if that's possible for example you have those reproducible builds then run it on a few servers which are independent and compare what you have. We have two more questions for microphone number one and only a few minutes left microphone number one. So what's your recommendation for handling credentials in application configuration files? We need often some database user and password or something like this in say Spring Boot application, YML or things like that and is there any best practice or any framework which can handle such things or we need to explicitly encrypt these credentials in this application and then decrypt for itself an application but then you need the semantic keys or Yeah so Ansible for example comes with a mechanism that's called AnsibleVault which encrypts that with the passphrase that you can enter a new command line as soon as you touch the file for example if you want to run Ansible then it will ask for password when starting up so if you want to share that password with your developers everybody has access to the same keys I would prefer to give everybody so every person in this team or even every device a different key if that's possible somehow that's what I was trying to mention with the GitHub accounts that you don't use one GitHub account but you use many of them if you, yeah We have one more question for microphone number one and then a question from the internet Yeah my question was more about I mean some of your recommendations are low-hanging fruits but some of them it's like it's just impossible I mean it's not sustainable like it's very hard to maintain and so I'm wondering if you use all of them every day or just part of them or do you just leave like an open VSE developer at the end? It depends on the project so what I try to do on my development system is to have this compartment so that one compromised project would not affect others because I'm not the only person checking and merging the code so and that's something that gets quickly too much for one person to review so I can't review all the code that I'm running currently on my computer that's true but I can try to mitigate what the impact of this will be And the question from the internet What tool would you recommend for dipping a file system? Diff Worked for me so far or what exactly is the question about maybe you want to see if there did the hash change in the file so when you have for example the script file 1 and the script file B and they have a different hash sum that's something I would consider something I would look up manually so as soon as I have an indication that there was something wrong I would look it up manually and use any tool that I have Haxidit or whatever's available We have less than one minute left Any final remarks? Thank you


So this week guys is within the tower within the hangar area this week also he's selling new loot in terms of legendaries what exotics this week we have the tractor cannon we have the knucklehead raider for the hunter for the titan we have to do pang boardrons and for the warlock we have the permevians they're not too bad if i'm honest with you legendary weapons we can see selling for legendary shards but there we have it guys as there's a loot for the 27th of august if you enjoyed the video leaving a like really helps out and hopefully guys i'll see you on that next one