Fuel 🛠 Bringing Superior Devex to Web3 Building Dapps on Fuel - Cami Ramos

foreign [Applause] [Music] cool hey everybody thanks for being here uh today we're going to talk about bringing a superior developer experience to web3 and how we're doing that at fuel labs and we're going to cover a lot in the next 30 minutes so we're going to go over kind of an overview of sway the programming language the VM and kind of what makes fuel such a good option for building uh daps and then we're going to talk about specifically like going through a workshop so if you have your laptops you'll be able to go through it either in real time or you can go through it during the hackathon so real quick uh just a quick about me like I said my name is Camila I had a kind of a more traditional path to engineering I studied computer science in college then I started my career at PayPal where I was an engineer before moving on to developer relations almost two years after that I did devrel for web 2 for maybe like a year before pivoting over to crypto I've been working in crypto full-time since April of this year and now I'm the head of developer relations at fuel labs so before we start let's just kind of kind of get like a ground zero where we're all under the same understanding so when we talk about a tech stack I find it easiest sometimes to try to map the web to Tech stack to the web 3 Tech stack and kind of draw those relationships so we're both clear on what it is that we're talking about when I say certain things so when you're building in web 2 these kind of five pieces basically are The Primitives that let you build pretty much anything right you have apis authentication database client-side Frameworks and file storage so now if you take that similar idea and kind of try to map it over to web3 it's not a one-to-one right because there's a different Paradigm to building but you can kind of map a similar map of all of the different pieces so this is back from when I was at edino the team there did research this was a year ago actually almost exactly where we published This research and as you know like step in web 3 moves super fast so a year ago things were way less mature and way more nascent than they are now so there was a much bigger need to Define what a working Tech stack could look like at the time and this is what they came up with so you see you have your layer ones you have your layer twos you have your development environments file storage indexing and querying oracles identity wallet and client okay so fuel Labs uh that's the orientation that I work at we're building Fuel and I kind of like to nickname it a layer two but better but the official term that we use is a modular execution layer so what that means is that you know instead of it being just a layer two and maybe the sense of like it being a roll-up or a side chain or whatever kind of different types of layer twos there are it's a execution layer that can be plugged in it's the engine that can be plugged into any different L1 or to any different configuration where you can have fuel as a sidechain you can have fuel as a roll-up you can have fuel we don't recommend it but you could have fuel running as a monolithic L1 you could have all of these different configurations and that's kind of the whole modular idea is that you as a protocol developer can Define what you want your chain to look like and you can say I want to use fuel for execution or I want to use fuel for execution but I want to use it as like a side chain or something like that and the three pillars that we're going to talk about our performance leads so small there we go performance flexibility and waste reduction and developer experience and the two that we're going to focus on today are performance and developer experience just because we don't have a bunch of time so for those who might be like oh what's a modular execution layer what does that mean exactly so really what it means is that blockchains have these four functions and we have a bunch of reading uh on our website if you want to kind of learn more about this but basically blockchains have four functions and when you have a mono monolithic chain the node is stressed trying to do all four things right so you you have this like limited set of computation power and then you have to divide that by all these different functions and the thesis of modular is that if we can separate these out we can have higher performance on each layer individually so when you combine them you have higher performance in general so what fuel does is it offloads just execution so the chain only handles execution it doesn't worry about uh if something is correct it doesn't worry about settlement it doesn't worry about consensus it just executes all these State changes so it'll execute all your transactions and then post them back to the L1 and then the L1 is in charge of saying you know what order are we going to put these in blah blah so again the fuel VM is designed to be modular and it can plug in as an execution engine for any blockchain it's kind of like the thing to note all right so when we talk about fuel building the fastest module execution layer how exactly are we doing that what what are we building that makes it such so the three things that we're going to focus on are parallel transaction execution the sway language and the fuel VM so I made this meme laugh um because right the vibe is how do we stay in the ethereum ecosystem right because we all for one reason or another are like either value aligned technology aligned whatever aligned with ethereum but how do we take what we know and love about ethereum and improve it so the thesis of fuel is like how can we bring a more safe smart contract language how can we bring a more performant VM while staying in the ethereum ecosystem so let's talk about what we mean by parallel transaction execution and how that kind of what that actually means so the evm which is a virtual machine for ethereum versus the field VM which is the fuel fuels ritual machine so the evm is single threaded and because of that it can only process transactions sequentially so what that means is it can only process one transaction at a time once that one is finished and it turns on the next one Etc so because fuel is utxo base which we don't have to get into the weeds of what that means but basically it's a different model ethereum uses an account model the field VM uses utxo model again we have a lot of reading on our page where you can kind of dive into this more but it uses all of your machines cores and threads and because we're utxo model we have access to these things called State access lists where what that means is it looks at the transactions and it says which ones have dependencies like first you have to execute this one and then this one let's say right out of 10 transactions there's like these three dependencies let's say so what the VM is able to say is okay let's execute all of the other ones that don't have any dependencies in parallel and then the ones I do have dependencies you know sequentially so just based off that you're able to get much higher throughput just off this one Improvement right where instead of having to do everything one at a time you now are able to process things um in parallel so if we look at this graph if you see the the orange like triangles at the top you'll see that the number of transistors on CPUs has been increasing exponentially over the years also known as Moore's Law the single threaded performance over the last years which is the blue right under that hasn't you can see like it was increasing but it's not increasing exponentially but what has increased exponentially over the years has been the number of cores so if you have a system that's sequential that can only leverage a single core it's like you're running it on a 10 year old laptop you want to leverage the things that are increasing exponentially year over year and the fuel VM is designed to do that it's designed to be able to run transactions in parallel and this leads like I said to a vast increase in throughput if all other things are equal so not considering any of the other improvements just because of this you're you're able to actually access all the cores and all the threads of your machine which like I said according to this graph is what's been growing is what's been improving so and it's not because you bought a better computer right or a more performant like machine it's just because you're using all of the resources that in your computer are wasted in the evm um the other thing when we talk about developer experience is that the fuel VM uses a graphql endpoint instead of a Json RPC if you've like deployed a contract you know you got to go find like the RPC endpoint and you just like paste that in and that's how you deploy so with fuel we have a graphql endpoint and what that means is that you have a graphql API built in so you might have heard of the graph right the graph exists because these other networks don't have that so you need an external service or you know someone else to build this layer on top of it and with the fuel VM so this you guys can't see this oh you can see here um with the fuel van this link right here is actually the endpoint to where you deploy your contract so if you were to click on this did it open so um if you click on this endpoint it'll take you to a graphql playground where you can actually start making requests right away and you don't need an external service you don't have to write new mappings you don't have to like write the whole API that you have to do to use the graph you know okay so now I'm moving on sorry about that uh so now moving on to the portion of developer experience and we're going to talk about Sway and Fork sway is the rest space language and Fork is the tool chain kind of manager so we're gonna just kind of like fire through because we only now have uh a few minutes left we have 20 minutes left actually so it's fine so we're gonna kind of speed through some major points we're not going to get into too much detail but all of these have QR codes so you can you know scan them and go into the actual specs or into the docs and read more about what I'm saying so our standard library is actually written in Sway and the reason why that's notable is because a lot of other uh languages for blockchains are actually not written in that language so for example like move the standard library for move isn't written in move uh so that's like something that's really interesting about our project is that the standard library is actually written in sway um so the standard Library can move fast and this is because you don't have to wait for the compiler devs to add features so for example if you're like oh I have an idea for a library I want a library I don't know for like super scientific Edition with like 27 decimals let's say you can just write that library and then it'll just work so you don't have to wait for the official compiler team to like build that in and add support for it you can just write that Library yourself so because the language is lean it's able to move much more quickly as a side note we have a grants program and here at the hackathon we have a booth over at the like kind of in that little corner before you go into the main stage so if there's something that you build here and you're like ah we kind of want to extend this or we we just had a great experience and we want to build something else the grants program just opened up maybe a month ago so um it's like super open for projects there's about I want to say like 15 to 20 projects building right now on fuel through the grants program which is really fun and because it's such an early developer ecosystem well at least for me what I think is cool did it work oh good yeah um it's like you can have like a pretty heavy hand in like influencing and building the developer ecosystem because it's so early so imagine being like one of the first 30 projects on ethereum that's kind of the vibe right now where it's like we're still super early in standing up the ecosystem so if you have an idea you can be like the first X so right now we have the first team building in Oracle on fuel which like you know by a later stage project like they've already done that so any idea that you have it's very likely that you're kind of the first person that's building this out in the fuel ecosystem so just to know and we support through grants and we're building out this accelerator program to connect teams with VC funding if that's something that they want to pursue to connect them with like legal and marketing if they want to like pursue kind of turning this into a real company or if you're just like I just want to build some cool [ __ ] and get a grant to support it that's also like a option that we have okay so the other thing about having a standard Library so like solidity for example doesn't have a standard Library so you know if you've ever tried to like do an erc20 or erc721 what people typically do is they go look at like a bunch of big like uniswap or you know the big kind of orgs and see how they've done it and then they try to deduce and kind of like piece together what the best way to do it is so with sway you have this like single source of Truth for certain things instead of having to compare the the code at like seven different orgs wrote to have like a custom erc720 implementation or something like that the other thing that we have that's really cool and kind of the overarching uh thesis or idea around this is like everyone who's written in Rust loves rust like you you've never met someone who writes and rests and they're like I'm going back to like whatever everyone's like [ __ ] rust like I love it and there's a reason why right you have this like built-in type safety you have this compiler time uh stuff where like yells at you at compile time it won't even let you deploy something that has these issues so you kind of harness that in an adversarial environment like blockchain where you're dealing with real money you're dealing with real assets you want to be in a language in an environment where something is saying hey on line 36 like you have XYZ we're not even gonna let you build this contract much less deploy it until you address it so these are the next few things I'm going to talk about is kind of how we do that so the first thing are these things called generics in some types so generics if you've ever written like in C plus C plus plus or something like that you know that you can kind of like Define a function but not Define the type right away you can just say like for any type and then later on you can actually use like int or like string or whatever it is so let's just say for example Edition you can write a function called add and then use a generic type because you're saying I might want to reuse this Logic for both ins and floats so instead of rewriting the function twice you can just use this generic type so that you can basically reuse logic without having to rewrite code and then the second portion of this is some types which is kind of like unions where it's like one or the other so let's say you have this enum called result right and you could have in a result you could either have like a successful or a not successful those are that would be a sum type so when you put those things those two things together it allows you to I wish you could be um okay so if you can imagine these two things together where like you can Define the types later and you have these subtypes where it's one or the other what happens is that you don't have to in solidity you would have to rewrite this for every single type you wanted to to use it on that's the first thing and then if you wanted to have similar logic where you're like one or the other you wouldn't be able to do it in the same way and I have an example up here so maybe when it's working we can come back to it and you guys can see okay the other thing is explicit error handling so if you guys know in solidity the EC recover function do you guys know that one okay do you guys know what will what it will return if a signature is invalid it returns a zero just returns zero it returns zero address so what you have to do as a developer when this happens is that you have to go in and you have to check for the zero like you have to remember say you have to say like if zero like whatever do do this to handle the error and what does that mean right like you could forget you could not know or you could just like straight up I don't know just not handle that case just not even out of not remembering you could just not do it um so what that means is that you might have this like variant path where you're not actually handling an error case that could be very problematic and in sway we have explicit error handling so you can't see it again but like with the results that I was talking about in the last slide we're talking about successful or like non-successful you can actually wrap the return of things so instead of uh if you just try to like run this code and it returns nothing and you don't handle the error sway will tell you that you're not handling the error first at compile time it won't let you build your contract it'll say you haven't done it and then two it forces you to call this method dot unwrap on it to actually see what the error is to actually like access you know to access one level in so in solidity you have to manually remember in sway it's done at the language level at the compiler level it won't let you build it won't let you deploy unless you actually handle all the errors explicitly so again like what does this lead to say for code better applications for end users the other one is type inference oh did it work a glitched over here no okay type inference with the same type system as rust so basically it can infer the type so even though you're writing in Rust which is like a language where you're thinking of types all the time you can just say let's for example let answer equals 42 and the type will be inferred so you don't have to say like you know let like int or float or whatever it'll just infer what's on the other side of the equal sign the thing that I think is really cool is this concept of namespace storage access so you know for example in solidity you might have like a storage variable let's say called count and then you might have a local variable called like CNT or account underscore or something like that like a nomenclature where it's similar because you they are related in some way in your code and that's why you name them like that but they do different things one access to storage and one doesn't and sway not only do you have to define the type of storage access that a function has in the actual function definition itself so you say read or write or both or just write or just read and so that's the first thing you have to Define when you define the function and then two when you're actually wanting to access storage the way that it's done is storage Dot and then the name of the variable and so what does that mean two things is one when you're writing for you as a developer who's writing and any developer that's perhaps using a library that you wrote It's explicitly clear what type of access to storage these functions have but number two is you'll never kind of have this error of like you accidentally access storage or you access storage in a way that has unintended effects because you didn't necessarily know you were accessing storage we're just like trying to reference a variable that you might not have known was actually in storage so with sway it's super explicit where if you want to access storage you have to use the storage keyword and if for example you didn't Define that type of access on that function and it won't even let the developer do that it'll just at compile time it'll just not work it worked very great yay I think you guys can see this big now okay um this is what I was talking about for generics and Sun types so if you see this uh result when I'm talking about explicit error handling so this is the result I'm talking about when I'm talking about uh explicit error handling you can do this unwrap method on result to actually access what was it was it okay or was it error so that's what I was referencing earlier and then this is the explicit error handling that's kind of what I mean when I say it forces you to call this method unwrapped to actually see the error okay we're going to speed through this oh so this is what I meant when I say access uh so here you're actually saying this function increment has both read and write axis while this storage only has read access to storage okay exhaustive pattern matching so a match statement to exhaustively enumerate all possible cases and the compiler will tell you if you miss a case so basically instead of having to like again manually remember to do a bunch of if else's like if it's true if it's no it's not true if it's seven if it's ten if it's 24 if it's like 100 you have to manually remember to like write all these if else branches but with sway you have exhaustive pattern matching which is this match statement which you can look in our docs but basically it'll tell you that if you miss a possible path so again how do you write more safe applications how do you make it safer for your users to be using it and not be kind of at the will or the whim of like a developer making sure that they cross all their T's and dotted all their eyes you use something like sway okay re-entrancy this is the most exciting feature that we have coming up so you guys all know what re-entrancy is okay uh so I won't use this um so here's this list that I found or actually John found which is like this list that's maintained of all the re-entrancy attacks today and you can see the last one was September 30th and that's only because I screenshotted this around that time there might have been another one since then um but with sway at the compiler level it'll call out if you have a potential re-entrancy vulnerability so it'll say on line 36 you have you know a potential re-entracy vulnerability please address it so we all know what it means but I'll kind of just go over it for maybe people who don't know you might have the case where it's like you have a function where let's say on line 27 you're you're sending some money and then on line 28 you're flipping some Boolean to let the program know that the money has been sent right so that's how you could be one way that you could be vulnerable to re-entracencies because someone could just keep calling some function that keeps getting to that first line of the execution of that function where it just keeps sending the money over and over but never actually makes it to that line where it flips the Boolean to true or false or something like that so that's something that the compiler will call out and again it won't let you build your contract it won't let you deploy your contract until you address this so with sway this list should be zero this re-entrancy attack will never happen in sway period um so okay Fork is the fuel orchestrator it's the equivalent of boundary cargo npm so it's what does all the bills manage dependencies deploy format tests the language server so I kind of made this map to kind of show like part of the the draw of fuel is not only all the things we just talked about but it kind of unifies part of the developer ecosystem and the developer tooling so that instead of having to rely on this like kind of fragmented ecosystem right where one team built Foundry one team build heart had one tree one team built the evm one team built solidity one team you know that's like all of these different things that you kind of have to make them work together as a developer you have to work with like versioning you have to make sure that everything's talking to each other that works well we feel we're like let's just build everything in-house and make sure that everything's always maintained up to date so for developers and that's what I'm going to show you here you don't have to worry about installing ethers installing wagme installing Foundry using hard hat copying and pasting your API like all these different pieces to make it work oh okay now let's just Speed Run uh writing a Dap on field can you guys see my desktop right here okay cool um so this is following the developer quick start which I'll pull up here just so you can see you go to fuel.network you hit read the docs developer quick start so we're going to follow this so if you don't uh you know if we don't get through it or whatever this is how you can do it so we're literally gonna speedrun this baby so you just have to install the rest tool chain install the fuel tool chain and then I'm just going to go ahead I already installed that obviously so I'm just going to start so I use warp as a terminal by the way if you don't use it you should check it out it's cool Warp yeah it's really cool for a lot of different reasons uh so what I'm gonna do is I'm gonna make a new uh thingamabob a new thingy then I'm gonna make a new project so the way you do it is Fork new and then I want to call it something I'm going to call this one counter how about now can you see my vs code though okay I'm gonna zoom in Okay cool so now we did Fork new and then the name of the thing I just called the counter so if you open this we have a main file this is where we're going to be adding all of our code so in this thing we're just going to Define a simple contract where there's a counter function to increment and then a counter function to grab the current value so I'm going to go here and just copy this and then we can talk about it all right okay so the first thing that we're going to do is Define our ABI now if you were building a real uh like quote unquote kind of real project the way you would do this is you would Define your ABI in a separate file because the idea is then another developer could use this library and say like you know if I built a library for like I said like scientific math or something I could just Define this API and then you could use my API and Define your functions but we're just going to do it all in one because uh time but let me just copy this whole thing actually and then we'll talk about it delete [Music] copy okay there cool so the first thing that we're doing is every sway contract starts with defining what type of file this is because you can have a contract you can have a library which is what I was talking about where you would just Define your API in another file that would be a library you can have a script so this is we're defining a contract so you'll see it was cool I really like this I'm a visual person is this the storage variables are kind of grouped together in this object like you know syntax if you're coming like from JavaScript which is really nice because then you could have like another one another one and they're all together visually so you can just scroll to the top and be like what are my storage variables then we defined our ABI which are just two functions increment and count so here you see there's actually no function body that's what you would Implement in your actual contract but like I said we're doing it on the same file just for simplicity's sake so here's where we're implementing counter so we Implement uh this one that's just count which just Returns the value of counter which starts at zero this is the equivalent of this by the way so this is shorthand we don't need the word return and then you don't need the semicolon and then here increment does the same thing it accesses the counter variable in storage takes the current value and adds one so we're going to go to terminal Fork build make sure oops Fork build make sure it builds great so now the next thing that we're going to do is we're going to build a front end for this so there's actually a part here to test to write tests but we're just not going to do that because we don't have time uh uh then we're going to deploy our contract I already have test coins I'm just going to go ahead and do this so here if you guys can see it says Fork deploy hyphen hyphen URL and it's that graphql endpoint that I was talking to you about because again like I said that's where you actually deploy so it's not a Json RPC endpoint uh so this this part that we're talking about oh it's fine it just was creating a new file um so this part that we're gonna go through is like kind of janky right now because so Fuel and sway in general just a very early like we just did test net maybe a month ago so there's still a bunch of parts that are in development the wallet part is one of those things so you kind of have to do this manually for now but in the near future you'll have um like a browser extension wallet like everything else I'm gonna do Fork wallet list to show me all of my wallet addresses which I only have one so it says Please provide the address of the wallet you want to sign with I'm going to pass it in it's going to give me this transaction I go back here Fork wallet sign pass that in and then index 0 because here this address is index 0. right here the zero that's where that zero is coming from and the path do my password and then it gives me back a signature then I give that back here okay I know that was a lot but it won't be like this forever then you copy your contract ID I'm just going to put it um I'm gonna put it here so I don't lose it don't look at my notes then um yeah okay cool so now let's go back here we now it's uh deployed to the test net we have our contract ID so now let's go ahead and build a front end for it so this kind of shows you how to look at it on the Block Explorer which we're not going to do now we're going to create a react project in the same folder so we're going to CD out one so we're in the big folder and then we're going to paste this in which creates a you know react project for us and then after this loads we're just going to install two things one is fuels it's the umbrella package that includes all the main tools wallet contract providers more and then the fuel chain which generates your apis for you so I'm going to go ahead and copy this while that loads okay we're running like one minute over time but I lost a few minutes so it's fine I feel like I can go over a few minutes yeah okay cool so now we're going to go into the front end that was just created we're going to install the two things that it wants which are listed here cool okay now the next thing that we're going to do is we're going to generate our types and this gets done automatically with the light with the packages that we just installed so that's how we're installing them because we want to be able to run this command that will automatically generate types so if let's say you update your contract like you're building your front end you're like I want to add another function or like whatever I want to update my contract you go make that contract you redeploy it and then by running this command it'll regenerate your types automatically without you having to like verify your contract copy the API paste it in your front end it'll just get done and imported uh automatically so I'm going to copy this but without this okay and then here I'm going to change the name because here I called it counter instead of counter contract so uh this there will be a note in this in the quick start but it's like the name of this so counter and then if we run this you'll see successfully generated four typings done cool so now what we're going to do is we're going to create so this is another part of the thing that I'm saying is janky that you won't have to do so we're going to create this file called create wallet.js which basically makes us that you create a wallet in your front end so you can sign these transactions just going to copy this paste it in save and then just run node create wallet.js and then I'm going to copy this because I'm going to need this close your eyes okay great so now let's go to our front end project source app.

