An introduction to the concept of Fluence Cloudless Compute and its relevance to the ETH Denver event, with a focus on decentralization and trust issues in cloud computing.

Introduction to Fluence Cloudless Compute

Exploration of Fluence's approach to solving cloud computing problems through decentralized serverless compute, decentralized physical infrastructure, and a decentralized compute marketplace.

Decentralized Serverless Compute

Discussion on the verifiability and use cases of Fluence Cloudless Compute, particularly in the context of verifiable data preparation networks, real-time data pipelines, and decentralized RPC solutions.

Verifiable Data Preparation Networks

Insight into the protocol behavior and implementation of Fluence Cloudless Compute, including off-chain compute, reference peer, Rust implementation, Aqua VM pool, and scheduler.

Protocol Behavior and Implementation

Explanation of the dynamics between providers and the marketplace in Fluence Cloudless Compute, including capacity commitments, offers, and deal creation for deployment and execution of functions.

Provider and Marketplace Dynamics

Details on the cloudless serverless compute tracks for the ETH Denver event, including the bounty structure, integration options, and varying levels of complexity.

Cloudless Serverless Compute Tracks

Introduction to the challenge of improving DAP with FRPC, addressing the issues of RPC as a service, single points of failure, and privacy concerns through Fluence's Cloudless Compute.

Improving DAP with FRPC

Discussion on integrating Ceramic, Ceramic Stream, or Composed DB into Fluence Cloudless Compute, as well as the use of EIP 4844 for intermittent state persistence.

Integration with Ceramic and EIP 4844

Explanation of the development options for library and enabling projects, including multi-party TSS crate, ECDSA, and porting the Halo 2 crate to marine WebAssembly.

Library and Enabling Development Options

Overview of the development experience for Cloudless functions and their architecture, including the setup, peer discovery, deployment, and Aqua bindings for WebAssembly files.

Experience of Developing Apps for Fluence

- Bernhard and Alex A. from Fluence discuss the Fluence Cloudless Compute and its use in the ETH Denver hackathon
- They believe the traditional cloud is broken and aim to solve this with decentralized serverless compute and physical infrastructure
- Use cases for Fluence Cloudless Compute include verifiable data preparation networks, real-time data pipelines, and decentralized RPC solutions
- The implementation includes a protocol carried out by a reference peer, Rust implementation called Knox, a marine pool, Aqua VM pool, and a scheduler
- Providers offer capacity commitments to the Fluence blockchain, and the marketplace matches offers from developers and providers
- The hackathon offers 5 cloudless serverless compute tracks for a total of 25,000 USD in prizes
- The tracks range from creating and deploying a Cloudless function to integrating Fluent Cloudless with other projects and implementing specific features like persistence and cryptographic algorithms
- Alex will discuss the experience of developing apps for Fluence, focusing on Cloudless functions and their architecture, which resembles serverless architectures like AWS Lambda

- The Cloudless functions are written in Rust and accessible through a peer-to-peer network
- The HTTP gateway consists of an HTTP server, Cloudless functions, and a FluentJS client
- To start developing a Fluent CLI project, you can use Fluent init or Fluence in it
- Peer discovery in Fluence works based on participants stored on the chain
- Fluence manages the topology and overlay network, allowing developers to focus on building functions
- There is a longer workshop on the 27th for those interested in learning more about Fluence

- The Fluency YAML specifies the development configuration
- It uses a service with a compute function and specifies the price
- The project and config are shown
- It can be deployed to the chain and will work

Fluence Cloudless Compute, developed by Bernhard and Alex A., aims to revolutionize traditional cloud computing through decentralized serverless compute and physical infrastructure. Use cases include verifiable data networks, real-time data pipelines, and decentralized RPC solutions. The implementation involves a protocol, Rust implementation called Knox, a marine pool, Aqua VM pool, and a scheduler. Providers offer capacity commitments to the Fluence blockchain, and the hackathon offers 5 cloudless serverless compute tracks with a total of 25,000 USD in prizes. Alex will discuss developing apps for Fluence, focusing on Cloudless functions and their architecture, which resembles serverless architectures like AWS Lambda. Peer discovery in Fluence is based on participants stored on the chain, and Fluence manages the topology and overlay network. There is a longer workshop on the 27th for those interested in learning more about Fluence. The Fluency YAML specifies the development configuration and can be deployed to the chain.

