How to DAO: Strategies for Resilient Decentralized Governance - Alexey Pyshnenko | Fluence

hello everyone how's it going um my name is Alex I'm from fluence U I'm a developer myself um been team leading the network team on fluence and today I'm going to talk about what makes fluence how it works how to use it uh I'll try to show a little bit of experience of how it might look for developers even though we have static slides here okay so fluence uh is composed of three main components um that's uh compute Marketplace that's a two-sided Marketplace uh where on one side are the compute providers that provide uh hardware and those uh Computer Resources and on the other side are developers who consume those Resources by deploying um applications to the hardware and those applications they build with the cloudless stack so compute Marketplace is a place where where uh where providers set their prices and say hey I uh I'm ready to serve your workloads for this price and developers discover that and there is a natural competition over Hardware price prices and over different Services provided there so let's talk more about the compu Marketplace it's a Global Network of providers uh right now we mostly target uh the Enterprise grade Hardware because we are to replace Enterprise price great clouds uh that have high up times good discs good network connection fast CPUs and overall provide good experience and ability to build Enterprise grade software that's in contrast to commodity Hardware that's often been the focus of the deepin uh sphere of the this industry we are thinking about that too but our current focus is on providing a seamless uh experience to to developers to users so they can really build complex projects that require high slas in order for providers to be sure they can pay their bills and their income is stable uh we made the protocol in a way that allows developers to pay with stable coins so developers when they deploy their workloads uh on the provider's hardware they pay for that in uh different stable coins um if we consider a possibility for them to pay for example with our native token with FLT that would make providers kind of dependent on the fluctuation of the price and if the price goes High then providers might overcommit on next investments in their infrastructure and when the price normalizes they will not have enough income to continue uh supporting those uh that infrastructure so uh that's why developers are paying for their workloads in stable coins however uh in order for the network to make sure that there is enough capacity idle capacity to accommodate more and more workload for developer from developers we need to make sure uh that provide that some of the providers stay idle and not saturated by the existing workloads and for that uh the protocol gives FLT rewards for providers that are idle and can prove that they have uh enough cap CPU capacity enough dis and RAM capacity I'll talk about how those proofs work a little bit later but you can see that there is two uh two streams of the income the stable coin and FLT rewards this network um is not homogeneous so all providers are different um in what differ them besides the amount of Computer Resources they provide is the man managed Services the fluence allows to integrate basically any software into the protocol so it allows to connect different web free protocols be it ipfs file coins ceramic uh and other and others or it could be like ethereum uh rpcs different web free uh protocol apis or it could be web2 software like web2 data databases be postgress elastic search or be it some Network API that you want to call to send an SMS or something like that as long as API as there is a network API or CLI API uh it's possible to integrate that inluence and that's makes different providers different because they uh decide I I'm going I have expertise in providing radi for example and I have expertise in Pro in hosting filecoin so I will provide API to call to get data from filecoin and stuff like that the way we measure uh the computation uh influence is by using the compute unit uh that's an abstract unit of computation it corresponds to one physical core uh it's important to to see that for CPUs with hyperring it's going to be to logical course uh and on on other CPUs is going to be a single core but in essence it's a one physical core 4 gab of RAM and 10 gigabyte of virtual dis for storage providers operate not just in terms of cus but obviously in terms of physical Hardware or of physical servers and each server participates in the fluence peer-to-peer Network exchanging Network packets uh participating in the discovery protocols and stuff like that so so when a provider registers a certain Pier a certain server in the network it provides many compute units um compute units number of compute units in a server roughly cor responds to number of physical cores so for example for a machine with 64 cores there could be 60 or 62 compute units depending on how providers set them up uh usually we advise our providers to leave one or two Cor for uh for needs of operating system so it can do scheduling it can do IO processing it can do uh networ processing so depending on the workload that providers observe they might change those numbers so every computer provider would likely have many many different uh servers with different number of cus and they would register them all together you can think of every computer provider as a small or big business that wants to utilize their uh Computer Resources to get money in as stable coins or get money uh as FLT as I mentioned before it's important for the network to be sure that there is enough um compute capacity idle compute capacity in the network to accommodate new workloads coming from developers so it's when you as a developer want to deploy something for example on Amazon you can be sure that there is enough capacity for your workload that's exactly what we want here and for that we employed the mechanism called proof of capacity uh it's a basically proof of work uh it runs uh in a way that how many idle cus are there on a server that many um randomx threets will be run on that machine machine saturating those scores completely eating out 4 GB of RAM and this proving that those CPUs those scores really exist and really are not shared for any other workload so on a single server uh it could be that some computer units are dedicated to calculating proof of capacity and yet others compute units are dedicated to so-called useful workload the workload created by developer for which they pay in stable coins every cuu uh is required to have a stake on it so provider has to put a certain amount of FLT tokens to uh Pro to um so that when the provider stops sending proofs suddenly for example because of the downtime it can be slashed that state can be slashed um and obviously that um the fal rewards that provider receives or delegator of the stake receives because it's possible to delegate the stake um are proportional to the number of cus this uh protocol is tolerant to Providers downtime so as long as provider doesn't have much downtime it's not going to be slashed but the downtime is accumulated over time so if provider goes below its slas it's going to be slashed yeah and U as I said before um compute units can switch from calculating proof of capacity to serving uh developer workload the cloudless functions and that happens in a way that each server of the provider listens to the events from the blockchain and when it receives a signal like hey please stop sending proofs for that computer unit and instead deploy those web assembly functions those cloudless functions to orchestrate them provider does exactly that so every server can have uh in different Time moments of time can have different uh cus allocated to useful workload and different cus allocated to calculating compute proofs providers might balance that they might have different strategies it's a free open market after all um so they might experiment with different proportions of and different prices uh regulating those proportions ft rewards that are received for putting stake and sending proofs by providers are vested that incentivizes providers to stay in the network longer and longer because if they want to stop serving uh their capacity stuff and improves of or stop participating in the protocol completely they will only receive the wested part of the rewards that makes uh certain pressure for them to keep their Hardware in the network indefinitely so let's talk about the cloudless stack the sdks and approaches that allows developers to build distributed systems on fluence so the central concept uh here is the cloudless function cloudless function is the orchestrating mechanism or choreography mechanism it's a workflow script that tells hey go to that Pier execute that function on that peer take the data put them to variable send to other peer and overall it allows to describe any kind of distributed algorithm but in essence it's a thing that orchestrates web assembly functions so that I hope that's visible uh that's how how it looks for the developers um if they are to use rust they would uh write code um like that just the usual rust code and you put Marine macros uh on top of it Marine is our web assembly run time and for example here you can see they can issue HTTP requests as long as provider allows uh Coral effector like Coral um manager service to be deployed on his Hardware after developer uh described that algorithm uh she compiles it to web assembly then she provides a deployment definition deployment configuration saying that for Coral deployment that's just a name I want replication Factor fre that's Target workers and I want to I I'm I agree to pay 33 usdc per epic per per 24 hours for that and it includes just a single service and you can see uh spells there that's are um analogy to Chrome jobs that allows to run cloudless functions by timer or by by some event and this orchestrating something uh that happens in background on its own after deployment is created you can see there is a succeeded deployment that's how it looks you can you can see a corresponding contract that describ the deployment and manages the balances on the blockchain all the computations obviously happen offchain but uh the descriptions the uh accounting it happens on chain and you can see that replication Factor was free and now free workers joined that deployment and from that point on it will slowly start taking balance from the deployment balance and sending the money to to the providers and it's reachable by the network by using the cloudless functions so cloudless functions are written in a language developed by fluence the language is called aqua it's not a general purpose programming language it's a workflow language that allows to describe distribut algorithms of any kind but uh it's pretty small so it's not as I said it's not a general purpose programming language just has has enough constructions uh and tools to allow to describe distributed workflows here you can see that it's just a function so it could be used as a library it's obstructed over peers that participated there and here it implements part of the uh threshold signature protocol in multi computation setting where uh we are asked or rather providers are asked to go go to that array that list of peers that participate in the threshold signature uh cens and iterate over them in parallel and go to Every of them and call First the function called get key share then uh called function called get rank combine those combine those results into response construct the algebraic data type and return it back to the Coler you can see that by the putting par there uh next to the four uh we parallelize the computation so that that workflow uh happens com at the same time concurrently and in parallel on all the peers that are described by TSS parties it's executed like that every peer in the network uh like cloudless functions are executed like that every peer in the network has uh an interpreter for the cloudless functions so wherever so it's kind of executed between the peers in a sense it's not executed on some specific peer it's executed on every pier where it reaches and it's self routing so every peer in the network even the browser peers they know how to interpret those cloudless functions so wherever it arrives uh every peer can just read the script and see hey this line is not for me I know for what public key this line of the script is so I will route this cloudless function to that pier and when it arrives to the correct to the first correct Pier Pier does some function calls resolves where to send them further and does that and does its self- routing self- routing execution which just sent to the network replicates Forks joins um goes in parallel sometimes uh like de and it's up to developer to describe the distributed algorithm she wants to see there if she wants it to be a request that goes through 100 of peers and then back directly to her browser she can do that if she wants that just to be a request like a cloudless function that goes uh through 100 Pier write some data to them um she can do that without returning the result it's pretty flexible and allows to do many many things and as I mentioned before providers are differentiated by different managed services that they provide and cloudless functions allow to be integrated with different protocols be storage blockchains Web Two apis or databases Web Two or web three as long as it has Network API or CLI client it's possible to integrate it inter fluence which is virtually everything along the execution of the cloudless function all the providers all the peers that participate in the execution they put their signatures so you can as a result that Network packet that brings the cloudless function it also brings with it a trace of execution and it's basically an auditable log on of what function was executed with what arguments in what order and it's it's possible to compare that audit log with the cloudless function and see if it was executed correctly so that gives you kind of a proof of that Network framework of that order of execution and of the arguments that were used so you can certainly say that this computation was called with those arguments and pro was produced those results on certain peers Aqua the language GB cloudless functions uh allows to uh allows to implement basically any um distribute algorithm so be consensus be fell over Quorum multiparty computation lots of them how much time do I have okay 10 minutes so yeah and that's that's the uh fluence Network lots of providers in uh data data centers we good up times providing Integrations to different Services everything is paid by stable coins by developers um there is enough capacity to accommodate workload and as the demand grows there's going to be more and more capacity because token is going to be more and more interesting for providers so yep let's take a look at the software architecture behind uh the protocol so first uh let's see what constitutes a single compute provider you can see here that it's a capacity prover it's a software that runs randomix and saturates the idle uh course it's nox it's the rust implementation of the fluence spear I'll show its architecture in detail too um and those two basically Al constitute a complete fluence spear so complete fluence spear is aover and um and a KN together they constitute the capacity proving and the network part and the function execution the web assembly runtime I'll go to that into the uh into detail a bit on on the next slide so some of the providers also participate in the validation of the blocks of the uh blockchain of the L2 blockchain that powers the billing the proof verification of the fluence protocol some of them don't that's like a decision uh of the validator and of the protocol right now that L2 is on proof of authority it will be on proof of stake pretty soon um the provider if he uh or she uh has a validator or not uh it's connected to the I L2 blockchain powered by IPC blockchain and finally it's parented to filecoin uh beit calibration for test Nets or uh M main net for main Nets so the fluence pure architecture is like that you see there are two implementations here first one is the rust implementation that's the pier um that's meant to be run on server Hardware it contains uh cloudless functions interpreter it contains web assembly runtime and it's powered by Li P2P on the left you can see uh JavaScript client it's meant to be used in browsers or in CIS or like in any um any front end software and it has basically the same architecture it's a bit lighter or it's much much lighter because it's not meant to for high load and it's not participating in the cademia protocol uh only rust peers participate in the cadamia protocol that allows them to discover each other and they long living that's why it makes sense for them to participate there J clients connect to the whole network only through noxus through rust Pierce and they use them as relays one big limitation of J client being that it's impossible to connect there because it could be behind several nuts when you're sitting in McDonald's on some Wi-Fi you cannot just accept any incoming connection the firewall won't let you so you need some connection to the network that allows for two-way communication so the billing the proof verification um and tokens and all the smart contracts they live on the IPC subnet on the L2 uh blockchain and you can see what it has inside uh it has the compute Marketplace that the smart contracts it has a proof of capacity verification uh it has uh FLT bridged from ethereum to file coin and uh inside IPC and it has a rup usdc and other stable coins that developers can use to pay for the workload yeah the token the FLT token is bridged from ethereum uh to filecoin and to the L2 to the IPC we use axlr as a bridge uh to filecoin and then we breach them further to the IPC itself right now we have uh two main networks uh like there is a main net uh that's called cross it's pared to the filecoin minet um and it hosts it works on real tokens it works on real FLT on usdc uh we have external providers and unboarding more and more of them uh we have a on call team that guarantees up time of that Network we guarantee uh version stability and we make sure that if we are updating something major we notify people about that um yeah so it's a stable uh the stablest network that we have the second uh important network is Dar uh it's parented it's a test net so it's parented to filecoin test net de calibration it uses test net tokens and mostly it's for hackathons and uh developer uix tests we're thinking about maybe making that the network for the commodity Hardware so we may switch to real tokens there or some other tokens but still the the ones that have value and not just test tokens and bring more and more commodity Hardware there so the crust then would be the main net with high slas and the test net would be a much much bigger network but and it wouldn't be a test net anymore it would be a main net but it would would not be would not provide as high slas at as high up times and as high quality Hardware as the main net and we have a stage for wild tests for providers to come and register themselves so it might not work at times uh that's the goal to break it so please come and break it so if uh we see at the developer tooling there's actually lots and lots of developer tooling that we have inside of fluence we have uh rust SDC JavaScript sdks we have uh programming language we have a compiler for that programming language we have uh vs code extension and um different IDs are coming as well we have so many things but they are all are packed to the fluence that's our Swiss army knife tool for developers to deploy their code to inspect it for Prov providers to be to register on the network um go and explore it it's a pretty nice the there is great we make sure make sure that the uxix is great because it's so hard for me personally when some web free tooling just gives you some error error and you don't know what to do with that and we care about making sure that when users encounter something unexpected they surely know what to do next the documentation for the project leaves that the u.d um soon we will open the stage for anyone to register their providers so they you can experiment because right now it's uh on the cross on the main net and test net it's permissioned uh we want to open it on stage so people can experiment with their software with their strategies and stuff we have a network Explorer that's the screenshots the white ones that you see that's from the network Explorer you can see we have different providers registered uh on my that they have different offers uh with the same price right now but they can change it it was their choice with different number of compute units different number of peers so we're evolving there so what's in the future for for fluence we're pl we plan to go for AI we plan to so right now the compute units they are tied to CPUs we want to make it possible to have compute units on gpus as well right now we're mostly focused on Rust uh but we want to provide more programming languages and Python and JS are what we hear what we hear from people are the most important languages for that we want to provide ability to run uh Docker containers and we're designing and and implementing that we want to get further into the proofs of what's happening on the network so right now it's proof of capacity it's those audit audit logs but we want also have um proof of compute so we can prove that certain web assembly functions or any other runtime functions were executed correctly probably that's going to be zero knowledge solution we want to provide a market for liquid staking right now it's possible to uh for one entity to put stake for the provider so it could delegate it stake and that makes it possible to to trade that we want to integrate trust execution environments that's te so people have easier time storing secrets and managing secrets on fluence as an alternative to that we will provide MPC subnets multipy computation subnets so private keys can be shared for example it seems it makes sense to integrate Fiat payments so people can pay for the hardware for their workloads with credit cards and it would make it easier to onboard more and more people we're looking into more and more data Integrations not just IP FS not just camic not just filecoin but more and more uh some S3 some web2 databases there's just really many many possibilities for that we we're going to be switching the proof Authority main net and test net to proof of stake uh soon and also my I I I wish to see a GUI for for aqua so it's easier to to draw distributed algorithms instead of programming them I like programming them but not everyone do and last but not least we have an airdrop so uh if you ever contributed to some web free projects um you can go and check if you're eligible you go to claim. flu. network you enter your GitHub username and you see if you're eligible and just make sure that you're s keys were published on the GitHub like three months ago or because if they weren't the the airdrop it's trustless it doesn't use any centralized oracles so but it requires uh you to have SSH Keys published for your GitHub account at the time we made the snapshot and that's it from me if you have any questions I'd be happy to answer them [Applause] one question does anybody want to ask the one question we have time for anybody um can you hear me yeah um thank you for your lecture um so do you envision that one day since it's a decentralized and distributed uh computing power that there will be people who will uh organize compute Farms like U I don't know many uh servers working for them and do you think that do you have any way to prevent them making uh being a single point of failure mhm thanks yeah thank you for the question so uh what what we envision uh regarding the people organizing themselves into big computer entity is U one thing are the Dow regulated uh um Dow paying for the infrastructure for certain companies so it's possible with fluence to automate uh payments for the infrastructure you just make uh like a proposal on on your Dow and say hey say uh pay the fluence Dow uh certain amount of money create uh a deployment pay for those that infrastructure and this way you can power uh infrastructure of your business or of community owned business uh through fluence regarding the big uh creation of big farms that become big uh single point of failers it's possible for developers to specify different filters when they uh provide provider deployment so it's possible to also specify the G location uh of those of the providers and I think it's it's it's got to be super easy to to just add many many of them many many GE locations and say for example I want replication factor of 17 and I want that to cover um four different G locations so and that would basically solve that problem so if there are some big farms in different places of the world still a single deploy ment would scatter across all of them amazing thank you thank you so much and please big round of applause for alexe with fluence can you guys believe that this is his first ever big keynote thank you so much