Berlin Ethereum Meetup - Interoperability Edition - Panel Discussion

cool here you are guys thank you guys for staying I know that the weather is very nice outside and sunlight is limited so we have four projects up on stage you've heard them present there are some similarities between but not across necessarily all four although they exists in the same family so I'm going to lead off with a few comparison questions but divide them up here to the inter blockchain communication projects there's the obvious polka dots and cosmos could you speak together 1 & 2 2 & 1 a little bit about the differences between the projects shared security versus independent security and will do you think over time these be collaborative or competitive so on and so forth so yeah thank you for the question so like you mentioned that the most important difference between polka dot and cosmos is the shared security and the independent security side of things and then the second part is upgradable chains the on chain governance part of it basically the way we see it is that shared security is needed is the way because one change should not be competing with the other chain about security resources they should not be basically like doing the exact same thing with respect to stake or with respect to mining or something they should be collaborating on that scale and helping each other become more secure so if you are attacking a chain on polka dot a pair of chain you are actually attacking the whole network and not just that particular chain and secondly the other major difference is the upgradable runtimes and the blockchain with respect to Unchained governances nothing is permanent there has to be an option to upgrade things we are looking at right now there are so many use cases where we have to each and every day upgrade the smart contracts or upgrade the business logic or run times and everything and then there is this huge disruption of process happening because of that and we want to get rid of that whole problem by providing an on chain upgrade solution so that's basically the way I see is the two major points of differences between cosmos and polka rod and why they are there why these we are providing these kind of solutions with polka dot and I'll let Billy add to it sure thank you so I understand why the comparisons made often in a way we're solving similar problems but I think actually we're providing different solutions for different scenarios polka dot wants to be a very large shared environment which has its benefits and also has its drawbacks we kind of take the approach that sovereignty is the most important aspect of any application-specific blockchain and so we make that the first available aspect of it when it comes to shared security we also try to avoid using this term we think it kind of a misnomer what we like to call it is cross chain collateralization which is entirely possible and probably going to occur soon on cosmos and what that means basically is that so there's chain a let's call it cosmos hub which has an atom used for staking chain B could also use atom for staking as long as it's allowed to enact slashing conditions on that chain A's asset so if that were allowable than any of those validators which have atoms securing chain a would be able to use those atoms to secure chain B as well this is basically an agreement that those validators need to come to with the second chain which is again how we kind of see things happening there's no reason you should be forced to secure a chain that you don't agree with there's no reason that you should be forced to support something whose resources are draining on an otherwise productive ecosystem all of these things we believe should be sort of autonomous and taken care of by sovereign chains I'm also sure that you'll have responses to each other so we'll come back to a similar question a bit later on that will provide an opportunity there but to the graph and chain link this is sort of a similar question because Oracle ization and data availability do have some similarities and overlap especially if you're providing the data in a decentralized way could you speak a little bit to how the projects are distinct from one another and how you see them branching off a bit over time sure I'm just one small correction is I I don't think we saw the problem of data availability per se usually I think of data availability is like a layer one concern which basically means that like you're guaranteed that you'll be able to get the data that the data doesn't drop off that and and that's like an assumption that we make of all of our data sources and that essentially what we're solving is kind of quality of service so it's I want to be able to access the data quickly and cheaply and securely and and so that's like a layer that goes on top if one graph node doesn't you can send you a response you can just hit another graph node they're very kind of like interchangeable but then in comparison with chain link I kind of think of us as maybe like two sides of a coin or we're kind of opposite chain link is kind of a way of getting data on chain and we're kind of a way of getting data off change so it's kind of cool they're both these kind of you could almost think of them as like layer 2 networks that kind of sit on top of you know these like block chains and storage networks yeah so basically in order to achieve decentralization to achieve the TBG I think it's very important to have something like basically you need in order 12 to centralization to have as many actors as possible right so you need not operators who are providing this data to be incentivized and to have reason to act honestly my city to provide the data as I should provide it so not to lie or not to act maliciously so in order to do this you have to have mechanisms such as taking basically someone has something at stake right so if you have a security deposit in tokens basically saying all right if I start lying well the other nodes will show that I'm lying because it provides the right data I provide the wrong one so I might get sloshed right so you need to have kind of incentives for not operators to first act you know not Byzantine way house it and also to keep their nodes running as much as possible so having the best uptime possible and that's also incentive so it's having the right game theory the right economic system in place to make sure that the network exists can function very much coming back to over here and we'll have a few that run across the board but talking inter blockchain connectivity communication Billy mentioned in his talk that the next big piece for cosmos was IBC do you see standards evolving over time or will every IBC related project need to find their own way to interconnect if you were at the interchange conversations event the first question that Jay got onstage was when ether bridge so will will IBC possibly handle this over time across both projects or how will that shape up in European I mean it's always difficult to judge any future scenario the way that I kind of imagine things happening with IBC I mean in a way this also speaks to what what is IBC and what is supported with IBC and first off I got to say that when I joined cosmos I don't think I fully understood why cosmos exists and it took me a while to fully grasp exactly like what problem they were even solving and and in a way I was really excited by somebody who's trying to solve a problem that doesn't exist yet but there was a lot of sort of early comparisons to between what polka-dot was doing and what cosmos was doing and this idea of communication between blockchains and and a go-to factoid would be something like cosmos will support transfers of balances and polka dot will support arbitrary state updates and in a way this is true but what I came to realize later was that this idea of data transfers as message types so the first message type that would be supported with IBC is a transfer of coin this includes coins like non fungible tokens though so in a way these are two message types and when you're talking about autonomous chains that are application-specific and away the only part that really matters between those two are stores of value and so when you have a chain that's designed to do exactly what it does sometimes say do something to some other chain almost every situation can be sort of boiled down to a transfer of value but what I became aware of a little bit later as well is that so much of IBC is based on the work from goreck who's been sort of the inventors of the smart contract they've been working in this sort of context for 20 years and a message type that is very much on the runway is a call data message type so this would be sort of a smart contract execution message type which basically opens up any other sort of arbitrary state update transition that that could be imagined through a message type I actually think it'll be sort of underutilized though because of sort of the beauty and elegance that comes through the abstraction of actual transfer of values between into chains where were the things that matter sort of arbitrary state updates actually are already designed to take place on a single chain that they were designed to take place on so that's related to your topic but do you want to steer it more in one direction or another why should I just hand off the mic and then come back with maybe the question was really speaking to IBC do you think a standard will emerge over time that helps utilize some of the science between the projects to intersect each other back to other change can you repeat the question it's the initial question server repeating the initial question okay so so the to the answer like initially when we mentioned that it's still we cannot comment a lot on what's coming in the future it's I fully agree with that on the other side like polka dot is already having a protocol called ICMP interchain message passing which is different from IBC and it basically like allows arbitrary message passing now I go to go back to the one of the things that I mentioned in my talk is like the infrastructure for infrastructure so what ICMP is allowing for a chance to actually define standards on what kind of messages to be passed it's like we are not enforcing chains to you should be only doing a data call or you should be doing only doing a point transfer or anything it's like we are providing a base protocol and an infrastructure and the chains or the developers out there who are building their platforms and frameworks on top of it are fully free to decide which kind of messages to be pass what should be standardized should it be shouldn't there be a standard for coin transfer should there be a standard for arbitrary message or something like that it's fully up to them to design and implement and come up with it having said that there are other teams also who are looking into inter blockchain communication like I was talking to some of them in this week and there is definitely like a lot of overlap between these protocols and there are a lot of differences and it will be really interesting to see how we are able to you know combine those overlaps and still convert some of those differences to reach consensus on the on that but still very early days I would say just quickly so I am excited to hear about this sort of process on polka-dot which sounds to be marrying a bit the process of IBC which is sort of beginning with certain message types and working through what those message type support would look like on different chains I mean we've also talked between the projects about the fact that polkadot would be able to support IBC if it chose to and be able to send messages from the polka dot ecosystem out into the wider interchain vice versa your your sort of version of IBC is very much for communicating between different pair of chains right I I'm curious what the design decisions are between IBC and your own version of it that are specific to polkadot that wouldn't be possible to sort of incorporate into using IBC for all communication whether it was between pair of chains or to the wider enter chain sure I'll be very quick actually on that because I do not have that level of detailed expertise to compare IBC and ICMP but what I can actually say is that you're right IBC will be just a subset or layer on top of that if that needs to be supported in the future so it's still a underlying protocol which can basically if we devise a standard which has the standard of IBC messages then they can still be passed among the para chains so that's how I will just quickly close this so the topic tonight was interoperability and coming back to this side of the semi circle how I'm curious do you react to this sort of answer you guys have spent the last few years but the project's working to sure bring data on an export data from the etherium chain is this like starting over for both projects for each let's say inter brachii inter blockchain communication protocol or would you benefit from a standard or is it simple plug-and-play at the end of the day I think it's it's very likely to be like a very heterogeneous multi blockchain kind of world and we've kind of been prepared from for that from the beginning we started with aetherium just because it has the most active ecosystem we really you know I identify with the project but I think either way software is going to run on a lot of different chains and so for us we want to like organize all of the data from these different chains and we think that applications are going to utilize data from multiple chains and so actually like organizing that data it's it's not really like the classical interoperability problem all right the the problem that like cosmos and polka dots solve is much more around I want to update state across different chains and so for us there's an aspect of it where it's it's you know less tied to security in the in the sense that you know you can't make like a an incorrect state transition you know using the graph but still linking the data across different chains so you know if you have like an interface and in your app you want to show you know all of the jobs that you can perform and you know the those jobs are pulling data from different protocols that are living on different chains you still want a way to very efficiently get that data put it up on an interface and that's kind of the the part of the problem that we solve yeah I mean very similar like I think this panel and these talks were great because we had two sides of the equation we had this one side where it was interoperability between reductions and the other side between real world data right so bringing this real world data over to blockchains now on our side like technically it's very different from GBC but and basically being able to communicate the cross blockchains but once we have pulled this data from the real world to blocks and applications if you also plan to be block diagnostic right which means that we don't want to only have smart contracts keeping on here on we want were smart contracts living on cosmos and polka dot and all of them being able to communicate so I think having a standard there is a very key so we we all know about TCP IP and TCP IP was created by a consortium of enterprises businesses researchers who can work together to create the standard and I think it's very important in the blockchain space to have something similar like we can pull real world data without having like with having standards that are established you know and we need the same to kind of make this data flow across different blocks and networks so that's very key to having non inter connect duction words where we can across we can communicate across zero we're the real world and productions yeah thank you very much I have two more quick questions and then I believe Maurice will lead a few from the audience going to move quickly to everybody's favorite subject token economics so or lack thereof so quickly across the board and I'll hand off the mic so that you can sort of pass across cosmos seems to utilize one system where heavily incentivize taking but it's not required ecosystem wide if you move off of the hub or as polka dot i believe is the other side of the coin it's highly incentivize use to keep the entire system interconnected in that way I'm curious to hear about how going back and forth here chain links token token economic model was I don't think it's something we're get about in this presentation and how the graph pulls off what you guys do without it so channeling basically we are relying on a decentralized network right so any decentralized network in order to establish trust we need to can have game theory and token economics to make sure that the actors providing the data are incentivized to provide it in a reliable manner right so basically the way it works with a chain link once once everything will be kind of figured out on this side so in a few months we start implementing staking which means that people will or there is no date on this one but basically people will network we need to have a security deposit of link tokens to ensure that basically they have something at stake right kind of similar to us taking on cosmos and tezo's when you're committing to saying that this state is the right one if you're providing data to the chaining Network you need to have something at stake when you're doing it and basically these data these Oracle's will be paid by the users contract so someone who is pulling data from nirakar we'd have to pay this oracle using the link token so basically the more reputation you have so kind of first one is our stake in the Morris taking you have it means that you have more security deposit so more to lose so your reputation is kind of more important right because you're more reliable in this way if you have more at stake and second one can do people who have been provided so not operators we've been providing this data for a long time we'll have a bigger reputation which means that they will be more likely to be chosen by smart contracts owners who want to query data from them so that's I think our token economics is very similar to when a decentralized network that's choosing staking for instance like there are no like we haven't found the right approach I think no one has it's see the space that's being explored right it's a very new space so it's kind of similar and we'll try to experiment and see what works yeah I think we've probably talked about our token lesson like maybe any other protocol that I know about we haven't launched a token yet but there is a token as part of our protocol design and that's just because we made the decision early on that we wanted to solve like pressing problems for developers and we would start with that first and that we would kind of decentralize so what we looked at today in the demo was us running our hosted service well we're running a bunch of the nodes and it's basically centralized all the code is open source if you want to run your own nodes you can or you could just rely on our nodes to make your life easier for now but the goal is the decentralized network and so it's kind of this trust we're taking on with the community to say you know we're starting with the set of problems first we want to make it really usable we want to make life really easy for developers and you know what will be decentralizing as a subsequent step along those lines at graph day is this event that we held in January we oh we like published our specs for our hybrid network which is the next milestone for us and in the hybrid network anyone externally will be able to run a graph node it's part of this network we are going to release you know touken in that milestone and and so we published the the specs for this intermediate milestone where the graph is still responsible for some elements of security in the network but the economics are decentralized so you can earn money by running a graph node and basically the token has two uses in the network there's a work token model so it's very similar to like a live peer for example if you want to run a node you have to stake graph tokens and that provides the economic security so if you misbehave then you're slashed and and then in return as a node you can set fees per query in another currency like ether dye so we're explicitly not like a medium of exchange token and so this creates like an open marketplace where anyone can run a node set their own prices and that should make a service that's reliable and and cheap for people and then the second use of the token is for staking on sub graphs themselves and so there's a few pieces in kind of like the governance and how we DC how we manage essentially this global graph of data where people want to organize data and come up with standards for data formats in a way that's decentralized and so there's a governance component to that and then also there's like a revenue share component where if you stake on a sub graph then you can earn some portion of the query fees for your curation work so those are things that are part of our our hybrid network spec which is going to be the next phase for a protocol which is on our github at graph protocol slash research cool so as I mentioned earlier I am a fan of this idea of like - centralizing as there's value there if you try to decentralize too early and there's not value on your network it's it's a huge security vulnerability you can attack a network that has no value so I really appreciate that spec coming from y'all in a way it also has similarities to the way we think about talking economics at cosmos because atom is meant to be a staking token it's not meant to be a store value it's not meant to be a fee token right now atom is a cosmos as a hub that only has one token on it it is used as the fee token but we want to make atoms as illiquid as possible because that will make it as hard as possible to attack the network because if it's easy to buy one-third of the the stake that's on the network then it's easy to attack the network but if there's just not even one third for sale at any given moment it's going to be impossible to accrue enough to make an attack like that so our primary goal is making the token illiquid one of the ways we do that is with staking rewards which are very different from rewards on a perc mining where you think of getting paid for running your node if you find the block reward you know that's your payday it's very much the opposite on on cosmos we we mean it to be an inflationary token it basically means if you're not staking your token the value of it is dropping every second that someone gets a block reward because the the quantity of tokens out there is constantly increasing if you're not part of that increasing by delegating your stake to a validator or validating yourself that means the value your tokens are constantly dropping so that is supposed to encourage you to delegate them to stake them lock them up do not let them be on the open market because if they're available that means the market and the network is unsecure the atom is supposed to give you rights as a validator to accept fees this is where we see the value of the network going through which is why we also very much depend on people wanting and using block chains this is something that I like strongly believe in it's it's a time to finally test like we have the tools and the ability to build scalable block chains now let's see if anybody wants to use them because if there's actual value out there those those fees from that value will be what those validators actually want and what actually get paid from so something like the one thing that I find very common in all of these token designs is proof of stake the world is moving to the staking side of things now and now the thing is with polka dot we again have a proof of stake system but what we call it and it's how it is slightly different from generally proof of stake or delegated of SOI stake it's like it's called nominator proof of stake basically or nominated proved mistake it's called n pause and the way it works is not everybody needs to run on or to get block rewards you can actually nominate a potential validator to act with your stake and they can stake into the network and run a node the second most important thing is when these validators join the network they actually are changed or shuffled every set period of time which is called a session so they and at that particular time the block rewards are distributed so that's one utility of the dot token for polka dot that you stake your tokens to become a validator on the network and you can nominate your dot tokens too for someone else to become a validator so that you can share rewards with them the second utility is getting parish in slots themselves so you have to stick dot tokens to get a parish in slot on the relay chain and then you can actually be a part of that whole polka dot network which allows you to participate into the message passing and the pool security and all the goodness of the relay chain there is no concept of gas or fee per se it's if you have a parish in slot you are actually allowed to be part of the network processing the transactions along with the other validators and message passing and in your chain yourself you are completely free to how you want to have your token economics it doesn't have to be if for example there are use cases like NGOs and governments where you do not want your users to be paying for transactions they should be using your network as a as a free service then you are good with that as well you do not need took a local token economics in your parrot chain and in case you want a fee or sub system or something like that for example the smart contract pair chain being built on polka dot called H where they will be having their fee concept inside their particular chain so it is very segregated and different on the polka dot network it's the dot token doing all these several things and being used for that and for a local parrot chain it may or may not be something else yeah yeah all right so the last one is a fun one you can keep it relatively short if you'd like there were two comments made up here one was that when they joined someone here joined their project they thought it was a problem a solution in search of a problem and the other one was mentioned by okay still fits the question and multiple people up here mentioned not to speculate about the future so let's do both I hearing hearing these critiques I'm involved in the etherium community some wholly unfamiliar but these projects are coming of age right and while it may still be a few more insert weeks months soon trademark years before polka dot v2 or phase two of serenity is online or IBC is live with lots of folks in the zones and your projects have come to fruition can you give a brief real-world example for either those here that may be slightly less technical or some that may watch this feed of how the project envisions its use in the future if those things have come to mind for you and will go this way sure so actually it's a vision of changing is ready to replace detail agreements by smart contracts so for this we need a lot of data we need the system of decentralized oracle which is secure which is reliable I think a good example of how we see move things moving forward is the integration we had recently with Google which is going to use bigquery which is going to use chain link in order to pass big query data on to the ethereum blockchain so that's I think yeah I'm lucky because it was announced a few days ago and it's a perfect example we aim to see a lot more businesses using chaining in order to solve problems that can be solved with smart contracts so DocuSign is another partnership we got their CEO is an adviser to chain link and we see a lot more enterprises using chaining in order to leverage the power of mass of smart contracts basically it's in insurance in finance and in trade finance all of these fields will be very disrupted by smart contracts to be disrupted they need to transfer the data to the blockchain and they will lose changing to do this so if we're successful the graph will be like a global API for just like all the world structured information so if you want to build an application you go to the graph and you find all of the data that you need to build your app really quickly you deploy it and it just runs forever as far as kind of the space as a whole I really subscribe to the kind of sovereign individual sort of view of the world where you know everyone can design their own jobs you know I could build my own custom application that's just how I want to spend my day I clock in I find the type of jobs that I want to do you know people are matched in this global open marketplace and and that's somewhat what the future of work looks like I recently asked Chris goes who's heading the research on ABC would it be possible to run a single server validator that supported IBC because it made me think about sort of the original spec for HTTP that was supposed to support a standard for value transfer and they they just couldn't figure out how to solve the double spin problem and sort of the the endgame that I kind of see with the Internet of blockchains or the inner chain is a network an internet of computers where money is a primitive instead of being a number in a database that is going to rely on a merchant service to redeem that value later on you just have a much more efficient computer system where money itself is as important as a boolean or a string when you're programming and you can you can rely on this fact that money is real in the software level and what's required for that is something like IBC which is you know a standard for transferring value between different computation systems whether it's the most boring case say a single validator on a chain or a public validator set on a public blockchain the idea that you could support that as a computer network is is where I think sort of the endgame lies good so for Gerard it's kind of something similar but it's in a slightly different way again if we are successful and we will be we are looking at basically a world which is more connected we for example let me give you an example for a real world there will be change for doing very different things and doing them very efficiently very well if I want to book a book a flight and I want to book an Hotel and I want to book an taxi and those are all being done on different chains they will be I don't have to write like rely on their calling them separately or I don't have to basically authenticate my identity for each of them I don't have to make payments on each of them I will be basically able to do that payments on one chain or who I am where is my digital passport on one chain and similarly poking at plane ticket and hotel on the other chain and so on so it's basically going to be a lot more connected less bloated and a lot more transparent when we succeed hopefully all right thanks everyone and I'll hand over to Maurice for a few from the audience however many you feel you have time for there was one very eager center in the back here in the white shirt sorry for being too eager I also think you led with the right question you asked me earlier like what is the most important question I think sort of highlighting that difference between different projects was very interesting but to this first topic like what does the standardization of IBC look like and so so as a bit of like I worked very closely with tenorman back up to 2017 and we're launching like a first real-world use case in 2000 like in two weeks an application with like 25 million users but so I mean we're launching first two three thousand and ninety thousand and so but three but I mean we had to look at this problem also how do we communicate between side chains and et RIA minute and so maybe it's more of a proposal like we you have a IPC in 12 and so we communicate is hash data according to e IP 712 we store it in one contract we prove that it exists in the outbox on e teria minute and now we pass whatever message so we have a message struct and then a specific type struct that sits in a message struct where we just use VIP 712 so maybe an ID instead of like trying to invent another standard there already exists on an idea rather than a question it's okay thank you so much Maurice to the next all right so this isn't this is also not really a question but so there is a standard for IBC that's currently being worked on by multiple companies and actually at the last community call a researcher from web do foundation actually participated in the call so if you want to participate then you're more than welcome to there's a github repo it's cosmos slash ICS and then actually also the polka dot wiki has a good explanation of it and then there's also right now for implementations Haskell that's being worked on Haskell JavaScript Russ tango cool things yeah the meetup is also supposed to be kind of an exchange so that's perfect do we have some more questions my question is more regarding like getting jet data on chain and off chain and I'd like to understand because it seems to me that this is more or less a subset of just off chain compute environment and in both cases both in graph and in chain link you require having these decentralized networks and why do they always have to be separate why do you have to build the network every single time one you can just build a generalized application that requires for example in my case I want inputs from five validators and that can be the five API is that I'm requesting but also I can run it as many nodes as I want and I only have to run it on let's say that I exactly at work why do I have to limit myself to a subset of API requests but I ever chain-link or graph offers and not be able to write a generalized spec such as let's say a kubernetes one well I think you're right that you know generalize compute is kind of a reusable kind of primitive but I also think that all of these different use cases have enough differences when you down into it we're especially because we're so early in the evolution of these protocols they kind of need the ability to evolve separately because it's just really hard to coordinate large number of engineers together and so like even within a single team you know you kind of break things up into like modules or something right you want to have something that's a small enough box that there's like one team or something that can like own that box and make changes independently and I think that the general concept of like protocols that are specialized that layer on top I think is a good one you know modular I think is better than monolithic in general for these types of things now as a node operator maybe it turns out that you're an enterprising node operator and you say you know what I can actually ingest the same data from these like seven different you know networks run nodes for these you know five different networks on top and I can do that really efficiently in that way I'll make even more money because actually you know the data ingestion part is very similar the data I have to store it the computation maybe is like somewhat reusable and you can find a way to do that and I think people should experiment and I think there's opportunities for those kinds of optimizations but as far as like the specs and the networks themselves I just think that like you know we're kind of building an operating system here it's like you know all of the different pieces are super complex and we just have to you know draw boxes around the various components so that we can kind of get it done yeah it's a very new space it's very hard to define a generalized application in this one I think the modular approach is much safer and much better - basically for the future its revision yeah I have a question regarding the interoperability so currently when developing a weapon for example and I want to use a single blockchain then I already have this issue that I need a blockchain wallet I need some plug-in like meta masks and now if I imagine that we have a plethora of different competing block chains Oh neat yeah numerous wallets as well if I don't want to have the power at this central web app server so have you thought of any kind of yeah of combined wallet that that allows you to use those different blockchains from where else for example as well so I read an article recently from Richard Moore who if you don't know him is a great researcher mostly associated he's image of ethers j/s and a few different projects and he who was writing sort of a speculative article about how do you you to proof your blockchain for the quantum computing world and quantum computers are really good at doing very specific things but not everything one of the things they're really good is sort of breaking encryption on private keys what they're really not good at doing is dealing with pip 32 mnemonic phrases so there's nothing that would prevent you from using the same mnemonic phrase on many different curve architectures and also it would sort of keep you future proof from a quantum world I'm not sure which wallets are currently supporting different curve outcomes from bit 32 I know that cosmos supports the same curve as aetherium the way that metamath scandals it is slightly differently in order to sort of recover the public key so there might be some tweaks there but somebody from meta masks was here for the weekend at the cosmos hackathon sort of supporting the the grand goal which I agree with you is is to be able to have you know a unified key management system across different worlds and and in a way this is I think the most important thing because block trains are cool and all but what's really cool I think we can all agree on is cryptography and what it's done is made a reason for people to care about strong encryption it's made a reason for people to have private keys to be aware of what they are to think about what that means to think about multi signatures to think about all these really important schemes that are extremely powerful it's only until we have something that we need to secure do we care about securing them and I agree with you that I think this is sort of the most important component of no matter what blockchain you are it's it's where the the tires hit the road it's where the humans touch the technology you've down no more questions I would say thank you and thank you all so much yeah thank you so much for this great panel [Applause]