DAPPCON 2019: Panel - The Road to Scalability

Transcript

all right so yeah when when when we were preparing this suspend I was already joking that there have been probably already 1 million panels called rotor scalability on blockchain conferences so the question is what can we what what what what is new or what can we where can we provide additional insights and so the way I would like to structure this this panel is basically that we have like four people that represent a different way how to tackle scalability and I would like to well yeah discuss

from the perspective of a depth of L upper today if you have well a need to build something today there are four different options and basically what are the trade-offs so what are the timelines when can you expect what if you go with what direction what what what do you get and what do you maybe sacrifice if you go with this direction and yeah maybe shortly introducing of course if terrorists working on Radian stage channels and maybe you can give very short like summary of state channels or payment channels Braeden yeah yeah you hear me all right

so I mean if there is I work in the Radian network we are creating essentially lightning for aetherium it's a payment tunnel network there you have payments analysts that is a construct that is composed of both the non sane and obtain component on saying you have a deposit in the theorem blockchain and then you can transact between you and your counterparty as much as you want within that deposit obtain that's like right right I mean so in general I actually assume that most people are familiar with the wizard solutions and we can go more into death

but anyways continue is with sunny whoo yeah I guess represents the sidechain solution sir hey guys nice to meet you my name is Sonny I researcher at cosmos and the cosmos when it comes to scalability we're kind of focused on three main things one is fast finality BFT we think it can provide more scalability than most Nakamoto consensus chains the second is application specific block chains we think by segmenting applications onto different block chains and making them specialized for their use cases that can also help scalability and finally is side chains when you have all these applications specific block chains you still want a single cohesive ecosystem and some sites chains allows for you to split these

applications into different chains but still and you get more throughput because you're having different chains doing different things and only the users who care about a certain application have to run that chain you're not processing transactions for other applications that you don't care about you're only a user for the applications you care about yeah I think Jordy I don't even need to introduce because he just gave gave talk but I mean what you can again here I'm going to talk more about what we can say the roll-up method or if you want there's a zero knowledge using the zero knowledge of proof from computation method mainly they there is we split the problem between the verification side which is done with zero knowledge and that

availability side so there is the main array is that you can have maybe a let's say a central operator that can take 1 million transactions execute those those transactions and then just create a zero knowledge proof that proves that those transactions are executed in the right order in the right way without double spans that are executed in the right side and then we just prove the new state of this new transaction just on on on state of course this half the problem that the transactions that you are executing needs to be available in order to verify because if not the system would not be a warble and here is the

data availability here there so we split the problem and how we'd solve that availability then that's another story but that's what mainly what the theorem 2.0 is trying to solve for five coin is trying to solve all other solutions may be some federated systems can also solve or if you want the first version from roll-up they raise to put this data in the same chain so we let's put this that in the same chain is a shorter data but with this way we can scale maybe 10x and what's most important we can test that this technology actually actually works and that's the steps that we are working right now right and so alexei might be to some surprised by where he's on the panel because he's not kind of directly

working on a on a layer 2 or the scalability solution but we nevertheless wanted to have him because he came up or he I think he represents well just interesting strategies how to use the existing blockchain is the existing etherium 1.0 more efficient and kind of an on both sides as a DEP developer kind of how can you get most out of it how can you kind of create your contracts in the most efficient way and of course also from the client perspective how can just clients well make optimizations to yeah make make theorem as it is most scalable and maybe you can like describe

few things yeah so Thank You Martin so last couple of years my main focus was to essentially try to squeeze out as much as possible out of the existing cerium and now it's kind of light is spilling out and so other are technologies and luckily recently I had more help in terms of there's three people sitting in his audience that are helping me now so hopefully things are gonna get a bit faster and because the the things that I was trying to do modifying the existing implementation they're not mainstream yet although I believe they they should and can become mainstream and yeah my approach still I'm kind of gently ignoring most

like things are happening with the proof of steak and other things I know that they exist I know the general idea but I still want to demonstrate that even without them you can already achieve quite a lot if you are paying more attention to the implementation and that's one of the reasons we're putting out a work workshop on Friday is to try to this lieu to basically show people at least starting to show that it's not a dark arts to work on these implementation it actually could be made a science rather than the dark arts so yeah that's my approach yeah great so so to go forward I would like to well I

