Fluence Labs 🛠 Decentralized P2P Protocols And Applications With Fluence And Aqua
ETHGlobal·Sun, Oct 9, 2022, 12:00 AM
Join Bernhard Borges of Fluence for a workshop titled "Decentralized P2P Protocols And Applications With Fluence And Aqua." This workshop is part of HackFS 2022, a three-week long virtual hackathon focused on building a digital world that is censorship-resistant, decentralized, and trustless. For HackFS, ETHGlobal has partnered with Protocol Labs - the organization building Filecoin and IPFS - to run an event centered on dapps, web3, decentralized storage, and everything in between. ---------------------------------------------------- Follow us: https://twitter.com/ETHGlobal​ Check us out: https://ethglobal.co​m Email us at: hello@ethglobal.com
Transcript
foreign [Applause] [Music] feel free to just drop them in the chat um we'll be monitoring that and then uh we'll have Bernard ask them answer them at the end um and yeah uh Bernard uh feel free to take it away all right hi everybody thanks for having me uh You're Gone by since the last hack FS so it's super exciting it's almost right there right of Summer and uh very happy with everybody to be here so the workshop is half an hour so we're not going to be able to to get everything done I usually try to get it done but hopefully we'll get enough done so ask questions put them in the chat ask them and uh we'll we'll stop periodically and obviously we can deal with them at the end as well so the workshop is all about the centralized peer-to-peer protocols and applications and how to accomplish that with fluence and aqua big statement and we'll spend the next next 30 minutes or so unpacking that very very statement so what's fluent fluency is is is a stack that that includes a decentralized peer-to-peer compute protocol a network and a whole bunch of tooling everything's open source very permissive Apache to blah blah blah and the network in it by itself it's bootstrapped by fluence because it's peer-to-peer protocol uh peer-to-peer Network it's open it's permissionless so anybody with a node that's protocol compliant can join and uh and participate so you've probably seen all this you know how we got from uh from web one to web 3 and uh I don't I don't want to dig into the details of it but the important part is that we want to decentralize through peer-to-peer networks which is very very different than just decentralizing decentralizing a bunch of services is easy but it doesn't give you the web three attributes we're looking for and uh if you start decentralizing with peer-to-peer or on top of peer-to-peer networks you actually get those desirable peer-to-peer uh uh web 3 attributes and those attributes are you know uh reducing your de-platforming risk uh reducing costs a lot reducing rent taking both at the network and the application Level uh increasing availability increasing failover all much cheaper uh reducing your censorship exposure reducing your exit barriers if you if you lock into a system uh like uh with some Cloud providers it's easy to get in very difficult to get out same as social networks easy to get in impossible to take your data out and and this is where peer-to-peer type decentralization comes in and is super helpful and if you look at uh it's it's what we want to do we want to decentralize a lot of things or everything in order to actually to unlock those web three attributes and we've seen it in uh on the crypto side particularly in decentralized financing with uh crypto smart contracts D5 a lot of decentralization's been happening and uh what we really want to look at though is we want to look at the the stack a little bit more if you want to look at it from an OSI perspective and drop down a little bit more into how we decentralize at the quote-unquote internet level so if you look at storage for example ipfs filecoin our weave many more or a few more all peer-to-peer decentralized storage allow you to control your data that doesn't I mean that doesn't prevent others from copying your data once you use it or allow them to use it but it's you have your data you control it you can move it if you're in a social network and we get the network in a bit and uh you want to move you have your data identity super important right self-serverness self sovereignty and uh again the technology around uh decentralized identities verifiable credentials and and the whole linked data structures that we've been building for the last few years in conjunction with cryptographic tools really unlocks an entire different way how to uh authenticate and authorize yourself in in a variety of systems where you or the user stays in control of their data including their authentication profiles which are increasingly Based On cryptographic Tools like uh key pairs instead of just password login which are stored at somebody else's machine networking particular social networks very very difficult to get out of them and if you look at uh efforts like Mastodon for example which are super super cool starting to to build a real alternative to some of the big players and as the new generation of people with more I don't know requirements or even entitlement where it's controlling their own data uh grows up I think you'll see a big switch in those uh adoption of social networks and we really want to get to is Computing right because Computing is can also be decentralized and if you need an example analogy uh centralized Computing today would be for example Amazon laptop or Google workflows and so so you can start thinking how do you decentralize this and this is where fluence comes in so it was a very long wind up to getting where I wanted to go so there are different ways of decentralizing computing so if you look at it from a smart contract perspective or on-chain perspective you're operating in a deterministic context so that that's not good enough for everything for Global for Universal compute but it's good enough for on-chain compute and that's what really matters but you need to usually Supply off-chain capabilities to support on-chain capabilities and it's a very interesting model and but it's limited then you can start looking decentralizing from Hardware marketplaces for example so you look at goal and life peer for example a very high intensive compute uh using aggregate compute resources and a lot of the management actually is on chain so those are specific compute instances by and large and uh that use unchain for management and then we want to get into general purpose peer-to-peer compute so I told you peer-to-peer networks are are super interesting for a variety of reasons because they enable things like failover availability much much cheaper than uh than structured centralized networks and even though we do structure peer-to-peer networks by structured I mean actually build designed and managed like uh if you look at the virtual private Network for example in Amazon and a general purpose peer-to-peer compute solution basically you can do any computation any computation we want the the functions if you think of it as a lambdaized service we want this to be function addressable not so it's not rest or Json RPC but the function addressable which is the equivalent to uh content addressability you see in ipfs and Falcon for example we want a universal run and uh in the fluence case we want web assembly because it's uh it's super portable and we really believe it's the the future of of modular called business logic expression and we want the network open and be permissionless so this this is what we want to bring to the table and this is bringing to the table so fluence is decentralized peer-to-peer compute let's skip that one so what does it actually look like so if you look at the right we got a peer-to-peer Network the uh upper left and lower left green circles are peer clients could be a browser for example could be a node uh application could be a hosted script we'll get to that in a minute then you get nodes in peers in the peer-to-peer Network those are the blue rounded square ones and uh these nodes can host services and they'll get which is your business logic expressed in webassembly modules it really fundamentally is a peer that is publicly accessible not every participant in the peer-to-peer network is necessarily a public successful it could be nodes being behind an app for example or it could be a browser which doesn't necessarily which which can't hold the connection right so you need a relay in order to re-establish connection with that browser if there is something coming back for example so if you think about uh a use case for example you can think about uh spell checker or or a document processor so in the Apple left corner this is a browser and we typed text uh colon plus one hack FS rocks okay so and now we have two Services which we wrote as web assembly services and we deploy them the first one would be an emoji ejector so it takes you send a text now to that particular service and that service now looks oh look there is uh uh colonos one we inject a thumbs up PNG right that's that's the state change that service operates on that data which was our our text and then the next series would be spell checking and it's a really super smart spell checker so it knows it's not Arc FS it's hack FS so again we apply our state change and now in our workflow we could specify hey save that text this spell check and Emoji inject the text and I don't know a PDF whatever you want to do and save it ipfs so how do we get to ipfest I'll explain it in a minute and then finally or simultaneously in parallel we say hey send a text to some recipient I wanted to go to which is happens to be the peer client in the lower left so so if you look at it from this peer-to-peer perspective so we gotta we get peers that connect to each other these peers are capable of Hosting web assembly Services modules and those modules these Services can take on any business logic you want it's just you know fundamentally No Limit and uh so we can have this motion Emoji injector we can have a spell checker and we can write adapters to other resources out there in in the general internet so it could be to microservices it could be to other peer-to-peer protocols like ipfs and by the way we have a fully functional integration with ipfs so if you want to integrate with ipfs for your project you don't have to write anything it's fully available for you and uh and now I told you before that we use function addressability not rest or or taste RPC so how do you the how do you get from here to here to here you're not using if you're not using rest or uh or uh Json RPC because if you really look at it it's what you're seeing here is uh well let me tell you first how you do it we have a we have a language called aqua which is specifically designed for peer-to-peer programming and uh but basically do it allows you to compose Services into protocols or applications and use functional addressability where the functional addressability of this service in particular for example would be the peer ID that's hosting the web assembly modules and the service ID which is unique associated with those webassembly modules so that gives you a couple fundamentally and you can and and aqua helps you resolve that Tuple very very quickly very very easily at a very very high level and uh what they end up then is is a data push model which allows for super thin clients right is that I mean Finn I'm not talking browser Finn I'm talking like you know smartphones in the 80 to 100 range that's a thousand dollar range I've talked about like really light Chrome OS clients I mean thin thin thin Hardware based clients but also browser of course and so we end up with a data push model right so I take my text I I write this script and act but it basically it says hey take this text and drive it to the uh Emoji injector so we basically we create something here we throw it onto the first we lay it's a browser here we made on that relay we figure out hey we need to find this this pier with that service it magically it's not magic but it happens without you have to actually do anything it then Finds Its service the service applies at State change to that data and it says hey are there any steps left in that workflow yes spell check so find that peer with a spell check service apply to spell check State change and then hey are there any steps left in that workflow yes we want to save it in parallel to ipfs the the final State and deliver it to that client we write it to ipfs nothing left okay nothing left terminate so you may want to be able to send something back to the originating client but you don't have to and this is a very different model than your typical client server right where you have the client server client server client server client server a lot of turn a lot of bandwidth requirements a lot of activity this offloads everything if you want to to the network okay so how does this work we have act by the language and then we have with the language comes Aqua compiler and aqua virtual machine and we also have marine marine is a general purpose webassembly it runtime so the web assembly we're using is called webassembit and that is different than you may have encountered as was and bindgen which is entirely built for the front end for the browser yet it does run in the browser because we make Aqua VM which executes a lot of that stuff available for browser deployment but it's it's a different type of uh of webassembly in terms of runtime perspective so you're looking at wasmer was the time as the underlying runtime not buying jet okay so every node every peer in order to be a successful participant in the network runs and we have full reference implementations office of course you don't have to build that stuff if you want to run a node allows you to basically comes with Marine runtime and Acro VM so you take this app by Script and I'll show in a minute what it looks like you compile it and then you send it to the network the network then on the network and aqua VM wherever it hits first doesn't matter whatever relay it hits it says hey find this peer find the service just like we mentioned before once we find the superior and the service we load it into Marine we execute it we apply the state changes go back to acquire VM keep going so you get this data push model and uh okay so basically the the the crit aspect for this data push model is what we call a particle you can think of it as a spark package and that's basically Cloud Aqua plus your Genesis data at the beginning and uh and some metadata and this is packaged up at the client level so at your browser exam say we have this browser and we have this text so it's packaged up in this data structure and now this client finds whatever first relay available on the network and it literally like flings this particle onto this uh this this relay in this relay it says hey look this is a valid data structure excuse me and Aquaman now looks at the script what hasn't been executed okay not executed Emoji injector find me the mode to find me the pier and then we find the pier we go on disappear which will be direct right we may have to relay through a bunch of other peers to get there but it it gets there that's the point and then Aqua VM you uh basically now uh now look again what has been oh yeah here we are on the right Pier we need the services the service available yes I know if it's available start executing you load it onto Marine you run through it blah blah you keep going and uh then when it's all done you get your state change back now the script gets up this metadata comes in of what has been executed and uh goes on to the next year that has the next service until the the workflow is fully exhausted let me go here okay so what does aqua actually look like so assume we have Rewritten of assembly service the webassembly service is a fancy greeter that takes two arguments a name and Boolean and the function is very simple if the Boolean is true I should say the name is access or response from running that function is I hack of s if the Boolean is false it's just by hackaths so very very simple hello world kind of example with added variable in it so Universal and uh that's our service we deployed and now we want to use Aqua to actually utilize that service right because you can't access it through rest or Json RPC there is no there is no IP driven link towards it it's it's all peer-based which of course is one of the big advantages of of peer-to-peer networks right because uh the peer ID which is uh basically a hash of the uh of the keys of the the pier are independent from the IP address so if the IP address turns or you rotate it deliberately you can still find that peer just by the peer address in the network so as long as the turn is the faster than the DHD updates you're in good shape and the fear is always available so we use Aqua for that and if you look down here so the first two lines remember I said we have this web assembly service called reading service and it has a greeting so we basically we uh uh specify an interface we call it greeting service which takes some service ID and this is the function we wanted to call greeting the extreme takes the name and the Boolean and returns a string right hi by access okay so now we got a a interface corresponding to our web assembly service in our aquascript now we actually want to write the function that executes that reading and uh if you look at the function signature we basically the first two parameters are the name hack of s right three true false so and then when we deployed our webassembly service to to that node we knew we know what it is and we got by deployment we got a service ID for that grading service so and of course we return a string as we discussed before so now all you have to do is you basically say on that peer on that node and the string is actually ready so it's like you know one two three DK blah blah blah and uh on that note create a binding of that interface to that particular service ID then use that binding as a namespace and execute that function associated with it our greeting for those two parameters hack FS true capture that as a result on that particular node and then return that result in this particular instance back to the originating peer which is different or could be different than the node actually hosting the service so if you look at the diagram what we have is we have a client here browser for example and uh we now connect to some relay node available and then we find that node that actually that peer that actually hosts a service and this may not be a direct route maybe going through many many nodes many many periods we execute that service on that hosted peer on that peer that's hosting the service and then we get the result back first to the relay node and if I'm really node back to the client if you had to do this manually in the P2P or any other uh uh uh sort of general purpose approach you'd be writing a lot of lines I mean depending if you're in see or rust whatever it'd probably be several hundred and python probably would be uh I don't know probably 50 to 60 maybe 100 and uh there's a lot of uh uh routing related work to be done and it's all abstracted away from you so this is actually super super powerful and now let me go back to so I have any questions at this point okay all right so what tooling is available to you so we have a rest SDK so webassembly is fundamentally uh okay hang on let's see chat somewhere foreign Okay so let me okay let's get back to this question at the end okay I'll get back to this but it's a very good question uh see we have a rust SDK to create those webassembly Services we are looking at adding additional languages right now but right now it's just rust and um that's actually a very very cool SDK so if you come from JavaScript or non-rust don't worry about the rust because uh it's webassembly everything's passed by value so everything that's important but also difficult in rest like lifetimes generics uh object traits blah blah blah all that stuff doesn't exist if you will uh for the purposes of writing web assembly code because everything's passed by value so it's and it's it's it's uh interface types are very very limited so there's nothing fancy going on if you know rust Scala python whatever honestly it's the first four or five chapters in the Rust book and uh I believe it's a very easy uh tool set they use cargo it's cargo to to deal with uh to compile at uh debug and run tests honestly like four or five hours and you should plus looking at examples you should be pretty productive and uh one of the things that our SDK allows you to do is actually when you write your web assembly code and you know you do in Russia in this case and you run your unit integration tests it's on the code but that's not necessarily what you want because we're actually cross compiling into webassembly and what the rest SDK allows you to do is it basically allows you to write tests using the modules you've combined you you compiled you cross-compile those webassembly modules as the reference for your unit integration test which is actually really really powerful because you're actually testing what would be out if you will on the peer-to-peer Network as opposed to the code that's going into the cross compilation pipe so very very helpful uh we also have fluence.js so it gives you everything to write a fluency uh influence clients peer-to-peer client or a fluent depending on how you set it up if it's long running or not and it includes a full Aqua VM and uh actually I think by now the Marine runtime is fully available so you actually can deploy webassembly Services onto the fluent Js client and or node it's very very the the aqua compiler actually generates typescript or JavaScript wrappers around the compiled Aqua for you to easily use in JavaScript so how is it different than anything else uh it's different in the sense that you are running the node so if you want High availability and cheap availability and failover it's up to you to create that environment which basically means you have to host a bunch of nodes whereas the other model with the rust nodes was with assembly was just you you send it out you host it wherever you want to and uh you let the running off the services be somebody else's business we'll get to that and uh and you can basically build and fail over in the aqua script very very easily okay Aqua itself it's a high level language it's a compiler and it which basically takes a higher level language intermediate presentation which is actually we call it air you can think of it by code it's not by code it's almost like structure but it is and it has a command line interface that helps you do certain deployments and a lot of other stuff uh okay so one of the things that's coming soon is a Marketplace and the economics we currently don't have any economics available so back to the original question and what incentives peers do most Services right now none the idea however is that uh peers that host Services charge services or service service providers for running the services and it's going to have an on-chain component and we're currently working on a very variety of models and part of it is also a proof of execution but that's coming so the incentive is to get paid by Services based on quote unquote contracts posts and service providers negotiate which is fully automatic you can not that similar not that dissimilar from what product care does for example I hope that answers the question if not post another one uh yeah so is it possible yeah of course it's possible but we haven't we haven't done it yet but we're working on it so uh there are different ways of doing these uh these uh verifications right and some are actually on at the level of the business logic itself so you write a web sentences and then you write a a snark to uh or Stark to proof the execution of that the the correctness of the execution of that particular service that's one way of looking at it but that's not very Universal and uh one of the problems you might run into this on a per service issue is that a lot of these services are not deterministic right so I mean you have HTTP calls for example and uh and if if they don't terminate that doesn't mean it was executed properly it just means that the uh uh end resource endpoint wasn't available which is not an execution failure in itself so what I'm working on right now we're working on right now is basically figuring out a general execution proof that just proves that whatever arbitrary service was provided and it's not that arbitrary but that service provided actually has been executed not that the result was correct because as I said it's not deterministic we don't know what the result actually is but yes that's coming and that's going to be a super super important aspect of uh of the uh of the ecosystem and the uh uh and sort of the the trustlessness or level of trustless that's available in a permissionless open network which is very very different from blockchain right hope that answers the question if not come back uh how much harder is youthful NCS compared to rust SDK it depends it depends on your background I I honestly I I don't think the rest part is very hard but if you never used it it's probably harder if you're coming from GS than not but I definitely give it a try I don't think it's honestly I don't think it's that hard Okay so we got a bunch of real Integrations which we don't have time for but we have bounties so we have two name bounties and uh how do I get rid of the chat uh best use of fluence of chain compute very open whatever you not whatever you want to do but use fluence and aqua to to maintain the D in your dap to keep it decentralized so if you're using for example a bunch of hosted providers like inferior Alchemy blah blah blah you can do a verification by replication like which is what safety is done we got an example on how to do it and look at the examples repo and so there are two prizes for a total of five thousand dollars and then a protocol basically build a protocol with fluence in aqua and the examples are for example examples for example that's a redundancy examples are decentralized a cross stream Bridge Relay For example which is a huge huge centralization choke point right now in a lot of bridges and uh work on that this would be so there's more and uh finally we're on GitHub Discord telegram Twitter we're hiring if you're interested in any of that stuff contact us any questions you can schedule a a you can schedule a call with the team because I mean at the end of the day we want you to succeed I'm not going to write your project for you but we want you to succeed both in terms of learning about by three learning about fluence and actually you know successfully implementing your ideas I mean that's the whole point and so whatever we can do to assist you in that that's what we want to do and let me get so I have we also have a repo that has some additional information so let me put that in the chat for you and if you didn't have anything else I sort of I mean I I could go on for another two hours but obviously that's not gonna work so uh as well stop right here yeah thank you so much Bernard that was yeah super super informative and and really helpful we all learned a lot um yeah if you um have any questions for Bernardo for affluence Labs I drop it in the fluence labs uh Discord Channel um they'll be there to answer all your questions and and help you with your projects and yeah thanks so much Bernard hey thanks for having me good luck to everybody and I'm looking forward to some awesome uh submissions awesome bye everyone bye
Automatic transcript — names and jargon may be misspelled.