Decentralized Network Summit x #BUIDLWeek

infrastructure providers for a decentralized network and a decentralized world. And you're going to hear from all the people here, Fluence, obviously, Sphere and Jensen, Film Mind, Streamer, and Lit. And you know, follow kind of a a normal element. We will start last is first. So Lit is on the far left, but we're moving them first.

Um David Snder um founder of LIT is going to introduce it. It's a decentralized key management protocol which has you know huge implications for keeping uh data safe and managing data uh securely and in a decentralized manner. So with that I'm going to turn it over to my friend David. Thanks Tom. Uh really appreciate the uh Fluence team for inviting me here and thank you all for attending.

Um, as mentioned, my name is David and for the next several minutes, we're going to talk about key management, specifically decentralized key management. So, to start, um, by a show of hands, does anybody recognize who this is? Yes. Excellent. And so, another way to think about who this is from the perspective of key management, this is a centralized trusted custodian.

If you are familiar with this uh film and if you know how the story goes, it is that centralized custodian uh this is from the Matrix that gets compromised and lets Neo into the source. And just using this as a kind of a fun example to illustrate some of the issues with centralized custodians. It's not just in web 3, but also in the world of film. And so it really comes down to the question where where are the keys stored? So in the matrix example and in many examples across the internet, keys are stored centrally in key management systems or of course self-custodied by individuals who want to interact with distributed systems or privacy systems like signal chat for example.

And then for us in the context of building a distributed key management network, where are the keys stored? Another way to ask that is can the internet keep a secret? Which is a big question that has been uh floating around this space for a long time. And I'll tell you about our attempt to let the internet keep a secret as well as what that can be used for. So first a little bit on the network itself.

This is as mentioned a distributed key management network. There are three core components that I'll quickly go through that make this possible that are listed here. It's a DKG which is distributed key generation that is a cryptographic process where a bunch of nodes can come together. Uh they exchange polomials and as a result each of those nodes now custody something called a key share. that key share does not represent the entire cryptographic secret but uh a threshold is set whereby 20 out of 30 nodes for example or in the example of like Coinbase's uh Coinbase's DAP browser they do a two of two scheme but the scheme is tunable where you can say you need X of N of these key shares in order to use this underlying distributed key.

So that's one of the core cryptographic primitives at the heart of this network. The other one is something called PSS, which stands for proactive secret sharing. And sometimes you hear this referred to as a key refresh. And so the problem that this solves is, okay, you have 100 nodes, they have this shared distributed key. 70 of them need to sign off or authorize any action with this underlying distributed key.

But how does that network persist over time? How can you ensure that nodes can join and leave the network over time? And that is where proactive secret sharing comes in which is a method for assigning out new shares to the next epoch of node operators where you can maintain the same underlying secret that same underlying elliptic curve in the example of web 3 but have a different set of parties holding that secret in distributed custody. And then the final element that makes this network uh complete is the use of secure encrypted virtualization. It's kind of like an enclave.

It is a is a black box. And so all of the nodes in this network perform all of their operations inside of SEV. And the role of that is to prevent the node operator from ever having access to any of that private key material which in this case as we talked about earlier is that private key share. Um and the top two things DKG and and PSS uh typically like these are these are subcomponents typically you hear this referred to as threshold cryptography more generally and then the overarching uh category that these processes are part of is something called MPC or multi-party computation. So another way to think about lit is as uh MPC key um as a network or a distributed key management network as we've been talking about.

So now let me tell you about how it specifically works. Just like with public key cryptography so independent of anything distributed just with an asymmetric key pair a key pair basically gives you two core features. the ability to encrypt stuff like how signal works and the ability to generate digital signatures like how MetaMask works when you want to sign a transaction and push it to a blockchain. And so I'll talk about both of those features in the context of distributed key management first starting with encryption and decryption. And so what we're looking at here is an oversimplified diagram, but basically the way that the process works is Alice can encrypt some data client side.

So let's say it's like a video. Alice can encrypt some data and go and store that on IPFS on a blockchain on Arweave wherever and with that symmetric key that's generated client side from Alice Alice can encrypt that to lit which again is a key pair in its own right and set a rule. And so some of the rules uh that we've supported thus far are based on blockchain state data. So developers can say, "Hey, let somebody get this key when they hold certain assets in their wallet." And so this is like an oversimplified way to describe this is like token gating.

So you could say somebody needs to hold this NFT in order to decrypt this content. And so the cool thing about it is the decryption. So Alice encrypts that data. She encrypts that video. She sets a rule that says only somebody who's a member of my DAO, for example, can decrypt this video and view it.

Bob shows up later on. Bob is a member of a DAO. He signs a message, which is his proof, and he broadcast that to the nodes, the to the lit nodes. The lit nodes then, as we can see here, validate that data against the blockchain. Is Bob a member of the DAO?

And then if yes, each of these nodes generate something called a decryption share. You can think about it as like an authorization and sends that down to Bob client side. And this is what's really really cool about MPC is it's almost like a client side consensus. There's no interaction between the nodes. This is it's like a nice mental model is similar to the way torrenting works, but rather than Bob collecting little bits of a movie, what Bob is collecting is little bits of the ability to decrypt that symmetric key.

So Bob collects all those decryption shares client side and now he can decrypt that symmetric key that Alice initially generated and then use that to decrypt the video. And yeah, he's in business. Um, and so now we'll walk through a couple specific Oh yes, one more thing I want to mention before we get to the use cases is it's not an exact definitional match, but this is kind of like what they would call identity based encryption. And I pulled this page from Wikipedia. And as you can see, like identity based encryption to date does require a central authority to do that key provisioning.

And that's the invention that we've have here is being able to do the key provisioning but without a central authority in this threshold oriented way by dividing the key up as we discussed earlier. And now let's talk about some of the use cases. So if you're familiar with lens protocol, it's an NFTbased social protocol. Inside of the Lens SDK, they have the notion of gated publications. This is a screenshot from the Lensster app where when somebody makes a post, they can say only collectors can view this or only people who follow me can view this.

And it's the same process that we talked about before where that poster or creator that content is encrypted in the lens case. It's stored on IPFS and then lit is being used to validate does somebody hold the follower NFT or does somebody hold the collection NFT? and if so they're able to decrypt that content. This is also being used by Orbis Club uh which has built out a social graph and chat interface using ceramic as the storage mechanism. So similar kind of mechanic uh this is a screenshot from the orbit uh SDK and so lit and the key provisioning that we're talking here is being used in the context of token gated messaging and chats.

We'll see if this is going to play but I'll be able to talk you through it. So what we're looking at here is quite cool. This is an example from a team called Krebbit. And what they're doing is using a third-party vendor to Oh yes, full screen. Good idea.

What we're seeing here is they're using a third party vendor to validate some KYC information. Um, and then that KYC information, that proof of somebody's age, for example, is going to be encrypted client side and also signed by that vendor. and then in this case stored on ceramic and then that user gets selective disclosure around who can decrypt that information and so like selective disclosure I just want to define that for a second a kind of a a web two analogy of what selective disclosure is if you've ever signed in with Google and you see that screen that says hey we would like access to your contacts or your calendar or whatever these scopes might be that's obviously if there's three parties in that system there's the user there's Google which is custodying the data and then there's the third party app that wants that data. In this example that's zeroarty data. That data belongs to the user and then they can have a direct relationship through provisioning a decryption key who in this case can see um who can decrypt this KYC information.

Just in the interest of time, I'm going to continue to move along here. And then uh I know the team from streamer is talking later. They've been up to some really cool stuff around using this key provisioning mechanism. Conditional decryption is another way to think about it. Access control is another way to think about it for having a distributed data marketplace.

So that is some use cases and how the encryption works. Um, oh yes, and then there's one more feature that this actually just I just put this in last minute. This got uh released two days ago. So for about the past year and a half, uh the SDK was set up to only be able to provision decryption keys or perform the access control based on any state data. Uh it is now possible to have this network provision decryption keys based on any HTTP endpoint, any API.

So really any data on the web can be essentially used as the input for an ACL or access control list. Um and this feature is called a lit actions conditions. And I'll talk more about lit actions in just a moment when we get into some of the signing stuff. And so the product uh around programmable signing and again just going back to the framework that I talked about earlier with public key cryptography you have encryption and you have signing. And so this is kind of the other core feature of public key cryptography.

We have this product called a programmable key pair. Uh and what it is is exactly what it sounds like. It is a distributed custody wallet aka key that can sign based on rules. And um let's take actually a look here. I want to show you what these rules look like.

So these rules are encoded in JavaScript and what we can see here is um a JavaScript function where it says sign ECDSA. I don't know if you can see that here but basically it is a mechanism in a single function to say I want this distributed wallet to sign on these conditions. For example, well actually we'll go ahead and look at some examples. for example, in the context of um of creating wallets for users. So user onboarding and or what you might call retail custody.

So what we're looking at here is a few wallets being generated via OOTH credentials. So the user in this example is not custodying any seed phrase but also not relying on a centralized custodian to to hold onto the key. Um and that one is really really cool. really excited for that as it relates to mainstream onboarding of web 3 using this distributed key essentially as the user's wallet and there's a lot of really interesting things around like where this touches account abstraction as as well. Another really interesting use case is around DeFi automation.

Um, we'll see how much of this you're able to see, but this is a project that a community team built for using one of these distributed cloud wallets to basically function as an immutable and automated escrow agent for cross-chain swaps. So, Alice sends some tokens from Polygon into this wallet. Bob sends some tokens from uh, Arbitum into this wallet. And then when they both approve the wallet because it can sign programmatically sends the requisite tokens to the appropriate counterparty. And so if you think about like uh OTC deals over the over- the-counter uh trading of tokens, this would be a mechanism for not having to have uh like a trusted escrow agent, but basically having code as the escrow agent between blockchains.

And what's being shown in this video is just the process for sending the tokens to this programmable key pair uh and then approving it and then and then receiving them. Awesome. And then the swap is about to happen. And all of this stuff is on our Twitter if you want to look at these videos. We put out a lot of content as well.

And then this uh last one is from Krebbit as well. This is really cool. Um, if you're familiar with what verifiable credentials are, it's basically some signed JSON linked data. Uh, in this case, Krebbit, as we talked about, stores this data on ceramic, but it's like who is the signer of that verifiable credential? What is the key that you trust?

And so, what we're looking at here is a user who is connecting their Discord and then it is this lit, this MPC network that is signing that. And so this user can basically add in a privacy preserving way their Twitter name, their Discord name, etc. to their data backpack as a signed verifiable credential. And the signer of last resort isn't the user because how can you necessarily trust it's one user versus another, but is again this distributed signing mechanism. And then so I'll kind of uh end this to say where are the keys stored?

Coming back to this key question, um, and it's really interesting. So, we're right now in the midst of rolling out the the network. Uh, there's a handful of node operators, and I just want to kind of make a mention that if you want to operate a node in this network, there's a a contact us form right on liprotocol.com. We are like right in the midst of of rolling this out.

So, if that's something that you're interested in, please do get in touch. And uh, maybe I'll have a time check here. Um, but if there's maybe a few minutes for questions, I would be glad to take them. And thank you so much for your time and attention. [Applause] If anyone have questions, let me know.

There is a question, but I think I lost the mic. Yeah. Oh, there it goes. Hey. Uh, so the question is how does this different from new cipher and threshold network?