mean now choosing one of those routes you go of course it very much depends on the use case and I would like to kind of take the the simplest use case of just simple tokens and token transfers and try to point out as different advantages or disadvantages of different solutions so I would like probably start here if there is if you just want to up - yeah well have more scalable token transfers token payments what are roughly the the factors scalability factors or what are what are the advantages you get from state channels and maybe what are the what are key advantages you only maybe

get with state channels pensions well you can get much cheaper and faster transfers and big advantage is the finality that you get because we consider its final once the obtain mesons is what we call balanced proofs are exchanged so any any application that can benefit from token transfers but doesn't have any direct on sane side effects of those transfers because as an important thing would benefit a lot from using a pencil network such as Ryden but if it has side effects that have to be you know don't say at the same time then

basically you're just missing the point of my maintenance maybe going on yeah I would say that the application-specific side of cosmos doesn't apply as much a token transfers but I think what does apply is the sidechain side where it basically says that look you want to be able to side chains are useful or any sort of thing in which you're splitting your ecosystem into multiple things whether it's charting or side chains or whatnot your bottleneck is always gonna be the inter chart or inter train communication and so the most useful one of the so you want to minimize the amount of inter

train communication that you have and so for token transfer I think you know you want to try to find what emergent properties are of networks and so you know I think it's a very common situation that in financial transactions in the real world the majority of your financial transactions are usually located like based off of geography you do most of your financial track transactions when you're going out to the store and so you know having side chains that are specific to communities or doesn't have to be necessarily Geographic but the idea is to look at the larger financial system and find subgraphs in the system which have a high amount of localization and transactions and try to build side

chains for those so that way you can build a chain that really is only meant for the people in that smaller community and understand the side chains come in where when you do have financial transactions going out of that community you can do that by sidechaining to aetherium and sending it back to the main chain or something yeah in this technology it's um probably the newest one that the at least in the what stem-related it's still little lot of things to do the main limitation right now for example is the creation of this proof you know these proofs are very computational heavy things important generating these

proofs some makes some examples right now generating uh maybe a 1/5 sections four mm transaction proof it can take half an hour in a big computer in Amazon right now so there are a lot of improvement here just trying to do FPGA or trying to do some you know a graphics card and improvements in this generation it can also be paralyzed a lot so there is a lot of work that's being doing on that but the promise of this technology is quite high because once you have that you will be able to do normal transfers you will have like Bitcoin you know transactions per block and you could have theoretically the Skiles very very

high one interesting things figure from the user is that's very easy to do for example atomic transactions atomic transactions in this technology are quite straightforward and probably in the next in the in the first versions of the roll-up implementations all of them they will have these atomic transactions with out which are very important for you know for lots of applications it changes and moving tokens around I'm trying to kind of try to nail it down as specifically as possible what what are the unique things so I would say it was with state or payment channels is probably instant finality this is kind of something no one else can offer I would for me or I see what the most interesting thing about payment channel networks for payments is that you have a

situation where in almost every other solution it there's a level of broadcasting data to everyone when you want to do something while in payment channels the nice thing is it's not like it's not like a multicast or you're broadcasting something to the entire if the entire world doesn't need to know about something it's a payment between me and you we can just like keep it between me and you we don't have to broadcast something to the entire world and I think that's like the main I think that's what gives second like payment channel networks and like things like inter ledger or different payments on networks like the scalability is the fact that you're not propagating stuff to the entire world right that yeah that's that's a nice positive side effect but I mean at the end you would

propagate the sum up of everything that you did right when you exit prowl for this fast micropayments things that needs to go fast payment channels problem or you cannot do it better yeah so so then well if those are the unique things about channels I would say the unique thing about snarks are probably that you if you trust the the cryptography and kind of if everything is kind of works well there then you don't give up any security compared to doing it directly

on maintain its kind of this is probably the most appealing thing about snarks or well of course larks the cryptographic primitives that you need to do to trust our little a little meet a little bit more weak but we have for example Z cache which is related it's using this primitive and these assumptions and I don't know how much is what's the market cap of snarks but it's quite high for us not for like roll up I think it's the end goal of any sidechain thing where it just if you currently with slight change you're usually trusting some sort of you know economic guarantees of the side