Learn how to use decentralized serverlesss compute with Fluence Functions to create new or support existing decentralized applications and protocols. Join us to discover how to improve your dAPP with fRPC, a decentralized RPC substrate created with Fluence Functions and executing on HA DePin.

APPLICATIONS FOR ETHDenver 2024: #YearOfTheSpork ARE OPEN


APPLY NOW
https://ethdenver.com/apply

Hello everybody, welcome to ETH Denver 24.

It's always a good time, February, starting out ETH Denver.

We're both with Fluence, and we're here to introduce or discuss Fluence Cloudless Compute with Fluence in general, and of course, how it pertains to unlocking 25,000 USD through the hackathon.

So we at Fluence believe that the cloud as we know it is broken.

It's controlled by oligopolists that seek excessive rents that want your trust but at the same time don't give it.

They have high exit barriers, technology lock-in, de-platforming approaches and more.

The way Fluence attempts to solve this problem is through a set of protocols where we have decentralized serverless compute, we have decentralized physical infrastructure, and we have a decentralized compute marketplace that matches compute capacity from independent data center operator participating in the deep end structure with developers requests and desire for capacity to run the serverless compute and influence everything being decentralized we verify we don't trust.

So from a use case perspective obviously it's serverless so you can do whatever you want with any other serverless.

However, due to the proof-based cryptographic system underlying the Fluence Cloudless Compute, verifiability at the runtime and execution layer is actually paramount and lends itself to some really interesting use cases, particularly around verifiable data preparation networks, real-time data pipelines, decentralized RPC solutions, and whatever you can imagine in your trustless mind.

On the verifiable data side it's interesting because as AI is getting increasingly regulated and you you want provenance from data through data preparation to data lakes to AI models Fluent serverless can really help you significantly more than any other of the traditional cloud providers can From an implementation perspective.

We don't have time to dig into all the protocol aspects, but the behavior of the protocol Which is off-chain compute is actually carried out by what we call a reference peer.

And it has a marine pool, which is a generalized web assembly runtime developed by Fluence, and an Aqua VM pool, which actually handles your distributed choreography of your functions.

And on top of it, you have a scheduler, basically ground jobs, that allows you to manage your event triggers.

And from the network perspective, it's truly deep in bottom up.

We have large data centers, mostly Filecoin miners right now, that provide significant capacity to the network, for which they get paid if they're just providing capacity through a proof of capacity and or executing your functions for payment from the developer side.

You end up with Marine Services, which is WebAssembly.

And then you package your availability requirements.

This is how you can build, through our distributed choreography engine, your own failover and high availability solution.

Provider specifications, do you want to only operate with or work with green data centers, do you have geo preferences, and of course the willingness to pay for your services.

On the other side you have the providers which they have their servers, they have peers which we just saw these Nox's and then, spelling, we sliced capacity into what we call compute units, which actually are cores, for the most part, two-threaded cores, And I think right now for 4 gigabyte of RAM per CU allocation, which is what will run your functions.

Providers give these capacity commitments to the chain.

And the chain is actually, it's Fluence's own blockchain built on IPC, Interplanetary Consensus Blockchain, from Protocol Labs.

And they also provide their offers, where they say, hey, this is what we offer.

This is our green status, our carbon footprint, what developer attributes these are, these services we can provide or we want to provide, and how much we actually need to pay or accept.

And then the marketplace, which is on-chain, matches those offers from developers and providers and then you create a deal which then leads to Deployment and the execution or the availability of your functions to be executed Okay, I only got 5 minutes left to get to the bounty So let me go through this quickly, because Alexei is going to dive into some of the aspects a little bit deeper.

We're going to have 5 cloudless serverless compute tracks for a total of 25,000.

