Fuel Labs 🛠 Superior Developer Experiences

[Music] hi guys so today I'm going to be talking about the superity developer experience at fuel Labs my name is uh call delegation and I work as a developer relations engineer at Fuel and in this presentation I'm going to talk about what fuel is at a high level um why you should care about developer experience and showcase some of the unique features uh of fuel um namely predicates and so you're wondering to yourself what is fuel fuel is a modular execution layer it is a L2 um and we have our own fuel VM and we don't use the evm so we have our own language our own um compiler um and our own stack and so if we talk about blockchains um in a traditional sense there's the execution layer the settlement layer the consensus layer and the data availability layer and so a when we talk about monolithic blockchains um namely ethereum it does everything from top to bottom and so we can replace the execution layer with fuel um and so you would execute your transactions on on fuel and settle on ethereum and so what makes fuel so fast is that we are again building our blockchain from the ground up um and we are using a utxo model instead of an account based model which is allows us to run transactions uh in in parallel and that's why we're the fastest modular execution layer so with the next piece I want to talk about the developer experience um and why you should care about the developer experience and if we took a take a look at ethereum um the typical onboarding flow is that um you as a web 2 developer coming to web 3 um you might come across maybe some basic tutorials like crypto zombies or do a few solidity cfts on open Zeppelin um and now that you're a little more comfortable with solidity you want to develop full stack applications um but then there's so many Frameworks to choose from like truffle hard hat Foundry and and then let's say you you're pretty comfortable with solidity now but you notice all the shortcomings that um happen with solidity so you move on to Viper maybe um and then when you do have your fully built out application you would go through um static analyzers like Slither um a bunch of different audit companies to choose from and spend a bunch of money on audits so the point I'm trying to make is that the development experience is a bit fragmented um in the ethereum world um and and sometimes it can just be simply overwhelming so let's compare it to the fuel stack um from top to bottom everything is made in house um so starting from our our our language that targets the fuel VM our s l um and the surrounding sdks the typescript SDK as well as rust SDK um and last but not least the indexer um so you know everything works from top to bottom and so I wanted to showcase some of the sway code so if you want to pause the video right now and try to identify what is wrong with this contract uh written in sway uh feel free to do so but the bug is reeny and reeny has been around since 2016 um since the Dow hack and it's still prevalent today um and over the years it's costed our ecos system hundreds of millions of dollars um and we're just setting that money on fire so we can talk about the sway compiler um again built from the ground up you can detect the sway compiler can detect reeny bugs um at compile time and this really helps with the developer experience because now you have web 2 developers who are who are really excited about the web 3 world they don't have to know about all these little nuances of solidity all these nuances of um different types of bugs that can be prevalent um that some to be honest like some audit companies might not even pick up on and so the barrier to blockchain development just got lowered so there are going to be less hacks in the future less friction and faster development overall so you right now you might be U curious about fuel maybe you're not um but but I want to showcase one more unique feature um that fuel offers and that's predicates so there are four programming types in sway there are your traditional um smart contracts that you're probably familiar with there's libraries um scripts and the last thing is uh predicates so what are predicates predicates are just simple programs that are stateless um and they can return true or false and just to reiterate they are just a piece of code um if you hash that piece of code you get an address and you can send tokens to that address and the rules of the predicate again if they evaluate to true or false you can unlock those tokens so predicates cannot be created or deployed because they're just a hash of a piece of code into an address and some of the properties are they can't read or access any data on chain they can't read data from Smart contracts they can't check the date or time they can't read the block hash or number but what they can access is the transaction data which is um some of them include the input parameters input coins output coins transaction scripts and B code of the actual transactions and you might be still asking yourself why is this useful and one of the main problems of ethereum is is that there's a lot of State bloat and with um predicates and account abstraction we can prevent a lot of state blo that happens on chain some of the limitations of predicates is that you cannot update a predicate because it's just hash of a piece of code so anytime you um rewrite the rules uh you you would need to remove the assets that you've put into u a particular address into the new address so just to highlight some of the features of predicates I'm going to do a short demo on um how to create a predicate based multisig so in this part of the tutorial we'll be building a multisig predicate and for those of you who don't know what a multisig is it's essentially just a digital signature scheme that um requires M of n signatures to authorize a transaction so if you have um two out of three uh signatures in the multisig approving a that signs a transaction then um you can unlock the utos that are locked behind the predicate and so this is what we're building so um like before we're going to do Fork new multisig predicate demo um and then this generates a sway project for us so we'll just go into the multisig predicate demo and then open it up in VSS code so we can go ahead and remove the pre-loaded contract from before because we're going to be building a predicate program not a contract program um and inside this will be needing several uh several things from the library standard Library sorry so use standard library and we'll be grabbing the transaction winess data um the transaction witness count and the transaction ID and here we can use um the uh 5 b512 type as well as the elliptical curve recovery function and I'll be explaining in a in a shortly why we need these things as we're building out our predicate okay um and yep so now we can Define our configurable um and what a configurable is in sway is just a fancy constant that um can't change during an execution but can be adjusted after building um through the typescript or R SDK so this is similar to immutable variables in uh solidity um so here we can Define two two of the or all three of the addresses that we'll be using for this multisig um and then let me just grab some of the private keys I'll be using and within this multi- um we need M of n signatures so um n being three we we' defined three um signature or three public keys in this multis and we would probably require two out of the three to sign in order to um unlock some of these uh tokens that are inside this predicate okay and then um just just to reiterate the predicate um only evaluates to true or false so if two out of the three signatures um are verified then it can unlock the um utxos inside this predicate so we'll be our our main function would just return our true or false um and then we can Define the key addresses here okay and the next step is to um Define some of these mutable variables so one of the edge cases is that we don't want um let's say two of the input like uh one of the one of the public Keys signs the transaction twice so we want to make sure that the um the input witness data in the transaction is unique um so we'll be keeping track of that and we'll also be keeping track of um all the valid signatures that are coming in as well as the uh trans transaction signature count and the last thing that we need is actually the message hash that is the transaction ID okay so we're going to Loop through the transaction count and once we've hit um we've hit zero then we can exit and check all the transactions uh check all of the signatures to make sure that there's enough valid signatures unique valid okay here we are taking in the first um first signature and we're going to do let the current address not so we're making sure that the sign message matches with um with one of these private Keys here okay and now if the current address signature and here we're doing the actual check then we would increase the count by one as well as the number of valid signatures and that's it so all we have to do now is to check if the signatures are unique as well as um ensuring of course that M of n signatures are present to unlock these utxos have the valid so if all of this is good then we will return true if it's not we simply just return false and for those of you who have been following along if you guys are having any issues with uh compiling the uh predicate here uh please refer to the GitHub in the QR code to um continue to The Next Step okay now that we've written our predicate we can simply just do the exact same as we did with uh any other contract or program type we simply just run Fork build and it returns us a predicate route um which is just a hash of this code that we have written and um we would send our utxos to be locked behind the multisig um to this address I want to highlight some of the other applications that are um possible with predicates and are currently being built on fuel right now is order books so predicates um let's say this particular type of predicate is a over-the-counter um order of a token so let's say you have you deposit a token B inside this predicate and if someone comes along and sends you x amount of token a then you would return to and unlock token token B to um whoever the buyer was so you have your usdc you put it into the predicate address um and then someone comes along they send in token a and it unlocks the usdc so you can imagine a bunch of these um orders for your token a and on the other side you have a bunch of the orders for token B and you can imagine that everything is stateless um because again predicates they're due to their nature they're they're stateless um you can do all the a matching of all of these orders offchain um which can uh save a ton of resources so the main takeaway from this presentation is that um there are these cool new features um that fuel is offering um and I would love for everyone to kind of explore and um play around with fuel and just to expand on what people traditionally know about blockchain development and so if you want to come talk to us uh we'll be floating around in uh e New York and this is a QR code that you can scan to visit our docs and hopefully I'll see more of you in our ecosystem and building on fuel in general thank you everyone