So what they're doing is something called proxy reenryption where the input to that function is a key. So I could say this key used to be encrypted to person A but I want it now to be encrypted to person B. Um, and so the input is a key and so that person who wants that key to be re-encrypted to another party needs to be online. It's very very interesting technology but for the specific use case that we were trying to solve around conditional decryption we actually looked at using them a few years ago it didn't quite meet that which is why we went through this MPC key provisioning mechanism um but yeah it's really cool but basically the the the difference is that in proxy reenryption you start with a key and it gets encrypted to another party where in what we're talking about here around conditional decryption the key is encrypted to the network and the input is a rule and then the output is that same symmetric for Kate. Yeah, it's it's on.

Okay. So, I have a question that uh how is it different from the REN BTC's MPC? How is it different from the REN BTC's MPC? REN BTC NPC. Yeah.

So, RENB BTC is also doing like that. So, how is it different from that one? And also, can you elaborate on the part that what account abstraction and multisync put to to these protocols? Yeah, absolutely. So, I'm not that familiar with this protocol.

So, I can't talk to that in detail, but I'd be glad to chat with you right after this and uh and learn more. Um, as it relates to account abstraction, to me, probably the most interesting use case that I've seen around combining MPC keys with account abstraction or smart contract wallets has been around user onboarding. Uh there's a there's a team called patch wallet where basically they have set up an AA or account abstraction wallet where a user who's new to web 3 can sign in with Twitter and the MPC key acts as the signer on the AA uh on the AA wallet and then it lets the user move to self-custody over time. So once they aggregate some assets and some reputation, they go, you know what, I've had enough of this MPC key. I want to move to a hardware wallet.

they can call a function to boot off the MPC signer and and move to self- custody and it's a pretty interesting on-ramp for individuals that are entering the space. We'll talk more about REN too. Any other questions? Yeah. Can you speak a little more to the like the type of conditions you can have?

Like you said something about HTTP endpoints, but can you query a contract state for instance? Yeah. So, so um let's take a look at some of these conditions. So, the conditions like on EVM chains for example can be any like here's an example of somebody needs to hold an NFT within a given collection but also any kind of custom contract can be used as the input for designing this condition. So here in the Moolok DAO contract they create the construct of a share and here you say if somebody has more more one or more shares they can do the decryption and then the new piece that I was just talking about in terms of using even off-chain data it's writing that function in those lit actions that we were talking about earlier that JavaScript and that can be connected to any data onchain or offchain and then return a true or a false and that's just encoded in JavaScript and you can connect to any point there and then You can basically have the lit node say you know if this returns true based on this JavaScript execution environment turning complete connected to anything provision the key to that individual I saw some someone were yeah any other questions yeah ah okay hi uh I just have one very simple question you mentioned uh earlier there is a user case that uh So the the content creators can use the semantic ways to uh encrypt the content informations.

Correct. And uh Bob which is a DA member of Addis can use some way to get this semantic keys from your distribution node. So there is a question is that is it possible that Bob could leak this semantic key because we all know that once you create create a semantic key and it's leaked all the information will leaked online. Is there a way you can create some kind of a time based semantic key which going to change over time? Yeah.

Um, so certainly you could implement something around key rotation, but like you're it's a very interesting question and the question is once somebody has that symmetric key or their content, what's keeping that from putting it on YouTube or doing anything with that? And frankly, there's no kind of obvious solution there. So if you think about like Patreon for example, somebody subscribes to a Patreon, if I'm a patron of Mr. Beast, I can screenshot or screen record that video. So they have access to the key and they have access to the content.

The reality is is that somebody's own laptop, their own client is their environment and they can take the content at that point. One more question maybe. Yep. Um so we haven't talked a lot about the nodes uh but at the beginning you've hinted at at uh at them using secure enclaves in order to not leak this information to uh the node runners, right? Um, so what type of enclave are you using?

Because SGX has been pawned several times and it doesn't seem to be standard for anything. So what how how have you solved? We're using AMD SEV SNP. It's the same processor that's used by uh Google confidential compute and Hashorp. Banks banks use it.

It's pretty new technology. Uh if you're interested in this type of stuff, definitely worth taking a look at secure encrypted virtualization. um it it's technically different than an enclave. Um and the specific use of that it's basically it's not the primary method of security. The primary method of security is distributing the key, but it's functionally a backup method.

And my personal take is that anybody that's working on distributed MPC absolutely needs to be using some kind of encrypted virtualization or enclave. Um because it starts to get really scary uh if like if the node operator can be doing something with the private key material. A AMD SEV SNP. Great. Amazing.

Thank you so much. You're awesome. Dave, another hand. Thank you. Fantastic.

Um, up next will be uh Evenny um who is a co-founder with me of Fluence Labs. Fluence is a distributed serverless compute network and I think all the all the companies that you're going to see all the protocols you're seeing today are critical and all function together. Fluence is unique in being just a compute piece of it. Um, and Evenny's is going to go into a lot more detail about what that means. But one thing I will tell you, it's not necessarily it's not just compute at the edge and it's also just not um um a compute that happens where the data is.

What's critical when you have serverless compute is that that compute has um redundancy and is builtin failover resilience. And that is what I think has been missing in a lot of the distributed compute protocols that um have kind of been have have been out there so far. And that's that's the pro that's the problem that Fluence is working hard to solve. So I just stole a little bit of um of of Genny's thunder here, but um I think he's got plenty more to talk about besides besides that. Um and I think he's ready to go.

So with that, Evan, do you want to take this mic? And with that, Evani Pomrov. Hello. Um, so yeah, I'm going to talk about fluence. Um, so like basic introduction, it's kind of obvious things, you know, uh, we're moving into world of decentralized platform, decentralized compute in particular.

Um and you know if you think of how compute projects in web tree space were designed you know like the the first most innovative for blockchains blockchain the new type of compute where you have consensus but because of consensus it's kind of restricted and slow and and u uh kind of useful for specific use cases like uh digital value. Um and then there was like the generation of projects um building um using blockchain to create uh compute marketplaces and basically it was about hardware marketplaces to to aggregate a lot of comput resources and solve um all the um you know problems of humanity like big big scientific problems or like apply it to some computational heavy tasks like rendering video for example. Um but but we um we've been looking for uh some solution that would allow us to have some general purpose um uh compute infrastructure to put our like application backends on or like you know basically like whatever we have right now in in in a web two space um in Amazon in Google in like in the clouds to put it somewhere like to to to run the actual code um somewhere um securely and and in decentralized fashion. Um and um you know uh obvious thing um platform risk in web two space. If you're building on the cloud, they can shut you down.

They can censor your account. Um if you using um some big social media or like a big platform API like chat GBT for example or like more older Facebook APIs, they can shut you down. They can censor you. they can you can lose business if your business depends on particular um API provider. Um but we see uh similar things happening in web um as we see um you know stories about tornado cache uh with all the um their accounts in in GitHub and everywhere shut down.

Um, we see how how MetaMask and Infurat sends their IP addresses um uh and kind of some some people basically lose access to to the infrastructure and that's um kind of not cool. We want to have something more um resilient and and more universal, more permissionless and open for everyone. Um and similarly to um web 2 API dependency and platform risks, we have similar things in web 3. Uh like today um many many companies in webree um when they build their products on top of onchain data usually their products like if they ship their products as APIs for devel for developers these APIs being hosted on particular servers in particular cloud uh usually managed by the team who runs the project. Um and it means that um whenever any issue happens, any government pressure or you know bad day uh in in some of their team members, they can shut you down.

They can you can lose access if you're using their API. You can lose access. Um and and but the it's not it's not because you know all these projects are bad. It's because there is no just proper infrastructure that you can use to create um your API and and share it for other developers. uh the way that you cannot really um um get uh cut access from them and um um yeah so so we see uh decentralized computing like a kind of solution to um solve this problem and uh um it sits somewhere in the middle between like in terms of like capabilities uh between onchain and and centralized computing like for example uh it doesn't doesn't have any middleman doesn't have any uh particular company that that operates uh the network.

So you should be um in like you should feel good as you are not dependent on particular provider. Um at the same time it's verifiable. Um but it's not constrained like like a blockchain. Um and um you know if we have such infrastructure then it's useful for many many things. uh we could do uh whatever uh you know we could do whatever applications we want to manage by DAO because like if uh they are not in proprietary cloud then the DAO can make a decision about like um application upgrades or like some changes and stuff like that.

So it could be like uh immediately enforceable. You could build all kind of trading bots. Uh you could you could think of you know distributed validators, MPC uh RPC relayers, indexers, oracles um all kind of things. Um and also you can think in terms of like a standard uh ideas about hey let's do better messaging, social media and stuff like that because like you need some infrastructure to uh to build this and basically um this is what Fluence enables you. Um and Fluence is two big parts.

So it's a developer platform giving you tools and it's computing marketplace organizing computing resources from different providers into a network. So you can deploy on these uh resources and um yeah so again uh Fluence is cool because uh it's um permissionless potentially lower cost than cloud sensor resistance uh less dependency on vendor locking um um and secure um a couple words about developer platform. So we're trying to replicate kind of um experience that everyone used to and best experience in the cloud is serverless. So what we have is basically uh several um tools that you can use like for example marine is a web assembly runtime. You can think of marine as as an analogy to to lambda.

Uh it's a little bit not the same thing but you know it's useful analogy. uh we have Aqua which is um our distributed um execution protocol and language uh but it's kind of similar to Amazon step functions or Google workflows which you use to express your business logic on top of um lambda functions um and then there are like some some some other tools that also kind of similar to uh traditional cloud stack um so couple of things about how it all works um under the hood like usually In the cloud when you build an app u usually have some several microservices that gate it u by some API gateway and your like users client devices they you they talk to back end through a single API gateway uh that runs in the cloud and fluence um implements the coordination free distributed execution protocol that allows you to like whenever business logic you program it allows to execute it over the over the network of providers without any central centralized um gateways. So literally um your app is being executed um without um you know getting back and forth to to single uh single place. Um and um um Aqua exists as a as a you know scripting language that allows you to express um algorithms in terms of distributed network. So you can say for example if you have some tasks where you need to calculate some average of let's say um bitcoin price um you can have the function that executes that that um calculates the price on one machine and you can have several such nodes that only host this function and only provide this function and then you have other machines other nodes that provide function that does average um calculates average from the prices And then you have this script uh saying I want the input data to go to first to nodes that um calculate the price and then force them after they calculated the price to send this data to nodes who calculate average and then to the calculated average to send to the um some some another user or like some output database or somewhere else and this will be executed by by the network by these participating peers.

uh without any central coordination. They will not be um sending you know data back to uh initial client. They will not be sending data to some blockchain or somewhere else. It would be just like coordinated u over the network. Um and Aqua is super useful to build um all kind of distributed um um systems from the ground up.

So from simple things like a pure discovery, resource discovery um to um things that we used to have in the cloud like um fault tolerance, load balancing, failovers, autoscaling um and stuff like that. Um so basically what we have right now like um some of the things exist right now um um and um some of the things um end up to to um like we commoditize some of the things into um more general concepts like for example we introduced concept of subnets and subnets is basically um uh the ondemand subn network of nodes that are providing some um piece of application. For example, subnet could be like replicated um having consensus um provider of some data. For example, you can have like a IPFS subnet. If you want a fault tolerant um provide provider on of IPFS data influence network, you're just rolling out IPFS subnet and then uh every every node participating in this IPFS subnet will be connected to IPFS network and they can optionally have consensus on top of data.

They may not have consensus on top of data. Um you can basically program and customize the the coordination mechanism between these nodes in the subnets and by default fluence right now when you deploy your application your your function on fluence it will be deployed to on demand subnet. So um the nodes will will opt in into uh providing your function they will um coordinate with each other and you can customize the way they coordinate. you can um implement it with basically um writing aqua algorithm. Um so like fluence network is heterogeneous.

