# Developing Scalable Decentralized Applications for Swarm & Ethereum - Dr. Daniel Nagy

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2017-10-09
- Duration: 14:55
- Topics: blockchain, smart contracts, distributed ledger
- Watch: https://streameth.org/watch/yt-xrw9rvee7rc
- YouTube: https://www.youtube.com/watch?v=xrw9rvee7rc

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on IPFS and more.
https://archive.devcon.org/archive/watch/2/developing-scalable-decentralized-applications-for-swarm-and-ethereum

Blockchain-coordinated decentralized applications represent a radical departure from the client-server model on which most of the currently popular web applications are based. On one hand, such đapps’ approach to scalability is more natural as the computing power and bandwidth available for applications grows in proportion to their user base, while on the other hand the lack of a centralized trusted infrastructure under the control of a single — typically corporate — entity raises unique challenges in trust, reliability and coordination. In my presentation, I will introduce some of the principles and practices of architecting and developing such applications, highlighting both the challenges and the unique opportunities for transcending the limitations of the client-server model. In addition to developing the underlying infrastructure, the Swarm team also develops some example applications that, while useful themselves for end users, are also meant as a template and a starting point for independent developers. Using these examples as illustrations, the presentation will introduce prospective developers to techniques and approaches of both replicating Web 2.0 patterns in a decentralized fashion and going beyond their limitations, taking full advantage of content-addressed storage and blockchain-arbitrated interactions. In particular, the basic building blocks of decentralized, community-moderated knowledge bases (such as maps or encyclopediae), social networks and other forms of information aggregation are going to be presented.

Speaker(s): Daniel Nagy
Skill level: Advanced
Track: Developer Infrastructure
Keywords: architecture, dapps, trust, scaling, trustless, ipfs, whisper, api, legal, finance, hypertext, multimedia, identity

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 2 was held in Shanghai, China on Sep 19 - 21, 2016.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