chain at the end of the day what would be perfect is if all side chains communicated to each other with a snark that proves validity of all state transitions the only you know the in cosmos we just focus not so much on that because you know it's hard and you know we'd rather that smart people handle that and we just build state machines that you know what's easiest to do today but I think the end goal of all sidechain solutions is to be using snarks for validity proofs and and then maybe touching on the point you mentioned as a advantage for state units that not necessarily every transaction has to be propagated through ever to to everyone so kind of the scalability of the data or the network working layer so I assume there is a still probably a

bottleneck so you still probably need this operator that needs to collect all all transactions but can be a decentralized operator and at the end is for example the roll-up that we are designing right now it's a kind of proved mistake so if you want to be an operator you need to put some money on the stake and you have the commitment that you will generate that proof at specific point know that if not you you are / it so that's for example and many of those can be competing and be like a random I it's like very much like a provost stake would work but of course there are other consensus mechanism in order to synchronize the

operators but you know operators well I don't think it's going to but can be as much as you as we want but it could be a very smaller Network compared to the to the users network for most roll-up solutions real usage like for which cases do you want to have decentralized operators versus just having a centralized operator break now I would be happy just to have a single network with a centralized operator that's true but at some point when you want to the problem of centralized operator is that the operator at some point maybe can stop stop working you know it's the particular stop and then what happened

with the network and then you need to define some mechanism that you can some way or maybe other operator can take over or you need to something that this moves on and that's but that's that's absolutely solvable it's just a matter of designing a good a good protocol that that sorts all this that's an issue it's something that we are talking a lot of that yeah so I think the the advantage of saying on chain are kind of obvious or but maybe we reiterate anyway so why not use all those solutions why I try to make yeah well I think what what would say that if you a lot of these

optimizations that you can come up with in state channels and roll ups and other things are based on assumption that you will do a lot of transfers interactions but you end up with a very small state in the end let's say that you had thousand or million interactions but you ended up with a thousand holders of the tokens at the end when you settle however if you end up with let's say thousands of holders at the end you still have to settle at some point and so one of the examples I'm wearing this badge which is a proof of attendance as a gentleman on the top floor is giving him up so basically he said that he went to Sydney

due to the East East what it was a code to one of the events and then he went to India in Sydney Buddha was about sixty people to attend and he had to distribute sixty tokens and each each token transfer would cost him like once a let's say $1 in fees and people generally can afford that in India let's say 500 people turn up or thousand people so the scales are quite different there and you know they can't afford one dollar per transaction and so but then in the end of this cooperation you will need to have thousand people with the tokens so whether you use the whatever not plasma but what do you use roll ups

or you state channels the end result is going to be the same you will have the large state so that's why I would say is that it's not correct to think that the token transfers somewhere else been set so it is solving all the problems and I would say that if we look at the ERC 20 for example in a cerium they generally work okay apart from the cost problem I just mentioned and the second problem which comes up when you start really doing things like potentially like wallets or a block Explorer is that it's very hard to actually discover what other all possible talk tokens out there so I had this task recently when I had

to I wanted to find out how much of the cerium let's say state is dedicated to the IRC 20 tokens and you know it was actually not so straightforward in the end I figured out it was about half of the state is is dedicated to the balances of the air-sea 20 tokens but in order to do this correctly I had to calm the the state many times with different combs and and it's not even so the design of the token standard I mean I know that it was it looks very simple but actually it has some corner cases which make this analysis harder and I know a lot of people talked about it before so even the simple task of enumerate all the

tokens and then when you've got a token in numerating all the holders is also not trivial sometimes you actually have a sit you can have a situation where you it's impossible to enumerate all the holders because of some technicalities so yeah that I would say that it's not this scalability of transfers but the scalability of analytics data analytics on them which also is a bit it could be fixed but I think what we could do without a level 2 solution unfortunately is I have to go we have to basically recognize that token it has to be something native and implemented as efficient as you can like the the one of the parallel example would be I remember when Z cash got launched in and people added and then we

added the the pre compiles to Byzantium and people say well why do we need the cash anymore because we've got this pre comp hours we can do everything and I just did a calculation I said well it's three hundred times more efficient to do the same thing on Z cash then it's in a smart contract with the Byzantium pre compiles you know three hundred times it's already through two orders of magnitude it's it's almost it's it's basically far beyond the point where quality quantity becomes quality it's like one of the principle of principles of dialectics is when quantitative changes become qualitative so you know know it you know it 300 times it's already a huge scale regarding this

