DAPPCON 2018: Web 3: Building the Base for Decentralised Applicatons - Peter Czaban (Web 3)
DappCon 2018 · July 2018 · 17:01
Peter Czaban, representing Web3, discusses building the base for decentralized applications at DappCon 2018, covering the infrastructure layer needed to support dapps beyond Ethereum's current design. The talk addresses interoperability and scaling considerations for the next generation of decentralized systems.
Speakers
Topics
From DappCon 2018, hosted by Dappcon Berlin.
Transcript
so I gather I gave a pretty similar talk a few days ago at the meetup so I hope it's not not it not too much overlap in the audience but I'm Peter from the web free foundation we we kind of that the organization has been brought to life to make web 3 happen you know we've from the early a theorem days especially we we know that that the derivative of cerium and whisper and swarm and those are supposed to be the protocols that that will enable us to build the centralized applications and you know as we've been building there is
we learned a lot of lessons about about about each individual protocol and the protocols in general and and how we can build applications and what is missing in this technology stack and we are there to dedicate it to to help with the pieces that are currently missing and try to try to bring together the DEP DEP stack of protocols that will enable us to build decentralized applications so I will talk a bit about how do we think about web 3 in general and then like what what do we see as different pieces of it and what do we need to push in order to get to a stage where we have useful applications built on top of it so first kind of let's go back a bit to
to kind of why did we start building the centralized applications in the in the first place and what what what kinds of features do that the centralized applications have as opposed to regular applications and I think a lot of people are just building regular applications now with some decentralized features while they don't keep in mind a full kind of set of features that we want to maintain ideally at all times so we usually are able to avoid some risk associated with sending the centralized system so there is no single party that that controls things so risk of breach or our dramatic increase in pricing and
and any other risk associated with with kind of datas usually flowing so one point can be avoided it's usually much easier to interoperate so those systems usually the protocols kind of enable different protocols to be built on top of them and next to them and make it make it much easier to build this this whole stack so we see many second layer protocols now being built and on top of on top of projects like ethereal and and oftentimes we that they enable their users of the application to own the application rather than rather than having a central project like right now usually there is a central project that
developed something but then ideally we then hand it over and the protocol kind of runs on its own out there and we really want to want to make sure that there is no that the protocol is specified in a way that no one is privileged a priori so there is no no no person no single person that is able to erase everything that is going on oftentimes with when when contracts are upgradable let's say let's say we end up relying on one party or or there is a party serving remotely the result like the data from the blockchain rather than users using the blockchain directly each each participant has a role clearly
defined and can be replaced so for instance if we haven't centralized the RPC and point like it's not it's not very straightforward to then have someone else suddenly provided to provide data for the users of an application that make it make use of that and usually the protocols are designed in such a way that that the interactions are ensured in a in a way to so that so that it doesn't require too much trust it is pretty frictionless to enter with in agreements via smart contracts or participate in those protocols but but and in order to build those all those applications we need to have a bunch of capability so if you think of regular
applications let's say maybe it's not the best example of a decentralized application but but if we think of Buber which is a everyone kind of knows what are the participants who uses it and if you build such an application you need to you need to have the parties transact with each other you need to be able to store some data to serve images to the user you need to be able to broadcast the transient message hey I want to take a ride from here to there and I don't want to record it forever on the blockchain or so we need to application developer when they build their descent very super then they need to be able to have protocols that will enable them to use all those capabilities and what is really
important is is ok if let's say we build on five different protocols that the application that that we want to make and now we want to serve it to the user and we want them to use it in a trance free manner we want to use use it in such a way that no one is still privileged over anyone else and so ideally they kind of connect directly to those protocols and and for that they can they cannot run on their phone for instance nine five different blog chains and to peer-to-peer networking stacks and then try to gather data from all of those in order to use their application we need a way in order to two to four protocols to come together in such a way that we can run a compact protocol stack
on your phone and then serve serve the application through some browser browser or through some through some endpoint on users phone and and this you can have multiple applications on top but there is a tight protocol stack that provides all the other capabilities that are needed and this is where things like light clients come in and this is where integrations between between making sure that a peer-to-peer networking layer is common for for instance for different protocols so it doesn't require only thinking on the application layer but also on the protocol layer and this is this is why why we think that is really important to put a lot of the efforts that are that are currently being pursued in different directions on to on to kind of on the on the on a
single page and basically figure out how they can all work together so here here we kinda kind of it's pretty packed from from that from the lower layer the lowest layer to the highest layers that higher layers that depend on the lower layers of the of the stack and kind of just going through the different technologies that that that we think are important in order to make it all work together so first on the bottom like if either p2p protocols we need some p2p networking for them so we really think a extensible protocol likely p2p consume supply this this p2p networking layer for many different protocols and already
protocols like ipfs and polka dots are making use of the p2p and aetherium as well has plans to transition to lead p2p and this is great because all the development of the p2p layer can be reused and also potentially you can then reuse any discovery mechanism with peers on on each of those protocols across all of them so you don't need to run five p2p networking stacks on your phone then we want some way to have computations that are understood by the whole network and here again web assembly is another standard that is emerging so there is in theorem there's push to have charts run web assembly but but there is also other
projects that looked at it like true bit and and in case of POC other than party substrate it also makes use of web assembly as this computation engine and then on top of that we have a bunch of protocol so then we have the layer one protocols and then the second layer protocols that that provide the functionality to developers so we need those we need block chains and and what we found is we need potentially many different block chains there are some block chains that enable us certain capabilities and some other ones other ones so like there is there is something like a theorem that provides general-purpose smart contracts and is for many for especially at the for prototyping and for applications that
require complex logic but there are networks for instance like blink that enable very fast transactions processing and parallel transaction processing may be with different security characteristics or Z cache that that enable privacy or or potentially many other other chains and so we want all of them to provide those different capabilities then we want to distribute the data amongst amongst refer for the user so we need projects like like for instance big trendy B that is trying to transition into into more permissionless setting to serve the data and then we need p2p like messaging so here there was not that much development we are
doing some research on on whisper and trying to push it a bit forward so that is actually usable for developers when they develop their application and then on top of that we have the second layer protocols so incentivizing storage heavy computation like Gollum and encrypted storage and and so on and then finally we we need we need a something that when a developer sits down and wants to develop an application we need an API that enables them to plug in to all those different protocols underneath right so there's not not it's not enough to just plug into blockchain but ideally we have an integrated environment that that lets them to develop stuff across those protocols and then we need languages to be developed as well for
that like solidity or so here for instance one effort is to make the solidity toolchain compatible with web assembly so that we don't have to redo a lot of the work that we did already with the solidity to change but also developing new languages for instance based on roster and then we need a browser that enables you to serve this application to the user so ideally this router underneath would be running those protocols and then serving the applications to users and yeah ideally running it in a transverse transferring fashion but then I mentioned all those different different block chains and and there is many new projects that are now coming up with new block chains and there is side
chains and people bridging to e theorem and it's all great because because it enables people to actually get their applications out there random and they're reasonable costs and potentially provide new types of capabilities but most of the most of the interesting stuff that is there in new blockchain so if we think of projects like like for instance let's say Tasos they don't really they provide an interesting state machine but all the networking and all the consensus is the same kind of stuff that everyone is trying to everyone else is trying to research and make so it would be great if it would be much easier to create new chains like that that are also light client compatible so you can serve two users the applications
that are running on them so this is this is why the first implementation of substrate was developed by priority but it's a general general protocol that is basically a shell that that produces overhead to build new block chains and and this state transition is is specified in in this platform neutral description like a computation description language web assembly so it makes it just very easy to to get it up and running specify the state machine and deploy deploy a complete in your chain but then once we have all those new chains and they provide all the different capabilities we get again to the problem that that people need to be running multiple different clients and
also to we have a problem that the more chains we have the more spread out the security is so so if there are mining communities that secure different chains or even if the chains are proof of stake the more chains we have each of the chains has to do their ico and has to have enough stake in order to be secure so so this is a big problem especially as the number of chains is growing so we need some way to secure all those all those different chains that are running we we need to need to make sure that they can communicate with each other and and that they can they can again run so that so that an application can make use of them while not running multiple chains at the same time and this is this is why like the origin of the elder of the polka dot project to
help help to make that happen so whatever whatever that shine is and whatever capabilities it provides polka dot is built in order to be able to provide either either full security for a given state machine or enable that at China where we've set there's separate security to interact with the network or even if there is a consortium chain or a chain that is permitting a permission setting they could we could also specify a bridge that enables you to communicate with polka dot network and this makes it easier to experiment with new chains while maintaining those security characteristics and and also the protocol is designed in such a way to be
very flexible so so that so that as as our changes as our needs change and we need to kind of have a new protocol that functions in a bit different way we can adapt to it so we really hope that kind of as part of this of this wider web 3 technology stack those those two those two protocols and foundations can help with experimentation and just to mention like both of those are like you might know that that the initial implementations are being done by parity but but we are now engaging other teams to develop developed implementations of those protocols or so in other languages so that they are even more kind of
community led projects and and as I said like that the key is to is to is to collaborate and make sure that that that we are all aware what we are aiming for and application developers need to be aware how can they build decentralized applications and how to maintain those the central characteristics and be aware which protocols they use that enabled those applications to be used in a transparent manner we need browsers to integrate or be extensible to integrate multiple protocols that are that are fully featured and enable people to write fully featured applications and we need API sign languages that as well are able to not on
the cover kind of one set of needs of the developer but are kind of you know encompass the whole thing and we need we need the higher-level protocols that make it all a bit easier so so as we communicate across those different protocols we need formats and standards that are that make it easier in aetherium is it's great with with all the things like er C 20 and other standards that that really need that also even more when we have this variety of protocols out there so just to go back a bit or two what we try to do to help help out with this with this mission a mission so we do some in-house research on on the number of the topics
that may will make it easier to develop those protocols so so I already mentioned research on whisper but also on consensus algorithms and on other bits and pieces that that are still a bit underdeveloped form of verification with collaboration also with externally with universities we want to give grants and funding for to develop either different pieces of this type stack or the glue that gets like makes it all come together and also community efforts as well to educate people like what what is it all about and I guess the tooling falls into the accessibility initiatives and workshops so making sure that people are actually
aware what is the decentralized application work what qualities it should have and and how do we actually make it usable for people in a transferee matter so you can find out more at some of our different places where we are online especially the riot is a good place to to chat and figure out how we can how we can the center is the web all right thanks [Applause]