Scalability & Sharding

Transcript

hello everyone okay so as you can see I'm not wrong which should have been here initially - to present this sadly it had an issue to get a visa so that's why I'm doing the presentation instead of him so myself and the CTO and I'm more like we've been enjoying your background so I will present you like some algorithm and as I'm not the mastermind behind all that theory please understand I might go a bit fast on some stuff so um if later you have some specific question about algorithm I will give you a way to contact Chang also directly okay so yeah as we Alex said

you know scalability is a single most important technical challenge that we have to solve if you want to reach mass adoption for for blockchain basically today if you remain Bitcoin they can achieve a maximum of 15 transaction per second well if you look at a system like visa where worldwide system it can go and thousand of transactions per second so I guess you are more or less all well aware of that issue we saw in the past or still today some some solution to solve that there is a unsane solution that implies sharing there is also have changed solution that we saw also today and I firmly believe that buffer are a complementary and that in the long run

we should use them together so clearly if Hume is leading the way in for the research in that area so it's a real pleasure for us to be to be here today there's many progress being down we could see that this morning in the keynote so it's great so many of the existing trading algorithm that we see today they are basically similar to frame sharing so in a nutshell they rely on proof of stake in a validator shuffling I guess you get the idea this morning during the over presentation and in some way they all imply the usage of for two-phase commit when it comes to

cross transactions so this is quite challenging in different ways but but first like reshuffling introduced quite an overhead basically to catch up the entire state of a new char that's that's expensive also crucial transactions well actually it's not so efficient because they have to do to be done in multiple step so yeah it's not ideal so at a Lapham we decided to take a another approach and that's what I will present you to do till you know so we proposed a new a new approach we call block flow this is a white paper you can find on our website that describe in detail how it works so we have an innovative

consensus algorithm where we combined diag erecting a cyclic graph and shredding together thanks to that we can support cross chart transaction natively which means it's you just do a cross cut transaction in one step it's just one operation the network is vulnerable to 51 attack like Bitcoin and that 1% attack and we also provide a practical solution for scaling smart contracts so it's quite nice because all the main obstacle were resolved when we implemented the alpha version that we have currently working we were able to run it on AWS and we got some yes some really nice metrics out of that so

basically we're able to achieve a throughput which is a higher than 10k transaction per seconds so now I will give you a more detailed introduction about the the algorithm and how that works but before really getting into the the detail of the algorithm sorry I just want to give you a quick sneak peek and the under philosophy we follow so basically we believe that the evolution of the blockchain algorithm follows the same evolution path as the computation model so you're probably all we're aware of the of this evolution of computing model we started with sequential

computing and then we we move to concurrent computing and eventually we reach distributed computing which is basically a shared version of concurrent programming so now if we think about a blockchain how does that match you know basically sequential computing is the equivalent of the single chain like the original beacon paper then the equivalent of concurrent computing is is the dag algorithms so we believe that the next natural evolution that corresponds to two distributed computing is basically combining dag we sharing and that's what black flow is doing and it's to our knowledge it's the first of its kind to do this kind of a

combination so let's see how the sharing works in practice so our shading approach is quite different from the existing ones we use a scalable UT EXO model and we have two level of serving so at the first level we take the addresses and we share them into G groups so G is a is a parameter of the network then at the second level we take transaction and we share them into G times G groups based on their input and output addresses so if you look on the left side you see a little graph as an example here we have three groups a B and C so the transactions

they have nine different categories which correspond to any two of these three groups right so that's why we have we have nine edges in this graph and each edge have a unique blockchain right so now let's see what kind of property we get from this design right so first well let's say I want to do a transaction from one group to another let's say for example from Group B - Group A well I can directly commit my transaction to this edge chain in just one single operation so that's a pretty nice property also if we look at what

group B needs to download right actually he only needs to download what is highlighted in around in this graph which is basically all the transactions coming to this group and getting out of this group and that's basically 2 times G minus 1 of the overall G times G Assurance so that's also a pretty good property to to have so of course shelling is not just about sharing right it's also about reaching consensus for all the charts and that's quite complicated as we could see right this morning in in a in some of the talk so