So every every pier is different. Every node is different. um it could host like every node decides basically whatever uh applications or functions it hosts and every every um node can uh announce and advertise that okay I'm I'm I can provide access to this this and this external things like um data or like a blockchains or external APIs and stuff like that. So every node can be connected um to um external data and then provided into the into the network uh for for the functions that run in the network. Um so the next thing is um computing marketplace which is you know if you're familiar with things like filecoin filecoin is a marketplace of storage providers.

We're building marketplace of of comput providers and basically like if I have some compute capacity some servers um I can join the network I can say okay like my um you know I I going to charge this amount of money uh for my um resources and also I going to provide these types of data for um applications on the network and then I compete with other providers and basically whenever I deploy my application I can deploy it to many many providers at the same time um by um rolling out sub network. Um and uh the other thing is we um like basically when we think of um decentralized um computing infrastructure uh we want to like we think a lot about security like how do I like if anyone can join the network anyone can be provider how do I trust whatever they execute right so um and um in many solutions that we see on the market right now it's basically I have to trust the provider I have to trust that they're going to do the work correctly ly um and what we are trying to do is uh we're trying to bring cryptographic proofs to any types of execution and um because of the design how how the fluence works under the hood because of this aqua and marine components we have several types of proofs. We have proofs on aqua execution which is like a proofs proof of um this um distributed that that this distributed execution were executed correspondingly to the script and all the nodes that executed every piece of it um you know signed the data correctly. Um and so so the flow of the computation is correct. Um then the other part is that the actually the function that every peer was executing uh is correct.

That's the proof of execution. And then um the other thing we want to bring is um capacity incentives which basically when providers will prove that they um they own some you know amount of compute capacity they can prove that they they own it at the at some moment of time and then based on this we can like incentivize them with tokens to to be on the network to grow the network faster. Um so um how like where where we are right now um um basically all these proofs are uh so proof of proof of processing proof of aqua um is coming soon like maybe in a couple of months uh all other proofs are down the road. Um in terms of like developer experience and developer platform we are much more advanced. So um this week we are uh hosting several workshops where we'll be showing the uh developer experience using fluenc it kind of like it it the what we are releasing this week is basically the smooth experience so you can uh create projects and deploy it easily with like couple commands.

Um and under the hood it will it would do all the complex work. would uh create u the subnet um from from the nodes on the network. Uh they will actually uh participate in the compute marketplace that would be like hidden from basically like abstracted out from developer tooling. Um so they would um under the hood would put some like token stakes that would um um you know coordinate into the um compute deals um and stuff like that. So like basically the state of the of Fluence right now is um developer tooling is advanced.

So you can build applications you can deploy on the network. Um the compute marketplace is on a test net. So like all the deals and and stakes and stuff like that it it like it works but it's not live on the mainet. Um and then like we we be going to work more on u implementation of proof security and and moving u the compute marketplace uh on mainet after uh proofs are ready. Um yeah so some some of links um obviously and and um a couple of things that also I wanted to cover um we going to host uh the several workshop this week where we'll be showing the um one of the example applications like the simplest application that you can create on fluence it's a distributed um RPC uh resolver basically it's sort of decentralized in Fura uh built on fluence it's a uh app that um where when you use it, you can deploy your own instance of um RPC resolver uh that you're going to that you can use with your um web tree app.

Um and under the hood it would be uh load balancing requests to uh different RPC providers that you can specify. Um and um basically this is like this RPC this nodes that providing access to to RPC providers would exist as a subnet on fluence network and all the RPC requests from your DAP would be routed through Fluence network uh to one of these RPC providers based on the Aqua algorithm that is written into this example application and that you can customize. So we have bounties uh uh feel free to check out uh yeah and uh um other events u workshops join us um this week um yeah thank you uh any questions to if yeah one minute can we have mics a little bit louder because we here in the second stage page more. Hi. Uh yeah, it's very cool.

I love serverless. I mean I think serless is very cool. But I have two question for you. First is that in today's computing services in cloud services serverless is not entirely replace all the computation like in AWS still I think more than 17%age of the computing resource comes from EC2 not from serverless. So the first question is how do you think the future of the web three of the computing do you expected that the developers will use all their computational power and uh their resource in serverless which I don't think is possible there is still some kind of computational task which serverless cannot take so do you require the developers in the future going to do a combination of the web two e2 Q plus the decentralized serverless to do the things.

Yeah. The well basically we we're looking at um Docker as well, right? Like so so the thing is like you can um create secure system if you um have like like basically like if you if you build on Docker, it's super hard to make it secure. It's super hard to uh build proofs uh for the execution of Docker. And you know you have a lot of other um issues with you know um slow start of docker containers and the amount of memory they take amount of resources they take.

So but I I agree with you like you cannot put everything in serverless. So like mainly right now we are focusing on was serverless experience but like at some point docker will be there it just like will be a little different um security model for running docker on fluence. Okay, my second question is about the security because when we're running something no matter it's in EC2 or serverless sometimes we have to put some like security stuff inside like connection string to the database or some kind of a key to the API call. So in your serverless computing stuff if we how could we trust that we can safely put rose connection stream or the security key inside this random node and uh also beyond that you mentioned about you will do some proof of something to guaranteeing it's going to be execution by the way of the script but how could you going to guaranteeing the node won't link the information or data during the runtime pan out. Yeah.

Yeah, that that's a good question. So, um with secret keys, um we are like it's coming also like it's not there yet. So, right now basically like you can pass the key to the node to your function and deploy this function to the node but then the node will be able to like you know scan memory or something and and just see the key. Um uh so the solution is u basically like end to end encryption. Uh so you protect it from at least network nodes not seeing your key and then um using like secure enclaves on the nodes so like the node doesn't you know cannot cannot access your key and then um it it still lives some sort of um trust to to the node provider because like um you still trust the provider that they run proper secure enclave uh and stuff like that And you know the only other option basically that exists is you always use MPC for signing whatever uh for accessing whatever external APIs um and the nodes on fluence network should only um should only get the shares of the key and that's that's the solution.

Okay. Thank you. Yeah. Thank you. Yeah.

Love your presentation. And so I'm really curious like if you could elaborate a bit more about how the execution flow or how actually the deployment flow works. Say I want to deploy something like BFT related, right? And then uh how do I contact with your P2P network and in the process, right? Say uh the nodes are executing some BFT logic and then like some nodes goes offline and how how do you like uh do the fill o over uh and in the process like do the nodes like they just talk to each other and know each other's uh like performance ranking like how does that process work?

So basically um your BFT algorithm is part of your application. So like you you write the like you you have to implement this um algorithm for of how the coordination between nodes will work and uh fluence protocol gives you discoverability. It means like you when you write this script you can say okay I want to like if I see this you know pier not available I I should you know replicate uh this to another pier or I can call this here and there. Um and then you deploy it to like to network. when you deploy to a network, you deploy it to some nodes.

So it means that uh some nodes will have the basically like the the instance of your application and after they have it, they can run it, right? So so so um it's a little more complicated but like uh you can um basically like you can create chron jobs, right? So uh you can u run this like you can trigger this script by time this script that you written will do whatever you written like we'll go to this node and send this piece of data and we'll wait for this response and then they will you you can write this coordination of course so uh say in the case of uh you know me running some BFT logic right and then you know some nodes goes offline and then the the the nodes that's currently executing will be finding some peer to uh basically fill up the the spot right and in the process like do they know like which peer is better or worse you know how does that part work so this is right now is not part of you know default protocol so like the the protocol doesn't um give you automatically like you know substitutions of nodes that that went offline or something like that um it has to be part of your application but we working into like you know for you to have it as as kind of libraries sort of when you build. Yeah, thank you. I saw some other questions here.

Um, yeah, you you go first. Uh, in your example for Aqua, it looked uh it looked like a trustless map reduce. Uh, was uh was that just an example or is uh is it more than that? Like can you do more than that with Aqua? You can do like any distribute algorithms.

Yeah. Like this this was just a map produce example. Okay. Okay. Got it.

Kind of related to the previous question in terms of how the nodes are selected or who does the selection. Say if um I want my app to be run by like five nodes um and then fulfilling certain criteria, right? um how is the process of selection done or who are the person to select? Yeah. So, so if you deploy into compute marketplace which is like a basically public network of providers um you have to make a deal with them, right?

You have to negotiate the price and you have to negotiate whatever you're going to run on them. Uh so this is a part of um deploy deploy protocol that like Fluence just gives you. Um so this kind of negotiation um thing currently at the most basic setup uh the because the compute marketplace right now is not available for everyone I mean like for every provider it's uh um mostly nodes that runs run by fluence labs um currently you deploy like when you deploy your application uh fluence lab nodes uh see that you want to deploy it and like basically random subset of them say okay I going I host it. I like this application. I going to make a deal with it.

But this is the part of like making deal. Sorry. How's the price right now for how's the I wonder how's the price right now? It's free. It's free.

Oh, okay. Great. Brilliant. Thank you. Yeah, we love to hear more questions and we have time for it.

Any others? Yeah, maybe. Oh, hi. Uh is it possible to to run tender mint or cosmos uh consensus on top of Aqua? Well, if you implement it in Aqua Yes.

But is it technically feasible to implement it? Should be. Um here's Bernard who is our chief scientist, you can ask these questions to and is it possible to run was modules deployed to Fluence network on local device? So if you I want to just download the package and run it as a wasmom at any platform. Sorry I didn't get it.

So I want to download some fluence package to my iPhone and run this application like maybe this is a bot or conversion library or what other application will run on top of fluence? Well you you need to have fluence node to run the the application. I mean like you need to have aqua virtual machine and you need to have a marine execution like execution. Thank you. Great.

I think we're good. Great. Thank you. Let's give a hand, please. Thank you.

And you know, one one question that came up early I want to address is is everything moving to serverless. the way if Genny had a slide up there earlier. You know, the cloud has a dominant share of compute now, but there's still people running compute on servers in companies in businesses, right? So, it's been a long transition over decades to the cloud, and we expect there to be a transition to serverless decentralized over time as well. It doesn't happen all at once and there certainly will be applications for which that's not relevant but over time serverless will probably take a material share.

Um happy to introduce Harry who's going to be talking about a super exciting topic which is the training of artificial intelligence models using decentralized compute. And I think there's probably no hotter topic right now than the chat GBT, you know, um, LLMs. And that is has a terrific overlap with decentralization. And I think the further these models get in use, the more important this decentralized training is going to be and the more more we're going to recognize the need for it. Fluence actually fits into this, not from a running of it, but um, or training of it, but from an actual running of the models.

And so when you think about LLMs, there's the training which is massively compute inensive and I think that's what you're going to hear a lot about from Jensen and their advantages in doing that and that has um really open- source kind of um implications as well. But then once they're trained, they also have to be run in a decentralized way because there's lots of censorship potential in the actual running of the models. I'm actually giving a talk on on Thursday Denver on on exactly that topic and on Fluence's potential role in it. Um but that's separate from the actual training of the models which is a more intensive computation more cost intensive um process. So I think um with that we're about to learn a lot more about that exact process and the cost and um and security benefits of running it um with Jensen.

Okay. In in 20 seconds We good. So that Harry from Jensen. Give him a hand. Thank you.

Perfect. Cool. Uh great to be here everyone. And um hands up if anyone got a t-shirt or a hoodie from the back uh the back stand. Few a couple people.

Okay. There's lots back there and we have to get rid of them. Um so um I'm going to do this presentation minimized because I can't uh connect to the Wi-Fi here. if it changes uh we'll we'll go ahead and do that. So just to kind of kick off um we're going to talk about uh kind of three key things today.

