Hello everyone. We're just going to wait around to get a few more people on the spaces.
I see that Josh is now a speaker and Russell you're now a speaker. Feel free to unmute at any point
now. Say hello. Let's see if my headphones hooked up correctly to the phone. Yeah I think
they're all good there. Successful test. I cannot believe this can only happen on mobile.
It's quite an iPhone. Josh how's it going? Good how's everybody? Good good. We're just going to
wait another few minutes just to get a few more people into the spaces and then we'll we'll go
from there. I see that JSpeak is here as well. Hello JSpeak. Nice to see you. Big fan of your
videos. So I think we'll just get going now as more people will just start to filter in.
So before we get started I'm going to try something risky and see if I can join from my
desktop as well just so I can read stuff. Yeah no worries. I'll read out comments as well
or flag them as we go along but let's get going. So hello everyone. I'm Connor the social media
manager here at RDXworks and today we've got a Tech Corner episode and we'll be discussing
two recent opinion articles on Swede Mooz VM. These were written up by Josh Primero,
head protocol architect at RDXworks and essentially in the first article Josh has highlighted four
key flaws in Swede's Mooz VM and then the second he goes into greater detail on how
that extension avoids these flaws and so on so I'll drop the articles in the comments if you
haven't already went over them. So this space will be a little bit more informal conversation
of Josh's points so if there are any questions throughout the conversation let us know and you
can ask at any point. Feel free to ask in the comments too and Josh or Russell will answer them.
So let's kick it off. Today we're here with Josh, head protocol architect and chief technology
officer Russell here at RDXworks. I'm sure you guys have a lot to go over so hand over to you
guys now. Sure and that we're actually going to broaden it a little bit to just talk design in
general and virtual machines and that sort of stuff so any questions about that are welcome.
This is tech corner not business corner so if we see wind finance we will of course get very angry.
And Josh, head protocol architect is that's a title but that's not what that's not what Josh
is. Josh is Josh is a systems guy and for those who don't know what a systems engineer is Josh
do you want to explain your view on what does a systems guy do? Oh yeah good question. I would
say systems is a lot about as opposed to say application programming systems. I really like
dealing with things like resource management not as in script or resources but more like
hardware resources and how sort of that interacts with software. In any system you're always going
to have a finite amount of hardware which you need to allocate to software and such a thing is
even more visible in say the blockchain where you've got very little let's say compute resources
memory resources which you need to somehow distribute across a lot of software that wants
to run on top of that. That's why I think blockchain was like super interesting to me.
But anyway yeah I would say yeah I come from mostly a operating systems background
and I really like the system a little stuff a lot.
How'd you get started? What was your first research into blockchain?
Blockchain. Yeah I'm not sure I think it was just I think it was the fact that
I guess throughout the 2010s kind of most of software was moving towards the direction of
you know web two apps a lot of web apps and not too many not too many more system things
that were too interesting to me. And so blockchain came around where again this whole resource
the hardware resources became finite again and all the system stuff became really interesting
again. Things like how do you write a VM? How do you write all these things in a much more efficient
way? And I guess that's sort of why yeah I kind of got drawn into it. I think it's also because
for those who don't know Josh, Josh's favorite thing to think about is abstractions.
It's always about what's the correct abstraction for everything and this is the perfect space for
that. So yeah it's a it's a philosophical thing. I think that's part of your core
your interest in systems. You think a lot about these different layers and what are the
abstractions that each and yeah yeah totally talk to each other. Yeah and if I could like maybe
steer the direction towards SUI this is one of the things I actually really liked about
SUI's VM and I guess move VM in general is that they've got very nice low level abstractions.
They're very simple and to a system guy like me it's very elegant really nice very easy to use
and honestly like when I was for kind of designing kind of what kind of system we would want to
we would want to write it looked very much like SUI, SUI's current product. I guess I'd have to
credit Yura said Matt for kind of steering the direction high level direction of it moving
towards more of a I guess I guess you would say product focused where you're rather than think of a
elegant abstraction at the low level we're really thinking about it from a user's point of view.
I guess a question for you Russ is how did this where did this sort of philosophy come about
and I guess your background around this sort of stuff. My entire career has been building stuff
that ultimately gets in front of users and wide populations and that sort of thing and so I've
always been of the mindset of it's cool to write features and things but ultimately you think of
who's going to use this thing and definitely I remember at my time arriving at the company we
were very much in getting features working mode and Matt and I were both very much in a well
you got to think of your you got to go do product discovery you got to build something and ship
something that people will want to use and that's where this all came from all the approach we took
was was basically going like look for a for a network like this a distributed network you can
theorize all sorts of different consumers but basically you can boil it down to you have
users who want to interact with the network in some way and you have developers who want to build
stuff on the network and you have to make sure that those two main categories of people have
a good experience what do you build to to make sure that they'll have a it'll be appealing to
them right when this is a place that has a lot of competition why should they come here and
of course we we settled on the like what is the what is the key thing that people want to do and
was all around assets it was all around assets everything that was making DLT interesting to
people outside of universities was movements of assets and doing interesting things with them so
we said let's let's be good at that that's a that's a core philosophy of product development is you
should pick the things you're going to do well the things you're going to be good at i think that's
one of radix's biggest differentiators is that we do we are dogmatic about that the important
scenarios are around visibility of assets ownership of assets movement of assets strong
guarantees around those things and we designed accordingly and i know you and i had a bunch of
wouldn't say it was arguments but it was it was a lot of spirited discussion of how important it
was to enshrine the the uh the resource model that we ended up with do you want to
remember when you're doing your um when you turned me on to all the research you've done into
finite state machines yeah yeah yeah i mean fsm's um i was if you remember i was i was quite uh
kind of obsessed with kind of the fsm model um back in the day as we were trying to figure out
well like what is how do you make sort of uh what is the model for making a safe assets um machine
essentially um and coming from the sort of an embedded systems background fsm's are usually
what you use to make very say like for example elevators or car car systems these have to be 100
reliable they usually use some sort of fsm um as an implementation because um given that fsm
you've got very reliable um uh safe properties um and i guess that whole fsm model um it can't
the realization and kind of i'm gonna make the transition from fsm how do we get to like more
of the rust model is that with fsm's um it was kind of this realization that fsm is sort of like a
movement of from one state to another state if you think of like um you know there's like graphs
of fsm's you're just basically moving like uh moving from one thing through a transition to
another thing and that was like that's actually sort of like what resources or assets kind of do
um and sort of that idea of movement then came about from this
and then this was actually before i even looked into knew about rust but i remember reading
things about rust and how they use this sort of move semantics and um that's sort of how that
whole thing started yeah when we were when we were doing the scripto syntax and like early
we were doing discoveries early early 2021 not even as much as late 2020 when we were
just writing syntax with nothing underneath it for how it would feel to do this kind of thing
yeah for pushing assets around and uh yeah at that time rust wasn't even in the conversation
it was just the syntax wound up mapping quite closely to what would be supported by rust
as we got a few months into it i remember right right right um yeah and it turned out i think
rust was even just starting to like become popular back then or maybe i'm just late to
the game but yeah it kind of came at exactly the right time um for things to kind of come together
yeah i remember when you proposed it i was like i've i've heard that that's a language but i
knew nothing about it at all so it was it was definitely it had it had just reached that point
of awareness of it was a thing you'd seen but uh yeah it was definitely familiar with it yeah
there that that strong ownership that rust has wound up meeting really nicely at what we were
trying to do and i remember the to get a little bit into um the relation to to to uh your article
on swi on the the object primitive which is too generic one of the things that we asked internally
actually was if we do this this fsm-based model for assets is it going to be
flexible enough to meet real use cases right this was a a concern we certainly had internally of can
you can you do all the interesting things you want to do right and i think back then i was
sort of proposing a similar model to suey where i wanted this very nice strong object primitive
um which kind of could do everything um and so as a system person i wouldn't really need to care
about you know what the application layer does it's i've done my job right as a system engineer
provided the primitive you could do everybody else can do what they want on top of me
yeah that's the big philosophical change we had if it's it's that's insufficient we can't just
be cool i've made a generic tool go do what you want it's to focus on what are the things that
people are going to want to do and that's a harder problem but that's our bet that it's a problem
worth solving yeah exactly and it's quite i guess it would i would say it's one of the big
differentiators of radix um because like for example ethereum's model is like very open right
like they essentially say this is just a cpu um turn completes and then everybody can
build anything on top of this um which makes it nice and generic allows people to kind of
explore the space for example d phi probably would have um they didn't the notion of d phi didn't
exist when the evm was first created um but then i guess there are also um downsides to this
approach as well yeah for sure i'd say the thing we constantly um had in discussions with um various
vendors we talked was they'll do something and they'll kind of go oh you could you could do that
on ethereum when we're explaining uh you know something we do well it's like of course you can
there's so many the space of things you can achieve is is tremendous but if you recognize
this is a good idea why hasn't it been achieved elsewhere it's of course because it's impractical
because the level of complexity is high and just having certain primitives baked in makes it so
there you can assume instant adoption of of those sort of things you don't have to go
propose a new interface change and try to seek adoption for it all that sort of thing so
one of the things we we settled on early was it wasn't about making the impossible possible it
was about making the impractical practical because there's so many great ideas in the d phi space
that it's just sort of like it's too woolly to try to get that working on the evm or something
like it where you're having to fully define everything and so we say we'll give you the
tools that take care of a lot of these basics for you and enable you to build more complex things
with the low level problems sorted out for you oh yeah i mean one of the one of the uh one of
the things i always kind of hear when i go around is like the evm could do it because it's like turn
complete and yeah i mean turn any turn complete language could essentially do um by definition
do anything any other turn complete language can do but it's kind of similar to saying that like
english is the same as greek right if they're both languages you could you could um you can express
everything with both languages but maybe one language it's easier to easier to use in
certain situations and i would say like in our situation we wanted to focus on you know d phi
acid movement that sort of stuff um yeah yeah well sort of like you could write anything in x86
assembly but it might just take you a really long time it'd be pretty error-prone yeah exactly so
let's let's take one from the the crowd i know connor said he posted one from earlier before we
even began um did the did the radix team look at move language before they designed scripto and
if so what year did you start looking at it was there ever a thought that move might be good enough
for radix's purpose we definitely had scripto syntax design going well before this i remember
the first time i looked at facebook published some stuff on move that we read when we were in
london doing design in late 2021 after olympia had had gone live um do you remember what your
thoughts were at the time when we were reading that uh some of the basics of move uh yeah i i
do remember looking into it um especially because since uh they're very similar to rust um and
i think we we didn't really ever think about using it just because because it's so baked in into the
bm layer um i kind of described this in my post a little bit whereas the bytecode where they
statically um um statically enforce these things um there wasn't much flexibility for us to kind of
try and um extend that bytecode um and we kind of we kind of had a quite a little bit different
model from um what move was um back then yeah i remember liking that it was that ownership was
important and things moving was important we definitely had uh these guys have the the
philosophy of stuff moving around from place to place to different owners is is the is one of the
core things you have to get right but um i definitely thought that at the time that the
way we were pushing towards the focus on assets being predefined was i was surprised that they
hadn't gone to that approach i remember because of the the claim that it was so important of this
this you know asset movement is the thing it's one of those things where it's
before crypto if you ask anyone i'm going to design a financial system
nobody on earth would have come up with oh you bake all the logic into a thing which is also
where we have the the balances like that the whole erc20 standard came about out of necessity
entire space has just sort of it's it's become de facto the way of doing things and it's just
it's just crazy nobody would ever whiteboard to that design um i think it's pretty early on we
settled on just that concept of like assets aren't going to have the logic is going to be all
just in these different state transitions right right and i mean if you look at if you even just
look at like regular finance right like all we all we think about is like there's this amount of
something i want to trade it for this amount of another thing it's never like any more logic than
really just basic asset movement right yeah right and when you have logic around like what's
allowed to happen that doesn't exist that doesn't move with the asset itself right it just it
doesn't make any kind of intuitive sense whatsoever but that's the pattern that's emerged and it's
one that we see constantly where people come in as new developers and they've been building on
ethereum or elsewhere and they they come straight into this notion of i want to write a token that
does all the following things how do i go right and this this mindset shift to your your your
asset is this predefined thing that has you have the ability to govern the rules around what what
what are the uh the state transitions that can happen and that's where your power comes from
and the flexibility of well what are the different things it could do it could be
taken um you know it could be frozen in place at this if if you want your asset to be behaved that
way you can restrict you can withdraw it or deposit it you can you know control the supply
and all those sort of things we're able to achieve with our model uh i remember one of the key
insights you had was the lack of knowledge of a resource in flight elsewhere this was an important
new concept do you want to talk about that a little lack of knowledge of resources buckets came about
there wasn't just a concept of basically i have a a resource that is an asset that's in transition
it's not owned by somebody this at this given moment right right right um yeah so i guess this
would be very much similar to like and i think this is what sort of makes radix different from
other blockchains that say they have native tokens um because there are the the concept of native
tokens are essentially a maybe a a token which has been already pre-implemented um has already
been done that's nothing new um and it's essentially just like a some i would say some
of that erc20 token where um it's an erc20 token implementation but it's just been predefined by
the network um the difference with us with with sort of radix and i would include move in this
is that we have the notion of the ability to um move ownership of state which does not exist in
a regular um vm type uh regular vm blockchain um and it's really that notion of i could move
ownership of let's say this resource to another thing um and and have uh and be able to do logic
around that um around the state that's sort of in transition like you were saying russ um so i
like i can i can essentially um i would say it's similar to like i've got my wallet with cash in it
rather than depositing it directly into the store's bank account i would pass it to the cash year and
and then the cash year would put it into um um their cash box and it's sort of this idea of this
transient bucket that can that can have logic as as it's before it gets persisted and that makes
for like a much more intuitive model um when programming because i don't need to think about
account balances i could just think about this um asset in flights and do logic around that
that's kind of a very roundabout way of saying uh describing our model but i think it's just
it's a lot easier to program than describe um yeah it is my method gets past a bucket of tokens
right and that you can just immediately start operating on it you don't have to think about
oh who's my caller and do i have permission to spend from their account and all this kind of
crazy stuff it's literally it's a very physical style model matt you know you were sort of
describing that uh the one that matt loves to use the physical analogy of going to a money changer
and all those interactions are the exact same way that interaction happens on radix and the
permissions all make intuitive sense on that kind of thing rather than the it's again our model of
the way you draw it on the whiteboard or the way you describe it in a physical analogy is exactly
the way it behaves right right exactly there's a sort of looks like a related question uh reading
there are many other platforms cardano sweet avalanche etc that proclaim having native assets
can we walk through the different shades of native and how is radix's model different in that regard
uh yeah i mean i think i just uh mentioned it um well i think there's one one of the flavors of
native you see a lot is i think um a lot of people say they have native assets because they
have some kind of system defined erc 20 type standard where they're saying you don't have
to deploy your own contract to get an erc 20 the system will instantiate one for you
but that's that's a common one that's used to say we have native assets but it is extraordinarily
different than our model where the asset really is a first-class primitive rather than a there's kind
of a a system blessed smart contract that says this will be the base used for for assets right
right um yeah and kind of following that up as well um so i think suey and move em
in general they have also have a input implementation um which they call their
native um asset um which does have move semantics i think the difference with radix is that
there can only ever be one um asset implementation um with radix um which is our kind of a our
resource um system um because we disallow um sort of that resource state machine from occurring for
for any arbitrary objects on our system um and so yeah like we because of that that's
um that notion of resources much more i'd say like baked in into our protocol
it's it's the the big difference if it's done any programming is the
most networks do a has a versus an is a model which is saying if you meet the following interface
you have a token like if you implement a send method you implement a burn method etc that sort
of thing then you have a token and when you take that approach you you open up the Wild West for
all the crazy stuff you can do directly in the token logic because again it's just now a piece
of code that happens to conform to an interface but you you lose that that guarantee of behavior
that safety if i know exactly what's going to happen if i um in in the case of of us you don't
have a token send you literally take it from a vault right but you know exactly how that's going
to behave there's no uncertainty as to how has this been this method been implemented underneath
is there some secret thing i need in order to be able to send it to somewhere else so so you can
have things like the the famous squid game coin where uh you know there was this this thing hidden
away in the code that made it so you couldn't even um send it to somewhere else without having some
other asset so it's the guarantees of behavior aren't just good for devs if this is a big part
of our thinking on remember the other big one is who's the user is going to use the network is
if if crypto is going to get out of the basement which it absolutely is not out of the basement yet
people are going to have to be able to understand whether they're
citizens or business entities or whatever how the tokens in front of them work without doing a bunch
of research if you have an asset you have to know that it's something you can rely upon the behavior
of that thing so that in my wallet and in off chain explorers that sort of stuff you can
understand the behavior of that thing without having a whole team of people whose whole job
is just to be investigating smart contract code to determine if there's any hidden gotchas on this
asset right right i was going to say actually around that that same thing that like theoretically
your guaranteed behavior um of these contracts because it is immutable code but practically
speaking nobody's ever going to really or or an end user is not really going to try and decipher
what this application code really is right um so you lose kind of that whole um that whole security
um of that you know just because like nobody's going to read evm code and try to decipher that
yeah it's it's one of those things that even the people who are sophisticated tend to just rely on
oh someone else thinks it's safe to interact with because who has the time realistically to go
through to look look through all these things and even so it could be easy to to miss a subtle bug
in it so another question can you open up the box with scalability written on it how does the
implementation of native assets relate to scalability i'll kick that directly over to you
yeah um i would say because we have a very um very strong constraints on what resources
are and what they can do um as they have no other behavior the state we need to store for each one
is very well known it's much more easy to scale um such a thing and i think i had a uh an example
of this in my second article where i mentioned um kind of using um sui's transferred object model
um and kind of taking that sort of idea and just use that for resources because essentially you're
just moving um uh an amount of some asset to a vault of another assets um and in this way you
can reduce contention because the receiver doesn't um the state of the receiver is not
unneeded um so i think um the fact that we do have um native resources and along with our
move semantics um is very important for when we start to scale out yeah and just just from the
simple thing of not having this long smart contract definition of every token which would
then have to be replicated for every single shard that has to deal with it many scalable
bottle is of course a nice savings there you're not going to have this everybody's got to be aware
of um this custom smart contract definition for every asset they can interact with all right
another question sui founders this week revealed they have the ability to make transactions where
both the sender and receiver are offline using radio networks for comms will this be possible
on radix too i don't know i need more details we we saw that thing it was sort of a tease i'm curious
what the limitations of that are but i'm i'm sure once we we see radio comms using it's this
using radio networks for comms i remember this ring from the question i remember that the tweet
i read was about uh uh just that sender and receiver are both offline the transfer can be
done safely i know we have a lot of questions about what are the pre-conditions for this
happening and what trust is required and and all that sort of thing but i think at this point we
need to wait for more details of how it works um and then we'd see one is it is it an interesting
thing to pursue and then how would that fit with the model i'm uh i think we're not at a point of
crypto adoption where that is that interesting of a use case at this point i could see in a future
where crypto is out of the basement that could become far more interesting it's one of those
things that i mean if you think we're not even ready for at the moment wide-scale adoption things
like point of sale terminals and that would certainly be a a bridge to cross long before
this in my mind but i'm curious to read how that works once they publish the details of it
sorry just offhand thinking like i would just be afraid of uh double spending by the the sender
of that thing because maybe it's off chain and they they could have some proof where it's not
connected to the network but then perhaps that the initial sender could um spend those funds
somewhere else without the other guy knowing that he's not going to receive it later on yeah i don't
know is this yeah i'm really curious i remember when we when we were um talking with layer zero
with the ceo brian was i just got the edge of a conversation he was talking about a some key that
can only be you can only sign one thing ever and i was you know we were going to sidetrack the
conversation for it but i was like i got to go learn about what this is it gets related to
something there maybe you set up some precondition of like this particular bit of state i'll be able
to transfer away but i can only sign once but i don't know i'm curious to see what the details are
do we have uh i'm not able to see questions here connor do we have any other questions um
um yeah i think you've covered all of them on the comment section but if anyone has any questions
that you'd like to ask josh or russell just put your hand up or drop them in the comments
so we'll get you up here we're waiting for a few to filter in i know one that uh
has come up a few times before is that we have this the radix the the engine design is very much
like an operating system style of model and you just want to talk a little bit about
where that came from and how you arrived at that when that's very much not the standard model in
crypto uh yeah sure um i think it came about sort of when we were talking about um you know this
the separation of business logic and assets um and
essentially came down to if these two things are different i want to be able to express my business
logic um as easy as possible and what what's the easiest way to do that through a turn complete
language um that's um well known by everybody um but then how do how do we include let's say
assets in the picture and sort of this idea of a um if you remember we talked about this a little bit
back in the past but sort of this analogy of i've got a cpu which can represent the way i express
my application logic running on a machine and then i sort of had this co-processor which um
which my application logic can interact with and would um would manage say the asset type logic
that i want um have constraints on to have uh to be able to express asset type things
um rather than um cpu turn complete cpu style expressions and so because of this sort of
the economy between cpu and then asset management asset movement um um kind of this model of uh
kind of building an operating system where you've got it's essentially the same model where we've
got the application running on top of wasm and that wasm also has a system calls which um allow
you to then manipulate the asset type logic those system calls trap into an operating system
where you can then um which then manages the logic of uh of these assets it probably has
done the same thing like three times in a row but uh but it's very much the traditional model where
it's it's all the learnings from security that have come about through years and years of operating
system development applying very intuitively just because you have this you know the application is
this untrusted space that that it's executing from and then you can apply our auth model
follows very much what you find in traditional um application building where you have this role
based access control and you have the the notion of i can look at is is is am i permitted you think
of like in a file system am i permitted to get a handle on this file am i allowed to write am i
allowed to read all this kind of stuff all those patterns wind up uh mapping over directly and
they're well studied and well understood patterns right i would also i would also add um that i think
as from a just a computing model people are very and sort of with radix's model where we want to
add standardization add all these things that help applications become better um you could
just think of like your browser is sort of your operating system into the web where they've got
sort of these protocols and standardizations which make the web browsing experience way better
rather than um just interacting at a TCP layer right um it's bringing all these things that
are important to the user um that's important and it is quite as opposed to like other VMs where
you know they're very low level and it's very generic radix has a much more fat stack in that
middle where we try and standardize and do a lot of things um similar to operating systems um yeah
that would kind of do on behalf of the user or the user
yeah and the the focus on sorry is of course then picking the
again we chose that it's about doing these this asset movement is the thing to focus on
and that will build those in and make those things easy to do even though of course people are still
free to build whatever it's just that if you're in anything that's managing assets you're going
to have a very easy time of it and the system's going to revive you with a lot of
shortcuts and a lot of strong guarantees about how those things work
um i'm just gonna uh feed in here we've got a speaker request from jspeak so i will just
accept that just now and we'll get you up here now you should be able to chat now
it's just connecting there we are take it away jspeak oh cool yeah so i don't know
if you guys can hear me but uh let me know if i'm coming through rocky or anything but
yeah when it does come to that uh point there russell i think um you know i think that uh i
think a lot about what you can do with uh with the need of asset approach especially with radix in
terms of the behaviors that you kind of have given in a default way and i just am uh i'm curious about
certain vms and their ability to for example cardano was mentioned earlier i think you guys
uh talked about this already a little bit but i just wanted to bring it up when it comes to i
guess the evolution of you know maybe these lower level vms or other vms is there's like
is there kind of a architectural like genesis to when you have to you know okay that's sort of
the end all be all or do these things evolve can you kind of explain your philosophy on on that
because to me it feels like that can um in in places like cardano where there's sort of
these native assets and maybe not with behaviors or some of the functions you can point out what's
different but they're with the plutus VM it's like is there things that developers and other
ecosystems can do to maybe uh retain competitiveness or is this kind of something that if you believe
the direction that you guys have taken is sort of uh going to open up a lot of possibilities that
should be opened up you have to go with it from day one yeah does that make any sense guys josh
and uh russell and thanks by the way for the space this is awesome it's definitely
people that that took a that didn't take a approach of the a very strong
primitive asset type would be in a very difficult position to adapt to it would certainly be into
you know a hard fork territory and and for many many ecosystems once you have
assets and smart contracts live you're pretty much stuck on doing continuing the way you're
going right it'd be an enormous architectural change so i don't feel this is the kind of thing
that you can sort of back into um you can change your model a little bit expanded a little bit
that sort of thing but it's very difficult to say i'm going to be suddenly incompatible with
everybody who's already deployed on my network right and so i think when it comes to
evolution of these things you're unless you thought very very carefully about having a
universal model you're going to be pretty much stuck with with what you started with
with some some minor changes on top and when we did the the model for what became resources we
really did a first principles things of just looking at forget how it's been done elsewhere
what is it that a token should do what are the universal things and this is out of that research
we came up with the model that we got and what we're discovering constantly is there'll be
take for example the um i forget now the number for the standard on ethereum for soulbound tokens
this is a big deal that's it's covering all this hype and we're going this is literally
automatically exists in a much more powerful form in our model because as part of the natural
definition of resources you can freeze them there should be is that yeah or like nobody can
freeze the things yeah oh yeah it should be the same restrict where it moves around otherwise
how can i ever have securities if we can't restrict how things can move around right
so yeah it's it's we keep coming into we love this is what we love to hear use cases from people
and making sure that we can always address like yeah this is how you how you'd achieve it in
radix and it's just a different way of thinking than how people achieve things when they just
bake whatever custom logic they want directly into a token contract
well can i just sorry josh would did you have anything to add there too
because i didn't want to you know hog the mic here you guys and by the way connor kick me off
whenever you're finished with me but uh i i've enjoyed this but josh did you have anything to
add because i did have a follow-up too for uh if if you know if i don't get kicked off by cotter
yeah go right ahead yeah i i mean i would say theoretically speaking
you could always any current vms could always add new opcodes that could include
the expression of sort of move semantics or some of some of the things that we've built into radix
practically speaking though um i i would consider almost close to impossible just because if you
start to inherit try and include other models now you're kind of damaging all the smart contracts
that were there previously that of the whole environment that's um um that you built for your
previous users um and um not to mention the risk you take in kind of changing models and
changing uh previous executions of uh of uh your bm um yeah think of off ledger tools even just
like wallets you see when there's some kind of new token standard on ethereum it might be published
but it's not adopted by many well then like it slowly trickles in and say metamask now recognizes
it and now it's sort of official at that point but it is this you can't uh assume instant
compatibility the way you can when we have our our resource model like ours where this it's it's
defined how these things are going to behave and all these different possibilities are already
accounted for and so that we don't have any of these worries of if we do elsewhere decide
other people are trying to add new functionality of things like oh we're going to add this soul
bound concept wallets have to be aware of this now and it's not always the case that you use
you might have a good idea but you can't get sufficient adoption for it one more thing to add
right one more thing to add is that if if new vms do add sort of um a new model you'll also need
like a new bridge that will somehow bridge the old model and the new model and that's more
complexity and yeah um there's just oh yeah that's a good point on that yeah like backwards
like almost backwards compatibility or something yeah can i can i just ask you guys this though
because i think your point was really interesting there uh towards the tail end rustle you know
when it when it occurred to me that you guys you know really thought about the properties of maybe
like a physical you know coin i think is mentioned in one of your blogs and and you know just even
above that too with some of these things i mean you can't really i guess you can put a physical
coin in the freezer but i don't think it's the same effect uh you know do you um do you expect
to run into a situation where your application layer sort of uh adds new behaviors or do you
kind of feel pretty confident and this has been like an ongoing thing i've been really analyzing
you guys i'm like i wonder uh i wonder how they feel about it do you feel really confident in the
preset behaviors there for like you know assets or do you think there will be in the near term or even
you know mid-term like situations that force you to um add additional behaviors or do you feel
pretty good about the ones that we got over on radix definitely feel good about them and in the
cases when we're we're holding up to the use cases we're presented both financial and defi i think the
only one that we don't have a uh a route for it i don't think there ever will be is if
for tokens that want to do some kind of of rebasing that is not a
um i want to i want to take this user's share of that they're holding this token i want to up
their token amount by 10 percent and some other user i want to down their amount they're holding
by five percent right that that type of manipulation is just antithetical to our
design of course we we would when you have a model where you just have basically a balance
sheet tracked somewhere it's very easy to do we think that's a a dangerous type of model
and other than that but that would that's one that we're we're happy to say that we we don't
support that kind of thing and if you wanted to achieve it through some business logic an
application layer you could you could do it with say making a token that you could recall from
where it is and you could like take it out of the user's balance and adjust it and deposit it back
to their account but this would be something that the user would be aware of this that this was
possible they'd see right they're like hey this this token can be recalled and then when they
would go if they were to go look into why that is they'd explain that oh we have this rebasing model
we can pull it away from you and change how much you have and give it back to you and that sort of
thing but other than that every scenario we encounter we're able to support and a lot of
the interesting business logic is properly separated from the asset itself like the rules
around when they twiddle the the the changes on say for a while this token is going to be
there's a pre-sale period and then after this it can't move anywhere and we're going to change it
so nobody can withdraw the token until six months have passed after which we're going to make it
public again and that can all be put into business logic at the application layer without having to
bake that notion directly into the token because again we don't feel it it makes doesn't make
sense to put that into the token itself yeah and josh would you have anything uh to add there or
or uh with yeah i don't know if you did but uh i had some comments additional so i didn't want to
hog the bike and get a getting caught or kick me off man i'm telling you i'm a hazard to the space
but josh would have yet to add uh feel free you know i mean i think russ kind of summed it up
pretty well um and anything that we're missing at the asset layer um could always be added um later
on um yeah well okay so i have two questions then like when it comes to the sort of radix engine
and i know that this space is also about move vm so i kind of want to i kind of want to give some
sort of uh some sort of light on that too in this question but when it comes to the process of adding
say a new behavior in the near term does that just require like val like 75 of validators to do a
network update or like what's the kind of thing if that was to occur i know that that's like uh
edge case kind of deal and then also with behaviors themselves is that a function in the um
move vm as well i think you guys mentioned that uh topic but are are these preset defined
behaviors of of like native assets a common stance there so those are my two for you guys
you want to go for the first one russ sure so the the first one if we wanted to do a
coordinated protocol update is how we handle the if there's going to be some change in the protocol
like there's say some new system behavior that is i mean officially you need 67 but we always
when releasing a coordinated protocol update we set a threshold higher than that of an expectation
of if this percentage of of stake worth of validators vote for the the if if they are ready
for the protocol update to occur we wait for that to be i think we usually target something like 75
but that's something we can change on a case by case basis and that's the usual seamless
up the network upgrades that we have we had on olympia and just did the first one on bamilon the
anemone protocol update was an example of that you want to tackle the the second josh yeah um
can you uh repeat that question i read j speak yeah yeah yeah so it's basically just uh a question
around is there a similar concept to behaviors on the like move bm i didn't quite understand
that from the um earlier part i think you guys were hinting at there being like a simp is there
like preset behaviors there or is this sort of different is this sort of a difference um yes so
move bm uh or at least sui's implementation i haven't looked too much into aptos um they have
they have their own say assets uh type um that's sort of their native token type um where they
they've implemented it um but that but the difference with theirs is that anybody can
create your own implementation of an asset type so it's not necessarily tied down to um sui's
um coin type and i think they have uh yeah they they've got a couple of these predefined structures
for uh resources oh okay yeah that answers that question for sure and then um i have yeah i kind
of you know i kind of had one last one just because i do spaces on uh on radix and stuff and
a guy uh who's in here uh black sheep actually he always says or at least he said at least once i
think that the magic was uh kind of nailing the uh the radix engine with with like serverless
in tandem and uh we talk about this uh almost like intangible flexibility between a user's
determinism of like what they receive and what they sign and i rustle or you know joshua i don't
know if you guys are catching my drift there there's sort of this thing that um comes up uh
around this sort of like signing of a transaction knowing what you're gonna receive but then some
flexibility of how that result gets delivered am i accurate when i'm you know speaking about
this stuff saying it like that or like how like where's the magic yeah can you kind of
just take the ball maybe let's let's back up a bit and talk about the why because the important
thing is to always focus on why is it this way and then we'll talk about how we got to that so
in traditional finance if i have some problem where oh my god my bank i logged into my bank
and there's there's less money there than there should be in my checking account or something
like that there's this authority you can appeal to right i can go call up the bank and it might
take a long time might even have to get lawyers involved but eventually there's some way to make
me whole again if an error was made and that's the the trust i'm having in the system is that
there is this this if something goes wrong some process will be followed and i'll be i'll be
made whole again in the decentralized space um how is it ever going to work when there isn't
this authority you can appeal to to go hey go wind back the clock change the history this was
this was a bug right this was uh i got hacked or something like that
because that's not something you can do in the decentralized space or it it occurs only in
things like the dow hack on ethereum where this was this very dramatic thing which still has been
you know there's another fork to this day because of people who didn't believe that should have been
done how are you ever going to get people to say i will i will use this i will trust this and not
the tiny tiny percentage of people that use crypto nowadays but to expand to more people
and the only thing we come up with is if there's no such authority you have to at least be
absolutely predictable you have to give someone all the same confidence they have when they say
go transfer money with zeal to my friend how do you get that in the crypto in the decentralized
space such that i can at least say all right if i slide the sign here what i expected to happen
will happen and that was the whole reasoning behind the approach that we made and so everything
was about how do we present to users in a non-overwhelming way expectations around what's going
to happen and let you have guarantees about some of those things and the the way that we chose to
do that to avoid overwhelming was to say ultimately we're deciding that the thing users will care
about most is what are the asset movements in and out of my account in a transaction and those are
the things that we choose to surface and we built into our transaction manifest our our transaction
model where you have the sequence of steps that happens the notion that you can make assertions
you can say at this point i gotta have 100 xrd else call it off and that the application that
proposes a transaction to you doesn't get to prevent you from adding those things the whole
model was the the application you're using can say i want these things to happen this contribution
to uniswap to happen and the wallet gets to decide okay you've given me a proposed transaction
i'm going to add my own guarantees so that my user knows that at the end of this thing i get
100 banana coin else call it off and that model is one that what you see everywhere else is there
they're they're grappling for a preview model where it's sort of saying hey i did a dry run
and this happened sound good two thumbs up sort of thing that's better than just blind
signing the hash for sure but as we've already seen it leads to gaming the preview then right
you can you can write things into you like to make a silly example you can have a smart contract
that says if block height modulo two equals one do this else do the do the nasty thing
and then if someone happens to preview it at a odd number block height then looks like what
she wanted to have happen happens then by the time they submit it they get a bad outcome because the
now that logic that's looking for an even numbered block height occurs and suddenly the user's money
is all gone so that was the whole philosophy was just in and this was part of that integrated stack
for defi that we always talk about is it's not just about providing the easy tools for the developer
it's giving it so the user has confidence not only in how things behave but also when they
sign something what's going to happen if i could add to that um from a technical point of view this
is like the difference between how static um how much of a static analysis can you do on say
transaction versus how dynamic is is execution um the more static it is the more the more by
definition the more information you can you can analyze about a transaction you're about to execute
so with like our transaction manifest um you can tell statically all the for example all the
components i'm going to call and this sort of thing um whereas in ethereum you're just calling
a single smart contract um that's basically all the information you can get um statically um
and yeah so the more static it is the more uh confidence you can have as a user that
the preview is going to be correct like Russ was saying um with ethereum you've got these
you could you could do these previews um but you're never exactly sure if it's going to be
do exactly what um you had to do um because their machine is so dynamic um but there there's always
like a trade-off between how static and how dynamic it is i went through that a little bit
in my article where if it's too static you do have trade-offs for some parts of the user
experience are harder developer experience is harder um and so at radix we try to find like a
nice middle ground between how static and how dynamic it is to um one give the user you know
very good previews like you're talking about um but then also make the developer experience not
too difficult as well well is contention then because i know that that's big uh uh kind of a
thing that builders are kind of building around in something uh i have context in which is like
cardano they have to kind of really think about contention is that the other side of the spectrum
then russell it's like if you have too much determinism almost and is that an application
related thing or is that more of a something is that a different part of the stack maybe
so you're thinking of there is in the case of card auto the it's the case that in my transaction
there i'm literally specifying you know this particular utxo i'm interested in interacting
with and then if you have two transactions that appeared both trying to access that particular
utxo which is only going to get used once it will only the first will succeed and so our entire
model is around you talk at the level of what's my user intent which is i want to withdraw 100 xrd
from here i don't care which particular xrd inside that bulb under the hood that winds up being and
that's the way we resolve that problem anything else you want to comment on that josh and i think
this will be our last question as we're we're at the hour and i do need to go yeah i i would say
that cardano in sort of the dynamic static spectrum is or any utxo based vm is very much static
you know all the exact inputs all the dependencies up front so you do get nice the ability to
to preview and know what the execution is going to be but at the same time the the other side of
that trade-off is now like you like you mentioned j speak the developers now have to think about
way more they can't just have this shared object type model you have to think about
contention you have to think about all these other things which you don't get in traditional
programming cool so i think that's going to wrap it up for us today thanks everybody for joining
let us know and telegram right here what you what you thought of things and
we'll see if we can do uh another tech talk pretty soon
thanks everyone thank you russell josh and you speak for those questions and uh yeah we'll see
you next thing thank you thanks yeah thanks connor you're the man goner keep doing your
thing you're doing your thing man cheers see you later guys