#209 Amrit Kumar & Xinshu Dong: Zilliqa – A Scalable Sharded Public Blockchain

Transcript

[Music] hi welcome to epicenter the show which talks about the technologies projects and startups driving the crypto economy I am a Roy and today we have a very interesting episode discussing sharding and a project that has a unique approach at sharding blockchains we have on the show xin shu dong and Amrit kumar from silica since you as the CEO of silica and amber it is the Crypt elite there silica is an innovative

blockchain platform which has a a sharded blockchain already running as a private Testament since when welcome to the show thank you it's our pleasure to be here thank you very much thank you so before we start talking about silica and what that project is trying to do tell us a bit about your background and how you came to be involved in the blockchain space sure so maybe I can start my my name is Cheng Xu um I'm from the more technical side in my PhD I worked on cybersecurity for web browsers in a web applications so later I worked on you know the security for control software control software for larger systems like smoke weed transportation internet things

things like that of course I started to develop a personal interest later on blockchain yourself and here you know predict Saxena talk to me again you know I used to work with him very closely during my PhD time so after a few years he talked to me again he I started a company you know we're working on blockchain why don't you come in joining us so that's that's the time I really started to think seriously that I should you know really work full-time on a blockchain and and I I did so after a few month I join his company and started to develop this skill about blockchain technology into you know commercialization into deployment as a permission approach and you know that

was about you know more than one year ago and that's how I started working working on blockchain cause you know this year we started this new project silica I'm very excited to bring that technology into a much larger scale as a public blockchain you know that's very briefly about myself yeah so for me I have a PhD from India France and then I came over to Singapore I started working as a postdoc at a pretty sexy huh and then I started iscoming blockchain man and they're different different problems and solutions and my essential background is on applied cryptography and privacy so again it was the same kind of story but they called me up and

said yeah are you interested in something like I said find out and then I joined the project so yeah cool so I think I think very few of our listeners would explicitly know about pratik Saxena and the and his group at NUS Singapore so as I've seen a lot of papers from this group including so there was a paper called like demystifying incentives in the country in the consensus computer that that that that posited that there was some kind of verification dilemna in in a blocks in like a cerium and that translated through multiple different technological jumps became like the true bit another

project to come out of this group is like noise work starting with secure smart contract languages and then ultimately decentralized exchanges and khyber Network so that is so loyal so today's PhD as far as I know from from this school and another project that I know of personally is just this one zelicah so there's this between at least like three three three interesting projects that that have come out of this group that's unusually productive for an act that's very unusually productive for an academic group in any university outside yeah yeah you know we're very fortunate to be part of the group as

well so you know the whole idea of silica you know is inspired by this original academic research paper cause of by law and pretty is called elastic oh no that's that's where or these kind of ideas of shoddy started okay so let's let's drive down into zelicah so silica is a is a Charlotte public blockchain with its own cryptocurrency called Xilinx but before we try it down into what exact exactly the way the technology works let's talk a bit about scalability in in general right so our viewers know about the scalability problems of blockchains

because we have talked about that many many times they seem that is not perhaps a bit less known is what exactly is sharding we have this word but is there like a good definition for it I don't know I guess I would not try to give a very formal definition of shouting because I think that this term shouting was invented many years ago in the ending the database community but when you know people bring this idea of shouting into public blockchain to try to make the blockchain the most global the high-level idea of shunning is quite straightforward let's just assume we have a blockchain network of 1,000 nodes so what shouting to us is to divide these 1,000 nodes

into let's say ten jars you know with under your nose each so then what it does is to process different transactions in different shots disjoint set of transactions so then you can achieve some level of parallel processing so this in yourself improves the throughput of the blockchain by by you know a large large factor so this is this is a high-level idea of sharing of course you know to really work it out to make sure this process is secure and it's very efficient you know that that's where you know the complexities come like sharding I presume is like this technique that has been used at

different sort of database designs of course time right right and now we are bringing that sort of knowledge and and those techniques from into the blockchain space which has its own unique challenges while you while you shard the blockchain right so like is sharding a single monolithic technique or are there different kinds of sharding that have that are possible I think there are different possibilities or the forbearance of shouting so number one I think where most people talk about shouting we actually refer to something we would call a shadi so that's maybe the closest you know the derived idea from the database sharding

concept so what stationing does is essentially it will divide the nosing and they work in two different parts so when one node belongs to one part or one shark that knows only stores information for that particular shop in other words it you know it doesn't know what's going on in another shop know what's going on outside the shot itself so this clearly has several advantages so number one it significantly reduces you know the size of data each no needs to stop and reduces you know the number of connections in each no needs to process and it also reduces the volume of data that needs to be propagated

across the network because you know you just you know send some data to this shot you don't need to send the same piece of data to another shot for example so these are all these advantages of stay shining that's why this concept is very interesting but on the other hand there are also many challenges to you know to do this properly so number one is security so if one or stage within one shot and then it doesn't actually understand you know oh you know knows outside that shot I understand things going on inside this shot so if a tackle is just focus all the power attacking this particular shot you know over time this may become a patient so this is number one in number

two is about redundancy or resilience because instead of let's say a whole network of xx other knows storing twenty thousand copies a particular piece of information now you only have let's say 500 or 1000 notes keeping that piece of information and once one third or half of those knows have a problem with the information either the compromised or attacked or deleted or somehow just lost such information it's a problem because nobody else in this network you know understands at this particular piece of information so these are some of the issues I see if I may add to this I mean this whole idea of steal Shawnee let's

