 you know, Ethereum far too long. I've aged significantly and it has been a wild journey. And yeah, I've been using Solidity, I think since it started or since the very, very early, early, earliest versions. So it's been a very wild roller coaster of an experience and so in lots of different apps, lots of different stuff happened, but effectively after a little while, getting deeper and deeper into Solidity and getting deeper and deeper into how the EVM actually works, you know, you wanna go a little deeper and a little further and thanks to Chris and Alex, you know, UL has been an interesting pathway. So yeah, today I'm gonna present, you know, my extension to UL, UL Plus. You could call it a new language, but it's effectively, it's mostly UL, but with some extras, that's the way you can think about it. So for the agenda, we're just gonna do a little overview of UL, you know, what I really like as a dev about UL and what it is. And as well, the motivations for why there might, why there's justification for maybe an extension to UL, you know, objectives for this new language, a feature overview, roadmap and you know, where we might wanna take UL, UL Plus and then lastly, I have a special reveal of a project. So you guys are gonna see, well, kind of the reason why I want all these things and the reason, the sort of the result of doing it. So yeah, that's sort of the agenda. So yeah, with UL, UL is just an intermediate language. It helps Chris and Alex and the rest of the Solidity team sort of build Solidity and act as a nice sort of intermediate layer between assembly and some kind of reasonable language. And the things that really stand out to me about UL is just simplistic grammar. There really isn't a large grammar there. It's functional notation, it's low level. It manages all the stack work for you. And if you've ever tried, I don't know, computer science class or something managing stack, it's a goddamn nightmare. So it's great. It's easier to audit and formally verify primarily at the assembly level. So when I want to take a build that I've done and have people who do form of verification work with it, I find the produced assembly is much easier to build proofs out of than Solidity. So I think this is a big benefit. And I know there's tools that are on the way and that are constructed for Solidity and form of verification. But with UL, we can really do it right at the assembly level and just the produce build is really clean. So the compiler is simplistic. I love that I can open up the Solidity compiler and look at the UL section and actually understand exactly how it's breaking everything down and how it's going to ship off to EVM code. I think that that's a huge benefit for the community and the language to be able to have this really simple step. Solidity has obviously got a ton of features and it's working with a lot of different concepts. And this, of course, makes the compiler complexity, it increases the compiler complexity significantly. Whereas with UL, you're really doing more simplistic operations. This is minus the UL optimizer, which adds a bit more complexity, but of course you can just turn that off. And then it produces really efficient builds. So because it's just managing stack and you're effectively still using stuff right off assembly, you get these really tiny, clean builds of contracts. And I really do like that. Of course, you're not gonna get the safety you want, the language and compiler level safety. That you get from languages like Solidity, but you do get significantly increased build efficiency. So the deployment cost is very small. Shared memory and function macros. So you can actually, using UL and all show cases of that. But one big aspect is just sharing the same memory across many different functions. And I know Solidity can probably and eventually do this using some macro terminology. Or if it already does, I don't know, I haven't worked with Solidity recently, but effectively this is one of the big reasons and you'll see why in a second. And as well, just more precise stack control and management. So just being able to more in a fine grain way build applications and low level code and get a better idea as you build, how the stack is actually going to be managed because you know the UL compiler is actually very dumb. It's not doing anything special. So if you're loading up a huge functional statement, then you know you're gonna be pushing the stack even further. And that's basically the precision you get with UL. So some motivations for the extension to UL. So I love UL vanilla. The second I saw it and the second I started to work with it, I immediately loved it. And given that I've spent a long time with Solidity, I felt like as a developer, it was sort of reasonable for me to be able to extend my capacity and go further down closer to the EVM metal for experiments and for development and everything else. And I loved UL for various purposes. And I built the Fuel Optimistic Rollup, which is what I'm currently building. Most of the contract, about 80% of it is written in UL. So it's one function written in UL and then there's the few Solidity functions. And in our second build, which will be releasing this quarter, the entire contract's built with UL Plus, effectively UL, but UL Plus. So the lessons I've learned from that, I've kind of taken into this and said, okay, well, there's definitely a few things I would love in UL, but it may not make sense to have in UL. So first thing is management. So building large code bases with UL becomes very verbose, repetitive, obviously, because it's low level and it's going to not do a lot for you. So it comes with a lot of mental management as working with memory on a low level would always come with. There's not a lot of sugar. So there's many instances where you just wish there was a little bit of syntactic sugar and adding it would not be significantly less efficient. So it's not like we're adding on these really complex statements that have big concepts around them or anything like that. They'd be simplistic concepts and they just add significant notational value without increasing build complexity. As well, I think you can add sugar to something like UL because it has such a simplistic sort of base grammar, but that doesn't mean that it should be in UL because the reason why I think I love it and why other people will love UL for certain cases is going to be because of its simplistic grammar and that there isn't all these new concepts or expressions or anything on top of it, it's very simplistic. So this becomes kind of a motivation to say, hey, maybe there should be a little sugar or extension on top of this that's going to pepper in little things that just make building apps with this easier. And I will say too that I don't think it was the expressed motivation that UL would be used for application development or for things like scaling and rollups, but it really fits the bill in terms of what I'm looking for as a more lower level developer with Ethereum and for the express reasons, Bob. So of course, the design intention was not to put something really developer facing in front of everyone with UL was more, how can this be a nice intermediate step between assembly and the development of Solidity and or other languages? So that's just to note that. So as for safety, UL comes with little safety nuts. Of course, it's just, it's effectively a simplistic compiler over the assembly, over assembly. So, and then lastly, extensibility. So making an open source layer on top of UL that allows for a lot of custom language variants and plugins. So this you'll see is kind of something we're looking at. And it's something that I will, we're already kind of using with D-Type, which is an interesting new typing system. So these are the sort of motivations. And as well for Fuel Labs and the Autistic Rollup game, it's primarily about gas sensitivity and you'll see why in a second. And then as well, it's better for rollup contracts because rollup contracts require a significant amount of low level gas sensitive work in terms of breaking down proofs, a lot of cases where memory would be shared and where if you're copying fresh memory every time, that's going to really significantly add up. So you wanna be able to have a deeper level of control over what's happening in execution. And then lastly, I'll show it's fantastic for building stateless contracts, which are sort of, I don't think a concept that people are really working with yet because we're not really dealing with problems of scale just yet, but as you'll see, stateless contracts are what we believe is the future of decentralized app development and the future of, well, everything. So pretty important. Okay, so objectives for the new language. And we're almost through my dense point slides. So just hang in there if you're getting bored. So objectives for the new language. So philosophy, don't do too much. Value, just add sugar where you need it. Don't, you know, where it's only going to add maximal value. Don't add all this fun sugar up for nothing. You'll first produce valid, you'll build grammar, keep the grammar as close to you as possible so that we're not doing too much once again. Be extensible. So allow others to add in different layers on top. You know, I'm not gonna know every reason or feature that people want, but I do know that JavaScript is a really easy system to add and remove things. So, or it's a really easy language for others to contribute, socially contribute. So, you know, it comes with a lot of interesting potential experimentation and then as well influence. So if a lot of developers using a certain feature in ULPLUS, we could see maybe can that be carried over into ULL or Solidity in some format. So just being able to influence other languages. So the features of ULPLUS after that huge rant are as follows. So just all existing UL features, Enums, Constance, and Ethereum, ABI generation, the hash generation, Safe Math. So you can basically get Safe Math injected for free and you can turn that off as well. Any of these things you'll be able to turn off in the production compiler. Injected methods. So M slice and require and memory structures, which are the more sophisticated addition and will be expanded to support ABI encoding and a few other different kinds of structures, D type structures, et cetera. So as I said before, ULPLUS is just a layer on the UL Sol compiler. So we've written ULPLUS in nearly, which is me actually there, which is a nice sort of grammar parser. So the grammar is constructed in this grammar language, which is sort of a hybrid between JavaScript and their own language. And then we break down the UL code that way, add a layer of features on top that gets compiled to ULL and that's it. We're really not doing anything more than that. So to cover some of the features. So here's what enums look like. We've kind of kept most of the notation similar to UL. So just enum, colors, et cetera. So it'd be zero, one, two. And as well, constants. So just adding the const specifier. So this does two things. One, with constants, it will, if it's a literal, i.e. a number, hex value, something like that, it will just do injection across the build. If it's not a literal, so it needs to be run in execution, then that is going to be set as a let statement, but we'll look out for other things trying to reassign. And so that's the current way we're handling it. I'm sure there's more that can be done there, but that's practically the basic idea. ABI signature generation and topic generation. So still all vanilla UL, you can do fun things like write sig, and then effectively a solidity function, which is how it's getting parsed. This is thanks to ethers.js's solidity function to ABI parser. So you can effectively write what you believe that function is in vanilla solidity. It's sort of a header and then that's going to get compiled down to its signature and do all the checking, et cetera. Same thing for topics and the topic hashes. So it'll do the topic hash generation as well. So this just makes handling, readability, all that sort of stuff, just cleans up a lot of jargon that you're gonna get if you just tried to do it with hashes because you'd really have to prespecify like this hash is this thing. So these are nice little generations and that's just going to do a literal injection there, which is quite nice. So save math by default. So if you're just using add, sub, divide, et cetera, it's going to basically change that method name in execution and inject the save math methods above. So it'll switch ad over to save ad and then you're running that. However, you can turn it off and you can use features like unsafe ad. So you're just specifying in the literal sense, hey, this is, I want unsafe here, so give me unsafe. And of course you can just turn it off outright if you don't want it. So really flexible on the basic things like save math and overflow and underflow checking. And with this addition, I want it to be as hands off as possible. I don't want to be maintaining this magnificent addition to Yule, I just prefer that it gives us the flexibility to add what we need, create low level builds and then move on with our lives. So some methods getting injected and another feature. So mslice require, so all mslice is just, is effectively just shifting, shifting right by a certain amount of bits. So here I'm just taking the first four byte signature, just grabbing it from the call data that's copied to memory. So doing little things like that, mslice is great for, it's just, I use it so much in my builds that it just had to go into injection. However, these methods can be changed in the compiler settings, the injection settings, and you can turn them off and you'll be able to basically specify like, okay, or you'll be able to go, hey, I don't use mslice at all, so it'll never get injected. So you have many different options with what's being added onto the Yule language here and require as well. So it'll be able to specify like, hey, the statements, whether it's true or sure not, and then you can specify an error message and we've chosen a simple error system here where the error basically, you put a huge string in there, it's just going to hash that string, take the first four bytes and then use the first four bytes in an injected literal in the require statement. So that's all it's doing. And then at compile, it will give you, it will give you all the errors in their hashes and it'll give you all the signatures and their hashes. So you still get all the sort of luxuries that you would get from a solidity like compiler environment using SIG and error and these sort of injected systems, but they just come in little clean packets out at compile time. Of course, we can standardize notation there and make sure that all the builds are up to spec they produce nice arrays and everything else of all the APIs, but even right now, just with this basic injection, we've been able to do quite a bit. And then lastly, the most sophisticated thing we've done, and this is going to change over time. Right now, you will, in the later versions of solidity compiler support types and they're basic types, but they're still types. So right now, you will, it's just all, it's typed, but it's all, at least in the builds that we're producing, it's all the same type. So it's one, it's only one type. But of course, as we go along, we're going to add in that typing and we're going to add in as well some custom typing with the enums, m structs and you'll be able to do some basic custom typing. So I think that'll be a really nice addition. It's really not that hard. It's just haven't gotten the time yet to switch it. So right now, this m struct notation is sort of in a non-type setting, but it will be in a type setting after. So basically what we're doing here is we're just specifying and describing an existing structure in memory or a structure that may come into existence in memory. So right here, we have some complex data. Maybe that complex data has a signature, it's four bytes. Maybe it's got a value that's 32 bytes. So maybe it's got an array-like structure with a dynamic length and an array where you have 10 bytes for each item. So this allows you to describe a lot of what structures would be popping up in ABI. However, this doesn't have offsets yet where you can specify dynamic offsets for each property, but that will come as well. So you'll be able to get a nice sort of recursive, offsetted memory structure description and I think that that's going to add a significant amount of value to ULPLUS. So right now, it's more just keep it basic and just see how this can be used and this is what we're gonna build a lot of our roll-up with. But in the future, you're going to have full-fledged ABI and not only that, you'll be able to specify your own ABI encodings and you'll be able to specify our typing as well. So these would turn into instead of four and 32 and 32 and 10, it would go to something like a bytes for or it would go to like a U32 and U256, et cetera. So that's really where the typing's going to come in and then here we have the usage. So the usage is really cool. It's just the structure name, so complex data, dot. So the dot notation is already supported in UL, so we're not doing too much here from a sugar perspective and then signature. So there and then we're just putting in the start of where complex data as a structure begins. So this makes managing memory at a low level just really, really, really easy. You're just laying out the structure and saying, hey, here's the structure and then you're just picking it apart and it comes with all these sort of generated functions. So you can say, give me the position of this particular value, you could say, give me, I'm sorry, array should be R there. You can say, hey, give me this item within this array at this position. You can say, give me the array length, you could say hash this particular value or hash the entire complex structure. It'll just do all the positioning for you and it'll inject those functions. So it's really just a function generator and what we want is a system where you can tune that generator the way you want it because we can't expect everyone to use all of the systems in the same formatting. However, ABI encoding at present does most of what we need. Unfortunately, when you get into rollups, the ABI encoding falls short because it's not tight packed. So this is something we can go over in the discussion but that's effectively what's up there. So roadmap and future language exploration. And by the way, how am I doing for time? Am I ranting too much? No, you're good. You have five minutes to go and then anyways go into the your discussion. So it's gonna be great. So I'll get through this as quick as I can. So basically we're gonna add this ABI in string specifier. So this will actually generate an M struct based upon the ABI you specify and then you'll be able to then use those structures and existing memory, which is really cool. So this is great for call data and parse and call data and doing all that sort of work. As well, you'll be able to, it's extensible. So you'll be able to plug in your own typing system like D type. The objects will be extensible. So we'll introduce some basic extensibility. It'll just be copy and paste extensibility. So it'll just follow the expressed ordering and just inject it. There'll be tiny packages. So we'll do a tiny little package manager and it might support as well the ETHPM package manager because I know it can handle this sort of thing. Better CLI supports and low level customized version of remix. So remix is great and I like the way it's configured. But I think yet we could have yet another lower level oriented version that I think expresses what's changing in execution over time with better gas metering and so forth. So, and then the big thing as well, types, types, basic custom types and memory pointer types, which is what we're gonna discuss next. So that's the roadmap. So now for a special reveal of some stuff that we're working on here at Fuel Labs and we think will be a game changer and I'll try to present it in four minutes. Here we go. So using our UL Plus tech and our low level code, we were able to roll up ENS. So we now have a version of an ENS registrar and Nick Johnson knows all about this and we'll be releasing this soon. And basically it cuts the cost of ENS registration currently in half, but that will be even more as we get it more efficient. And as we kind of go further, it's a system that has got a lot of features. And this is sort of the usage of why UL and UL Plus and these lower level languages is so important. Because as Ethereum scales, as we go to 2.0, as we go to a world where we're in a more stateless environment using a lot less state rights, all of this becomes very, very critical. You won't be able to use state the same way. So you're gonna have to get creative. So Spark ENS, so what is it? Stateless, verifiable, and cheap ENS registrations. So basically we've knocked the cost of registering a name down at good gas prices to about 0.001 cents per name. So 10K gas. And right now we're sitting at about 45K gas per name. So this is pretty significant savings. And name registrations can be matched. Like I personally love like getting face to face time if you can call this that. But yeah, I don't think it's like the end of the world if... Oh, sorry, is someone talking? Sorry, whoever is talking. I would say this is the usual time right now. Yes, this is the usual time. Okay, Nick, I muted everybody and now you have to unmute yourself again. Great. And then it should work. Great. Okay, can you guys see me? Yes. Can you hear me? Okay, great. Still got it? Okay, great. So the way this works is using a sparse merkle tree and some kind of encoding. This is a... Well, you can get 16 characters in with compression but you lose certain names if you do that. It's EIP 712 compliant and it stayed optimized. So the entire thing, the entire contract it uses one state mod. So you're literally registering potentially millions of combinations of names and we're only doing one state write on Ethereum. So we believe that this kind of design is the way that Ethereum apps and EVM apps should work. We shouldn't be using millions of state writes on Ethereum, it's not sustainable. The way that the client manages state as we've seen is a huge bottleneck because of random access state memory. So this sort of state optimized design where you can have millions of E&S names being registered under a single state mod is sort of the way we think it should go. So here you can see we have our one S store that we use for the root and then you're deriving the names and a name is broken down by an encoding scheme to a specific number which is going to be your number of where this is included in the sparse merkle tree and then that's going to resolve to your name data. So this simple use of a sparse merkle tree to increase the efficiency of things like E&S will present massive value at I think as we move closer to scale and just making things a lot cheaper. I mean, instead of paying something like one cent per name or things like that on a bad gas day you're paying a lot less for that. And for people like wallet developers and stuff this is a pretty big deal. So I can go into this a little further but effectively looking at some of the sparse E&S contracts all this will be open source soon under Apache 2 and you'll just be able to really check it out. But here I'm using the enums you can see I'm using M slice you can see I'm using the SIG generator and you can see I'm using that M struct formation a specifier. So I'm really all these things that we're building into language we're really using all the time. Here's more M struct usage taking in the registration and doing the batch work and as well adding in safe math where necessary adding in these nice little multi M store bits of sugar and then doing the required statements and so forth. So instead of doing M store zero M store zero plus 32 M store zero whatever you know how M store is going to function so you can just do some nice quick sugar there and it just makes the notation so much easier we know what it's going to do. So considerations so I'll just try to wrap this up. So basically as we move into what we believe is a new era contract development which is stateless contract development or using one to two state rights for an entire system. So imagine you imagine a dex using only one to two state rights something like that. You know we basically you know we believe that scalability is going to be key. Designing for scalability is going to be key. Reducing S stores, reducing S loads and getting to a point where the execution is very clean it doesn't cost a lot and it can last a long time and be formally verified. So yeah stateless contracts woo and yeah our sparse E&S system should go up in about a week or so so you can get a demo and you can try it out on Rob's and Goorley. And you know I think that's really to set the bar and the reason why we're doing things like UL Plus and kind of focusing on that stuff. So if you want to use UL, UL Plus just save install UL P NPM. There's a UL Plus plugin which is awesome thanks to the D type team and UL Plus IDE which will build eventually into a lower level system GitHub, discussion, et cetera all the links are there I can post these slides somewhere. So I went a little over, I went three minutes over but yeah that's presentation, thank you. No worries and thank you so much especially for the info on the E&S stuff. You can stop sharing your screen now if you like and other than that are there any questions for Nick either and you can post your slides by the way on our Solidity Gita because we're using the Gita Chat to chat during the conference. So let's check in this room first. Any questions for Nick on UL Plus? For the newbies here you can use the raise your hand feature to raise your hand so that I can see that you want to say something. And let's also look into the Gita channel. So there was a discussion going on in the Gita channel about basically the problem that like while UL Plus is a nice project I'm a bit worried about promoting developers to write low level code. Some of the Solidity mitigations are going to be missing and people will make mistakes. In my honest opinion this should come with huge warnings like what happens if someone is unlucky and writes two functions that generate the same function ID with Solidity he is going to be safe but with UL I suppose there will be no warning. There was already a little discussion on that but I wanted to give you the chance to also comment. Yeah, so I think safety is a big reason why Solidity needs to exist and the development safety that comes with having a compiler focused on new developers coming to Ethereum and new developers coming to the ecosystem and I think that that's critical but the thing is as you start to build these more complex builds and as you start doing development that requires a lot of sensitivity to gas and op codes and exactly what you're doing. Yes, it takes expert or will consider to be I think expert knowledge to do. There's not a lot of places to go to and there's not a lot of places to find languages that will support you. We had Lisp for a while and things like that which offered some language like options for working with assembly but UL really stationed itself nicely as an intermediate ground and then UL Plus is a sort of addition to that that makes it more human to use. So I wouldn't say this is something to be promoted for general developers. I wouldn't say that at all. Well, we can add a lot of the same safety protections into the UL Plus compiler just because humans are humans and even I make autonomous takes as I'm building. I think this is more for people who wanna go a little deeper. They wanna be a little more sensitive. They might really have a deeper knowledge of the EVM and they just need something with more precision but they also don't wanna be dealing with the baggage of working with just UL that's more designed to build languages. At least it was intended by defaults to be that. So I think that's my justification for this and why I think it's important. And as well as Ethereum devs move to more stateless out designs they will need the sensitivity and the precision and that's where I think UL Plus will really shine. So we'll hope to get enough safety in there for even more general purpose people to use it or general purpose builds but right now it is really more specifically for scaling, stateless apps and sort of deeper EVM development. So that's my rant. So I think you're wrong but I also think you're right. Yeah. Okay, we're running a bit over time but I see that Justin might want to comment on this again. Okay. Yeah, can you hear me? Yes, we can. Okay, perfect. Yeah, thanks for the presentation. Yeah, like my point is that like UL and UL Plus like this is a great project and when you're going to use it like you know what you're doing and like from your expectation like only people with some expertise are going to use it but my point is that you should kind of also when you are promoting and presenting your work on UL Plus had some huge warning just to be sure that like the people that are going to look at you and UL Plus must understand that they need like some level of expertise to use this language. Yeah, I completely agree. I know that some people are going to you know like with your blog post or like with some publication and see oh UL Plus is great I'm going to reduce like the gas cost and everything and they might not understand that they need like this level of expertise. So it might be just a notion of having more like running or having more like promoting it with like this huge wet flag. You need to know what you are doing when you use UL Plus, doesn't make sense? Yeah, I completely agree. I think we can slap massive warnings on everything from a developer perspective so that they know that that's the case. Yeah, and even UL too in many areas says the same thing. So because it's not, it really is for more experienced people. I mean, and I wouldn't even, and just to wrap this up like when you're starting out even with coding you would recommend like a Python you wouldn't give them a C++ right away and say like, hey, you know, this is great. This does like everything you could ever want use this, you know? So I completely agree. Yeah. Okay.