Fluent: The First Blended Execution Network

GM GM. Welcome to what's going to be another great DevNTell. So if you didn't know, DevNTell is a 30-minute podcast for founders, hackers, and anything in between to come on the show and demonstrate what they've built to the Web3 community. This could be an awesome project you've started, a company you've started, a weekend hack, or anything in between that. And today I am ecstatic to have on the show Fluent co-founder Dino and DevRel Chris Mata. So if you didn't know, Fluent is the first blended execution network and Ethereum L2 and framework that blends WASM, EVM, and SVM-based smart contracts soon into an execution environment. If you stick around for today's show, you'll see Dino and Chris give us a comprehensive introduction to Fluent, highlighting its key advantages and why it's a game-changer for developers. All right, let's get into it.

GM GM. Welcome to the show Dino and Chris. Happy to have you on.

GM, good to be here.

GM, GM.

All right. Yeah, thank you so much for taking the time out of your days to come and teach us about Fluent. I guess before we get into the meat of the content, did you guys want to give a brief introduction about yourselves?

Sure. Yeah, I can I can kick that off. I'm Dino, one of the co-founders of Fluent and I got in the space quite a few years ago at this point. Always had a background in cloud infrastructure and developer tooling. And then got sucked right down like the modular and Ethereum and rollup rabbit holes. And that through a series of things led to Fluent.

Sure. Well, I'm a DevRel here on Fluent. I've been in the crypto space for about 4 years. And I was an indie hacker, you know, mostly participating in hackathons or doing proof of concepts for different protocols. And way before that, I was doing research in the academy. So that's how I entered the crypto space.

Awesome, awesome. And yeah, I always like to probe and probe into the origin stories here and I know you were you were briefly talking about it before we started the show, Dino. But I guess how how did you find yourself co-founding Fluent?

Yeah, so I was starting to get more and more involved in the space over the course of a few years and especially like I said before, in the modular infrastructure and rollup landscape. So I was doing some like hobbyist writing and researching on different protocols and getting more involved. And I actually at one point started Modular Media, which is a news outlet for modular infrastructure as it may sound. And it got to a point where I just knew I wanted to start a protocol or at least jump really early on to the start of a protocol. And so it was pretty serendipitous. One of my friends in the research community introduced me to my now co-founder, who was working at a different company at the time as their CTO, actually chief architect. And was running a bunch of like ZK experiments, so some ZK KYC stuff and a few other things which led to kind of the core idea of ZK WASM, which clearly found interesting enough to want to spin out. And so we actually met right as Zuzalu last year in Montenegro was kicking off. And so we spent two weeks there getting to know each other. Obviously like what better place to get to know the project than around some of like the smartest devs and researchers in the space.

And so we did that for a couple weeks, bonded over some nice food poisoning and here we are. Clearly it was a fit.

Oh no, food poisoning no good. But I mean, if it brought you closer together that was for a purpose. Yeah, that that's fantastic. Not the food poisoning, but the rest of the origin story itself.

And I guess Chris, how how did you find yourself at Fluent? Like what what gravitated you to join the team?

Sure. I think it was it was this year at ETHDenver 2024. So I was hacking, you know, with my team and doing Dev Tooling. And then I I found... while hacking and whatnot, it was it was a good hackathon and I won some prizes. And after that, I was like looking curiously about where to choose my path. So I was thinking on ZK was a a great topic for me. I was really, really interested in it. And then it was like, okay, it's it's okay to have ZK, but what what will be the next step? Like the correct abstraction and whatnot. And then I found WASM. So I was playing with WASM for a time. But then I found about Fluent. It was like, okay, this combines the two things that I really like, which was ZK and WASM. And then I met the team and I think we started we started from there. It was like a great fit and and then I'm here.

Awesome, awesome. And I think that's a great segue point to see exactly what excited you the most about Fluent and having the opportunity for you both to teach us about it. Um, so if you want, the stage is yours.

Yeah, sure. I mean, the first thing it was like they say we we can combine these different VMs. So for me it was like, okay, you say that you can combine different VMs, but it was like, how how you do it? Like is it you have one state virtual machine or you have multiple state virtual machines? And if you have that, how you can achieve interoperability? So I was like very, very curious about around it. So I think that was the first question that I asked when I met the team and then I found those those good solutions for those problems that I was thinking of. So and I was like okay, this is a great team, this is a great solution for things that I really want to to work on. And yep, that was it.