say it essentially came from Bitcoin model right where you have this you txt model and you want to if you want to know whether an output has been spent or a cylinder spent you want to have to store and you have to store the diet history and that history can be very huge so you need to kind of divide that history to chunks so that each not only has to solve part that that chick that died astray so the story comes from comes from these su tx1 Bitcoin card model yeah this is this stage sharing of course you know we started this idea of this direction of possibilities where we design the Silica's protocols our sort of conclusion at that time was it's very

challenging to do that we would rather need more time to work on it on the other hand what silica Caritas is something we can call never shutting or transaction shoddy that means for each node it still stores all the current state up you know up to date let's say account balances for the entire block chain network so it's not still charting but on the other hand we shot the processing of the connections so that means we have different shots we will send different transactions to different shots for processing and eventually you know what such information for the next block will be aggregated and still sends through to all the knows so you can see easily here

we you know the pros are very simple we basically avoid many of these security and resilience challenges initially but on the other hand there are additional challenges in doing all these network sharing compared to stitch on it because every no remissed you need to store lots of information and still we need to propagate lots of information to all the nodes so you know these are some of the places silica is you know doing the information ok so so when you speaking is in show like sort of imagination came into my mind which is that we can imagine we can imagine like any blockchain for us like like a blockchain

like Bitcoin let's imagine that as sort of sort of like a government office right like so so there's this there's this government office and they're like employees in that office and all of these employees they are just accountants right and these accountants are basically all the nodes so these are the these are the full nodes of of the system so whenever like you want to process a transaction you you you basically like go to this building and you like put the transaction in and all of these employees they maintain their own book and they're gonna area they're going to verify that your transaction is right

and they're going to add it to the book and the the they working in this sort of office this governmental office is designed in a way that each employee will add the same number of same transactions in the same order in that in that book but that a that book is replicated across all of the employees so if there are like a thousand employees in these this building each one of them has the same copy of that book and at any instant of time each of these employees is working on that on a same set of new transactions to add on this to this book they were verifying the same set of transactions right and so that's like that's like Bitcoin

that's like etherium today so each employee is redundantly doing that work and all of them are redundant lis maintaining that the same copy of this book now what-what silica does is like once one step ahead so what silica does is okay this there's the same 1,000 employees now in the silica blockchain but the same 1,000 employees need to maintain the same copy of that book and that book contains all the transactions that happened in silica but the advantage is that if there is like 1,000 employees then we can have say groups of 100 employees in some way that are working on different

transactions so let's say employee one until employee 100 works on one particular set of transaction at the same time employee 100 to 200 works on a different set of transactions at the same time and so on so they are like 10 subgroups in this government office each of them processing their own set of transactions but each employee ultimately needs to keep lack of transactions that know not only their group has process but also transactions processed by the other groups as well right so that's sort of the silicum model and early for the silica model and then you could have a higher level model which is like stage Harding in which these 1,000 employees

are again divided into ten groups of 100 each they are processing their own sets of transactions but each employee is maintaining the books each employee is maintain the ledger or UTX asset or book only for the transactions processed there by their group that's right if I'm in group number seven my book contains only the transactions processed by a group number seven and if some if my friend is in group number five they won't they only contain transactions processed by group number five but even though my book and my friends book do not have intersection in the transactions we have process somehow there is a way of making sure that there

is no double spending like I am NOT processing the transaction and he is processing another transaction and they are couldn't conflict with each other so so that kind of thing which is the ultimate in sharding would be staged sharding yes yes and zelicah is not staged sharding it is it is that in that intermediate level where I as a bookkeeper need to keep track of all of the transactions other groups apart from mine also processing but per se my computational cost in verifying transactions is limited to those process my by my group only exactly so I think this is a very good analogy I just want to clarify a little bit on the silica model here so I I think the state

charting is very interesting but you know there are many challenges very discussed security redundancy and this you know cross your communication basically these are main challenges we we should you know what very hard on to resolve but at this stage I still cannot know for sure whether stage shutting is the ultimate you know objective for for charting point of because if you look at the Komodo you know all these accountants process different employees transactions and they eventually every count and still be updated on every every other accountants processing a process the connections right but this is this is the current implementation of zero coyote code but

the design of silica is not limited to this so for instance to address this issue of you know excessive storage requirements so basically each accountant needs to know every single transaction right we can reduce that because when we say we don't do stage shutting that means every accountant needs to know the balance is for every employees but on the other hand it is not necessary that every accountant also keeps a precise record of all the transactions right since there's a difference if you look at like if the rims accompanies the model you just need to keep the balances you don't need to know all the history hmm most of the

applications as I see only need to understand the final balances but some applications will also need to you know access all the history like either scan for example so in that sense we can we can you know reduce the storage for every accountant by applying another Magnum something like DHT for example you notice to a hash table to to allocate you know which know to a store which which historic data so that's only about the historical you know transactions but this is sort of off the corner to the fact that every accountant still knows the account balances for all employees that's just one thing I want so yeah that that's that's the super

important so basically like what what you're saying is like even though if I mean like Group one and I need to know some like something about Group 7 there's this ways in which I can reduce the total set of knowledge I need about what went on in room 7 group 8 so instead of knowing all of the transactions that happen I could just know the state of the ledger after those transactions were process exactly exactly so like one of the one of the like doubts I have in my mind and I think this is a doubt in many people's mind is if you look at the blockchain space today there's there's two kinds of

