Hi, welcome to epicenter the show which talks about the Technologies, projects and startups. Driving the crypto economy. I am here, 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 should dong and embrace Kumar from silica since you as the CEO of silica and Amrit is equipped to lead. Their silica is an innovative
blockchain. Platform, which has a sharded blockchain already running as a private testing. Since when welcome to the show. Thank you. It's our pleasure to be here. Thank you. Ma'am. 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 Block Chain. Space. Sure. So maybe I can start. My name is Jin xiu.
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 smart grid, Transportation, internet of things, things like that. Of course, I started to develop a personal interest later on blockchain itself 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, you talk to me again, hey, I started a company. You know, we're working on blockchain, why don't you come and join us. So that's, that's the time I really started to think seriously that I shouldn't know really work full-time on a
blockchain. And, and I do so, after a few months, I join his company and started to develop this scalable, blockchain technology into, you know, commercialization into deployment answer, permission blockchain, you know, that was about you, no more than one year ago and that's how I started working working on blockchain of course. 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.
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 interpreting 6 a.m. and then I started discovering blockchain and 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 developing something? Like Silk? I said, why not?
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.
Right now that that that that posited that there was some kind of verification dilemna in in a blockchain like you cerium, And that translated through multiple different technological Jones became like the true bit. Another project to come out of this group is like loy's work, starting with x must secure smart contract languages and then ultimately decentralised exchanges and Kaiba Network. So that is also.
Now I also did his PhD as far as I know, from, from this group and another project that I know of personally is just this one silica. So there's, there's been at least like 33. The interesting projects that have come out of this group, that's unusually productive for an act as very unusually productive for an academic group. In any University, I would say, Yeah. Yeah. You know, we're we're very fortunate to be part of the
group as well. So the whole idea was silica, you know, it's expired by this original academic research paper caused by law and predict is called elastic. Oh, you know, that's that's where all these high level ideas of shouting started. Okay, so, let's let's drive down into zelicah. So silica is a is a sharded public blockchain with its own cryptocurrency called xilinx, but before we drive down into what, ex 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. The thing that is sort Or 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 inning, 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 sharing is quite straightforward. Let's just assume we have a blockchain network of 1,000 nodes.
So what shouting does is to These 1000 nose into let's say 10 shots, you know, with 100 euros each. So the El what it does is to process different transactions in different shots, disjoint set of transactions. So there you can achieve some level of parallel processing this in itself, improves the throughput of the blockchain. Bye-bye, you know, a large, a large Factor.
So this is easy, the high level idea of shining, 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 have bringing that sort of knowledge and those techniques from into the Block Chain space which has its own unique challenges while you while you showered 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 different variants of shouting. So, number one, I think when most people talk about shouting, we actually refer to something
we would call stationary. So that's maybe the closest, you know, the derived idea from the database sharding concept. So what stay shutting does is essentially it would divide the nodes in the network into different parts. So when one note belongs to one, Part or one shark. That knows Only Stores data and information for that particular chart. In other words, it, you know, it doesn't know what's going on in another shark know what's going
on outside the shot himself. So these 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 transactions 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 of example.
So these are all these advantages of stationing, 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 Nava is security. So, If one hour stays within one shot and then it doesn't actually understand, you know, nose outside that shot, doesn't 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 an issue.
So this is number one and number two is about redundancy or resilience because instead of let's say whole net worth of 20,000 knows storing, 20,000 copies. Uh, particular piece of information. Now, you only have let's say 500 or 1000 notes, keeping that piece of information and was one third or half of those nodes have a problem with that information either. They are compromised, or attacked or deleted or somehow
just lost. Such information is a problem because nobody else in this network, you know, understands 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. I've stood Surety for say it is actually came from Bitcoin model where you have the suit exe model and you want to if you want to know whether an output has been spent or is still on the spot, you want to have the store and you have to store the diet history, and that history can be very huge. So you need a way to kind of divide that history into chunks. So that each node only has to sort of part that that that they died history.
So the the story comes from comes from these. This utx or Bitcoin current model. Yeah, this is stay shouting. 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 Curry does is something we can call never shouting or transaction shot. That means for each node, it's
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 stay shouting, but on the other hand, we shot the processing of the transactions, so that means we have different shots. We will send different connections to different shots for processing. And eventually, you know, all such information for the next block will be aggregated. And Still seeing through to all the nodes so we can see easily
here. We, you know, the pros are very simple. We basically avoid many of these security and resilience challenges in slingshotting, but on the other hand, there are additional challenges in doing only Network shouting compared to stay shouting because every no room is still need to store lots of information. And still, we need to propagate lots of information to other nodes. So, you know, these are some of the places, silica. 'He is you know, doing the information. Okay?
So so when we're ready, when you are speaking is in show like sort of imagination came into my mind which is that we can imagine. You can imagine like any blockchain first like a blockchain like Bitcoin. Let's imagine that 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 reasons I full
nodes of of the system. So whenever like you want to process a transaction, 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 are going to add, they're going to verify that your transaction is right, and they're going to add it to the book and the, the 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 our same set of new transactions to add on this to this book. They're verifying the same time, set of transactions and So that's like that's like Bitcoin that's like it's helium today.
So each employee is redundantly doing that work and all of them are internally 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 this is the same 1,000 employees. Now when the silica blockchain, But the same 1000 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's like 1,000 employees, then we can have say, groups of 100 employees in some way that are working on different transaction. So let's say employee one, until employee 100 Works around one particular set of transaction at the same time employee 100 to 200 works are different set of transactions at the same time and so on. So There are like 10 subgroups
in this government office. Each of them processing their own set of transactions, but each employee ultimately needs to keep track of transactions. That note not only their group has processed but also transactions processed by the other groups as well, right? So that's sort of the silica model energy 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 employees, maintain The Ledger, or utx, a set of book, only for the transactions process, thereby their group. That's right. If I'm in group number seven, my book contains only the transactions processed by a group number 7. And if someone, if my friend is in group number 5, if they won't, they only contain transactions processed by group
number five. But even though my book and my friends, both do not have intersection in the transactions. We have processed somehow, there is a way of making sure that there is no double spending. Like, I am not processing the transaction and he's processing another transaction and they are couldn't conflict with each other. So that kind of thing, which is the ultimate in sharding, would be State sharding. Yes, yes. And silica is not.
Age Harding. 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 computation cost in verifying transactions is limited to those process. My, by my group only Exactly, exactly. So I think this is a very good analogy. I just want to clarify a little bit on the Zilla Komodo here.
So I I think stay charting is a very interesting but you know, there are many challenges where he discussed security redundancy and this, you know, cross Charter Communication. Basically, these are main challenges, we should, you know, work very hard on to resolve, but at this stage, I still cannot know for sure. Whether State shouting is the ultimate You know, objective for shouting, for example, because if you look at Zilla Komodo, you know, all these accountants
process. Different employees transactions, and then eventually every continent still be updated on every other accountants processing process, the transactions, right? So, but this is, this is a current implementation of zedek, I would call. But the Desire with silica is not limited to this. So for instance, to a jurisdiction, Issue of, you know, excessive storage requirement. So basically each accountant needs to know every single
transaction, right? We can reduce that because when we say we don't do stage shouting, 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? So there's a difference, if you look Cat-like, you theorems 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 get, you know, reduce the storage for every accountant by applying another mechanism. Something like DHT for example, you know, Hash table to allocate you know which no to a storage which historic data that's only about the historical, you know,
transactions. But this is sort of orthogonal to the fact that every accountant still knows the account. Balances 40 employees. That's just one thing I want to add. So we are that that's that's that's like super important. So basically, like what what you saying is like, even though if I'm in like Group 1 and I need to know some like something about group 7, there's ways in which I can reduce the total set
of knowledge. I need about what went on in Group, 7, group a. 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 minds is if you look at the blockchain space today, there is this 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 the first at least first. We've been W. What is the difference between interoperability and sharding? Yeah, this is a very good question, you know, to me, you know, I can't, I can't really draw an absolute line between interoperability and and and sharing.
Especially if you look at things like plasma, for example, like you have a mansion and you have side chains. So so in my view usually where we say shouting still about shutting within one production so it's it's one single unified blockchain. But yeah, I mean whether The over time, we can when the incorporate tea party is very mature, whether the boundary is still very clear, not I'm
actually not very soon. Yeah, I mean, I completely agree that, you know, you have different problems in the Block Chain space and different blockchain Technologies. They come up and they solve different problems right. Now, this voltage is how do unify them. You can't have 1 million blockchains and standing all alone. You want to wait so that one
block in can talk to her. Look T at this is where this interoperability Comstock and we definitely need need a technology like this so that 11 blockchain technology can talk to another Block Chain technology and 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 are designing a protocol that allows you to interoperate all you know talk communicate with other blockchains that kind of orthogonal problems. So what do you mean when you say there are orthogonal problems which means that these sort of two different problems blockages, which address KB your, let's say throughput they want to address or they try to address. I mean, how can you increase was the technology that you should imply?
What's the protocol edition of Y? So that you can increase the throughput of that Block Chain? So this could be a block team that tries to sound skill ability. You could imagine protein such as Z cash which which are mainly focused towards privacy, they want to ensure that whenever you do a transaction, it's private which could be lets say hiding your amount hiding who is the sender, who is the recipient? And you know what? These kind of features do they would go these blocks as we saw
different problems, right? One is solving scalability. The other one is kind of attempting to solve the Privacy part. 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 these are the blockchain will be solving another problem which is very, and all three are very crucial for You know for the Block in the ecosystem to work in a really nice sweet but they all solve different problems.
It's like we imagined this government offices government building with 1,000 employees working in it and scalability is okay. We have 1,000 employees. How do we get them to do? The most work securely, right? Yeah. And interoperability is sort of the problem that, okay, 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 the 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. Good Postal System, where a scalability is getting the employees in one building or in one office to be able to do more work than what they can today. Yep. That's all understanding, of course, you know, the difference between interoperability and shouting is really the difference between, you know, whether this is the one government body or five government bodies Okay, okay, makes 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 you give us a broad overview of how the network is designed? Yeah, silica is, you know, it's slightly complicated, 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 arbitrary many identities because you know if you can create arbitrary, many identities in the in the consensus process, if you over simplified as a voting, you out, vote for the good guys but that's why we need to establish. Shhhh shhhh some way to sort of that people only create proper identities, you know, that that's something we need to do to solve. So, that's where we have proof of work. So, people have to do approve work before they can enter into
our consensus protocol. And okay, now, the question comes, how do we do this? How do we, you know, sort of enforce a proof-of-work, who are who are check? You know, who is running prove? Were correctly or not, correct? So that's why we established something called directory service committee. You know this is just 11 a.m. we give basically this is the overarching layer so we will have knows competing a proof of work to get into this particular
overarching committee. So once this committee is formed this committee becomes the body that will check other nodes. So we are other notes doing proof of what you do check whether this is the correct or not. Correct. And then, 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, good knows those who have passed, you w in two different shots and then this overarching committee. Also decides, how do we send different transactions to differentials for processing? And eventually aggregate all the process transactions into the final block. So if we go back to the, you know, Garmin and accountants model, so this is like like the
top governing body though. The the selection criteria is also higher. And then, once this government 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 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 a super nose, we just trust them. Let them decide that that in our view is is not ideal because you know people can keep their power attacking this knows if they are static and in this knows maybe corrupt in You have away. So these targets service committee has to be
decentralized. So the election of this committee self is also by proof of 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 Stone. Like, static forever. So, this is a high-level idea of silica's network design. So would you like to add something on it and has she just said you know you want to have, you want your networks in an inviting your network right? You want to divide that Network
into some parts? But you need some some, you know, somebody or a group that is going to control that in a way that is going to say, you know, you go to this shot, you go to this short, you graduation, right? So you need a body that's going to 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 wanted to have because this this this body will have the right to say you know this this this note is going to be signed with a shot so you don't want to have an app. You don't want to give one person absolute right to do
whatever he wants. And that's why you need to have a sufficient number of nodes in that in that body me that committee and then you want to elect them in a fair manner as well. So, these are the crucial points that you have to do when you want to do shy. So apart from the directory service comedy.
Like so we have these groups that are that are processing transactions and this directory service is sort of the administration that allows sort of these these groups to even coordinate and these groups to inform process transactions 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, how are these groups then you have groups that like process transactions.
So if I am a load, if I were new node that is like joining this network basically, like a new accountant on 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 try to become members of like one group, and the directory service committee, right? Yeah, the square and sting. Okay? Okay. 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, it's 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 chart. 70 group 7, how can I do that? And then if I want to join the directory service, Heidi.
How can I do that as a new node? So, in general of a node cannot choose which Shadow, which grew it wants to join because that's sort of decided based on some Randomness in the inner you know, proof of work without it. Generates, it's designed that way. Otherwise, if we can choose which shot I want to join. I can you know group with all these bad guys. Let's all go to shot Seven and compromise that shot, you know, that's a highly right here.
So what? These at certain intervals, let's say act at every two hours roughly to us, it's based on block type, of course, let's say roughly out every two hours, the existing directory service committee will announce an open competition, it will announce a now, there is a new proof-of-work scheme, everyone can participate and then any no no existing in this narrow or outside, that's fine.
Any node can do is I can just join this competition and and try to solve that puzzle of this proof of work. So the winner will be sort of agreed on by existing members of this directory service committee and then it will join this committee. Why doing that the committee will also ask the oldest member in the committee to live. This this is the way how it's updated.
So the membership of the committee is like churn or the change, every two hours, and then the process for like entering the committee is to solve this proof of work. So yes, let's say that I can into ours, is this before 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 and, uh, please, yes, right. Imagine this is a change. This is, this is a blockchain as
well. So, Whenever there is a winner of that proof of work that name will be added into a new block and block is appended to the action and then you know, if you go back to along the chain you then you can move to remove the oldest block. So what happens in those two hours. So let's say, like I okay, I'm a
new node. I ended up I succeeded in joining the DS committee and now for the next two hours, there's not going to be another another puzzle or another The node joining us. So, the set of these committee nodes is now known for two hours. What do we do during this period? So two hours is just example. You know, you can do it. Every SRI, SRI minutes for example. So this is the interval where we are sort of elect a new member
of the DS committee. And then, you know, at that time where we after we, you know, elect a new member into the committee, the DS committee can call another round of proof of work to sort of incorporate a new nose. And this process, of course, can be done. More frequently. We can be down, like they say, everybody kind of minutes as well. So these are parameters, who can tune.
But basically the DS committee can announce another proof-of-work scheme, to ask a new nose to join the or not drawing the DS committee, but they are doing yingu that groups for doing consensus and process transactions. So, this is another proposed scheme, we leverage on silica. And this this also, you know, understand Molly, this is also much easier because it's not that competitive in the DS, committee. Election is very competitive. Everyone is competing for that one position.
And this time you start, for example, 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 their according to the result of your pewww, you will be shot adding two respective committees and this Logic for shouting is decided by the DH committee. Amrit anything to add. Yeah, so that the two points here, right?
So the basic idea is that you want to elect members in the shop and you want to elect members of the committee, okay? At two points. Now the two ways of doing it, what is that you liked all of them together and how could you do that? You say that everybody is going to solve qw and everybody's going to submit their peer review and you could say look I have received all these two doubles. I'm going to sort them out.
I don't think the smallest one, let's say, because his Randomness incurably, so, you know, you cannot be that kind of expected. You can say that. Look, I'm going to sort all of that and I will take the smallest one and that will be equal to the radius 1 and the rest will go to the shower 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 were going to dump
the cup of these. There's these two lashes would say first select the DS people but we as member and then ask them to elect the short members, okay? So that's why we have 1qw to elect the DS Committee Member and S PW electric shock belts. And that is that if you decouple it, there you have some freedom in say that, you know, second one can be done more faster than, you know, more frequently than the first work and so on so forth.
So that gives you Freedom about this Ari, how frequently you want to do you, how frequently you want to elect the members in the shot and how frequently you want to elect a member of the committee. And that's why we decouple the
proof of work. Okay. Okay. So so basically, like, if I'm a new node, I can first become a member of the shot, by solving this, PO W. And then like this, this DS committee can last for four listener, a longer duration, and in these in this longer duration, like, they are like shorter durations wear this with a sort of elections of of puzzles that are going to determine who processes know, 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 7 and then I go and process transactions inside. Yeah. Short 7. And after that, the next run maybe your reshuffle to shark fight this. So okay, so in this secondary lecture is like, I'm in charge seven, first and sharp 5 and shot three, and again, back to short, seven sharp 9. So, I'm being I'm being shuffled around.
Not only Me. But, like, all of the nodes, we have been, we have been shuffled around really well. And then if I win the DS committee after let's say a certain point of time, I will become the oldest member of the DS committee and then I will have to exit that committee if I want to rejoin it. I have to have to win the lottery for that dies committee again. Yes, yes. So for example, winning the lottery for the DS committee once might entitle me to be
there for quite a long while. While the oldest nodes getting keep getting churned out, right? I might be might be there. Okay, okay, so that makes it. So let's say like a now, I was assigned to short number 7, So and then there are like a hundred other nodes that are assigned to short 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? Okay? So what happens is that, let's say a user creates a certain
transaction. I 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 scent as a dress, right? So what I might have a solution to imagine that you have only two shots for the time being, okay? Just to simplify the scenario. So we have to only two shots and how this transaction we go through, is that the sender address will be will be checked. Let's say this last bit is 0 would be 0 or 1 and if it is 0,
it will go to the first shot. If it is 1, it goes to the second shot. Now, if you have more shots, of course, you can do a modulo arithmetic and then you could end up in a specific shot. So a user since the transaction, it goes to a specific shot depending on the Center's Address. And then they will be a consensus V code within that short for that for that
transaction. Aha. So so basically like this is a way of automatically preventing double Spain's, 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 to shards because my address is sort of known and that address is going to address triggers a deterministic computation which sort of Gives the output as like which shot this transaction belongs to exactly.
So if you're starting with respect to, I mean if you 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 reasons, you won't be able to preventable spec, so shorting with respect to send us address. This automatically gives you a
double spend kind of prevention. So this is like like like a transaction partitioning scheme in in some way, right? Like so it's 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 are the other heuristics you considered or this one was the clear winner. Well, I don't, I don't remember if he tried anything else. Yeah, I think it was. So obviously it will give you a very nice solution.
Why would you bother about thinking anything else? It was suddenly clear. Okay so what is the consensus algorithm inside one shot? And like what are sort of the performance characteristics of of an individual Shard. It's largely we stone-cold practical presenting for tolerance, so pbft. But, you know, we understand pbft performance of very efficiently or a small size Network and they were like $100 to Hungry nose.
You can generate very high throughput, but on the other hand, when you have a larger Network and there were thousands of nodes or tens of thousands of nodes, then the performance of pbft would deteriorate. This is in contrast with Nakamoto protocols, where you know, throughput is very stable but there's a larger was more Network so but we pbft has
several advantages. So the main advantage of we like up you know about pbft it gives a finality so now Is, once you agree on the block or a few transactions, you want to accept that? Stop, there's no way you can rewrite the history. So what we do is we leverage from some of the existing literature to use Collective signing or schnapps signature to address, what particular performance issue in in pbft. Basically, in pbft is all about those talking to each other saying, I have sick days.
You have seen this, okay? I have seen that people telling me, they have seen this. So when they say such messages, they have to use this digital signature to say. This is really from me and otherwise malicious nose again. Can just, you know, craft messages, which seemed to be from all the other nodes, you know, that's why you need digital signature. But then when you have a very large Network, like the 1000 knows the size of the digital signature will become a performance bottleneck.
When you send this message across, That's why we Leverage is, no signature to reduce the size of a signature from, you know, we called over been. 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 obtained from there and you know average over tell us more about what are the issues with directly leveraging?
The snow on snow 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 try to develop in this efficient
consensus algorithm is actor. We play around different network topologies so you can have a random topology, get a tree topology which is in original proposal of leveraging, strong signature and and you know, star topology and eventually we choose the star topology as we think this is the most Patient a way to send messages across. So there are, you know, different aspects we had to enhance or ppfd, and I'm re can talk more about this, no signature partial.
Just before that out, I would like to highlight point on finality, right? So if you compare, that's a consensus protocol, Allah Nakamoto and pbft or PFD classical be of - causes for God, give thee or pbft. They give you finality which Is that if a block set of transaction goes into the blockchain, that's fun. You would have you do do need confirmations on top of that, it has many advantages. Why is that?
Because it's your final dare, you don't have to care about confirmations because it's tough, right? The morning goes is blotchy. The second guarantee that it that you have is that you don't have to keep the previous history, right? If you look at the Nakamoto kind of consensus protocol, let's say node us to do glue and submits a block. You don't know whether it's going to the final Block until you receive a bunch of confirmations. So you have to store that block
for a while. While in case of pbft, kind of consensus protocol. The moment you do, you agree on a block, it had its final. You don't have to store blocks that, you know, that's where it received. Previously, you can just get your state update, your state and then you are done. So it also tells you it to some extent that stage shouting 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'm not a node and I'm sending a transaction to Xin Shu. So I create I create my transaction. It looks like a fairly standard transaction So I'm assuming I'm in my head it's like any second aetherium like transaction, there's a gas price and it's like it is a my account number amount gas prices like code
stuff like that, right? 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 sharps inside. That was the nodes of The Shard. Listen to my transaction there. They participate in a consensus algorithm so the which is like practical Byzantine fault tolerance pace.
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 showered 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 might Actually, it's going to form. Is that correct at The Hideaway,
something like that. But, but, you know, there are some, there are some pollution issues being accepting just whatever that comes out of the particular shot because, you know, we still need some verification from from the DS committee because way, 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 is, you know, sort of recoil microblog Know that that is the 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 DS Level. And then dies level. So every shot will propose a block because it microblog. So the first shot will give a microblog. The second shot will create its own micro block. And then it, they will all go to the DS gallery. And then this DS, comedy will aggregate these two micro box into what is called a final block. And then final block have gives
you the finality. So there is that another one one level up. And the DS committee. Once his light, it collects these two micro blocks and wants to put them in the block. All of the nodes of the DS 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 DS committee will become the bottleneck, it would defeat the purpose of shouting or it or the snow's too.
Is it will verify that enough signatures. Us have sort of validated the correctness of this transaction from that particular shot. So, basically if I'm a DS Committee Member at that point, I'm like, okay I receive that I received this microblog from short to. Okay, I'm going to check which nodes are assigned to short to in the past, okay? I assign these particular 50 nodes to that shot in the past. Then in the, in this block, do I have two thirds of the signatures of these 50 NOS?
Yes, dr. Turk verify is other Seeing as that's correct. Okay. These signatures there's more than two-thirds signature. These signatures are correct. Okay, so I'm going to accept this microblog. So, that's how I accepted the macro block of sharp to then charred. Then I then, similarly, I accept the microblog of short one.
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 short, one and two, like these two blocks into the blockchain. And now that then then I, then the just, I'm just one dies Committee Member and the other dies committee members are having like, like similar threads. So how do the dies committee members now?
Come to consensus on whether these two blocks are finally, they actually wrong 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. Ha ha.
Okay, okay. So basically now now like a user from the user perspective, I send a transaction to Xin Shu and I have to wait that my transaction gets confirmed in let's say, short to and then in and then the block of short to gets confirmed in the in, with the DS 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 short and in the DS committee, Dang, I see these two blocks now, my transaction is confirmed and then Z which you can basically give me the car or whatever I'm looking to buy. So this is a four very strong, you know. Security on the other hand for applications you can you can use some heuristics for example, wave, see your transaction is accepted by Wang shark.
You may you may believe that 99% of the chances that these this transition will eventually The final connect a final final blogger. You can, you give me consumptions like that and for some application that's a payment, it's fine. Because you just need to have some reserved to, you know, Rectify, some of the 1% exceptional cases that case so that can give you sort of a very much shorter latency. Cool. Yeah, so at least I have a rough idea of of silica. Now, better idea of 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 shots each with 100 nodes or something. 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 transactions parallel as the high-level idea, right? Now, you need to have more shots, you want to move to, you know, if you were to achieve
better paralyzation, right? So let's say, if you have only 2 shots, you can do 2 times the processing Affair for shots. You can do four times process. If you have tension equal to 10 times processing, So, ideally, the two parameters here. What is how many numbers of shot? The vote. And what is the size of each shot, right, into parameters Ascension? Well, roughly speaking, the more in, if you increase the number of shots, you, your throughput 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 notes you join your network, the better throughput, you will get out. Okay, this is this is and that's roughly linear outside. In the number of shots. Now, if you look at the other other metric, which is how many nodes you should have in the shot, that's not the very crucial point. For many reasons, one specific reason is security, right?
So imagine the sharp will you just put one single node? Well, then it becomes a centralized infrastructure, right? Then this shot gets to decide based on section 2, except which transaction subject. So, you want to have more number of nodes in the neck in each short cannot be cannot be just one. Now, the question is, what is the ideal number?
Okay, I mean that sometimes I tell you that I mean the more the more notes you add in the in the in the in in short the more secure you become against Byzantine adversaries. So I mean gives you probability. So more notes, you have the property will be decrease exponentially. So we came up with so if you look at that formula you can give will have this exponential kind of curve. I will tell you that, you know, roughly 600 nodes gives you a one over million kind of. Yeah, kind of like the
probability. So you'd have roughly around 600 to 800 notes in each chart to guarantee security. But if you need more, if you need better parallel sterilization, 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 N like statistics. So as 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 this.
Let's say, let's say we talked about people, right? All of us have different heights and let's say there is this like group of ten thousand people now? Out of this group of 10,000. People are going to select, let's say like subgroups of 100 people. I'm going to sample groups of 100 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 hundred people and Min when measuring the average heights of these hundred people. Then there is actually a chance that I might come across groups which whose average height might be two meters, right? Even though the even though the population of those population, average of Vista, 10,000 1.8 meters Randomness mind.
And sure that I might select a group of these hundred people and the average height maybe two meters, that can happen, right? So my sample might not be representative of the larger group If the sample is too small and as the sample size becomes bigger, when I go from 100 to 200, 300 to 400, I will become more and more representative of the bigger group. So, in some senses, I feel the formula you're referring to the
exponential curve. You're 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 in I'd them but we have like, let's say, let's say we have two thousand nodes and some fraction of it is Byzantine, 20% of which is Byzantine, but when you want to compose a shower 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 is this there's a higher chance that if say two hundred nodes are Byzantine inside those two thousand. If you are sampling groups of just 100 nodes, Is a high chance that we might encounter a group in which like 9090 nodes are Byzantine, like you might create a shower with 90 Byzantine nodes and 10 honest nodes, but if we increase the size of the sample from, let's say 100 to 500, then this we are somehow like because
we are sampling a larger set. Now we're taking a larger set out of this 2000. If the bigger set of 2000 is majority honest, it increases the chance that my set of Also going to be majority on this, it's something like that, right? It resonates very, very aging about in the extreme case, if we have 1,000 nodes and then you know, we only have one shark.
Let's say let's say we just make an assumption that it is original $1000, only have, you know, less than one-third of presenting and that it's actually 100% true. That this shot has less than 1,000 one set of the nodes. Representing by that's extreme case. We don't, we don't need 100%. We need 99.99999% him, something like that. That's what we do. Okay. So there are a few distinct. You have derived from something like this is a shower door to lie between 600 and 800 members. Yes.
And and then as, as nodes are added, we can we can increase the number of shards in right some way. Okay, so as I'm aware like silica already has a private test net running, right? So first tell us like what are sort of the performance characteristics of this private test name. So you know, at this stage it's especially Ronnie or AWS ec2 Cloud.
So we basically host a particular category of instances the virtual machines everyone virtual machine is running as a note inside our test net and then I think, two weeks ago, three weeks ago when we scaled up to about 3,600 knows, you know, test then we could retrieve, we could achieve a peak capacity of Of those to 2500 connections. A second. So you know the interesting thing is when we compare the results with the 3600 nose, to, let's say 1200 nodes. We really see a linear curve in
terms of throughput growth. So that basically sort of validated our original hypothesis. That was reported were leading a group that's interesting. And to me 3600 nose is still a very small Network. Do today's popular public blockchains and we really want to take this as a stock. And we want to further grow that our projection is where we have to let's say 20,000 knows.
We should be able to reach about 8,000 to 10,000 transaction the second and this is not to say that it's as straight forward. As you know, tomorrow, we just get more money and expand our test and it's not going to be that straightforward. I think we expect more so Of technical Innovation. We have to do along the way to achieve that goal.
Okay 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 cover the other interesting part of silica which is the Smart contract. Language design, we have limited time. But before we get there, how, what is the incentive structure for for all of these nodes, including being a DS committee node and being a node processing time? Actions in this chart.
Okay, so so we should look at a little bit about why incentive structure should be different. The first place compared to let's say Bitcoin or or incident and the reason is the consensus protocol. So if you look at the Bitcoin or Ori theorems Nakamoto classes for call, there is one leader and he proposes a Blog so he kind of does the hard work, right? So he gets a reward. No, it in a pbft kind of study notes, which are there in the shot. They all together work is signed
transaction. They do or together work and then they proposed a block So the point is, you know, you have to be, you have to do different, right? It cannot be just just that way. The classical way. So what we see what we came up is, is that if you were to give a reward, let's give reward to the leader, in the DS comedy, and the leader in each chart. Okay. So for every microblog proposed by each chart, you will take the reward value divided into these people.
So all the leaders across charts and the and the leader in the DS coming. Now, what will 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 chart type.
So this will help you if you work, so these are leader and then you can replace that you have in some other you And then, you know, you can eventually be able, you would be eventually be able to devote every single member in the shot because every single member will eventually become a hero. So that's the, that's the incentive incentive model. Okay. Okay, so yeah. So let me the only leaders of these blocks are able to get
rewards. So, if I'm a new node joining in, if I solve the proof of work become member of the DS committee, For the first few blocks. After member, I might not be the leader and I'll not make money at the air at that time. But then eventually it's like around, it's like a round table is like, will circulate back. And I will become the leader. And when I create a blog, I'm going to make money as a member of the DS committee.
And similarly, if I have a new node joining and I end up being assigned to short 7 may not make any money because other people are proposing blocks. But then my time to propose, those a block is going to come and I will be deleted and at that point I'll make money. So it is this model has one advantage is is that you will have low variance, right? So in in Nakamoto, kind of consensus protocol, you are kind
of competing with everybody. So you know, after after a few, you know, few time interval you will probably have a chance to get the become the leader and then you will get it. We get the reward here, it's different because the moment you get into shot and if you stay there, you will have, you will have the votes. And it's guaranteed. Hmm. Very interesting ways. So in terms of like this whole sharding scheme, what are the largest points of uncertainty for your team?
Like things that like design choices or places where you don't understand the choices you have 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 is shotting scheme is relatively sort of validated. I would say you know the most challenging parties when we skill further I think you know
now it's 3,600 knows. I don't think you know, double that size will be an issue, but if we really go to something like 15, Thousand or Twenty Thousand. So we may run into some bottlenecks which are not obvious at this moment. So that's something. We have to redo the experiment because many things can become put on a like, validation of connections can become poorer, neck, sending the micro blocks or sending the final blocks know, all these things. May become a performance issue.
So that's where we need to experiment and then starting further, try to figure out a better way to do things, so that's my expectation. Emory. Yes, I'm it's very similar to the point that he discussed, which is you, you start with the smallest shot that you can have. Let's say with 600 notes because going below, that you will have security risks to start with start. And the more notes come in, you keep on increasing the number of
shots. At some point of time, you have to come back and say, you know, now, I probably have to increase the shot size and I should not increase. Let's say, Richard 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 between like security, throughput expressed, as selecting the number of shards and nodes in a shot, right? Like you're trying to optimize both security and throughput and the levers that you can pull the number of shirts that are going to be there in your network and the nodes that are going to be there / chart. So how do you tweak these two parameters to get an Optimal of security and throughput is the other point is, how many nodes can be really support?
That's not the question. We cannot support it, say, 1 million nodes, it's not, it would work for any network, it would work. If you let's say, if you look at Bitcoin series if they have 1 million notes, 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 interblock time is not in a 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 be mining on a different block and then, you know, you will have folks. So the, what would be the maximum Network side that we should support is not very clearly hold. So silicon has 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. So we would like to have a smart contract language. First of all, it is, will Design principle. And that's why we started with something new and that is that we want to have a language that is easy to reason about consuming the fact that we have all kind of issues with different kind of spark contracts. So we need, we need a language that allows you to reason formerly which you could say, you know, if you run this contract, you're only going to
see this. This of this kind of behavior, not something else. That's, that's the high level idea. And how would you do that? Is is tricky. The reason is that if you want to do, Do, if you want to give very strong properties. If you're approved, very strong properties about about your program, it cannot be a very, it cannot be a very full fledged language because then it becomes very complicated reasonable. So you kind of you want to have a language?
That's kind of You know, it's not two incomplete. For instance, it could be it could be restrictive set but it's, you know, but but which would allow you to have formal proofs but should be expressive enough that should allow you to, you know, design, interesting contracts. This is this is the high-level principle that we will follow and like so your working life smart contract language is it like early or do you have some some kind of specification and
implementation of a language. So we don't have a specific issue 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 contraction would look like and what kind of properties you could prove on those kind of contracts? So one interesting thing is, you know, we also want to balance between, you know, the security of the smart contracts and sort of sort of program ability.
So if we ask programmers today to write, that kind of Automotive style language, it's very tough. You know, the learning curve will be very stiff. So that's why we will try to develop solidarity like syntax as well, for for programmers, so they can still write smart.
Tracks being the familiar language like today and we will have a compiler and sort of compiled that kind of syntax into this, these actual language for smoking chart and of course, we will not be able to support 100% of solidity syntax. And we may add on a little bit but it's largely like that. So I almost feel like we need a, we need a separate episode on the smart contract language when when you're further along. Yeah, we agree. Yeah. Yeah. Yeah. This is topic. You know by yourself.
Yeah. Why is that cause like yeah I think we are we are towards the towards the end of the recording. So I think we let's reschedule other one for specifically, for the smart contract execution, environment and languages. But before we end up for today, so Silica in network has had its own cryptocurrency, which is, which is xilinx. I'd like to know your plans about ceilings. And when do you think people will get chillings in their own hands?
Yeah, we're you should ceilings as a utility token. So that means, you know, how does the Brazilians were be able to send traductions wrong, smart 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 end of November or it could be as late as, you know, let's say early
jet. So, you know, that's the rough a timeline where We're still thinking about this moment at this stage, we're running 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 fundraising, 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 of the total allocation and then a KU Library further on the emission specifically for the mining rewards.
So, you know, as we already mentioned silica stay Energy has a feature, we have more miners in the network, will be able to process more transactions, every second. So that's why designing. Our token structure? We give - slightly heavy pie. So basically, we plan to give at
least 40% of our total focus. Apply to mining rewards over let's say 10 years of time and then you know we will give our supporters either in this early contribution phase or in the public contribution phase about 30% of our Token Supply.
And then the rest 30% token Supply goes to this company are unsure which sort of developed this technology for the past two years and xenical research is a little research, will be the entity going forward to, you know, sort of spearhead this IND of silica and try to engage the community to, you know, promote silica to application developers to build High throughput apps. On top of that, you're basically, that's the entity
going forward, will be silica. And then into some of the tokens will also go to funders advisors agencies, who are helping? That's the rough idea. And I think I'm working but yeah yeah. So I just want we'll add a couple of sentences so the emission curve. So of course I mean as she just said we need more - in the beginning because our network is is powerful and it will give you higher throughput only when you have enough - in your network and to attract those - we'll have our mission.
Curve will be kind of A large portion of that would be in the first few years. That's a first for years so that people can come in and mine it and then it will kind of exponentially decrease over the next next next year's because the idea is, you know, over time there will be a high volume of transactions. So the transaction sort of gas fever will pick up as the majority of incentive for minors. Hmm, that's super interesting.
So yeah, something like 30% for the company and silica research 40% with 40% of the token Supply over 10 years for the miners with it being front-loaded in in in the in the short term like we can earn more in the first few years, then you can is after after like five years later and 30% to people spread across like To contribution periods like an early contributor, which taking
more risk. Yeah. The later contributor which who's probably taking less of a risk when, when much of the uncertainty has dissipated. Okay? That, that sort of answers the question and it makes sense. Cool. So with that, I'd like to thank you. Both of you since show and a number eight for being on the, on the show, it was great to have this conversation with you. Thank you very much was it was really great. Yeah. A lot of interesting
discussions. Thank you. And I'd also like to thank our listeners for tuning into the show. Epicenter, Bitcoin is part of the LTE network. You can find all of their shows at let's talk Bitcoin that calm. 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 the show on our YouTube channel at youtube.com slash F is in a Bitcoin. If you are a loyal listener and have been enjoying the show, we like to ask you for a favor. I'd usually iTunes reviews are really important for podcasts and help new people find the show.
We'd like, Like to have more iTunes reviews and it and would appreciate if you could leave a review on iTunes, and of course, you can set us a tip with the address in the show description, if you find, we produced valuable content. So until next time it was, it was great having you in show, and I'm ready.