Panel: EVM vs SVM vs ARM vs Blended

Summary

In 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

00:00

🤔 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.

05:00

🛠️ 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.

10:00

🔍 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.

15:02

🏗️ 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.

20:04

🤝 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.

25:05

🚀 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.

30:07

🎉 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.

Keywords

💡Virtual Machine (VM)

A virtual machine is a software-based simulation of a physical computer that executes programs like a real machine. In the context of the video, VMs are being discussed in relation to blockchain technology, where they serve as environments for executing smart contracts. The panelists debate the necessity and utility of different VMs, such as the Ethereum Virtual Machine (EVM) and Solana's Sealevel VM (SVM), and how they address issues like scalability, security, and developer experience.

💡Ethereum Virtual Machine (EVM)

The Ethereum Virtual Machine is the runtime environment for smart contracts in the Ethereum blockchain. It is a key concept in the video as panelists discuss its limitations and potential improvements. For example, Keone from Monad mentions building a high-performance EVM layer one, indicating the desire to enhance the existing EVM's capabilities without altering its compatibility with existing applications.

💡Scalability

Scalability refers to the ability of a system to handle a growing amount of work, or its potential to be expanded. In the script, scalability is identified as one of the three main issues with the EVM, implying that current virtual machines may struggle to process a large volume of transactions efficiently. Monad's approach to introduce a custom state database and optimistic parallel execution aims to address this problem.

💡Security

Security in the context of VMs pertains to the protection against unauthorized access and ensuring the integrity of the code execution. It is one of the three pillars discussed in the video, indicating its critical role in the design of VMs. While the script does not provide specific examples related to security, the general consensus among panelists is that security is a fundamental aspect that needs to be considered alongside scalability and developer experience.

💡Developer Experience

Developer experience refers to the ease and efficiency with which developers can create and deploy applications on a platform. In the video, it is mentioned as a significant area of focus for VM projects. For instance, Fluent's representative emphasizes the importance of developer experience, stating that their project aims to simplify the interaction with VMs by using an internal tool called Aras to formalize and prove zero-knowledge transitions for all languages.

💡Modular Ecosystem

A modular ecosystem is a system designed with independent but interconnected components, allowing for flexibility and easier upgrades or changes. The host, Rex Kersner, mentions this term while introducing the Expansion podcast, which focuses on such ecosystems. The concept is relevant to the video's theme as it reflects the ongoing discussion about the fragmentation and specialization of VMs within the blockchain space.

💡Interoperability

Interoperability is the ability of different systems or components to exchange and make use of information. In the script, the concept is discussed in the context of VMs, where the goal is to allow different execution environments to work together seamlessly. The panelists explore the idea of creating a unified VM that can emulate or simulate different environments, thus facilitating interoperability between applications.

💡Layer One (L1)

In blockchain technology, Layer One refers to the base protocol or platform on which decentralized applications are built. The term is mentioned in the context of discussing the role of L1 blockchains in providing proof verification and computation off-chain. The panelists consider how the structure of these layers affects the design and function of VMs.

💡Rollups

Rollups are a scaling solution for blockchains, particularly Ethereum, where multiple transactions are bundled together and processed off-chain before being submitted as a single transaction to the main chain. The script mentions rollups in the context of off-chain computation, which is a method to enhance the scalability of the EVM by moving computation away from the main blockchain.

💡Zero-Knowledge (ZK) Proofs

Zero-Knowledge Proofs are cryptographic methods that allow one party to prove to another that they know a value x, without conveying any information apart from the fact they know the value. In the video, ZK proofs are mentioned as a technology that helps in the development of the blockchain ecosystem, particularly in enhancing privacy and scalability. Fluent's approach to use ZK proofs for transitions across different execution environments exemplifies this.

💡Abstraction

Abstraction in computing refers to the process of reducing complexity by hiding the details of implementation and exposing only the necessary features. In the script, abstraction is discussed as a trend in the blockchain industry, where the goal is to create systems that are easier for developers to use by hiding the underlying complexities. The panelists debate the merits of abstraction and its impact on the future of VMs and blockchain applications.

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