Firstly, deep learning as a topic area. Deep learning is something which uh is in the public eye uh to a huge extent currently. Uh lots of people are talking about it. Lots of people here are talking about it. We've been doing these conferences for a while and you know it's it's good to hear it kind of coming back into the back into the kind of uh the limelight.

Uh so we're going to define that quickly. We're going to talk about the compute problem which is inherent in deep learning today. And then finally, we're going to talk about what Jensen's doing in terms of building a permissionless supercluster for deep learning computes. So to kick off, we'll talk about what deep learning is. We'll give some examples and then we'll talk about the kind of wider market.

the the easiest way and I think I described this to some of you over the stand at the back to think about deep learning is to think of it as a subset of machine learning and inside of that machine learning a subset of artificial intelligence. If any of you have ever done any algorithmic trading or if you've ever kind of done any sort of logical programming ever, uh you could make an argument that artificial intelligence starts when you tell a machine to do something and it's able to operate on its own and execute that task. Simply here, you know, buying Bitcoin under $30,000, which maybe wouldn't have been a good trade. Um, machine learning takes that idea of asking a machine to do something, but it lets the machine draw the conclusion about when to do it. So, specifically, you give a machine lots of data about the price of Bitcoin versus dollar and then the machine determines say using a line of best fit when the most optimal point to make a trade is.

So, like above the line sell, below the line buy. Deep learning is a subset of machine learning with two kind of key caveats. The first of which is it uses vastly more data orders of magnitude more data. So if you think about some examples like driverless car um image recognition you have to have hundreds and hundreds thousands of hours of drive of a car driving around with the inputs to the steering wheel to the brake to the gas etc in order to to to build a network there. Whereas statistical machine learning, classical machine learning typically uses smaller data sets.

And secondly, they use neural networks which are models that roughly approximate the biology of the human brain, but ultimately just allow for something called hierarchical feature representation, which is essentially the ability for each consecutive layer of a network to learn something different to the one before it. to kind of paint a picture of this uh free blue on brown did a fantastic uh overview of uh how an image uh recognition model works for a handwriting data set. This is the emnest data set if anyone's familiar with it. Essentially, you take an image, you make the image into a vector and then you push it through lots of layers and you know you know a four handwritten four equals a four. you can tell the network that and over time a network learns to slowly calibrate the various parameters it has in order to produce when it sees a four it's never seen before the number four uh in terms of an output.

Uh the idea here is you expose the model to lots and lots and lots of data and over time it slowly nudges down to understand exactly you know what certain images mean in terms of the outputs. um the a kind of more mathematical way of thinking about it is as a kind of loss space. So if you have say the image problem, the more you expose it to kind of different styles of handwriting maybe maybe slightly blurriier um blurriier uh images of handwriting etc. you're able to over time find the kind of global minimum in a search space where the model is appropriately generalized to the problem and you could get a totally new handwritten number show it to somebody show to the model rather and then be able to classify it correctly. The trick is though as we've said lots of data and also that data has to be exposed to the model a lot and that typically means enormous computational capacity is required.

The kind of flip side of this is the more compute you have, the crazier things you can do. So these are kind of at Jensen our kind of four favorite examples. One of them is the neural link uh monkey pong studies where they use neural networks to process monkey brain signals in order to make a brain computer interface allow it to play pong uh remotely. Secondly, if you think about whenever you're on a video call, many video calls uh or video platforms rather, they use uh a form of compression which uses machine learning to essentially upscale the image. Um so you can have a kind of identical bandwidth to a normal codec, but using this kind of machine learning codec, you're able to kind of increase the resolution effectively.

Thirdly, one that everybody knows recently is chat GPT. This is the uh kind of output of an enormous neural network which is trained on the majority of the data on the internet. Uh so the kind of scale of this is kind of quite quite difficult to kind of frame. Basically internet scale text data sets put through the model you know more than once in many instances although we don't know yet because the research hasn't been released. And then finally one of the classic examples of driverless car um image recognition.

If you want to look at this kind of more from a market perspective, every 3 months the average state-of-the-art model size doubles. So essentially like for like doubling the compute requirement of anyone using uh using those models. Uh and this corresponds to a roughly $2 trillion market by 2030 uh for hardware. So it's hard to understate a the speed of advancement in the space but also the kind of enormous economic uh e economic kind of consequence of that advancement. So to quickly summarize on deep learning, it uses um artificial neural networks to learn patterns.

It requires lots of data and crucially for the rest of his talk, lots of computational power. So lots of compute cycles. The market's enormous and as we've seen recently of chat GPT and we'll continue to see as the world gets weirder, um it's going to completely change the uh modern human experience. So at Jensen, we're solving the compute problem within this um within this kind of scenario. Let's talk about three things.

So principally the key issue which is a price versus scale trade-off. We'll talk about the supply side issues and we'll talk about the concept of freedom of compute which is something that fluence mentioned. So everyone's familiar with the kind of the kind of bad guy uh in web 2. Um many people kind of they don't usually put numbers to it. 61%'s the gross margin on EC2.

It goes up to sort of 70% on Azure. Uh it can be higher for more kind of bespoke comput providers. essentially all if you're trying to train something on the order of chat GPT over half the cost for training which is the main cost is going into someone else's um kind of bottom line profit uh which isn't very helpful if you're trying to advance the frontiers of of deep learning typically when you want to train a large neural network you have kind of a few options you can either buy all the GPUs yourself which is really only an option if you're a large player um or otherwise you basically have to work with AWS. So for a Nvidia A100, which is a kind of standard deep learning uh GPU on AWS, that's going to cost you roughly $4. If you use a specialized deep learning comput cloud provider like Cororee, it's going to come down to roughly $2, but you won't be able to get as much as you could have got on AWS.

And if you go even lower, you could buy the physical A100 yourself. The cost is very low, but it's very, very hard to scale. This creates an issue whereby if you want to compete with Google or you know Microsoft you have to essentially pay an absolute fortune. Chat GPT for example is owned by Microsoft. It's trained on Azure uh compute farms.

Uh the original deal they did with chat with OpenAI was for a billion dollars of Azure credits. Uh that's very difficult as an outsider to compete with and most people are outsiders. Secondly, even if you did have access to that compute, it can be turned off. uh this is something which is everpresent in these conferences. It's something we think about a lot.

As neural networks begin to replace not just human decision-m but also speech I mean chat GPT is a speech bot. It is a language model. We've kind of made the sort of we were in the kind of third chapter of technological advancement here. We had originally kind of constitutional biological rights. You know you can say certain things have then shifted over into kind of transistors around the middle of the 20th century.

And now we're in a position whereby people can be programmatically censored. Models are, you know, being requested by court dictate to have kill switches put them in in the European Union. Um, and there's now, of course, a scramble among all the states in America to enact laws to prevent uh large language models and uh their consequences. But more broadly and maybe more relevant for this audience, uh there is simply a huge amount of computational resource which isn't being used in the world today. If you were ever like an Ethereum miner, um you'll know that the kind of glory days are over there.

If you're holding on to any of that hardware, if you want to try and attach that to something which is going to give you a yield, your options are very very slim. Uh and the yield you're you're going to make is a fraction of what you previously received. It's caused many um miners to go out of business, but moreover, it also doesn't provide a kind of incentive for underused compute to to find a find a home serving useful work. So to summarize, oligopouloolists are extracting fat margins. Even if you pay the margin, it's hard to get to scale.

Oligopouloolists, governments like to censor people and we've seen that kind of, you know, adnauseium for the past kind of decade. And finally, there's exoflops of compute which just aren't being used in the world today, which could be you could be kind of put towards useful work. So at Jensen, we solve this by building a deep learning supercluster. We're a trustless layer 1 protocol which is solely focused on training user submitted neural networks. Crucially, when we say training, we don't mean inference.

So when you use chat GPT, you're using the model in a kind of inference setting. It's producing a result for you. We're fully focused on everything up until that point. So all the dollars spent to build Chad GBT and it's kind of um kind of it analogs. We reckon that the price can be up to or more than 90% cheaper than your standard AWS GPU compute using an A100 as a benchmark.

We're able to maintain uh security at scale given a novel verification system that I'll speak about in a moment. And we're seated with over 50,000 GPUs in our community, many of those coming from disgruntled X Ethereum Juan miners. And we're backed by a number of uh of uh leading investors. So just to touch on our verification problem here. Uh when you think about a model learning essentially a kind of a trivial way to think about it is imagine the models as taking a test you know how many mistakes is it making that's the model loss and over time models typically make less mistakes because they're exposed to more data and they've also made the mistake before so they're able to kind of correct for it.

What we saw with the kind of handwriting example. The issue with training neural networks uh in the context of verification is three-fold. The first is neural networks are very computationally expensive. People in our community spend weeks training individual models. So that's an AWS EC2 instance in the cloud running for multiple weeks on end for one model.

Secondly, models are typically probabilistic. Uh they're not very deterministic. So lots of the GPU operations which have made modern neuronet network uh and deep learning breakthroughs uh possible are you know the the speed advances come at the expense of uh essentially determinism. So if you want to do any hashing that goes out the window because it's difficult to kind of maintain uh identical results across different devices. And thirdly and finally these are just very big models.

If you want to kind of parallelize them, if you want to send them around, typically uh typically the network overhead is is is often the bottleneck. Although there are ways to get around that. For us, we solve this problem by using a form of uh polomial Oracle interactive proof and targeted replication based on that proof. Our thesis is that basically as the model trains, you can monitor the loss of the model. that the loss begins to increase on an unexpected way.

You essentially do targeted replication. You pinpoint that part of the process and because you're using a proof, there's much less overhead required in terms of sending around uh model parameters and data. Secondly, we also apply contiguous replication over the top of the model training process in order to prevent what we'd call a laziness attack. Essentially, there's kind of two types of attack we're trying to prevent here. The first one's laziness.

So basically someone wants to get the yield for training a model but they don't want to train the model. That's number one. And the second is vandalism. That's the idea that maybe a malicious actors on the network. They've seen that you've given your model to the network and then as a consequence of that they've decided that they want to you know cause a problem.

Uh our our system catches and solves both those problems. And the kind of consequence is when you think about that kind of previous uh trade-off between scale and efficiency. We're able to basically take that very very cheap unit cost of compute that serve two cents an hour compute that you kind of see in the Ethereum classic mining pools through an A100 and we're able to take those GPUs and apply them to this much more valuable task at a global scale a scale which isn't kind of you know limited by the size of a network to kind of like paint a picture of this um you can think of the kind of being four types of uh well two kind of four types of user in a network two in the demand slide And then two in the supply side. On the supply side, you have your kind of classic Ethereum miner. They might be mining uh Raven protocol right now.

They might be mining some basically any number of proof of work coins which are materialized post the Ethereum merge. Uh if you've got an A100 standard deep learning GPU, you're typically looking at 2 cents an hour um if you're lucky uh for for you know maxing out that GPU. Equally, if you're a cloud provider, so let's just say your your main business isn't Ethereum mining. It's not even web free, but you've just got kind of spare compute cycles. Uh you want revenue predictability.

We speak one of the largest data providers or rather cloud providers in in Europe who for three or four years actually was a substantial Ethereum miner. They made about 30 million euros per year uh in revenue topline revenue from utilizing your GPUs when they weren't uh otherwise being used by their customers. Um these people either want more revenue or revenue predictability. On the other side, you have people who are using EC2 and they're paying through the nose for that same A100. These are real numbers.