Awesome, awesome. Did you want to share your screen? Oh, yeah. Sure. Yeah, we can do that. Let me just share my screen here. 'Cause I know I know you guys prepared some great content for us.

And while Chris and Dino are going over that content, folks, if you have any questions for for the team there, please post them in the comments and we'll bring them up. And there you go. Yeah, floor is yours, Chris.

Okay cool. So well, this is the presentation that we made for DevNTell. So what we have if we combine SVM + EVM + WASM?

So if we combine all of those, then we got the first blended execution network. So what's this blended execution network? Well, Fluent is an L2 scaling solution. So it's designed to execute WASM-based applications.

So how it works? And that was my first question too, when when I came up with Fluent. So it is like you have a single execution environment or blended execution environment. So you can see this single execution environment is different VMs that we already know. You have SVM, we have Move, we have Sui, Cosmos. And those are isolated environments. So if you want to interact between those isolated environments, then you would need to come with different solutions to replicate state within those virtual machines, right? So what's new on what is this blended execution? Is let's imagine that you can have all these frameworks just in one place. And how is that done? So you will have you will need to have a base, a virtual machine. So how Fluent solves this is we have a WASM virtual machine. And on top of it, you can have any different virtual machines that you want to add. And how is this achieved? Well, you can compress the state changes using ZK proof. But we are just talking about in our general VM, the WASM VM. And we have a different version of WASM, it's called rWASM. And what why we have rWASM? is because we have different instruction sets that WASM have. But then it is reduced because there's some instruction sets that we don't use for deploying smart contracts. And this helps us keep the transaction schema that we will talk later on why this is important and why the the size of it is important. And the support for these environments is achieved through special system contracts known as compatibility contracts. And we envision these compatibility contracts to be community-based for support. So let's say for now we have the SVM, EVM, and WASM, but this doesn't mean that it's all of it. If the community wants, and of course we will show the path to do it, they can implement virtual machine for any type of languages that are compatible with WASM. So an example for future we can add support AssemblyScript, or we can support Go.

And yep. What's there for devs on Fluent? We will have a similar developer experience building EVM apps. This means that if you come from an EVM environment and you want to deploy your EVM app on Fluent, you will only need to change your RPC and everything will be okay. So that's awesome because we have a fully support for EVM. And you can build apps that weren't possible to build on EVM supported languages using Fluent-based Rust SDK. Example given, computation-heavy dApps. And what does this mean? I think a good analogy would be like, let's say if you code on on JavaScript, TypeScript, then you will use a lot of NPM packages, right? But so you know that you can reuse that that code and those some of those packages are audited, so it's good to implement those in your codebase if you need if you need them. So on Fluent, you can literally import any crate, any Rust crate that you have in, you know, in the package library. And the only tweak that we need for implementing those on Fluent would be that you need to... that crate need to have the no standard flag. This means that if it has the no standard flag then you can use it on Fluent. So that's really great 'cause then you have a bunch of Rust crates that you can really reuse on to your smart contract if you're trying to do math or you have to do cryptography or you're trying to do any different things that is already done. We are seeing a clear path for this on games. There's a lot of crates that implement some, I don't know, some game logic so you can just reuse them and then just import them in your smart contract. And what's cool is that all that computation will be proven in the ZK proof that Fluent posts on the L1. And of course, you can have blended apps.

So how WASM smart contract is deployed? I think this is a is a good question because if I came here and say, 'Hey, you have an an framework where you can use SVM, EVM, or you can use WASM,' so I think the main question is, okay, if I have EVM, will I use MetaMask for deploying a smart contract or interacting with it? Or what tools I can use? Yeah. For Fluent, we we decided to use the current stack that Ethereum has. So you can use any framework that supports EVM to interact with Fluent. So you can use, you know, Ethers, you could use Foundry, you can use Ethers RS. And then deploy smart contracts or interact with it with get get methods or read methods. So let's talk about this. In Ethereum you have a transaction structure, you know, transaction object where you have these different fields like nonce, gasPrice, gasLimit, to, value, data text, and v r s that are ECDSA signature values when you try to, you know, for a transaction. This v is the recovery ID in order to prove that a public key is linked to that signature. And r s are different values that you get when for doing that that signature. And in the Fluent transaction structure, you will have the same, but what changes is and then in the data, you will put the WASM binary, the hex of the WASM binary, and that WASM binary is our .wasm compiled file. And that that's it. You do that with the same structure, you only change the data field and then all will happen in the backend and your WASM smart contract will be deployed.

