IPFS IPFS þing 2022 - Building Apps on IPFS, 10 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Compute + IPFS - @evgenyponomarev - Building Apps on IPFS

Description

Compute + IPFS - presented by @evgenyponomarev at IPFS þing 2022 - Building Apps on IPFS - https://2022.ipfs-thing.io

A

I'll be quite short, with my uh talk, the the whole idea that uh you know there is a huge amount of of approaches in terms of compute on top of decentralized data, and uh um I think what we put most attention to is.

A

um We started from this like okay, we have ipfs as a great decentralization for data, and uh the first idea is now we don't need any backends like we don't need clouds anymore right, like we can build everything on front-end, but then we have all this complexity on the front end and we basically start thinking. Okay.

A

What can we really move somewhere to performance nodes on the back end and make sure that you know we have data indexing, caching and uh some apis and stuff, because we cannot really um have enough performance to have decent ux on the front end, um and uh uh we were thinking a lot about this topic, and uh um the whole idea here is to have the as universal as possible, runtime that potentially like as cool as uh lamb does uh and like automatically scalable.

A

So you can just put any code there and like it's magically works and you don't need to think about it and it can work on any device so and also like it's open from the nodes perspective. So like it's the same as anyone can run the ipfs node, anyone can should be run. Fluence node, who would do this computation, um and um uh I know I have like these slides.

A

I have here- they are like quite high level and pretty obvious stuff, but we kind of think about a lot of this platform risk and uh um the composability of software in general, like a web 2 problem. If I have api and- and it runs on some server and uh probably uh like the data- probably sits also in centralized database, but even if it doesn't sit in centralized database, someone still runs api on some server.

A

So if other applications use this api to build their stuff, they have this dependency and this dependency controlled by api api creator and by whoever runs this api under server. So they can cut off the uh the access which is pretty bad and uh yeah.

A

It's kind of like this, this slides from from blockchain context, but like a lot of companies in blockchain space right now they take this open um database of blockchain data and index it and and kind of convert it into some custom, queryable databases and uh package it as apis like nft apis like openc, uh like some wallet apis and stuff like that, and then uh other people, like they kind of try to bring other people to build on top of their http web to apis, uh to have uh better products for users and the problem is like.

A

The data is decentralized. It's there it's on the blockchain nodes, but this this apis are centralized and no one can like rehost them or like rerun them like, and and uh basically we get back to uh at this layer we get back to web to world.

A

We don't we don't solve the the platform risk uh from this perspective, um so we are trying to kind of solve this issue um at the highest level and uh uh we think that uh there is a like there should be a network that just allows you to deploy any computation run it and uh to have like. If you need verification for the computation, you should be able to do it. If you don't need, you should be able to avoid it.

A

uh So it's sort of like a hybrid trust model for the computation, and it should be like much more relaxed than you have um than constraints you have on chain. um So uh this uh sound like you, can build anything on that for sure yeah. We want to enable web to use cases. We want to bring web 2 use cases to web 3 as well, but what's important here is we end up having kind of three things we have the development toolset, which is very specific.

A

In our case, uh I I'll talk about it, uh so we have the network of nodes who anyone can can join and and run fluence node and like execute this. Whatever created with this development stack- and there is like the whole economics around that- like incentives for uh for nodes to participate um and stuff like that, um so two core components of it uh of the development stack is um the web assembly runtime, which is works like sort of instead of docker.

A

Instead of docker, we run everything in web assembly uh and the reason to have web assembly is not just because you can run it on any device. But uh you know if you are the running node and you allow anyone to send a docker container to you with their program and you're going to be like the hosting provider like you would need to create additional.

A

um You know constraints for these docker containers not to break your system not to break your machine and wasm has much better resolution, so you can just have it out of the box and it's kind of like super easy to become the hosting provider. uh At this sense and um like we, uh we have our own runtime, uh it's based on wasmar, it's pretty cool. It supports, like whatever uh webassembly standards exist.

A

