Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Tech Talk: Radix Tech Updates & Insights
Recorded: Dec. 4, 2024 Duration: 1:04:51Space Recording
Full Transcription
Piers Ryddiard and CTO Russell Harvey. Guys I've sent you both a request so just feel
free to accept and hop on up the stage. We're just going to wait another few minutes. If
you guys can all share the spaces with your communities and followers that would be really
really helpful and we'll just give another three or so minutes.
Hello Piers. Hello. This is working. Yeah yeah you're working good. Good. Excellent. Thank
you very much. Have we got Russ yet? I think Russ is a way for some water and then he'll
be and he'll accept his invite. But yeah. Alrighty. So what's been going on Connor?
Well I've been busy just keeping the socials going. Literally I have to be chronically online
to actually do that stuff. You just absolutely neglect your own personal socials and you're
just focused on the brand stuff all the time. At the end of the day you'll end up not liking
socials. You know. Hi Russell. Hey I learned my lesson from last time when I didn't have
water. It's all the talking. Perfect. Okay well let's let's kick it off again. Like I said
we're here for another tech talk with Piers and Russell. So feel free to take it away guys.
I'll be in the back waiting for questions. I'll send them over in our channels and we'll
get to them at the very end. Okay. Excellent. Thank you very much Connor. Alrighty. So Russell,
I think we were sort of going backwards and forwards about what topics to do today. The
thing that we sort of landed on was it's worth doing a bit of a deeper dive into the asset
model in Radix and unlock some of the stories behind why we built the asset model the way
it is. And then I think one of the things that would be good to touch on a little bit is how
that sort of model overlaps with scalability from the point of view of how that interacts
with the Radix engine as well towards the end of the towards the end of the call. But let's start
off by talking about talking more broadly about what the problem that you have to solve when it comes to
defining assets on a public ledger is and like what the what the technology approach was to solving
those problems. Sure. And the I mean everything starts with what is what is an asset? You know,
what is people have many different definitions for it. And what is
can be most commonly thought of certainly in the crypto space is the people think of tokens,
they think of just it's a representation of value, probably you can move it around, maybe you can't,
but it's some signifier of something that has some reason to exist some value to it. And it's probably
usually thought of in terms of there are ones that are fungible, where, you know, one is much like
another within the same collection of the asset and non fungible, where each one is unique. And
it's kind of interesting how this came about and in smart contract platforms. You know, when you had
you move from Bitcoin, where really everything was conceived of just around as Bitcoin is the asset,
everything is around how that asset gets held and transferred around and how more is created and
that sort of thing. And then you had with Ethereum, that it's just a, you know, the basis of Ethereum is,
of course, that it's the world computer, and it wasn't created, unlike Bitcoin specifically for,
we're, we're going to be pushing tokens around, right, pushing assets around.
And of course, very quickly, there came to be, you know, the ERC20 standards basically said, look,
we can do something that has an asset like behavior, a smart contract that says, I'm just
going to have a list of balances, those balances are held by addresses. And if I get a request
from that address that says, hey, go move my, my, my balance to this other address, I will do that on
their behalf. And this, of course, kicked off. Far and away, the most common use case for
blockchains for DLTs is this, it is this moving tokens around and doing interesting things with
them, of course, became the killer app, so to speak, for these and almost all of the activity
that people care about on these networks relates to tokens and that sort of thing.
Yeah, and I think like, just, just to think about the, like, the reason for that is kind of obvious
now in hindsight, but what wasn't obvious at the inception of Ethereum, but this, this idea that
you can create a digital object that represents ownership of something that you can then pass
around is really, it obviously, so much of the global economy, so much of everyday people's lives
is related to sort of commerce and transactions, and especially when it comes to businesses and
finance. But the thing that I always think of, when I think about the Ethereum model,
or the analogy that comes to mind is, you know, the, the smart contract is kind of like a bank,
as in, if you think about, if you think about the smart contract, the smart contract is the thing that
contains the balance. And then you have an account that is authorized in that smart contract, and then
you have to go to the smart contract and ask the smart contract for the authorization to deal with
your balances. And just like a bank, your money can disappear from that smart contract, because there
are many things that can happen within it that are not necessarily adhering to the rules of the asset,
but are adhering to the rules of the interfaces to that smart contract, which are potentially badly
implemented or not implemented correctly, or there's some bug in the code or some malicious asset.
And so I sort of think of these, like, maybe, maybe a bank's not quite the right analogy, but it kind
of like, it fits in my head, as like, my wallet doesn't contain the asset. But I have, I have this
authorization key, and I can log into the smart contract. And I can say to the smart contract, hey,
I want you to move this balance that you control from this key to this key, which is kind of like
a bank, like it is, it is quite bank-like in its, in its, in its conceptualization.
And it's, you've hit upon the key thing that when we were getting to sign it, we said, this is not the
way things should be. People think in terms of, you know, I have two ETH, and it's sitting here in my
account here. There is no such thing as a, as an obvious, like, oh, this is one ETH, and it's moved
around, right? It's all just, it's kind of emergent, this thing that, oh, I have two ETH. What it means
is, I picked a bad example. Let's pick an ERC-20 contract. In the case of, I have USDC, let's say.
The one example, right. But even still, it doesn't entirely too discipline. But if we think of USDC,
for example, you think of, I have two USDC here. It's, that's not the case at all. It's just on
this balance sheet associated with this address, there is a number two. And this, the cracks in
this, in the way things work like this, this is where it works pretty much everywhere. There are
some exceptions to that, like the, the move VM-based ones, but we can talk about that later.
This works fine for things like, well, you and I both want to deal in USDC, and I want
to go send you for USDC, I'll tell the smart contract, you get it, and so forth. This is
a bit of a problem of, well, I want to do something besides just what's directly possible with that,
you know, that send interface of, I would like to, I want to do something with a smart contract.
And this gets us into these other powerful use cases of it, we get into things like, well,
I'm not going to be the one taking action all the time, but it is mine. So I have to go give a spend
allowance to some other address to say this, this other address is also allowed to access my balance.
And I can set limits on that. But every time I do that, of course, I need to do a new transaction
to update that smart contract of what the permissions are. And this has famously led to,
of course, all applications that need access to do things on your behalf, rather than causing you to
spend every time on a new transaction. They just ask for permission in perpetuity to go spend any
amount on your behalf. So you're not hassled every time you interact with it.
And this, of course, has led to any number of, whether through malice or through just a bug existing
or something like that with people's wallets being drained by some contract having the permission
to spend out of there. There's also the, the problem of
ownership is tied completely to there's just the single address notion. There's nothing of I have, well,
what if I have a smart contract, and I have a bunch of different, I have some US, USDC for this and some
USDC for this other thing. All that sort of tracking has to be done because USDC is not itself a thing that is
contained within that smart contract that could, that bit I have that wants to organize it.
That's just on a separate contract, the USDC contract itself. I have to manage all that myself
within my own custom smart contracts, try to properly segregate the different bits of USDC it
owns and who they're allocated to. This certainly leads to a, a philosophy throughout
all these other networks that it is very much in the, everything is based on interfaces. So you say,
what is a token? Well, it's anything that corresponds to this interface. It has, you know,
a send method and a mint and the burnout sort of thing. Well, that's a token. And so
by leaving up the implementation of that interface to all these different people that to say,
you define it yourself, code rules, whatever send does, you must have a send method. It must
correspond to this, this signature of what parameters it takes. And it's kind of crazy to me
that that is what is seen as a token when I can implement send and make it do anything I want,
as long as it corresponds to this expected signature. Yeah. And you can do all kinds of
games that way. I think one of the sort of like interesting starting points philosophically
here for me is like, is the protocol, the interface
to your ownership or as a smart contract, the interface to your ownership. And it it's,
it's a, I know these things like sound super abstract and like almost and esoteric, but it's,
it's sort of getting to the crux of like, what are these public ledgers for? And if the,
if the underlying point of these public ledgers is the concept of, is the concept of ownership and
control, which is essentially what the purpose of a public ledger is, it provides you to be able to
hold digital assets and have control, direct control over those digital assets. And the more direct
that control is, the more safe those assets are. And the, like the starting sin essentially of the
Turing of the like Turing complete, but no ledger primitive point was essentially giving up the
philosophy of what the point of a public ledger was. But I mean, that's not, again, that's not really
to throw stones at Ethereum. Ethereum was, um, we Ethereum. I mean, I remember when I was very early
in Ethereum, we weren't really sure what Ethereum was for. Like it was the, it was just, Hey, now you
can build these unstoppable, uh, these unstoppable applications. And like, that could be, that could
have any number of applications, any number of uses, but like, as, as we've gone, as, as the space
has matured, it's been clear that, that the need, that there is an underlying primitive here, which is the
concept of ownership. And the protocol itself, the layer one itself, the more natively the concept of
ownership is defined by the protocol, the closer you get to an underlying protocol. Like if you think of
the internet and TCP IP, you have this concept of the data packet and the data packet is the, it is the
fundamental building block of the internet upon which everything else is built. And, um, I, I think
that was really one of the core starting points of the, of the design and philosophy of Radix was like,
no, there are some things that are intrinsic to the point of a public ledger and they should be as close
to, uh, as close to universal in the protocol, uh, and be considered like primitives of the protocol. And
then on top of that, you can build, you can build functionality for applications and functionality for
utility and functionality for all of the other stuff, but you want it to be more like the internet in its
primitives than, uh, just like building something atop a server and running an application that is on top of
that server.
Yeah. And I think we should just go in then to the, you know, how we thought about this. Cause that's the,
the launching point for that is we said that we're going to be dogmatic about this, that the point of
the, the, the, the useful thing that everyone wants to do is about this ownership and movement of assets and
managing these assets that are going around. And let's focus on that. Let's make that what the network's about. And of
course it is Turing complete. You can do anything you want, but we put the stake in the ground and said,
look, we want to be good at something. What we're going to be good at, what's going to be easy to do,
what's going to be the network's strength is this, a strong notion of how assets work, make it easy to
use them, make it safe to handle them and make, uh, design everything around this concept of the interesting
things that people want to do on a network involve assets.
And this seems kind of obvious at this point, obviously this is where everything has gone, but, uh,
it's, it's, it's continually surprising to me that so many networks stayed down the road of,
even after a point of recognizing that what would people wanted to do was
things with assets, moving tokens around doing is that they kept with this model of, um, an ERC 20 type
of model for everything. And we came at the problem and said, look, an asset has to be a network primitive.
It has to be a thing that you don't come in thinking I'm going to write a smart contract.
And because it behaves in a way that's kind of lets you do some asset like things, that that is what an
asset is on the system. That was from a very early point, a core decision that we had to have at
minimum. There must be this piece of state that represents an asset with certain characteristics that
can be concretely owned by something that can move around independently of other versions of that asset.
We went through many, many, many, uh, iterations of, from that starting point, what else defines an asset.
And for those who were with us, uh, after the Olympia launch, and we did the, the development of
the Alexandria, uh, effort, which was never a, you know, production network. It was always just a test case.
It plays to test out ideas of what would ultimately become Babylon, where we introduce the powerful resource
model and all this assets being called resources on Braddix for those that are new to the project.
Uh, we did a very iterative process where we started with simple things like, well,
you, you know, that assets, we think of them as fungible and non-fungible and fungible things
should be able to be, have some simple flags on, can they be transferred? Who can mint them? Who can
burn them? That sort of thing. And then we tested them out with developers and see what people were
building and we built, we dog fooded things ourselves and ran through notions. And what we eventually
arrived at was this concept that if you think in a, a certain set of behaviors that may be possible
for an asset, we, we, we've now landed on these kinds of universal primitives that we could turn into a
state machine. We could turn into a very predictable system defined way in which, um, anything that you
attempt to do with an asset is trying to trigger a state change that we can set the rules on what
govern that state change. For example, if I have a, I have a Zombo, I have a Zombo token sitting in a
vault in my component and I try to take it from that vault. Well, that's a state change. It's no
longer sitting in the vault and Reddick's terms, we're going to take it and put it into a bucket,
which is where assets exist when they're kind of in transit. All right, well, before I put it into
that bucket, I can now go set some rules here. I can say, well, what, what must, what must be true?
What conditions must be true before I allow you to take it from the bucket? And from a traditional,
what you think of as a usual asset, that condition is simply always allow this. There's never any
restriction on taking it out of the bucket, but by the same, excuse me, taking it out of the vault,
but by the same logic, I could also say, well, what if I want to have it that only, you're only allowed
to withdraw it when certain conditions are met. It might be something like, look, I want to be able to
say I could make it. So once, uh, a token lands somewhere, it can never be withdrawn again. I can set
that rule to be deny all forever. You're never allowed to pull it out. This, uh, actually we'll
get into that a bit later on how we, this, this basically functions as what is a soul bound token,
which, you know, made a bunch of waves of Ethereum and kind of was a, a so what on Radix. Um, but I can
also do things that say like, well, maybe only certain actors are allowed to take a token from a vault
and you have to have some rule as met for that. And then I can also say by the same,
by the same set of rules, I can also say, look, this world doesn't have to be static forever.
I can allow the creator of the token, even though it is the system itself that is, um,
setting the rules, excuse me, setting the common behaviors of all tokens.
The developer who's creating their one for their specific needs says, look for this token,
I want the withdrawal rule to be this, but I also want to be able to change that withdrawal
rule in the future. And I can set different conditions on whether, um, you know, what,
what requirements are allowed. I need this signature or these two parties to agree
before I can change the withdrawal rule to something else. So tokens can change their behavior over time.
And then we, we looked at what are all these things that cause interesting state transitions,
things like withdrawing, things like depositing, uh, minting more supply, burning supply,
what we call recalling, taking it from a certain place where you're not the direct, uh, immediate
owner of it, but you want to do a direct ownership transfer, freezing them in place in an individual
vault rather than being, um, talking about the entire supply, but taking it in an individual
vault that you want to say restrict movement into. And by exposing all these state transition
rules to the developers, we wind up with a pattern where you can really achieve all the scenarios you
are interested in for powerful programmable tokens without having to resort to
write a smart contract that defines all this stuff. You can set rules up that allow the different state
transitions. So I can control who's doing withdrawing, depositing, that sort of stuff. And if I have
specialty behavior, I can have separate business logic in a smart contract that is separate from
the token that allows things on how are those rules changed. And when do I produce say approvals to do
things like if I want to have a limited withdrawal token. And this was the, the thing that I think was the
biggest mind shift and for people coming in and developing, and we really knew we had something on
our hands here where time after time people would come in to go play with Radix and they came from
usually Ethereum, but, but many other places as well and would always start with this. I'm writing a smoke,
I'm writing a token contract and they would always get into how do I implement this or that into my token.
And it was always this mindset of what is, what is the use case you're trying to solve and getting
them to split their thinking between there's the asset primitive, which needs to
behave in a way that is the system standard way. And you just ask the system for the configuration you
want for it. And then putting all your business logic separate from that. And what that gives us is
complete predictability of behavior without anybody ever having to
have the burden of before I can interact with an asset safely, I need to go review this smart contract,
or I need someone I trust to go review this smart contract and tell me if there's any gotchas here.
Does it behave in a, um, the way I'd think on sends and receives? Is there a way to restrict movement? All that
sort of stuff on Radix is completely transparent to on and off ledger tools. User wallets can just
show you before you interact with an asset. These are exactly the things that are possible and not
possible with it. And these are the rules that can be changed by people.
Yeah. And I think that this, this like sort of just going, going up a level to the conceptual
for a second. I think this is the, like, there was this, there was this period, um, in Radix,
while we were defining this where, um, uh, Matt would continually be talking about objects and
actions, or he called them business objects and business actions. But, um, it was, it was this,
it was this idea that you are, uh, when you, when you think about all things that you own,
there are, there is, there is two components to it. There's the actual thing. And then there's
the rights associated with the thing. So let's say you have a, a share in a company and the share in
the company is, is, um, is always consistent. Like it is a, you know, it's a ordinary class share.
And then, and then you have the rights associated with that share and the rights associated with
the share could be, you know, your, your, um, your voting rights. It could be, you know, drag along,
tag along rights. It could be all of these things that are defined by the shareholders
subscription agreement or by the articles of association or whatever. But the share itself
doesn't change as an object. It's the, it's the rules associated with how you can use that object
and what can happen with that object that change. And you can, and you can basically map that into
everything in the physical world. It's much easier. You can say, I have a house, the house is an object,
but then, you know, if you're renting the house versus if you, if you bought the house,
if you bought the house, if you've leased the land, like all of these things change according to the
rights that you have or the actions that you can do according to the object. And it sort of all maps
across all elements of ownership. But if you start with this idea of going, there is a primitive concept
of an object that can be owned. And then there is a separate concept of all of the actions that can
be performed against that object. You now separate out the concept of ownership of objects, and then
the rules associated with how you can transfer or deal with that object.
And I don't think that, I think that very few people in, in the blockchain space, I think that
very few companies, um, when building smart contracts and things like this ever really think about the
separation of those two things. And like, why, why does that matter? It matters because of all the
the things that Russell's talking about, which is that you, you want the concept of
objects reversal. You want that to be completely and utterly, again, going back to this idea of you
have a, a, like a low level protocol that defines the concept of ownership. And then you have the
ability within smart contracts, um, and code to define the rules associated with how those objects can be
dealt with. But fundamentally the rights associated with the objects and the object itself are separate
ideas, separate things. They are conceptually separate in law. They're conceptually separate in, uh, in, in, in,
in physical reality, they're separate, they're, they're, they're, they're, they're separate, but we
always mush them together because every single contract you'll ever sign when you, when you buy a
house or when you buy some equity in a company or when you, uh, buy, you know, some, some physical
good, like if it's a complex physical good, all of those, those two concepts are sort of like pushed
together. So I don't think it's, I don't think it's, I don't think it's surprising that that's where
we ended up going as an industry as how we define an object because we go, oh, well, obviously the
object is the object plus the rules associated with the objects. And so we, we should put the
rules and the object together. But as soon as you do that, you have absolutely no standardization of
what an object is. And you have no way of reasoning from a computer science point of view, or from a
safety point of view, or from an interface point of view, what the, what the thing you're, you're,
you're touching is which part of it is the object and which part of it is the rights. And in radix,
those two things are entirely separated because that is actually the way to think about ownership
versus actions associated with an object that is owned. If you, would you bring them together
as it is elsewhere as a single thing, you, you break from how you draw things on a whiteboard.
You get the situation where Uniswap, what you're talking to is the LP token smart contracts,
right? That's, that's bananas. Nobody in a million years would have thought,
if you just came in and explained how it worked to somebody, you know, out of there, well, you have,
you have this thing and you, you know, put in tokens and you get out this thing that shows your
ownership. Nobody would then, after they're drawn on the whiteboard say, so actually, well, on the
whiteboard, it actually in implementation looks nothing like this. What you're doing is there's
the same thing that shows the balance of the LP is actually the thing that you're,
the definition of that is actually where the entire system is contained. And that's,
it's one of these things that it's, people have just accepted it. And there is this small set of
developers who have gotten their minds wired to think this way, and they're able to successfully
build smart contracts. Uh, but part of the reason why we've had such success with people who have
never even coded before coming in and building things is that on Radix, because of the way we've
done ownership and assets and this, this, this strong split between this business logic and the asset
itself, it works just like you draw it on the whiteboard. And so your implementation, you're not
stuck with these, oh, I have to, I have to get my brain out of the model of how it's on the whiteboard
and into how I implement it, because they're one and the same. Your, your brain's already in the right
mindset of, I'm going to have a thing that manages what happens when tokens come in and the
tokens are a separate thing. They're going to come in and out.
Could you like, I always think about, I always think about like the, like, sometimes I think that
these, these abstract concepts can end up getting to the point where people are like, yeah, but why
does this matter? Like what, what, what does this mean from the point of view of the industry? Like if
the industry's already adopted something like the EVM or the industry's already adopted this, like this,
this, this model, like why does, why does this matter and what advantage this is actually give
to Radix? And I often think of like the, the protocol wars back in the days of the internet,
like Gopher versus TCP IP and things like that. And like the importance of the right level of
standardization and abstraction, the right concept of primitives where you don't put too much into the
the low level concepts and you put it and you, but you allow this concept of standardization to
then proliferate. Like maybe you could talk about that from the point of view of this, but not just
from the point of view of why this matters for crypto, but like why this has always mattered in technology.
Yeah. Standardization is the key term. It is a hundred percent that
that the crypto industry as it is now has people are willing to put up with it
because there's money to be made and there are
at current industry size, it's, you know,
while it is growing, it is still very much a nascent industry. And you see time and time again that
large players, even medium sized players that aren't crypto first are very hesitant to enter. They're
very, very cautious. And
one of the big reasons for this is of course they are risk averse and they are wanting to
if you've ever worked in a large corporation,
you know, the difficulty of trying to sell up the chain, some novel way of doing things that they
can't wrap their head around the, the, how it works, that once you get down into the, um,
the folks most concerned about, uh, CYA, for lack of a better word for it, they want to make sure
they're doing the right thing and they're not going to be embarrassed by this in the future.
They want things to work in a way that's similar to something they already understand.
And the way things have evolved in crypto, your, if the industry continues along the way,
particularly the way ask behavior and this ownership very strongly tied to keys and the
objects and the code being tied as one thing, you, you will never get away from this concept that
everything is custom. Everything is bespoke. There is no single way to think about this that they can
map their heads to in the, in the traditional businesses that they go, okay, I understand how
it behaves. I believe in it. I can hire people for this easily because there's a standard way of doing
things and I can work at scale because much like with how the internet grew and gained popularity was
due to standards starting to win and those standards being things that you could rely upon. And
it is of course possible to try to, um, build successive layers ever higher and higher on things to try to
achieve these standards. As you realize the importance of them, you know, later on down the road,
and then try to freeze the things underneath those standards that you've now created and say, okay,
this set of things has been vetted to conform to the standard that you can behave in a predictable way.
You can limp along to that, which is what you see happening all over the place in, in crypto.
But, um, I mean, let's take the example of USDC circle has, of course, a bunch of networks that are
trying to say that we want to have USDC natively on our network. And they've put out a, do you recall
when this was, when they, when they first released kind of the look, here's the way USDC should be done.
If you want it to have come to your platform, I think, I think it was actually only earlier this
year. It was the, um, it was the, uh, USDC standard. Um, but yeah, I think it was only earlier this year
that that came out. And so, so fairly recent, and they basically said, look, that we're going to move
to a model of rather than, um, us implementing it everywhere. This, they realize, of course,
this doesn't scale as well as saying, look, here's how it should behave. You go build the thing.
Here are the rules that must adhere to. And then if you follow these rules, we can kind of vet that
you've done everything correctly. And we may choose to, you know, take over your USDC implementation.
And the creation of things like that will, of course, lead to others trying to say, look,
well, well, circle obviously has a lot of experience with this. They see the problems
that are faced by a, um, a very commonly a supplier of a very commonly used token. And what are the
things they run into with regulation, balancing those needs against the, you know, retail users
and permissionless use and all this sort of thing. And they, this type of thing will try to kick off
others trying to say, look, let's, let's sort of glom around this USDC standard as the way of doing
things. And by that, we can maybe get more things that behave in this way. We might be able to
sell to larger institutions. Well, if you can comprehend the USDC standard, we're like that.
And this is the way I see things going, um, and, and not getting out of that elsewhere, because
ultimately somebody has to go review to make sure this custom contract actually did successfully
implement the standard exactly and is without error and behaves exactly to spec. And this is the kind
of thing that when you're doing this in a, every individual implementation needs its own examination.
And that examination is not something that's trivial to do. It's tough to say that this is going to be,
you know, Oh, major league traded assets. No, this is, this is how it's going to work.
That you're going to have all these custom definitions of things that are going to have
to require each individual rigorous review and all these different places. And then companies will
freely adopt those and be comfortable with that at scale, much beyond the current way that we have
at the current crypto industry. When you embed that concept all the way down to the core primitives
of this, this is bedrock, this is fundamental, this predictability, this transparency, there is no need
to do custom review of minutia. The things that can be changed in the behavior are well known and well
defined in your review of how it behaves as the matter of a few minutes time rather than, you know,
weeks or months and, and, and still uncertainty on whether there is a bug that you missed in there.
I really don't see it that people will move into it at scale with any kind of speed without that. If we keep
trying to build higher and higher layers of interface definitions that then have to be scrutinized,
the speed at which crypto can be meaningfully adopted, particularly by
firms that don't want to have a very large crypto facing department that is staffed with incredibly
intelligent people who are very trustworthy, who we know are quite hard to hire for,
you're going to just see few players that are willing to get into it. And they're going to get into it very,
very cautiously and in small steps, because it's very hard to build up that trust in that the system
is going to work the way that you expect. There's not something where they can get
a single review of how things work and understand that other assets behave the exact same way of what
they've already understood about the way crypto assets work. It's a tough concept to try to put into words.
Yeah, I think it's one of those things that if you work at a large place, you just realize the
difficulty of trying to get approval and buy in for a thing where everything is bespoke,
everything is custom. There is no guarantee you can rely upon.
I think the thing I always think about is the way that the Ethereum standard systems work. So like
ERC-20 is a standard, ERC-721 is a standard. And ERC-20 is broken in a number of ways that have been
well known by the industry for a very long time. So like sort of the approval process is known to be
incredibly vulnerable to attack. There's like a bunch of methods within ERC-20 where like you'll
often see very prominent Ethereum developers rail about the fact that this method was designed in this
way. You see, you've seen many, many attempts for people to move away from the ERC-20 standard.
And there have been many proposals for improved ERC-20 and variations to ERC-20. But what has occurred
is that you have this inertia where that ERC-20 is the standard that all of the exchanges accept.
ERC-20 is the standard that all of the wallets accept. ERC-20 is the standard that all of the
sort of tokens that people understand accept. And so you have repeated use of a interface standard,
which is known to have vulnerabilities and is known to be not fit for purpose for a number of
specific use cases. And as a result, you're having to constantly design around this.
You wouldn't actually, like if you're starting from scratch, define a share of equity as an ERC-20
token. But because if you designed a new token standard with a new set of interfaces, it would
not be adopted by any of the infrastructure because the amount of inertia that you'd have to get over to
get all of the people to do that is just so large. Everyone is essentially continuing to use a broken
standard, even though everyone, including the, you know, sort of core people in the Ethereum
community and in the Ethereum Foundation are going, this is a bad standard. Like we shouldn't still be
using this standard. And when you're concentrating on interfaces, you have no good way of adjusting that
over time. When you concentrate on a framework for the specification of assets and then a
generalized model for authorizations and programmability of actions around that object,
you now have this way in which people can much more readily create the objects according to the
way that they need to behave. And those objects are still universally understood and accepted by
every single piece of infrastructure that is integrated with it. You don't have to change,
you don't have to adapt a new standard or adopt a new like understanding of how an interface works.
All of the, all of the ways in which you can then innovate from there are, are, are, are built,
built into the bedrock of the protocol. Um, and yeah, I agree with you. It is often hard to like
properly communicate this, which is why I, I often sort of like go for these analogies of like,
um, of what are you building? Are you building a, are you building a, a low level protocol? Like
where does, where does the concept of ownership and, um, and, uh, and objects that can be owned sit?
Does it sit as an intermediated concept in smart contracts or does it sit as a protocol primitive?
Um, I think what would be also interesting, cause you said, you know, you'd circle back to
the SWE model or the MOVE model or the Aptos model, like how has what MOVE has done differ from what
Ethereum has done and where have they, where have they, where have they learned lessons and where have
they still not learned these lessons that creates this, this issue of, um, essentially continuing to make
the same mistakes. Yeah. I mean, I think it's a different, it's, the approach was certainly one,
let's just talk about just MOVE in general. Um, they did definitely get onto this concept of,
I should be able to have this kind of discrete object, which can be owned, right? I mean,
the whole concept of MOVE was that you move it from one owner to another kind of thing. And that
there can be many of these objects which are, which categorically behave the same
and in, they can have discrete owners, but their behavior is defined in one place. And I think the
big difference is that they still left that behavior up to, well, you, you go right. It's
still, the concept is it's an interface. And if you, if you adhere to this interface of an ownable
thing and transferable thing, all that, then it's, it's kind of, well, it looks like a duck, it quacks
like a duck. It is this. And so a, a wallet piece of wallet software will recognize this as a, as a
token. And I think it's, it's certainly a step in the right direction in that case. And it's certainly
a much better thing for the purposes. If I want to do something where I need to have, there's a thousand
different definitions of sharding. Let's just call it that there's no one computer that, you know, all
transactions must be seen by it. It now gives me the possibility of, well, I could have one
zambo and send it to peers over here. And Matt can have one zambo and send it to Omar. And those two,
because those are discrete objects, there doesn't need to be one single place. That's where all
zambo movement is tracked, right? So it gives you that. That's certainly great. That's a big improvement
for that. But this is where it's a, a, it's that fundamental difference between there's a,
a philosophy that I think a lot of engineers have particularly
kind of coming out of school where you want to say anything's possible, code wins, right? Write
whatever logic you want. And as long as it meets this interface, you have a token. And that
it's easy to think that's the most powerful model. And
when you can say, look, I'm going to set some, some
limitations on where you're allowed to, to, to touch things and where you're allowed to just freely
define things, you actually wind up with something that is much more powerful outside of the system
you yourself has written. Where you have the, if you're interacting only with things that you've
written and you have whatever custom definition of logic you want, of course, you're the developer,
you understand it completely. And it's all fine to you. Why would you think of any limitations on this
thing that say this asset you're writing? But when you want the asset to be comprehended and used by
stuff you yourself didn't write, or you have a large organization and other teams want to write,
it is good that you have a concrete definition of behavior that now that it's not just that, oh,
it'll have an interface and I, the send method should do this, but they're up to write whatever
they want to the send method. If they want the send method to also mint a hundred more supply,
I'd send it somewhere. That's up to them. That's up to the developer code wins. That's a scary thing
for me to now adopt into my own system. If I don't have a close relationship with you, the developer
of that asset. And I, I would be much faster to accept your token, say my system that is generic,
if I know that send is send, and I know exactly what that does. And I can see if you've set any
restrictions on that, then I can see that it's not possible for you to have changed what the meaning
of send is. And more to the point, I can do all that, that reasoning. If I want to say, look, I
only have certain, I'm writing a, uh, an AMM and I only want to accept tokens that have no possibility
if anybody could ever lock the ability to withdraw it, because that would break my smart contract.
My smart contract on ledger can just go look at the asset and go, Hey, I can see that the rules are
set so that immutably there could never be an inability to withdraw. So I'm going to let you,
I've never even heard of this asset before. It doesn't matter. I'm going to let you instantiate
a new version of my AMM that adds that as one side of the pool, because it's safe for my users for
that to occur. Because I know that any token that went into the pool could be gotten back out.
Right. This is, it's, it's, it's enormous, the impact of this in how much trust you get
without having to go talk to the person who made the thing or go through a smart contract review.
And that's right. It's tremendously powerful for adoption. When I don't have to
go do research on how this token behaves, you can see the simplest form on Radix, which everybody can
experience is you will see time and time again, the telegram channel. Hey, I got sent the
flu asset. Is it safe for me to use it? That's insane. That is insane that it is. People are
trained to go, Hey, is it cool to touch this thing? Or will I lose money on it? You know,
on Radix, it's completely safe to do. There's no, there's absolutely you can, because it is a system
primitive object. There is no secret trap door that could possibly exist that would make it unsafe for
you to, Oh, I got some, some Zombo. I will, I will interact with that. I will send it on to peers,
or I will do something like that. Every user who gets trained up on that Radix has experienced just
the smallest slice of what a developer has to think about if they're going to allow an asset to interact
with something they've created to be part of their ecosystem that might have a very strong dependency
on how that asset behaves. And they don't want to think about, can this asset
break me or can it harm my users if I allow it into my ecosystem?
Yeah. And actually you can see this sort of like writ large, if you've ever had, if you ever have or had
dealings with custody providers with exchanges, um, any companies that have to deal with tokens at
volume, or if you, you know, you're, you're a wallet creator, you essentially, um, often have to
decide every single asset based on the code review of how that asset actually works
before you can add it to your platform. And that's, that's crazy. And it also is one of the
things that sort of stops, um, assets being added quickly to platforms and why it can still take
a surprisingly long time, even to get an ERC 20 added to a platform because of what you have to do to
to make sure that there is nothing non-standard or that there is nothing malicious in how it's been
defined. Um, and I always, I often think about like, you know, this idea of like, I can go quickly on my
own, but is, uh, you know, the, the, the old saying, if you want to go fast, um, go alone. If you want to
go far, go together. Like it's, it's sort of that idea writ large. You're going, look, every by, by
defining as a standard for how all of these things work and what an implementation looks like,
like there is a, there is a correct way of implementing these low level concepts and these
low level concept that that implementation is enshrined and enforced by the protocol.
You are then, you are then getting to a point where your, your predictability about what an
integration is going to look like becomes, becomes, it's, it no longer becomes a, a, a minefield.
It no longer becomes something that you have to worry about taking a risk. Can this harm me
to take it because the, the things that it can do are very transparent and there is no possibility
to doing anything else. Yeah. Um, we've only got a few minutes left. I wanted to briefly touch on like,
how does, how does, how does like pushing these concepts down into at these sort of like as core
primitives change the, the scalability of the system as well? I mean, certainly it's at minimum,
it's that, you know, that if we're talking about scalability, as far as transaction throughput,
you're saying that sort of thing. Yeah. Yeah. Transaction, transaction throughput. Yes. So how,
how this interacts with sharding and how this interacts with sort of processing and, and, and
the most important first concept is that because I can have a definition of behavior that is, um,
extraordinarily compact, and yet I can have many, um, instantiations of this that can have,
I can have, I can have a discrete state that can transfer independently and say, this is a Zombo
over here is 12 Zombo. And those, we know how Zombo behaves that's defined in what is this basically a,
you know, there's a, a, a native rule for behavior and the only thing modifications that are that are
like, okay, what are the rules around these specific state transitions? That can be, you could think of
this, every node can have, well, what's the definition for Zombo? That's extraordinarily compact.
There's only a few, um, some, some set of rules that are set on what is, what is strongly known by
all nodes is how do tokens behave. And all I have to check is the rules on that. I can have a copy of
that everywhere, but then I can have these discrete bits of Zombo all over the place. And then there's no need
for if I have an interaction with a smart contract with my Zombo token that a shard or a, you know,
a shard space in our terms that has no interest in that smart contract, even if it is tracking some
Zombo because it's present, because some, you know, there's an account address that it has,
that has some Zombo, it need not at all be involved in that transaction because that particular Zombo,
the one held by me that I'm going to go use with this component on ledger,
it has no knowledge of it and has no interest in because it hasn't interacted with things itself as
interesting. And we've left, this is one of the areas where we thought about this very, very deeply
on where should we set the controls on this, because there are certain concepts like,
it's interesting to know what's the supply of it, what's the total supply of a token.
If you have a sharded world where it may not be known at any point in time, like in order to get
what that total supply is, I have to basically interrogate the entire set of all nodes that to
get full knowledge of, okay, what's the current total supply. If that is critical for your
application, that you know that something like, for example, if I have, let's just take the Uniswap
example where I have, I need to know what the current supply of LP is. So I know if somebody comes in with
that, what percentage they do of the pool, I must have that information always up to date exactly at
this moment. You can choose to have that supply always trackable and that will have implications for
you when we move to a sharded world to know that all transactions which cause new LP to be minted or
LP to be burned will have to go through a single shard. But transactions which are just moving LP
between different parties but aren't changing the supply, those are free to occur in parallel unknown to
each other. And if that is unimportant to your token that you have the most up-to-date knowledge
about the total supply is, you can release that constraint. That can be a choice to say it's not
important that the supply be always up to the second, up to this transaction exactly accurate and then I
have no such pinch point on minting and burning. This is a really deep topic to try to cover in a few
minutes. But the fundamental thing is you must break away from this, I have a smart contract which
holds the balances. You have to break away from that in order to achieve scalability without getting
a bunch of trade-offs on how if you try to say separate the balance sheets many places, you wind
up with a whole host of new problems of trying to reconcile those things. And far and away the best
solution when anybody would come to doing it is let's have these, if these objects behave the same
way, let's them let them be discrete pieces of state and let those pieces of state move around
without having to go involve some central party.
And then when it comes to computation, like how does this, what are the advantages of doing it in this
way versus doing it? Of course in this case there is no smart contract interpretation at all.
You have, because they are system primitives, they are executed. I mean, in the case of Radix,
you know, it's not doing a WASM interpretation of a smart contract to try to determine how the thing
behaves. This is just running natively at full speed. And so you get enormous performance improvements
when you have something that can be and has been aggressively optimized and has run everywhere natively,
and not something that has to be run by an interpreter or some other higher layer, which just by its very
nature is going to run more slowly than something that is natively defined on the platform.
And, you know, like, you know, again, one of those things that you don't think about,
sort of the difference between building a proof of concept of an application and building a scalable
application. When you build a proof of concept, you know, it's running on a single machine or a single
server. And, you know, the cost per operation for computation doesn't matter. But if you're running it at
that massive scale, you know, sort of Amazon scale or Netflix scale or, you know, Google scale,
every single, the cost of every single computation matters from the point of view of how much a single
node can process and how much the entire network can process given a certain amount of processing power.
And it's sort of these, these, again, these thinking points that sort of overlap with what is a
primitive, and then how is that primitive executed? And how do you ensure that you have the most efficient
execution of that, that really goes into this idea, you know, that I keep coming back to of the
underpinning of Radix being the idea of a fundamental protocol that can, that can scale as much as possible,
and that that has been designed into sort of every single layer of the stack from, from the start,
not just from the point of view of what makes a developer's life easier, or what makes
integration easier, or what makes standardization for the concept of ecosystems easier, but also from
the point of view of how does that then interrelate with this idea of something that can be
universal and run everywhere?
Completely. And it's,
I think there's, of course, you can always say, well,
making something horizontally scalable is hugely important. So the thing that I can add more, I can
add more computers to the network and, and get overall throughput, but that's, it is not a panacea for
everything where you, you must also think about that. It is also important for how much, as you said, of,
how much can one computer process? What's the cost of one operation? And we have addressed at the beginning
with this model, part of that is we have a single thing that we can optimize in the, in the, the asset
primitive that pays enormous dividends on how much you can get through in operations in a, in a single computer.
And then when you pair that with the ability to horizontally scale, then you get this, you know, this, this
beautiful near linear scalability, which is of course the, you know, one of the tentpole
promises of Radix, that that can be achieved and will be achieved.
Cool. Well, I think we'll, we'll leave it there. Um, I hope that was interesting to everyone. Um,
before, before we go, Connor, was there any questions that you wanted to highlight?
Um, no questions that I can see on, uh, Twitter or Telegram. Um, but no, thank you very much for that, guys.
Thank you very much, uh, Connor. Thank you very much, Ross. Thank you everyone for listening.
See you all next time. See you all next time. Uh, there's another space on Friday with Dan and Adam.
So, uh, the announcement will be out for that probably tomorrow. Um, so we'll see you there.
Catch you all later, folks. Have a good night. Bye-bye. Thanks everyone.
I'm起來.
Bye.
Bye.
Bye-bye.
Bye.
Bye, bye.
Bye.
