Sei v2 Devnet Special w/ @jayendra_jog

Recorded: Feb. 14, 2024 Duration: 0:58:19

Player

Snippets

All right.
Good morning, good evening, good afternoon, everybody.
Can you guys hear me all right?
Yes, sir.
Nice, nice.
Happy Valentine's Day, everybody.
And thank you, Grover and Jay, for joining this Sayan Spaces.
We'll give it a minute to get everybody in here,
and then we'll kind of get started
talking about some recent developments
and what the Say community can look forward to.
Thanks, everybody.
Say is my Valentine today, Joe and Jay.
We're all each other's Valentine's, just for this year.
Yeah, bro, just this year.
It's not like it's been the same every other year for me,
but it's OK, you know, because I'm happy to have you guys at least.
100%, 100%, sir.
All right, I think we should get started.
Jay, are you with us, sir?
GM, GM, boys.
GM, sir, our fearless leader.
So yeah, let's get started.
I'll just introduce myself and then hand it to you, Grover,
and then to Jay to introduce yourselves too briefly.
I think many of us know who we all are,
but I am Sensei Joe, going to the handle at recently rugged,
and have been working for, say, for over a year and a half now
on the growth and marketing team.
So happy I have the pleasure to host these spaces
and to be able to discuss with Chads like yourself.
So Grover, would you like to introduce yourself?
So yeah, my name is Grover.
I am the head of marketing over here at Say,
and my job is to make really complicated things
that the engineers work on as simple as possible.
So yeah, it's like you said, it's a pleasure
and really excited to get into, say, V2 DevNet
and talk about what this means and who it's for.
All right, I will go last then.
GM, GM Saiyans.
I am the co-founder over at Say Labs,
and my job is to build those complicated things
that Grover was talking about before.
And damn, it seems like over 100 people
in this space story, so this should be a good one.
Awesome, awesome.
Well, I think that's a good segue
into talking about the Say V2 announcement.
So yesterday was a pretty big announcement for Say
with the release of the public DevNet.
Can you talk a little bit about what is the Say DevNet
and who is this for?
You know, is this for teams?
Is this for users to try it out?
Let's chat a little bit about it
before we go into the remaining of the spaces.
Of course, of course.
So Say V2 is the first paralyzed EVM,
and the DevNet is the,
I would say second major technical milestone
as part of the overall Say V2 release.
So in November of last year,
that is when we had put out the Say V2 proposal.
So this was essentially saying
this is what we want to be getting out to the community.
We're going to be having a governance vote on it,
and hopefully the community kind of resonates
with this as well.
In December, we put out an internal DevNet.
That's when we were largely complete,
and that's when we started having teams deploy
and helping us debug.
So this public DevNet is now the second major milestone,
and it's a huge deal, honestly.
What this means is that the past six to nine months of work
that we've been putting into this
is finally coming to fruition,
and we finally get to see people from the public
both come and deploy onto Say
and also use the applications that are there.
So it's a massive deal.
It kind of shows that everything that we've been working on
is coming to a good point,
and everything works end to end as well,
which is one of the most important things.
From here, there's going to be other milestones as well.
One of the most notable ones will be a mainnet launch.
But I would say for this public DevNet specifically,
there's a few things that we really wanted to do.
From Say Labs, we are a Silicon Valley team,
and we really believe in Silicon Valley values
of launching, collecting user feedback,
and iterating based off of that.
And in this case, we really want to get feedback
from developers, innovators, and just normal users
around what this overall end-to-end experience looks like
and feels like from their standpoint.
So the goal over here is to be able to collect feedback
and to be able to refine the DevNet
so that we can eventually get to a place
to an upgrade we can vote on to be deploying to mainnet.
So this is a call to action for people
to start exploring the capabilities of Say.
And we really want people to start playing around
with the decentralized applications
that are being launched on Say right now.
So we want people to try deploying apps
and also try using them end-to-end.
So yeah, I mean, overall, we want to make this seamless.
We want to make a transition to mainnet
be as seamless as possible.
So this is going to be the first step
in collecting that user feedback
to be able to have the best possible parallelized EVM
for users to use.
Awesome, awesome.
Well said, Jay.
And Sayans, you heard it from the man himself.
Help us test out Say v2.
Your feedback is very much appreciated
and it'll help with the mainnet launch.
So awesome.
So I kind of have some questions from the community.
And then later on, we'll bring up some Sayans
to kind of ask their questions to you directly
if that's OK, guys.
So moving on, what inspired the development of Say v2?
What were the motivations to propose this upgrade to Say?
Is this something that has always been on the roadmap?
Or is this a recent development?
I kind of know the answer, but I would love to hear it
from either you or Grover.
Yeah, I'll take a stab at it first,
and then Grover can hop in as well afterwards.
So supporting the EVM is something
that has been on the roadmap basically
since the genesis of Say.
The initial engineering pull request that we had put out
was in August of 2022.
So from the start, we've known that we
wanted to be supporting the EVM.
After the mainnet launch happened though,
so for any listeners that might not remember,
the mainnet launch was in August of 2023.
So almost exactly six months ago now,
I believe the public net launch date was August 15.
So tomorrow will be the six-month anniversary.
But after that release happened, in the spirit
of launching, collecting user feedback,
and iterating, we started collecting user feedback.
And the biggest thing that donated developers were saying
is that it's higher friction for them to deploy on to Say
because there is no EVM support.
And once we started drilling deeper into this,
there were a couple of things that became very clear.
The first is that trying to get someone who is not
crypto-native and then succeed on any ecosystem
is incredibly difficult.
Trying to get someone to leave their job at meta, which
is kind of what other teams are trying to do.
Getting Web2 engineers to leave and then helping
them be successful, that's not a recipe
for growing a good ecosystem.
So getting Web2 engineers in and helping them succeed
is a much more difficult process.
So you really want to convince crypto-native engineers
to come and build in any new ecosystem
because they're much more likely to build something that
is a killer application that really solves user problems.
So within these crypto-native engineers,
they don't want to move to new execution environments.
Firstly, because almost every crypto-native engineer right
now is an EVM developer, there's a tiny number
that are salon developers.
And outside of that, there's really
not any crypto-native engineers that
are building and move, for example, or other old VMs.
And these crypto-native engineers,
they don't want to move to new virtual machines,
new execution environments.
Because first of all, it kind of goes against their ethos.
They are EVM aligned and moving to something that is new VM.
It doesn't really vibe well with them.
And even from the technical side,
it's really, really difficult to be able to move to a new VM.
Because if you know all the intricacies of the EVM,
you're going to know what kind of attack vectors
to look out for.
And if you start building with a new execution environment,
and you make even a small bug, like one small bug out
of your entire project, that can result in your entire project
getting drained.
It can result in your entire project just failing,
as a result of that, and the company essentially shutting
So crypto-native devs, they strongly prefer the EVM.
And I think that's one of the learnings
that we had, which is that the EVM is here to stay.
I don't think other chains have really understood this yet.
I think there are still several other VMs that
are trying to make things work.
But fundamentally, one of the core realizations that we've
had is that the EVM is here to stay.
The question is then, what is actually
missing from the EVM right now?
So if you look at every single EVM chain right now,
none of them really have very high transactions per second
that they can process.
They're basically all at around 50 transactions per second
as the upper bound, in terms of what you can actually
see happening on mainnet.
And we realized that this is a massive, massive limitation.
And this is something that, when we were just
chatting with crypto-native engineers,
this is something that they reaffirmed just consistently.
If you're trying to build with the EVM right now,
and you can't get more than 50 TPS,
there are several things that happen.
The first is you see massive gas spikes,
because block space becomes a very, very scarce resource,
and everyone is competing for that.
Recently, I don't know if you guys
have been looking at Ethereum gas prices.
I think yesterday or a couple of days ago,
it was over 100 Gui for a couple of hours,
which was the average price to be transacted on Ethereum.
Even right now, it's probably somewhere around 30 to 50 Gui
to be doing stuff on Ethereum, which is ridiculous.
That is not something that a normal person is
going to be able to use at all.
Submitting one transaction, if it costs $5 to $10,
that's not going to be a place where a lot of activity
So normal users are just excluded from the EVM right now,
even though that's exactly the type of people
you want to be building these crypto rails for.
And it's also really bad for developers,
because developers have a much more limited design space.
If you want to build an order book-based exchange
with the EVM right now, guess what?
You just can't.
And because of that, you start seeing anti-patterns,
like automated market makers.
So Uniswap, for example, that type of structure
is not there in traditional finance,
because it's less capital efficient.
Unfortunately, in crypto, you have
to make these design trade-offs and use
these anti-patterns with the EVM,
because you just can't have this bigger design space.
And that's why we're like, shit, this needs to get built ASAP.
And that was the impetus for say,
V2, which is the first paralyzed EVM.
And the first paralyzed EVM is really going to unlock,
is we're going to be helping increase
the throughput for the EVM.
And when you have greater throughput,
then you're able to have cheaper gas fees,
you're able to have bigger design space for developers,
which allows for new killer application to be built.
So yeah, that's my chance there.
George, do you have anything to add?
I mean, yeah, already really well said.
I think this is the kind of stuff.
So I think we saw a few apps already start
to roll out on DevNet.
One of them is an order book, like an EVM-based order book,
which is awesome, called Saoram.
And I think we'll see more and more of these apps.
I'm kind of excited to see more and more of these apps that
couldn't have been built on Ethereum or Rollups.
But now you can actually build them on say.
And yeah, that's really, really cool.
So I think the other point that Jay made there
that's really important is you want to like, so say is
completely like, I guess the phrase people are using now
is EVM equivalent.
So you don't have to make any changes.
And there's no differences to sort of account for.
So developers can be confident, like whatever
they've proved, what's been proven,
like the code they've written, it's
sort of sat there with millions and millions of dollars
in it for months or even years.
Then you know that's kind of proven, it's tested,
it's going to work.
So that will just be, you won't have to make any changes.
You can just deploy those straight away.
And then like that's in the short term.
But I think in the long term, it's
what people kind of build in this space.
And I probably can't even guess what those things are.
And that's why it's really exciting.
Yeah, to just double quick on that point that Grover made.
What this means is that you can take a contract
from Ethereum L1, use the exact same developer tooling
and deploy it to say with no code changes at all.
And on top of that, users can just change their RPC
on MetaMask.
So instead of hitting Ethereum L1, they can start hitting
say, and that's the only change that'll need to happen
from a developer or from a user standpoint.
And I mean, that's just like a click of a button,
similar to changing to any L2 or something.
And then users can just start using those apps
directly on say.
It's a massive deal to make it this seamless.
Like a lot of ZK EVMs, for example,
they're not able to support something like this.
So developers need to go and make changes,
which adds in much more complexity for the DevX.
In the case of saying, it's incredibly seamless.
So that's something we've been working around the clock
to support, and it's just beautiful to see all of that
coming together with this DevNet.
Yeah, last point here, and I'll let Joe ask a question,
but I think the order of magnitude,
like it's literally a hundred X difference in TPS.
So if you go to L2beat, at letter L number two beat.com,
and you go and look at how I think the tab is activity,
you can see the TPS at Ethereum and ZK Sync at Arbitrum,
all these rollups are sort of cranking out.
And you just scroll through the max daily TPS,
and you can sort of see, okay, well, yeah,
we can see Ethereum 12 TPS was today's average
in the max all time is 22.
And then you look down at ZK Sync and Arbitrum,
all these guys, it's like between 20 and 50.
It's, yeah, when we're talking about thousands of TPS is,
so it really is like an order of,
two orders of magnitude difference.
So yeah, really, really excited to see what guys
kind of use this design space to build.
Very well said, lads, and it's super exciting stuff.
And it's also a good segue to kind of go
into the next question I have.
I know some people might understand
what a paralyzed EVM means,
but with Sebi to say is introducing the first paralyzed EVM.
And can you kind of go through, what does this mean?
And what are some of the advantages
of having something like this
that has never really been seen before?
Yeah, so if you look at every major EVM
based chain out there right now,
the way they work is they have sequential processing.
So if you have a hundred transactions
and you want to process them,
they'll get processed one after the other.
This is really simple for engineers,
like the code for this EVM is like much simpler
for engineers to write
because it's like really straightforward.
The downside is it does not take advantage
of modern hardware.
So those of you listening to this on your phones,
like your phones are multi-core machines.
They have multiple cores that are capable
of processing multiple work streams at the same time.
So it's really silly that current EVM implementations
do not take advantage of modern hardware
to be able to give better performance to users.
And that's what parallelization
in the context of parallelizing the EVM means.
It means taking advantage of all the cores
that are on the machine
to be able to run multiple threads at the same time
and to be able to process multiple transactions
simultaneously.
So one example here,
a hundred transactions before with sequential processing,
if each transaction, let's say it takes one millisecond,
then it takes a hundred millisecond
to process all 100 transactions.
With parallelization, let's say you can process
10 work streams at the same time,
and each transaction still takes one millisecond,
then it only takes 10 milliseconds
to process all 100 transactions.
That is a 10X improvement,
and it is a major, major improvement
on the amount of throughput that you're able to process.
So what George was saying
with a hundred X improvement in throughput,
the reason that's so big
is because now you're able to offer
much cheaper gas fees for users,
and you're able to unlock a much bigger design space.
And that's why what a parallelized EVM really lets you do
is it lets you get the best of both Ethereum and Solana.
With the Ethereum side,
you're able to get the EVM and all of the developers,
all of the mindshare,
all of the tooling that's built up around it,
and you're able to get the idea
of a really high performance execution layer
that you see would change like Solana.
So we think this is going to be the biggest way
to really help kind of democratize access
to doing stuff on chip with the EVM
that has been attempted ever since the EVM came about.
Yeah, I'm gonna do a marketing thing here,
and I'm gonna try and explain
parallelization in really simple terms.
And some of you might've heard this analogy before,
but I'm gonna riff it one more time here, which is,
okay, so imagine it's a really, really hot day,
and you want to drink, you're really thirsty.
And let's say that you,
there's one vending machine in the town that you,
like you're on the coast,
you're in the beautiful south of France,
there's one vending machine in the town,
and everybody's queuing at it.
It serves, let's say five different types of drink.
It serves Coke, it serves Sprite, it serves Pepsi.
So everybody, just despite which drink they want,
so even if you want a Sprite,
but everyone else wants Coke,
you all have to queue for the same vending machine.
So imagine if you parallelize this process,
now you have multiple vending machines.
So if you want a Sprite and no one else does,
you can just go straight to the front of the queue.
The Coke people still have to queue,
but you're gonna see like,
this is the analogy for parallelizing processes.
It's really like taking that one vending machine,
and now you can have multiple things happening.
Different parts of say state can be touched
at the same time, at the same time.
So yeah, that's pretty much the best analogy I have right now
for explaining parallelization.
And that's something that will be implemented automatically
on top of say.
So developers don't actually have to do anything.
It's the technical, the fancy way of saying it
is optimistic concurrency control.
But basically this means that developers
don't have to do any extra work.
It's just done on their behalf by the blockchain itself.
I really do appreciate the average Joe
kind of analogies and ways to kind of simplify.
It really helps to kind of learn
what makes this so special.
And speaking of things that make,
speaking of things that are special,
we've talked a lot about optimistic parallelization
and how this is a big feature of say v2,
but are there any other key improvements
that say v2 introduces?
I know on the same main account,
we've talked about say DB or some community members
like to call it say DBZ.
But what are some other things that are going to be
introduced with this say v2 upgrade?
Yeah, that's a great question.
So say DB is definitely one of the bigger things
that we're working on.
At a high level, like I guess taking a step back,
what are the trade offs with parallelization
and more broadly, like what is the downside
of processing more transactions per second?
Because I've been preaching about the benefits of it,
like cheaper transaction fees
and bigger design space for devs.
Like what is the trade off that you're making there?
And the answer to that is it leads to more state load.
So state is the active data that needs to be stored
by each full node to be able to process
any incoming transactions and to generate a state hash.
In a more simple way, it's basically token balances.
Like Joe has 10 say, Grover has 20 say, I have 30 say.
That's part of state.
And then it will also be smart contract data.
So for example, on like palette exchange,
it might have like, these are the different NFTs
that we're tracking and like,
these are like the existing like orders
that people have submitted on chain, for example.
So when you have more transactions that are happening,
there's more state that gets generated.
And the question is, how do you handle that?
So I'm happy to do a deep dive
if that's what the audience wants right now.
But for a more succinct answer to what say DB is,
it's just a way for us to be able
to better handle state load.
And there's a massive, massive amount of work
that went into this.
And we've seen huge improvements.
Some of the numbers that I'll mention,
I don't remember this specific number,
so I'll just give ballpark numbers.
I think we've seen a 90% reduction
in the amount of data that needs to be stored
by archive nodes.
We've seen around a 60% reduction
in the amount of state that needs to be stored
by full nodes.
And catch-up times, I believe they improve multiple times
and we commit times improved by over 200X.
So all of this is to say ton of improvements
that happened from that standpoint
to not only improve the performance of the chain,
but to ensure stability moving forward as well.
So that's one of the big things we did.
As we were talking about before,
optimistic serialization is really cool
because developers, they don't need to think about it at all.
And if you look at chains like Solana,
developers, they actually need to pass along
the dependencies that each transaction has.
So it adds in much more complexity to the dev workflow.
And I mean, just after chatting with engineers about this,
like engineers don't want to have to deal with this.
It's more complexity.
And what devs want to do at the end of the day
is build a successful project.
And they care a lot less about doing
a lot of complex technical things,
unless they really need to.
So just based off that feedback, we
introduced optimistic serialization,
which makes it very, very seamless for developers.
And the chain is just able to figure out dependencies.
On top of that, the other major unlock that we have with CV2
is we're adding in EVM support and making it
interoperable with everything that already exists.
So EVM will be able to call Cosmwasm.
Cosmwasm will be able to call EVM.
So a ton of improvements from that standpoint.
And yeah, all these, you can test them out
with the current public DevNet.
Yeah, reminder, all this is live right now on DevNet.
So go and check it out.
It's not a white paper.
It's not a theoretical piece.
It's right there right now.
You can check out the code.
Say is fully open source.
You can go and fork it, review it, try the apps out,
and everything's ticking over right now.
So yeah, go and check it out.
Yeah, that's a very important thing to touch on.
Say is fully open source.
This means that all of the source code
to run the Say binary, it is available online
for anyone in the world to see.
And it's really interesting to me
when there's other projects.
There's at least a couple of well-known projects
that remain closed source,
which means that they don't share their source code,
which it just goes fundamentally against everything
that I believe in for crypto.
Like if you're going to be building a blockchain,
which is supposed to be a transparent,
permissionless system,
you are introducing huge trust components to this.
Like if it's going to be closed source,
you're basically trusting that that team
is doing the right thing when they have closed source,
when they have like a closed source implementation.
So that's one thing that we're really proud of.
And I mean, we often get the question,
like if you're open source,
aren't you concerned about teams trying to like fork Say?
And the honest answer to that is like,
that's not really a concern at all.
It's kind of like if someone were to try to fork Ethereum
or try to fork Bitcoin,
and then do a better job than Ethereum or Bitcoin.
Like if someone were to suggest that,
you'd probably laugh them out of the room.
And I think it's kind of similar with any project like Say
or Solana, where if you just try to copy the source code
and like try to build something identical to that,
it's just not going to work.
So yeah, we think open source is massive,
and it is really what the values of blockchains
and of crypto are built on.
And any project that doesn't do that,
they're just fundamentally not really standing
for the values of blockchain and crypto.
Yeah, and speaking about that,
just with the, I guess the broader Ethereum community,
crypto community in mind,
I mean, it would be awesome if teams out there
working on Ethereum, if guys and girls
building projects around Ethereum
want to leverage any of the code that Say Labs has built,
then yeah, definitely do.
I think that would be like really, really exciting as well,
just to see people coming in and seeing the use
and seeing the, so the improvements have been made
and saying, cool, yeah, we're going to take that idea
and we're going to iterate on it as well
and publish your own work.
I think that's encouraged.
Well said, sirs.
Yeah, I mean, I could fork Say and build like a Joe chain,
but I wouldn't be able to fork the same community
or the talented team that comes along with it.
So very well said, guys.
So with that in mind,
what excites you most about this upgrade
if it's passed by governance?
And something I was wondering too,
like, is it a possibility
that this doesn't get passed by governance?
If say holders kind of band together and they're like,
no, we don't want this innovative upgrade.
But what excites you the most about it,
if it gets passed?
Yeah, so I'll touch on the second point first.
Say is a fully permissionless network.
It is fully transparent, fully trustless.
And this is going to be a governance proposal.
So there's definitely a chance that it will not get passed.
My general read on the community sentiment right now
is extremely in support of this proposal.
But when that governance vote happens,
I mean, honestly, anything can happen in it.
It would definitely make me sad.
Someone is really excited about a parallelized EVM
if that does get rejected.
But that's definitely always a possibility
with any decentralized network, like say.
Which is kind of why like,
I've been really excited to talk about the parallelized EVM
because I really want to get the community on board
with making a change like this.
And if the community is not bought in,
then like none of this can really happen.
So yeah, I guess that's one of the downsides
of building, of having a fully decentralized system
like say.
With regards to the initial question that you had asked,
which is like, what am I excited about
if this passes on mainnet?
I think, so fundamentally from my standpoint,
the biggest area that I would like to see improving
in the say ecosystem is more applications getting built
and more users coming on.
And that's why the parallelized EVM is really exciting
is because it unlocks for, first of all, EVM support.
So more crypto native devs are able to come on.
It allows for these crypto native devs
to explore the 50 plus TPS design space.
Like right now with the EVM
we were talking before several times,
you only get less than 50 TPS.
So what if you suddenly weren't limited to 50 TPS?
What if you could explore that design space between 50 TPS,
let's say 12,500 TPS,
which is the theoretical upper bound would say be two.
Well, then you're able to explore many new types
of applications.
And that's what I really wanna see teams start to explore.
This 50 to 12,500 TPS design space.
And I'm most excited to see kind of killer applications
emerge from that.
Because I think that's been extremely under explored
on the EVM right now.
You just have not been able to do that effectively.
And I think that will lead to a lot more usage
of the core chain itself.
Any thoughts from your side, George?
Yeah, exactly.
I mean, like, it's exactly this.
It opens up the ability to just to carry out
more complex transactions in the first place.
It opens up, I mean, the already obvious examples
of things like order books and, you know,
high performance, like gaming comes on chain.
I mean, traditionally, if you think about
what is crypto gaming, web3 gaming,
NFT is on the chain, but then, you know,
everything kind of runs off chain.
There's not much, the only part that really touches
the chain is the NFT sort of ownership in your wallet.
And you could bring more and more of this stuff on chain.
You can do more and more complex things on chain.
So that's definitely really interesting.
I think, yeah, like all of this stuff around
increasing the design space, it's gonna be things
that I haven't considered before.
And that's definitely why it's exciting.
I think there's definitely a few chains
that are around right now, which are all coming
from the same kind of angle, which is, hey,
like we can really get much, much better performance
out of decentralized systems than what's expected
and what's sort of accepted right now
by the majority of developers.
So I think that's gonna be really interesting
to see what comes up.
Yeah, that's my two cents on that piece.
Well said, guys.
Okay, before I kind of go through the last kind of bit,
I just wanna let the community know
that after this question, we're gonna open up the stage
to let some sayings come up and ask the co-founder
of SayLabs himself, as well as the head of marketing Grover
some questions about whatever you guys are thinking
about SAVY2, about Current Mainnet.
So if you guys wanna start requesting now,
we'll kind of start bringing people up.
But before we go into that, we did promise a bit
of an alpha drop in regards to Current Mainnet users.
I don't know if Grover, you kind of wanna talk
about our little surprise that we have
for the Current Say community.
Sure, yeah.
I'm a big fan of dropping alpha at the end of spaces.
So yeah, we'd seen a bunch of community members raise
a few concerns around gas pricing on Say.
So right now, I think some of you might have already spotted
but there's a governance proposal to basically been pushed
by SayLabs to reduce the gas cost by 5x on Mainnet.
So if that passes, it will be enacted on Saturday.
So yeah, this Saturday coming up.
So yeah, 5x cheaper gas on Say very, very soon.
Absolutely love to see it.
I mean, it was, as a user say to myself,
I didn't notice like the fees being high
but it's a nice pleasant surprise to know
that they'll be even cheaper.
So yeah, let's go ahead and kind of get some sayings up here
to ask some questions.
So feel free to request guys
and I'll go ahead and let some people up.
All right, so for the first saying up here,
iceberg, how's it going?
It's going well, it's going well.
I have been in the Say community for a couple of months now
and I've seen the organic growth on Say
and how the vibe is and the technology aspect of it.
And are the question when it comes to Oracle,
is it band protocols who's doing the Oracle stuff
or have you guys been talking with the chain link?
G.I.J, if you wanna take this one, I'm happy to.
Yeah, I mean, I can only speak on behalf
of what Say Labs is involved in.
Say Labs is not involved in any of the negotiations
with like external validators to be launching with Say V2.
In terms of what's there on Say V1 right now,
there's a native Oracle.
So if you want price feeds for some major assets
like CCC or ETH, these are all supported
just through the native Oracle.
So I mean, that is a decentralized Oracle
that is being run by Say network validators.
So it's, I would say the standard for Oracle is Ente.
On top of that, I believe there's also Pith,
which is there on Say V1 right now.
So if you want data feeds on the Cosmwasm side
that's supported by Pith.
But yeah, George, do you wanna add something else?
Yeah, yeah, so like Pith is, so DeFi apps,
like I think LaVonna, a few others are using
some of the more exotic sort of, I guess you could say
long tail asset feeds that are provided by Pith.
And then there's like the enshrined Oracle
from the validator set as well
with like a smaller set of price feeds.
Well, that's very good that you guys are in with Pith
because they are very good in the pricing
and have been developed themselves in a very good way,
how they attack the pricing
when it comes to the pricing, so it's very nice.
But the thing that I was asking about Chainlink
and the other type of protocols
or other type of things that help the community
when it comes to like randomization
of like gamifying randomization when it comes to VRF.
And that kind of things, I'm very interested
so we can have more gamified experience
when it comes to the NFTs and et cetera.
Yeah, I believe Pith, last I'd heard
through the grapevine is that Pith will probably do
something like that on the EVM side as well.
So stay tuned for announcements.
I don't wanna drop too much alpha here,
but there's one piece for you.
Thank you very much.
It sounds like alpha for me,
so I'm gonna deep dive it more.
So thank you very much.
Thank you, Iceberg for the great question.
Okay, so we got a couple more Chads up here.
Thomas, GM, would you like to ask a question
for any of the Sey members up here?
Yeah, GM, GM, everyone, this is crypto boy.
So I'm really excited to be on the spaces.
Shout out to everyone, all the Seyans on the spaces.
I mean, it's always an honor to hope on spaces
that half my team said,
and I appreciate this opportunity.
So my question has to do with setting up the wallets
between the EVM side and then the cosm wasn't side.
Like how easy can someone go through the process
so that doesn't have to deal with lots of technicalities
in certain of like, that were like in a simpler manner.
That's my first question.
I think Thomas broke off for me a little bit there.
Was a core question like,
how do you support wallets to sign transactions
on both EVM contracts and on cosm wallet and contracts?
Yeah, exactly that.
Yes, yes.
Yeah, so the interoperability piece
is probably the most complex part
of the user experience over here.
There'll be updates coming within the next month,
like more clear explanations around how to do this,
but it will be possible to sign transactions
on both sides between cosm awesome
and the EVM side as well.
I'm preparing some diagrams to help illustrate the point
because yeah, it's somewhat of a new concept,
but it's gonna be, I think worth a little wait
and we'll make sure we've got the best information out there
so that everybody's understanding the process.
But it's not, yeah, the end goal is of course always
to have the least friction in the user experience
and you shouldn't know that you're having to choose
between one or the other, exactly.
That's okay.
Oh, go ahead.
Okay, thank you.
Just last question and then some of the same kind of come up.
I mean, currently there are projects deploying,
but we need more projects to deploy.
So what are some of the strategies the team has put in place
and making sure we get more developers
from existing communities to deploy and say?
Yeah, so I'm from Stay Labs.
I'm much more associated with the core technology.
I don't know if Grover or Joe had anything to speak
about there, otherwise I could just give my thoughts
on what Stay Foundation is doing.
Yeah, I know.
So there's like you've seen, I think we put out a thread
earlier today with like a good healthy amount of teams
who say native teams who are pushing
like the first apps to DevNet.
So I think it looks pretty healthy on that side.
I think the main things that developers are always looking
for is a healthy community to sort of come
and share their apps with and to build for.
So always looking to make sure that the community
is being listened to and being heard,
making sure that we have an inviting place
for developers to come in the first place.
So guys like Cool Times up here,
like running their spaces, all of the sort of the podcasts
and the blogs and the YouTube and everything,
this is what is super, super inviting to developers
in the first place.
And they're like, yeah, this is somewhere I wanna come
and build, this is kind of happening.
So I think that that's from my side,
like one of the most important parts in attracting developers
to like a thriving and very like active ecosystem.
Thank you very much, Zegruva and then Jay, I appreciate that.
Thank you for the awesome questions, as usual, Crypto Boy.
And this wouldn't be a true safe spaces without Cool Times.
Cool Times, how you doing, brother?
Good, I'm doing like some stuff on my laptop,
but I just heard you guys maybe like five or 10 minutes ago
talking about the transaction fees.
For people on mainnet right now,
and I might've missed a little bit,
but I am curious to hear about,
like how does that actually happen?
How do transaction fees get cheaper over time?
Is that something that is just like naturally gonna happen
or do you guys have to go in there and do it?
I'm a little un-baptized when it comes to this stuff.
So just curious to hear you guys
kind of talk a little bit about that.
Yeah, so there's a consensus enforced minimum transaction fee
per unit of gas that is consumed.
So that is something that governance sets.
When the chain genesis happened,
governance set that based off the initial token price.
The token price has since changed
compared to August of 2023, so compared to six months ago.
And transaction fees are substantially higher now
because of the change of the core say token price.
So because of that,
there's now a governance proposal that was released
to help account for that.
Moving forward, there will be like,
one of the work streams that is really interesting right now
is around multi-dimensional fee markets.
So there will be kind of investigation done
on how to better account for that.
Because from the standpoint of say,
there's a lot of really interesting routes
that you can go down.
Like Ethereum, for example, had EIP 1559.
Parts of that design are very, very odd,
but it doesn't account for things such as parallelization.
Solana has their localized fee markets.
And in Solana's case, it is also very well thought through,
but just because of their technical architecture
with like continuous transaction,
consumption, transaction, I guess execution,
it results in things like jitters,
which I mean, that might be a little bit too technical,
but I think there's a lot of really interesting ways
that we can explore having multi-dimensional fee markets
on today to have much more accurate resource pricing
per essentially per piece of state
that is being touched on the core chain.
Cool, I just had one other quick question
about ETH Denver at the end of this month
because DevNet is obviously
a really interesting development.
I know that there's gonna be a ton of chat
ETH developers at ETH Denver.
How do you guys kind of plan?
And I'm not sure who to really direct the question to,
but what's kind of the say plan
to kind of attack ETH Denver
and make as many of those chat developers
aware of what's going on right now?
I believe the plan is to throw a big party.
I think that's in a nutshell,
but yeah, it's definitely gonna be members
of foundation down there,
and labs will be down there as well,
DevRel and guys on foundation BD and all kinds.
So yeah, there's gonna be a good little army
of team members down there.
And if anybody listening is going to ETH Denver,
make sure that you've checked out
the parallel brunch.
So remember it's breakfast and lunch at the same time,
parallel brunch, right?
So if you're interested in coming to that,
then definitely sign up.
I think the event is oversubscribed 6X already,
but if you're a longtime sailor, definitely apply anyway.
And yeah, there'll be a bunch of people down there.
So hit up the guys in the,
all of the guys have a little say badge on Twitter,
just drop them a line if you're heading over.
Thank you so much, cool times.
Looking forward to your spaces later if you do one.
If not, no worries, we love you anyways.
So say Hunter, I brought up as well.
We'll do a few more questions guys,
and then we'll kind of wrap it up
and let the builders get back to building.
So say Hunter, how's it going?
Do you have a question for any of the members up here?
Hey, how's it going?
It's more top end.
So once we're on V2,
does this mean that I'm able to go on remix
and then just publish contracts straight from there?
And yeah, let me,
I'll let you finish that first part.
Yeah, yeah, that's doable.
So I mean, even with this public devnet right now,
you can do that.
All right, perfect.
And then I know you probably restated it a little bit earlier,
but is the long-term goal is to provide documents
for devs to add Metamask to their websites?
Because right now it's currently Compass and a few others.
So is there going to be some integration for that as well?
I know you kind of touched on it.
Yeah, yeah, so there will be an integration with Metamask.
And I mean, the long-term goal that we want,
I mean, and this is already feasible right now,
is for all Ethereum tooling to be reusable on say.
So for the public devnet,
everything that's part of your core EVM development workflow
will just work with say.
There will also be other integration set up
to help ensure that even like stuff
that is not related to the core development workflow,
but that is more accelerated
such as like indexers or something,
all that tooling will be there as well.
And then all the user-facing tooling,
such as like Metamask, for example, also works.
And you can use that even right now with CAV2.
Like if you want to use any,
if you go to the docs for CAV2
and then you look at like the instructions over there,
you can install Metamask and then go and play around
with applications that have already deployed
on the public devnet.
So all that tooling should be reusable.
All right, perfect.
I think, yeah, that was the only questions.
Thank you for the great question.
And all of the questions have been really great actually.
So we'll go ahead and do one more
and then we'll wrap it up.
Dogwiz, GM, sir.
Yo, yo, yo, how's everybody doing?
Hoping everybody's doing, having a great afternoon
or wherever you may be.
Can you guys hear me well?
Yes, sir. Yes, sir.
All right, awesome.
Jay, nice to meet you.
I know we're on the stage in cool time space,
but we really didn't get to talk.
I guess I have a few questions.
My first question was kind of piggybacking
off of Say Hunter's question.
So they're gonna be able to use EVM rollups
and implement that really easily.
What about the contracts and let's say NFT collections
that are right now out in the same network, V1?
Will those people have to merge, migrate?
Is there anything specific?
How about like marketplaces and exchanges?
Will they have to kind of update their backend code
or something like that?
Or how will that work?
That's something I've been wondering.
So that was my first question.
Yeah, that's a great question around interoperability.
So we're introducing this concept of a pointer contract
and pointer contracts will...
I mean, I don't know if you're like familiar
with the computer science term,
but it'll allow the same data to be referenced
from like different, I guess, interfaces.
So in this case, it would be like the Cosmwaza interface
and the EVM interface would be able to interact
with the same data.
Example here would be for an NFT.
This would allow an NFT to be usable from both the EVM side
and from the Cosmwaza side.
So there will be documentation, as we've been mentioning before
in a blog post, it'll be more cohesively outlining this
in the next few weeks.
And that's something that George will be helping out with.
But all of the things you described,
like they will be possible too.
Awesome, that's kind of what I was wondering.
Yeah, I'm actually my background
as a network system administration.
So I do know what a pointer system is.
Okay, that's great, that's great, thank you.
And then my next question is, so we saw,
the past few days we had an exchange come up
and it kind of wasn't the best.
There was an exploit happened and stuff like that.
I was wondering like,
is there anything that you can tell me at least?
So I'm part of a group.
I'm the founder of The Sake of All.
Like our main goal is kind of to protect the ecosystem
right now and try to avoid all of that stuff from happening.
So I was wondering, is there any vetting steps
that maybe I can DM you and we could go over them
that I should probably keep an eye open?
I just wanna be able to vet using the encountering
or talking to first correctly
to kind of avoid all of this stuff.
But yeah, that was, it was more of a question.
It was more like, hey man, I need your help.
But I think my next question would be.
Grover, did you have any thoughts
from your side around that point?
Sure, yeah, I guess.
So yeah, I mean, there's always like a bunch of steps
you can take to like make sure,
I mean, like crypto is definitely the Wild West.
There's no two ways of putting it.
There are like risks that you as a user,
we're taking on this burden of like self custody
and we're taking on this burden of like,
we're our own sovereign individuals
or this sort of stuff, which is beautiful,
but at the same time,
then we need to sort of be quite careful
with how we interact with new projects, with new teams.
So yeah, I think it's kind of like the same playbook.
I mean, like on a personal level,
not speaking for say labs,
but like, you know, you always need to vet a few things,
like, you know, is the project audited?
Is the project open source?
Is the team known?
All of this kind of stuff.
So I mean, like, that's just like a very generic answer.
But yeah, I think that's just like general advice
to anyone who's looking to vet and decide like,
you know, how should I interact?
I mean, even on say DevNet, you know, it's really important.
Like, and I put it at the end of the threads,
recommend, you know, there's gonna be a bunch
of teams deploying, like all kinds of teams.
Some like a lot I expect have fantastic intentions,
but some might not.
And so you have to be sort of conscious of that.
And I recommend like using a clean wallet,
if you're interacting with new apps
and connected to new sites,
like all this kind of like hygiene stuff is important.
So yeah, I think that's something that you just,
yeah, have to bear in mind,
especially because as we open up to like thousands
and thousands of new developers, you know,
right now the pool is pretty small
in the Cozumwurzum world.
But when you get into EDM,
suddenly you just like a hundred X number of developers
you can deploy in your chain.
Stuff that will become more and more relevant
for us as a community to bear in mind.
No, that makes total sense.
Again, like I said, we're trying to create
like a vetting team of sorts, you know,
you know, we have a couple of, you know,
really intellectual members in the Kaba'a.
And, you know, I think utilize their smarts
and their research abilities of, you know,
weed out the obvious ones, right?
But okay, thank you very much guys.
And then my last question was,
I was checking out the say docs and like, dude,
first of all, awesome.
Can't wait for like the four major advancements
that same V2 is bringing.
How does like one get featured on those docs?
Like, you know, a project or anything like that.
I saw you guys had three projects feature there.
So I was just wondering what that process is
and get on there.
Yeah, I think, so the first thing,
I think there's a form on the foundation site now,
which is like, hey, let us know about your project.
I mean, so like, if you've never spoken,
if you've deployed an app or an EVM site
and you've never spoken to say,
you don't know how to get a touch,
like that form is a fantastic way to do it.
Honestly, if you DM, like I said,
pretty much anybody with a say logo,
they'll be able to steer you in the right direction.
And yeah, if the apps kind of like, you know,
you're like, yeah, this is ready to go.
I'm really happy.
Like it's working over pretty well.
And it's a great example of like a good user experience
for the EVM site, then 100%, man,
like anybody can get an app up on that site.
So yeah, that's I think what I tell people
if they were looking to get onto those dogs.
Awesome, thank you guys so much.
I appreciate you.
And again, thank you again for, you know,
answering my questions and being here.
I appreciate all you guys work and, you know, let's go.
I'm ready for red chain, good chain summer.
Much love, Douglas.
Thank you so much for the great questions.
And I know we have some other people requesting to speak,
but I do want to give some time back to Grover and Jay
to kind of get back to building
and making sure that save me two is ready, right?
So I think this is a good time to wrap up the spaces.
Grover and Jay, if you have any closing remarks,
now is your time.
And then we'll kind of wrap it up and get back to cooking.
Yeah, so from my side, just a couple of things.
First of all, thanks everyone for joining in
on this conversation.
A ton of great questions.
If you all have anything else,
feel free to DM me on Twitter, like tag me in a post,
tag me in a tweet and I'll try to respond.
Second thing is, so we put out the public,
we want to get feedback from people, right?
Like one of the biggest things we want to know is like,
what kind of user pain points are coming out of this
and how can we make this the cleanest user experience possible?
Internally, like Grover and Joe can speak to this as well.
We are kind of maniacal about just building
the best products for users to be using.
So the ask for people on this call right now
is to actually try out the public DevNet.
If you go to the V2 docs,
which were linked in the blog post,
also linked in the tweets yesterday,
you can install MetaMask,
make sure that you're pointing to the right RPC,
use the faucets to get tokens,
and then actually play around with the apps.
There's also a process to submit feedback over there.
It'll link you to a type form to submit feedback.
Please, please, please try that out.
Anything you do over here will just be instrumental
in helping us build the best type of product
for the end user.
So we'd really appreciate that.
Yeah, that's it from my side.
So thanks everyone for joining.
Yeah, echoing everything Jay said,
and I will add red, fast, good chain summer
sounds great to me.
So cheers everyone.
Thanks for listening.
Thanks everybody.
Thank you Grover for hopping on.
Thank you Jay for hopping on.
I know you two are very busy.
And thank you Saiyans for coming in and supporting.
So everyone's left with a bit of homework.
Try out say V2.
And yeah, let's make this good chain summer happen.
So cheers everybody.