And hackers should be cognizant that A, you can provide or submit to more than 1 track.

And you can actually integrate our challenges, if you will, our bounty tracks into any of your other hackathon projects over the week.

So the first 1, and it goes from easy to a little bit harder along the way.

The first 1 is basically just hit the documentation, hit some of the videos, and create, and deploy, and execute a Cloudless function.

And for that, we have 5 times a USDC 1,000.

So as most of you are aware, RPC is a sticky subject in the community.

On the 1 hand, it's almost impossible for most app operators to run their own failover nodes.

So you end up with RPC as a service, which is very, very available and very, very cheap.

And what we've done is we built on Fluent's Cloudless Compute, we built a substrate for you to basically orchestrate multiple RPC endpoints, service endpoints, and Fiora, Alchemy, many of them, into a decentralized solution to eliminate the major sticking points which I just mentioned including a single point of failure all this good stuff.

You work on that we have that substrate ready and the substrate consists of multiple components including some Fluent's cloudless functions but also some pretty interesting distributed algorithms on how you manage the workflow, the choreography of these services.

Anyway, you manage to do this, you implement it and use it in your DAP, and you're in the running 4 or 5 times 1,000 UCC.

Fluent Cloudless is stateless, fundamentally.

So if you want persistence-particular data, you need to add that on your own and 1 of the more interesting projects is ceramic and if you integrate ceramic ceramic stream or composed DB Into your clue influence cloudless You're in the running for again 5,000, 2,500, 1,500, 1,000 each.

Now this is my pet project and I hope we're going to get a lot of participation in that 1.

With EIP 4844 it's interesting that you can use this blob as a sort of intermittent, or intermediate, if you will, state persistent option.

And anybody who wants to indulge me and use that in their hackathon project, go ahead.

Again, you're in the running for 5,000 years to see 2,500 1,500 in the thousand the last 1 is a little bit more involved and is more on the Library and abling side we give you 2 options an NPC options in the CK option on The NPC option basically we want you to do is part a multi-party TSS crate, ECDSA, yeah, and demonstrate its use through orchestration with our orchestration language, which is Aqua.

On the CK side, port the Halo 2 crate, which already is close to WebAssembly, to marine WebAssembly, and demonstrate it's used by proving hamming distances.

The CK option is actually fairly, it's not as complicated as it seems, since the circuit is, I give you examples for that in the repo, is already has been written.

So you literally can copy that circuit and demonstrate this.

So it's all about how to use it from Fluence as opposed to how to write the circuit.

We're going to go through the experience of developing apps for Fluence.

And today, we're going to focus on Cloudless functions and their architecture.

You may already kind of know it, because it resembles a lot of serverless architectures out there, for example, AWS Lambda.

You have compute functions on the right, they're usually written in Rust, they're accessible from the peer-to-peer network and we have an HTTP gateway which is complex a little bit and it can call those compute functions and can serve HTTP API so HTTP client can call it.

If we look a little bit deeper, then what happened?

So the Cloudless functions are usually written, the compute functions are usually written in Rust and are accessible through the peer-to-peer network.

So if we look inside the HTTP gateway, We will see that it actually consists of several components.

Obviously, it consists of simple HTTP server, and it has a cloudless function inside, which you could also call distributed workflow.

And we have a FluentJS client that lets you send those Cloudless functions to the peer-to-peer network.

And the Cloudless function itself specifies the peer discovery mechanism to discover peers that host certain compute functions.

So in order to start developing Fluent CLI project, you will need to set up Fluent CLI project.

1 easy way to do just Fluent init Here on the right, on the left in your case, on the down, the interactive wizard will guide you through all the steps.

You will have to select the quick start or whatever, and just follow the instructions.

Or if you're proficient enough with Fluence, you could do Fluence in it with all the things specified.

So it will create a quick start project with the following structure.

The most important things it contains are Cloudless functions in the ACO directory, the HTTP gateway, which calls those Cloudless functions.

It contains compute functions definitions written in Rust.