You know, they almost don't feel real like $4 on one side and two cents on the other side. But this if you you can look at it right now in AWS or the classic pools. This is this is as of this morning. Um there are people who are paying through the nose for these A100s. It basically means they can train the models for less time or they just can't train them at all.

And then there are some people who use more specialized providers. But even still, we reckon that the price that we can get it to, including the verification, including the network overhead, results in an 87% and 74% saving, respectively. And of course, the benefit to all of this is you can train bigger models for longer. And bigger models being trained for longer results in much more advanced neural networks, which allows many more breakthroughs in the field. If you're interested in either supplying compute, so let's say you were a minor or you just actually have a gaming PC or maybe for some reason you have a number of uh A100 server kind of yeah contemporary devices, we'd love to hear from you.

Uh scan the link uh the QR code. Uh secondly, if you're uh more broadly uh just a deep learning engineer or you're interested in training large language models or vision models, then as well we we'd love to speak to you because we have a solution which will be significantly uh less expensive than the uh the kind of web two equivalents. That's it. Thank you. Thank you so much, Ben.

And thanks for the swag we we have in food hoodies and t-shirts at the table. So yeah, feel free to take it. Any questions, guys? Yeah. Um I think Yeah.

Can you um thank you for a great presentation. So my question is uh when you when you when your team got started um what what's your strategy to bootstrap and scale the network of suppliers? Uh sorry one more time. Um when so uh when your team got started uh what was your going to market strategy trying to um bootstrap and scale the the um the network of suppliers of computation power? Uh great question.

Um so we benefited from the Ethereum merge basically. Uh the Ethereum merge is a kind of uh a blessing uh for us because the typically in these in these in in our world and I probably include some of the other um companies and protocols here today the supply side tends to be relatively I describe it as like coin operated. So if you're a minor we we go to the kind of Bitcoin mining conferences and we were in the various Ethereium mining circles. um these people just want money, you know, and if there's a way to get it by buying an A100 and standing up in a data center or even a shipping container in Serbia, they'll do it. Um and post the kind of Ethereum merge, the um essentially the kind of opportunity cost of uh of mining became became a lot lower because they didn't have the Ethereum one network to mine on.

So that was the kind of first kind of I guess tailwind that we had. Secondly, with the kind of huge interest in uh in deep learning which we're seeing just now, there's demand from kind of hobbyists from people who don't have access to these large clusters from small startups as well who typically get to the end of their kind of AWS compute credit package of like $100,000 and they're like, "Wow, this stuff costs so much money. You know, I'm bleeding cash whenever I try and train a model who are looking for cheaper alternatives." And it was basically going after those people on the demand side and uh the kind of disgruntled miners on the supply side which allowed us to get the initial community we have today which is about 2,000 people. [Music] Thank you.

One more question. Uhhuh. Yeah. Yeah. I see.

Hi. It's very impressive. I have one question because u I think many people had the same problem before. I used to work for the recommendation system for Tik Tok. As you know, we have very large models and we we use very stable cloud services to train our model.

It trends one week like you said wakes. But there is one thing we suffers a lot is that some node will die in the training because of the memory issue, because of the desk issue or because of any possible issues. So if some node fail we have to retrain the whole model again and uh so in your uh solutions decentralized use the resource I I personally think that uh the node the stability of the node will be less stable compared with the cloud solutions. So how we going to overcome with that? What do you think about ML ops?

Yeah great question. Um also could you guys turn the turn the speakers up possibly just for the for the audience of us. Okay thanks. um the um so yeah basically machine learning operations how do we think about the kind of fault tolerance of our system versus the uh the kind of incumbents in in web 2. So there's kind of that you have to kind of um biseect that question.

There's the data kind of side of it and then there's the compute side of it. We've solved the data side of it with a proof of availability subsystem in our network which essentially eraser encodes and chunks data. So it it kind of creates a fault tolerant um data availability layer. In terms of the compute side, that's a good question. Um, and it really depends on the model architecture you're using.

So the jobs on the Jensen network are quite small relative to the overall model. And essentially, um, we chunk you. So if you've got something of the order of maybe GPT2, so a model with over a billion parameters, which takes a long time to train, nowhere near as much as chat GPT, that model will be chunked into thousands of little jobs. What we do is incentivize each individual note provider to number one not go offline. You just can't go offline.

If you go offline, you're going to be severely punished for you lose your stake. But if you do go offline um at the kind of model level, at the abstraction level, you're able to train models in ways which don't require every single individual um job to have been completed. Number one, and number two, you can also see that the job hasn't been completed. And then you're able to kind of uh as a consequence uh retrain that job. The cost of retraining is covered by the uh the node which fell off.

So as a user it's more fault tolerant in the sense that decentralized networks tend to be more fault tolerant. However, at the cost of it maybe being slower. So there's a little bit of a speed cost there. It's an issue that we don't see being an issue in the long run as more kind of institutional players join the network. similar to the way that Bitcoin miners have uh somewhat become institutionalized over the last decade.

Um I have two questions. The first one is do you have some metrics showing um for Bitcoin mining for example we have a farm right at which point it would make sense to get rid of the bit of Bitcoin and do this work number one. And the second question is easier. It means um do you absolutely need I mean using CK proofs um makes your project viable and without CK proofs it would not work. Cool.

Uh two good questions on the uh on the first question. The way we think about this is how uh Bitcoin uh miners think about it which is time. It's basically the time to return the underlying hardware. So, if you're buying a kind of ant miner um to to mine Bitcoin and you're putting it maybe in someone else's data center or or someone else's mine, you think, you know, what's the time to return really on the blended cost of the Bitcoin over that period? Usually, the number that they go for is between 12 and 18 months.

You want to return the cost of the hardware in 12 to 18 months. Our 53 uh cents an hour estimate bakes in the idea of some an individual going out buying an Nvidia A100 on the market brand new putting that in a data center and then the break even cost for doing so including the kind of increased uh verification time required of a network kind of shaking out to 53 cents an hour. So at 53 cents an hour, if that's the kind of steady state price as a Bitcoin miner, provided there's enough demand in the network, you should be indifferent about whether or not you want to mine Bitcoin or you want to mine mine Jensen. Lower than that, it gets a bit different, but you have to satisfy both sides of the market. So that's 1.

1. Uh your second question was on ZK and whether or not it makes the kind of network um I guess you know work. Um it makes it work better. uh it does it's not essential in as much as we could have a dumber more expensive version of a network which uh maybe catches less of the second class of attack I talked about which was the kind of vandalism attack uh however using the the proofs that we use which technically aren't zero knowledge they're just proofs um but they take some zero knowledge research in polomial um interactive oracle proofs and take out the zero knowledge part to to to get a speed increase um they make them all they make the entire uh verification system much uh much more uh a efficient and b uh robust too many question like yeah let's keep it a little bit shorter and we can go with two thank you uh I really enjoyed the talk uh my question is um besides uh neural networks do you think in the future you could uh use uh your application to train other sorts of models that require a lot of uh data and computing powder. Yeah.

Uh we think about this a lot and it's kind of similar to the kind of question of inference as well. People say you know inference is easier to the extent and it's less computationally expensive. Maybe it's a better go to market. We think training neural networks is the market to go for for uh two reasons. Uh the first reason is neural networks neural network training represents a market which is unique in the world in terms of computational expense.

It's going to be bigger than rendering and we already is you know it's going to continue to grow much larger. Um it's something which is foundational to our economy going forward. Many models once they're trained have to be retrained. um for example um and thirdly if we branch out to kind of more statistical machine learning models so for example XG boost or like random forest um while those are used by people number one they typically don't have the same kind of extreme computational requirements as um as as neural networks which means that the kind of the kind of the kind of calculus for someone switching off of AWS onto us is a little bit less clear number one and then number two those models as well we think for many of the use cases which are you know, we're talking like kind of artificially general intelligent use cases where you have um you know, autonomous autonomous machines which kind of look similar to kind of androids or where you have Oracle level supercomputers. Um it is going to be eclipsed by neural network training.

There's another argument whether or not we do compute-l like rendering. Um we think we're better being focused on one very tight vertical which is neural network training. Thank you. uh do you expect that uh all these nodes do you expect them to hold the entire model or are you also compatible with federated learning? It's a really good question.

Um it depends on the size of the model the short answer is no. um for some models. So actually for the the image the handwriting model the answer is yes. But for the um for any kind of modern transformer model or language model um over sort of 500,000 parameters the answer is no. Um the model would be chunked higher up before it hits the node into a smaller job.

Um so they wouldn't have to hold all the model and secondly they wouldn't have to hold all the data either because the data is eroded and chunked and distributed around the nodes of the network. Um, and so when you're doing your verification, are you passing through one layer? So like, and this comes back to the federated learning part. So that means that like if you're are you just are you verifying what one node does through its layers? Are you verifying one layer?

Like how is that working? It's a really good question. Uh the short answer is our our thesis is it won't be federated. So it won't be doing federated averaging. Uh purely because federated averaging isn't the way that large transform models are trained.

it would look more like a distributed machine learning uh workflow like pipeline where if you had an NV linked um cluster uh it would look kind of like that uh with verification checkpoints but the um the short answer is you could do a federated model on top of that as well if you wanted um yeah I can talk to you more about that after that's a more technical question great thanks so much appreciate it Ben so let's give him a round of applause please and coming up next um int introducing Pashant from Spiron. We've already had um very we've been very infrastructure focused and I think everyone who's spoken so far are building critical building blocks for the infrastructure of web 3. But that doesn't help if we don't have users and so what Spiron is building is actually an on is an onboard they're basically an onboarding um effort to bring applications and users to web 3. And so from Pashant, we're going to hear their initiatives to have applications um native to web 3 and bring um the users that we all want to see into the web3 ecosystem. So with that um round of applause for um for Bashant and I think last time I saw him, he was in um we were in Singapore.

It looks like he's come from that climate because he's wearing his jacket inside. So he may be used to a different climate than here. See? Yeah. Uh I am coming from Dubai so it's it's a really hot weather there.

Uh but thank you so much uh Tom and the entire Fluence team for having me here. Um so I'm going to make this entire discussion a little bit more interesting rather than like more focused on the tech side because a lot of tech people have already spoken about a lot. Um and as Tom was stating about like um it's good to build infrastructure today but it's also uh is where we start thinking about how we are going to drive the adoption for it and that is whereon kinds of kicks into the picture. Um we are more focused on uh building the middle layer on top of all of these infrastructure which you are you guys are seeing today. Uh today at Spiron we are proud enough to have aggregated more than around five plus infrastructure out there and um we are also proud enough like uh one of the best tools out there to host your D apps launch your computes and lot more things.

I'll try to dive into much more deeper into it and uh if you guys will have any questions feel free to shoot me up after the after the talk. Um so yeah I am currently working as co-founder and the CEO of a company uh taking care of making sure like spiron goes to the global stage and also making sure is on also getting into the developers hand. Now coming to the talk which I'm going to be specifically talking about is going to be around improving the web3 infrastructure accessibility. Um and um that is what I'll be talking about and these are the feature set which you can go ahead and start using today uh in ispheron like decentralized hosting compute web three storage and dedicated gateway and believe me once you go to the spiron you will find it very easy to use. So uh let's get into the state of the web 3.

Currently um you guys have already heard about a lot about uh the tech infra where all of these people are building uh very core level module module level blockchain uh sovereign level blockchain which is more focused on uh solving the lower level use cases. But if you see all of those uh as a use case, these are the current state of the web3 infra is like u it requires a high learning curve to go and start using any of those protocols lack of automation and toolings. Um so if I ask you today is like to automate the entire server operation of yours or DevOps process. I can challenge most of you will not be able to do it. Uh if you can then I would love to give you a coffee right now after this this uh particular talk of mine.