So why we need blended apps? I think Dino can answer this better than me.

Yeah, let me I can I can jump in here. Um, and and I'll actually want to take a couple steps back into why we need blended execution um as as a whole, right? And then I'll tie that into blended apps. So um as Chris was walking through before, right, like the status quo are these what we call like single execution environments where, you know, that could be EVM. I mean, for the most part right now, today, it is the EVM. Um, but that could also be some of these other um VMs, which which are better, right? Like a lot of people are improving upon the EVM in terms of technical features, be it um, you know, implementing like formal verification or paralyzing things. I mean, some people are creating different versions of the EVM that can paralyze that. Um, but there's so there's a lot of innovation happening, but the core thing is like you still have to make different tradeoffs. And and honestly, that that's started to like fracture, you know, a lot of this state. And like some of that's inevitable, right, because like there are certainly need like there's valid need to have different execution environments and customize them. But like sometimes it's not super necessary when you do um just want your one execution environment to have like features from these different VMs, right? So so what do you do? And um over the past, you know, year or so, I think um a lot of people have tried to solve this problem with like a multi-VM approach, but to us that's just not the right way to solve it um because it's a little bit like um you know, you kind of get a to some degree a Frankensteinish experience. I mean, some of them are much better than others, but like you're still fundamentally taking two VMs and putting them into the same execution environment. And like there's usually there's two different states and you're like trying to make them interoperate as best as humanly possible, but like there's going to be some implications either from a Dev experience perspective or at best um, you know, if the Dev experience is fine, um you're definitely going to have implications from a like ZK proving perspective, like an efficiency perspective and cost perspective.

So we kind of came along and said, hey, let's let's actually create this new type of VM using WASM as like a base um and just simulate the different VMs so you you only have to prove kind of like, you know, one bytecode at the end of the day and um and we found that that approach works a lot better. So the question is um all right, now that you have this, like why should you why should you care? How do we make it like more concrete for people, you know, what can you actually build in this environment? And that's where um you know, there there's a couple different reasons why it's it's interesting, right? Like even if you're just building a Solidity app or you're just building like a SVM Rust app, it's interesting um you know, to to have those apps sit in the same state machine. Like that's that is definitely interesting. You can have, you know, EVM apps, EVM whatever, historically EVM-based apps um use like SVM assets and so some cool things you could do there, which is which are obviously interesting. Um, but the most unique thing that blended execution enables is is um this notion of blended apps, right? So let's just say um, you know, for example, you might want to build a DEX in Rust because you just, you know, you either like Rust or you do or you there's certain libraries that you wanted to use um that just work better pulling Rust libraries off the shelf than like rewriting yourself. But so let's just say you, you know, you build a Rust DEX and you want to support ERC-20. Uh this blended execution environment uniquely enables that. Let's take the inverse. Let's say you actually want to build a DEX in in Solidity and maybe you start off by forking Uniswap, but you don't want to just have another copy-pasta app, so you want to differentiate it and you use, let's say, right now Rust libraries to differentiate it or you pull in some C++ libraries. Obviously, WASM is not limited to just Rust, that's just what we're currently supporting, so over time you can pull in any of the millions of, you know, dozens of languages or millions of um you know, software libraries that you don't have to write yourself. And so like that's those are just two like examples and it's kind of an easy way to think about like just like two of inverse of like the same example basically. Um, but there's there's a lot you can do, right? I mean, there's this one project uh that's building a um a game on Fluent and that in and of itself is a is a blended app, right? But the even more interesting thing is like that game also serves as a primitive for other games to be composed on top um in either Rust or Solidity and uh, you know, or Rust and Solidity. And so you can see this like composability space kind of blow open um in a good way with blended execution and these blended apps.

So um what what kind of apps are we looking to to create? Um yep, you go Dino.

Um sure, yeah, so like I touched on a couple examples before um but I I think and I think it kind of spans the gamut. Like this isn't like a vertical-specific thing um like obviously isn't a language-specific thing, um but we are we are seeing like a couple different um you know, I'll say like the the ecosystem is starting to like blossom in some areas like more than others. Like I think a lot of folks in the gaming community have have really gravitated towards um blended apps. I mean, a lot of these folks are um just like in it's kind of have an inherent understanding of like using the best tool for different parts of an app, right? Like a lot of these like other world builders, they're like system world game builders and um they kind of get there. They're used to operating in like performance-constrained environments and already know and love Rust. So that's like been a nice kind of early product market fit. Um, and then I think over time what what gets really interesting is, you know, as we add more languages and kind of people can um pull in software libraries that are commonly used in Web2 um you know, Web app just Web applications today, I think that becomes uh even more interesting and, you know, as we add more languages it becomes more and more accessible to more developers too.