And it contains configuration files which configure your deployment.

And if you're using local development environment, which we recommend you to do, then you will also configure it in provider.yaml.

So let's see it in action, but I guess not today.

So what it does, so under the hood of what happens in Fluence, you will find peer discovery.

It works based on the fact that deal participants are stored on chain, so whenever you deploy something to the network, it actually finds, the process looks like that.

So whenever, at first you have deployment in your Fluence.yaml, you configure different stuff like how many, what's the replication factor, that's target workers, that's how many peers will be chosen to deploy this function to, how much you would like to pay for a certain period of time for this function to be hosted and available, what's the initial balance of the deal, that means how long it will live until you have to put more money on it, and what services, what compute functions it includes.

Once you have that, you run Fluent Deploy, and you get cloudless distributive uploaded to IPFS or to IPC.

Effectively, you get CID back, which is sent to the chain, which creates a developer offer, which is then matched on chain Through through the market deals are matched with providers so providers specify their prices available APIs and stuff developers specifies desire desired price desired APIs and stuff, and market matches it all.

And as a result, you receive an active deal.

Deal is active once It has enough balance to go on to burn through the money to pay to providers.

And once providers signal to the chain that they are ready to serve that function.

So based on that information on chain, The peer discovery mechanism works by querying that information from chain and going and Returning that information back to aqua, which is your distributed workflow it iterates through the peers in the subnet in the deal and is able to call the function on each of them, collect the answers and present it to user or let it do whatever it wants to do, modify data process and stuff.

And the last thing of the puzzle is how Aqua knows the functions API.

Because Aqua is a type-safe language, so it doesn't let you do silly mistakes.

It does, though, let you do clever mistakes.

But So what we do, we take a WebAssembly file that we generate by compiling Rust code.

We look at its interface types that we insert there, and we generate aqua bindings for it so that whenever the Cloudless function, the distributed workflow, finds the right peers and goes to them, it actually knows the types it should pass and can validate that stuff.

Or if some data is wrong, it will alert the user.

And what resources are in your presentation?

Thanks Okay, so a lot of things Alex H is covered are actually things you as a developer don't have to take care of This is all taken care of for you by both the CLI which is our Matt it's a magic, but it's it's it's your your way to scaffold and manage your project, and by the various components including marine and particularly aqua.

So aqua manages the topology, so you don't have to program at the P2P level at all.

And 1 of the interesting parts that comes from those deals Alexei was talking about, basically those deals when they're done, where you match providers with developers, their requirements, as well as the resource, the peers, you actually get something what we call a subnet, which actually is an overlay network on the libp2p network that is managed through the configuration of your Aqua.

So again you don't have to chase down any of that.

So you can really focus on building your function and choreographing them into these cloudless applications you probably want to end up with.

Now, I know this was really short, 20 minutes.

So we have a much longer workshop on the 27th.

And you'll just have to check our channels including the discord which is fluent start chat or our Twitter which is a twitter.com slash fluence underscore project For more details, but if you're interested definitely come to that workshop If you have questions in between now and then hit us up on discord or track us down in the building and we're happy to help.

We obviously want you to take home that money.

Those USDC, that's our entire purpose of being here, for you to succeed.

So if you want to take advantage of it, we're certainly up for it.

Yeah, so just quick, I have like 30 seconds or something.

It can access external resources through HTTP or whatever.

Here is what your Fluency YAML looks, where you configure the development.

And here you can see that it specifies that it uses the service that contains this compute function and specifies the price, all that, and we can deploy it to the chain and it will work.

That's how the project looks, that's how config looks, this is it.


Speaker 0: Hello everybody, welcome to ETH Denver 24. Great to see you, great to be here. It's always a good time, February, starting out ETH Denver. Ritual obviously. And I'm Bernhard and this is Alex A.