um highly broken out which basically means like it is it is like if you have to launch a D app you have to literally go and talk to four to five different protocols to make that happen so it's like highly broken out um token is something which is playing a very vital role personally speaking um if I'm a I'm a solution architect for your everyone information as well if I have to integrate web3 tech into my solution I'll not go directly with a token model the reason being because if I go directly to with the token model I don't even have opportunity to go and explore any such kind of technology before even I start using it. Um so that is where the token gap kinds of start playing the very vital role fragmented in various ecosystem again uh it's like you have to so uh if you ask me today I see crypto in two verticals one is called transactional chain one is called infrastructure chains uh transactional chain people are the defy users and NFS and DOS and all of those things but infrastructure users are more around like storing your data assets storing your NFD assets and all of those things. Imagine if you are making a money in infra uh transaction chain but you have to pay for the infrastructure chain and then you have to go for lot of token swap here and there and go to Binance, go to different exchange and get wrecked yourself and then uh once you are done with wrecking yourself then go ahead and stop using the infrastructure completely. So these are the fragmentation which you can see today. Uh lack of grand dispersion model and this is one of the best use cases uh which at spiron we have kind of built over the time.

Um if you see the infra as such as a whole it cannot scale if you give out token to normal like all the developers like that because they will have opportunity to go and dump into the open market and the moment they dump into the open market you know what is going to happen your your protocol is not going to scale anymore you are going to be basically giving out free USDC to people to start partying into the parties out there so that is where the grant dispersion model is kind of a very uh vital role um and at spiron as I personally personally believe and my entire team also believes in one thing. Web3 education is very important and when I say web 3 education it is basically around infrastructure because lot of people talking about D5 NFTs and whatnot but really you will find people talking about web3 native infrastructure and that is where we want to focus on um and that is where our educational materials and things are kind of lying around. Um coming to ispheron and how we are kind of changing the state of the web3 infra. Um these are the uh couple of things which we do. Uh we are the aggregators.

We are building one of the best aggregation out there. What we are trying to do is let's say if bluefluence is building something fluence has a serverless model and everything. Uh what we can do at spiron is we can build a wrapper on top of it so that uh fluence can go ahead and start distributing those rappers to the developers out there within few clicks. So they don't even have to worry about fluence project as such. But they should be worried about solving their use case and that is what we that aggregation kind of means here.

Bridging the token gaps today at spiron once you log into system you don't even require any token to start using any protocols out there. It's very straightforward go as a premium model once you start loving the system then go and start uh working on the token or or even thinking about the token and that is where we kind of play a very vital role. Apart from that uh spiron currently exists on all the EVM chains and on Solana as well. At this point of a time we are scaling oursel heavily into transaction chains so that we can bridge the gap and bring the money to the infrastructure chain so that infrastructure innovation can be kicked in and a lot of people can start building into that space. No code dev tools and automation which is already built in.

So you have if you have a GitHub if you have a GitLab Bitbucket or whatever you use as your repository go and configure entire thing as an automation and it is just a few clicks away you don't even have to like learn anything new it's just state web two but underlying infrastructure is going to be utilized as a web 3 built-in grand disposal so as I spoken about earlier we all have we have uh these things I would love to um after I'll not have enough time to basically show that here but would love to if anyone wants to like discuss deeper into that we'd love to but just to give you the understanding how exactly the uh spiron grand dispersal model work so for example today um let's imagine a scenario today fluence wants to go ahead and give out their tokens to people who are building over overfluence but they want them not to dump over a market right directly so instead of dumping into the market they should be able to use that token to excelate or use their infrastructure so what we have done is like we have built a built an alloybased model into the system uh where we can create a liquidity pool for ourself internally. Uh we give out grant to these developers in a in a virtual uh uh system rather than in a real coins. It will be a virtual coin which is which is a wrapper uh around it and they can just use it in a in the system itself. They cannot use it outside of the system which which basically means you cannot withdraw it out. Uh and also by this introduction of mechanism you also safeguard yourself from lot of legal troubles as well.

So that is where u this disposal model kind of plays a very vital role and then you can do lot of incentive mechanism. So for example we partner with Akash network and uh when we partner with them um we built one of the coolest feature on top of them was the incentive model. So today if you want to go to Akash go to Akash ask them like if you can incentivize us they will incentivize you via their Akash token over by the spiron uh where you can get those token and start building on top of them very easily. education and best support channel. So yeah, out of uh if you are if you're new uh to the web3 ecosystem, if you are new uh if you're moving from web 2 to the web 3, we have a dedicated support channel in discord.

Uh go ahead and open a ticket for yourself. One of our team members will be jumping into there and we'll be helping and making sure like you guys are able to save to the web3 and we'll make sure you have a nice and great experience there. Um so let me play this video. This basically represents how exactly the spiron works and how we basically make sure that it happens. So here on the left hand side there are users in the center there's a spiron and this particular engine which you are seeing which is rotating now.

It can be scaled horizontally in multiple uh nodes. What basically means like we just don't believe in having a decentralized infrastructure aggregating but we also believe in making sure like our infrastructure also getting decentralized over the time and that is how the infrastructure kind of looks like. Our model is very simple. Uh just imagine uh you are working in a you are building a service based company where uh on the other side of the company you have people who have a uh let's say in uh you have a nodes which has working uh capability. You pick those nodes.

What those nodes do is like they just upload the data to the specific providers wherever they want to and spiron what it does in the middle layer is like it make sure it facilitates that particular process so that our users has a very great experience there and in while doing any of all of these things we are building a nice incentive model for all of the people who can basically participate and start scaling themselves and as you can see like on the user side user can be on polygon optimism arbitrana or avalanche or wherever we are u and just start accessing any decentized infrastructure out there. Um again uh just to uh pointing out like uh it's again a chilling point where I just want to sh as well more spiron as well. Uh why is we're on today um is because we are chain agnostic. Um we are we have all of these automation works. Uh if you have a D app which you want to accelerate using and you want to make sure like web3 infra kind of getting used for your D app.

Um go ahead and start using spiron you don't even have to have off-ramp your crypto to make the payment for your infrastructure cost. So go ahead and start using it. And most importantly we have been building this particular space for the past 3 years. So we have learned a lot of problems which infra companies might face in coming days if they are building on top of it. So we are well positioned to make sure uh we we we take the infra to the mass adopted on the on the developer experiences side.

Coming to our achievements which I just wanted to focus on as well. Uh what we have done so far uh we have onboarded 3,300 plus developers. We are very heavy in India. Uh if you go to India and ask about us most likely you will get to know about us. Um so most of the developers we are targeting we were targeting into Indian space now we are expanding globally as well we are getting into Vietnam we are getting getting into another Asian market and we'll make sure in the next one year we will I'll show you the number what we are kind of looking for but that is something which we are kind of targeting for uh we have more than 17,000 plus uh unique web application deployed so far uh served more than 155 gabit within last 3 months uh we started calculating this data from January um 100 plus unique domain which means like 100 plus new businesses are getting served via spiron gateways 50 plus active compute and this is what why I wanted to mention it here Akasha as well so that u the moment we integrated them we had around 50 plus compute which has been currently active um via spheron itself we have around 2.

5k plus a been distributed so far we have 10k a into the liquidity pool as well where we are planning to distribute as well uh via spiron uh this one our our grant dispersal model uh coming to the next what we are looking for achieve to achieve And these are the couple of things which we are on our on our track list. Uh product is solid. Everything is is on the line. The next thing is we are looking forward to onboard next 20k plus developers around across the space. When we say onboard that basically means like they should be by any chance they should have one GitHub unique accounts.

They should have one GitLab or whatever unique accounts that is what we when we call them as a developers or else we don't. If they have certain commits also into the system then only we call them as a as a developer. So that is what those numbers kind of represent like um and that is where we'll be working. We have all the plans in line to make sure like we are able to reach that number and we'll make sure by the end of this year you will once most likely next year when I'm back on the stage we'll have those numbers in house. Um and coming to other part as I said education is something which we are most focused on.

Uh we are going to be launching sphere on universities soon and the focus of the universities is not to talk about defi not to talk about anything else. It is focus is going solely going to be around talking about infra providers and how exactly the web3 infra can solve the bigger problems and issues which most of people before me were talking about like censorship and all of those things. um is on DAO since uh if you have seen that architecture earlier uh there was an arch there was a node which was sitting around and that was uh the DAO part where DAO wanted to introduce and make sure like these Dows are able to make sure and run these dedicated gateways and as not as a founders we are running those gateways um more infra partners we are currently working to on board more infra partners so that uh we can provide various other features on top of it so for example uh today we don't have a serverless execution yet so that is something which we are kind of working on most likely that will also be done. Um the most important part is the infra marketplace. Um so today if you have to launch I'll be very honest.

So if you go to the market lot of people have a WordPress application right and uh one of the best places to capitalize the market is also to provide support of the WordPress applications. So, Infra Marketplace is is a place where all these developers who are building over a web3 infra can go and submit their um in uh their templates their um like they can go ahead and sell their templates as well. For example, if they have built their docker which can run on Akash network or they have built a user interface which can be deployed on filecoin or IPFS or RB or wherever they can go and monetize that by putting that over infra marketplace and other side of the user they can go ahead and buy it and immediately start running it without any hiccups. So yeah uh that is it. Thank you so much.

I believe I have not bored you a lot. Um so again if you if you love what we are building we'd love to connect with you. Ison HQ is our uh headline. We have a foundation which is which runs at ispheron fdn. Um and yeah so let's bring million users and million developers on the web3 infra in coming days.

Thank you so much. Yeah. Hi thank you. Uh it's very good the presentation. I just have one very simple question.

So uh I I didn't really get clear about your decentralized network the details of the technology side. Do you have your own decentralized network or in other words could a normal minor join your network to provide the services to get some coin incentive or your decentralized network your infilt? Yeah. So generally u let me just go back here again. Um this is where I was kind of showing that um if you see this uh in the network that that part this part which is uh their nodes are there those nodes are nothing but our kind we call them as a worker nodes and their job is to uh basically just imagine in this way in this room we have 100 people sitting out of that 100 people 10 people owns AK token 10 people owns fluence token 10 people own RV token or whatever token they own.

What we tell them is if you have these tokens which are just lying around with you and you are predicting that and speculating in the market to basically pump that token up so that you can dump it over the market. Instead what you can do is like you can use that token and generate yield for yourself by participating in the network and lending your token there. So that these workers can what they can do is like they can use your token to upload these assets to this particular decentralized infrastructure and once they do that they will get incentivized and as of now we have not yet built the incentivization layer but our aim is to build some incentivization layer where all of these developers who are all the nodes providers who are becoming the active uh web worker here they are getting incentivized either in the Ethereum token or either in the stable coins or either in spiron token who knows how exactly we will design it but that is what our uh long-term um aim Anyways, but at this stage we are more focused on uh driving the adoption in terms of understanding and letting people know about web 3 first rather than just introducing the token at the first. So okay we can talk that offline. Yeah if you don't mind.

Any other questions? I saw one hand one more hand. No you want to ask something else right? All right. Okay.

Yeah. Um, so we have time for questions because book uh is like um for a couple minutes he's out. Oh, break. All right. Well, thank you Pashant.

Yes, we're done. Thank you. Um, give a hand to Pashant. Thank you. And just um I know Pashant has come from Dubai.

