New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Scaling & Interoperability Panel with Fredrik Harrysson, Philip Stehlik, Lefteris Karapetsas, and Ig

ETHBerlinWed, Oct 9, 2019, 12:00 AM

https://ethberlin.com https://decentralala.com/ https://goerli.net

Transcript

cool all right up next we have a panel on scaling and interoperability the panel is hosted by Frederick Harrison Frederick is the CTO of parody and I will let Fred introduce the panelists this is a superstar panel so talking about something super important enjoy thank you very much Lane yeah hopefully gonna be talking about everyone's favorite topics scaling with us on the panel we have Philips telic the CTO and co-founder of centrifuge we have left Harris Cara Pettis who works for brainbots and works on Raiden and we have egor barinov the co-founder of our founder of P way network so why don't we start out by everyone just giving a short one sentence introduction of what what it is that you're working on Igor you can start hi guys my name is Igor I'm from Peoria Network IPO is immediately available scalability solution for FileMaker system and also the first IBM chain to weigh packed to a theorem so tokens can be transferred from a theorem to Peoria and back hello my name is Therese I am the development lead for ridin riding is the Pam internal network for a theorem essentially imagine the Lightning Network how it would apply in theorem hey my name is Philip steric it centrifuge we deal with a lot of financial documents namely invoices purchase orders and these kind of things and helping large corporates to connect each other in a decentralized way and send that data around so that's kind of like a state channel how these documents are treated so we do that off chain and then we have an online component as well so I'm actually a user more on that part of what you are working on so let's try to frame the problem a little bit we're talking about scaling and everyone sort of knows this you know transaction per second metric but what are maybe some of the more underappreciated problems of scaling you see me your story yeah well let's talk about the theorem right because the scaling problem applicable for many black jeans but if you if you open watching Explorer you can see that all blacks are fooled right and there are multiple existing solutions for for scaling side chains Forks and there are about 15 Evo based networks out there and if you open watching sports for them you can see that PLAs are are empty and classic is like 1 to 5 percent each block and the question is why people don't use them and I think the the big problem with scalability is interoperability so that's why we combine these two topics together if you're Deb developer any theorem and you cannot use your assets on another evm network it's a problem and second problem is tooling if you don't have watching Explorer if you don't have mathematics in fewer and old tools you usually have a video mind that you will not use the skill abuse oceans so that's that's what I think about under a little problem in ability so for the question is for problems that we don't consider in scaling or some of the more and maybe let's talked about problems okay well I have a very technical view on this problems and I would say that the what we need right now is solutions that are deployed and work first of all and then we can define the more concrete problems after we see solutions that working just like where lightning has deployed on in Bitcoin and they have UX problems they have problems with the topology of the network but once we also do the same in a theorem then we can perhaps define some other problems right now I think that the main problem is to actually have scaling solutions that are deployed and working in the theorem minute I think from our side as a user who want or as an application developer who wants to launch the application to enterprises transacting a lot of documents with each other we want to do that right now we don't want to wait two three five years until the optimal scaling solution is out there so I think the conversation that we have is what can we release today on main net and maybe keeping some other things more centralized potentially or in some other solution and then migrate that over time once that is possible I think that relates to my next question I think a lot of people in the audience here are def developers or application developers in general and they are looking to build something but you know with the problems that we have today how can we work around those problems to still build something useful we're working on side chains so I think they changed a great solution you can play around with different settings outside Sheen and you can get the user experience that we expect from from ethereal minute but you cannot get it because the scalability problem is not solved there and I think for foresight genes we need to build tools and and different forms of bridges and that's the most important part so for tuning today we are I would I'm biased because we are building the writing Network and we already have deployed it in the Robson theorem testing it and are planning for a soon to come maintenance release so I would like to ask people if they would like to see to link try out a network test our API because the API that is currently right now I'm a testing will be the same it will be on the minute so they can try to create doubts that utilize payment channels and what they will create will also be usable when writing goes on the mainland and if I think about the app development and kind of the approach we're taking is putting only transactions on main that where it's actually worth paying a lot of money in order to have them there so that might be high-value transactions or it might be super important data doesn't change that much and then for us at least trying to release something today like before you are on main it is really finding workarounds for these other parts and there were some people do batching and then only doing one transactions was like a batch off of things in there I think people for example does that yeah recently I saw a project called Portus it's a web wallet it's a it's like a meta mask but embedded inside a web page and the great thing about this wallet that it supports multiple chains so you can connect this wall to multiple chains and if you tap support transactions on both network you can get advantages of for example having you see seven to one on my net and operations are on side chains and that's I think that's a that's a great thinking the app developers will think about multi-gene transactions within one day speaking of what the app developers should think about you mentioned this a little bit as well trying to build on rate and maybe on that test net but what should tap developers today like have in mind to make sure that what they're building is future proof for the scaling solutions that will eventually come out well it's a good question I think that this killing solution should think about the apps more than the apps developers think about killing solutions for example we all like you know solidity and I think when we think when we think about if Azzam we shall have something where you can reuse existing libraries security audits all the stuff that we set up with the app developers expect to get from from a theorem that on these new skills oceans but for when we thought about how to which parameters we should select for for side chains we think okay should we have not eight million years but no 80 million years and this is this can bring more use cases but on the other side developers who deploy it on on the network with more gears limit per block will be limited to deploy it back to a 2-0 minute so we think that you know skeletal oceans like side chains should think about you know what they were scaling if you're minute and give depth developers streamlined experience you don't think about this like make it don't make us think about your infrastructure right just let us make it you know you just want to add to that is as adaptable are I do have to think about it a little bit though think if I'm having most of my data on a side chain but I'm just saying whatever other platform I want to interact with only exists on main chain I have to somehow get my data around so when you structure your DAP like thinking about that like what are the other projects that I might want to build on when might that be on main net and how can I move my tokens or my data back and forth because I think bridges will not be available for everything I mean for your 20 tokens and so on that you can move them around relatively easily but it will not work for everything right out of the gates no actually they will be available for everything there's a concept called arbitrary message bridging parity is working on this and be always working on another implementation and this this approach will allow you to transfer any type of my students between address but not today that's what I like it's well from pure it's available today we can I can show you yep okay awesome but isn't this kind of centralized solution because you're having a sighting that has Authority knows it's a good question it's a it's a different simple control mechanisms right there is a proof-of-work propose take PE and the POA where the validator said with lists of authorities can be different a way to add or remove validators so they're like centralized prefer Authority networks which we expect to get from like financial institutions where there is a DevOps who can add or remove all data's right and there are period networks with unchain governance where auditors decide themselves or next validators so you can think about this as like a clap of validators but within this group all well daters are independent so that's actually that's that's how we were inspired by : network I like almost two years ago and decided to make public decentralized view network so it's yeah I understand but it's a different trust model that's what I want to say a different trust model and so the original question I would like to add something so the original question was how are the developers supposed to prepare right now in order to have applications that can work with scaling solutions that will come so I can speak about payments on other systems so for that you have to think about how you're dub will work and what you want to put on obtain payments the only way that you can structure your table so that this can happen is to have no own say in side effects from the payments because essentially then payments are make no sense so you have to start to your dub in a way that when you want to utilize payment channels you just also keep the results of the payments and the later obtain so speaking about the payment channel specifically do you think that that's a solution that will wiebe general that any dap should use or do you think it's application-specific and you sort of have to really think about this in advance if this is an architecture that you want to build wrong yeah there is no silver bullet for sure so you have to have it up that deals with payments and results of those payments more generalized solutions could be combinations of payments annals and other side things or plasma but as for pure payments annals no not every adapt will benefit from the existence of something like the other networks so you need to have a specific kind of application like let's say pee-pee eyes for example pay-per-view streaming and things like that any other comments about priming cells yeah that application specific use case and it's good that when we can have it on video networks totally great to have it the final thing I wanted to touch on just on that on the DAP side is the UX of some of these solutions so obviously if you're just dealing with one chain the maintenance EDD you can have a wallet that just interacts with that what are the UX problems that come from some of these scaling solutions yeah recently one key migrated from from muharram to POA how to build narco cartels called dope reader and it's a high transaction amount per user so for about 250 users per month they created about one hundred and fifty thousand transactions and it's I think it's most advanced RPG game so what they expected from the game that block time should be less you know because when you have like five seconds block you can you can get more smooth experience so for example waiting for for new block is important right but also having black time smaller not only because you can put more transaction but because you can have more smooth UX and UI so that's important for them and yeah they're happy because now they understand okay if we migrated from lithium to boa and next day we'll get better scalability solution for example you network with you know better parameter so less expensive computation they can do it again so they can switch from network to network and they used bridge to migrate EFC 71 tokens so they migrated characters from from a theorem I need to do a chain and we implemented as my contracts and that's streamlined process so I think parameters of the network can affect your acts of games and we don't need to think about sub-second blocks because want people interact with games they still have to approve transaction I was like okay I have to move I have to pay should I move and so forth but when you made this decision the decision should be at the same time or you know quite so slightly last time did you spend to make this decision and you know we don't need sub-second for this because we still human and we still so right and you know that's that's from from from our experience from migrating games and by the way I think the games will be the the big use case for upcoming part in scalability oh yeah so the UX issue is very very interesting for payment channels because so the goal of payment channels ideally would be to be invisible so that the user or the tablet uses mint doesn't really have to be aware of the concept of what a channel is or god forbid settlement timeouts and all of them talents the time talents scheme of the last time look transfers so the biggest challenge that we are facing in any payments on any system is to hide this from the user in a way that the user just says I want to transfer X amount of tokens from me to Charlie and this can go this can go through multiple hops but the user shouldn't have to care at all about it and also the concept of opening and closing channels should not be visible to the user so we were trying to introduce something that we call a connection manager so it automatically connects to a network according to some rules create channels with with a particular token network and then manage them and then when the user wants to close and leave the token editor then it closes and goes to the talent scheme so how to do that so that the user doesn't have to care at all on how to have proper eqx interfaces that communicate is nicely to the user is the biggest challenge that we have faced in UX and how we try to abstract that complexity of what happens under the covers is we just provide a simple API in our case enterprises calling a REST API and we abstract things like okay when is this document final right two different chains might actually have different finality and and these kind of things so that's talking about a way so that for them it doesn't really matter that much so there's that abstraction would be through a layer two solution on top of this multi chain architecture in this case it's much more the client that they would use to interact with with whatever chain is underneath so they let's say Alice wants to send an invoice to Bob and she wants to make sure like that document exchange is anchored and verified and it's just there forever then we just have a new status that says guaranteed instead of saying okay a block height is X because it doesn't really mean that much to to Alice so people usually draw this comparison between speed and decentralization being on opposites and opposite ends of a spectrum and left area so you touched on this a little bit in this side chain model usually like in a PUA set up the trust model changes you go from having maybe a public proof of work network to having to trust authorities what are some of the problems and challenges with that yeah trust authorities I think it's a more complex problem so first of all we need to understand how we start the network right and usually it's called trust ceremony and where this is a part where we have most risks and in Peoria type of network usually there is a role who bootstrap the network like first validator we call him master of ceremonies and this validator on board first validators and like who is the this master of ceremonies is very important when you put Stephanie network and and also you should understand who are about us and what are like security model of this validate that for example companies have can change ownership and when you onboard companies today can be up company owned by one company or person tomorrow can be different so that's why we decided to have individuals with us take it identity as validators and create some instruments how we can prove that they are independent from each other and unaffiliated so they're not relatives not a part of an organization so peer network is a us-based network so although the u.s. residence with no previous criminal record which is also important and after the ceremony conducted so first of all data's were imported we give unchained governance to all details so it's a part of consensus and what data's can vote in or both out all details so for example POA e first Network started with 12 old daters and after they started to onboard and remove all data from the consensus and at the moment it's twenty-one validators and there's some academic research from Colonel called decentralization and Bitcoin inferior and there is a conclusion that the quorum system with 20 or more independent auditors can achieve better decentralization consensus wise and current if you and Bitcoin network so that's the security assumption network exists for 10 months already and without any security risk problems and governance and all other artifacts of this PAE network can be publicly observed and verified and the biggest adventures of this type of content so that it's horizontally scalable you can take the same contract the same parity binary the same audited infrastructure and you can deploy it for European Network and you can think okay I don't want us what it is I want you validators or I want companies about the others or whatever you want right and and you can put strap the same network with same security assumptions and it will be as secure as the original Network and that's what we cannot achieve with proof of work and that's harder to achieve with proof of stake so horizontal scalability of psi cheese is the best achievements of piauí protocol I would have to ask you to repeat the question it's very the question what are some of the challenges in changing the trust model to this POS or sidechain so especially coming at it from an enterprise perspective a lot of the conversations that we had with folks they are asking us how cool you're doing that only theory or theories in scale can we do this on hyper ledger no that's not what we do and at least our belief is that we want to do this as on public infrastructure as mass as much as possible and I think there's this thing of like what's the maximum viable decentralization at a given point in time and so for us it would be perfectly fine that there are for example validators that are run by some of the members of the network who are voted in some kind of way but then in the end we want to be as much on a completely decentralized infrastructure as we can so when it is possible we migrated to towards that yeah I already mentioned that it's a different trust model so I don't think I can say much more other than that an interesting fact is that I mean observation basically I just heard that everybody all of the validators are in the US you said yeah doesn't that place the entire network under US jurisdiction yeah so that's what that was a behind is that we are using some existing trust mechanisms and for example having all the auditors in the same year is diction can protect token holders from collusion of Auditors more or less and well if you live in the u.s. you understand that very you know each state has its own law right and and like for example we like bodies in Peoria are public notaries so publicly regulated state by state there is no in federal agency for public notice we can revoke license from them and so forth so they're all in the same the same country the residence of the US but you know participation as a minor in decentralized network is decriminalized since 2014 by FinCEN so like you don't need to be you don't need to have money transmitting license to to create blogs in in public networks so that there is a there isn't well you have to pay taxes from what you earn from the network if you don't pay you know okay you came you can get problems but otherwise if you create blocks and decentralized network is totally legit business for validators I would love to add to that aesthetic as a user of a network like yours I mean it would be up to me or my application to decide is that a trust model that that works for me maybe somebody running somewhere where they don't want anything to touch the US and that might not be the network of choice and they can deploy their own network and so on but that would be on the user of the network than to decide yeah and consensus only what consensus gives us it gives us agreement on a set of messages which are valid by the protocol right so these validators they don't make decisions about my contracts and transactions they cannot modify your balance without breaking the whole system down right well so that's they just they just helpers to help thee the rift operator I want to move on to a little bit of interoperability and touch on that as well so what can def developers do today who want interoperability want to talk like to all these different services and blockchains okay so there are multiple perspective I mentioned multi multi chain wallets and porches is a good example where you can use one world to operate with to cheese without switching the network and it's from a UI perspective but and also when we think about that developers usually you know the app developers working for some companies which made ICO before and they have ears e20 token and if c20 talking like idiot on a seed remaineth right so there are multiple approach how we can bridge easy 2013 from network to network president POA we have EFC 22 years it when you bridge and yes it when token can be moved from but not the the whole supply by it but part of the supply can be moved from ischium to puree or others 18 and can be used for for computations on the chain so we have a use case with with Bank Corp and Bank were deployed their application on on pure network and we deploy the bridge for them where any bank or talking holder can migrate their ears it win token from PV from aetherium to POA and use it as a Bridget token on peer network for computations and they have different use cases right for an example they have Bank or use case for 4-minute and specific use case for stable coins Africa on peer network so I think bridging tokens from network to network is what the app developers can use now and it's from my perspective it's undervalued yet right so it's available now so this interoperability elbow you can do it right now right but not many examples yet I hope so so the question was interoperability before between what so for example if you're talking using Raiden could you use Raiden to interoperate between let's say a POA side chain and maintenance or like what are the tools available if you want to use these different scaling solutions or so the question is interoperability between different scaling solutions yes okay if you see a side chain as a scaling solution yeah so I have a bit of a radical opinion there because we have already also talked with the Lightning guys for for this I think there are so many potential scaling solutions right now that have so much work to do on their own in order to so we are creating protocols right when you create a protocol you have so many things to take into account from from the latency to the security so if you have not yet deployed tested and couldn't feedback from such a protocol you don't really think of interoperability you can talk about it it sounds good in paper but I don't think that we should think about interoperability at this point first let's creating the scaling solutions that work and then we can think about interoperability it works I'll show you after the Asian pear so it might work for a year see 20 tokens but it might not work for for some of the other use cases I mean what you're helping with polka dot with that that's gonna be really amazing once you get to that so obviously bridges is one type of interoperability and bridges come with their own set of problems one key problem is that it's hard to interrupt like it's hard to build a generalized bridge that would for instance talk between aetherium and Bitcoin and if they're him in another aetherium network or aetherium and in like a plasma network and and my main so one of the main questions we've gotten is method is that working right in and enlightening and so that would be a hell of a lot of work for very very little game and we're just one thing to add as a temp developer I see a lot of people kind of going down the rabbit hole like oh we need and then we need to do and we need to do and so on so if I'm just want to develop an app just focus on something that works today because not everybody can solve the scaling solutions on the level that you are doing it so how important is interoperability between just tokens like we were talking a little bit before and generalized state so if you have interoperability between tokens you can build something like a decentralized exchange but obviously that's just one use case so on that scale like what is the most important thing we can get when you see interoperability between tokens it mean like token swaps yeah like between Bitcoin and theory ah because like one thing that we can do with Rhydon is that we can any asset when any talking that is on a theorem is easy 20 compatible we can just swap it atomically so this interoperability sue we have that's that's that's easy but between other sites in the scheme solutions we haven't yet but varies ways perhaps bridges for example I think tokens are important because you know during the last two years many companies and teams promise that they will deliver the apps and they will deliver working software and most likely they cannot do this on on a on a currently remain that right because players are full it's expensive and so forth right so so so many problems and this this way they can deliver on side chains or force or new network CDM compatible networks and and breach their existing token and deliver what they promised right that's that's very important for the ecosystem because if projects will start not to deliver and this would be you know a major problem for the platform right because we'll see decrease of adoption of the platform and and you know I chose what we considered as care because they cannot deliver and so forth and the idea of arbitrary message bridging origin or a spotter cause is important for new types of applications which we will see soon right when we will have this applications as soon as we can I think baby steps is really kind of that we're taking as we go towards more generalized integrations so touching on charting a little bit that's obviously the scaling solute solution du jour and something that everyone is excited about it's it's much further down the line but you could see charting and starting up a bunch of aetherium networks and they all share the same security pool in that world like how do scaling solutions that we are looking at today change for instance will side-chains even be necessary anymore side she is helping to to build theorem tools right because we cannot leave for example without watching Explorer so at p ye we decided to build full-featured either scan alternative for sidechains force and charts and when you think about okey we have shirts for example they're developed at tomorrow right how can we see transactions on these charts so we need to build tools to observe transactions we need to build new modification in in other tools and side chains can help here by adopting third toes to these new short models and that's good when we working in the same way PI system even though we think like where it can be competitors in some sense well within in America system we're not going to you know tell a second system us Definity and other ecosystems and I think that natural that we have different view on the same scalability problems but we can work together to move what we'll have together right so you're saying sharding will solve all of the side chain kind of different side chains and just solve that together then because I just think I think there would be different chains for different use cases and not everything is going to be on a theorem even though I love you theorem but not the whole world is gonna run on a theorem at some point so there will always be other change that somehow need to communicate with each other if you have a tap on side chain and you're happy with speed and price and so forth and there's another solution why do I need to move right it's like huge employer on I know AWS and the Asia offers you some something right but you think okay cost of moving or and you know all the separation expenses can be bigger than the advantages out yet so I think if side chains are good enough for for depth today and they're happy and to work on them they don't need charging but new apps can go to charts and these applications believe him the same at a fair market system but with different view about you know where this application running on that's right so as far as talking transfers is concerned for inserting so starting required would require for transfers between subs it would require cross that communication as opposed so I don't think that it will achieve the same results as a payment and same internal systems in one chain so perhaps combination of both would be what the future would look like and so we're talking a little bit you were talking about starting up side chains for these steps but if we you know if every tab has their own side chain then we're obviously splitting the security across all of these and the security overall will decrease because there's a finite amount of sort of security to secure chains isn't this a problem in that model if you're you're starting up a bunch of side chains well I look at this as like Internet right so Internet is a bunch of autonomous network operated by humans connected by routing protocols and there is you know there are different type of security problems but we don't feel like internet is not secure right we feel that it can be insecure in some sense right but the internet itself is quite stable decentralized working together the same will be with side chains and and other chains working together just each part of this ecosystem shall think about security for example when we launched the bridge in production we had four security ideas for smart contracts because we thought okay one is not enough to no threes enough okay let's let's make one more pass we audit that possibly trust code implementation which we were based on and we had legal review because Interop usually it can be considered as money transmitting if you don't think about this and implement what everything you want it can be money transmission so it should be regulated so we had six audits for for the bridge between two networks and this bridge is working quite secure and i know we're can when problems can be and i think if someone will launch the same bridge between first and classic and if you know i can say okay guys this is secure you can use it there are some security assumptions about this bridge were validators what our limits quotas and and so forth you should take you should consider this but other all i think yeah that's fine because it's it's working the same with PSHE you deploy it it's secure it's proven public honeypot you know anyone can hack it but it's it's it's not hacked yet and when you think about security of each individual part and you can buy them together and people use them and they use same security assumptions it's like commercial airlines right yeah you don't care about pilots because they have the same education but yeah happens what's I think I can't talk about the security of site since I said we don't really use them at the moment related to the same sort of question can relate to state channels and there's a lot of talk about plasma being sort of insecure and everyone withdraw us model and this sort of thing do you think that these layer two solutions affected the security of the layer one solutions effect I mean layer two definitely depends on layer one being working correctly and being secured of course I always expect layer two to be less secure than later on it's it's only its nature it's more complicated protocols and they're depending on yet another protocol it it would be impossible to be to have the same security so for payments analyst we are trying to have the same guarantees but when you start to combine it with other things like plasma or plasma or other sites since then you have different trans models and then the security adjusts to these trans models and as a developer just making sure that you use whatever implementation that really fits your use case and I think when you man is affecting layer one Security's when you have an exit scenario and layer one gets clogged is that is that what you meant to I mean that that's one scenario in which case basically everyone kind of trusts this layer two solution but because layer one couldn't really keep up they might actually lose some money and that's me yeah yeah so I just wanted to end on a final question on what is your own vision for scalability and interoperability and do they necessarily go hand in hand like is interoperability necessary for scalability or can you have one without the other and what do you see in the future yeah we can make our stuff super scalable by just keeping a lot of things off theorem but that's not really where we want to go because we want to plug into the ecosystem of gaps and protocols and whatever there is on on this awesome Network so for that interoperability will come into play from there just to get access to all of that yeah so I think that scalability will first have to prove itself through various implementations some will just not be used and will not survive those that will survive then will have to become interoperable with each other and that's the end vision we're the ones scaling solutions that end up being used by the app developers we have to become interoperable and then we will have a scalability problem solved well it's not possible to to have vertical solution for for one network so most likely will be multiple networks and if you have something horizontal you have to connect it and that's why interoperability is inevitable all right so we cannot we cannot have change without communicating with each other and I think that there are some that some problems that we not thinking about for example when we think about transactions per second and compare them with each other we need to think about where we store the data right because when you have thousand transactions per second for example in any theme node it would be more than five terabytes a year and on each node and when we have a high throughput application on sizing on settings what we see we can we know that for example a game with 250 monthly active users can create about 2,000 reads per second to api's so like new applications can create not only rice but only a huge amount of reads and if you if you remember Joseph Luton recently mentioned that they have enormous amount of reads unknown and fewer he can parrot it with Google and I can I can agree that for for us transactions per second is not as important as distributed read to this database and well I think we as a layer one solution should work on scalability and the interoperability and make experience of depth developers please and and we need more to have developers and just you know it's such such a point where we have we have many networks but we don't have enough the depth developers check state of the apps you know most popular game is five hundred daily active users it's just a baby baby numbers right so bill games okay all right thank you all very much for joining me on this panel [Applause]

Automatic transcript — names and jargon may be misspelled.