 Welcome to build a fuel or learn more about it. And there will be some things in here for that. So you can always do workshop at home. So you can take it home, workshop. So, I also can't see the slide, so I'm gonna like, also tend to something creative. Okay, so I'm gonna talk a bit about how we got to where we are today with fuel. By going through a brief timeline of events. In June 2019, I introduced optimistic role of design paradigm under the title of minimal viable merchant census. And this kind of kicked off the whole idea that you can have some sort of scalable execution system anchored into Ethereum for security. Moving on to December 2020. This was right at the end of the year, but still 2020, we did a mainland launch of Fuel V1 as the first optimistic roll-up on mainland Ethereum. And to this day, it's actually still the only system that could be considered a true roll-up that is trustless and permissionless. Since then, up until January 2022, we were essentially heads down building out Fuel V2, which was an evolution of the protocol from a payments only platform to a general purpose smart contract execution platform. So we published our code in GitHub. Since then, the code has been developed. It has been open source and entirely developed, planned, and et cetera, all in public. Not a lot of projects actually do this entirely in public. We actually do all our development in public. And in June of 2022, we launched a SwaySwap demo. SwaySwap is a port of Fuel V1 to Sway, which is the high-level language that I imagine most of you are here excited about. And along with the private test map. And then in September of 2022, so just a short month ago, we released the Beta 1 public test map of the Fuel Protocol. This is actually completely permissionless. Anyone can use it to apply a smart contract, run transaction, and you can use it today. And now we're here at DEVCON October 2022. And what do we have and where are we gonna go? Let's talk about the three pillars of Fuel and what makes the protocol so great to use and to build with, et cetera. So we have three fundamental pillars. One of them is performance. Performance through parallel transaction execution. The second one is flexibility and waste reduction through the Fuel Virtual Machine. And the last is a superior, in fact, unmatched development experience through Sway and fork. I'm going to be expanding on each of these pillars in the coming slides. So let's start with the first one, performance through parallel transaction execution. This one of this is actually going to be the shortest of the three-floor liqour because it's actually fairly straightforward to explain, which is that, you can see from the chart here, the, while the number of transistors on CPUs has been increasing exponentially over the years, you know, this is Moore's Law, the single threaded performance in the last, you know, 10 plus years hasn't increased exponentially. It's kind of stalled, it's basically leveled off. What has increased exponentially, however, over the years has been the number of cores, right? So if you have a system that is sequential that can only leverage a single core, it's like you're running it on a 10-year-old computer, right, there's not exactly a very good place to be when you're trying to build a global financial, XS, et cetera, system, right? You really want to leverage a thing that is increasing exponentially year over year, and that is this parallel execution, multi-core, multiple cores, multiple threads running in parallel. The fuel virtual machine is designed, and the fuel protocol is designed to be able to run transactions in parallel as opposed to EVM, which unfortunately can only run transactions sequentially. This will lead to a fast increase in throughput, all of us being equal, not because you need a more powerful computer, but just because you're using all the resources of your computer that in the EVM are just kind of sitting there wasting it. So that's the, again, so that was short, because that's really all there is to it. Parallel transaction execution, massive increase in throughput. Now onto waste reduction and increased performance on the single threaded model. Oh, I guess I didn't collect this. And waste reduction and improved performance within a single thread, through the fuel virtual machine. So there's also some QR codes here that you guys can scan if you so wish, that link to some of our documentation around these things. Just in the slides, we'll all be posted later on, so if you don't, maybe don't want to scan them right now, they'll obviously be available. The fuel EVM is fundamentally the EVM but improved. One amazing thing you can do in a roll-ups is experiment with improvements, enhancements, et cetera. And there have been many, many EIPs and just ideas that didn't even make it to EIPs that had been posed over the years for Ethereum, but that could never be implemented because of a need for backwards compatibility, also then the developer resources, just the worries of too much change too fast might be risky if you have a large code base on radio with a lot of tech debt. But people still want these changes, they've been proposed. If you take a roll-up and you might say, oh, okay, I'm an EVM equivalent roll-up, I want to improve it. I'm gonna start implementing EIPs to improve it. I'm gonna add a counter-fraction, I'm gonna add parallel transaction execution, et cetera. Let's fuel. The fuel EVM is the EVM but improved. So if you're looking for the EVM of five years from now, that is the fuel EVM. Next one, state this account of traction. Some other projects give like entire talks about this one topic, but this is just one of the many things you get in fuel, so it just gets one slide. Fuel supports account of traction, but statelessly. Stateful account of traction is actually a denialist or a specter. So e-wary, if any project that says has stateful account of traction. We have state-less account of traction. What does it allow you to do? Well, like any account of traction protocol, it allows you to define conditions under which a transaction is valid. Not conditions, not logic of what the transaction will do, but actually conditions under which the transaction is valid or not. The most obvious case, one thing you could do is use a different signature scheme. You can use schnore signatures if you want to. And this is actually what enables us to use any wallet whatsoever for fuel. Obviously, we're building a native wallet that has all the bells and whistles, things like transaction simulation, in a mode where you can log in to pretend to be any public key or any address, et cetera. But maybe someone doesn't want to install a new extension because they use some of that, right? And they have a sign on a wallet or they use Ethereum, they have MetaMask. You can use any of these things and sign transaction on fuel because of account of traction. It allows you to define the validity conditions that are basically a wallet. Whatever sign, message, whatever wallet you want or will do, it checks that for validity. And users are the ones that define the spending conditions, the validity conditions of this, not the protocol. Now, there's anyone in the world can go in and just define some new conditions and they'll work with a new blockchain, just like that. No protocol changes required, no hard fork required, no governance required. Just as a user, you just write it and you're done. In a sense, we all know that transferring tokens are a really painful thing, right? There's like super extremely, actually for real, this time safe transfer from, right? Needed because there's only vulnerabilities and something as simple as just transferring a token properly. Fuel supports multiple assets, multiple assets natively. So every token is a native asset. So you could have like a die as a native asset, you could have USDC as a native asset, you could have, well, Ether obviously as a native asset. And these native assets can be pushed with contract calls, which means you don't need the notion of token approvals. You can push them, their first class is just like how in Ethereum, you can push Ether with a contract call. No token approvals, so not only are you getting better security from not needing some sort of safe transfer from function, transfer from function, you also don't need token approvals. And this is actually a really big thing for users, not developers, because as users, you know that token approvals are a really big UX pain point, right? It's due to approve the exact amount you wanna spend. If you do, then you have to always add a second transaction every time before you interact with the protocol. It's more expensive, it's slower, it's worse UX. If you do infinite approvals, now the protocol has a bug, they can drain all your tokens, all whatever you infinite approved, right? With this, no need for token approvals because you just push the native asset. Okay. Next is native safe math, just to make sure I'm on the right track. There's no need for a safe math library, there's no need for some runtime overhead that will add extra bytecode to check for safe math. The virtual machine itself supports safe math natively by default, which means you get overflow protection for free. Cross call shared memory, again this isn't like, all of these things are either EIPs directly or variations or inspired by EIPs. If you guys have heard of transient storage, transient storage is storage that persists across contract calls within a single transaction. That's what this is, right? It's some piece of memory that is accessible across contract calls. The fuel of our machine, all contract call frames share the same memory, which allows you to do things like a completely in-memory re-intrancy guard. You don't have to set the storage slot for a re-intrancy guard, you can do it entirely in-memory. And in fact, this is already implemented in the SWAY standard library. It was a function to do it in-memory re-intrancy guard. So it's not just theoretical. It also allows you to pass large data around with contract calls, so if you happen to do some data computation intensive task, you can do it just by passing a pointer to the data. Next one is transaction scripts. One of the pain points of approval and transfer from in addition to, you know, just approves being painful is they have to be done in two transactions. You need a transaction first to approve, make it complete, and then transfer from. And they have to be done in two transactions because an Ethereum transaction can only call a contract. It can't call two contracts or call two contracts and do some conditions and call a third contract or fourth one depending on some condition. The fuel protocol has transaction scripts which are basically bytecode embedded directly in the transaction, and that is the entry point for execution, not the contract call. And the script is bytecode. It can do anything. It could call one contract, it could call two contracts, it could do an atomic approve and transfer from. Obviously for fungible assets, like I said before, there's multiple native assets, so you don't actually, ironically, you don't need this for approval and transfer from atomically for native assets, but it will be useful for things like if you have a non-fungible token that does have approval and transfer from, then you can use, you can do that atomically in a single transaction thanks to transaction scripts. This also allows you to do things like add liquidity to a pool or for two different tokens, et cetera. So basically the other thing that nowadays you would need multiple transactions to do, just due to the nature of Ethereum only processing a single contract call for a transaction, you could do it in a single transaction and fuel. All right, we're getting to the end of this section. And last but not least, to reduce waste, the virtual machine is register-based and it uses 64-bit words. The 64-bit words, instead of 256-bit words like what the EVM has, means a lot less waste, a lot closer to the metal when it executes because you don't need big integer math every time you do an addition. You can just add two numbers together and this goes really fast. And combining these things together, including being register-based, means that you're executing a lot fewer instructions to do the same work in addition to just executing faster and that reducing the number of instructions executed to do the same work is very important because gas-accounting overhead is a huge portion of the overhead of the virtual machine. It's like enormous and you want to reduce that overhead as much as possible to squeeze as much throughput as you can on the same physical hardware. So by being register-based, you greatly reduce that. And it doesn't really affect the end user at all, because you as a user, there's EVM as stack-based, but you don't care that it's stack-based if you're a user or a developer. It just is, it just works, right? Okay, on just my important and unmatched developer experience, standard library. So the language is very minimal. A lot of things are moved to the standard library. One example that we'll reuse in subsequent slides is the easy recover. This thing here will recover the public key or the address, does an implementation detail from a signature and a message hash, right? In slidity, this is part of the language itself. In other words, the compiler developers need to go in and add some special magic method into the compiler, embed it into the compiler, easy recover, right? That does not exist in SWEI. The SWEI compiler and the SWEI compiler team don't know what easy recover is. This exists in the standard library, which is written, the standard library is written in SWEI, although it's software, not embedded into the compiler. Here's a QR code I think to link to the implementation of easy recover. Why is this good? It's good because it means that the standard library can move very fast because you don't have to get the compiler developers to do something. This is in SWEI. If any of you can write slidity and you can write SWEI, you can just add stuff to the, you can submit a PR and just add stuff to the standard library. You don't need to know how a compiler works, right? You just write SWEI, you just write in smart contract code. So it allows the language to move quickly because it's lean and it allows the standard library to move quickly because it doesn't, you don't need to know how compiler works to contribute to the standard library. And this basically almost every function that isn't actually like core to the language itself is in the standard library and not in the language itself. Next, generics and sum types. Generics, look, is that the angle brackets, right? So you can define the type of the thing later. Some types are either one or the other, right there, kind of like unions. Combine them together and you can get things like a result, for instance, which we'll talk about in the next slide. But generics are very good because they allow you to reuse code, reuse logic, without having to duplicate code. There's a Safe Math library, right for splitity, but if you want to use Safe Math for like a UN64 instead of a UN256, you just have to copy all that code and change the type, right? If you have generics, you don't have to do that because you can just make a logic generic over any type that supports some functions like same-edition and then, you know, instantiate with different types. So it allows much easier code reuse without having to, well, it allows code reuse, period, for things that are the same logic but in different types. Now, why do we care about results specifically? Why is this important? We're gonna go back to our example of ECRecover. On Ethereum and Solidity, the ECRecover function will return something special if there's an error. Can someone yell out what that something special is? Okay, someone says zero, perfect, right? So if the signature is invalid, then ECRecover will return a magic value of zero. You know, the address zero has signed over this message hash with the signature. Obviously, that's not true because, you know, if you knew that, if you knew the private key to the address zero, things would be very bad. But the ECRecover doesn't tell you anything explicitly, right? This is this magic value. And if you don't remember to check this, then someone can pretend they're from address zero, right? And maybe like do a bunch of nasty stuff. And in fact, just a few months ago, a contract forgot to do this and I think it was exploited. Or maybe it wasn't exploited, at least it was still there as a bug in code. With results, you can actually wrap the return of things. So ECRecover in Sway, which again, the standard library function does not return a value. It returns the result over a value and an error, right? So if the signature is invalid, it's not going to return zero, it's gonna return an error. And if you want to actually get into the value, you have to unwrap the result. And you have to do this, otherwise the compiler just straight up won't let you compile your code. In other words, you have to handle that error and the compiler will force you to handle that error explicitly. In Solidity, there's not the case, you have to actually go manually remember to check that zero value. And there's other places where this happens. So having generic in some types allows us to have results along with other things. And this allows for explicit error handling, which means safer code. Because the compiler tells you, you don't have to go and remember your result. Okay, next one, type in fronts. We probably all hate writing types of things, especially when those types are long, especially relevant when you have generics. There's a left keyword. No, I'm not tired of what would have been a bar, I guess. But you know, there's been some bike shedding. I think on Twitter I saw fairly recently on this left keyword. So this way is a left keyword. And this allows you to have type in fronts. Right, we use the same type system as Rust. So you can just, you know, whatever's on the right, it can be inferred. You have to actually write out very few types. And if you look at our standard library, I think type in fronts is used quite a bit throughout it. So that would be a good example of how you don't have to write that many types everywhere. And on to, okay, next one is namespace storage access. Insolidity, storage variables and regular variables are all in the same namespace. And if you have a storage variable foo and a local variable foo, and you go foo.whatever, which one are you accessing? Right, likewise, what happens if you have two variables that are close in name, right? You have like an O, count and cmt, let's say, right? You can use the wrong one by accident, right? You intended to increment something in storage, but you incremented it only locally or vice versa. And sway storage accesses are namespaced with a storage dot keyword, which means if you want to access a storage variable, you explicitly have to write out storage dot. This means you can just look at the code, type old or not, and you can see what words of the code are actually touching storage versus not, right? So additional explicitness means additional safety. Next one is exhaustive pattern matching. This one was implemented quite quickly by one of our amazing compiler engineers, Emily. For those of you who aren't familiar with pattern matching, it's a match statement, right? And it allows you to exhaustively enumerate all the possible cases. So let's say you're matching an Boolean, the exhaustive cases are true and false, right? And if you only matched on true, the compiler would tell you, hey, you haven't matched exhaustively. This means that unlike in Solidity where you have to do an if-else chain, and hey, if you forget to check a case in your state machine, right? For your contract, if you forget to check a case, well, too bad it's so sad. The compiler tells you nothing, right? With exhaustive magic expressions, well, not only is it cleaner, because it's all like a single thing instead of a chain. It's also exhaustive and the compiler will tell you if you missed a case. Next one is zero cost attractions. This is kind of a first-class notion in this way language and this way compiler that the Solidity compiler doesn't really do. One example of a zero cost attraction or just zero cost things in general, it means moving stuff from runtime to compile time wherever possible. That's what the ethos is really about. One example is, well, what happens if you could check method payability at compile time instead of at runtime, right? The Solidity compiler will actually inject some runtime code into every method that is non-payable, right? This is a runtime cost, it's bad and that's why optimizers will actually just add payable to every public method to avoid that runtime cost and just say, okay, read the documentation, read the docs and the function and don't send ether to this method, right? But you can always do it at compile time which is what Sway will do, right? The Sway compiler is that you actually check at compile time with someone trying to send some non-zero value of any asset, not just ether, to some non-payable method. Okay, and another, last but not least, the thing that will zoom through since I have one minute left is re-entrancy. Re-entrancy exploits are still happening to this day six plus years later after the Dow. Tooling should pick this up but it doesn't. The Sway compiler will warn you if your contract has some potential re-entrancy vulnerability because it violates the check effects interaction pattern or other patterns. The Sway compiler will actually warn you. So goodbye to the days of re-entrancy vulnerabilities because we now have two of them that can warn us about that. All right, and last but not least, not on the language side but on the tooling side, we have fork, the fuel orchestrator which is the equivalent of foundry or cargo NPM. This allows you to do a variety of things including building, deploying, managing dependencies. Oh, I have a question. Thank you so much. Okay, it allows you to build, deploy, manage dependencies in the same way cargo does and no weird git modules. It has an Australian formatter, tasks, a language server. We actually had a language server before Solited did it. So if you want to visit QR code to link to the Sway book, if you want to learn how to write Sway and dive in ahead first, this will take you straight there. I'm gonna leave it up for a few more seconds. And then with a few seconds left, I would like to close out the slide by thanking not only you guys but each and every one of these 65 contributors in the FuelLabs team that has brought fuel to where it is today. Thank you.