Our next speaker has come from Ecuador, but uh we've just lost him for a moment. Where where is he? Uh he I just saw him. He was sitting right there and he vanished. Um Vuke, who's building Filmmine, which is a protocol for um for D for basically compute on the Filecoin network.

um for both running um decentralized uh hosting um and storage uh that basically allows for uh contribution of storage capacity um and the staking of um Filecoin. Oh, and there he is running in. Um this allows the staking of Filecoin um on on Filmine to basically enhance your your reward profile. Um, so fresh from the Ecuadorian jungle, uh, please welcome, um, please welcome Vuke. I think that's the web link.

There you go. I'm good. [Music] I just finished the slides, so bear bear with me. And also ignore the Solana hoodie. They gave me the hoodie for free because they were closing the store in Miami.

And it's pretty good. Anyhow, uh yeah, I thought I would talk about a bit of a different topic. Usually I would talk about decentralized computing coordinating all the jobs that we heard about today and figuring out how to take like a job from a network and deploy that into a particular provider. Uh today I'm rather going to talk about like what are the implications of all of this but on a token economics level and how to think generally about these networks. So first what do we actually mean by web tree in this uh context?

Anyone has an idea? Uh yeah I mean generally web three was framed by parity I believe in 2018 and it was kind of mixed term. It was uh really cool because uh three is larger than two. So everyone thought this would be actually the next thing but actually there is a lot of ambiguity on what web three is and I think that we are coming now to a point where web three is actually gain like a sense so it's not a one network where you have transactions uh that are uh happening with some consensus it's rather focusing on something that uh provides more of a utility so you have networks that provide a particular utility so you could imagine falcoin being uh utility network. The utility of that network is the storage.

So you provide the storage and you have utility providers and the utility providers in that context provide the storage. You could have leer uh network providing the encoding. You could have the fluence network providing some generalized compute but those are utility networks. We're not talking about Solana. We're not talking about deterium.

We're talking about networks that can provide a particular utility. And in those networks always you'll have like two main roles. One is the utility provider and the second one is the token uh holder that is basically a stakeholder in the entire protocol. So if you look at those two roles you have resource providers. So those are folks that are basically providing the hardware or providing like uh the software that is giving that utility.

So in the case of chain link chain link is providing the feed. That's the utility that the chain network provides in the case of lier again like the encoding and so on. Well, the token holders are just to uh holding the tokens of those individual protocols. Now, uh how does a utility provider look like? Uh these are utility providers that can do like some kind of encoding, some kind of computing and so on.

Those are also known as minors. But the minor word is also used for a bunch of other things. So I'm going to try to avoid using it. But you could imagine a utility provider like this or a utility provider like this. These are more frequent in the Falcon network because uh it's not enough that you have GPUs but rather you have some kind of storage but also you need some computing because you need to do a lot of cryptography that is necessary to board data to the Falcon network and so on.

While token holders are basically yeah just shillers and like people that just believe in the network and want to actually be part of that journey. So how does a resource provider interact with the token holder? So usually uh you would need some kind of liquidity as a uh resource provider in order to provide that utility. Let's get a bit deeper into one particular protocol uh which is the Falcon network. So the Falco network does provide 15 xabytes of capacity today.

This is committed capacity that is being proved every 24 hours. So there is a proof of every sector of 32 GB uh that that particular piece of data is actually stored on the Falcon network. You have a ZK mark that is done in the background. Three pabytes of data are being on boarded every day. And uh very soon like uh it will have EVM compatibility.

But the point is that in order for this 15 xabytes of capacity to be on the network available for everyone, you need a resource provider. That resource provider needs to do a set of activities. They need to first provide uh and commit a particular uh amount of storage. So let's say it's 32 GB which is like the size of a sector. The sector is very well known in the Falcon ecosystem but I'm not going to get deeper into it.

Then what the the storage provider needs to do is they need to commit a particular amount of collateral. So like you need fill that will be logged as collateral in the case of the storage provider going offline. Uh and uh that collateral is not small like uh you'll need to commit 0.2 to fill uh just as a commitment and if you're really storing data you would need to commit to fill uh to fill is uh actually 20 bucks and uh that's for 32 GB of data. So the requirement of the liquidity is super high.

Uh and yeah just to walk you through uh how the protocol actually works is that uh once you have committed the collateral uh then you have like 24 hours uh you have the storage power. The storage power is used in the same way as hashing power on the bitcoin network. You're getting rewards because you have the storage power and uh every 24 hours you need to generate another proof so that you'll get like the rewards for the next 24 hours. And basically in that way you're getting block rewards from the inflation that is happening on the network. Now uh of course there is also risks involved.

Uh the collateral is not there just because of the sake of the collateral. It's actually there to uh have the ability to punish a particular storage provider if they go offline. If the data is uh really not there and they have committed that they are going to store the data for a particular amount of time they will uh get penalized. So what will happen in that particular case is that uh the storage provider fails to send uh the proof. Uh so they have a particular grace period in which they can uh not get rewarded but still not get penalized and ultimately they are going to start getting slashed and if uh they are offline for a long enough of a time frame they're just completely going to get slashed.

So like all the collar that they have is just going to be burned because they are not providing the utility which they have committed that they are going to provide to the network. Okay. Uh but this is just one instance of like a web3 protocol. What about the other ones? Guess what?

Uh most of the other ones have like uh a similar model. And the reason for that is that they need the economy that is self- sustainable because if you don't have a demand for your particular governance token or whatever utility token you're using, it's super hard for you to build like a sustainable economy. So in the case of Lipier you have the the abstraction of a orchestrator which is basically someone that would get jobs from the network and would execute those jobs. Now the orchestrators can run also the workers which are basically doing the the encoding or they could just offload that to someone else. But similarly, you are basically as an orchestrator staking the tokens and because you have a particular amount of tokens staked, you're able to get a particular amount of jobs.

So you always want to be staking more. So you get more jobs and with that you increase uh the utility which you can provide and with that you increase the reward that you can generate. And of course when you uh return the results uh to the network, you you're just going to get rewarded by the network. Uh okay. Uh does anyone see a problem potentially here?

I hope yes, but I hope that everyone is timid. Uh ultimately the issue here is uh that liquidity is uh linearly dependent sorry uh the utility is linearly dependent with the liquidity. Meaning that in order to increase the reward uh and with that also increase like the utility that you're providing to the network, you need more liquidity. And now if you roll back and think who the utility provider is in this particular case, it's a minor. Why would a minor care about holding tokens?

They don't. They they care just about generating profits and just growing their infrastructure business, which is fine. Like most of the businesses today work in that particular way. But all of the networks that we have today are basically designed more from a top- down approach where uh the economy is actually dictating how the protocol should be built rather than interviewing particular like personas and trying to understand like what a minor would like to do. The minor uh doesn't care and generally like uh everyone that was designing the web three protocol couldn't care because they had to think about the the economy.

So yeah, generally the reason for that is only the fact that you need to uh create enough demand for your utility token so that your token is not going to go to zero because you're just influencing your economy because if you also zoom out like most of the economies in web three need to have some inflation. The inflation is there not to screw up like the the existing token holders is there to incentivize the utility uh to be provided on the network and uh most of the networks are just going to gravitate towards this model. I haven't seen anything uh different that is not actually like using the utility token and just pushing a lot of demand on it. But how can we actually solve this without changing the the core protocol because that's most likely not going to happen. uh and uh yeah that's something I'm super focused on and that's basically what we are building.

We are building staking for web three and when I say staking there is no staking in web free because like most of those protocols do require a utility to be provided. So when we say staking it's not like Ethereum where you just take it directly in the node. You actually need to coordinate a bunch of uh jobs that will be executed on those uh networks. And when those jobs are executed or the utility is provided like in the Falcon e ecosystem, you're going to get a reward and then you can do something with that reward and that's how you generate the yields. Uh in the case of the Falcon network, basically you have a token holder which in a way just uh sticks in a particular storage provider and because you're generating the rewards uh you can uh generate the yield.

Now, of course, this is how everyone thinks about staking. Actually, it's a bunch of other things that we have to figure out just to make it possible because ultimately you need to do a bunch of things to provide that utility and the better job you do to provide that utility, the better the staking protocol is going to be and with that also the higher yields that you can produce are going to be. So how it works, the token holder just takes in the protocol. Uh the tokens get distributed to the utility providers. They use the liquidity to provide uh the utility and uh then the protocol generates rewards and everyone is happy because everyone makes money.

So yeah was super fast. Uh by the way like I have another set of slides on the computing front. This Yeah. Oh, this one or [Music] Yeah. I thought it was me.

This one or the other one? This one. Okay. So, token holders just taking the film protocol which is the protocol that we have built. The tokens get distributed to the utility providers also known as miners.

Uh the miners use those tokens to provide more utility. Because they provide the utility to the network, the rewards are generated and because the rewards are generated, they get uh funneled to the protocol and then they get distributed to the individual parties. one minute. I am afraid of Yeah. So, I'm I'm going to start with this and they have a lot of backup slides that that I have uh assembled for other stuff that I'm working on.

So, in the Falcoin protocol uh in order to on board data or commit capacity, you actually need to do a lot of cryptography. That's called proof of replication. Uh it does last like four hours in memory. Uh and uh it does require like a full core and uh then you need to pass it to the next process and the next process requires GPUs. Then you need to pass it to the next process requires some IOPS then you need to pass it to the next process requires again a GPU.

So there is a lot of cryptography for this to work because you ultimately had to balance out between having a lot of compute happen in the beginning but proofs that are sent frequently like every 24 hours be lightweight or do a lot of compute like every 24 hours. So most of the compute was actually pushed on the on boarding phase. Now this is just like a picture but actually how it looks like is let me see here. It's actually like this. Oops.

This was the next slide. Yeah. actually and even this is like high level like under this there is another layer. So basically on the uh right side you have the storage providers then you have like the compute providers that are helping us on board data. Then you have the ZK snark producers and like all of these are super different because for the middle process you need a lot of IOPS and a lot of memory and you need like server grade CPUs.

The networking needs to be super good because you are transferring a lot of data. uh you can see that you're transferring 32 gigs between like uh that provider and the the storage provider and then like you can just offload the snarks to someone else and that is basically just a GPU uh activity which a Ethereum miner could do and then that gets back to this process and then it gets back there. Guess what? We built all of this just to be able to stake tokens. So we actually started like as a staking protocol and I thought I would do cool DeFi stuff and actually we we spent a lot of time just building infrastructure to make it possible.

So I I think this is going to happen in the other protocols as well. We are looking at lipier we are looking at many other protocols that are doing snarks and this is super interesting but again like it's a lot of deep technical work uh just to be able to like do a simple activity on on the first layer. Uh okay. The question was is this still uh considered decentralized? Yes, absolutely.

Because we are not the ones running these nodes. We are a SAR building software. I mean I love computers, don't get me wrong. We have a lot of servers. again like we are trying to build protocols that can be bu used by everyone and everyone can participate in them and even then the question is is it really decentralized depends how you build the job cues.

So if the job cues are uh decentralized enough where you can actually get the jobs from the cues and execute that commit that you're going to execute and then finish the jobs. Yes, it's absolutely decentralized enough and the question is where you want to put the line on the decentralization and I feel uh yeah that's something we'll figure out as everyone is building in the space. By the way there are many similarities on what we're doing and what the other teams are doing. So I think what we're going to see is like a more generalized protocol that is going to merge all these protocols. I was hoping that's going to be me building it.

I still hope but like I have a lot of work on the DeFi stuff. So maybe someone else can do it. Uh but yeah, super fun. Uh let me get back to this slide which was the most important one. Uh for the first time we are hiring we need like product people and like protocol engineer.