I totally agree with this. I think um developers should be able to have the correct tool for the things that they want to solve, right? So and I think it's all possible on Fluent, not because um the abstraction that we have, but because the interoperability almost native that we can achieve through these VMs. And that that's what I think it differentiates us for different other approaches. 'Cause, you know, if you only keep adding on top of your VM then your other VMs, you you will have a significant overhead. But here since, you know, all compiled to WASM bytecode um then you don't have that much overhead. I would say almost none.

Um so what's next? Um well guys, um how you can visit our docs and you can visit our CLI tool and just we will talk about this in the transaction schema, so you know those those parameters that you need to change. This parameters are all done by the GBlend tool, so it will be cool if you all are already a Rust developer, you will only um install the GBlend tool through cargo and then just execute the gblend command and then you will have this um this CLI. And you will choose if you want to play on Fluent with Hardhat um or on with Rust, then you can spin up your first crate.

Um yep, and that was it. Um reach out to jam more if you have any any idea or you you say, 'Hey, I might want to do this on Fluent,' feel free to reach out to me so we can discuss it and we will try to help you to get your idea down.

Awesome. Yeah, that that was great, guys. I guess um you touched on it briefly, um but what would you recommend is the best way for folks to start um building with Fluent? Is there like a hello world type of thing you would recommend or um any sample code people can pull?

Yeah sure. Um we have different examples. So we will have for we have a composable hello world, and it's the easiest example if you trying to play with blended execution. So you will have a Solidity smart contract that will output 'hello' and then you'll have the Rust smart contract that will put the 'world' and then you have the hello world. Well, but um I I really think that if you want to play then you can use more complex examples that we have um on our docs and that will be um importing a Rust crate directly into your smart contract and then use it with your Solidity smart contract. So then you can have the whole experience and then you can say, 'Hey, that makes sense 'cause I can literally import any library uh from crates.io into my smart contract, so then you can you have infinite possible you have a bunch of possibilities to do within your smart contract.' So I think that that would be the best example, if you ask me.

Perfect, perfect. And we'll have the links um to the docs in provided in the YouTube description, so definitely you want to check that out. And I guess kind of uh kind of to build on that, like what's what's the craziest thing you've seen somebody build? Like I know you touched on like DEXes and and games, but like is there something it was like, oh wow, I didn't even think like that would have been possible before Fluent existed?

Um, I think I think the gaming example is probably my answer. Like when you start to kind of extrapolate and see like how composable and how, you know, how composable those experiences can get when you have like Rust and Solidity things that are being built on by Rust and Solidity devs in Rust and Solidity. Like and you're just like, 'What the hell?' And then that's only with the first like two languages and environments that we're supporting. And so like then when you kind of sprinkle in um we will support SVM for our testnet, uh sometime in Q1. And then when you like you can take in some SVM assets and SVM Rust and the composability space just explodes in a I think a really fascinating way. And so I'm excited to see um more experimentation there. One area of experimentation I'm pretty excited for is um I'll say like multiple leveraging multiple different gaming frameworks, like from different ecosystems, um because they're each kind of tailored towards different things like MUD is good for this and um I think that'll be really cool. And we actually haven't seen that done yet, but uh we've been we've been kind of ideating on it. And and yeah, I don't know Chris, maybe you have different answers.

No, for me it was the same. I think it was um in the gaming side. So you know, um if you if you want to develop a game, then you have this question: what should be on-chain and what should be off-chain and and if it is off-chain, how I can prove that that execution was correct? So and then I found this demo demo app for um it was a chess, yeah, it was a chess game. So and then you have, you know, um if you play the game then you have all the pieces randomly uh in a position and then you need to to solve um that match. So for me it was, is this all happening on-chain? And it was happening on-chain. So for me it was like, okay, this is a great, great product. So yeah, I think it was that way. Like having things that you were impossible to have on-chain now for me it's like a game-changer.

Excellent. Yeah, sounds like it. And um I guess a little bit if you can, like what's what's coming up on the Fluent roadmap? I know we have a question from the crowd asking if Move is on the radar for Fluent, but um is there anything you can share in particular?

