Panel: EVM vs SVM vs ARM vs Blended
Summary
TLDRIn a panel discussion moderated by Rex Kershner, various experts convened to explore the concept and utility of Virtual Machines (VMs) in the blockchain ecosystem. The conversation delved into the scalability, security, and developer experience challenges associated with the Ethereum Virtual Machine (EVM) and how projects like Monad, Fluent, and Ellipse Labs are addressing these issues with innovative VM solutions. The panelists debated the necessity of VM competition, the importance of developer experience, and the potential for a unified execution environment that could support multiple VMs, hinting at the evolving landscape of blockchain technology.
Takeaways
- 😀 The panel discussion revolves around the concept and utility of various Virtual Machines (VMs) in the blockchain ecosystem, with a focus on Ethereum's EVM and its alternatives.
- 🤔 There is a debate on the definition and necessity of VMs, with some panelists questioning whether they should compete or if different VMs serve different purposes.
- 💡 The Aoma project, represented by Rex, is self-admittedly underqualified for the panel, highlighting the complexity and diversity of perspectives on VMs.
- 🔄 The Monad project emphasizes performance improvements to the EVM, aiming to make it more efficient without changing its compatibility or developer experience.
- 🌐 The Solana VM (SVM) is designed for performance, with constant factor improvements and a focus on how well it works with today's computers.
- 🛠 Fluent aims to enhance developer experience by allowing the use of existing tool sets and translating them into their VM, thus avoiding the need to invent new VMs.
- 📚 The panel touches on the historical context of VMs, discussing their origins in time-sharing services for mainframe computers in the 1960s.
- 🧩 The Resource Machine project breaks down the traditional EVM into separate components, allowing for more flexibility in state architecture, instruction sets, and message passing models.
- 🔑 The importance of defining the problem that a VM is trying to solve is highlighted, as it affects how well it fits into current deployment scenarios.
- 🔄 The concept of 'Blended Execution' is introduced by Fluent, which aims to create a single VM capable of emulating or simulating all other VM environments.
- 🚀 The discussion concludes with thoughts on the future of VMs, with a consensus that the industry is moving towards more interoperability and abstraction, potentially leading to a unified or blended execution environment.
Q & A
What is the main topic of the panel discussion in the provided transcript?
-The main topic of the panel discussion is the different Virtual Machines (VMs) in the blockchain ecosystem, focusing on their purposes, advantages, and the challenges they address.
Who is the host of the panel and what is the name of the podcast they host?
-The host of the panel is Rex Kersner, who hosts the Expansion Podcast, which is Block Works' latest podcast on the modular ecosystem.
What is the project that Rex Kersner is working on?
-Rex Kersner is working on a project called Aoma, but admits to being underqualified for the panel as he doesn't know what a virtual machine is.
What is the stance of the panelists on the competition between different VMs?
-There is a general agreement among the panelists that different VMs may not necessarily need to compete with each other, as they could serve different purposes and suit different needs.
What is the main reason Keone Han's project, Monad, was built for the EVM?
-Monad was built for the EVM because of the network effects of the large number of developers, libraries, and existing programs that are already familiar with the EVM, which is considered powerful.
What are the three main issues with the EVM that the panelists discuss?
-The three main issues discussed are scalability, security, and developer experience.
How does Monad address the issue of scalability?
-Monad addresses scalability by introducing a custom state database for storing Ethereum Merkle tree data and optimistic parallel execution to process more transactions in a unit of time.
What is the main goal of Solana's virtual machine (SVM)?
-The main goal of Solana's SVM is performance, focusing on making the virtual machine more efficient and better suited for today's computers.
What is Fluent's approach to handling different VMs and developer experience?
-Fluent's approach is to allow developers to use any existing tool set on the market and combine them by translating into their special VM, enhancing the developer experience without exposing the internal VM to developers.
What is the concept of 'Blended execution' as discussed by the panelists?
-Blended execution is the concept of creating a VM that can emulate or simulate all other VM environments in one place, allowing developers to use any tooling or language while the underlying system handles compatibility and interoperability.
What is the panel's general view on the future of VMs and the importance of abstraction in the blockchain industry?
-The panel generally believes that abstraction is a key trend in the industry, with the future likely involving more interoperability and less focus on specific VM details, allowing developers to work within a unified computing environment.
Outlines
🤔 Introductions and the Concept of Virtual Machines
The panel, hosted by Rex Kersner, begins with introductions of the participants and their respective projects. There's a candid admission of varying levels of understanding of virtual machines (VMs), with some expressing uncertainty about the necessity of competition among different VMs. The discussion hints at the potential for VMs to serve different purposes, reflecting the diversity of functions they might represent.
🛠️ Diverse Approaches to Virtual Machine Design
Participants from Fluent, Ellipse Labs, and Monad share their views on VMs, with a focus on their projects' contributions to the ecosystem. The conversation delves into the scalability, security, and developer experience aspects of the Ethereum Virtual Machine (EVM), with each project addressing these pillars differently. Monad, for instance, aims to enhance performance without altering EVM compatibility, while others like Lana and SVM focus on performance improvements specific to their use cases.
🔍 Exploring the Essence of Virtual Machines
The panelists engage in a deeper exploration of what constitutes a virtual machine, discussing the historical context and the evolution of VMs from time-sharing services on mainframe computers to their current forms in blockchain technology. The conversation challenges the conventional understanding of VMs, suggesting that the focus should be on the problem they aim to solve rather than the technology itself.
🏗️ Building a Unified Execution Environment
The discussion shifts towards the idea of creating a unified execution environment that can simulate various VMs. Fluent introduces 'Aras,' an internal tool designed to formalize zero-knowledge transition proofs for different languages, enabling the simulation of multiple execution environments within one system. This approach aims to enhance developer experience by abstracting away the complexities of multiple VMs.
🤝 Interoperability and the Future of VMs
The panelists consider the future of VMs in the context of interoperability, both between applications and with the existing base of programs. There's a debate on the importance of VMs as a differentiating factor for building a business and the potential for computational environment abstraction. The conversation suggests that while technical aspects of VMs are crucial, the industry may be moving towards a more abstracted and interoperable landscape.
🚀 Growth and Modularity in Blockchain Development
The conversation concludes with thoughts on the growth of the crypto space and the importance of modularity in blockchain development. There's an emphasis on the need for the industry to move beyond monolithic solutions and embrace a more collaborative and delegated approach to building blockchain ecosystems. The panelists highlight the role of VMs in this context, as part of the execution layer that can be shared and optimized across the industry.
🎉 Closing Remarks and Acknowledgement of Panelists
The session ends with a round of applause for the panelists, acknowledging their contributions to the discussion on virtual machines and the future of blockchain technology. The closing remarks encapsulate the essence of the conversation, highlighting the importance of continued innovation and collaboration in the crypto industry.
Mindmap
Keywords
💡Virtual Machine (VM)
💡Ethereum Virtual Machine (EVM)
💡Scalability
💡Security
💡Developer Experience
💡Modular Ecosystem
💡Interoperability
💡Layer One (L1)
💡Rollups
💡Zero-Knowledge (ZK) Proofs
💡Abstraction
Highlights
Introduction to the panel on different Virtual Machines (VMs) by Rex Kersner, host of the Expansion Podcast.
Participants introduce themselves and their projects, with some expressing uncertainty about the definition and purpose of VMs.
Rex Kersner's confession of being underqualified for the panel and the lack of a formal definition for a virtual machine.
The notion that different VMs might suit different purposes is introduced, suggesting that VM competition may not be necessary.
Eugene from Ellipsis Labs discusses the Solana Virtual Machine (SVM) and its performance goals since 2018.
Keone Han, co-founder of Monad, explains Monad as a high-performance EVM layer one, emphasizing network effects and developer ecosystem.
Discussion on the three main issues with the Ethereum Virtual Machine (EVM): scalability, security, and developer experience.
Keone Han describes Monad's approach to improving the EVM's performance without changing compatibility for developers.
The concept of 'Blended Execution' is introduced by Demitri, aiming to unify different VMs into a single function or VM.
Fluent's strategy to enhance developer experience by allowing interaction with an internal VM through existing tool sets.
The idea that the EVM's current problem is a lack of a clearly defined problem or purpose in its deployment scenario.
Debate on whether the EVM and other VMs are suitable for the modern blockchain environment compared to their 1960s origins.
The Resource Machine project's approach to separating state architecture, instruction set, and message passing model in VM design.
The importance of interoperability between applications and the existing base of programs for the growth of the crypto space.
Concerns about the current coupling of compiler development, virtual machine operation, and specific blockchain layer operations.
The potential future of VMs and the crypto industry's move towards a more modular and interoperable ecosystem.
Final thoughts on the necessity of pragmatism, the opportunity for crypto to grow, and the importance of performance improvements to existing standards like the EVM and SVM.
Transcripts
so thank you everyone um welcome to the
this panel on the different VMS my name
is Rex kersner I am a host of the
expansion podcast which is block Works
latest podcast on the modular ecosystem
and uh before we jump into VMS let's
just do a quick run of introduction so
if everyone can say their name their
project the VM they're working on and
then let's maybe do one or two sentences
on why you think the VM that you're
working on is the one to bet
on uh sure I'm happy to start uh thank
you all for coming today if I were you I
would be in bed so I'm impressed and
honored that you're here um some of you
look like you might still be in bed
mentally even if not physically I
respect that too um I work on a project
called aoma and I have a confession to
make which is that I am greatly
underqualified for this panel because I
don't know what a virtual machine is so
I'm hoping that maybe we'll figure that
out um I'm also not convinced that they
should be competing with each other uh
so you know a little little yeah maybe
not sure about the frame of that
question I mean the closest to a
definition that I found is that virtual
machines are ways of representing
functions and I think it's not really
possible to speak about which is the
right way to represent functions without
speaking about which function you want
to represent so perhaps different
virtual machines would suit different
purposes but we shall
see Hello uh my name is m I am from
fluent I totally agree with your point
that what the hell are virtual machines
yes they tried
uh to figure out what it was the proper
definition of virtual machine and why we
have such huge amount of virtual
machines and uh uh let's figure out how
it works why it works and actually why
how fluent is trying to solve this
problem hi I'm Eugene I work at ellipses
labs and I guess I'm the third guy in
the panel who doesn't have a formal
definition of a virtual machine but as a
company we are core contributors to
Phoenix which is a limit order book Dex
on salana we're pretty familiar with the
salana virtual machine and uh the the
tool set around
it hello my name is keone Han co-founder
of monad uh monad is a high performance
evm layer
one uh and the reason why we built for
the evm is because we feel that the
network effects of um so many developers
so many uh libraries so many existing
programs is just really
powerful okay well I was not expecting
to uh just have debate on the concept of
VMS but we'll power through and we'll
we'll come to conclusion by the end but
let we we should start with the evm and
uh like let's start with the vanilla evm
the classic evm so today I I'll
summarize kind of like the complaints
with the evm in three pieces right we
have scalability we have security
and we have developer experience so can
we talk through each of your projects
and um except for Keon who uh is using
the evm but kind of in a modified way
can we talk through which of these three
pillars do you think is the biggest
problem and how is your project uh kind
of addressing that issue that you've
identified so why don't we go reverse
order Keon why don't you start us off uh
sure would you mind just saying the
three different sure so um scalability
security and devel experience oh sure um
so monad is fully bite code compatible
so any existing evm application could
just be redeployed on monad without any
changes um the all of the changes to the
VM that monad is implemented are just
related to making it a lot more
performant for example um introducing a
custom State database for storing
ethereum Merle tree data um that's
completely under the hood um optimistic
parallel execution for executing more
transactions in a unit of time but also
completely under the hood um so just you
know regards to the scalability aspect
um I just think that there are a lot of
areas of
improvement um relative to the current
implementations of the evm uh for
example in G or Aragon or other clients
and um our team is is a team that's
really focused on just making some of
these fun fundamental improvements that
don't actually change the
um yeah any compatibility or any any
considerations for
developers so Lana and the svm are
really designed for performance and
that's sort of been the the goal for
salana since 2018 and so at the BM layer
there's you know some constant Factor
improvements just in um uh really just
in the implementation where we don't use
like U 256 because they don't work super
well with
computers um
today's computers let's say
um salana has a couple of other things
like native access lists uh although
this is not like a VM detail necessarily
this is something you could slap on the
evm if you wanted to and allows you to
do a particular type of uh parallel
execution uh when it comes to like which
VM is going to
win I mean I think in the same way that
it's relatively unlikely that a single
blockchain wins like every single use
case wins every single user I think it's
pretty unlikely that a single VM or a
single execution environment is going to
win every single use case uh kind of
going to the original question of what
are these things useful for
anyway uh some applications are going to
be really really performance sensitive
some of them are going to really rely on
uh being extremely extremely sensorship
resistant and probably the right tool is
going to be different for different
types of
applications um you highlighted three
main areas and uh that's a bit tricky
because at the same time uh you cannot
design solution uh by for example
ignoring one of these and you also
cannot focus on one specific area
influent tries to build a product that
combines all these three main aspects
but uh if someone ask me what's the most
important and uh beneficial uh for
example in terms of fluent I'd say that
it's a developer experience and U I have
a reason for this because uh there is a
giant problem and maybe I think it's
even a giant Gap in misunderstanding of
what is VM how it works and why do we
actually need to have these T of
different VMS because they all designed
for specific needs for specific tasks in
fluent we don't want to invent new VMS
actually we do but we don't expose it to
developers we this allow developers to
interact with our VM internally we
instead we say that you must use only
tool set you know only tool set that
already exist on the market and you can
combine all these tool sets together by
translating into our special VM and uh
this is how we try to enhance uh
developer experience and at the same
time uh for example scalability is
extremely important for projects
starting with uh let's say like fluent
tzk based and it brings scalability
opportunities for chain to be uh semi
centralized and be scalable
simultaneously so um I think we've been
scoped maybe by the editor the virtual
machine Wikipedia page if you go to the
virtual machine wikkipedia page it
describes a bunch of these designs from
the 1960s and in the 1960s uh computers
were all mainframe computers they were
in like University Laboratories and
there were very few computers they were
like big and they consumed a lot of
power and they were expensive and
universities being you know nice wanted
to allow their staff many different
staff to use these computers so they
created these kind of time sharing
Services particularly time sharing
services for computation where people
who wanted to do compute jobs wanted to
run them on the mainframe computers
maybe even have those compute jobs
interact with each other would submit
job requests they would send them all to
the Mainframe the Mainframe would like
schedule them and execute them in order
because it was uh trying to share up
this resource of computation um and even
if you look at something like the e M or
the svm um they are modeled after the
same basic like understanding of the
problem um and I think that
understanding of the problem was
perfectly suitable for 1960s mainframe
computers when what you wanted to do was
share computational resources I'm not
convinced that it's suitable for our
problem I mean we haven't really defined
what our problem is but to take apart
the evm for a second to me the evm
consists of three things it cons
consists of a State architecture how
state is stored how changes to state are
authenticated um it consists uh a State
architecture it consists of a an
instruction set this is like how
computation is represented so add
multiply to 56-bit integer types that I
would call part of the instruction set
and finally it consists of a message
passing model which is how programs send
um data and messages to each other and
in the evm this is accomplished by like
the call op code and its various
variants uh and these three things are
coupled together in the evm but it's not
clear to me that they're like
necessarily coupled together at all so
one thing we've done uh with our project
called the resource machine is split
these three aspects apart the resource
machine is a State architecture but it
doesn't fix a particular instruction set
or message passing model so you could
still use the resource machine with the
evm or the svm just as an instruction
set to represent functions and you can
pass messages I don't know however you
need to pass messages on the intent CIP
Network through solvers to figure out a
satisfying solution and just publish
that as a transaction I don't think the
resource machine is the only way to
split these three components apart you
could do a different architecture you
could do many instruction sets you know
when you split them apart they're not
tightly coupled they're not one to one
coupled like they are in the evm um and
you could probably do many different
kinds of message passing models so I
would be interested to see a lot of
Investigation in that direction I think
it's really hard to say like what the
right VM is without defining a problem
to me the EV M's problem right now is
that it hasn't defined a problem like
you know apart from the world computer
which is a meme uh it's unclear what the
evm is trying to do what what is the
what is the machine that it's aiming to
virtualize is the machine one blockchain
that wants to share you know that wants
to provide abstract computational and
storage resources that's maybe what it
originally was but with rollups with
kind of layer ones being used mostly for
proof verification with a lot of
computation happening offchain and with
just the very structure of the gossip
Network implying that no one other than
the person actually you know proposing
the block can really guarantee the
results of execution uh you know absence
of more complex models but still like
random nodes in the gosip network can't
I think the evm is has a sort of
definition that's like Misfit to its
actual deployment scenario and if we
want to fix it we first kind of need to
clearly Define the bounds of what the
machine is that we want to virtualize
and to
whom ke did you want to say something uh
yeah I mean definitely appreciate that
uh kind of breakdown of the the evm into
several components and the effort to try
to reimagine like what what it would
look like if we you know took the
burrito apart and made a burrito bowl
instead but um I I think just to State
it very clearly like
the way that and we all know this
because we all interact with ether scan
we see like a block and we look into the
block and it has a bunch of transactions
and then you know we look at one of the
transactions and it's interacting with a
particular smart contract um you know I
would just say that the you know at the
end of the day like that's a pretty easy
to understand computational model of
just like transaction based execution um
where a transaction is like you know
depositing money into your bank into
your like virtual bank account uh like a
lending protocol or something like that
so it's not like totally um abstract
what a VM is like a VM is a Sandbox for
executing a program using a standardized
instruction set like you said um and
then you know this gives us building
blocks we can build up more complex um
you know an entire Lego castle from
these individual
bricks yeah I mean just got got to take
that off just like I I did not realize
the concept of VM would be controversial
for this panel and look like I come from
the I don't know School of com of VMS
that like I learned what a VM was from
uh parallels I have a Mac I wanted to
play Windows games and like that's how
you did it right and so you could you
could say like well what's the point of
this virtual machine and like it doesn't
have a purpose and it's just like
general purpose windows but like the
point was that I had access to it and
that I could start like putting my
actions and transactions into it and so
and you had had applications that you
wanted to use right that were like
written for this VM in some sense
written for Windows right sure sure yeah
yeah so again I what I see at the VM is
and maybe like we need to come up with
new vocabulary like there's a good space
for new vocabulary but um like it is
just like the environment on which your
like smart contract or sorry your your
blockchain actions just happen within
right so in the VM that is this like
well-defined space the svm has a well-
defined space that are not exactly the
same but you know like they're the
Computing space By the way according to
you called it the vocabulary I think
this is the perfect term that can
describe the problem we have right now
because uh what we know today we even
cannot call evm a virtual machine
because technically it's not a virtual
machine I'd name it
uh specific context dependent EX
execution environment with specified
instruction set because from the like uh
you provided an example of uh uh
parallels uh uh like uh it's more about
like emulation a hard it's a hardware
emulation problem and it's it's it's
quite different because in blockchain we
don't have a hardware emulation problem
we have a sunbox execution problem and
the way how we can pack it efficiently
into one place in in ex cute and the
question is uh why do we all develop on
evm is it the best solution or we have
to do this to support all developers
that already persist there like in the
community or we have some alternative
choices yeah I mean I think to your
point about you know parallels users
want to use applications and if those
applications are written for tied to a
specific virtual machine I mean users
will want to use that virtual machine in
virtue of allowing them to use those
applications I suspect this is part of
why you you guys at monad want to
support the evm and implement it in a
more efficient way make it better
because they're already all of these
applications that totally makes sense to
me but then you know to me the question
is can
we make it easier to for some users to
make different choices while retaining
the ability to interoperate right you
know these VMS uh if we take them there
many specific choices let's say specific
choices of State architecture in
instruction set they have different
trade-offs that make sense for different
applications and you know developers are
like quirky and maybe they will just be
attached to particular VMS there are a
lot of people who really like this
language called knock used by urbit um
and you know it's interesting it's very
quirky so maybe we should let developers
have their diverse preferences keep them
happy uh but how can we allow that to
happen at the same time that we don't uh
Force users into this question of like
Mutual incompatibility so just like with
parallels well you had to install this
whole separate environment you had to
you know make a virtual desktop and I I
haven't done this in years and years and
years so you're testing my memory here
but like I mean to me this is like a
pain in the ass like wouldn't it be nice
if you could just run the windows
applications in Mac right what if the
operating system handled this
compatibility and interoperability for
you so to me it it seem it seems like
we're question we're having a question
about virtual machine design but also to
your point about a Sandbox execution
environment I think we're asking more or
less about the wrong problem we're not
trying to build a virtual machine we're
trying to build build an operating
system okay that blew my mind um I I do
think this is a good opportunity and
we'll borrow from fluent and so Demitri
I'd love you to speak on this but can
you talk through like this new concept
of Blended execution and uh we yeah we
just give us a little bit of a
definition and then we'll have some
questions for the panelists yeah uh the
concepts uh of uh Blended execution is
to try to find a way uh it's literally a
way how we can present all VMS using
only one function using only one VM so
is is it possible to create a VM that
can solve and emulate or simulate all
these environments in one place so yes
in yes it's possible yes and we also
think that it's possible because if if
you try to imagine how your application
works like if you try to support evm svm
and all these other VMS all these
standards language your your mind is
blowing because you understand you must
Implement thousands of thousands
different standards uh it takes years to
implement and it makes no sense because
during the implementation period new
standards appears new versions appears
and you cannot support the circuits you
cannot support this codebase it's super
complicated but what if we we we try to
define a new way how you represent your
application through a transition and if
there is a language that can uh simulate
everything that can run everything then
you can use this language for example to
for to simulate itself we call this
language Aras it's an internal tool
inside fluent it works under the hood of
the fluent and it used to Simply to to
to formalize how we proof ZK transitions
for all languages and we uh do so-called
like downcast ahead of time compilation
from all the
binary representations into one binary
representation and we use this binary
representation to prove itself and to
prove all and simulate all execution
environments in one place so developers
can take any tooling they want any
language they want any virtual machine
actually we don't care about languages
we care about execution environments and
if you have solidity Viper Etc you have
some standards we don't care about
standards at all because we support
execution environment if we have
something that is uh on the uh lower
level than standard then by implementing
this layer you have standards as a
default feature and also of course all
languages like solidity Viper Etc it's
like a side effect of your
product do you handle or do you try to
handle program
interoperability and how do you do that
if so um so this is uh the giant I think
question about how this model Works uh
because the most difficult thing is to
handle inter between these different
execution environments and uh influent
we don't know what execution environment
you use actually entirely we have only
one language our side we have only one
virtual machine that is absolutely
closed for developers and they cannot
use it and they cannot interact it's a
side effect of the development process
of the compilation of the translation
unit and uh uh we create our own tree
representation our own storage layout
and we create special let's call it
loaders for for applications according
to the execution environment where we
Define how they uh interact with this
tree how they interact with this state
transition and what uh Al loans they
have and what restrictions they have
because we cannot allow this
applications to do uh everything they
want because they can for example
corrupt storage get access to another
execution environment somehow and we uh
during the compilation process we inject
all these restrictions all these
constraints into the loaders of the
execution
environments so yeah let me out one
thing you can build something like like
you can create application using evm
using using solidity let go you can
create application using svm and they
can share same balances you can do
Native interrupt between these apps the
only thing you you need to carry is uh
of is uh AI encoding so we we don't care
about AI of course because it's I can
explain why uh because it's specifically
developers problem they all think that
oh These Chains these platforms
executions has different API developers
cannot interact but if you develop a an
app using solidity language how do you
interact with other apps on solidity of
course you specify API you must know the
language you use to interact and what
language developer of the application
use if you want or for example some
specific Library you want to interact
and what's the difference if I specify
solidity compatible II or some other IBI
for example borch compatible API or some
like usan compatible API so there is no
difference for developers uh syntax May
changes a bit uh but it doesn't affect
the development experience
significantly great so my brain doesn't
have very many wrinkles let me try to uh
like regurgitate back to you what you
said tell me if this is right or or the
effect of what you said which is as a
developer if I want to deploy into
fluent I could write my code in solidity
or I could write it in rust or another
language and fluent in the background
takes in all of these binaries and then
presents the users at that this is one
unified uh Computing environment correct
yes yes correct and like that incredible
thank you um and like to me this is like
clearly where the industry is moving
right we just uh whoever was here
yesterday I saw um Ed Felton I believe
from arbitrum talk about arbitrum
stylist and this is like the exact
direction that they're going which is to
realize that you know like there's not
that many solidity developers there's a
ton of rust developers and a ton of C
developers and C++ developers and so I
guess um my question for all of you guys
is like is this for me this is the clear
trend of where the industry is going but
is that how you see it do you see that
these execution environments are kind of
this like developer weird thing that we
have to deal with now as just growing
pains of blockchain computing or um is
this like an important Paradigm that
will exist in like 10 years and 50 years
and like we'll understand what the evm
versus the svm and be having those
debates uh when we're grandparents so
why don't we start up from
ke um I mean I'll just mention that
JavaScript is still like you know the
backbone of most
um interactive web
apps and you know we have like nicer
Frameworks on top um typescript and then
Frameworks on top of typescript but
everything under the hood is still
JavaScript so I think if you're kind of
trying to project like five years into
the future and say like what what does
the smart contract landscape look like
is it just like a jumble of all these
random like you know solidity things
that um you know are floating around a
different GitHub rep goes all verified
an ether scan um I think that's that's
likely and we just see like a
proliferation of of more complex
applications built on top of the
existing ones um similar to how like
what what we see in the in the internet
landscape with JavaScript yeah
Fair yeah uh I think this is very path
dependent there were also you know
previous web Frameworks web languages um
before JavaScript and I don't think it
was clear a priori what was going to
reach escape velocity and there's like a
lot of these sort of constant factors
that matter here one of them is the like
the hardware itself the computers the
browsers now have access to so much more
resources than they did before to the
point where like the average shitty
JavaScript developer like myself can
still build a web application that
mostly
works and the the tooling is also seem
to reach some sort of escape velocity
which is where in my mind the evm has
the biggest advantage today I think the
total of number of developers just
doesn't matter whatsoever uh if you're
bullish at all on crypto you should
expect the number of developers in the
future to be at least two orders of
magnitude higher than it is
today uh and then where you're going to
get the runaway Network effects
potentially is going to be on the
developer tooling and developer
onboarding
um I think um one very important
statement um from my from my perspective
uh we cannot fight against uh developers
needs and requirements no matter what
tool set you provide to them they all
the time use what they want and you
cannot limit them with a number of uh
VMS and say oh you must use this this
and this for the for for your needs
because you you you cannot like the
number of so if you can create all these
VMS you also can create an app that
doesn't fit into one of the VM and
you'll need new VM uh you highlighted
the great example of JavaScript I like
to call JavaScript a machine code
because u in some way of how you think
about Chrome Let's uh it's an operating
system and it has its lowlevel machine
code in JavaScript because it's the
simplest thing you can develop and use
in ins inside your Chrome browser and
Google tried to replace JavaScript for
several times they tried to use Dart as
a foundation language for development
but under the hood they literally
translate all the time everything to
JavaScript and JavaScript is uh the most
weird machine code ever created because
uh because it's un it's it's it's not
natural to have JavaScript as a machine
code it makes no sense but this is what
we have and today if you want to create
new Solutions you must always uh worry
and think about developers about uh
execution environment you have like uh
Google Chrome developers or like old
browser uh front developers they are
locked to use JavaScript and there is no
ways how they can like get away from
this they're trying to uh mix it for
example with u uh web assembly uh to let
developers develop for example you are
using the JavaScript and develop uh
highly loaded apps using web assembly
this is very similar for example what
stylos is trying to achieve and uh uh
you can use evm that is like let's say
an important Legacy to have and also you
can expand functionality using web
assembly but uh we're trying to think
even further because what if we don't
want to limit developers with two
languages with two execution
environments what if we can like let
them Define the execution environment
they want if they want to develop
something that is not supported by for
example stylus they are limited with
functionality because they need to wait
stylus to develop this but uh using our
like translation approach we can let
developers to create their own execution
environments and create apps for these
execution environments if one new VM
appears they just create translators
into our presentation they create
simulation tool set and that's it
developers can start using this and and
we think it can be the future because it
uh we don't want to limit developers we
want to help them to use the same
environment to use the same tooling and
uh we want all developers persist in the
same St state in the same
place I mean to me the question is what
are we trying to provide here and in all
of the examples that you've given of
parallels of the evm of your kind of
Blended execution environment it seems
to me like what we're trying to provide
is interoperability in two ways we're
trying to provide one interoperability
between applications applications need
to share some kind of environment some
kind of operating system especially when
they don't all trust each other in order
to uh facilitate interoperability State
messages Etc and two we're trying to
facilitate interoperability with an
existing base of programs developers the
stuff that people have already written
in solidity for the evm the models that
developers already understand um and I
think we will continue to want both of
those kinds of interoperability I think
this question does not relate to many of
the aspects that are often bundled under
the term virtual machines in particular
it doesn't relate to the instruction set
nobody cares about the instruction set
what's the instruction set you said that
JavaScript is a kind of machine code
which I think is is true and funny but
also you know Google sank boat loads of
money into their just in time JavaScript
compiler and it does random things that
I guarantee no one in this room knows
unless you work for Google on V8 then
I'm I'm I'm impressed and wrong but
probably not come find me after um and
the reason that you don't need to know
it is that they have abstracted the
right things developers can write
JavaScript I mean the web browser apis
are not great but they're they're there
you know uh at least there is an
operating system environment and Google
sank they're money um which they have
too much of into a lot of compiler
Engineers to at least try and make your
JavaScript run kind of fast most of the
time and you know it works sort of well
enough um and I think that is much more
likely to be the world that they will
see maybe there will be some uh you know
lowlevel formats that for whatever
reason or another are kind of standard
just because it makes things simpler but
developers will not need to even think
about them if they need to think about
them and we're on this panel and another
60 years as Grandparents still talking
about minutia of virtual machines yeah
then I think need to re-examine our
lives okay well you kind of cut off my
last question to the legs here but I'll
ask it anyway which is you know a
buzzword right now in this point of the
narrative is abstraction right like
chain abstraction account abstraction um
and I guess like my question for you
guys is like do you believe that we're
inevitably going to reach computational
environment uh abstraction and to that
effect like how important uh how
important is the VM and like can you
build a business with your
differentiating Factor being you know
your VM or tweaks your VM or that kind
of thing or if we are really going down
a computational environment abstraction
like uh road map like is this stuff
really relevant or is this kind of
implementation details that um a
developer will see on like page 12 of
the docs so why don't we go in uh
forward order Chris take us up yeah I
mean I would say um to me at least
computational abstraction was invented
by alen Turing so I think we're like
doing okay there we don't necessarily
need to reinvent that one perhaps we can
build some better
compilers
um what was the second question sorry um
so do you believe in this uh
computational environment abstraction
and uh is the VM a differentiating
factor that you can build a business
around right um I mean whether or not
you can build a business around
something depends on what kind of uh
world of money and a Finance in which
you operate um and I think it's likely
that that will change I mean it always
changes through history so even absent
crypto or even talking about our
specific technology a reasonable
assumption is that it will continue to
change in the future um I you know I
mean to me like compilers are useful
like it saves energy to have more
efficient compilers so I would be very
happy if we come up with ways of
organizing our financial system that
make uh producing better compilers
valuable businesses at least for some
people maybe not everyone if everyone's
producing compilers and no one's
producing potatoes were in trouble but
we probably want some resources
dedicated towards that uh I I think the
business models will need to look
different than how they currently look
where people like uh in effect you know
raise the development of compilers and
virtual machines and the operation of a
specific like layer one blockchain or
rollup or something these are coupled
together uh in the public eye in the eye
of capital allocation and I think this
coupling uh doesn't work very well one
it like doesn't work well as a value
capture mechanism because people want to
send intents and transactions based on a
lot of other factors factors mostly not
just like the computation mostly not
just the VM um and two it doesn't work
well in terms of actual Capital
efficiency because you have a lot of
like wasted duplicate efforts and then
you try and create gate gatekeeping
effects so people will send transactions
to your chain or whatever so I think in
general that's a pretty terrible system
of financial coordination and we should
probably seek to replace it in order to
get better compilers and more
abstraction yeah I want to say regarding
obstruction I want to also add regarding
modularity and um I think these are
quite uh similar Concepts because I I
extremely love what's happening with
script industry today that happens like
two three years that started to happen
two three years ago because before
everyone try to build like layer one
layer one layer one like the fully
monolithic uh almost the same
blockchains with one tiny difference but
today developers they finally figure out
and the entire community that there's no
need to to create all these fully
independent environments you can you can
do so-called um um like you can delegate
uh responsibility for specific functions
to specific areas you can try to
abstract most of things like uh you can
split your blockchain into sequen
execution data availability settlement
and Etc and you you can let different
teams to focus specifically on specific
things this is why VM matters because VM
is a part part of execution layer and
let developers create uh great execution
layers and share it across the entire
industry and just utilize what we have I
think this is extremely right way
because uh uh the entire crypto industry
is finally on the way to build the giant
crypto infrastructure that can be it's a
giant ecosystem that can even compete
with web 2 and uh to be integrated into
web 2 because we finally forgot about
the extreme decentralization with Asic
mining where the only thing that is
important is to um produce your hashes
and uh this is huge you have 10 K hashes
and amazing Mega hashes Terra hes it's
it doesn't matter but finally we can
think about uh more semi centralized
solution about ownership responsibility
delegation and actually thanks to ZK
because ZK really help to Boop this
process yes it's not super optimal today
ZK has a lot of things to fix to improve
to optimize but but communities start uh
started to think about the problem and
now we can expand the ecosystem
finally I'd say the economic interest
here where everyone is always trying to
commoditize their compliment means
you're pretty much always going to be
stuck in the cycle
where like in traditional media today we
see this cycle of B bundling and
unbundling bundling and unbundling see
the same thing in Enterprise SAS uh and
we're going to see the same thing at all
these different levels of the crypto
stack where I'm all as incentivized to
try to abstract away or commoditize the
layer above me the layer below me
they're trying to do the same to me uh
so I think this is really all motivated
by business interests I think it's
pretty difficult to fight against the
the economic incentives uh I think
that's how it's going to play
out uh yeah I mean I think we need to be
very
pragmatic I think
that you know there's uh just an
incredible opportunity um for the crypto
space right now to grow substantially
and um take more share of the market um
for decentralized apps to become the
prevailing standard but that's not going
to be easy to do um and I do worry that
um well in any event I think what's
really important is
to like you know we have a couple of
Standards it's pretty clear that um you
know the you know like there's traction
around the evm there's traction around
the
svm um and we'll make incremental
improvements um performance improvements
or feature improvements to those um but
really the yeah just I think that the
growth has to be obviously in the
application space
um and I think that you know to some of
the earlier points about
like just wanting to like abstract
everything away or like give a ton of
flexibility I do think that there's a
reason why like you know trains run on
tracks it is because you can go a lot
faster when you're on a track so I I
would just push back a little bit on um
some of the some of the other comments
about like how Developers might want to
you know run a random language that
doesn't exist right now and like we I I
don't know I just think that evm is here
to stay um our team is working on trying
to make it a lot more performant and I
think for the entire ethereum space it's
just really important for us to get much
more scale out of what we have and then
go figure out how to um make inroads
into the rest of the like Tech and
financial space awesome well we're out
of time so everyone can we get a hand
for our
[Applause]
panelists and uh yeah thank you guys
thank you very much thank you
Посмотреть больше похожих видео
What is EVM (Ethereum Virtual Machine)?
Ethereum Layer 2 Solutions Explained: Arbitrum, Optimism And More!
Internet Computer is the ONLY 3rd Generation Blockchain | Dominic Williams
How to Join a Client PC (Windows 10) to an Active Directory Domain Controller (Windows Server 2019)
Azure Update - 19th April 2024
How to Configure LAN Segments in VMware Workstation Pro
5.0 / 5 (0 votes)