in the network each charts can have Forks so how do we ensure that eventually the network will select compatible and correct Forks for different routes and that's basically known as a fork choice rule and we had a great explanation about that this morning so in blood flow we use a smart data structure to resolve the dependencies of the different Forks and we've one kind of dag algorithm which then combined which is then combined with a penalty algorithm and this way we reach a consensus so to be a little bit more precise in blood flow each black selects several black caches as dependencies and pack them inside the the block content

right and so each new black determine determine a unique fork for each start and that's in a transitive way that's very important so in the end the or consensus algorithm is not that different from a traditional black chain the minors in addition to packing the transaction they pack the dependencies and also the know they have to validate the dependencies in addition to the transactions so this is just a small example graph of dependencies between between blocks between each it short so if we if we say that Alice which is in

Group 1 want to send 10 coins to Bob which is in group zero so at least first created the transaction in broadcast is to the network the mine is the miners for c10 find some of the latest Block in over Charles the miners back those ashes and transaction into a block and then the miners miner proper nouns and broadcast what casts it to the network so the thing is that the the ashes they are selected based on a sophisticated algorithm this is a describing in nice detail in the white paper so with this I go within we don't have to include all the ashes of all the shelves in the

network right and at the same time we can ensure that all the ashes are compatible with each other so do some some form of validation so now let's do a quick analysis of blood flow so first in time of speed you can find a more detailed semi formal analysis in the in the white paper but basically if we say that's if the TPS of each single shard is B then the overall TPS is P times G times G right so for a 10 megabit network bandwidth we could choose P 15 and G 32 and you get over a 10k transaction per second yeah it's worth noting that even with

the G of 6 you're already higher than 500 transaction per second security as I say the earlier the system is is vulnerable to 51% attack like Bitcoin but not one person attack and that's thanks to this block dependencies mechanism of course all of this is nice but it doesn't come from free right so what is the cost of using this approach basically the the main cast is that you need some spaces to store the the the block dependencies if you if we take GE Geller 32 it's around one kilobyte we've wrote it a but there's a simple optimization that can be implemented and we can get down to a couple hundred

bytes to store that and then there's also another cost in term of validation that need to be done but we believe it's quite a negligible compared to all the overwork that has to be done at that time so that's it for the the theoretical part about the the algorithm and now I will just yeah let's see how the application of Elysium like looks and what kind of advantages you can get as an D app developer so yeah so our design philosophy is to is to scale the what we believe to be the most useful

functionality and to rely and less scalable solution for the overflow functionality so when I say the the most useful function T we have in mind talkin actually so the way we designed that is we decompose the handling of smart contracts into a token protocol and a data protocol and we support smart contracts into specific chains so here if you look at the graph these dis chains here a B and C we call them the intra group shared a chain and basically here we can keep a consistent state so it's possible to render the the small contracts there oh yeah and yes so with

this our tow country particularly is friendly buff for users and developers because it's simple it's simpler to use than something based on a two-phase commit and so the user experience is roughly the same as if you were working within a single shard so please also note that our token protocol is programmable to some extent even though it's not your incomplete like a full fledge smart contract language so yeah what can we do with that right what kind of thing we can do so we all know that a lot of his kids will benefit from this for maybe even a scalable blockchain because of the performance improvement

so let's see if you example where Aleph M could actually have specific advantages or exist trading approach thanks to the algorithm where we are using first we could actually build an efficient and fully insane decentralized exchange we that we still don't have today we could also build prediction games that will run at large skilled using the token protocol and last but not least for stable kind banker or maker Dow kind of protocol the an Ling of the exchange could be done with smart contracts while the token will be distributed among all the shards so we think it's a really nice scaling

property but anyway in general thanks to this a native cross word transaction support roughly I mean all application could could achieve a better scalability so thanks for your time that's it it was a pleasure to present Aleph him to you I hope you enjoy it if you want to know more please go to our website you you can access the white paper from here and you have all the detail about it in case you you have some question you can catch me around for anything that is really related to the algorithm design that I will ask you to to contact anyone directly if you go to a web site with a telegram a telegram group and you can join here will be will

be had a happy to to help you yeah thanks