projects broadly there's like projects like cosmos and polka dot there are like promising interoperability and now we see just the beginning of projects that are actually offering sharding so like silica is probably first at least its first wave interview what is the difference between interoperability and charting yeah this is a very good question you know to me you know I can't I can't really do an absolute line between interoperability and any sharing especially if you look at things like plasma for example like you have a man chain you have side chains so so in my view usually when we say sharding is

still about shouting we think one option so it's it's one single you know unified blockchain but yeah I mean whether over time we can when the intraoperative party is very mature whether whether the the boundary is still very clear or not I'm actually not very sure yeah I mean I think I mean a completely Audrina you know you have different problems in the blockchain space and different blockchain technologies they come up and they solve different problems right now the solution is how do you unify them you can't have 1 million block chains and standing all alone you want to wait so that one locket can talk to another blockchain and this is where this interoperability comes from and we

definitely need a technology like this so that one one blockchain technology can talk show another blockchain technology I probably have you know take benefits from from the other technology I think but they're completely complimentary things right solving let's say scalability problem and this designing a protocol that allows you to interoperate or you know talk communicate with other block chains that kind of orthogonal problems so what do you mean when you say there are orthogonal problems which means that they solve two different problems blotches which address scalability or let's say throughput they want to address so they try to address I mean how can you increase well the technology that you should like what's the protocol addition apply so that you can increase the throughput of that blockchain so this

could be a block scene that tries to solve scalability you could imagine blocks in such as Z cache which which are merely focused towards privacy they want to ensure that whenever you do a transaction it's private which could be let's say hide in your mouth hiding who is the sender or who is the recipient you know for these kind of features oh they both is you know blocks is they saw different problems but one is solving scalability the other instead of ten pixels for the privacy bar now you need something in between that can allow you to talk you know try to communicate from one blocking to the other one so that's another time this disorder the blockchain will be solving another problem which is very and all three are very crucial for you know for the blockchain ecosystem to work in a

really nice way but they all solve different problems it's like we imagine this government office this government building with a thousand employees working in it and scalability is okay we have a thousand employees how do we get them to do the most work securely right yeah an interoperability is sort of the problem that ok let's say we have like not one but five different government offices each having a thousand employees how do we make sure like that we can have things where I can submit a paper to this first office and then they are and then you can shuffle it around

between these two different government offices and do something which like sort of I don't know allows these offices to collaborate so interoperability is like a postal system between between these offices or these government buildings it's more like a postal system a good postal system whereas scalability is getting the employees in one building or in one office to be able to do more work than what they can today that's how understanding of course you know the difference between interoperability and shouting is really the difference between you know whether this is the one cup of body or five

government bodies okay okay make sense so yeah let's let's let's go down to like how silica achieves this this this level of sharding so it could give us a broad overview of how the network is designed yeah silica is you know it's really complicated but but I think I think you know it's also very based on several important building blocks so number one we need to make sure not not every node can create arbitrarily many identities because you know if you can create arbitrary many identities in a consensus process if you is oversimplified as a voting you're out

vote or the good guys so that's why we need to establish some way to sort of that people only create proper identities you know that that's something we knew would resolve so that's where we have a proof-of-work so people have to do approve work before they can enter into our consensus of protocol and okay now the question comes how do we do this how do we you know sort of enforce approve who odd who a check you know who is from improve work correctly or not corrected so that's why we establish something called directory service committee you know this is just one more name we give basically this is the overarching layer so we all have

knows competing a proof work to carry into this particular overarching community so once this committee is formed this committee becomes the body that will check other nodes so when other knows doing proof of our it will check whether this is the correct or not correct and then those knows who have done correct proof work will be allowed to participate in the consensus process and this overarching directory service committee again is the body that sort of device or this you know goodness knows who past eww into differentials and then this overarching committee also decides

how do we send different transactions to different channels for processing and eventually aggregate or the process transactions into the final block so if we go back to the you know Garmin anacondas model so this is like like the top governing body though the the selection criteria is hours of higher and then once this gamma body is selected it can you know sort of allocate different accountants to different departments and decide which department processes which sort of employee data so this is a high-level design of the network one key thing we have to make sure you know this is done properly is that this so-called

directory service committee has to be decentralized you know otherwise it's very easy we just pick five or even 100 so-called super nodes which is trust them let them decide that that in our view is is not ideal because you know people can keep their power attacking these nodes if they are static and this knows maybe crapped in you have way so this started a Service Committee has to be decentralized so the election of this committee itself is also by proof work so that's fair to everyone and we keep updating the composition of the committee you know to make sure this is the time a dynamic committee is not ecstatic forever so this is the high level idea of silicon's network design

so would you like to add something over it she just said you know you want to have you want your network same imagine your network right you want to divide that network it is subparts but you need some some you know somebody or a group that that's going to control that in a way that it's going to say you know you go to this shark you go to this shore newman edition right so you need a body that's going to you know run that thing right and then that is the discovery and as you said you don't want it to be one person because then you can attack that you want it to have because this this this body will have the right to say you know there's this this note is going to be assigned to

this shot so you don't want to have an app you don't want to give one person absolutely try to do whatever he wants and that's why you need to have a sufficient number of notes in that in that body in that committee and then you want to elect them in a fair man as well so these are the crucial points that you have to do in order to be shy so apart from the directory service community like so you have these groups that are data processing transactions and this directory services sort of the administration that allows one of these these groups to even coordinate and these groups to even form process records actions and then maybe we even even coordinate so that's the directory