tsx and we're going to paste in the code from here [Music] nice okay can you guys see this should I make it bigger smaller it's fine okay I'm just gonna quick fix this I just has the wrong so this is counter contract that's just the name of the project from the quick start here we just call it counter so we're going to update that same thing here update that Quick Fix Okay cool so let's talk through what this looks like really quick so here at the top we have our contract Factory and here what we're going to do is we're going to paste in our contract ID and our wallet secret so our contract ID is this first one that we got when we deployed the contract our wallet secret is the private key from the uh wallet that we generated in the front end so I'm going to paste that in here great uh the other thing I'm going to do is I'm going to go get some tokens so this doesn't fails from the faucet so I'm just going to type in faucet I'm going to get some coins real quick great see how fast that was by the way [Music] um great so now we have this so this is just like a simple count thing right here we have a button here we have a button where are you butt in here but anyway when we click it on the front end it calls this function called increment which is defined here and this is how you actually interact with your contract so await contract.functions.increment and we know it's increment because it's defined as increment here so if this were called like apple that's what it would be called there uh transaction parameters we're passing the gas price to one because it can't be zero and then we're doing Dot call so that's how we like actually interact with the contract so you see you don't have to install wag me or you don't have to install ethers.js you don't have to install like external dependencies to be able to get your contract and your front end to talk to each other it's all built in and unified in the tooling that's created by Fuel apps uh and then here we want to so remember we have two functions one that increments and one that just gets the current count so we've called increment now we want to get the current count so here await contract.functions.