Yeah, so let me I'll I'll unpack how we're thinking about different environments. So right now what's live on our Devnet is kind of WASM and EVM. Um and so uh you can, you know, deploy apps in Rust and you can deploy apps in Solidity and you can deploy these blended apps. Um as I started to talk about before, we're going to support SVM next. And that should be um good to go by our by our testnet, hopefully a little bit before, but that's part of our testnet like design goals um in Q1. And um we've run some other experiments and uh one of those is Fuel VM. So this has only been a proof of concept so far, but we have been able to get like Sway apps working and have them able to, you know, compose with other languages easily as well. Um and then we have obviously Move is top of mind. Like I think, you know, Movement has done a really good job like getting attention and momentum around the Move language. Um but it's as far as we're a startup and we need to focus kind of thing, like I don't know if we're going to jump towards Move. One thing that's cool about the um so to answer the question directly, like it is not on our roadmap right now. We could do it. We've experimented and researched it a little bit and it should be possible. Like one thing about the current blended execution approach is we've taken care of EVM and SVM, which like couldn't be more different. And so like from that point forward adding different environments ends up being, you know, easier and easier if they fall like within that spectrum. Um anyway, it's it's doable. We think it could be interesting but not the focus right now.

Fair enough, fair enough. And I guess are there opportunities for developers to contribute uh to perhaps any open-source opportunities um at Fluent? Like to help building it out or adding uh more support for other uh virtual environments?

Yeah, let me I I got some quick thoughts and then then Chris, maybe you can add on to it. Um so yes, the idea for this Fuel VM proof of concept, which we've been working with like the Fuel team on. Um but it's early days for our codebase, right? So like we have been doing most of most of that work. But the reason we're doing it is to just show like a path for um the community and other ecosystems to to add more environments themselves. And so um you know, as the codebase like matures, uh we do want to get to a point where that's almost um permissionless for people to just like deploy their own compatibility contracts as Chris was saying earlier in the presentation. Um and then there's another way that people can contribute over time is adding new languages uh so like adding SDKs for new languages in the like core WASM VM. And uh I'm certainly excited to see, you know, what more people are interested in building. I mean, we focused on Rust to start, um that was just like the most clear demand. Um but I but I think that uh we've started to hear other people talk about adding like C++ libraries. I haven't really heard of like people wanting to add uh or like write their contracts in in C, but like definitely pulling in Rust libraries and C is interesting. Um and I don't know, Chris, maybe you have different perspectives there.

Oh yeah, if devs want to contribute um as for now you can contribute to, you know, the GBlend tool I'll say, it's open for contributions and if you're talking about the Fluent base common... the main codebase, we currently do not have any open issues 'cause, you know, since it's rapid evolving and whatnot, it's hard to keep track for us, but it's definitely something that we will um came um soon. Then we'll have good first issues, enhancements, um and whatever type of issue that we think like, hey, at the end we really want people to play with our codebase and as Dino said, we see this as people if they want to add support for another language they have all the tools for doing that. Um yeah, so yeah. We will open uh contributions soon.

Awesome. Yeah, love to hear that. And I uh we're coming up on time and I guess um I'm also looking forward to seeing people play with Fluent too. Uh you guys have um created something pretty awesome and opened up a whole whole new uh sea of opportunities for folks to build things that probably weren't possible before. Um so really looking forward to seeing folks um dabbling with that. Um and if they do if those folks do have questions, um is there a Discord or some sort of community they can reach out for support if they need it?

Yeah, there's Discord is always open. Uh we have if you really want to do something on Fluent then we have um these Telegram chats that it's we we post there support if you have any question, you know, your person will be um answered very quickly. But of course if not, um you can just go to the Discord, open a ticket and we will be there helping you with the deployment process or any other that you have.

Or just honestly if you're out there and you're looking to build a a blended app and you have some cool idea, you know, a cool idea for some some novel thing that wasn't possible on other chains, just DM me, man. I'll take care of you.

This is the way, this is the way. And uh yeah, we've shared uh Dino and Chris's um X accounts on the YouTube description and tagged them on X so you know how to reach out. Um and with that, just want to thank you both so much for coming on the show today. Um this was uh excellent and really appreciate you guys taking the time to teach us all about Fluent. And I'm really excited to see folks um start to continue to build and see all the wacky cool apps uh people come up with.

Thanks for having us. It was fun.

Thanks for having us, Narb.

My pleasure, anytime. Um all right gang, I guess with that, I want to wish everybody a very happy Friday, happy weekend wherever you may be and that we'll catch you back here next week for more DevNTell. Right on, have a good one.

Cheers.

Bye.