service committee that's in the sort of in the center and then how are these groups then you have groups that like process transactions so if I am a node if I have a new node that is like joining this network basically like a new accountant or new employee coming into this network I have the choice of either trying to go and become a member of the directory service committee or only become a member of one of these groups or become trying to become members of like one group and the directory service committee right yeah yeah this crown staining okay okay so so so tell us like like how I can enter the

directory service committee or how I could let's say let's say let's take the earlier example is like there's a thousand nodes with like ten shards or ten processing groups each with 100 nodes so if I want to let's say join shard 7 or group 7 how can I do that and then if I want to join the directory service committee how can I do that as an you know so in general a node cannot choose which Shara which group it wants to join because that sort of decided based on some randomness in the you know proof of work without it generates it's designed that way otherwise if they

can choose which shot I want to join I can you know group with all these bad guys let's let's all go to shot seven and compromise that shot no that's that's a hallelujah so what happens is at certain intervals let's say at and every two hours roughly to us it's based on plot time of course let's say I'd roughly had every two hours the existing directory service committee will announce an open competition you announced a now there is a new proof-of-work scheme everyone can participate and then and you know not existing in this name or outside you know that's fine any node can do I can just join this competition and and try to solve that puzzle of this proof of work so the

Wigner will be sort of agreed on by existing members of this directory service committee and then you know join this committee by doing that the committee will also ask the oldest member in the committee to leave this this is the way how it's updated so the membership of the committee is like charge or the range every two hours and then the process for like entering the committee is to solve this proof of work so yes let's say these I didn't in two hours there's this proof of work so I participate in that puzzle and if I solve it I become part of the committee and then the oldest member of that committee will end up in the plea is yes

right imagine this is the change this is this is a blockchain as well so whenever there's a winner that proof of work that name will be added into a new block and the block is appended to that shell and then you know if you go back to along the chain you then you can move we move the oldest block so what happens in those two hours so let's say like okay I'm a new node I ended up I succeeded in joining the DA's committee and now for the next two hours there's not going to be another another puzzle or another node joining us so there's a set of these committee nodes is now known for two hours what do we do during this period so two hours

example you know we can't do it every 30 30 minutes for example so so this is the interval where we all sort of elect a new member of the DA's committee and then you know at that time when we after we you know elect a new member into the committee the DA's committee can call another run of proof work to sort of incorporate new nose and this process of course can be done more frequently we can be done like they say everybody 20 minutes as well so these are parameters who can tune obviously the TS can be teacher announced another proof-of-work scheme to ask new nose to join they were not drawing the DA's committee but they were doing into that groups for doing consensus and process transactions so

this is another a performance scheme we will leverage on silica and you this this also you know understand body this is also much easier because it's not that competitive in the DA's committee election is very competitive everyone is competing for that one position and this time is not what number we are accepting 20,000 nodes so as long as you are you know you are reasonable computer you should be able to join and there according to the result of your peww and you will be shot it into respective committees and this logic for sharding is decided by the DA's committee anything to add yes so the two points here right so the basic idea is that you

want to elect members in the shot and you want to elect members of the committee okay there two points now the two ways of doing it what is that you elect all of them together right and how could you do that you say that everybody's going to solve qw and everybody's going to submit their period of view and it would say look I have received all these cuter because I would have sort them out I will take the smallest one let's say because these random bits include a whistle you know you cannot be that graphics then you can say that look I'm I'm going to sort all of that and I will take the smallest one and that will be cool to the ds1 and the rest will go to the shop right this is one way of doing it we said that you know we want to give freedom so we want

to have some freedom so we said we are going to be couple these this these two lashes so we would say first select the DA's people the DA's member and then ask them to elect the sharp members okay so that's why we have one pow2 elect the DA's committee member and second PWE elect your Sharp members and that is that if you decouple it there you have some freedom in saying that you know second one can be done move faster than you know more frequently than the first one and so on so forth so that gives you freedom about deciding how frequently you want to do how often do you want to elect the members in the shot and how frequently won't we liked our member in the committee and that's why we take up our okay okay so so

basically like if I'm a new node I can first become a member of this chart by solving this P or W and then like this this DA's committee can last for for this a longer duration and in these in this longer duration like there are like shorter durations where there's where they're sort of elections or puzzles that are going to determine who processes and who belongs to which shard and that is a separate proof of work and I could conceivably participate in that as well yes and like let's say be allocated to short seven and then I go and process transactions inside yeah short seven and after the next one maybe

you are we shuffle toe shuffle this so okay so in the secondary election is like I'm in charge seven first and short five and short three and again back to shard seven shard nine so I'm being I'm being shuffled around not only me but like all of the nodes we are being shuffled around really well and then if I'm in the DA's committee after let's say a certain point of time I will become the oldest member of the DA's committee and then I will have to exit that committee if I want to rejoin it I will have to win the lottery for that DA's Committee again yes yes so for example winning the lottery for the DA's committee once might entitle me to be there for quite a long while well why the oldest nodes getting keep getting

churned out right I might be I might be there okay okay so that makes it so let's say like a now I was assigned to shard number seven so and then there are like a hundred other nodes that are assigned to shard number seven for the next 20 minutes how do we process transactions in that chart how do we come to consensus amongst these hundred nodes yeah so what happens is that let's say a user created from trust transaction it goes to the network so let's suppose for the timing that it ends up in that shot and why why would happen is that the transaction has a senders address right so what what I might have so let's imagine that yeah