pre-compiled smart contracts just one tire question to you is that we will see webassembly in the theorem to 1.0 1.0 theorem at this point I don't think it will so that's my current view of this because I think we've maybe it's off topic I don't know it's important for scaling also because for example for validating in the validating snarks in the main theorem it's important that these primitives these cryptographic primitives are there so one way to go is going to WebP assembly that's that's the relationship but if you consider out of

topic just please I can answer it very shortly I mean again don't take my word for it and maybe check with other people but as far as I understand the the team which is working web assembly they realized that the biggest hurdle to implement in cryptographic stuff in EVM is actually the long arithmetics arithmetics of the over the to to point to the power to 250 to 256 200 500 112 with something like this if you actually had some primitives for those then most of the cryptographic things become actually quite cheap and you don't necessarily need another execution

engine for those so maybe the path but a better path is actually to introduce to those primitives may be continuing with with the discussion and talk you you briefly mentioned it already wallets and the the infrastructure that would need to exists to support some scalability solution so right now if I have a new year she's 20 token they're probably like 20 different wallets that I can just use out of the box and it just works so they just recognize the the token and I can interact with it so as soon as my token would be like just represented in a hash in a in in America marquetry or what would be in a state

channel the wallet would first just didn't recognize it so what needs to happen for the different solutions kind of is it possible to to to have fully were general wallets for those solutions that that can just support it out of the box or will it be then very application specific wallets and then kind of how how much are the standards evolved yeah we have a rating wallet or will we have a general wallet that recognizes state units and that's a very good question like UX is something that it's going to be the biggest question for most of the

layer to scaling solutions because once you have the base thing working then you have to have users trying to use it and from what you've discovered and also I think you even try it right and then after some steps you said okay you know I'm not going with it or am I wrong yeah the the I try to write in and unfortunately I think I just assumed like the the Pierce I connected to were down and so I couldn't I that's my Sampson why it didn't work but yeah so there is a ton of problems with the UX with I meant analyst III no because what I do I guess the other layer to scaling solutions may also have UX problems so we are trying to focus more on improving

onboarding and usability right now but also do this using tools that the app developer or the app user even would be accustomed to so we would like to be able to have a user using meta mask and actually use a lighter form of the writing protocol we are creating something called a light Client SDK I would also mention it in the talk for I don't 230 or 215 it is and something else that I just want to pick up from what Alex said before is that the current layer two solutions or at least us heavily depend on layer one working

properly and in an optimized manner and sometimes we seem to forget that layer one is still far from perfect and not done we like so much layer one basically we paul event and this sometimes can be different between different clients different optimizations also that at some point we also get frustrated because later on is not working properly so I want to also focus that we have to help layer one still continue or else there too will never exist or it would be too unstable to ever function sorry for switching the topic a baby so two questions I have about the UX on layer 2 one is when it

comes to wallets for example with rating don't wallet suddenly become a lot more stateful now where I like for example on etherium I have like trust wallet and like I am token and stuff on my phone and sometimes I like just switch between the two pretty quickly and which one I'm using for which application but with second layer stuff went like if I have to maintain the state of my payment channels and a wallet somehow I need a way for these for this state to be transmitted between my wallets right and so has there been any work on that kind of layer for wallet compatibility on there it just want to kind of mature everyone thought so right now you can just migrate to another wallet by just probably typing in your 1212 worth words

with with the state channel I mean maybe you can yeah I mean it's not just 12 words right so no so essentially it's a non same state that you can poll by using let's say your theorem client or with the Lifeline protocol we use other ways to pull the chain but then yes you also need to have some so for the full right in node it's you you have a full write a node with its own state in it the light client so we have an SDK that tries to keep it as light as possible but this would still need to be transferred somehow but at least we try to focus on having users of this protocol with consumer wallets like meta

mask and I am talking so we try to make the users being a familiar environment so to say really your main rating wallet will be a separate standalone software and and there's an API that will be integrated with more consumer wallets yeah we we are actually making a proof of concept one we more want to focus on an SDK for which people can build various writing modules for their own wallets we don't want to be the builders of their ID and wallet another question I have as well for the that for the UX of secondary stuff specifically on aetherium is I thought who it was someone a couple months ago posted like oh look at all these scaling solutions happening on a theory I mean I think