count which is this one right if the name was something else it would be something else but it's called count so that's how we reference it dot get so now let's save this let's run this okay and that was it so you see right like the thing that I kind of wanted to highlight is if you've ever developed apps for ethereum I was literally just let me see if I can open it up I was literally just trying to write something for the evm the other day and just like I couldn't even get the compiler versioning to like work with the thing I was trying to write and I got really annoyed and I just like gave up kinda but like with fuel the thing that I really really like about it is that you have this like way way better developer experience and you don't have to deal with like puzzling puzzle fitting all the different pieces to work like we just did so this slide let me just show you like last last two seconds so this this slide we replaced this whole thing right like we didn't need to use hard hat or truffle or Foundry or brownie or anchor we didn't need to use web3js or ethers or anchor and then we didn't have to use the graph um like we just removed three like key kind of pieces that you have to usually finagle with to get something to work and it all just was integrated directly uh last thing I want to say is here are some resources if you want to check it out more the first link or the first QR code is something called awesome fuel which is basically this resource where you can find all the Articles podcasts tweets like all the best stuff about fuel publicly and then the second one is the fuel book which is the developer resource with the quick start with information with the sdks and all the different stuff that you could want and finally thank you my name is Cami Emily right here is from the compiler team if you want to talk to her about compiler stuff and sway stuff and like I said we have a booth at the front and yes thank you