when you do shots for the time being okay just to simplify the scenario so you have two only two shots and how the store that can we go through is that this sender address will be will be checked and let's say this last bit is zero could be 0 or 1 and if it's zero it will go to the first shot if it's 1 it goes to the second shot now if you have more shots of course you can do a modular is material then you could end up in a specific shot so a user sensor transaction it goes to a specific shot depending on the sender's address and then there will be a consensus port code within that shot for that for that transaction aha so so basically like this is a way of automatically

preventing doubles paint in some way because if I am a sender of a particular transaction my transaction can end up only in one shot and it cannot go to two shots because my address is sort of known and that address is going to the address triggers a deterministic computation which sort of gives the output as like which hard this transaction belongs to exactly so if you're shorting with respect to I mean if you're assigning the transaction with respect to the sender's address you have this advantage right yeah but let's see if you don't do that if you instead do with respect to the receivers address for some some reasons you won't be able

to preventable spam so sharding with respect to senders address this automatically gives you a double spectrum of prevention so this is like like like a transaction partitioning scheme in some way right like so like the government office these transactions are coming in and we need to determine which group they are going to go to and this is the simple heuristic and the other heuristics you considered or this one was the clear winner well I I do not remember if you tried anything else yeah I think so obviously you know it gives you a pretty nice solution why would you bother about anything else okay so what is the consensus algorithm inside one shard and

like what are sort of the performance characteristics of of an individual shard it's it's largely a we stone the practical presenting for tolerance pbft uh but you know we understand pbft performance very efficiently for a small size network and they were like 100 nodes too hungry knows I can't generate very high throughput but on the other hand we have a larger network and there were thousands of nodes or tens of thousands of nodes and the performance of PBF do deteriorate so this is in contrast with nakamoto protocol Square you know through code is very stable but this larger was more small network so

but me pbft has several advantages so the main advantages we like up you know about pbft is it gives the finality so that means once you agree on the block few transactions you want to accept it that's done no there's no way you can rewrite that history so what we do is we leverage from some of the existing literature to use collective signing or not signature to address one particular performance issue in in pbft basically in pbft is all about those talking to each other saying I have seen this you have seen this okay I have seen enough

people telling me they have seen this so when they send such messages they have to use this digital signature to say this is really from me in otherwise malicious knows gain can just you know craft messages which seem to be from all the other nodes in that's why you need digital signature but then when you have a very large network like they want out the nose the size of the digital signature will become a performance bottleneck when you send these messages across so that's why we leverage is no signature to reduce the size of a signature from you know we called our band that means you know it grows linearly to the number of nodes in the network to a constant now that's a

big performance you know benefit we we we we obtain from there and you know Amador tell us more about what are the issues with directly leveraging the stones you know signature you know there are also security issues that we have to address with additional steps but you know that's that's why idea and another idea we we try to develop in this efficient consensus algorithm each sector we we play around different network topologies so you can have a random topology you can have a tree topology which is in original proposal of leveraging strong signature and and you know a star topology and eventually we choose the star topology

and so we think this is the most efficient way to send messages across so there are you know different aspects we had to enhance all pbft and a memory can talk more about this no signature box or so just before that I would like to highlight good point on finality to it so if you compare that say consensus protocol on Nakamoto and pbft or PFD + 4 BF d carcasses per call give T or ppfd they give your finality which means that if a block set of transaction goes it was no chain that's fine you know you would have you do need confirmations on top of that this has many advantages

what is that because it's your finality you don't have to care about confirmations because it stopped by the moment equals block ii guarantee that it then you have is that you don't have to keep the previous history right if you look at the Nakamoto kind of masses protocol let's say no doodahs fear of going to service a block you don't know whether it's going to the final block until you receive a bunch of Misha's so you have to store that block for a while while in case of pbft kind of cuts us protocol the moment you know you agree on a block it's final you don't have to store blocks that you know that we received previously you can just get your state update of state and then you're done so it also tells you in to some extent that state sharding is not that

important when you have finality great point great point so the way the way my imagination is now so let's say like I am now a user of the system I am NOT a node and I am sending a transaction to Xin shoe so I create I create my transaction it it looks like a fairly standard transaction so I'm assuming I'm in my heritage it's like any sanitarium like transaction there is a gas price and it's like it is my account number amount gas price like cold stuff like that and like data and so when I send this transaction to the network based on

my address this transaction will be allocated to one of the shards inside that mom was the nodes of the shard listen to my transaction they will participate in a consensus algorithm so which is like practical Byzantine $4 in space so this is the same as like things like cosmos similar to things like cosmos what they're doing and then a block is created and that block has my transaction in it and as long as soon as I see a block in that chart with my transaction in it I'm done for for all intents and purposes as a user I can take that as a guarantee that my transaction is confirmed is that correct

at the high level is something like that but but you know there are some there are some potential issues being accepting just whatever that comes out of the particular shot because you know we still need some verification from from the DA's committee because we see this this block how do we verify how do we verify that more than two-thirds of the know sort of agreed to this this you know sort of we called micro block you know there that is one more step we do in silica so what happens is that the moment you create a block at the short level it kind of gets to the DES level and then D s level so every shot will propose a block we call it micro block so the first shot will give

a micro block the second shot will create its own micro block and then if they will all go to the DES cavity and then this D s commit even aggragate these two micro blocks into what is called a final block and then final block helps gives you the finale so there is another one one level up and the DA's committee once it's like it collects these two micro blocks and wants to put them in the block all of the nodes of the DA's committee are going to verify all of the transactions in these blocks individually and you do not need to know verify the transactions again otherwise you know the DA's committee would become the bottleneck it would defeat the purpose of shouting boy all these know Stewie is it will verify