We're both with Fluence, and we're here to introduce or discuss Fluence Cloudless Compute with Fluence in general, and of course, how it pertains to unlocking 25,000 USD through the hackathon. So we at Fluence believe that the cloud as we know it is broken. It's controlled by oligopolists that seek excessive rents that want your trust but at the same time don't give it. They have high exit barriers, technology lock-in, de-platforming approaches and more. The way Fluence attempts to solve this problem is through a set of protocols where we have decentralized serverless compute, we have decentralized physical infrastructure, and we have a decentralized compute marketplace that matches compute capacity from independent data center operator participating in the deep end structure with developers requests and desire for capacity to run the serverless compute and influence everything being decentralized we verify we don't trust.

So from a use case perspective obviously it's serverless so you can do whatever you want with any other serverless. However, due to the proof-based cryptographic system underlying the Fluence Cloudless Compute, verifiability at the runtime and execution layer is actually paramount and lends itself to some really interesting use cases, particularly around verifiable data preparation networks, real-time data pipelines, decentralized RPC solutions, and whatever you can imagine in your trustless mind. On the verifiable data side it's interesting because as AI is getting increasingly regulated and you you want provenance from data through data preparation to data lakes to AI models Fluent serverless can really help you significantly more than any other of the traditional cloud providers can From an implementation perspective. We don't have time to dig into all the protocol aspects, but the behavior of the protocol Which is off-chain compute is actually carried out by what we call a reference peer. It's a Rust implementation called Knox.

And it's built on libp2p. And it has a marine pool, which is a generalized web assembly runtime developed by Fluence, and an Aqua VM pool, which actually handles your distributed choreography of your functions. And on top of it, you have a scheduler, basically ground jobs, that allows you to manage your event triggers. And from the network perspective, it's truly deep in bottom up. We have large data centers, mostly Filecoin miners right now, that provide significant capacity to the network, for which they get paid if they're just providing capacity through a proof of capacity and or executing your functions for payment from the developer side.

How do you create these functions? How do you go about it? You basically have your business logic. You code them in Rust. You end up with Marine Services, which is WebAssembly.

And then you package your availability requirements. Do I want 1 invocation? Do I want 1 instance of my function? Do I want 3? This is how you can build, through our distributed choreography engine, your own failover and high availability solution.

Provider specifications, do you want to only operate with or work with green data centers, do you have geo preferences, and of course the willingness to pay for your services. On the other side you have the providers which they have their servers, they have peers which we just saw these Nox's and then, spelling, we sliced capacity into what we call compute units, which actually are cores, for the most part, two-threaded cores, And I think right now for 4 gigabyte of RAM per CU allocation, which is what will run your functions. Providers give these capacity commitments to the chain. And the chain is actually, it's Fluence's own blockchain built on IPC, Interplanetary Consensus Blockchain, from Protocol Labs. And they also provide their offers, where they say, hey, this is what we offer.

This is the kind of CPUs. This is the kind of RAM. This is our location. This is our green status, our carbon footprint, what developer attributes these are, these services we can provide or we want to provide, and how much we actually need to pay or accept. And that gives an offer.

And then the marketplace, which is on-chain, matches those offers from developers and providers and then you create a deal which then leads to Deployment and the execution or the availability of your functions to be executed Okay, I only got 5 minutes left to get to the bounty So let me go through this quickly, because Alexei is going to dive into some of the aspects a little bit deeper. We're going to have 5 cloudless serverless compute tracks for a total of 25,000. We have 5,000 for each track. And hackers should be cognizant that A, you can provide or submit to more than 1 track. And you can actually integrate our challenges, if you will, our bounty tracks into any of your other hackathon projects over the week.

So the first 1, and it goes from easy to a little bit harder along the way. The first 1 is basically just hit the documentation, hit some of the videos, and create, and deploy, and execute a Cloudless function. And that's basically it. And for that, we have 5 times a USDC 1,000. Improve your DAP with FRPC.

So as most of you are aware, RPC is a sticky subject in the community. On the 1 hand, it's almost impossible for most app operators to run their own failover nodes. So you end up with RPC as a service, which is very, very available and very, very cheap. However, it has problems. It has single points of failure issues.

