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.
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.
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.