they posted like 10 and out of those like six of them or payment channel networks and you know for its flaws at least the foreign lightnings flaws at least you have this one thing where everyone in Bitcoin is working on one payment channel network and you have multiple implementations of like see Lightning L&D and like the third one of calories called Eclair you have like and they're all kind of they've all done a really good job of standardizing the bolt API so that way all and then now basically any most Bitcoin wallets are starting to do lightning integration now and it works because everyone's focused on one network how do you E like make sure how do wallets choose oh should I

work with Radian or should I work with the connects channels and I work with the elf or counterfactual channels how do we how do how do wallets choose what layer to solutions to integrate that's a very good question we have had a few works in interoperability between the different layer to scaling solutions but in a theorem but we also have different approaches like some of the solutions you mentioned use more of a hub approach to payment silence and we go for the full payment channel network thing if in the end we would like to be interoperable with the other solutions but that also takes working time first we would like to focus on having

something working and then see that we can interoperate between what if it's too late at that point and then we just have a huge balkanization of like like wallets on like oh we're like great in supporting wall and then how do we how do we do not think we have to pre and for interoperability rather than like patching it on pop yeah but at some point you have to make a prioritization because it's like like it's writing we have a limited number of resources and building the the core thing is already taking so much of our resources that then even within the team sometimes it's difficult to cope let's cooperate but to synchronize yeah I don't want to imagine

how it will be with I mean I just I know like a lot of people like to criticize the Lightning development team but the reason it's been taking so slow is as they've gone through this process of making sure they have consensus amongst all of these developers and so I'm just curious of like what are the pros and cons of these yeah I mean I think we can't solve solve it here now but I did definitely an important issue and it's it's true for other fields as well so they're smart country contract wallet said that could provide a lot of advantages and there are five different ones that are not compatible with each other so but it's it's of course not easy to do but let's let's continue with with like a similar question to snark stuff so I recently used Toronado cash

or something exact mixer and similar my state as a wallet starts to grow because I no longer just have my my my seed price I in addition have some receipt that I made the deposit so is this necessary as well for for if you use another is just a mixer and I would say that's just like an application like another application in this case is for mixing but it's like if you have a game or if you have a smart contract of voting system where you will have your own state so this is something that the wallets will have to handle at some point for this question before I would say that wallets at least what is that

user that users use should be user driving so who the end who who choose what should be in a wallet what couch analogy share in the wallet if you want but payments are that you know the wallets will have to and the users what they need from the technological perspective I think that the best we can do is just create like a reference wallet that uses the technology that you are providing so that actually the the wallets the same way that when the wallet just takes many coins and its take more narrow and it takes the cash and it takes Bitcoin and aetherium and put them all together in order to facilitate that due to the user and to make the things easier so there's

a process that the wallet designers should take an account that's more a process on the wallet from the technology perspective is like okay this is a Manero wallet or this is the roll-up wallet or that and here is the reference so that the wallets can implement inside right so I think I have two topics left so one topic would be or yeah one topic is how those solutions could work or complement each other so which are or like where do you see potential can you canoe first up we'll use channels was in within within roll up or something like that

I can I can say it they are very much independent on each other and the work that's done in one can be used in the other mainly for the roll up case and it is very specific doing transactions is quite easy because you can put just processing a transaction is not inside the snoring it's quite easy when you want to start doing more complex things like for example running smart contracts or you know it's running some some logics with payment channels and so on you need to embed that inside the snarks or so here the key technology that maybe that's like two steps forward but the key technology is the recursive snarks where you can insert it well you can validate the snark in circle start so we

can have a bigger snark that's holding smaller snarks and you can actually create any sort of a smart contracts that can be validated in super states of the state that are processors with this recursive a snark so that's the technology that enables all the scaling paths of the smart contracts but no that's like two steps forward right then maybe maybe the last question from my side is basically the limitations and I think Alexey touched on it earlier so yeah we could go through each solution and say what is what is he absolute maximum you

can get or kind of at what point what it's what will be the first constraint that well that will limit this approach and maybe Alex Alexei you can already comment where you see the the the limitations from the layer one perspective well yeah as a lot of people know that apparently the cerium the size of the serum state and its growth was the is probably currently the biggest limitation to this capability and there are many ways or maybe actually that not not so many ways to deal with this problem and we thought about two different approaches is that to do the