It has privacy issues. It had data trust issues. And multiple solutions have emerged. And what we've done is we built on Fluent's Cloudless Compute, we built a substrate for you to basically orchestrate multiple RPC endpoints, service endpoints, and Fiora, Alchemy, many of them, into a decentralized solution to eliminate the major sticking points which I just mentioned including a single point of failure all this good stuff. You work on that we have that substrate ready and the substrate consists of multiple components including some Fluent's cloudless functions but also some pretty interesting distributed algorithms on how you manage the workflow, the choreography of these services.

Anyway, you manage to do this, you implement it and use it in your DAP, and you're in the running 4 or 5 times 1,000 UCC. Fluent Cloudless is stateless, fundamentally. So if you want persistence-particular data, you need to add that on your own and 1 of the more interesting projects is ceramic and if you integrate ceramic ceramic stream or composed DB Into your clue influence cloudless You're in the running for again 5,000, 2,500, 1,500, 1,000 each. Now this is my pet project and I hope we're going to get a lot of participation in that 1. With EIP 4844 it's interesting that you can use this blob as a sort of intermittent, or intermediate, if you will, state persistent option.

And anybody who wants to indulge me and use that in their hackathon project, go ahead. Again, you're in the running for 5,000 years to see 2,500 1,500 in the thousand the last 1 is a little bit more involved and is more on the Library and abling side we give you 2 options an NPC options in the CK option on The NPC option basically we want you to do is part a multi-party TSS crate, ECDSA, yeah, and demonstrate its use through orchestration with our orchestration language, which is Aqua. On the CK side, port the Halo 2 crate, which already is close to WebAssembly, to marine WebAssembly, and demonstrate it's used by proving hamming distances. The CK option is actually fairly, it's not as complicated as it seems, since the circuit is, I give you examples for that in the repo, is already has been written. So you literally can copy that circuit and demonstrate this.

So it's all about how to use it from Fluence as opposed to how to write the circuit. Again 5,000, 2,500, 1,500, 1,000. And that's it for me. So Alexei will take over. Thanks.

Speaker 1: Thank you, Berner. Hello, all. I'm Alex. We're going to go through the experience of developing apps for Fluence. And today, we're going to focus on Cloudless functions and their architecture.

You may already kind of know it, because it resembles a lot of serverless architectures out there, for example, AWS Lambda. So it's pretty simple. You have compute functions on the right, they're usually written in Rust, they're accessible from the peer-to-peer network and we have an HTTP gateway which is complex a little bit and it can call those compute functions and can serve HTTP API so HTTP client can call it. If we look a little bit deeper, then what happened? My laptop hanged.

No. Oops. Okay. So, I'm gonna try to get it back. So, I'm gonna try to my laptop hang.

Service, service. No. Oops, sorry. I have no idea. Sorry.

I have no idea. Yeah, thanks. No, it's my laptop. It's not yours. So I guess there's going to be no demo.

So the Cloudless functions are usually written, the compute functions are usually written in Rust and are accessible through the peer-to-peer network. So if we look inside the HTTP gateway, We will see that it actually consists of several components. Obviously, it consists of simple HTTP server, and it has a cloudless function inside, which you could also call distributed workflow. It's written in Aqua language. And we have a FluentJS client that lets you send those Cloudless functions to the peer-to-peer network.

And the Cloudless function itself specifies the peer discovery mechanism to discover peers that host certain compute functions. So in order to start developing Fluent CLI project, you will need to set up Fluent CLI project. And there are 2 ways to do that. 1 easy way to do just Fluent init Here on the right, on the left in your case, on the down, the interactive wizard will guide you through all the steps. You will have to select the quick start or whatever, and just follow the instructions.

Or if you're proficient enough with Fluence, you could do Fluence in it with all the things specified. So it will create a quick start project with the following structure. The most important things it contains are Cloudless functions in the ACO directory, the HTTP gateway, which calls those Cloudless functions. It contains compute functions definitions written in Rust. And it contains configuration files which configure your deployment.