that enough signatures have sort of validated the correctness of this reaction from that particular shot so basically if I'm a TS committee member at that point I'm like okay I received that I received this micro block from shard - okay I'm going to check which nodes assigned to short - in the past okay I assign these particular 50 nodes to that shard in the past then in the in this block do I have 2/3 of the signatures of these 15 oh yes yes verify is now the signal is correct okay be signature there's more than 2/3 signature these signatures are correct okay so I'm going to accept this micro block so that's how I accepted the micro block of char

- then charge then I then similarly I accept the micro block of shard 1 and then I say okay I am then I am in a state where I say in principle I agree to including the micro blocks of shard 1 & 2 like these two blocks into the blockchain and now then then I just I'm just one TS committee member and the other DA's committee members are having like like similar threats so how do the these committee members now come to consensus on whether these two blocks are finally they actually run another round of consensus protocol so okay to make sure the final block is also final you know it's it has a finality and that

is also a pbft yes haha okay so basically now like a user from the user perspective I sent a transaction to sin-shoo and I have to wait that my transaction gets confirmed in let's say shot two and then in and then the block of shot two gets confirmed in the in with the DA's committee so I have to wait for these two confirmations and these two confirmations have like strong finality so once the block is made in the shower and in the DA's committee dang dang I see these two blocks now my transaction is confirmed and since you can basically give me the car or whatever I'm looking to buy so this is

the fault very strong you know security on the other here for for applications you can you can use some heuristics for example where you see your transaction is accepted by Wang Xiao Yu you may you may believe that 99% of the chances that these this generation will eventually go to the final and a final fun Apple Opera you can you can make assumptions like that and for some application essay payments it's fine because you just need to have some reserved to you know rectify some of the 1% exceptional cases in that case so so that can give you sort of a very much shorter latency cool yeah so at least I have a rough

idea of of silicon and our better idea how it works can you tell us like what are sort of the scalability advantages of a design like that so let's say we start start with like two shards each with 100 nodes or something let's start with like one configuration and as we add nodes what what happens to the throughput of the system so you we are creating shots to ensure that you can do transit spamela as the high-level idea right now you need to have more shots you gotta move to you know if you want to achieve better parallel sessions right so let's

say if you have only two shots you can do two times the processing if you have four shots you can do four times processing it's you have ten shot you go to ten times processing so ideally they are two parameters again what is how many numbers of shortywood and what is the size of each shot right the two parameters a session well roughly speaking the more in I mean if you increase the number of shots you your your stupid will increase and that is one really a big benefit in silica which is not the case with many blockages that currently exist which means that the more nodes you join your network the better throughput you will get out okay this is this is and that's roughly new I would say in the number of shots now if you look at the other other metric which

is how many nodes you should have it a shot that's on the very crucial point for many reasons one specific reason is security right so imagine a shot where you just put one single node well then it becomes a centralized infrastructure right then this shard gets to decide which transaction to accept which transactions will check so you want to have more number of nodes in the net in each shot cannot be just one now the question is what is the ideal number okay I mean there are some theorems are tell you that mean the more net at the more nodes you add in the in the in the in any shot the more secure you become against visited adversary's so I'm a gives you probability so more more nodes

you have the probability will decrease exponentially so we came up so if you look at that formula you can you will have this exponential kind of curve and it will tell you that you know roughly 600 nodes gives you of one over million yeah probability so you'd have roughly around 600 to 800 noise in each shot to guarantee security but if you need more if you need better parallel parallelization you need more shots more of such numbers so sort of the basic problem is is is it is almost a problem of sampling and like statistics so I I don't remember the name of this exact problem but the problem is something like you

have I don't know you have 10,000 instances of like I don't know you have let's let's say let's say we we talk about people right all of us have different heights and let's say there's this there's like group of 10,000 people now out of this group of 10,000 people I'm going to select let's say like sub groups of hundred people I'm gonna sample groups of hundred people then if the if the average height of this this group of 10,000 people is I don't know 1.8 meters and if I'm sampling like I'm taking out only 100 people and measuring the average heights of these hundred

people then there is actually a chance that I might come across groups which whose average height 92 meters right even though the even though the population of those population area of this 10,000 1.8 meters randomness might ensure that I might select a group of these hundred people and the average height might be 2 meters that can happen right so my sample might not be representative of the larger group if if the sample is too small and as the sample size becomes bigger when I go for 100 to 200 or 300 to 400 I will become more and more representative of the bigger group so in some sense as I feel

the formula you are referring to the exponential curve you are referring to is a reflection of this fact that we are assuming at some level that once the nodes solve proof-of-work that there is a certain fraction of Byzantine nodes inside them but we have like let's say let's say we have two thousand nodes and some fraction of it is Byzantine 20 percent of which is Byzantine but when you want to compose a shard we want to sample this group of two thousand nodes create a subset of it so if we create a subset with only 100 nodes there's this there's a higher chance that if say 200 nodes are visiting

those 2,000 if you're sampling groups of just hundred nodes there's a high chance that we might encounter a group in which like 9090 nodes are Byzantine like you might get a showered with 90 Byzantine nodes and ten honest nodes but if we increase the size of the sample from they say 100 to 500 then there's we're somehow like because we are sampling a larger set now we are taking a larger set out of this 2,000 if the bigger set of 2,000 is majority honest it increases the chance that my set of 500 is also going to be majority honest so it's something like that right it's very very you think about in an extreme case if we have one of the nose and then you know