state rent and to do the sort of some kind of stateless status clients paradigm and in the beginning it seemed like the status client weren't really visible in so the state rent was the solution but now I think it's kind of not certain this way and so the limitations are that start to come up in terms of the status clients which I'm currently mostly researching is that it's essentially some design decisions which were made when the cerium was created unfortunately made it more costly for the rolling out of this things for example the if the the try in

the theorem state was binary instead of hex re the proofs that would be required in status clients would be much smaller like maybe three to four times smaller and so also complexity could have been done could have been improved so we're actually even thinking about maybe we should replace the hex Retriever the binary tree I mean it also sounded like proposed idea for me to me like four times four months ago or something but now actually I don't think it's so preposterous any anymore maybe that's that's still possible and the sort of limitations could be removed there are I don't know how many of them they are and I don't even know

I haven't finished prototyping how efficient can we be with this for example if you take the stateless client approach this is where if you take it to the extreme then you would start a scene the lines blurred between what people call level 1 and level 2 because essentially you would have segmented the network into the nodes which have a very small part of the state and they can still operate they can verify everything and the nodes which have a most of the state or all of the state and the the ones are helping the other two to operate and this is and if this is supported natively on the protocol level then people don't have to think about all this

lots of these solutions which are keeping the data of chain and put in a miracle route on chain they wouldn't even need to be done because that would be automatically supported you just put some stuff in a contract as you used to do before and the protocol was going to take care of that the whole thing is going to be just transported as a block proofs and this is where I see that the the effort which we could do on a core level will actually just reduce the effort that every dub developer needs to do on a layer on their own version of layer 2 and this is where I could see the line starting to get blurred but that's why I think there I'm not sure about limitations yet and in the roll-up

idea I would say mainly two limitations one is the generation of the proof as I explained before it's a heavily computational power that you need to generate the proofs but the good news is that this paralyzed very very very well so with you know maybe with not this course but some other more bigger curbs we and scale very much because these the operators can be you know big data centers with the clusters and can be really great a lot of transactions in that side the other that I would say probably the most important limitation we have right now is the data availability we need that availability there of course if you put the data on

chain the limitation is how much data we can we put in chain which is no much and if we put well there are some crazy ideas of using other block chains like Bitcoin cash and other stories but etherium 2.0 for example the the first stage it's going to be mainly at that availability network so and this you know this can scale you can have thousands of transactions per second easily just in in the theory on then various other technologies like file coin or other change that are very specific for that availability think it and there is also other solutions about

that availability you can also have a federation of service which is not our not so nice but from the pragmatic perspective you know if you just ensure that the data is available because you have a 10 servers running with some trusted parties different places on the world then that availability is not a problem anymore so you can scale very much on that if you assume that that availability it's a little different let me because this is important it's it's it's different of a consensus and consensus you need like 2/3 that availability you just need one server that warranty is the data is available which is it's a weaker it's a weaker requirement and kind of limitations in

terms of number of constraints or something that the reefs in the Korean Corp there is a constraint there in the Korean Court that for example that you can validate in a theorem there is a constraint and maybe you depending on the constraint of the transactions but it can be around two thousand one thousand two thousand three thousand transactions it's a limitation math limitation of that court but if you just choose on other curves that are bigger with you know bigger fields and so on it's that you can grow there so it's just a muff it's just a muff limitation there I would not even consider a limitation in global you know in the long run limitations I guess there's four cosmos on the tenement side there's

like you know you do have this N squared problem where as you increase the number of validators your consensus becomes much much slower and there's a lot of work being done but by our team as well as well as many teams throughout the space on how to improve that even further from the cosmos side I think the main limitations are that as you know the obvious one is as you go onto site more and more side-chains the total the security of any individual side chain does decrease but I think you know person I think that's okay because you know you should be using as much security as you need for an application and not all applications need to have the optimal security and I don't even

think that all applications need to necessarily settle to the chain with the OP with the maximum security and then I think yeah well and so with the drawback you know you do trust the counterparty validators set to be doing proper state transitions and if they're not the way we design cosmos is we try to make our inter chain relationships such that corruption on one chain does not affect the global ecosystem and so the simplest way to do that is you you know we focus on token transfers for now and this way to do that using other systems as well like a gorrik and whatnot but with things like roll-up and stuff with and