And if you're using local development environment, which we recommend you to do, then you will also configure it in provider.yaml. So let's see it in action, but I guess not today. So yeah. So what it does, so under the hood of what happens in Fluence, you will find peer discovery. It works based on the fact that deal participants are stored on chain, so whenever you deploy something to the network, it actually finds, the process looks like that.

So whenever, at first you have deployment in your Fluence.yaml, you configure different stuff like how many, what's the replication factor, that's target workers, that's how many peers will be chosen to deploy this function to, how much you would like to pay for a certain period of time for this function to be hosted and available, what's the initial balance of the deal, that means how long it will live until you have to put more money on it, and what services, what compute functions it includes. Once you have that, you run Fluent Deploy, and you get cloudless distributive uploaded to IPFS or to IPC. Effectively, you get CID back, which is sent to the chain, which creates a developer offer, which is then matched on chain Through through the market deals are matched with providers so providers specify their prices available APIs and stuff developers specifies desire desired price desired APIs and stuff, and market matches it all. And as a result, you receive an active deal. Deal is active once It has enough balance to go on to burn through the money to pay to providers.

And once providers signal to the chain that they are ready to serve that function. So based on that information on chain, The peer discovery mechanism works by querying that information from chain and going and Returning that information back to aqua, which is your distributed workflow it iterates through the peers in the subnet in the deal and is able to call the function on each of them, collect the answers and present it to user or let it do whatever it wants to do, modify data process and stuff. And the last thing of the puzzle is how Aqua knows the functions API. Because Aqua is a type-safe language, so it doesn't let you do silly mistakes. It does, though, let you do clever mistakes.

But So what we do, we take a WebAssembly file that we generate by compiling Rust code. We look at its interface types that we insert there, and we generate aqua bindings for it so that whenever the Cloudless function, the distributed workflow, finds the right peers and goes to them, it actually knows the types it should pass and can validate that stuff. So there are no errors. Or if some data is wrong, it will alert the user. And that's unfortunately it.

A little bit shorter. And what resources are in your presentation? Sure. Presentation shirt.

Speaker 0: Thanks Okay, so a lot of things Alex H is covered are actually things you as a developer don't have to take care of This is all taken care of for you by both the CLI which is our Matt it's a magic, but it's it's it's your your way to scaffold and manage your project, and by the various components including marine and particularly aqua. So aqua manages the topology, so you don't have to program at the P2P level at all. And 1 of the interesting parts that comes from those deals Alexei was talking about, basically those deals when they're done, where you match providers with developers, their requirements, as well as the resource, the peers, you actually get something what we call a subnet, which actually is an overlay network on the libp2p network that is managed through the configuration of your Aqua. So again you don't have to chase down any of that. The discovery is not inherent.

It's not intrinsic. But it's taken care of for you. So you can really focus on building your function and choreographing them into these cloudless applications you probably want to end up with. Now, I know this was really short, 20 minutes. It wasn't much time.

So we have a much longer workshop on the 27th. 60 to 90 minutes. Starts at 1. And you'll just have to check our channels including the discord which is fluent start chat or our Twitter which is a twitter.com slash fluence underscore project For more details, but if you're interested definitely come to that workshop If you have questions in between now and then hit us up on discord or track us down in the building and we're happy to help. We obviously want you to take home that money.

Those USDC, that's our entire purpose of being here, for you to succeed. So if you want to take advantage of it, we're certainly up for it. Okay, Alex has 1 more thing.

Speaker 1: Can you switch me, please? I hope it won't crash again. Yeah, so just quick, I have like 30 seconds or something. So this is how compute functions look. It's just Rust code, right?

And it can do whatever it wants. It can access external resources through HTTP or whatever. But here it just returns a string. Here is what your Fluency YAML looks, where you configure the development. And here you can see that it specifies that it uses the service that contains this compute function and specifies the price, all that, and we can deploy it to the chain and it will work.

That's how the project looks, that's how config looks, this is it.

See all ETHDenver transcripts on Youtube

Introduction to Decentralized Serverless Compute With Fluence Functions and Aqua | Bernhard Borges