um We we have mike here but he's uh he left now, but he probably gonna talk about this on friday, if you're interested at uh um ipfs and wasm uh track um and the second. The second thing is um aqua that we're also going to have the track about this tomorrow.

A

It's a language that, basically, you use to implement the control flow of your application. So when you build staff on fluence, you have the wasm um modules as a sort of docker like as a microservices sitting on different nodes, uh wherever you what you deploy them um and you have the orchestration like business logic. On top of these uh wasm containers uh implemented in aqua and- and you know some some simple stupid analogy with web to cloud that I have is like you can think of marine- is sort of like lambda functions.

A

uh Aqua is sort of like workflows on top of lambda functions, but aqua is much more performant. It's um like not just some jsons or um uh configuration but like the whole programming language that abstracts out a lot of uh pure connectivity and uh uh and things like that- um and it looks like very simple, so you um like, if you want to do some map, reduce or like pluralization, it's just like few lines of code um and yeah.

A

Admittedly, I think mitri showed uh this yesterday and what is cool here is that um for basically every request that happens on network, like user clicks, a button, the aqua vm creates sort of um you know short-living sub-network that executes uh this request. So, like um all these nodes, can, you know know can discover each other can know about. Each other.

A

Can work together can send like the some function like get price executed on onenote, and then the results send to um uh to the uh nodes that that calculates uh the average and after the you know, this script is executed, so request ends to in the second device. uh This subnetwork is is not exist anymore, but you can also create the you can use aqua to program the long living subnetworks. If you need the sub network to exist for long period of time and like run some scheduled execution, so you can also do this.

A

So it's kind of very similar to what you have in the cloud where you have you know cloud functions, they're triggered by events. They read data from some place. They write data into another place, but this here you can also manage the workflow of the execution, the topology of the execution in terms of network and in the cloud you just don't see it, you don't know how it all works inside they just it works like a black box, so yeah again like some pictures.

A

So traditionally you have this centralized gateway that manages everything and kind of reroutes requests to different microservices or orchestrates business logic. Here you can like really decouple business logic to different nodes um and uh yeah. So so this is fluence pure and we mainly try to focus on on compute and not touch. Data like every fluent sphere by default comes with ipfs node, so you have like native access to ipfs data, but potentially you can plug anything like any data source.

A

So you can read from any data source, however, actually I uh I spoken to some uh protocol labs folks and uh there's idea that you know uh every day like any data should live in ipfs, so we we should always read from ipfs. Even if it's like a blockchain data, it should be first dumped into ipfs so like it should be like cid, right and and then like by cid use influence node by cidu.

A

You should be able to retrieve any data, and uh you know, do some stuff on it and put back to ipfs so like you have inputs and outputs all as cids and it's totally doable, and this is a pretty cool concept, but like right now by default, so you can just plug any data um and yeah.

A

We have rust uh implementation, javascript implementation, uh they a little bit different, but uh almost the same um and yeah and and the we have a few more components of it, because um when we, um when we think of of um you, know using this to implement just re-implement something similar to traditional back-ends, um we started having problems that we didn't have in centralized setup like you know, nodes, reputation and stuff like how. How should I select nodes? Where should I deploy my web assembly code?

A

um If I, if I don't know them like if they all the same for me, because I don't know any of them, that's why we have, for example, this trust graph thing which is sort of web of trust uh solution. So it's it's a distributed database of trust relationships between nodes on the network.

A

So now, if I run the code like the function, I should be able to uh select nodes that I trust the most and and deploy it there and execute there, because, um because they're more trusted and the graph there is, it means that I can basically query.

A

um If I you know, I trust protocol apps, and I know that protocol apps run some nodes. There are trust entries on the network from protocol apps to particular node instances, so I can discover these nodes and see that I transitively trust can trust them, because I trust this protocol up authority, but I can subjectively decide whichever authorities, I trust.

A

So this is basically a lot like this component basically allows me to manage wherever I execute the the code um on the network.

A

uh The registry thing is is about uh having the metadata about subnetworks, basically like grouping the nodes uh by giving them um the ability to know that they work in the same group on some particular application.