snarks we can eventually make it so we don't have to rely on those validity of state transitions anymore then we're really only relying on the counter party validator set for things like censorship resistance and double spend resistance and stuff yeah no writings awesome there is no limit thank you so one big one would be the layer one actually working properly and being optimized because we have had so many problems between the two major clients that we are using so parity and geese that may be around events or something events and return an error codes in a way that they handle prone

state when is the state pruned how do they handle the technicalities it's not technicalities but hey when you're developing software that's all that matters so that is one and another major one in payments and networks is a proper network health because you have payment channels and they all form a network together right and it's channel has a certain capacity of tokens in it and so after a lot of transfers a channel can be depleted towards one side so to be completely imbalanced and then the paths get all messed up and you can no longer

[Music] send payments properly through the network we are working on that we are introducing I will talk about it also in the 2:15 talk a pathfinding service that tries to provide optimal paths through the network that also take into account the balancing of the net also the fees using the property model we are trying to incentivize having a healthy network all right well so to close the panel I would give everyone again the opportunity to kind of do a call for action or something like that so is there something where you say okay well

a step that maybe developers can try out now or implement now or use now or where is the state for us so focusing payment channels a contraction would be to try to use our software and provide us with feedback so after a dies after the December Romanian release that we had we have gotten so much feedback that really helped us and help pinpointer course forward for us so the more of that we get like also the feedback that you you gave us was pretty good you will see we have a right and wizard now that will make everything that you were imagining about right and just work in five minutes yeah so and

everyone I think I can also advertise notes so didn't that note makes it actually very easy to set up a right note so yeah definitely encourage everyone to and try it out and I think there will also be talk or presentation about depth note anyway so we just published our IBC spec or like two weeks ago and so I'd love for people to take a look at it and see how to start implementing it in different frameworks because it's essentially a very well abstracted site change protocol that can work across a number it's pretty journalized and it can work with different consensus protocols different state machines and whatnot and so we're implementing it right now to have ten Derman chains talk to other ten Derman

chains but it'll be great to have more and using the cosmos SDK it'll great to have people implement it into like a go aetherium fork or a smart contract or on substrate and so we'd love to see more usage of IBC as a standard for how to do sidechain protocols on well on in theorem there's obviously this proof of authority side chains that would work as well as the standards right so that's yeah it'll be great to see like people using yeah I love to see the proof authorities I change for example maybe using the common sidechain protocol I think like one of the basics I think one common theme that we've seen throughout this entire talk was that there's a need for more standardization and so that's what really I think we should be pushing

towards any culture actions here is mainly right now the battle is very much in it scaling this computational side it's something that's very technical but anybody that knows about programming GPUs that knows about programming FPGAs it's very welcome because there is a lot of things to be done in that side of course also trees we mentioned a little bit or these coordination of the operator when we want the decentralized operator how we can not that so can create operators added so that there is a collaborative a way to do it so that all of them compute the proof not only the one that's assignment of

that there is a lot of work to do in that site of course wallet client sites there is also because this needs to be done testing documentation learning a snarks it's a full world so everybody's welcome to to jump in here and it's it's an exciting world so I would say that we identified the shortage of of essentially core development in in Syria where we people thought it was talking about it for some time and so I don't know exactly how we're going to do it but I think we need more Forks of the general purpose of clients

and we need more experimentation about like how could you do this and that differently maybe more purple like a purpose-built clients not just the one that this kind of can do everything but an average way but can do some things really well so again there's there's a lot of obstacles to that there's motivation there's funding and things like that I cannot solve over these things but at least I I say that's the the direction and of course we have this workshop on Friday but obviously in two and a half hours we can't really teach everybody from start and we really squeeze it in time so hopefully that will be inspiration and for for for us

and for all the people who can join we might do more of those things and and just start showing that this is a what people can do and just learn how to do it themselves yeah alexei gave me already a preview so it's on friday the workshop will be about just picking a very simply IP and trying to implement it and actually getting it into making proper code changes yeah well thanks thanks everyone so much I think well times over but we could allow one or two questions if there are otherwise well next there's the lunch break but if there are one or two questions okay we covered everything thanks everyone

[Applause]