Is RISC-V the Future of Ethereum? A Deep Dive into ZKPs.

Recorded: April 29, 2025 Duration: 0:47:58
Space Recording

Short Summary

In a recent discussion, experts delved into the rising significance of RISC-V architecture and ZK-Proofs in blockchain technology, highlighting their potential to enhance scalability and security. The conversation underscored the growing trend of integrating advanced cryptographic techniques across various blockchain platforms, including Ethereum and VARA network, signaling a shift towards more efficient and robust blockchain solutions.

Full Transcription

Thank you. Hello everyone, hi Dima.
How are you?
I'm good, How are you doing?
I'm good, how are you?
All right.
Let's also wait for Vadim.
One minute.
Let's invite him to the stage.
And then we can start hope everyone had or has
great day the weather is beautiful
hi Vadim how are you doing
I'm good all good good. You look great.
That's awesome.
That's a good start for this X-Space.
So welcome, everyone.
Today's session is going to be focused on RISC-V and ZK-Proofs.
I prepared some questions for VaraCore devs, which is Vadim and Dima.
Also, at the end of the session, we will be happy if you join us and you can just raise your hand and we can add you to the stage.
And if you have any questions, don't hesitate to raise your hand
and feel free to ask.
We will be happy for that.
And I think we can start so we can get to your all questions
and yeah and also this space is recorded so for anyone who couldn't join or couldn't come
it's going to be recorded there's going to be also content afterwards so you have a lot to look forward and i think with
no any more prolonging i'm gonna start with the questions are you guys ready
yeah okay i see dima has some issues oh he disappeared we are about to start and Dima just disappeared on us.
Dima, are you here?
Yeah, it's, you know, kind of our thing about our spaces.
When I disconnect every time in the very beginning and then everything happens fine.
But anyway, it's just annoying, you know.
Typical Twitter, just pranking us all the time.
So let's run a star.
So you are both here and we have no, let's hope we have no other issues.
Okay, guys.
So could you start by explaining what your knowledge proofs are and why they are important for blockchain scaling?
Yeah, until the time I dropped from the space, I think I can handle it.
If you start from the very beginning of the ZK proofs itself, it's some huge mathematical
thing that was invented by some great geniuses from my point of view, because it helps you
to perform some operations on the data data do some computationals or compute some
exact result without revealing the data itself so if you google it for example and go to the wikipedia
there is like the most common and simple explanation of the key proofs uh is about walda which is this guy from the picture and you give to somebody
the picture where is uh where somewhere is walda and he goes to the room without you without nobody
without any helpers just with the scissors and he should um find the world and give it to you without the original picture. So, and just like right before our space,
I was thinking, do we have some another example
that we could share within the space?
And I just came up with the idea.
So, Clara, I need your help.
How do you think?
Do I have your password from Telegram?
Do you have my password in Telegram? Do you have my password in Telegram?
Yeah, exactly.
Why do you think so?
Do you want me to prove this?
No, I don't want you to prove this, but I know you don't have it.
Maybe, but let's imagine that I have it.
I think you probably wouldn't want me to reveal the password for everybody here, just because it's kind of unsafe.
One thing is only me having this and you, and the other thing is everyone's having your password.
So I can prove it to you without revealing the password.
For example, if I say that like five minutes ago, you texted to a friend,
Hey girl, come on, how are you doing?
Sorry, I'm busy, I'm having the Twitter space
with two awesome guys, two great developers, you know.
Was it like this?
Oh, you got me.
Dima, you definitely got me.
Yeah, but actually it could be the coincidence, for example.
Not likely, but it could be.
So if you do it a lot of times, and I will say that you texted this, you texted this, you would believe me that I have your
password. So it's exactly how the key proofs work. I do not reveal it, but we all know,
exactly you know, that I know your password. So it's all about this. And for blockchain,
know your password so it's all about this and uh for blockchain uh it helps improve its overall
capacity so you could perform some compute you could perform some checks without occupying the
the time slots without occupying the the block uh the block capacity uh it's widely used right now
um from the very beginning when it become popular there was a some some how to say player
tools let's say layer tools for ethereum for example just because it's happy to be on the
theorem so there was a cdk layer tools because they allow you to just verify it ah we didn't
mention actually the key proofs consists of two parts. The first one when you do
do some compute and then provide some verification, some proof that you did it actually somehow
in already existing and everybody know how you do this compute compute and then you could give to somebody this proof and this
somebody could verify this proof and it's much more cheaper than do computations itself but
the key proof generation is kind of heavy operation and uh and it's more likely uh made off chain it's
100 made off chain and on chain you only have the proof verification so
you could do some maybe maybe a year of computation then do three years of proof
generation and then for maybe one day you can already verify this huge compute that you've
done but it's it's kind of approximate just for showcase but anyway yeah um and as i said for
for blockchain scaling it's a great tooling it's a great technology but it's kind of raw uh at this
point because uh it's still um how to say it's expensive in the manner of time so uh you need
a lot of compute power you need a lot of time to perform some
arbitrary compute and then provide the proof and after this that takes place
the cost of verification on chain but I think we're gonna discuss it later in
different questions which will be related to the key all right thank you
Dima and since we are also gonna be
talking about RISC-V architecture can you guys explain why has it become
particularly relevant in ZK space these days? Actually Claire it pronounces as
RISC-V so RISC-V is an open, relatively free CPU instruction set.
Thank you, Dima. Thank you, Banyan.
Why it's always me? Why do you blame me? I was silent.
About RISC-V, basically just an open source kind of instruction set.
So it's a Re recite book for processors.
And because it's tiny and regular, ZKVMs can translate each instruction into a proof circuit
with far fewer constraints than in other architectures.
So proofs come out smaller and faster, and that's why most of ZKVM engines use it,
like RISC-0, Jolt, and SP1.
And yeah, and RISC-V gain traction right now,
and it's become more popular,
and maybe it will be like the top engine
for smart contracts in the future we'll see all right so I
just got big lesson since this risk five and not risky I want to apologize
everyone uses we and I never read like it would be five so my mistake I'm not a
technical person so I think it's already forgotten.
Yeah, I see some people are requesting for Mike.
I just wanted to remind the open session
is going to be at the end of the X-Space.
So please stay here with us
and we will glad to add you to the stage.
And then let's go to the next question,
which is focused on VARA. And how does VARA
network currently implement ZK proofs in its architecture?
Actually, VARA network is not related to ZK proofs in its architecture. From the technical perspective it doesn't use any zk-like approaches but
due to the fact that we provide some platform some execution engine some compute environment
as we support any arbitrary computes within the wire network within the gear x as well
arbitrary computes within the VARA network, within the GearXe as well.
So it's easy to implement any ZK verification mechanism inside our contracts,
inside our programs within the VARA and GearXe.
So it's more likely the user space problem rather than the overall protocol
and engine compatibility.
All right.
Let's go to the next question.
how does EK-proof implementations
differ across major blockchain
platforms? Let's say,
for example, Ethereum,
and other networks.
Can you give us some comparisons or what do you think is better, how this works and why from your perspective?
Actually, for some precise comparison, I think we need a huge research here.
But in general, we can speak about uh implementation of decay inside
uh i think as far as i understand as as far as i know uh neither ethereum neither solana
or us we do not uh somehow adjust uh zk proofs inside the primary logic of the chain but instead
we provide the platform for custom programs to
implement zk verification mechanisms so uh i think it's all about which one zk verification system
you should choose it's all about the overall costs for you how how it's gonna be running
on your network or within your application inside some networks so for example on ethereum uh the
key proofs that accept like a huge data which is uh proof if proofs have a big size for example
10 megabytes it's not suitable for ethereum just because the call data inside the ethereum it's
the size of your payload of your transaction
which is going inside the smart contract this call data costs a lot so if you develop something
on ethereum you better prefer to some zk mechanisms that provide you a functionality
somehow reduce the size or maybe um verify not the exact the first proof but the verify the verification of the proof
for example you could uh combine polonky two as a first instance verification system the
k verification system and then wrap it into gnark system uh it's something that we do uh within the
ethereum bridge which we develop and then we provide the proof that we do within the Ethereum bridge which we develop and then we provide the proof
that we have checked the another proof so it's something like this and I think it's suitable for
all of the chains so for all of the major blockchain which is not the key based from
the very beginning which is not applicable to some for example example, RIGS-D solutions, some ZK-based rollups.
And so I think it's all about the sizes.
It's all about the compute, which is happening on the verification side and its speed
because the case of the recalculations and recalculations of some huge mathematical polynomials.
And if your system, if your blockchain, which provides the contracts functionality,
costs a lot from the from the perspective of computing some mathematical solutions, some math examples,
solutions some math examples zk wouldn't be such suitable for you in this very exact
and classic implementation you maybe would like to see some roll up on you or something like this
all right vajim would you like to add something to these questions
do you have some of your perspective on
this or Dima mentioned everything? I have a little knowledge about ZK and other
chains actually. I know only about RISC-V architecture but a little about ZK
pros. All right okay let's go to the next question. How does the standardized language support RISC-V impact developer experience versus other architectures?
Yeah, this is for you, question. Vive actually has a first class support in LLVM and GCC backends.
So you can, uh, so in like in Rust, in C++ and Zeke, any system language,
you can compile RISC-V targets.
So no problem with that, but, uh, and you don't need to, uh, you can,
you can keep using your usual crazy debuggers and CI's and everything works.
But, for example, the guys from Parity, they built their own RISC-V target
to implement their own needs for PolkVM, for execution engine.
And that's it.
But like for usual RISC-V, you can use existing tools,
and no new DSL or custom compiler like Solidity or Cairo.
So yeah, it has great support and ecosystem.
Okay, thank you Vadim.
So I'm curious, what unique advantages does WebAssembly bring to ZK implementation compared to RISC-V or other architectures?
compared to RISC-V or other architectures?
WebAssembly actually have some advantages
because it's portable.
You can run it even in the browser.
And for example, Polkadot, nir, vara uses web assembly and you can extend the dk
proofs using web assembly and but if you if we talk about the speeds and performance series five much better here but you need to have support supported on your chains and
have execution engines so that's it i think it's just two different things and webassembly is just
easier to use i think it's just more common yeah it's kind of more common because of the amount of tooling in the world,
amount of people within the community of WebAssembly. There is a lot of executors for WebAssembly,
for example, within the VARA, we have been using like three of them. Two of them is still in use
for VARA. And I think it's only a matter of time for RISC-V, or is it RISC-V?
It's RISC-V, right? Yeah. Yeah, it's kind of thing like iPhone X.
And so I think it's just a matter of time for RISC-V to adopt the community for them,
and it will be maybe even much more portable rather than uh web assembly
in some time yeah you will see i think it will become like a main main
i mean competitor to web assembly and maybe it will become like the main use for execution engines
in the future so yeah but WebAssembly is also great it's like a great thing invention in our time
yeah but but to be honest from from some perspective it's kind of incorrect to compare them just because WebAssembly always had its own purposes.
And at some moment, history, this purpose is extended on blockchains and execution environments.
So, but it wasn't originally some competitor to the processor systems.
There was just like 4VM stuff, this kind of virtualization stuff you know um while there's
five yeah yeah it appears to be the the main competitor to intel to arm and so i i think it's
much more um general stuff and much more harder to implement and adopt within the within the world actually rather than
web assembly which is just built in and everybody browsers almost yeah the main thing that web
assembly has a main use for in sandbox environment so you don't need to tweak anything you can just
load your web assembly module and run it and send in in a sandbox and that's it with the risk five
you should be more careful to run everything that's why it's the main user right now is in
azk proofs because if you want to put it on chain, you need to build a better execution engine and sandbox environment.
And that's why Parity built their own Polk VM supporting RISC-V.
Okay, this is maybe a good question or topic for discussion for the QA session here for listeners what they
think if RISC-V will be better than WebAssembly or if it can be or shouldn't
be compared so we will gladly have you guys join us for this next question Next question would be how do the implementation costs of different from VM architecture compare when building ZK systems, meaning differ from virtual machine architectures?
Basically, the question is what the difference between which one virtual machine choose when I build the K system in terms of costs.
Am I right?
I think if you choose some existing, already popular and adopted virtual machines, it will be approximately the same.
popular and adopted virtual machines it will be approximately the same so for example you could
verify the key proofs within the ethereum inside evm you could verify it inside the wasm you can
verify it on polkadot in some part chain that adopt um valid contracts inside uh you can implement
it inside vara you can implement it inside gear it, you can implement it inside GearXZ, it doesn't matter
actually. From my point of view, if you want to do some huge compute, you better to choose some
VMs which is originally built for ZK. So for example, RISC-0 as a virtual machine was built
to support some computational across RISC-V architecture for generating ZK proofs.
So it's always cheaper to do some project on this if you want to have ZK as your primary tooling for compute.
But from my point of view, now it stands on the very early stage it doesn't support
that much compute time it's hard to implement there it's not a lot of tooling it could be
unsecure sometimes so i think uh in the future there will be much more uh zk oriented virtual
machines but now we only have several ones and they're only getting
their hype they're only getting into the strain of tech and I think at some day we're gonna come to
the to the design of decentralized and distributed computational based on the case. So for example, as we plan to implement in a gear X sometime,
maybe soon, maybe not soon, but actually in future,
we are planning to adopt the key approach there.
So not every single validator will run some code,
will run some programs, but they will only
check the proofs of the previous run.
So the point of thek that it's unnecessary for
everybody to do the same compute it's unnecessary to everybody to go against greenpeace and so
you can only run it once and then provide the proof that it was computed correctly
and the vm could help you to do it more efficient but it's it's just a matter of
time and the matter of technologies which is popular and on hype right now
because the hype always moved the tech above above the current limits
All right, so I have three more questions and then we're gonna go to the live discussion.
I would like to ask about RISC-V. So actually, the good thing about RISC-V is because it's
open source and it's royalty free and you can modify it to your own needs.
And you can tweak it, you can modify it to run ZK Proofs,
you can modify the instruction set to using like smart contracts execution.
And I think that's a great thing comparing to WebAssembly, it's just not that robust and you cannot
modify WebAssembly architecture like you can do with RISC-V.
That's why it can have a lot more uses in the future, because in web assembly as we talked before it's just a
sandboxed like module and you can use it in sandboxed environments the best thing
yeah yeah as we have mentioned risk 5 originally came to the scene of these architectures for processors as the primary opposite to ARM to AMD.
And it was better from the perspective of ZK because it's much more compact.
First of all, it's open for everybody.
It's open for some modifications.
modifications it's open for new models uh and it's also more lightweight to to prove within the zk
It's open for new models.
math because you have less instructions that you need to support uh they're more like laconic i
would say um and i and i think it helps a lot to um to be adopted within the world. Because if something is simple and is able to be expanded,
this will be expanded in the right time, in the right place
for somebody who would like to use these benefits
rather than supporting some legacy,
rather than supporting some instructions
that you do not expect to be within your system and so on.
Yeah, there is five, it's just it has neuro native speed like really neuro native speed
because it's similar to other architectures, the most common x86 and ARM and WebAssembly is just unique another type of instructions it's more difficult to
you know to learn and use it's not it's not common to for a common engineer to use WebAssembly and know a lot about it.
But actually RISC-V is not near native speed.
It should be at exact native speed just because it's almost direct flow to the processor itself.
Yeah. because it's almost direct flow to the processor itself. Yeah, yeah.
All right.
I'm very glad you guys are so passionate
that we had this beautiful discussion between each of you.
But maybe we could add someone else to the stage for a change.
I see Sarah is requesting the mic. So let's
add her as a speaker and let's hear what she would like to say about this. Just think maybe
some discussion would give us more insights. Hello Sarah, can you hear us?
If not, I'm going to continue with the question.
And if you feel like you want to join us, feel free.
So what would be required to make Ethereum Fully ZK provable?
And how does VARA approach differ guys it depends it depends on which kind of the key provable characteristic we speak about
because you can already ZK proof the the whole ethereum network you could put inside the proof for example
checking of signatures of the validators across some block across some um already finalized state
and it could be the key probable so uh it's uh one of the primary approaches modern modern bridges zk based bridges built off but if we speak about
the key probable execution of the smart contracts I think it would require a lot of changes to the
EVM because EVM should be runnable on the risk-V architecture so I think it wouldn't happen maybe at least in the nearest
future just because it's a lot of work to be done it's a lot of economical sense and I'm not sure if
it could bring a lot of benefits to Ethereum right now because there is a lot of other problems there
is a lot of other ISPs going inside the Ethereum there is a lot of layer
twos appearing to be on Ethereum and maybe maybe for a theorem it's better to think how to support
these side projects which may consume the liquidity of Ethereum which may be in some terms parasitic on Ethereum which we were
discussing on the previous AMA when we talked about GeurXZ which is by the way not parasitic for
Ethereum. Yeah so I think at some terms Ethereum is the key probable right now but as from the role of observer of ethereum but not uh as execution
as execution engine itself so uh and for the water i think it's the same so we can prove everything
across the storage that some block took place in the history of of this blockchain that it was finalized there was such validators blah blah blah we just need to
select some genesis from which we gonna go with our proofs what what happened on vara on or on
ethereum um but to be able to compute everything in the key there is uh should be changes to the model of storage inside ethereum
there should be changes to evm there might be changes to to the contracts on ethereum because
the storage storage patterns will change and i think it will be a huge pain for all of the existing protocols on Ethereum. But if they could do this transition to maybe RISC-V,
to maybe some other approach that you allow to, like,
cheaply do the ZK proofs, it will be okay.
It will be great for Ethereum, but I don't,
I'm not sure if it's possible right now.
All right.
And what do you think about what are the main challenges for developers
when they are facing, which they are facing when working with Zgame Proofs
and different VM vm architectures
i think it more likely is something about the tooling about the community and overall
limitations of zk so for example right now you cannot do make as i said for example you have done
a year of computations you cannot actually do it within the ZK proofs because they
will be super huge. It will be
millions of millions
of petabytes for
the proof itself.
But I think it's just a matter of time
when the ZK adapts,
when the new approaches
appear in the world, when the new
mathematics reveals
some new opportunities
for ZK proofs
mechanisms.
Then I think we're going to talk
about some VM architectures because
as we mentioned, some ZK oriented
VMs is much better for
ZK rather than
typical ones just
because they were built for it.
Okay. like typical ones just because they they was built for it
so i have a last question which is also a question for all of you who are listening
uh looking ahead how might vm architecture evolve to better support ZK applications? And anyone guys here in the space feel free to join us for this question and we will be happy to hear your opinion.
I see we have a Mazzy here. Hi, can you hear us?
Yeah, I think I see me. Yes, we can hear you. can you hear us yeah okay yeah I'm sure in discussion that a friend of mine
helped me to the space so I just came into like no more about some fire
network but I keep hearing about what they mean tree was talking about so I
was just listening so I asked kind of ask, can you guys give a short explanation about what our network is building?
I can see it's like a layer one blockchain and it's backed by IKEA technology.
So I want to know more about what they're building and how you can help in the web3 space.
can help in the web3 space.
Like what's public serving in the web3 space.
Like what's probably in serving the web3 space.
Okay, guys, did you hear the question?
I think the question was like, what are we building if I'm not correct?
What is Vara network, right?
So yeah, Vara network is just a layer one blockchain.
Yeah. So yeah, VARA network is just a layer one blockchain, as you said.
And the main purpose is to run smart contracts.
You can build the Gear protocol, it's an execution engine for smart contracts and it's like built upon actor model and web assembly and
etc etc and the main benefit is you can run heavy on-chain programs smart contracts logic execution
it's like no costs, it's a really low cost and it's really performant and that's the VAR network, it's just a governance ruled layer one blockchain
that is using your protocol to run decentralized computing compensation.
So yeah, that's a basic explanation of VAR network.
Yeah, there is a lot of other than only VAR network from the Gear protocol, because the
Gear protocol is agnostic stuff that provides you the functionality of building some systems inside which actors could communicate with each other
from messaging and they have some set of syscalls which our executor provides and built above this
gear protocol engine primary executor there is layer one standalone layer one based on Substrate VARA network and there is the
upcoming Ethereum coprocessor named GearXV which is also built on the same engine.
So for example, you build your program once and could deploy it both on VARA and on Ethereum.
And there is also upcoming bridge from VARA to Ethereum just to cover some things between these interactions.
Yeah, I forgot to mention that the main benefit of Gear Protocol is just is if you're coming from
web to world you just can onboard with Gear Protocol like in five minutes, in 10 minutes, maybe in one hour, it depends.
But you can write your programs, smart contracts, just like any web2 development environment in Rust language.
You just start your program, code your logic and go on chain, test it, build it, ship it.
test it, build it, ship it.
I love the fact that
guys, I love the fact when someone asks you
about VAR and gear, you just go
and go and go and go.
You are the biggest promoters
I think you told him everything.
He just asked what is it
and you told him about everything.
I think it's supposed to be like this because we are developers and we do need to promote it actually.
The world must know about us just because we did great stuff.
We do a lot of researches, we provide a lot of libraries for userspace, we provide a lot of libraries for user space. We provide a lot of tooling for Wozom, for Substrate, for us, especially for us.
And we do provide and host a lot of educational events and programs.
So I think it's still up and we could share our educational hub maybe.
Yes, we can.
I wanted to step in because we have other people joining us here
today so I wanted to give the space to ask questions or to join us as well. So I see DeFi
May here with us. Can you hear us?
Hi, how are you? Yeah, I'm good.
Yeah, GM Claire, GM Geertec, and Vara Network, yeah.
So I got on board real quick.
You guys are hosting a contest, so I hopped on, and, you know, I love how you guys are
I love, you know, how this Vara Network is so scalable.
Yeah, it's very, very smooth, and, you know, if you areAR network is so scalable. Yeah, it's very, very smooth.
And, you know, if you are a developer
and you are coming in to the Web3,
you know, actually Ethereum, Bitcoin and all the rest,
they are so complicated.
I love how VAR network, with the help of GearTech,
they integrated and everything works smoothly,
you know, for developers and users, and users, providing a good interface
and great developing tools.
So that's it.
I love Vara Network and I love what they are building.
So I'll be right here listening.
So I'm a bit nervous for, you know, never mind.
Thank you very much.
Yes, thank you.
It's great to have some live feedback on our work, actually.
It's great.
Thank you very much.
All right.
We also have Essential here on a stage.
Can you hear us?
Would you have some questions or something you would like to add to this space?
Or guys, yes, hi.
Hi, I'm Claire. um so um yeah actually uh what i wanted to actually ask earlier was what must be asked
so um probably i'm just going to ship this into it like okay um i actually don't know how long you guys have been building so do you mind
sharing with us um how long you guys have been building and what do you what um have you guys
encountered that seems to be like one of the biggest um challenges um at the journey of
building like you know i know you guys are still um keeping stuff, but what has been the challenges so far and how do you guys intend on tackling it in the future?
Thank you so much for having me.
Actually, the Gear protocol itself started maybe in the end of 2020.
So it's been almost five years we are building this execution engine.
And there's a lot of things we have done already. There's a lot of things upcoming within this year
within the some some future time because we have a lot of
plans to have our vision, how some things should work within
the tech within the tech world. So I think it just needs a lot
of time and adoption inside the community for
some real users to come, share feedback, say what do they like, what they do not like, for example,
if something exists like this, which I'm not sure because we did a great job, as I said.
Yeah, and I think there is a lot of upcoming stuff in modifications to already existing
products like VAR network and for upcoming ones as a GearX.
And as we mentioned about ZK stuff, we're going to improve GearX.
Once we release GearX, in its first implementation, there is our white paper when we share some our future vision of
how should it be done with a zk based approach and will be much more efficient than right now
but it's still super efficient and much more efficient than other solutions scaling ethereum
all right um thank you so much um brother thank you uh i appreciate that that's actually kind of
explicit and definitely answered my question so yeah i'll actually pretty much take around
viral network and check out the community because uh i believe in i will so much believe in community
because i know um for a product to be successful, it needs the community adoption and the community to promote the product itself.
I'll be so much bullish on the community aspect and how you guys are building and I would love to
work along with the community. Thank you.
Thank you so much for joining us.
Feel free to join Discord and Telegram
and we will be happy to have you around.
That obviously is for everyone here.
Feel free to join Discord, telegram and we will happily
Ask answer you any questions you have
Also, I see we have
Marvin Hayes Marvin here today
Would you like to ask some question or do you have some comments about the X-Space?
Can you yes
hi can you hear me yes i just um want to make um comments concerning
what you guys are building um so far so good i went through the
the dock i went through the everything and i i i love what you guys are
building and i've been active in your community trying to interact and share more about your um
products to the community member and i just love everyone to keep the energy burning and yeah that Yeah, that was it.
Thank you so much.
So I think we could kind of wrap it up. I know all the guests were given time to ask some questions.
I think it's about the time.
We've been here for almost 50 minutes for now.
Dima, Vanim, do you have some closing remarks
you would like to share about maybe the space or anything
what is in your heart?
Yeah, as usual, we must say goodbye.
We must end this space.
But anyway, see you next time.
Thank you, you everybody for attendance
thanks for your question for live feedback it was great i think we we maybe need to host some
amai session with a lot of people joining and asking something in life maybe we we could
organize something like this and we would be happy to see you in our Telegram, in our Discord, in even DM messages.
So don't hesitate to ask something.
Don't hesitate to just contact us and say something.
We're going to be just fine with you coming to us and we would be happy to help.
Yeah, it was a really good session.
I enjoyed it.
And thank you guys for coming and for listening see you next time all right thank you guys both of
you for coming for answering all the questions thanks everyone who joined
today and then also all of you who join us at the stage really appreciate it and
yes see you at the next one as always it's gonna be the next month
and if you guys have any recommendation for future topic I will be happy to hear them so feel free to
send me or guys DM and we will gladly to get some ideas from you and yeah have a great day guys and
see you at the next one