hello everyone this talk is aimed primarily at application developers and I would like to give a quick overview of the architectural considerations behind developing decentralized applications for aetherium on top of s'more so what's wrong with the web to model well yesterday we have already heard that the web is kind of broken so it has these problems that you have a centralized trust management based on certification authorities you cannot really trust content delivery networks and so there's this other problem that scaling is so it's buying more power from data centers by the person who provides the application whereas demand is just users pounding it and there all sorts of like elastic solutions but none of them so they're ugly they're just a hairy solution to providing more computing power as you have more clients even though there's this natural thing that every client who comes they come with a computer that could just be used so it would be really natural to scale computing power by using the actual computers that the users come with and the problem however is that so trustless computing it comes with overhead costs that are not going to go away so for example if you are trying to host a number of movies it will be always cheaper to do that in a data center than to do it on a trustless network so there's always going to be an overhead and somebody will have to pay for it and you need to keep that in mind but we're working really hard to reduce that that overhead to a acceptable level so that the other overheads that centralized solutions like the profits of unrelated people they will be comparable or maybe even lower so so how do we get from web to to app three first of all you may want to dispose with the notion of clients and servers so for now aetherium ecosystem the app dab the ecosystem is still very reminiscent of the old ways so we have the nodes and we have the clients and we have these things like meter mask and it looks like we're running a client-server network but really it's a peer-to-peer network so as you could see from today's presentations we're really moving in the direction that there's going to be some kind of ethereal node everywhere there most of them will be light and very light nodes but still we're going to have a network where there are many many nodes and you typically don't connect to high powered nodes for your needs you have your own node so the backends that we're going to have their old general purpose they're distributed and basically the the ones that you need to rely on and the are the three listed on the slides so you're going to have a contract content address storage which will be something so in this case it's warm IP FS is hopefully so hopefully we are going to make swarm ipfs compliant and the addressing mechanism and the access mechanism will be compatible or even the same so what I'm going to tell here applies directly to ipfs as well as it applies to swarm hopefully it will be the same thing there's the blockchain based on census so wherever you need global consistency you can solve the blockchain and you will have a synchronous messaging so that's that's the things that you can think of as a back-end but you will not have cific databases that you need to query and so on which has this funny property that particular business logic the business logic of your application will mostly run on the clients which is either web applications written in JavaScript or native mobile applications so you will have to actually consider that much of your business logic is going to be run on the client it doesn't mean that the API will be such that you will have to do the index traversal yourself but in reality it is the client that is going to traverse the index for you so the you will not send queries across the network you will actually traverse the indices as you access them from the content address storage and you can only send the query to the API and it will be executed locally so here's here's an example of how the HTTP is the the Web API it works with swarm so the URLs begin with the root hash of a collection a collection is basically a collection of objects objects are binary files with a mime type so for example it can be a PNG image but so it looks very much like a directory but it really isn't so for example the second example is a map tile where that long code is the hierarchical tile code for for map slides so in a single directory you will have thousands or hundreds of thousands or even millions of files if you think about it as files but you really shouldn't so it's really a a database and whenever you access something like this map tile you're actually doing the know the indexed River so locally which is of course fast because it's it's done efficiently but it's still done locally and the property of the API is that if you change anything in the collection it also happens fast but it changes the route - so any put or delete method will result in a different hash and it will it will return to you the the new hash and of course if you want to have some global state that is consistent across all the all all the users then you can register these route hashes on the blockchain for example in hierarchical in hierarchical name registry contracts so in the last example you see an image which is registered in an album a photo album that is actually Joe's personal photo album the user experience is going to be very familiar to web users that's what we're aiming at so interactive responsive intuitive and so on however Identity Management will also be done on the client on the browser side so you don't have to implement your own identity management with each DAP you you get it ready and you're going to have legal and financial interactions so it's no longer a click-through contract it's something that actually has consequences so it comes with all those things that are also listed on the slide so now I will show you a few examples some of them are already implemented and downloadable from a source repository some of them are tearaway vaporware but all of them have these basic properties so the current route hash is registered on blockchain so that every every user can check on the blockchain which is the current version of the DAT and that's where they that's where they proceed from so we have done away with the problem of security in her in and in HTTP but you need to trust something else on the blockchain most static and dynamic data are stored in a content address storage and global state changes are registered on the blockchain so it's usually global state changes are simply changes in a hash if you don't store a lot of state data in the blockchain because that's expensive however you still need to to get those change changes to the blockchain eventually so that there's a global consistency and I have already talked about about the other things so whenever you have some local data local state like what the user is working with you keep it locally you don't submit it anywhere you can back it up if you want to so the first example is a distributed photo album this is already existing it can be you know you can download it you can look at the source you can learn from it you can take parts so it is completely open source so both the data and the web app are hosted in a swarm and they are hosted in the same collection that's very important so you don't have a separate root hash for the data and that it is the depth and the data together that have the same root hash so you can register a photo albums particular State which means the photos in it and the ordering in which they are presented long term incentives of swarm will make sure that it's not garbage collected that's actually not implemented yet short terms incentives will have the publishing Goes Down which means that if your photo album for some reason becomes hugely popular and half the web wants to see it it will not be a problem for you and it will not be a problem for your users either because the performance is guaranteed performance is improving together with popularity the easy part is that there's no concurrent editing and no comments rating so we have styves up the few difficult problems of that development in this particular example however it's still worth looking behind the scenes so one thing that is happening here is that the blurred backgrounds and the thumbnails they get generated on the client side during upload which is fine for a photo album but let's say you want to move on and you want to do something distributed like you so you want to do something like YouTube in a distributed fashion in that case you need to transport huge video files or you want to transform projections for immersive panoramas and things like that which are computationally expensive so all that stuff can you do that in a mobile phone well you can but you probably don't want to so in that case you need to do delegated computations in which case you submit the data and the specification and the reward and you want eventually to have a result of that computation and the proof that it is correct so there's gonna be other talks in this session which we'll delve into that what I would really like to highlight that there are two ways to go about it either you specify in an imperative fashion in a special blockchain in a special virtual machine what computations you want performed or you just make declarations about the result you don't care how people actually compute that you simply verify that it's correct and then you need to arbitrate it on the blockchain please talk to me after the presentation I don't have enough time to to to explain arbitration here but I think it's really crucial and a really interesting part of it the second example is something like Dropbox distributing Dropbox there's a huge demand for that kind of stuff it has a web app and a locally synchronized folder the first one is already in the works it's I mean it's already usable it's just not feature complete again here you have concurrent changes but they're not not typical when you're syncing between two devices of yours or between a few users and also there's gonna be a separate talk about implementing something like github in this distributed fashion so the third example which would be a distributed social network and the fourth example a map or a encyclopedia with no official truth so these things they are pure vapor where now although I'm aware of some teams that are working on projects like this so maybe we will see something like this in the not very distant future so there are also ways of doing doing things like this in a distributed fashion moreover doing it in a distributed fashion in a Content address storage actually opens up possibilities which are plain impossible to do in the web 2.0 way so thank you for your time and if you will have questions I will be happy to answer them