If we truly had a free market, I don't think we would necessarily
need all this decentralized technology the market would take
care of. What we really needed is a new
kind of blockchain, where what happens on the blockchain can be
trustlessly observed by systems outside the blockchain.
Bitcoin isn't really made for supporting these off chain use
cases. So I tried a theorem too that
didn't turn out that well either.
Mel started as like this research project to build a
blockchain back and actually support a whole Internet that's
user sovereign that has like decentralization and security
and resilience in all the protocols.
You know, not just a blockchain, but if you actually start
building these massive networks that depend on correct knowledge
of what happens on the blockchain, then if somebody
hacks inferior for a day, that's like worse than hacking
Ethereum. This episode is proudly brought
to you by Nosis, a visionary collective committed to
fostering and expanding applications for a decentralized
future. Nosis is at the forefront of
innovation with Nosis Pay Circles and Metri
revolutionizing open banking and creating a superior form of
money. With Hashi and Nosis VPN,
they're building a more resilient and privacy focused
open Internet. Are you seeking a robust L1 to
launch your project? Well, look no further than the
Nosis chain. Enjoy the same development
environment as Ethereum, but with significantly lower
transaction fees and with a robust network of over 200,000
validators, Gnosis Chain stands as a credibly neutral and
resilient foundation for your application.
Governance at Gnosis is driven by Gnosis Dow, where everyone
has a voice in shaping the project's future.
Join the Gnosis community today by participating in the Gnosis
Dow governance form. You can deploy your project on
the EVM compatible and highly decentralized Gnosis Chain, or
help secure the network by running a validator with just a
single GNO and low cost hardware.
Embark on your journey towards decentralization today at nosis
dot IO. Chorus One is one of the biggest
node operators globally and help you stake your tokens on 45 plus
networks like Ethereum, Cosmos, Celestia and DYDX.
More than 100,000 delegators stake with Chorus One, including
institutions like BIT, Go and Ledger.
Sticking with Chorus One not only gets you the highest years,
but also the most robust security practices and
infrastructure that are usually exclusive for institutions.
You can stake directly to Chorus One's public note from your
wallet, set up a white label note, or use the recently
launched product Opus to stake up to 8000 ETH in a single
transaction. You can even offer high yield
staking to your own customers using their API.
Your assets always remain in your custody, so you can have
complete Peace of Mind. Start staking today at Chorus
.1. Welcome to Epicenter, the show
which talks about the technologies, projects and
people driving decentralisation and the blockchain revolution.
I'm Brian Crane and today I'm speaking with Eric Tong, who is
the founder and CEO and CTO of Mel Project and so really
excited to get into into that with him.
There's a lot to unpack. Thanks so much for joining us
today. It's I'm really excited that to
have you on. Yeah, I'm really excited too.
So yeah, we spoke a bit before and looked a bit, you know, sort
of been looking a bit into Mel or the thing you're working on.
There is a lot there, right? There's a lot of different
components for it. It's a very ambitious, it's a
very ambitious project, but I thought, I don't know where it
makes sense to start. I wonder if it makes sense to
start with your VPN. And we're like, tell us sort of
like your journey of like how you how we became interested in,
you know, decentralization and the topics around it.
Yeah, absolutely. So, you know, I grew up both in
China and Canada. So, so back when I was small, my
family moved between the two countries a lot.
So I kind of got to experience both like a relatively well
functioning Western country, but also a country where, you know,
you had a lot of sense censorship, a lot of
surveillance and all of like technological control over
people. So like that actually played a
big role in how I got into computers as a whole because
when I was small, I was like 11 or so, I was, I was just
learning how to code. And it happened to be the same
year that China turned on its great firewall, you know, and
put it into production. So, you know, one day I just
wake, woke up and then all of my favorite websites were gone.
I couldn't go on YouTube. I couldn't go on like, you know,
Facebook and, and you know, that was a really big shock to me as
a like, I need to fix that. So I need to go to those
websites and I, that really got me into things like VPNs,
anonymous communication technology and really just like
there's this whole world that's dedicated to how do you hide
from your ISP? How do you transmit data on the
Internet in a way that your ISP doesn't know what's what's going
on? And so I really kind of dove
into that made my I back then with my like very limited coding
skills, I made like a very janky like browser actually that had
AVPN in it had like anti phishing and things like that
into it really got me into kind of like cybersecurity and
privacy and all of that. So later on, you know, I really
felt like my mission in life is really to use cryptography, use
these tools to build things that let people freely coordinate and
freely access information. I didn't know that much about
crypto or blockchains. I just went to went to like
university at Waterloo later when I was 17, I got into their
PhD program. I was like very much into like
superpunk things, right? Like I was like very much into
Tor, you know, Afrina, all of that.
How I really got into kind of like decentralization per
Southeast is really that I really saw two things.
So first of all, one thing I really felt like after I started
actually researching these things is that you need to build
like trustless systems. And this is especially, you
know, after like the whole Snowden thing, that leak
happened. I realized you couldn't just
host your server in the US and expect that to be good enough.
You can't, you, you can't just expect, OK, China's bad, you
know, Iran's Internet's bad. But as long as you encrypt your
traffic to outside of these countries, you're fine.
Well, that whole paradigm got shattered.
You, you can't trust anybody's infrastructure.
And the other thing is that, and then I discovered Bitcoin, which
showed that it's actually possible to build things that
where you don't trust any particular person through the
power of economics, you can actually build systems where
you're not assuming that somebody's trusted.
We're even assuming that a majority is trusted.
You're just assuming that a majority of people out there
want to make money, which is a much easier assumption to make.
And then you can build secure systems.
So I was super excited about Bitcoin, about block chains.
I kind of like pivoted my whole research into how can I build
these tools on top of Bitcoin. I even built like, you know,
public key infrastructures and things like that on Bitcoin.
And all this time on the side, I was developing my VPN that I
started when I was small. I rewrote it several times just.
To I I like before you were saying.
So you started your PhD program at 17?
Yeah. That's pretty crazy.
So you do. I was a bachelor's world before
bachelor's but before I went to university.
So like I wasn't necessarily limited to a particular
schedule. So I went to my bachelor's when
I was 14 and I got into my PhD when I 7th both in the
University of Waterloo. So it was easy.
I just like stayed at that one school and went to whatever like
to me the most. I guess so.
And then in the PhD you focus on, you were working a lot on
EVPN or also. Other not really like so I was
really focusing on peer-to-peer networks and Tor and anonymity
and that kind of thing and that really led me down to
discovering Bitcoin and discovering that you can
actually build secure consensus in a decentralized setting.
And so so yeah, like I kind of pivoted more towards how can we
build things like these core peer-to-peer networks, these
naming systems on Bitcoin, but later on I really discovered you
kind of can't right? Like Bitcoin isn't really made
for supporting these off chain use cases.
So I tried Ethereum too. That didn't turn out that well
either. And I published a paper or so
like here and there, but I just felt like that was not going to
be power the next generation of the Internet.
So I, I really sad and I thought about it and I realized what we
really needed is a new kind of blockchain where what happens on
the blockchain, it can be trustlessly observed by systems
outside the blockchain. And that kind of started Mel Mel
started as like this research project to build a blockchain
back and actually support a whole Internet that's user
sovereign. That's, you know, that has like
decentralization, insecurity and resilience in all the protocols.
You know, not just the blockchain, but you need a
blockchain to support them. Just so you said you were kind
of like trying out Ethereum and then you felt like Ethereum
wasn't the answer. What was the what were the
things that you felt were the shortcomings of Ethereum?
There's only just one honestly, and it's not just Ethereum, it's
every other layer one, which is that we don't have really good
light clients. So here's an example.
So let's say I'm building a BitTorrent replacement, except
the nodes are incentivized. So you know, if I download a
file from you, I got a page something like that.
Let's say you want to build this on Ethereum.
Well, there's many ways you can do this.
You can just use on chain transfers.
You could use some cool state channel thing called layer two.
It doesn't matter. There's lots of ways you can do
this. But if you actually get down to
implementing this, so you have a BitTorrent client running on
your computer and it's downloading a file from a peer
and it needs to pay that peer and it also needs to verify
incoming payments. So all of these things go
through an RPC provider like Infira.
Now this has 2 problems. First of all, they see
everything you do. They can censor it, but that's
not even the worst problem. The worst problem is that they
can lie to you, right? Like when you ask if you're a
did I get my payment? They can say yes when the actual
answer is no and there's no way for your client to know So
really the whole security, the whole economics of the system
completely depends on inferior telling you truthfully what's
happening on it. If you're even blotching and
then your system is no longer decentralized.
I thought BitTorrent was supposed to be decentralized.
Now you add a blocking in and now it's centralized.
This, that's the opposite of what you're trying to do, right?
Like so, so like I was trying to build these systems in with
every single launching it tried like this became a huge problem.
And I suspect that the reason why we currently don't feel like
this is a huge problem is not that's because we're not
building this kind of system that actually is off chain, but
uses on chain for security. Because if you're building
systems that are on chain, then this is fine, right?
If you're transferring entities on chain, if inferior lies to
you, they don't steal any money. If they don't do any damage, you
go switch to a different RPC provider.
If somebody hacks inferior for a day, it'll be of great
inconvenience. It wouldn't lead to massive
hacks of huge worldwide systems. But if you actually start
building these massive networks that depend on correct knowledge
of what happens on the blotching, then if somebody
hacks inferior for a day, that's like worse than hacking
Ethereum. Of course, I think a lot of
people are sort of like aware of this problem.
I mean, I remember a great article by we should probably
put the link on that in the show notes.
I think we mentioned it before, but there's this great article
by like Moxie Mullins Marlins. Yeah, exactly.
Right. But he kind of points exactly to
this issue. But yeah, you're right that,
like people don't tend to think of this as a problem because I
guess why would, I mean, if you're lying to you, it would
ruin their whole business. They, they don't have an
incentive to do that, right? But I guess I wonder if, if the
would the issue be more something like, OK, let's say
if, you know, I'll build this BitTorrent network that has
Ethereum incentives and you depending on a centralized RBC
provider. I mean, I imagine where the
challenge might come is that they're going to be like, oh,
but you know, we don't want to, you know, from a regular gym
perspective, we don't want to like support this kind of thing.
So we're going to have to like through all the days to shut it
down. Yeah.
I mean, honestly, this is the whole point of crypto, right?
I mean, if you think about it, it's not in the bank's incentive
to close your account. It's not in the New York Stock
Exchange. It's incentive to stop you from
selling Dogecoin. Like the whole idea is like if
we like, if we truly had a free market, I don't think we would
necessarily need all this decentralized technology.
The market would take care of it.
The problem is that we don't right?
We have monopolies and oligopolies that are controlled
that that, you know, have a symbiotic relationship with
regular regulators. And that's the whole problem
we're solving with crypto. So you know, so basically here's
the thing, like if you're building a app that depends on
inferior, you know, if you if that's fine for your use case,
then it's also fine not to use Ethereum.
It's also fine to have inferior run the whole app
infrastructure, right, like now, this is different.
So I think that the there's the biggest reason why people don't
feel like this is a problem is because we're not trying to
build this kind of app where the security bottleneck actually is
in fear of. So, for example, if we're
actually doing, you know, dehydrating or like the current
web 3 ecosystem, if you're isn't really the security bottleneck,
because, as I alluded to, if if you're a lies to you about how
many pudgy Penguins you have, how many ET you have, what's the
status of the pools on Guinea swap?
The damage they can do is very limited, right?
Like why would they do so and ruin their own reputation?
The worst thing that could happen maybe is that they censor
your transaction. They're not because of
regulatory reasons. They're not going to lie to you
because it's not in their interest and not in the interest
of anybody who hacks inferior. Like there's no reason why I
would hack inferior to troll people to say everybody has a
pudging Penguin. Like maybe I would want to do
that for fun. It's not going to make me a ton
of money. Yeah.
And and I guess the other thing I could also imagine happening
here now in the example of like, OK, BitTorrent, like network is
that of course some people not going to like that, right?
Like let's say the whole copyright type stuff, right.
So I could imagine then then basically being like, hey, we're
going to try to force inferior to give the IP addresses right
of the people so that they can basically go and pursue them.
Yeah. And I think like, that's
definitely a big problem, but I actually think that that's not
the worst problem here because that's still like a censorship
problem of inferior stopping the network.
I think the bigger problem is lying.
So I think maybe BitTorrent payment verification is not
necessarily the best example. So there are other use cases
like for example, into an encryption.
So I need to look up Brian Crane like in like Moxie Marlinspike
talks about, right? I look up your public key on a
blockchain and I use that to do into an encryption.
Now if if you're a lies to me, they can steal every single
message I sent to you, right? Like maybe I'm doing some like
big business deal here with and transferring a bunch of money.
Like you can literally steal money this way by lying to the
users. And so, so and, and it really
boils down to when we're using these decentralized systems, we
expect that we're trusting the block chains economics.
We're not expecting that we're simply running, we're simply
using a system run by insurer. So like, and you know, because
of this, if you're trying to build this whole Internet where
where the security really comes in the blockchain and you're
building these off chain systems like, you know, payment networks
or you know, BitTorrent like networks and end to an encrypted
messengers, then knowing what happens on chain really matters.
And the whole thesis of Metal is that these use cases are way
bigger than the current web for ecosystem.
The current web 3 ecosystem is like, let's stuff things on
chain. Do the composability on chain
because that's the safe place, right?
That's where all the security and consensus happens.
Once you're outside of it, you're kind of kind of like out
of luck. But if you can't actually
transfer the security out of it, then this changes the whole
paradigm and makes building out web three and mass adoption
everything way easier because you just need to look at the
blockchain from outside when when you need to.
So I, I really like what you said before, like, you know, if
you had it truly free market, we wouldn't need all this
decentralization. And I, I think that's a very
true point. And I, I think on some level,
right, if you kind of zoom out right, like what is all this
crypto blockchain decentral decentralization about?
And to me, it's also about creating an economic system that
is actually a free market. Exactly.
And I think that like Mel is really about that as well.
I think what crypto has currently done is it has greatly
liberated finance, right? Anyone can create financial
instruments, create tokens, sell basically stock in projects,
right. But the but I think that the
rest of the Internet needs a similar change.
You want a whole Internet that's permissionless, that's
borderless, that people can transact and communicate on
freely. And what Mel does is that it
takes all the cool security and decentralization we've invented
for blockchains and uses like clients to let people build
other protocols like communication protocols, like
publishing protocols to have the same kind of properties and
really get get the web of revolution happening across the
Internet and create. And this is like making a truly
free market, right? Because you don't, you can't
just only have a freeway of sending money.
You also need free communication, you know, free
publishing, all of that so that people can coordinate and come
to consensus on this. I, I would love it actually, if
you can go a bit more into depth on, you know, the kind of like
use cases that you feel like, you know, because you're saying,
OK, this is the kind of thing that, you know, could really get
us to like mass adoption and too much broader use cases and the
current sort of, you know, defy type thing.
Like, what are the use cases that you feel, you know, those
are really the things that are most powerful that could be
enabled by such a technology and that would really, you know, be
things that a lot of people would start.
Using that, you know today not using blockchain or maybe not
using blockchain for these particular types of problems.
Yeah, definitely. So I think that it would be
helpful to start with the actual use case, right.
So imagine you had a Discord like app that's completely
censorship resistant and permissionless.
So, you know, it's the imagine the UX is the same.
It's just Discord, except, you know, you don't have to trust
the Discord company while using it.
You can say whatever you want on it, start your own communities
on it. And you know, like, you know,
and basically just like create this whole, create all these
communities on this system that are sovereign and are user
focused. So let's just imagine an app
like that. So the societal impact of this
would be really big on because if we think about currently, how
can you get people to work together, There are basically
two ways. One is the kind of like a in a
private, informal volunteer basis way.
So I, I'm a person living in the US, you're living in China, he's
living in Russia. Let's go on GitHub and try to
write some code together, try to build something.
And this, this is one model. The other model is that this
fully regulated, very bureaucratic multinational
corporation where, you know, I have to like, you know, make
this whole legal structure, hire people, do something, some big
thing together. And it's all very complex and it
all very like it's really easily damaged or shut down by like
random like political or like societal differences.
So that's the current world. But if you have a truly
permissionless communication and community building tool, what
you can actually build, as an example, would be a
multinational borderless permission list collective of
people working on things that's properly governed and properly
incentivized. So imagine you can do votes on
this. I mean, Discord can do votes.
You can do votes on this. You can use this to control the
treasury, talk about things completely permissionlessly.
And you can access this app anywhere in the world.
You know, China can't block it. Iran can't block it.
Nobody can stop your money from flowing.
Nobody can see what you're doing on it.
So this will do to community building and Dow creation and
like coordination what you know Bitcoin did to money transfer.
So you could imagine people working on things like let's
say, let's archive all the books or let's, you know, share
whistle blower information or or do journalism in these
communities and it'll be both public, but also permission less
and organic. While currently we have a
dichotomy between if you want secure and permissionless and
kind of like outside the, it cannot be shut down.
It has to be low profile and private.
If you want public, then that's like very like bureaucratic and
regulated. If you have a, it's just this
one application will let you build a world where people can
make public but also permissionless collectives that
work and. Yeah, so the problem with
something like Discord today is like, OK, if you, I, I mean, I
guess so I guess one problem would be have you link the
Discord to something now, you know, on chain, like, you know,
we control a bunch of funds together, things like that,
right? So, so that's not the biggest
problem. I think the biggest problem is
that Discord is a centralized platform, right?
Like Discord sees everything you do, they can shut down a
community they don't like. And you know, also like if your
ISP doesn't like you accessing Discord, then you don't get to
access Discord. Like in China, it's quite
difficult to access Discord. So like, I think like it's not
really about the on chain. It's really about the software
itself. You know, what can you do if in
a in web 2 versus a truly permissionless application?
And so, so if you think about this permissionless Discord,
just like the actual Discord parts, let's forget about crypto
or blockchain. I think that'll really create
this very vibrant marketplace of ideas of coordination that
currently doesn't exist on the Internet.
We can really let people from all around the world join and
participate and do things that we can't currently just can't
do. And I think that what and and
the thing about mail is that to realize this kind of vision, you
need two things. First of all, you need a way of
actually combining decentralization, but also like
a centralized user experience, right?
Like the problem with decentralized messengers now is
that you got to like manually set up your servers and things
like that and you need to manually connect to them and
you're still trusting that particular server.
But with a with like clients in a blockchain like mail, you can
actually have a whole free market of different providers
you can pick from move your group between these things.
And I wrote a whole blog post on on this called like confederal
protocols, where I explore this concept where it is that we
start with a model that we know how to build, which is, which is
Federated message passing, which was used in like e-mail, used in
Matrix, used in XMPP. And we simply had a very simple
blocking layer to that. And we get like fully user
software and very decentralized and better user experience
because the whole thing becomes one namespace.
It's like Discord, you can search for servers, join them.
You have one username, you have like one identity.
Your identity is not bound to whatever server you pick.
And so you end up having the same user experience as a
centralized app, except it's permissionless.
All the incentives actually go to your community, not to
Discord. So imagine when you boost your
server, you're actually contributing to public goods for
your community. And it's censorship resistant
and like it, it's going to have better quality of service
because there's going to be a pure free market in the service
providers that provide hosting for these two communities.
So in because switching is basically 0 cost.
And so that's the kind of thing that Mel lets you build like
this kind of like much for your market for resources for
protocol infrastructure that let you build much better Internet
apps than with Web two or I guess with current Web 3
technology. So maybe you can go a bit into,
a little bit into the light client aspect here, because I
mean, light clients is something that, or is in crypto is always,
you know, everyone's always, you know, people understand like
kind of the, the importance of light clients, at least more or
less. I think.
What is, why is it so hard to have, for existing block chains
to have good live clients And like, what's the, you know,
what's the challenge around live clients?
And what do you, how do you do live clients and, and how come
they're so much more efficient? And, and maybe also kind of a
connected question. I mean, to me it seems like this
is something where actually there's a lot of innovation at
work at the moment that that goes into this kind of thing of
like, hey, have really efficient proofs of what happens on chain,
off chain, which is I guess like ZK proofs.
Do you feel like ZK proofs are kind of enable these properties
for like any block chain or is this?
Yeah, yeah. So maybe like talk a little bit
about like the kind of the role of like clients and how the
technical challenges around efficient like clients.
Yeah. So I think that like the thing
about like clients is that it is true that let's say if you're
wanting to build a like client for Ethereum, there's a ton of
technical challenges you have to overcome because Ethereum is a
complex protocol. You know, you need to somehow
prove that somebody correctly executed all of that and show it
to your like client. That is actually very difficult.
So how Mel? So the thing about Mel is that
it's not really dealing with the same problems as like clients
for existing L ones are dealing with the the the thing about
metal is that because we're making a new layer one, we can
design everything in a way that it's easy to prove to buy
clients. So, you know, there's a ton of
things that goes into that, like putting everything in Merkel
trees in a using a very simple UTXO model.
The upshot is that it's it actually turns out to be very
easy to prove to a lie client that we came to consensus on
this. This part of the state says this
without using ZK proofs. Now, of course teacher proofs
can compress this, but even without that, it's very
efficient. And I think that so, so this is
one part like how easy it is to actually prove the state.
The other part is actually like, I think that there's a lot of
awareness in this space that like clients are good.
But I think that what Mel really sees is why like, what can you
do with like clients? And I think that we're currently
in this blockchain space, we tend to think of like clients as
a scaling technique for, you know, like doing things like
cross chain things. It's really about how do you
make the blockchain better? But Mel's insight is that if you
have really, really good like so you just, it's not just enough
to have like clients. You need the like clients to,
for example, be very, very light and you know, allow them to, for
example, go offline for long periods of time without losing
security. You combine a lot of these
features. You have this like super powered
like lines, then you can build categorically different and much
bigger and better applications than what the blocking ecosystem
is focused on right now. So if you think about kind of
like this sort of decentralized Discord, let's just think about
the architecture of this. It's actually very simple.
You simply start with a system like Matrix and you put a
mapping between your username and which server you're on onto
the blockchain. So you know, for example,
currently maybe Brian Crane is at matrix.org, tomorrow it might
be at briancrane.com. You know, this mapping on chain
and in your actual like chat client, you look up this mapping
to see where, which server to contact to talk to this guy.
So it's literally just this very simple little thing on the
blockchain and you, you have to be able to look at that securely
with like lines. But after that, it's a
completely conventional traditional Internet system.
It's just a Federated chat system, just like Matrix or
e-mail. And so Mel's insight is that if
you have good like clients, you can start building things like
this and you can easily build full stack decentralized user
sovereign software by putting a little bit of things on the
blockchain and having every single user look at it.
And I think like, I think that's something that's hard even if
you have, let's say, if you're like clients, because if you're
like clients, for example, they have to be online all the time,
they're not that light. You know, other block chains
have similar caveats. So if you're like client, they,
they tend, even when they do have like clients, they tend to
not be optimized for this kind of use case because that's not
what they're thinking about when they're designing the light.
So that that means you can't build a system like this
practically on these other watchings.
But you cannot know and I think this is the key in section.
So in this example of the the discord like thing, so the thing
that you would put on chain, so you said a mapping of usernames.
So let's say, you know, crane the air for some sort of thing
like that. You'd you said the mapping of
usernames and servers you put on.
Can you explain that a little bit more?
Yeah, definitely. So, so let's just use e-mail as
an example, right? So currently you might have
crane bf@example.com and that's your identity.
So your identity is owned by example.com and this means that
you don't have a free market in providers.
If you switch to a different provider, then you don't keep
your identity. So this is the first problem.
So the first problem is that we you don't own your identity,
somebody else owns your identity.
The other problem is that end to end encryption is hard.
You might use PGP to encrypt your emails, but how are you?
How are people going to know your public key, right?
So, So what ends up happening is that you don't have good
encryption and you don't control your identity and basically the
the situations that the provider has sovereignty over.
They see everything they own. You don't own your own yourself
like example.com owns you. Now let's just add to this
e-mail system a very basic layer which is a mapping between crane
BF, like a global username, not crane bf@example.com.
So crane BF with an ENS like system map, map that to
example.com comma your public. So you put that on chain.
So, so, so here's here's what'll happen then.
Now when I want to talk to Crane BF, I just need to make send a
message to Crane BF and my chat client immediately knows which
server to contact and what public key to encrypt my message
with. So I meant send the message to
Crane BF and you get it. And you know, I don't have to
know your server or your public key and I don't have to trust
anybody else to tell it. It's trustlessly stored on the
blockchain. And I looked at it with my like
client. So I verified that information
myself. Now tomorrow, let's say
example.com becomes this draconian censorship machine.
They don't like you anymore, so you switch.
Great. I'm going to go to like foobar
dot XYZ. So all I need to do is register
an account at foobar crane DF at foobar dot XYZ, point my thing
to foobar dot XYZ and continue using the software.
I don't have to like my identity is not owned by example.com.
I'm just like they have to serve me.
I'm just their customer. I can go switch to anybody else.
So what this really means is that there's going to be like
free market in providers. You can switch with no cost and
the providers don't can't decrypt your messages.
All they're doing is offering storage and relaying services.
And if you don't like the server, you can switch to
somebody else. And so, so you have so
architecturally this is still e-mail.
It's literally just e-mail, but with this little on chain bit
that the clients look at. And but because of this, then
this whole system is user sovereign, end to end, encrypted
and honestly decentralized. And trust us, it's Web 3.
It's no longer Web 2 by the addition of this little piece of
piece on the block. So I think this is really what
Mel is all about. You can start building these
systems where you can sprinkle this like Web 3 Pixie dust on a
on a traditional Web one protocol and you get something
that's radically more secure, more user sovereign, more
decentralized. And this only works if the the
the kind of like off chain parts can compose with the on chain
parts securely using white clouds.
So we talked a bit about this thing of like basically the
communication and to sort of community aspect.
What What are the other use cases that you're most excited
about this technology enabling? Well, I think that The thing is
that it's going to compose like layer by layer, right?
Like if you think about how do humans interact, there's really
two big things. One is transactions.
I need to be able to send you money.
The other is communication. I need to talk to you.
Now, if we can talk to each other and send each other money,
we can do business and create value and create things.
So what mail is really about is building the infrastructure to
allow this kind of value creation that unlocks these
opportunities of people interacting and building things
that previously don't exist. So, you know, you could imagine
some DAO on this discord like thing comes up with some really
cool idea of some public good funding system, let's say, and
they they're operating that. Well, that's a use case that's
only enabled by mail, but it's not directly.
It's more like we have we build the infrastructure to let people
interact. And that's just like the how the
Internet works, right? The Internet doesn't, it's not
really like Riverside FM is a IPV 4 use case.
Well, technically it is, but it's not like IPV 4 is designed
so that, OK, one use case would be Riverside dot FM.
It's more like, it's such a general purpose liberating tool
that allows people to innovate systems like Riverside dot FM.
And you know, of course you can think of specific things you can
build on other than the Discord thing, for example, I've also
written blog post sketching out how you can build decentralized
incentivized MMO games on in this paradigm, How you can, you
can also build things like, you know, much better file storage
networks that are truly free market and not based on
tokenomics, unlike, you know, file queen, etcetera, but truly
based on you just pay your provider.
These are all things you can easily build within this whole
paradigm. And I think that we already know
how to innovate like this because it's just the Internet.
It's the whole Internet paradigm.
The only difference is that now with like clients, you can get
decentralized consensus on secure security critical things
whenever you need it. But once you have that, you
don't need to reinvent the wheel.
We know how to build Federated protocols.
We know how to build peer-to-peer file transfer
protocols. We know how to build web hosting
protocols. We know how to host HTTP
servers. We just need to compose those
with pieces that let us incentivize and decentralize
all. You know, one of the main things
that people do on block chains is, you know, smart contracts
and you know, Turing complete smart contracts and then build
all kinds of stuff on that. Is that something that mail, the
mail chain is also able to do or like what's your view on like
smart contracts? Well, I think there are
excellent abstraction for what they're used for right now,
which is Defy and making financial instruments.
I mean, Mel technically has terrain complete smart
contracts, even though it has a UTXO model.
So you could do it on layer one. But I would imagine in the Mel
ecosystem, most people would not be doing this in layer one.
It would be let's say on AZK roll up on Mel that is EVM
compatible. So that kind of thing would work
much better. So that's how I think about it.
I think it's a great tool as its job.
I don't think it should be the World Computer, and it shouldn't
be what defines Web 3. It's simple, one kind of
decentralized app that makes sense in the ecosystem.
Yeah. And it shouldn't be the world
computer because of like one, is it like scalability issues if
you try to put all the smart contracts on the chain?
Or it's also because you feel like just by having like
clients, you can do a lot more things that are, you know, off
chain where today you do it on train.
Like the whole reason why we feel like scalability is a
problem is because we have to do everything on chain.
So all we got to do, we got to somehow fit it in, right?
Mel's whole thing. And that's hard, right?
Like even if you have a very, very, very fast blockchain, you
still need to convince the whole world to this new paradigm,
right? Don't run servers, don't run
peer-to-peer nodes. Stuff all your logic on chain
and trust that the nodes on whatever blockchain will run it
for you. I mean, that's like how ICP was
trying to do it, for example. That's difficult like that.
I don't think that's like even if it could work, it's very
difficult. It requires rewriting the whole
Internet. Mell's approach is actually
that, you know, given that we have good like lines, why do we
need to do that? We can build our Internet
protocols the way people have done for decades.
We know how to do that in a scalable and sustainable way,
except that now we can make those things decentralized and
secure whenever we need to by reaching for the blockchain to
compose with Unchained logic whenever we need to, but not by
using the blotching as a world computer that the whole
ecosystem lives on. Now that's a paradigm that I
don't think generally works and has worked in the past.
One analogy I like to use is the Internet versus telecom before
the Internet. So telecom before the Internet
is basically this one world phone network approach.
The whole world was one integrated telecom system from
application to the infrastructure.
All the innovation happened on the base layer.
You know you'd want better quality phone calls.
Base layer, you want, you know, pagers so that you're a device
can buzz when you get a phone call.
That's the job for the base layer.
Everything requires infrastructure level base layer
improvements. Now what the Internet really
realized is that actually we can make the base layer composable,
simple and neutral. It's just a packet routing
layer. You know, it doesn't need to
have any features, it just needs to sit there and move stuff and,
you know, composed with other networks.
So it's actually decentralized in a way the Internet and then
we can leave as long we can allow anything to use it across
this telecom stock whenever they need to and then we're done,
right? Like market innovation takes
care of the rest. AT&T did not need to invent
every single website. And I think we need, we're going
to see something very similar in Web 3, which is that the early
paradigm of doing everything in the base layer, that's easy to
build out at first, but it really is inherently limiting
because it means that all sorts of key innovations require
improving the base layer, like you're adding CK stuff,
improving throughput, you know, improving storage capacity.
And it's actually worse with box chains because every time you
change the base layer, it's governance and you run into the
issue of if you change a base layer all the time, is it even
decentralized? Or is it, you know, actually
controlled by the deaf team? But even ignoring that, right,
this is just architecturally like very slow and very like
limiting. If we can have like a stable
base layer that just sits there so that you can put things on it
that need global consensus and you innovate and build protocols
elsewhere, I think that's copying the success story of the
Internet that really took telecom to like unimaginable new
level by decoupling the base layer from the apps.
So I think like that's how I'm thinking about where mail is
going. And then so it's a, you know,
the thing mail that you're building here, it's a proof of
stake layer one. So let's talk about this a
little bit. So it's UTXO proof of sake base
layer one. So for example, for consensus,
how does the consensus work? Well, we use like a Byzantine
fault tolerant consensus protocol called Streamlet.
So I as far as I'm aware, we, we might be the only blockchain to
actually use that in a production system.
So Streamlet is a BFT algorithm invented in 2020 that's actually
designed for pedagogy like, you know, teaching people how BFT
works. So it's a BFT protocol designed
to be as simple and easy to explain as possible.
And we chose that because we wanted we want our base layer to
be as simple and easy to explain and easy to implement as
possible. So we picked this kind of BFT
algorithm. I really suggest everyone read
the paper like of Streamline. It's surprise, it's shocking how
simple you can make a BFT algorithm.
Like it's basically as simple as Bitcoins consensus, except it's
proof of stake and it achieves finality.
So we need finality for good like clients so we we pets
stream. Yeah.
And and then if you, I mean a lot of people will be familiar
with tenement, you know which is I think sort of like the
generally also considered like you know a very simple BFT proof
stake system. So but stream that is even
simpler? Or like in what ways is it
simpler than something like tenement?
Well, I think it's kind of hard to explain.
It is just literally way simply like the paper is much shorter,
it's much more obvious after you read it how to implement it and
why it's correct. So it's actually built on top of
a lot of previous work, including Tendermint.
It's really the product of a lot of work done by the office of
that paper to really build the easiest to explain and implement
BFT algorithm. So yeah, like with Tendermint,
for example, there's the several rounds of voting and all of
that. You know, it's kind of tricky to
understand why that's that you need to do that and how to
implement it correctly. With Streamlet, it's much
easier. So it's also in Lineage.
I would say it's closer to like hot stuff and Casper BFT.
It's more like a kind of like a chain based BFT rather than a
voting based BFT. So like, but but that's like
more of a technical detail. But I like I think that it's by
far like the simplest BFT algorithm I've seen, and after I
implemented I realized its performance characteristics were
good enough for our use case, so we decided to use them.
OK. So yeah, so we have this simple
proof of stake BFT system. We also maybe we can talk about
the UTXO thing briefly. I mean UTXO of course you know,
everyone knows like Bitcoin uses UTXO, There are other chains,
right that have tried to do UTXO things for smart contracts.
But like what are the pros and cons between the sort of account
based model that Ethereum has and UTXO based model?
Well, how I'm thinking about it is that if you're trying to do
smart contracts, if you're trying to make an Ethereum
killer, don't use the Utxos. It's a bad idea.
Like that's, you know, like I don't think Utxos are the right
model If we're trying to do a basically an accounts based on
our contract model, we like it's trying to simulate that on your
UTXO is possible, but don't try that.
It's not a good idea. There are other blushes that
have tried that and I don't think it's a great idea.
Now, why did Malik use Utxos is precisely because it's trying to
do something very different from block chains like Imperium.
The the big advantage of the Utxel model that there's the
reason why Mel uses it is that it makes all the state and all
the data on chains structured rather than unstructured.
So if you think about, let's say on Ethereum, if you're building
a system like ENS, even if you have like clients, how do you
know what name you know creating the FS map to?
You have to call a contract and run EVM code, and that EVM code
accesses something in the state dynamically and tells you the
answer. That's just inherently very
complicated. If you have a like client, that
means many, many round trips to request a little pieces of data
your contract needs to execute. It means implementing a whole
EVM interpreter in your like client.
And all of this is because the on chain data in a smart
contract base model like account based model is legible to the on
chain code. It's not legible to somebody
just looking at the blockchain from the outside.
With the UTXO model that's very different because the actual
UTXO graph is structured, you can traverse it objectively
without running on chain code. So you can design your contract
to simply encode, let's say your mapping in the structure of the
UTXO graph. And then you can just look up
that structure, traverse it with a like client without running on
chain code, without diving into little pieces on chain.
So that's the number one reason why we use the QTXL model.
I think it's the best model if your main use case is to expose
data in a way legible to off chain like clients.
Because you can basically, I, I guess if I paraphrase it, if I
get it correctly, I can in Ethereum, basically because you,
you don't really, you know, you have different transactions and
you don't know what they like. You know, you sort of have to
know the state of the chain to know how that transaction
effects like other parts of the chain.
Yeah, exactly. It's not explicitly spelled out.
Yeah. Whereas here you could just
basically take the UTXOS that you know relate to a particular
username and then as long as you see those UTXOS then like you
can kind. Of yeah, and you can also trace
your history back, you see, see where they came from.
And you can use like on chain contracts to encode a shape in
it. Like for example, I actually
once wrote a paper there a long time ago of encoding a naming
system in the UTXO graph of Bitcoin.
So you literally can use the UTXO graph as like a binary
search tree and like build a tree and then you can, you know,
you can sell like what 01010 is one that means Brian, whatever.
And then that's where you're binding.
So you can do tricks like this because the UTML graph is
structured data, not unstructured data.
I mean, I guess one thing that it could be interesting to go
into, but I don't know if if that's where we should go now.
I know you also have this sort of low volatility assets, but I
don't know if you should go there or if if there's some
other parts of the system that you think are more important to
explain now. Well, I think that like, I mean
that, that that might be interesting, but I feel like, I
feel like the most interesting thing about mail is not actually
kind of its individual technical parts, right?
Because the thing about mail is that I think it's really easy to
like misunderstand it a little bit as, OK, it has all these
cool parts, there is a lot of cool parts, It has a different
consensus, a different currency, etcetera.
But I think what's really cool about Mel is what it lets you
build, right? So that's why, for example,
right now we're actually focusing mostly on building a
rental, which is this off chain data and money transfer layer
that is built on Mel. And that'll really be the like
protocols like a Rendell are actually where the ecosystem is
going to be built around, not like apps building on layer one
where like people running nodes on layer one.
So I think like that's an interesting thing about Mallory.
It has a lot of cool parts, but I think like what explains the
design decisions I make with all these parts?
Is this overall idea that how do you make a blocking that you can
use to build systems like, you know, a Rendell, like you know
the discord thing I mentioned so.
Yeah, so let's talk about air Rendall.
What's Air Rendall? Well, how so Air Rendall is
like, if you think about, OK, so the I think air Rendall can be
explained as like this way, which is like, it's a network
that you can use to transfer money and data both quickly and
privately. So you can think of it as kind
of like Tor plus Lightning Network.
So you know, you can plug your app back into it and send data
across or send money across and it's all off chain and fast
there there. But then there's two big
differences between Air Brendel and Tor plus Lightning Network.
The first one is that the nodes are incentivized and the nodes
are incentivized not through like a deep end like token
system. It's actually very simple, which
is that whenever you use resources on a node, you pay
them. You pay them with this same
payment channel system. So for example, I send a set of
packet of data through you, your node, and I have to pay a price
to user nodes resources. And we actually negotiate this
price with each other. So it's a free market.
There's no like protocol that coordinates all these prices.
People find peers that they're willing to peer with app prices
they're willing to accept. And the second pillar is that
Air Brindle is the first peer-to-peer network designed to
be censorship resistant against ISPs.
And this is actually really unprecedent because we think
about censorship resistance a lot in Web 3.
But we typically mean the other nodes on the network cannot
censor, right? Like Monero nodes can't pick and
choose who gets through. We don't mean the ISP can't stop
you from using the protocol. They can't ban the whole
protocol. And this, this kind of
censorship resistant, I call band resistance, which is like
it's resistant to ISP banning the protocol.
And it's very difficult to do that in a decentralized setting.
But I think it's very important because, you know, we're, we're
trying to build permissionless assistance here, right?
We're not, we're not saying, OK, we just don't, we, we don't test
our bank, but we trust our ISP. That's not what we're trying to
do. We're trying to build permission
lists that and that means we need to be censorship persistent
against our ISP as well. And so Arundel uses a lot of
technology I've developed for GEF, you know, my VPN project, a
lot of the research I've done in traffic obfuscation, in
censorship persistence to build the world's first decentralized
ISP, censorship persistent on transportation network.
So that's really what air rental is, is at a high level.
And that's only possible because we can build on top of smell
like, you know, the micro payments go on payment channels,
kind of like Lightning network, but settling on Mel.
And because Mel has much better light clients, we can do so
without forcing people to run heavyweight infrastructure.
You know, with Lightning networks, if you run the
Lightning node, it's basically a Bitcoin full node.
It's very difficult to do so on your phone, for example.
But with mail, you can use build, build payment channel
networks where the clients are very lightweight and can really
fit in every single endpoint. So that's just like one example
of how we use mail, but basically the incentive system
and the kind of like security systems, they're all built on
top of mail likewise. What's the state of the project
now? Like what, what have you built
and like where are you sort of in in the road map to making
this happen? Well, like currently for AR
rental, we're currently in an alphabet kind of situation.
We have like a few dozen nodes running, a lot of them run by
community members and overall like we're that's the current
focus of our development. So we're quickly iterating upon
of it upon it. We plan to launch the air rental
network into production later this year.
And then launching a rendall into production.
That means. But that's that comes before
because the male proof of state chain is not in production yet.
Well, the male proof of state has a def net right?
That has been public for several years.
So the initial version of a Rendall would run on the male
def net, but eventually we're going to upgrade that dev net
into a main net. So like a dev net, what wouldn't
be shut down, it would just be relabeled as the main net once
it's ready? And what's the what's the sort
of difference between the dev net and the point when it
becomes a main net? Well, I think the biggest
difference is that right now we run all the validators, we
nobody else has any tokens like. So that's the main difference.
Once we actually decentralize the token ownership and allow
other people to learn validators and decentralize that, then it
becomes the main. Yeah.
OK, OK. And then what about like other
parties building applications on mail?
Like what's the state of that? Are there people building things
and like is it sort of is there a developer ecosystem already?
So we have a whole SDK for building things on mail, but
kind of in the overall road map of the project right now, is it
we're not we're not quite there yet with like getting people to
build an ecosystem. And the reason for this is
because, you know, if you think about a typical crypto layer,
what launching the dev net is like closer to the last step,
right? It's ready to develop.
With mail, that's not the case because the ecosystem is not
going to be built by people just running things on layer one.
It's really about people composing with low level
protocols within the ecosystem like AR rental.
So I think like the how we're going to do it is that we're
going to first launch AR rental with a big use case for AR
rental, which is actually GEF by VPN project will turn into a
front end for AR rental. So I actually move all of my
users from GET into the AR rental ecosystem by just
upgrading their software because the user experience is not going
to change. They're just going to be using a
Rendall. And that's like about, you know,
half a million or more daily active users.
They're going to be using this first big use case of a Rendall.
And then I think like developer communities and people building
on the system, they would naturally look to compose with
this ecosystem, all the revenue generation happening on a
Rendall, building new applications on a Rendall,
building other protocols like a Rendall, using it as a example.
So I think by that's the phase in which it makes sense to start
having applications build on this ecosystem, not when there's
only the layer one. This is kind of like the
Internet, right? Like if you only have IPV 4,
it's not really ready to build things on.
But once we had e-mail, once we had TCP IP, yeah, that's when
the developer ecosystem started for.
So I mean you mentioned the the VPN, right?
It's called GIF, so Arundel basically would would be able to
perform all of the the kind of functions that people currently
use the VPN for. Yes, and actually a lot more
than that, because with VPNs you can only access websites, right?
With Arundel, you're also able to host websites anonymously and
also browse other websites that people host on the Arundel
network and also send money to each other.
So it's like a general purpose communication and payment
network and then yeah, it's like a super set of what VPNs are
able to do. OK, so so you can host website
anonymously of course you know we were like aware of the
example of that is like Tor today, right where you can.
Yes, it's quite similar to the interface of Tor.
Yeah. And then is it also like, you
know, I think in your Tor website, you know, like a URL
like the hosting websites anonymously, they also wouldn't
have, you know, normal, it's not going to be like WW dot, like
whatever, but it's going to have its own domain names.
Yes, so in Torah for example, you have this long string of
characters dot and that encodes your public cheap.
And now the cool thing is that because we have male like
clients, we don't need to do that.
We can just be a short human readable name dot haven, which
is what everyone uses because, you know, we can store a naming
system then like as I, as I mentioned, that binds your name
to your public key. So we can actually have really
human readable domain names and website names in this ecosystem.
I mean, I guess this is is also a potential use case or
interesting use case will be kind of, you know, replacing or
competing with Tor. Yeah, absolutely.
I think that like ambitiously, I feel like air rental is going to
kill Tor, right. And the reason is because like
it's more decentralized because there's no like central
directory server. It's also way better
incentivized because if you actually serve the network, you
get the market rate of like what people are willing to pay you.
The problem with Tor is that it's all volunteer run, which
means that the only people running it are basically people
with way too much money, which are basically spy agencies.
And like, because why would anybody else actually do this
for free? It's a lot of bandwidth, a lot
of risk. So like the, I think it'll,
it'll definitely have better performance than Tor because
it's also not going to be always overloaded because of this
incentive system. It also the the application
scope is much bigger than Tor because Tor is really just
focused on one particular kind of anonymity, while Arundel is
actually designed so that the user can select how much
anonymity they want. They can get Tor like anonymity,
they can get much better. Like Nim for example.
They can use mixed that delays to get much better anonymity.
They can also get very low anonymity for high performance.
They can just use this as a general purpose Internet and
only for ISP censorship resistance, not for anonymity.
And you can build like very high performance systems on it as
fast as like, you know, any other system.
So I think like it's really what air vendor is, is that it's
going to be this universal Internet layer that has the same
interface as the Internet. It's like a virtual network that
you can run any application you want.
So yeah, I think like that's I guess what Arundel is, it's
really doing. It's kind of like combining what
people already do with Tor with Nim with their regular Internet,
with other peer lip P2P. All of these protocols in this
one general purpose elegant abstraction.
Cool, cool. Well, let's maybe let's talk a
little bit about your low volatility kind of sable coin.
Why create something like that? Well, because I want
cryptocurrency. That's the short answer.
I mean, if you think about it, right, like why did people
invent Bitcoin? They wanted a non Fiat currency
like a unit of value, a like medium of exchange, a store like
and all of that, right? So The thing is that we tried
with Bitcoin, we tried with other crypto, it didn't work.
Every single one of them turned into a speculation token.
It's essentially a mean coin in disguise.
Nobody uses Bitcoin as the way they use dollars.
And so like, and the reason for that is because they all have
fixed supply and they, and you know, people's demand is
volatile, so the price has to be volatile.
And So what Mel is trying to build is I want to build an
actual cryptocurrency. I want to build something that's
trustless, that's decentralized, but also feels like a currency.
It's price shouldn't be too crazy, go up and down.
People should be mostly using it to pay for things, not speculate
on like it's going to go to the moon, right?
And that's the reason why it laid melt the currency.
And the objective here is that I, I don't want to I don't need
to make a stable point. I just need to make a coin
that's stable enough that it has a relatively state, but you can
do accounting in it, You can price tags it reasonably.
So you want the price to look something like U.S. dollar to
euro rather than U.S. dollar to Bitcoin.
And you also can't use oracles because that'll make it non
decentralized. And I realized there's nothing
else in the ecosystem like this. So I sat down and made made my
own design. And what's that design like?
Yeah. So the high level objective is
that I want to peg one Mel to this unit called the Dusk, the
day of sequential computation. So a day of sequential
computation is the cost of renting the fastest processor
core you can find and occupying it for a day.
So that's what a dusk is. So the interesting thing about
this metric is that it's one of the only metrics that have these
two properties. First of all, it's actually
stable in purchasing power over time.
So 20 years ago, renting the fastest computer back then for a
day cost about the same amount of money as right now renting
the fastest computer right now for a day.
In short, the fastest processor out there is about the same
price to rent at any given point in time.
So it's stable. The second thing is that it's
trustlessly measurable. And that's the really cool part,
which is that we do not need an Oracle to tell us how much money
this is. And this is because what we can
do is that we can design an auction on chain where we give
away some tokens and we say, give me proofs of sequential
work. So you can actually compute like
essentially A0 knowledge proof that you did a bunch of nested
hashes, which has to be done sequentially.
And then you can prove, OK, I did this many hashes in this
many hours, give me the reward. So what this really gives you is
two things. First of all, you get an
exchange rate between that token and how many hashes people are
willing to give up to get that token.
This is market based, right? You don't need the Oracle for
this. You can basically you can get an
exchange rate between token and hashes and then by how fast
people are doing these proofs you can get an exchange rate
between hashes and time. So finally if you combine this,
you could get an exchange rate between your token and time and
then you can use this to drive a stable clean mechanism so that
roughly 1 token equals 24 hours. Does that make sense?
Yeah. But does that mean is it, does
it mean it's basically kind of like a proof of work as it's
still because like to get it, you, you do the, you do the
sequential computation and then you get a token.
So if I want to get a lot of tokens, I'm going to run a lot
of these CPUs each for a day. It's a, it's a little like it's
proof of work in that sense, right?
Like you use proof of work to mint these tokens, but it it's
not where the consensus comes from.
And I also don't expect there to be lots of people doing this.
The reason is because in in typical proof of work, the way
it works is that you're printing these tokens and people kind of
like divide up a thick supply by how much like proof of work they
do. And you know, if the token goes
up, then like people waste eat more and more power like
competing over this same pole of tokens with metals approaches
more like if you do this much computation, you're guaranteed
this much token. So what will happen is that this
will increase the supply of the tokens until it's no longer
profitable to mint, and then people will stop.
And so the minting is only used as an arbitrage mechanism to
keep the peg in check. It's not going to be profitable
most of the time. It's only profitable when the
protocol needs you to mint so that you push down the price.
But you're still going to have the case that like, I don't
know. So even if it's like roughly
stable, right, like it's someone else, it maybe it cost them, you
know, $1.00 to produce like one token, someone else.
It cost them like, you know, 90 cents or eighty cents or
something like that. So 80 cents guy's going to mint.
The $1.00 guy's not going to mint.
Right, right, right. And then the $0.80 guy is going
to mint, mint, mint, mint, mint until there's so many tokens
that the tokens worth $0.80 and then she's going to stop.
I mean, I guess you still have kind of the downside here that,
you know, if now male gets a lot of adoption, a lot of usage,
then it still means that a lot of basically it's similar
amount. Or I mean, let's say now the
male tone supply needs to get to like, you know, 5 billion
because of how much usage there is of the thing.
Then it still means that there's basically roughly $5 billion
worth of money will be spent, or you know, 4 1/2 or whatever to
get those, to get all those tokens in supply.
But that's the case with any system because if, if, if your
EMS market cap goes up by 5 billion, you got $5 billion of
USD going to like Kraken or other exchanges and it's the
same thing it. Was not quite the same thing,
you know, because if your price goes up like then, you know,
everyone's richer and like you didn't, you didn't have, if the
Ethereum price goes up and now it's 5 billion higher, OK,
there's looks a marginal buyer that will like bought at a
higher price, but you don't have to, you know, expend all of the
money to kind of account for the increase in the market count.
Yeah, that's true. That's true.
But like I think the thing about Mel is that anyway, like if you
actually read the paper where I describe it, it's not exactly
that you have to mint out every single mill.
It's more like this minting process establishes a price feed
for how much does a market value mill.
And if we need to print more mills, the protocol actually
prints more mills and you don't need like the amount of minting
doesn't increase substantial in that situation.
Like the minting people only indicate to the protocol that
hey, mail currently is overpriced, print more mails
where mail is currently underpriced, stop printing
mails. So that's really the only thing
that it indicates. And then the protocol prints
more mail and it sells the mail. Yes.
And it sells the mail in exchange for the other token or
say token. Yeah, right.
So basically in the case of how the mail supply increasing a
lot, does it mean let's say now it goes from zero to 5 billion,
then some of it will be I guess spent by people doing the
sequential computation and getting the mail, but some of it
will be people basically buying mail or like buying the same
token and exchanging it for mail?
Exactly, Yeah. So then it sort of also means
that a lot of the value of the growth of the sable coin or you
know the the mail market cap would be sort of absorbed by the
same token. Yeah, exactly.
So the SIM token is overall designed as the value accrual
token. So it also is where all the fees
go to. When you stake SIM and read
validators, you got fees that are all denominated in mail as
people use mail. So the more people use mail
like, the more value accrual accrues to SIM.
Tell us a bit more about SIM. What are the sort of properties
of the same token? Oh, that's a much less
interesting token. It's just a standard fixed
supply proof of state token or like there's nothing cool going
on there. And the reason why I separated
from Mal is really just because what's good for a proof of state
token is different from what's good from the currents.
Because for a proof of state token, you want it to be like
Accrue Valley, you want it to be fixed supply.
You want it to be like, if I own 1/3 of the network, I always own
1/3 of the network with money. You don't want them.
So it's kind of like, you know, shares in the bank versus
dollars, right? That's kind of the idea.
So I mean, a lot of proof of state tokens are inflationary,
right? For basically you're paying
block rewards to the to the validators, right?
For, you know, running infrastructure.
So if it's a fixed supply token, you don't do that here or like.
Yeah, I don't do that here because if you think about it,
right, like inflation's not free money, inflation's you're really
imposing a tax on everybody else who's holding the token, and you
can just express that as a fee or you don't need to like
inflate the token. So of course you need to design
the fee economy differently. But Mel's whole design ensures
that like this, the work that the, you know, validators put in
can be fairly compensated purely by transaction fees.
And I think that's a more transparent design.
It's also like more clear where the money is coming from.
And, you know, it's also like just like more free market,
right? Because with inflation, that's a
variable that, you know, you need to centrally tweak.
It might be too high, it might be too low.
The market can't correct that because it's baked into the
protocol. With fees, it's different,
right? Like if the demand goes up, the
fees goes up. If demand goes down, the fee
goes down. And it all scales as with the
actual social value of the Met Mel protocol.
You just have to design the right mechanism so that the
validators capture that. And I think I have successfully
done so. It's quite a different way we
charge fees from other block chains, but yeah.
Cool. Maybe else you want to talk
about? I don't know, there's, there's a
lot of other things, right, Like, for example, how like air
Brendal really ties into Mel's overall go to market and how
that'll work, right? Because I guess I touched on to
that, right, like gaff will turn into an air rental front end.
But I think like the bigger thing there is that once you
have a lot of users on air rental, then you have a ton of
demand for anonymous traffic relay on the air rental network.
That means that you had the listener.
If you write a node, you can actually get a lot of those, a
lot of that demand as revenue. And this is also really cool
because what this means is that Arundel gives you a free market
for satisfying people's demand for the free Internet.
And I also envision a world where this means that Internet
shutdowns and Internet censorship becomes impossible.
Because if, if let's say you're some country and you shut down
the like international Internet, then the price for transferring
air rental traffic in and out of the country would go up like
crazy. And if you have like a Starlink
or like a little cable across the, across the border, you're
going to make a ton of money by serving the air rental network.
So we're really, what air rental really does is that it uses the
invisible hand of the market to solve Internet censorship.
And I think that's the thing I find the coolest about air
rental. Cool.
Well, thank you so much Eric for coming on and and thanks for
walking us through it. I think that was really great
and I think gave a really great overview.
I do think this is one of the most yeah, just like regional
projects, right. So they're really trying to
think through things from from a sort of, you know, fundamental
design perspective of like what we actually want to do with
this. And then, yeah, so it's like so
many original things you came up with here.
So it's very exciting to see where this is going to go.
Yeah, definitely cool. If people want to get involved,
what's the best way to do so? Well, join at Discord, go to our
website mailproject.org. You can find all the links to
the right things there. So if you join at Discord, we
have a lot of live, lively discussions about research in
our protocol development. Just join the conversation.
Cool. Well, thanks so much, Eric.
It's really great to have you on.
You too. 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 podcasts. 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.tv/subscribe for
a full list of places where you can watch and listen.
And while you're there, be sure to sign up for the newsletter so
you get new episodes in your inbox as they're released.
If you want to interact with us guest 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. So thanks so much and we look
forward to being back next week.