We are team of 10 people and uh we are funded by some of the best uh uh funds in the space. Thank you so much. Great. Thank you V. Great.

We've got our um very last presentation right now. Nico is on his way up from streamer. Um this is the last piece of infrastructure we're going to be talking about today. Critical piece of it. It is the decentralized data streams.

And I think we're all accustomed to receiving data streams. All of the um financial world right now is a customer receiving proprietary um centralized data streams. Having decentralized data is obviously critical because it eliminates a point of failure and a point of censorship. So as you we think about building this decentralized world, we've got compute, we've got key pairs, we've got um staking, uh streaming is a key piece of this. All of these pieces need to be in place to build this decentralized world.

So with that, I'm going to turn it over to Nico. Hey guys, how are you doing today? Um, I'm Nico. I'm the developer relation engineer of streamer and today we're going to talk about uh the drailized uh real-time data network. So I'm going to start off with a video.

I hope it works. We'll see. It does. Okay. [Music] Okay.

There's no sound, but just read the subtitles. [Music] system. Very much Okay, this looks a lot cooler with sound, I promise. Okay, let's just start um go to the first slide. Okay, so what is streamer?

Um we are a decentralized P2P network and how that actually works I will explain in the next slide. Um but essentially we have topic based publish subs a public a topic based publish subscribe system and if you haven't heard of this don't worry um I'll explain that in the next slide as well. Um essentially we stream data to any Ethereum accounts in real time. So you can get your data from A to B in a decentralized manner. That's stream in a nutshell really.

So streams, topics, subscribers, publishers, what what is that? Um I don't know who who's heard of uh pops up before. Okay. So basically no one. Well, if you have heard of it, um streams are essentially topics.

Um, and if you haven't heard of it, think of it as some sort of a list. Um, where you have publishers that write to that list and, um, subscribers that read from that list, right? So you have, uh, for example, this weather station here um, that is publishing data, writing to this list, to this table, to this stream, however you want to call it. And um then you have the subscriber that can then read uh data from that list. So for example um you have a JSON where you have temperature uh humidity all these kind of things and then you have this application that then reads this data and consumes it and maybe displays it in a dashboard or um I don't know shows you the weather forecast.

Right? So this is kind of streams in a in a nutshell. Um so here we have an example stream um from ultrasound money and what this does is it streams the Ethereum 2.0 stats uh burn stats every minute. So you can see here you've got like 48 then 49 and the time stamp.

um every minute there's data getting published to this stream and then someone can just kind of subscribe to that stream and read from it right now. How does this work? How is it decentralized? How does how how do we get the data from A to B? If we zoom in into our network, we've got this example stream here.

Um and essentially it's a topology of 30 nodes at the moment. The streamer network uh is made out of five five over 5,000 nodes at the moment. But we are looking at one specific stream topology. Um topology is just another word for uh network constellation. Uh so how the nodes are connected to each other.

Um and in this case uh as you can see most of these nodes have four connections to each other not more than four and they have these neighbor nodes and if you publish a message it gets kind of distributed over this whole topology um network. Um how this works I'll show you in the next slide. So we zoom in into this Denver note here. You can see these uh his neighbor nodes um displayed on the map. And if I now want to publish data, right?

Let's say this Denver node publishes um weather data. It wants to publish weather data. So what it does is it it sends this message, this data to all its neighbor nodes, including the one here to Lispin, which we're going to look into a bit more. So it sends the data to the Lispen node and then the Lispen node sends it to its neighbor nodes and so on and so forth, right? It's like a chain reaction.

Um, and it kind of uh floods the network with this message right here, but only within the stream topology, not outside with the five over 5,000 nodes that we have. So, we don't publish the message over this whole network of five 5,000 nodes right now. So if you have let's say this weather app uh you don't want a random you don't want to consume a random data stream for example fridge data or some other data right you just want your um weather data so we have a noiseless uh network there only streams there only nodes that are interested in that stream that uh which are going to receive the the data so that's the scale Um well we did a test of this network with over 90,000 nodes and I believe 85 countries and yeah in over 85 countries uh all over the world and yeah the results were quite interesting. So I just told you right we have around 5,000 nodes in total like globally and we did this test net with 80,000 nodes. So it's quite quite impressive and what we found is that the mean propagation delay which is kind of the delay um until a message arrives at the at your node um is around 400 milliseconds.

So it doesn't doesn't really exceed this uh 400 milliseconds. So does it scale? I would say it does scale because 400 milliseconds is quite nice for a decentralized P2P network. And yeah here you can see it's kind of converging um right so streamer network properties uh fast scalable real time it is permissionless and censorship resistant it's temperproof end to end encrypted uh talk about that in a in the next slide and it is free to use so anyone can use it anyone can kind of you know create a stream uh connect their notes to it and then start start streaming your your use case essentially. So yeah, access control and security uh it's a public network uh you know it's uh how how do we how do we contain um the access and how do we how are we secure?

So I just talked about this P2P network and decentralization and everything. So it's not to um it's not a blockchain. I haven't talked about any blockchain, right? So how do we use um smart contracts and and the blockchain to to uh utilize this access control is um well with a smart contract on the polygon network. So what we have is a stream registry which is essentially a smart contract uh that keeps track of all these streams and um and the addresses that can stream data to this stream.

So publish data to a stream or subscribe to a stream. Let's say you have a chat room, right? You don't want anyone to just publish messages to this chat room and you also uh don't want anyone to subscribe to this data, right? So you kind of need to uh keep track of the axis. So this is this is done in the smart contract.

It just kind of registers okay this address is allowed to read and this is this address is allowed to uh write onto the stream. So in this example um let's say this subscriber node gets gets data right and it is encrypted. So it's like okay uh I need to read it uh but I don't have a key. So it needs to ask for a group key from the publisher node and then the publisher node is like okay well let me first check if you actually have permission to read from the stream. So it asks the smart contract does 0xabc has permission and then the smart contract says yes it does indeed have a permission and then it sends the group key to the subscriber node and is able to read from it.

All right. So again, let's recap what's happening offchain. Offchain P2P data channels. So this is where the data gets sent from A to B and onchain is the access control and who gets to read from the stream, who gets to um send data to the stream and yeah network security. So in an ideal scenario, uh well, everyone's honest.

No one would um leave the network. Everyone would stay online. But in a real world condition, we all know we have some malicious peers. We have people that want to harm the network. Um and this is how we kind of counteract.

So we have two main attack vectors at the moment. Um which is one the Eclipse/Hub attack. Um, if you've never heard of that, that's essentially when uh nodes or malicious nodes come to the network and connect to, you saw the Lisper node earlier, right? It has like these connections and if only if it's only connected to malicious nodes and they would be like, "Oh, I'm not going to send data to you or not going to let data through, uh, you kind of disconnect the uh the node from the network." Um, how do we counter this?

this Eclipse attack and this hub attack um we say we we don't let any node uh connect to we don't let the nodes choose who they want to connect to. So if there's a a malicious node joining the network, it can't just say I'm going to just connect to you and then I'm going to take three other nodes and just connect it to you. So you're not able to connect to to the rest of the network anymore. You can't choose, right? So it's it's uh done by an algorithm um that chooses those connections randomly.

Um we also have the DOS attacks. Um so you know if if the network gets flooded with a lot of messages uh or data and um it it kind of takes takes away the bandwidth um and there's no uh room for actual data to go flow through then we have a DOS attack and we measure this by um restraining um this topology to only the streams right so the data doesn't get distributed over the whole network so if the network. If one particular stream gets attacked, it's not the whole network that gets attacked. And then of course security measurements is also the uh redundancy. So we have a lot of peers and there's actually good notes in the network as well.

Um right okay I'm coming to the end of my presentation. So if you want to build with us um we have this streamer client. So if you want to uh integrate our um technology, we have this npm package and here you can just npm install into your node application and then write some javascript down for example here. Can you see the mouse? Oh yeah.

Um so streamer.publish for example. Uh you just kind of publish this um object. Hello world for example you just publish it and here you can then subscribe to messages from that particular stream. [Music] And if you want and you're a builder, I highly recommend to check out the our docs at docs.

streamer.network. There's some quick start guides how you can just get started and check out how it works. You can also just talk to me. I'm happy to help.

Um yeah, and what can you actually build with it? Um mostly um real time data uh messaging DAPs. So that could be IoT applications. I talked about this fridge earlier. So smart homes, great.

Um maybe you have car data that you want to share. Um maybe you have a chat app which we built actually um right here which is called the chat.app. Um and it's actually going to release tomorrow um as a better version. Um, and yeah, essentially what's happening here, by the way, is this chat right here, this chat room is one stream, and then we keep access and and then you can uh log in with your Ethereum account and send messages to this uh stream or to this chat room if you have access to it.

Right? So, it's like it's almost like WhatsApp, but it's peer-to-peer and completely decentralized. So, that's quite a big deal because everyone in their mom has a has a chat a chat app nowadays, but uh streamer um streamer does this uh peer-to-peer um and decentralized, which is kind of cool. Uh all right. Yeah, if you have any questions, you can either reach out to me via Telegram.

Um again, I do developer relations, so if you have any developer questions, reach out. And if you have any partnerships uh partnership questions uh it's better to reach out to Matthew who's our head of ecosystem. All right. Awesome. That was my presentation.

Thank you guys. Thank you so much. Yeah. Uh any questions from the audience? Yeah.

One I see one hand. Thank you. How do the nodes make money or get compensated? So how do streamer gets money or No, the nodes. The node.

Oh, it doesn't. Uh so essentially you just the nodes it themselves are your application or your IoT device. So you kind of become your own it kind of becomes its own node. Um and this makes up the the network. This is kind of peer-to-peer.

So if uh we both would uh create a a chat room uh where we want to communicate to each other, my phone becomes a node and your phone becomes a node. This is how it works. And if if we have a chat all over the world and it's not just this you know Wi-Fi network, it's uh you know a a node would h uh come up in Australia for example. So this is kind of how it works. Yes.

So I saw that like you launch your tokens. Can I know what what is the usage of the token? Uh the usage of the token at the moment is used for um broker nodes. And so I didn't put this in the presentation because we were bit short on time but uh essentially we have this uh uh bounty contracts for node runners. So if you want to run your own node to provide bandwidth to the network to a particular stream um you get paid by token and this is how we use the data token.

[Music] Hi uh do you use any libraries like lip pp or any protocols like wacu or uh xmtp to build your product? I I don't know that. But if you want, you can just uh send that question to me and then I will just ask the network team. Sounds good. Thanks.

Feel free to contact Nico directly if you have any other questions. Yeah, I knew that. All right, so I think we've finished. Yeah. Great.

Well, thank you all for coming. We are we that concludes the uh today's program for the decentralized summit. So, thanks everyone for coming and thanks to each of our presenters, some of whom are here, some are not. If you have interest in talking about fluence, Bernard um is right there, chief scientist. and we'll give give a big round of applause to Nadia for organizing all of this.

Um she deserves all the credit for making this happen. Um and appreciate it and hopefully we'll see you guys around. We have a variety of other events for Fluence coming up. Um Nan do you want to go through some of those upcoming events? I think that I will just ask you to come for a workshop but it it is mostly for developers.

So if anyone want to try and build on top of Lun so please come on the 1 of March at Vep Hotel and and our breakfast is when and breakfast is also March 1st. So yeah we should have slides about that. Um yeah so the easiest way would be to join our Twitter or Telegram chat. There is all the information about upcoming events. So yeah, we'll be here for the two weeks and see you around probably.

Great. Thanks very much everybody. Bye. [Music]