we only have one shot let's say let's say we just make an assumption that this audition without those only have you know less than one third presenting and then it's actually hundred percent true that this shot has you know less than once out one set of the nose a presenting but that's the extreme case we don't we don't need a hungry person we need 99.99999% or something like that so that's what we do okay so so there are few ristic you're derived from something like this is a shorter like between 600 and 800 members yes and and then as as nodes are added we can we can increase the number of shards in some

way okay so as I'm aware like silica already has a private test net running right so just tell us like what are sort of the performance characteristics of of this this private tested so you know at this stage it's especially running or AWS ec2 cloud so we basically a host a particular category of instances no virtual machines every one virtual machine is running as a node inside our test net and then I think two weeks ago three weeks ago where we secured up to about 3600 knows in our test there we could reach you we could achieve you know a peak capacity

of close to 2500 in that a second so you know the interesting thing is when we compare the results with the 3600 nose to let's say what other than a 200 nose we really see a linear curve you know in terms of throughput growth so that basically sort of validated our original hypothesis that was report or D Negro that's interesting and to me 3,600 nose is still a very small Network compared to today's popular public blockchains and we really want to take this as a start and we want to further clue that our projection is where we have to that's a

twenty thousand those we should be able to reach about 8,000 to 10,000 connection a second and this is not to say that it's as 3/4 as you know tomorrow we just get more money and expand out you know test and it's not going to be that straight for I think we expect more sort of technical innovation we have to do along the way to achieve that ok cool so I think so one of the final questions I have and there's a lot to talk about the sharding model certainly it's like complex technology but we have to go coward the other interesting part of silica which is the smart contract language design you have limited time but before we get there how what is the

incentive structure or for all of these nodes including being a DES committee node and being a node processing transactions okay so so we should we should look at a little bit about why incentives structure should be different in the first place compared to let's say Bitcoin or foreign seed and the reason is the consensus protocol so if you look at the Bitcoin or or he seems Nakamoto passes for call there's one leader and he proposes a block so he kind of does the hard work right so he gets it's the reward now it in a PDF be kind of selling nodes which are they in the shot they all together work is signed transactions into or together good and then they propose a block so

the point is you know you have to be you have to different right it cannot be just just that way the classical way so what we is what we came up is is that if you want to give a reward let's give reward to the leader in the DA's committee and the leader in each shot okay so for every micro block proposed by each shot you will take the reward and then you divide into these people so all the leaders across charts and and the leader in the deskaway now what you might go with this model is that what you might do with this model is that after a particular period of time you could change the leader in each shard right so this will how pvap works

so there's a linear then you can replace that in some other and then you know you can eventually be able to be eventually be able to devote every single member in the shot because every single member will eventually become a leader so that's the that's the incentive and setting model okay okay so yeah so only the only leaders of these blocks are able to get reward so if I'm a new node joining in if I solve the proof-of-work become member is committee for the first few blocks after I remember I might not be the leader and I'll not make money at the at that time but then eventually it's like around it's like a round table this lie will circulate back and I will

become the leader and when I create a block I'm going to make money as a member of the DA's committee and similarly if I have a new lower joining and I end up being assigned to shard seven may not make any money because other people are proposing blocks but then my time to propose a block is going to come and I will be the leader and at that point I'll make money so this model has one advantage is is that you will have new videos right so in Nakamoto kind of concepts of protocol you're kind of competing with everybody right so you know after all after a few you know few time interval you will you'll probably have a chance to get the become the leader and then you will get it when you get the reward yeah it's different

because the moment you get it oh sure and if you stay there you will have you will have reports and it's guaranteed very interesting ways so in terms of like this whole sharding scheme or what are the largest points of uncertainty for your teams I think that like design choices or places where you don't understand the choices you've made and things might go wrong hmm that's a very good question I think I think at the high level I would think this this shotting scheme is relatively sort of validated I would say you know the most challenging part is

when we scale further I think you know now it's 3,600 nose I don't I don't think you know double that size would be an issue but if we really go to something like 15,000 or 20,000 so we may run into some bottlenecks which are not obvious at this moment so that's something we have to really do with the experiment because many things can become photonic like validation of generations can become pronate sending the micro blocks or sending the final blocks you know all these things may become a performance issue so that's where we we need to experiment and then study further to try to figure out a better way to do things so that's that's my expectation it's

very similar to the way that you discuss which is you you start with a smallest shot that you can have that's it's 600 notes because going below that you will have security risks so you start with this chart and the more nodes come in you keep on increasing the number of shots back some point of time you have to come back and say you know now I probably have to increase the shard sons and I should not increase let's say a short number for instance so it's not very clear right now when and at what extent we should we should make those choices so it's like the trade-off between like sort of having larger shards and higher security so the trade-off being like security throughput

expressed as selecting the number of shards and nodes in a shard right like you're going to optimize both security and throughput and the levers that you can pull out little charts that are going to be there in your network and the nodes that are going to be there Polish art so how do you tweak these two parameters to get an optimal of security and throughput is and the other point is how many nodes can be really support that's not the question we cannot support let's say 1 million nodes it's it's it's not it would work for any network it won't work if you let's say if you look at Bitcoin or helium it's if they have 1 million nodes one day for some reasons then you will have to propagate each block to the entire network and that will take time