A

um So regarding aqua. uh Basically, because we are, we are sort of decoupling. The control flow from the execution and wasm aqua becomes the language to create distributed algorithms, so we can create, like potentially anything like uh better kadamlia like a different. uh You know modifications of kadamlia consensus uh notifications like whatever, like any um any distributed algorithms- and this is what we kind of we see like for ipvs. In particular, you can just use aqua to implement and re-implement um ipfs um like parts of ipfs like basically slices of ipfs.

A

We can potentially be able to create something like bitswap on aqua or like something like uh content, routing or indexing and stuff like like that, um so we kind of like pitching it, because uh we believe that uh you can in what you can implement this uh algorithm once and then reuse across uh different implementations in different languages like go, ipfs, rasta, pfs like and so on, and so forth, um yeah and a little bit on on computational verification. uh As I said, the whole idea was that you know we are not.

A

We don't want to create a decentralized network that can compute stuff uh and we don't want to force the consensus there right, but if it's decentralized and anyone can join, anyone can provide any fake results to computations like how do you deal with so uh there are basically only several ways to deal with it like first, you should trust node and then for this to select the most trusted node. We have trust graph.

A

Second, you can apply consensus partially to a piece of computation that, where you really really need consensus- and you can- you know- write the consensus algorithm in aqua and apply it to the the wasm where you want to have consensus like basically, you can implement something very simpler, like collecting signatures for um combination result or you can have something more complex like tender, mint or something, and the third thing is basically some kind of ziki proofs, but they they really really depend on the use case. They uh it's not really.

A

I don't know if it's, if it's possible at all, to have ziki proof for arbitrary computation, that you would be able to create and verify at a reasonable amount of time, but we don't have them yet we probably gonna, have it oh and also there is a force way. Some people uh like to use te like uh trusted, compute environments, um and you should be able to discover nodes that provide it or like run fluence uh with support of td.

A

uh But the problem, my personal concern about that is that uh like intel's jax was hacked a few times and there was like a silent attacks on it, so people created fake keys, so they could have like really access to the computation that happens um because they didn't have the dt they they uh pretended to have it um so yeah, and you know the network is, is heterogeneous. Basically every fluid zone is different.

A

Every fluency node has different amount of wasm, can execute different amount of wasms, uh so you can imagine the marketplace of um of services or kind of back ends of applications or like a pieces of back ends of applications.

A

uh Yeah, and I think the rest is, is less important, but uh one cool thing here is uh because, like imagine that we run backends of applications in such a network- um and we talked in initially like in the beginning about api um kind of dependency and platform risk, so uh here uh the same way as in blockchain, because um the author of the code doesn't runs the code on the network, like the the hosting provider and the author of the code are two different people or companies.

A

um Now you can, you know, have the sort of demand-driven availability of the back-end components. So um if I am as a application developer, I create the new version of the application and it's you know goes against uh users, freedom or users, privacy and users. Don't like it.

A

The hosts and providers may just not update to it, so they basically can have your application back-end forked into two versions that would exist at the same time and uh like theoretically, users can uh choose whatever uh version they use. It's a lot more complexity, but the the idea here is uh same as on the blockchain. You can once you deployed stuff, it's there like forever.

A

If you uh do it properly uh and then you basically deploy every time you deploy the new version of your smart contract and they coexist and users decide which is better yeah and the economics is not yet there so uh not going to talk about this, and you can check out the network our documentation and come to our sessions tomorrow.

A

A

Fair to say that, right now you and it's interesting that you are essentially treating ipfs just as a file system for now yeah yeah for now well, a little bit more. So uh it's a kind of file system, but also, for example, we use ipfs natively to deploy the wasms to remote nodes. So, like you know, yeah, so, like you, you upload it.

A

You always upload it by default uh to ipfs and then the remote node retrieves it by by cd yeah yeah, exactly exactly yeah, and you can say that this is like sort of functional address function, addressability, but it's it's a complex, also question yeah awesome! Thank you. Okay! Thank you.