This is epicenter episode 258 with guests, Monica
acquaintances. This episode of epicenter is
brought to you by Dutch hex, the fair and secure decentralized
exchange platform, by kenosis to learn how you can build apps,
which leverage Dutch axes, liquidity fool, visit epicenter,
.t V, /, Dutch x, and by Microsoft Azure configure and
deploy a Consortium Network in just a few clicks with
pre-built. Aggregation and enterprise-grade
infrastructure. Spend less time on watching
scaffolding and more time. Building your application.
Learn more at aka.ms/offweb eccentric.
Hi, welcome to epicenter the show ex talked about the
Technologies projects and starts driving decentralization and the
global blockchain Revolution. My name is Sebastian Cujo and
I'm ahead. Roy, I'm here.
How's it going? It's going with been a while
since we've done this together. Yeah, I can't remember what I
think. I think blocks are at was our
last episode. Yeah, I think we've added a
couple of new hosts and I guess like the veterans are sort of
busy dying to do episodes with the new hosts so that they get
up to speed. And, you know, and we have a
more Diversified Group of hosts for the future.
Yeah, I'm really excited about it and so our listeners will
notice that the formats little different.
So we don't typically sort of have this little discussion
between us but we're works better.
We're experimenting with this new way of doing the show.
We just thought it would be nice to be able to, you know, spend a
few minutes before the actual interview to discuss about what
we're about to talk about what we're about to hear.
So this is actually being recorded after the interview so
it's a Good way to sort of frame the context for what you're
about to hear and also it gives us the opportunity to maybe talk
to you about stuff that we wouldn't normally have the
opportunity to talk to you about it like events, we might be
going to or things that might be happening in and around
epicenter and that sort of thing.
So, yeah, let us know what you think about this new new format.
I mean, doesn't change much for you, but yeah, hit us up on
Twitter and also would love to hear what you think about our
new, our new hosts. I mean son, he's been here for a
while. Most of you.
Are familiar with him, but for the Eco who just joined us
recently, we're super excited to have her on.
We're already this two episodes in with her and I think she's
been great. Yeah.
What do you think, man? So it's great to have new hosts
No, every new person, brings a different perspective and I get
to learn a lot as a host myself doing this episodes with frigid
Rica and Sonny because they questions are so different from
mine their Curiosities are so different from mine.
Yeah absolutely and it kind of takes takes the heat off of us
and allows allows us to do other types of things and also for the
listeners to be sort of kept on their feet as to Like, who's
gonna be the next host on? Like, the next episode?
What could I expect in some of the Dynamics that that creates?
Yeah, so yeah, I'm really excited and hopefully we can get
some more hosts on at some point.
So today, we're going to be speaking with Monica
acquaintances and Monica is lead engineering and adoption
strategy at kadena. And kadena is a company that
came out of JP Morgan. And it's building sort of it's
our unique actually because it's a company that's building a
public network and also private Network Technologies.
Typically if you take like a hyper Ledger or something like
that or like well maybe not Cosmos.
But yeah something like hyper Ledger sort of companies that
are traditionally the private blockchains space that deal with
Enterprise clients. You know, they have a stack that
they're looking to deploy and Consortium networks or with
Enterprise players. But they're not typically like
building a public network with minors and, you know, privacy or
sorry censorship resistance and such.
But they're actually doing both those things, they're building a
public network and they're building Enterprise blockchain,
toolkit stack, whatever you want to call it.
So from that perspective, I thought it was, it was, it was
interesting. I think you'll see that we sort
of get into the weeds with Monica because there's some some
points where Where we didn't quite agree about some of the
fundamental underlying premises of their, of their public, the
public network, and the consensus Network there, the
mining protocol, but I think it was interesting.
Nonetheless, what do you think mayor?
this kind of a unique episode for me because I saw the videos
of kadena, and I chatted with Sonny on the epicenter slack
prior to doing this episode, and Sonny.
And I were like Cadenas claiming nearly infinite scalable
infinitely, scalable proof-of-work blockchain you
know in one of the videos. Somebody asks them, what's the
limit to the scalability of your public platform?
And their answer is, you know, that they limit is something
like the limit of global bandwidth.
That is available in the world is what will limit their
platform. Like, some some answer that goes
into, you know, like the billions or trillions of
transactions, a second. And and when I Sonny and I like
looked at it, we felt that the scalability solution don't work.
So I was actually I came into this episode.
Hoping my doubts would be cleared and my skepticism would
go but it really hasn't. So I guess like what I am going
to do is you have the episode, you can listen to it, I get into
the weeds with Monica. And I'm going to just write what
I think, as a comment on on YouTube or on let's talk
Bitcoin. So I want to do this because I
sort of realize that. People listen to epicenter
episodes and they some of them might put their money one way or
another based on our episodes. And if I feel, if I have a
critical opinion about something, I just want to put it
there and have a discussion about it so our listeners see
what's going on in the hosts. Mine.
Yeah, yeah. That's a good way to do it.
Yeah, for myself I had discuss with Sonny prior to the episode,
but I did read the white papers and yeah, there were some things
that I also felt, I think it was after the show, we're talking
with her, that maybe we were there were some fundamental
differences about how we were coming at the problem, and we
really couldn't get to Get to really put forth and agree on
what we were disagreeing about. And yeah, maybe this is
something that we can try to follow up with or try to get a
better understanding in, you know, discussions sort of off
the show but in Twitter and social networks and stuff.
So, yeah, here it is our interview with Monica,
acquaintance of kadena I forgot to mention two things.
First, we are a web three this week in Berlin.
So if you're in town at the event and you see us come, say
hello, we be happy to see you and we will be at Defcon 4 in
Prague next week, all week long and we are hosting a meet up.
It is the decentralized pumpkin meet up.
If you think pumpkins are too centralized, you should come.
Have drinks with us and discuss this core issue.
It is on October 31st, Halloween night, between 7:30 and 9:30.
Right before the big Halloween party.
So location is not quite figured out yet, but if you go to
epicenter .t V / Defcon 4 and you sign up will send you a
notification when we have a location.
So, see you at the web 3 and see what they've done.
Louis here with Monica acquaintance, and Monica is head
of engineering and adoption strategy at kadena Monica.
Thanks for joining us. Thanks for having me.
So kadena is a company that came out of JPMorgan and we're going
to be talking to Monica today about the work that kadena is
doing sort of in both public and private blockchain and both both
of those ecosystems. They are building a public
blockchain network that is based on a new consensus model that
they've engineered called chain web and there, So on the other
side of that working on a private blockchain
infrastructure for Enterprise. And so today we'll be getting
into that in detail with me. So, first off perhaps, let's get
a better background. How did you get involved in
blockchain technology? That's why I love asking
people's crypto origin stories. So my I actually I worked with
Will at the SEC once upon a time, we were both in the group
that develops software to try to catch high frequency.
Trading fraud, the idea is that you need software products in
order to analyze trading blotters.
And so, we were working on a team that built will wrote the
first draft of something. That Actually got pushed out to
a bunch of examiners where they can like, upload a trade blotter
and it teaches examiner's, how to look for trading fraud.
So that was we were working there at the SEC and he was
really burned out and I was looking for something new.
So we both left at the same time and I went to go be a systems
engineer for rent to the runway, which is a fashion company based
in New York, and he went to jpmorgan's, blockchain research
Group, which was Hughes the lead engineer there and was hired by
Stu popejoy. And so, we'll and Stu were
working on the team that made Juno, which was originally
proposed to become part of hyper Ledger.
And then it didn't. And then it sort of eventually
morphed into the team that worked on Quorum before they
were doing, that will ensue were like, oh, we've made this really
incredible thing. This private blockchain, we
should turn that into a company so they left and they started
kadena. Originally make a private
blockchain with a smart contract language and then they're like,
wait a minute, we have an opportunity here.
We could take this from our contract language and we could
put it on a public blockchain and then so over time we've
evolved into this place where our product is actually just a
block chain that works for both public and private.
So willens do called me and said, hey we're going to make a
public blockchain. Do you want to come?
We need a systems engineer and we need somebody who can talk to
people about what engineering means.
So yeah, that's I started in December of last year, which has
been, I guess that's it. Like, ten months now, it's been
the longest 10 months of my life, we do a lot of great
stuff. A lot of good research but it's
also just like everything moves so fast.
Interesting. So you mentioned, you work at a
fashion company. How how is that experience,
informed anything that you're doing a get enough through?
The I was on the team that was doing data infrastructure and
that was a we were taking it from a bare metal database to a
distributed data cluster in the cloud.
So I was working on this project.
I was the tech lead for taking basically a, the old school
cluster in Secaucus New Jersey. And put more at migrating that
so that was, it ends up being really useful because I can
think about data and how its structured, and how it's stored
and like what atomicity means and being able to replicate
transactions. And so it actually translates
pretty well to the idea of blockchain to, in my mind a
blockchain is not necessarily different from the database.
It's just a data store that nobody administers.
It has some particular rules about it, but at the end of the
day, like it, Just another distributed data store.
I was not expecting that experience to be some
informative but more specifically, I think maybe we
could talk about your role at the SEC what you were doing
there and how that sort of that brought you into your trajectory
into what you're doing now. So the interesting thing about
what we were doing at the ICC is that the their technology
requirements are very high but they have the the talent there
needs to be roughly unfettered in order to do what they're
doing. And this idea of trying to
create sort of a tech incubator inside of a large government
organization, we were at the Forefront of that and it didn't
always like there's obviously friction there because engineer
is that have that are really brilliant and we had some
incredible brilliant people on that team and a lot of them are
still there. The idea of having to push the
agenda for new The Event Horizon of new technology inside of a
government organization, that we had a lot of friction there.
So I actually didn't last very long.
Well, was there for almost two years.
I was only there for like, four months before will left.
And I was like, I was just here to work with Will, who is we've
been friends basically, since College?
Cool. So shifting into kadena, can you
talk about some of the main projects that the companies
working on? Yeah, so the we essentially have
our hypothesis is that there is you only need one block chain
instead of going around and trying to Cobble together, like,
oh, I'm going to launch my token using etherium, and then I'm
going to write it in solidity but I might want to compiled a
Waze mm. And then I might want to have
some sort of second, Scalability Solution on top.
And then under, like, it's too confusing.
It's too hard. Nobody wants to develop on that.
It's not developer-friendly. We're still at the build, your
own PC stage of computing right now.
We're like it's for hobbyists and it's for people that like,
get excited about seeing all these weird tool stuff but we're
not going to see real adoption and usage and blockchain land
until we move away from like, oh well, you know, you're not a
real blockchain developer on. Less you build your own stack.
We are offering a stack that just works instead of building
your own PC. You can just go to the Apple
Store and you can buy a Mac and it'll just work and you can just
do your development on top of it.
So we have our own smart contract language and we're
building our own public blockchain and it already
scales. It already has a base layer
scaling solution. We're building all of our own
tooling. So right now we're working on a
pretty developer IDE that has built-in error messages that has
built-in formal verification. We have a bunch of new
developments around. How we use formal verification
in our stack. And then we also have the way
that we deal with privacy and handling privacy Solutions, is
we have you can have an oracle out to our private blockchains
so you can share as much data with public blockchain as you
want to and it just it's all designed to work together.
You don't have to go around and like find a bunch of third-party
solutions to try to do the thing that you're trying to do.
So you mentioned that there should be only one block chain
and so you're building your building this block chain based
of this idea called chain web. How does so?
Is it like do intend to build these permission private
blockchains using the work that was done at JPMorgan?
These will be separate block chains that Connect into this
system or has your focus entirely shifted to just a
public chain. We are still working on the
private blockchain. We're actually have a healthcare
insurance Consortium that's using our private blockchain
right now. In order to they have an MVP and
they're working on getting the pilot up and running between
these different companies and right now they're using it for
doctor office information. Sharing the idea is that each of
these insurance companies get fined if they don't have correct
information about like where a doctor is located and what
insurance they're taking. So each of them have people that
they spend money on that, call all of the doctor, like every
doctor in order to try and figure out what the right
information is obviously they spend a ton of money doing this
redundant work because they're all trying to do it.
So phase one of this project is each of them, instead can
contribute to this ownerless system, where they all benefit
from the data. And right now, there's a
mechanism in it where they can everybody pays into the system
by running their nodes and then They get rewarded for updating
pieces of data. And then eventually, the idea is
that this project we will connect to the public blockchain
and allow doctors to actually update their own information
because then they don't get spammed with calls from every
single insurance company and then they can get rewarded
directly. So the network can actually
sustain itself in terms of data update and storage.
So this is the kind of idea was like a private Block Chain, that
connects to a public blockchain but really it's just One
project, it's the project where doctors and insurance companies
can communicate with better data.
But it's connected of all these different pieces which is a
private blockchain with our smart contract language on top.
That connects to a public blockchain interface.
You know the Dutch have given us so much orange.
Carrots, Bluetooth. Artificial hearts, even Donuts
were invented by Dutch people, but they also gave us Dutch
auctions, which as it turns out are great for decentralized.
Exchanges Dutch, X is a decentralized trade.
Protocol for ERC, 20 tokens and it's invented designed and built
by kenosis current order book based exchanges.
Whether centralized or decentralized have a couple of
issues, minors and exchanges can FrontRunner trade when they step
in front of a large order to gain an economic Advantage.
Not to mention issues with securing funds, High listing
fees, lack of liquidity and pricing efficiencies.
The Dutch checks. Exchange platform uses a Dutch
auction mechanism to determine the fair value for a token and
participants in a trade are encouraged to reveal their true
willingness to pay. Say which eliminates front
running as a permissionless on chain protocol.
It's useful for Bots and other smart contracts needing to
exchange tokens and Dutch X also acts as an oracle for dash,
requiring, a price feed. So to learn more, check out the
documentation at epicenter. Dot TV, / THX, smart contracts
are live on a theorem a net. So you can start building today,
we'd like to thank gnosis and checks for their support of
epicenter. I'd like to come back just to
this thing. You said earlier that that we
would only have one block chain as a software developer, I'm
sure you can appreciate that. We have multiple programming
different programming languages from C++ to Java to JavaScript
and things like PHP and node, and all these different
programming languages, sort of serve a specific use cases, or
specific type of application development.
You know, whether it be for web development or Enterprise or in
solidity for smart contracts and such I think that this analogy
is sort of overlaps quite well in the blockchain space one
because presumably they'll be many types of applications for
blockchain but also just because of the sheer nature of Open
Source software and how things sort of or can proliferate, and
people work on their own projects and build their own
applications in such. Do you do you think that really
stands up that there could be a future where potentially we
could only have one block chain and everything else just
vanishes. So I definitely did not say
that. We Should only have one
blockchain, what I was trying to say and it may not have come out
this way was the idea that you should have the option to just
have a thing that works. And I don't necessarily agree
with like, there are multiple operating systems and people
write in different languages and we have lots of discussions
about languages all of the time but you don't have to build your
own computer in order to do development right now like the
onboarding pipeline. For becoming a web developer,
for example is easy. You just you go to the store and
you buy a computer and then you like, write your first app and
it's not that hard. You don't have to understand how
a computer works to write a web app, you don't need to.
We want to get to the place where you don't have to
necessarily understand like how cryptographic hashing Works in
order to build an app on a blockchain.
That was the point that I was trying to make that right now,
the learning curve is too steep. Too high.
You have to like have an opinion on validator nodes and like,
what's the right structure? Do you want to use like
distributed or do you want to use pbft or like all of these
things like people here, all these terms floating around,
they get totally bewildered. And we scare away otherwise
perfectly good developers who would be great for our community
with like Balderdash around stupid stuff about consensus
protocols like that stuff does not matter when you just want
people to build something. I Want to get the on-ramp from
people learning about blockchain to building things on blockchain
to be way easier. And I don't think that we're
going to end up with one block chain.
I'm fact I think that continuing to make like we because of the
way that interoperability Works inside of our own protocol mean
that we are already set up to have interoperability with other
projects which means we're going to connect to the cosmos Hub and
we're going to connect to a theorem and you'll be able to
launch your token on a theory on.
But have it the all of your transactions happen on top of
kadena? That's that's the goal.
So of course you want to build this main public network and
because you want it to be accessible to developers of all
kinds, you wanted to be scalable, right?
So that's why kadena is focusing on scalability for its public
chain. Yeah, we're focused on the way
that our architecture setup. We actually get both scalability
and security. The the design for chain web was
originally proposed by people not us.
It was probably the first paper that came out with something
like that was for Block rope, which came out and suggested a
way of scaling Bitcoin for security purposes, where you can
have two Bitcoins that share their proofs with each other,
which would give you an additional security property.
And we came up with this separately, and then ended up
coming back around to the same place where we've proposed it
for scalability and then realize that we also get the security
feature. So yes, the idea is that you can
just put something on chain web and not have to worry about
whether it's going to scale out or not.
Yes, and let's talk about chain web and this scalability and
security solution. Through it, how it works.
I usually do this with diagrams because it's a sometimes hard to
visualize. I'm a very visual person but we
can talk about it. So imagine Bitcoin and the idea
that you have a block and then your new block that you generate
on top of that one has a reference back to the original
block. Right.
This is the idea of like hash linking, or having a root or a
tree like a Merkle tree. So now, imagine if you had two
chains, then they each have their Genesis block and then
they each start working on their first block.
The first block for each of these chains would contain the
proof, like just the hash of the Year, their peer chains previous
block. So, not only do they have a
reference to their On previous block, they have a reference to
their peer chains, previous block, you can see for Two
Chains, this is a lot of messages.
Like you have exactly double the number of references as you do
chains, and that's a lot. So the way that we scale this is
by using a fixed graph structure and at this point, people are
like, oh, this makes you a dag with my response is all
blockchains are a dag. So all of these projects like
cash graph and Iota are what Like to call arbitrary tags
where they'll just pick like, some neighbor.
That's listening. That's ready to receive piece of
information. We have a fixed graph structure
where peer chains, always communicate to the pier that
they're supposed to talk to. And the way this gives us the
benefit of always having them communicate in the most
efficient manner, specifically, our graph structure with how we
braid the chains together. We use solutions to the degree
diameter. A problem which is how do you
have the largest order graph with a minimum number of
messages between nodes the degree and the longest shortest
top is minimized. So that's like the, the shortest
path between two points. What's the longest one of those
minimize that number? So it allows for the fastest
propagation of information out to all of the nodes, now this is
how we get it to be fast and how we get it.
Basically communicate with each other and effective matter is,
by picking a fixed graph structure, and we have for each
potential size of chain web over, which there are, you know,
many many, many different potential sizes.
Each of them, we get to pick the most efficient structure per
size. So, I talked about the Peterson
graph a lot because it's easy to visualize in your mind, it's 10
chains, each of those chains, communicating with each other,
in a fixed graph structure with a degree of 2 and a diameter of
2. So, Oh, that's to Nessa jizz per
node and to block height to receive full information
propagation from any node to any other node.
Okay? Okay, so let's let's unpack
that. Like so the way I'm thinking of
it is so, so imagine Two Chains. Let's say you have the Litecoin
chain and you have the Monaro Gene, right?
So we don't have interoperability between
different projects, it's not, it's not interoperability
between Projects. So what I'm trying to do is
essentially start with like Litecoin and more narrow strip
away things. We don't need like two coins.
Let's strip that away and have one coin and then and slowly
from from that starting point. Let's build kadena, right.
So, so so imagine like you have this is just imagine you have
like Litecoin and more narrow and we have like two chains.
And these two, two chains have two different coins today.
So one is light going, the other is one arrow and somehow in
later on in Cadena, it's like we are going to remove the two
coins and there's going to be a single coin.
So can we can we just talk about cloning Bitcoin instead like you
have Bitcoin and then you have another Bitcoin and they're both
like because the idea is that all of the chains are actually
identical. They're completely identical in
terms of how they maintain state in terms of how you interact
with it in terms. Of what they support.
Like they're all completely clones of each other.
Okay, so they're going to things Bitcoin and Bitcoin to, okay.
So you have Bitcoin and one in Bitcoin to.
And so you have like two these two blockchains, they both are
producing blocks else. Let's say, 10 minutes.
And now let's say I'm a minor and in Bitcoin one I'm a minor
in that chain. So I create a block right.
So what happens differently now in kadena, so in in Bitcoin when
I create a block in Bitcoin one, I would reference only the
previous block of Bitcoin. One, what would I do differently
in kadena? Right.
So as a minor, we expect that everybody's best case scenario
would be to me. All of the chains, all of the
time. So as a minor, you're actually
mining both Bitcoin and Bitcoin to you're trying to get a
success on both chains which from like a game theory
perspective, you want to split your hashing power because you
don't want to have a collision where you get a success.
Like if you throw all 100 threads on the same, to
generating the same block, there's a nonzero probability
that you get a success on to of your threads at the same time
which case you've wasted a bunch of hash power and you should
have to throw one of them away. So instead we positive that
people are going to try to mine as many changes as possible all
at the same time because then they can have more potential,
successes all at the same time. So you as a minor would mine
both Bitcoin one and Bitcoin to and you're just like hammering
away at both of them at the same time.
So for example, if I have 100 e-cig machines, I'm putting 50
Asic machines on bitcoin one and the other 50 on bitcoin.
Sure. Yeah, all right, let's go.
So if if you're mining Bitcoin one, did your block that you're
attempting to solve has in its header, a reference to both the
previous Block in Bitcoin one and the previous block on
bitcoin to Okay, so I'll create a block on bitcoin one and it
says, when this block comes comes in it references, the
previous Block in Bitcoin one and then it also says, oh, the
last block that I had heard of in Bitcoin to was this.
So put that in as well. Yes, right.
And similarly, some other minor that generates a block in
Bitcoin to would have listened about my block in Bitcoin one
and they would put the my hash of this block in between And one
in their block when they create one in Bitcoin to.
Yes. Exactly.
So information about each block in Bitcoin to ends up, entering
the Bitcoin, one blockchain and information about each block in
the Bitcoin, one chain ends up entering Bitcoin to.
Yes, exactly. And the benefit of doing this is
to fold one. It keeps the network from
diverging because if you have to listen to your peer chains, then
you have to very quickly come to like if there are two potential
blocks on bitcoin one and you're a minor on bitcoin to when you
hear about both of these blocks, you must immediately pick one
because you can only include one of them as the truth of Bitcoin
one in your next block. So it's a way of forcing Forks
to recombine faster because if there's a fork on bitcoin one
not only do the Bitcoin one miners, have Pick one, but also,
all of the other peer chains in this case, Bitcoin, to have to
pick one which forces people to make decisions, which is what
resolves Forks. So, that's one reason, the other
reason is this allows us to share.
This is how we propagate State between chains and which we do
through simple payment verification.
So if I want have an account on bitcoin one and we're an
account-based, not UT exobase. So I have an account on bitcoin
one. One and I want to pay you, but
you're on bitcoin to the way that we do that is we write a
smart contract or I hate the terms of our contract, we can
call it a smart contract between the two of us on bitcoin one in
which I say, like oh I'm going to pay my hair, one token and
then it is signed to your account on bitcoin to and then
we put that in on bitcoin one, the proof of it propagates in
the next block, 2. Point to, at which point you
say, hey, I'm going to redeem my half of the smart contract, on
bitcoin to I have destroyed the coins on bitcoin one and they're
gone. And then you redeem, which
consumes the transaction ID for your half of the Redemption for
the smart contract and then they coins get created on bitcoin to.
So we're like you could potentially have a case in which
there are is a chain that has no tokens on it because it has no
accounts or they're all empty. And then another chain could
have all the tokens and it doesn't matter because each
chain maintains its own idea of state.
And this is how we pass information from chain to chain.
If you've listened to previous episodes with Marley gray and
Matt koerner, you know, that Microsoft is committed to
providing enterprise-grade tools and infrastructure for
blockchain developers. Well, the Azure blockchain
workbench is perfect for organizations building.
Consortium networks. Take the etherium proof of
authority template, for example, it's ideal for permission.
Networks were consensus, participants, are known and
reputable. A theorem on Azure has on chain
Network governance, that leverages parodies extensible,
proof of authority. Client, each Consortium member
has the power to govern the network or delegate their
consensus. Disciplines to a trusted
operator and parodies. Webassembly support allows
developers to write smart contracts and for many languages
like C C++ and rust as your blockchain workbench was created
on the same principles that drive all Production Services in
Azure. So, you know you're relying on
secure redundant infrastructure, that can scale and we built in
services. Like authenticating apis off
chain databases and secure Key Management Services.
You can scaffold your infrastructure in just a few
hours to learn more about Azure blockchain workbench and how
Microsoft is Dancing. Blockchain usability, and
Enterprise, check out, aka.ms/offweb the center and
start building today. We'd like to thank Microsoft
Azure for their support of epicenter on the topic.
You mentioned earlier, that as a minor, you should be mining on
many chains. So if we stay on this example,
Bitcoin want to be going to, we extend that example to now
Bitcoin. And so presumably, you know,
there was hundreds of chains, perhaps and as a minor, I'm
Distributing. My hashing power amongst all
these chains. Not create a bandwidth issue and
because I mean scalability and blockchain is fundamentally a
networking issue. I mean, it's an issue of having
sufficient bandwidth to propagate blocks quickly enough,
so that everybody can come to consensus around.
What is actual state of the chain?
So, if I'm a minor and I'm mining on 100 blocks are 100
chains, rather that not only consumes a lot of bandwidth on a
network, but it creates congestion even sort of like at
the entry point of my like, my router like in my, or the switch
in my, in my networking facility.
How do you how does get in a sari chain web addresses?
Sure. So first, we make the assumption
that large mining pools exist which I think that it the crypto
Anarchist, who wants to believe that all Bitcoin is mine.
To buy like individual hackers with a GPU or something in their
closet is like it's a fallacy. We need to accept the fact that
like, Bitcoin large, mining pools exist and they are going
to mine, the whole web because they can.
And there are essentially going to perform the function of
coordinating the header stream and the header stream is just
these messages that go across the network.
That's say, like, hey, I found a block and here's the hash of
that block. And the header stream itself is
very lightweight because it's very small hashes there that are
being passed to each other. So, if you wanted to Only Mine
one chain, you could subscribe to the header stream.
And yes, you'd have to make an assumption that the hashes that
you receiving are valid. But given the fact that we
assume that there are large mining pools and that people
will be penalized by people not believing If they ever put out a
passion, that's not valid. Then, you know, we believe that
people will be able to Only Mine a small subset of the network,
if that's all that they can handle in terms of bandwidth.
But that most of the mining will be taken up by people that are
actually capable of handling the bandwidth.
I don't know that that actually solves the networking problem at
the network level, I mean, so okay potentially small.
Mining operations or individual miners might only might want
chain, but the broader issue that the entire network needs to
be able to visualize the state. And if those smaller miners or I
don't care miners like in remote areas that don't have the
bandwidth can access the information.
So how do we secure the In that sense.
What do you mean the information?
Because they should be able to consume the header stream.
The header stream is just small hashes being sent around to each
other. And they're only the number of
messages going from chain to chain that are the degree number
of messages in the network. So it for the Peterson graph,
for example, which is 10 chains, then that's there are for every
node that sends two additional messages.
So it's not I guess I don't really understand your question.
Yeah I think the Russians question is so today we have
Bitcoin and in today Bitcoin block size is 1 MB.
Right. So every 10 minutes, if I'm a
Bitcoin miner I must Get one and be worth of data very quickly
and build on top of it, right? So when somebody else creates a
block, let's say, Monica, you create a block in New York.
I must get that 1. MB of data very quickly because
I want to build on top of it. Now, now I can scale Bitcoin by
increasing the block size. So if you increase let's say the
block size from one end, be to 100 MB.
Now I need to get this 100 MB of data very quickly, right?
In order to be competitive. Now, what Sebastian is saying is
now, if certain, additionally, traditionally, when we talk
about scaling, we we want to reduce this requirement of 100mb
to something much lower, right? So so right now, like let's say
Bitcoin had a block size of 100 MB and you wanted to scale it
using some other mechanism. What you would try to do is you
would want to reduce the need for getting 100 MB of data to
something lower like 10mb. but in kadena, it feels like because
if I'm a kadena miner and let's have mining Bitcoin one and
Bitcoin to I would need to get 100 MB for Bitcoin one and I
would need to get 100 MB for Bitcoins and you don't need the
100mb for Bitcoin to all you need.
Is the like one bite or like 64? Bytes.
No, but or if I would like the other assumption is each mining
pool is mining all of the networks.
So if they're mining Bitcoin one as one is, as well as Bitcoin
to. And if I need to actually mind
both those networks, I need to get data from both chains.
So it doesn't solve scaling because All it all it is
equivalent to is, is an increase in Block size?
Like I could increase Bitcoins block size from 100, MB to 200
MB or I could split it into two networks Bitcoin and Bitcoin to
100 MB each in both cases. I need to get that 200 MB of
data in order to actually run my mining operation.
Yes, I agree with the idea that if you wanted to mine, the
entire network, you would still need to be able to have all the
data, but that's the same problem that we have right now.
In terms of people, just wanting to be able to pump out, more
Bitcoin, blocks or make bigger Bitcoin blocks.
But this is you if you don't you don't have to mind the entire
network, you can mine a subset of the network which means you
don't have to consume all of the data.
You could mine only one chain and then just listen to the
header stream for everybody else's successes in which case
you would only need to receive if we're using 200 as our
example, and you would only need 100 Meg's from the previous
block and all the others. You could just listen in for.
So if bandwidth is your problem, then you can only subscribe to a
subset. Yes.
I actually like that. That makes total sense, right?
So so the trade-off is If I as a minor need to mine all the
chains, then I need to get the data of all the chains and if
all miners are Force to get the data of all the chains, kadena
boils down to like a single block chain with an extremely
large block size, right? So that's not scalable.
So, the point at which Cadena would be scalable is if I if me
as a minor is given the choice of needing to mine.
Only one. And forgetting about the other
chain and then I need to listen to only one chain.
Listen to a smaller data stream and other minors can work on
that other chain. And then, there is scalability.
So, I actually agree that. That's the that's the
fundamental trade-off that in order for a system like a Dana
to actually scale really scale, you would need to concentrate
minors into certain chains like, hey, miners, 3539 and 38.
Focus on blockchain number 23, U5 - focus on some other chain
and so on. Would you agree with that?
Yes. And I think that it seems like I
should build a timing and bandwidth consideration into our
mining model right now, because we're doing a bunch of markup
simulations on like x, what people's expected value is on
mining different chains and that right now at the moment, we have
it where the penalty for switching between mining
different chains is very low, which causes our model to
suggest that people are going to basically hop to mining.
Whichever chain, they think The last, the least attention last
round and with that as I could just go in and dial in different
assumptions into and right now I don't think we've necessarily
considered bandwidth as being a huge lever.
But if you think that that's interesting, like totally think
that that's a worthwhile suggestion.
From my perspective, I think bank with is but on a mantle I'm
barrier to descale ability at the lowest level me any any
solution that we try to build on top of the existing blocking him
to create more efficient watching systems whether be
proof of worker proof of stake. What we're trying to do is
essentially is minimize the amount of bandwidth that needs
to go from. Validators that maintain the
chain for me. It's sort of a sort of a
fundamental thing in in this scalability discussion in a
broader sense that most people are not addressing.
So we've had some, we had a project on recently blocks
route, sort of building a Content distribution Network for
her blockchains that addresses. This issue at the fundamental
Network level, But I haven't, I haven't seen any other projects
at least the ones we had on that sort of look at scaling from
this perspective. But you written a white paper
which describes the different attack vectors possible with
chain web and the ways you may negate them, could you run us
through some of these and how your medicating those detectors?
Sure. So, the first one that we
started looking at, because it's like the fundamental Like the
first one described in the Bitcoin white paper and all this
is about 51% attacks and how like basically everybody
screwed, if somebody gets 51% control of your network and fine
but if they don't have 51% but they have less percentage of
your network. How does that mitigate the
potential likelihood of somebody being able to attack your chain?
And so when it comes to double spend attacks because of these
shared, References between chains where like Bitcoin to has
the hash of Bitcoin one. And it not only does it quickly
force you to resolve any potential Forks.
But also, as block, depth increases and the block that's
being attacked, gets further in the buried, not only by blocks
on its own chain, but by Pierre chains, that reference.
It also getting buried, you start having to not only replace
at any. Even chain, but you also have to
replace any peer chains that happened to reference it.
So, when we started looking into strategies, that would require
some that somebody would use in order to replace a block and do
a double spend attack, they have to honestly, mine the network in
order to generate Pier blocks like more than 60% of their,
hash power actually has to go to honestly mine the network in
order to try to attack the network.
And they just, they Potentially fall behind in terms of that
attack. That, that's not really a
fusible situation. That was the first one that we
looked at this is the whole, like, the block rope originally
produce. This chains, sharing each
other's hashes as a security measure, that's how that really
gets exposed. That's how we come up with the
term, we use the term Merkel cone because it's like, Merkle
tree, but it has an additional dimension on top of it.
So it's because of the way that that the Merkel cone propagates
exponentially across all these different peer chains.
Double spend attacks are very hard.
Okay. That's that's sounds like an
interesting proposition. So like in let's say like you
have like a kadena network and you have 10 chains in this
container Network, right? And you know like the total
mining power in, this whole network is X like X that I
hashes or x x, whatever unit and you can think of it like
thousand Tara hashes, some large number, And then you have kadena
chain 1, K 1, you have good energy into k 2 and you have
approval screen, a chain 10 K, 10.
So that the total hashing power is thousand data hashes, is it
the case that kadena one gets 100?
Tara, hash kadena to gets 200, Tara hash and these thousand are
distributed equally between the chains or how does mining power
get distributed across these chains?
So, it's the, it's the miners Choice, which chains to mine.
And this is part of what the simulation project that we've
been working on, in terms of building the, the model for the
network graph, and then building the minor graph and then having
them run through simulations on how they would mind that our, we
posit obviously, we haven't built it yet, so all of this is
still simulation land. But that the network when
actually stabilizes to a point where they're all Be equal
because any chain that you think has less hash power becomes an
attractive Target. So you want if your chain, if
you think the people a lot of people are mining a chain that
you're on, then you're competing too much.
And you want to hop to a chain where the collective hashing
power is lower which actually causes the entire network to, to
stabilize their. Also the fact that you have to
wait for that the blocks to be finished on your peer chains
before you can include their proofs in your header.
It serves to it's sort of like you've tied them all together in
this three-legged race where they can't get too far ahead.
You can only get diameter number of blocks ahead of the network
as a whole, which means that any change can only fall diameter
number of blocks behind before it starts to slow.
Everybody else down, which then causes people to dog pile on to
the chain, that's holding them back.
So this is the, like, the balancing Network.
We haven't, we've called it given this event horizon of It's
various names are lead chairman of engineer calls it.
The cut set, which I think is sort of a weird term.
I was calling it the meniscus for a while, nobody like that
one. Nobody liked meniscus.
So, I've I'm going with Event Horizon for now, which is the,
like, the latest block for all of the chains and where they
are. And this is the idea that the
hashing power will pool to the lowest chain because that's the
one that is the most attractive. So that's an interesting idea.
So the basic idea is that you somehow want to have these 10
chains and you somehow want these chains to progress at
similar speeds. So if a blocks is created here,
you want the other change to create blocks.
And so what you're effectively doing is, you're somehow
incentivizing the minors to switch to the slowest chain so
that the whole system can make progress and when the miner
switch to the slowest, In automatically the highest power,
distributes equally. So right?
So you start with let's say 1,000 Tara hashes, and you end
up with a system where there is like 100 Tara ashes equally
across all the chains, right? So it won't, it won't be exactly
equal but like some might have 80 some might have 120, this is
easier that but like it you will aim to get like somewhat equal
distribution. Now, the question becomes that
suppose, now I am a miner on chain five, right.
So I'm a miner on chain five and I'm a large minor.
And now chain 5 has 80 80 like a tee, Tara hashes.
Right now, I'm a large minor and my mining capacity right now,
I'm not mining to Dana, but my mining capacity is 100 Tara
hashes. I can 51% attack chain five
because those guys are 80 and I have 100 pointed waiting to go.
So what I do here is I'll say okay, let me put those 100 on
just chain 5 and let me just create one in valid transaction
that creates. I don't know a billion kadena
and just gives it to me. And I basically create that
block very quickly on chain 5, and because my block appears
quickly because I have more hash power than the others that
invalid block propagates to change seven eight, two and one
and they include my invalid block when they create the next
block. And so my block becomes
canonical. Do you think this is a problem?
So the way that that would become resolved in chain web is
like, you're not the only minor on chain five.
Somebody else will attempt to validate your block as a way of
putting the next block on top of chain 5 and see that your block
isn't actually valid. And which case they will suggest
this as an alternative. And since people are mining like
you Would mind a subset of chains.
Mine like chains five, six and seven, then somebody who's
minding five six and seven seas that like five is actually not a
valid block and will suggest an alternative block and include
that in 6 and 7. And then whoever is most
remaining six and seven. Will see this other proposed
block 5 and that it's not included.
In this other proposed block 6, which will then cause them to
reject that block 5 and the block 6 that includes a
reference to the bad block 5. Like This idea that a bad block
would never be validated by another minor is like, I think
the core of why that doesn't necessarily work.
So what are you saying is now, you're going to use the other
chains as a Judiciary of Kinds, right?
So I'm the, I'm the big bag, bad attacker.
And let's say, Sebastian represent the honest miners of
chain 5, I'm the attacker of chain 5 And so I was passed
because I have more hashing power.
I produce the black quickly, it broadcast quickly.
Now you saying like, oh Sebastian but will also create
the competing block and try to broadcast it right now.
Now the whole network chains, one two ten must decide his
methods block canonical or Sebastian's block canonical.
So, the whole network in some senses needs to become a
Judiciary. Yes.
But they can be a judiciary. Only if they know if only if
they store the whole Block Chain of chain five.
But only if they're mining a smaller subset of any connected
subset of the network like five, six and seven or three, four and
five or so. Because so let's say I propagate
my hash tube from 128 blocks change, 1 to it here.
My thing and Sebastian things Sebastian's honest, thing goes
only to 9 and 10. I win well but then it'll go to
9 and 10 and then 9 will have to reconcile with eight and then
you'll have to go and you'll pick which one of these either 9
or 8. So this is because of the way
that it's webbed together you have to make calls very fast.
And yes we assume that people are mining more than one chain
which allows them to cross check each other.
If everybody only mind one chain then we would have a problem.
But because it's designed for people to hop between chains in
mind more than one chain, it forces them to reconcile with
each other. I mean, let's let's move on to
some other topic, but I feel like the fundamental issue with
Cadena is is exactly this. It is, it is that in order for
reconciliation to work, you start to need bigger and bigger
jewelries and ultimately, you will boil down to the system
where everybody needs to mine Every Chain.
Which means Everybody needs to get the data from Every Chain,
which means actually it will not end up solving scalability.
I don't think that everybody needs to mine Every Chain but
that's that's a fair critique. Yeah.
Okay, so let's move on to the next theme Sebastian.
So there was a, I wanted to come back to this earlier in our
discussion but we sort of got sidetracked with these other
topics, but there is one passage in the white paper that kind of
struck me and I wanted to maybe get you to perhaps, explain it
in your own words on page 2. There's a section where you A
proof of stake and proof of work.
And you argue that proof of stake.
Validators would be subject to money, transmitter regulation.
At least in the US as it reads here.
Can you expand on this logic and What, what evidence you have to
support this? This claim that proof of stake.
Validators would likely be subject to money transmitter
regulations. Sure.
So this is the reason that we take this position is the idea
that right now. It's to it takes too long and
it's too hard to pass new laws to try to regulate blockchain.
And it's going to take a while in order to get new legislation
out there. Are especially in the United
States for these things, take forever and people debate about
them for a long time that trying to pass new laws for black jeans
going to take a while. So the only way that people are
going to try to regulate blockchain for at least, the
short-term is to try to apply existing legislation to block
chain. And the way that existing
legislation works for money transmitters is essentially, if
you put money up and we know who you are and then you clear a
transaction that sends money to like Al-Qaeda or something.
That we should punish you because you are enabling money
Transmissions to somebody who's sketchy.
So when it comes to proof-of-work miners because
they don't necessarily have any stake in the network and we
don't necessarily know who they are, if they clear a transaction
by mining that sends money to Al-Qaeda, then it's not their
fault because they weren't actually Being a money
transmitter because they didn't put any money up and we don't
know who they are, but when it comes to proof of stake, part of
the argument about making proof of stake, work, is that you had
to prove your identity. And you had to stake some sort
of amount of money and because you put up that money and then
you sent money to Al Qaeda, you can fall under existing money
translator legislation, much easier than a minor who doesn't
look like what the law already considers to be a money
transmitter. So That's why this area it's
that the shape of staking looks a lot like, the shape, of
existing money transmitter legislation.
Whereas, the shape of mining doesn't look very similar to
existing money transmitter laws. So that's why we're concerned
about validation in general. Like, all of these Services were
a fund is trying to turn their fund into being a validator on
my chios or something where they then clear transaction that then
causes, I don't know. No, something illegal that they
could be held liable for it. I mean, so don't you think that
if this were the case, if Regulators really wanted to go
after, after make what I mean like and I mean Bitcoin in the
eyes of us Regulators, I would say I mean, to some extent,
perhaps not everyone, but the some extent Bitcoin is seen as a
currency where a lot of it listed transactions occur, or at
least have occurred in the past. Don't you think The Regulators
could just go after money pools, that it because we know we're
mining is concentrated where they could.
Could force mining pools to do kyc on the miners that access
the pool. I don't think that legally they
could make that case right now that mining is money
transmission but I do think that they can make the case that
validating is money transmission.
That's that's our stance on it. That validating looks really
similar to existing legislation and Mining does not Mary I think
you'll have a lot to say about this.
Yeah and this is because like the validator is identified with
one public key, whereas a minor is not.
Yeah. Or that a minor may not even be
participating in the network necessarily.
They could just be mining a block with their hashing power,
and then immediately selling all their Bitcoin.
And they don't care about like staking money in the network.
It's this, like, staking thing. That is the, that is the problem
because then it looks like being having a money transmitter
license is like you know you staked a bunch of cash in order
for somebody to then be able to use you as a transmitter.
That's what that shape starts. Click.
Yeah, but I would say that that up, I mean the the obfuscation
of identity that you have in Bitcoin.
Mining can be you can wrap your, you can replicate that
obfuscation in proof of stake as well.
Be okay. You may have a key but I mean,
you can pretty easily I would say change that that key for the
next round of validations and the the valve later that's
taking steak from from Dell Gators doesn't necessarily have
the identity on this road. Some sort of kyc, of the
delegator themselves. So it's it's the probabilistic
nature of proof of work that really gives it the
slipperiness. Because as a Bitcoin miner there
is always a nonzero chance that the block that you confirmed
might not actually be the real confirmation.
It's this like invalidating, you actually have to vote and then
the vote is confirmed. And Have finality.
It's the finality thing that really makes it a certified
transition with your name on it in Bitcoin.
It's like there's always some probability as to whether you
did or did not confirm it and it's not really a Line in the
Sand, it's this finality issue that actually makes it slippery.
That's a very interesting argument.
I was saying like that's something and that's an entirely
new way of looking at it. So what you're saying is if I'm
a miner in Bitcoin and I created this block, it had a bunch of
transactions and I published it. I can argue that I published
some data but I wasn't 100% sure.
It was going to be included in the Bitcoin blockchain.
It could have been orphaned. So I wasn't processing
transactions, I was just publishing data and because I
didn't have certainty that that data would go into Bitcoin, I'm
not transmitting money. but in proof of stake, if I vote on a
block and after my vote the block gets finalized.
So let's say like the voting has happened and I cast the
determining vote that finalized that block.
And what I'm essentially doing is in the process of voting.
I am making the transactions final And that makes me more
like a money transmitter because while I was publishing that
data, I knew that if I publish it, these transactions would be
considered final. Yeah.
That's super interesting II. Don't know if The Regulators are
going to look at it like this or not, who knows?
I mean that's are interpreted. We just think that proof of work
is safer because it has this other like dimensional element
to it and I really don't want to go to jail.
I'm sure like the proof of stake designers, so you know, like, In
Allegan Cosmos. So I'm actually building a
cosmos validator. So this is a topic that's really
close to my heart in Cosmos. Yes.
Like the validator, it could be doing things that are like
castingwords. It's like you know or like you
know in Cosmo 66% of the network has to cast a cast.
A yes, vote for the block to go in the chain and be final.
So let's say, you know, like 65% has done and then My validator
costs that decisive vote that switches it over to 66% and then
creates a new block that takes that vote as final then maybe
they maybe they could be this element that.
Yes, I did put the deciding vote in there.
The validated it put the deciding vote in there, but I
think if you look at something like this a source, that
argument would be quite vka Source because in tells us even
if you create a block that block is not final until like 10 or 20
blocks are built on top of your block, it's like Bitcoin so
Cosmos is not like Bitcoin. The block is final and you don't
need to have more blocks on top of it to be final but in tells
us it's like like Bitcoin where you need 10 things to come on
top of yours before it gets considered final.
So if that's the argument then there's us Baker is fine but a
cosmos validator may not be so that that will be quite
interesting. I actually love Cosmos.
I think Cosmos is a great project and I think Zaki is
amazing and their whole team is great.
So just because we're not proof of stake doesn't mean that
necessarily were like fundamentally theologically
opposed to proof of stake. We look at some of the
blockchain ecosystem. At the moment, we can start to
discern some, some, some some applications and use cases for
each one. You know, Bitcoin is sort of
shaping up to be a digital gold, right?
And asset that you keep and that will gain value within the
future. Ethereum is shaping up to be at
least in the initial use cases in Project funding.
Etc. What is what is the use case
here for her chain web? What's the application that
you're hoping? Willie marriage is like the
killer application for chain with?
So I like to talk about the like blockchain as a stack where, for
example, if you were going to launch a project and you wanted
to do a token sale and then you want to have an application,
that would be able to move a bunch of transactions through
your app. And then you would sell your
token on ethereum, but you would want to program your app impact
and have your transactions from Chain web because we positive
that we're going to have much higher throughput and therefore
much lower transaction fees and we will be able to handle high
volume transactions in a way that right now if they're IAM
your sort of struggling to have a high volume of transactions
and we would like to have the ability to have interoperability
between all of these other different layers of the
blockchain stack. If you wanted to launch your
token on eith, we would want to be the computer underneath
because we have a super simple, smart contract language that we
think is very easy and has really nice tooling on top of a
chain, that will be able to handle your throughput.
So we're very conscious of your time here.
And we want to spend some time on packed, but I think we might
have to leave that for a future episode.
Give me like, two minutes on packed.
Okay, sure. Because it's really cool and
really, everybody should go and take a look at it.
We have the developer SDK sir. You can, like, treat your
computer as if it were a tiny node, and right packed right
now. It's so we've taken like,
basically the completely opposite track from solidity and
all this like virtual machine land, where we're trying to
replicate an entire computer on a blockchain, it is non
turing-complete on purpose. It's more like SQL for the
blockchain instead of sequel for database.
We have packed for blockchain and it has all the things like
key, signatures and governance. And who owns what?
And who can change? What?
All that is built in automatically.
It has a Full formal verification spec.
And we have this really awesome thing.
Now that we've just developed called verifiable interfaces,
where you can essentially like program, what an ER C20 should
look like and give it a bunch of specs.
And then if somebody implements it incorrectly, it will warn
them like, oh, you're you're C20.
Equivalent is actually a malformed.
So you can can't have like we did the summer a bunch of, like,
bad ERC 20s that come out. So, all of that stuff all built
in already packed is like, I could.
And a whole nother hour talking about it, but we'll talk about
it another time. Yeah, well we perhaps we can
have your own in the future to go more in depth on packed
because I mean chain web did take a while to unpack here
unpacked. So I did want to spend some time
on on kadena and your private blockchain offering.
So how does Canada interact with with chain web?
And what's the goal here with regards to the types of clients?
It's that you're approaching with this with this platform.
Yeah. So we have, we have to signed
clients. Right now that we're working
with one of them is this health care insurance project that
we've already. I've already talked about
briefly but in general, the idea is that we want to be a way of
onboarding existing businesses and new business applications
from private to public in a way that is Safe and secure, and is
a way of unlocking, existing business value in a new way, new
liquidity pipeline. So, I talked about the health
insurance one where, you know, you can pay doctors to update
their own information. We've also talked to a bunch of
different companies. Some of them are, some of them
are cooler than others. Are other big client right now,
is a reinsurance company that does Insurance products.
They do like home insurance and stuff.
Cough. And so we've been discussing
with them something where they can have a broader pipeline for
validating their auditor data. So using a third-party Auditors
that can contribute data in a more tightly verified way to
their pipelines so that they can have a better less leakage in
their insurance flow. Basically.
So we have the side where we deal mostly with private and
then we also have a focus on dealing with public and then
everything in between So we talked about the idea of
connecting Smart TV to the wall and then having a people in
public on the public blockchain, get paid like five dollars off
their Netflix subscription or something in order to provide
their Smart TV data to a private blockchain, that would then use
that information which would be better than what we have now
because right now like who knows who's looking at your data and
what you're providing them. This would give you control over
your own data which you could monetize in public but then they
could mine. In private.
So there's we have this idea that there's not private and
public, there's just one block chain with different
permissions, So to touch on this in the in the white paper you
there's a part there where it references, sort of the
scalability benefits of kadena in a private setting and it
makes reference to sort of five to fifteen thousand nodes as
being, you know, the threshold where it begins to exhibit
linear scalability. Let me, which is sort of expect
that at some point that your system is going to stop scaling
exponentially and more linearly But give it given that, you
know, a network like Bitcoin as I just looked up earlier, has
about 10,000 nodes. What point does a network, go
from being a private Network to just being another public
network? Does it preserve the benefits
that sort of the initial Consortium or set of clients set
out to, to implement? And what where's the line?
They're like, where were you sort of switched from being one
to the other? So the our simulations for
scalable bft, which is our private consensus mechanism, is
we've never run a simulation more than 500 nodes.
But given that are other options for people trying to do private
blockchain right now or like hyper Ledger, that doesn't scale
past four nodes and kurta, which isn't even really a blockchain
and all of these like other private blockchain Technologies.
We fundamentally believe that we have a better private
blockchain, then anybody else right now.
And that the idea is that you would for one of these
applications, start it in scalable, bft in the Consortium
model. And then, as you see the
potential benefits of unlocking, some of these pieces of data
into public, you can connect them to the public chain.
So it's more about how you want to monetize your data.
If it's still the idea that you want to share in a Consortium
model like we can scale that out for some certain amount of time,
but it's still a permission model.
Whereas, if you wanted to allow exposure to some of these pieces
of data to the public, like, we're talking to a fund right
now that creates products for people to put in their, like,
mutual fund portfolios. It's not treasury bonds, but
it's sort of like treasury bonds.
They want to create A tokenized representation of one of their
funds so that would be a public representation of a private
blockchain that represents an asset.
If that makes any sense. So I want to take this
opportunity to ask you your thoughts and opinions about
where we stand right now, with regards to Enterprise blockchain
permission blockchain, what have you?
Previously, I co-founded a company that sold I guess
Enterprise blockchains solutions for traceability to do large,
insurance, companies companies and finance sector.
And I came out of that with haven't been confronted with the
the the challenge. Of implementing blockchain in
Enterprise, sort of skeptical to like, where things are going in
the space right now. And I could point to a few
things namely is that blocked any sort of orthogonal to a lot
of the business models in, in finance, most in the financial
sector with insurance or banking, or financial services.
And although a lot of companies obviously are paying attention
to blockchain and experimenting with proof of concept set, None
of that has really panned out. And, you know, we've been saying
for about three years. I like that Enterprise is going
to start adopting blockchain, but even the largest Consulting
companies like IBM have been pumping out, pocs and are
struggling to convert those into production systems.
I think mostly it's because of this orthogonal nature of what
blockchains represent to large companies and just failing to
see the ROI I guess. As everybody is joining
consortiums and trying to figure out like what they're going to
do next. Why is credit card Anna
different in this sense and like what's your what's your
go-to-market strategy? For bringing customers on board,
consortiums on board and then converting them over.
It's a sort of this public is more public network as you
described it. So, our vision for kadena is a
whole is that we because of how, our smart contracts function,
you can essentially create importable services.
So stick with me here, and I'm going to tie back to Enterprise,
but imagine on the public chain that you have building block
services, that provide a network that You a lot of flexibility.
So you have we're going to set up a background, check service
that's on the blockchain and a escrow service and a smart
contract insurance. And all of these components that
we have right now in the economy, they don't function
great and they're expensive. And they essentially push all of
the payment on to the consumers, end, which sucks.
So instead, if we Have them in an importable smart contract way
on a public blockchain. Then you say as entrepreneur
want to create a rent, an apartment service on the
blockchain. So what you would do is you
would have a way of showing your listings.
And then when somebody wants to rent an apartment, you would
import the background. Check smart contract and you
would use it. And for some sort of micro
transaction fee, you pay the verifier of the background check
directly. Finish my contract, you would
have some sort of escrow service, which you would pay
directly, or maybe you just do it built into your smart
contract and these building block components would help you
do the part of your real estate. Apartment rental startup that is
most interesting to you, which is figuring out how to expose
listings without having to deal with all of these other terrible
components that are necessary for a company like ensuring your
smart contracts and doing background checks.
And whatever. So then when we're talking about
having these services on a chain, there are a lot of
companies that already have these Services.
They just don't know how to effectively monetize them or
they're already cost centers from their company that by
having an oracle to public blockchain, they could monetize
what's already a cost center for them.
So imagine like, I don't chase bank, Chase Bank already has
Department that does background checks and if they could have a
smart contract on the public blockchain where people could
pay them to do background checks, they could run that
through their Pipeline and monetize an existing business
unit. That right now is only a cost
center for them. So this is it's sort of like
applying the sharing economy to the components that already make
up very large businesses. So this is a way of onboarding
Chase Bank on to Enterprise bok choy.
And I'm not saying like Deer Chase Bank.
Please go in and rip out all of your existing database because
they're never going to do that. But instead we can go to them
and say, look, let's create a new product that monetizes an
existing cost center in your business.
That doesn't have to connect to any of the rest of your network.
That's totally secure, and let's see how it goes, because they're
much more likely to try to create a new Revenue stream,
that's disconnected from the rest of their business.
Then they are to try to like, About the guts of their existing
infrastructure. It's super hard to sell that
because nobody wants to touch something that's basically
working for something that doesn't necessarily have any
major advantages but potential new revenue streams, everybody
gets excited for potential new revenue streams I get that and I
think that's the fundamental issue here.
And that's the sort of fundamental problems with the
whole premise of Enterprise blockchain.
Is that It is orthogonal to the like to, to try to, to get Chase
Bank to monetize an existing service is real Authority with
the way that they already do business, especially when you're
opening it up on on a sort of public network.
And I think that coming over my experience in my previous
company that it's not so much. A technological issue, is not so
much about the technology. It's really a change management
issue. And that all this is vandalism
that all of us have been doing for.
So all these years in large companies and Enterprise about
blockchain technology, I think we've been doing it wrong.
And it really comes down to like, what is the future of
identity? What is the future of payments?
What is the future of insurance? Was that going to look like in
the future and in currently, I think most people that are
addressing their talking to Innovation, departments at Banks
and financial services companies Insurance.
What have you are not really doing this.
They're still spending time saying oh well I mean, look, you
could, you could take this existing thing plug a box and
into it and start making money in this ecosystem.
That doesn't, that doesn't exist yet.
So I guess my question is remains like, what is the, what
is really, the go-to-market strategy where have you?
I like sort of identified, some key Industries or types of
clients where You can take a Dana and really provide an
out-of-the-box solution to start generating like generate
revenue. And to prove these use cases
because the proof is in the pudding.
Sure. I mean, we have two existing
clients. We already have a working MVP.
I don't know what to tell you other than like, we're doing it.
And we don't have to pay like some companies like pay people
to use pocs, like, people come to us, they want to use our
stuff. Sometimes we have to turn people
away because they're like, we have this great idea.
We're like great, but we can't execute it for you.
You have to have your own engineering team.
We're just going to give you a Consulting, like, if people
aren't ready to go, we're not going to work with them.
But right now, big people are coming to us, say they say that
we have a thing that works. We do.
So what's the, what's the roadmap like in the next?
So you mentioned earlier and SDK but people can already start
using the platform. Can you talk a bit more about
that? Sure.
So we've got two teams right now working on both the language
development and tooling for developers and another team
that's working on chain web and protocol development.
And so we've split them into two tests Nets to where we're at
right now. Working on both of them, the
same time, The Pact test. Supposed to come up next month,
where people can see it's going to use a database to generate
blocks, but it's essentially going to have all of the bells
and whistles for a development environment, where people can
put, their smart contracts up onto our IDE, and have error
messages, and it'll hook up to the formal verification system.
And this will be more of a simulated experience of what
developing on containing will be like.
And then, Meanwhile, we're working on chain web test net,
which should be up by the end of the year, which will, it's
basically, just a way of testing.
Testing how blocks get generated in Forks, get resolved in the
consensus mechanism and then we're going to merge them to
create a unified test net. When then the goal is to have
the main it launched around the second quarter of next year.
Great. So we'll have links to all that
and show notes. If people are interested, they
can go to do the Canadian website, read the white papers,
which you've you've co-written with your co-founders and and
learn more about how Canada will be building up.
This, this chain web Network and then also implementing their
Technologies in Enterprise. So thanks Monica for coming on
the show today. Thanks guys, this is great.
Thank you for joining us on this week's episode.
We release new episodes every week.
You can find And subscribe to the show on iTunes Spotify,
YouTube SoundCloud or wherever you listen to podcast.
And if you have a Google home or Alexa device, you can tell it to
listen to the latest episode of the epicenter podcast, go to
epicenter, .t V /, subscribe for a full list of places where you
can watch and listen, while you're there, be sure to sign up
for the newsletter so you get new episodes in your inbox as
the released. If you want to interact with us,
the guests or other podcast listeners you can Follow us on
Twitter and please leave us a review on iTunes.
It helps people find the show and we're always happy to read
them. The thanks so much and we look
forward to being back next week.