and if you don't give if you interrupt I'm is not you know sufficiently large then you will have folks right because you know some some people won't be seeing the right block and then you would they'll be mining on a different block and then you know you will have folks so what what would be the maximum network side that we should support is not very clear forward so Silica's other big innovation could be in the in the paradigm of how smart contracts are executed inside silica and how they are programmed so give us an overview of your work and aims in in that space ok so we would like to have a smart

contract language first of all it is a design principle and that's that's why we started with something new and that is that we want to have a language that is easy to use it about considering the fact that we have all kind of issues with difficult spot contracts so we need we need a language that allows you to reason formally which you could say you know if you run this contract you are only going to see this this or this kind of behavior not something else ok that's that's the high level idea and how would you do that is tricky and the reason is that if you want to do if you want to give very strong properties if your proof then strong properties about your program it cannot be a very yeah it cannot be a very full-fledged language because then it becomes very complicated

to be simple so you can you want to have a language that is kind of you know it's not you incomplete for instance it could be it could be restrictive set but it's you know but but which which would allow you to have formal proofs but should be enough that should allow you to you know design interesting contracts this is this is the high-level principle that you wanna follow and like so you're working like smart contract languages is it like early or do you have some some kind of specification and implementation of a language so we don't have a specification right now we are currently writing it by the end of this month we will have a formal document which would say what exactly a program in our smart

contracts would look like and what kind of properties you could prove on all those kind of contracts so one interesting thing is you know we also want to balance between you know the security of the SMAW contracts and so no sort of program mobility so if we ask our programmers today to write that kind of automata style language it's very tough you know the learning curve will be very stiff so that's why we will try to develop a solid DT like syntax as well for for programmers so they can you can still write small contracts in the familiar language like today and we will have a compiler and sort of compile that

that kind of syntax into this this actual language for asthma contract and of course we will not be able to support how to pass a law so that it is syntax and we may add a little bit but rights largely like that so I almost feel like we need a villainess separate episode on the smart contract language when when you're further along yeah we agree yeah yeah this is topic you know by self yeah why cuz like yeah I think yeah towards the towards the end of the recording so I think we let's see she do another one for specifically for the smart content execution environment and languages but before we end off for today so

Seneca the network has this own cryptocurrency which is which is ceilings I like to know your plans about ceilings and when do you think so people will get ceilings in their own hands yeah issues ihling as a utility token so that means you know holders of zillions we'll be able to send transactions wrong small contracts on our platform and we are planning to run a public contribution a token generation event so the exact date has not been fixed at this moment so it could be as early as the end of November it could be as late as you know let's say Oh DJ so you know that's the rough

timeline where we're still thinking about this moment at this stage we're running an early contribution Rock so some people really show very strong interest to our project and then you know we try to work with them to get their support in terms of funding in terms of mining and in terms of application development you know various things so that's that's where we are in terms of our meeting okay do you have any any details on like what what kind of emission curve silica will end up having how many tokens will be issued in the public contribution and then how will the network go from there so I think I can give a rough idea on the you

know token allocation and then I'm really elaborate further on the emission specifically for the mining reverse so you know as we already mentioned silica technology has a feature we have more miners in the network will be able to process more transactions every second so that's why in designing our token structure we give - slightly heavy pie so basically we plan to give and it's 40% of our total focus apply to mining reverse over let's say ten years of time and then you know we will give our supporters either in this little contribution phase always in the public contributor phase about 30% of our tokens supply and then the rest of the

present token supply goes to this company untrim which sort of people is technology for the past two years and a cynical research is a little research will be the entity going forward to you know sort of spearhead this idea of silica and try to engage the communicator to you know promote silica to application developers to build a super apps on top of that you basically that's the entity going forward indeed silica and then to some of the tokens will also go to founders advisers you know agencies who are helping with us know that's the rough idea and I think I'm working a lot yeah yeah so I just want to add a couple of sentences so the emission curve so of

course I mean she just said we need more miners at the beginning because our network is this is powerful and it will give you how to put only when you have enough - in your network and to attract those miners we'll have our mission curve will be kind of maybe a large portion of that will be in the first few years let's say first four years so that people can come in and mine it and then it will kind of exponentially decrease over the next next next years because the idea is you know over time there will be a high volume of transactions so the transaction sort of gas fever or pickup as the majority of incentive for - super interesting so so yeah so something like 30% for the company and

zelicah research 40% with 40% of the token supply over ten years for the miners with it being front loaded in in the in the short term like we can earn more in the first few years then you can in after up like five years later and 30% - people spread across like - contribution P here it's like an early contributor which taking more risk yeah a later contributor which who is probably taking less investment and much of the uncertainty has dissipated okay that that that sort of answers the question then it makes sense cool so with that I'd like to thank you both of

you in show and a number it for being on the on the show it was great to have this conversation with you thank you very much to us it was really great yeah lots of interesting discussions thank you and I'd also like to thank our listeners for tuning in to the show episode of Bitcoin is part of the LDP network you can find all of their shows at let's talk bit on that at epicenter we release episodes every every Tuesday you can subscribe to our show on iTunes SoundCloud or your favorite podcast app for iOS and Android you can also watch the video version of this show on our youtube channel at youtube.com slash F is in a Bitcoin if you're loyal listener and I've been

enjoying the show we'd like to ask you for a favor I'd usually iqs reviews are really important for podcasts and help new people find the show we'd like to have more ideas reviews and and would appreciate if you could leave a review on iTunes and of course you can send us a tip with the address in the show description if you find we produce valuable content so until next time it was it was great having you tincho and [Music] [Music]