Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Polygon Protocol Governance Call #18
Recorded: April 4, 2024 Duration: 0:36:42Space Recording
Full Transcription
Thank you. so Thank you. I'm going to go ahead and put the bag on the top of the bag.
I'm going to go ahead and put the bag on the bag.
I'm going to go ahead and put the bag on the bag. so I'm going to go ahead and get started. Music Thank you. I'm going to go ahead and put the bag on the top of the bag.
I'm going to go ahead and put the bag on the bag.
I'm going to go ahead and put the bag on the bag.
I'm going to go ahead and put the bag on the bag. Thank you. okay awesome um welcome guys to pptc number 18 I'll just link the agenda in the chat. In terms of the agenda for today's call, there's three main buckets. and also the rollout onto a moya as well which occurred more recently um we'll then dive into
uh pip 22 which is a proposal um to kind of merge in data pruning to the bulk line
and then we'll finish off with some with some discussions around eip 3074 kind of abstraction.
Cool, okay, so to kick it off,
obviously Napoli upgrade went live on POS Mainnet March 20th.
Initially things looked to be running smoothly,
so milestones and then checkpoints,
which was kind of the question
as there was a change within
heimdall to kind of pass between blob transactions that occurred um sandeep
and the board team i don't know if you guys have any further updates as there's been a
little bit more time for it to to settle in now um yeah
Yeah.
Sorry, can you repeat that, Harry?
Yeah, so, you know, the Napoli half-up upgrade has had some time to settle on mainnet now.
You know, initially things were looking fine, milestones, checkpoints are looking good.
Yeah, just wondering if there's any kind of findings since now it's had a little bit more time to settle in.
Right, right. Everything looks good after the Napoli hard fork.
There have been a few sync related issues, but that's nothing to do with the hard fork.
Again, we are continuing to make some improvements there, including debug, a few of the nodes which are stuck at some block numbers,
but yeah, it's nothing related to the hardware, like I think.
Yeah.
Okay, cool. So everything looking good there.
Do we have any folks from the Testnet committee?
I know we went live on Amoy a little bit later.
Obviously, we did the Testnet phase on Mumbai,
but more recently went live on Amoy.
Yeah, I don't know if we have anyone from the Testnet committee
that wants to present any findings there.
Sure. Good morning, Harry.
I can weigh in a little bit.
It may be sort of no news is good news for,
at least for the Napoli rollout this morning or about 20 hours or so ago.
All appears to be smoothly operating there.
So I guess no news is good news at this point.
Yeah, it certainly is.
It certainly is.
Okay, cool.
All right.
Thank you very much, Scott.
Okay, so moving on.
Next item on the agenda is ancient data pruning.
So PIP32 is a PIP put forward by Minav.
I think we have him on the call um and i don't know
if you want to do uh yeah a quick run through of the proposal i know we have uh del wang on here
who kind of initially came up with the idea for this or at least to merge it within pos
in POS.
um so yeah i don't know if you want to give a quick run through on that one
So yeah, I don't know if you want to give a quick run
through on that one.
Yeah, sure.
I can give a brief about this, basically.
So the aim of this BIB is to enable ancient data pruning
inside our primary client, which is BOR.
Now, ideally, the current support for pruning is pretty much what gets,
gives, provides out of the box, which is like pruning the actual state,
which gets accumulated over time.
And there are some dangling, there's some dangling data as the chain progresses.
It gets accumulated and isn't cleared from the database so
that's that proning uh which generally people refer to uh but so uh in like this this approach
is a pretty different so uh because boris derived from get it kind of stores data in into two
separate uh structures one is the ancient, which is like the older blocks.
I think there is the limit of 90,000.
So all the other blocks, apart from the last 90,000 blocks
are basically stored in this ancient data store.
And only the recent 90,000 block data
and the state of the recent most 128 blocks is stored
inside this level DB structure.
So everything else moves to ancient data.
I think so.
We did some analysis that it kind of accounts for around 50% of the total data, but these
can depend on when you last pruned your node, but yeah, that's a separate discussion. But yeah, it pretty much is quite good amount of data.
Now, the aim of this feature, or I would say adding this support is basically allowing
someone to prune that data, those who don't really need this.
So for someone who is serving RPC or giving RPC support over a full node, I think it's a simple decision
that they don't really need to prune anything because they'll have to rely on that data.
But for those node operators who just rely on the recent most state and recent most block
data, they can basically benefit because it basically reduces some space for them.
And they can basically prune all those historical blocks.
They don't need to keep it.
So this basically means they won't be able to serve any RPC queries
over that data, and they won't be able to start this data
over the peer-to-peer network.
So for someone, so this affects someone who is syncing from scratch.
We had some initial concerns there that how will this play eventually going forward.
We were just assuming the worst case scenario that let's say everyone tries to prune, everyone
goes ahead with pruning the data, then there will be less number of nodes will be there
to serve the data in the peer-to-peer
network.
We had some concerns around it, but yeah, I think pretty much a lot of people, like a
lot of regular users generally rely more on snapshots.
So just because there is a possibility of less data in the peer-to-peer network, we can't really
prevent this feature from being there.
So yeah, that's basically the discussion in favor and against of this particular feature.
Yeah, also to add to what Manoj said, we will anyway continue to have archive nodes in the network, which will have all the data.
And so there will be Eragon nodes as well, which will be able to serve the data if any node is syncing from scratch. scratch and on top of it we will also push the community and you know to at
least run a few nodes without tuning the ancient data folder so the data
availability like even if somebody wants to sing their node from scratch we will
ensure that you know this is there like it's always available. And even the snapshots, we will have snapshots with the nodes which have the entire data as
well.
So yeah, that will be there for vector meeting. that all these arguments basically ensure that data
availability will not be a problem.
And so we are also in favor of going ahead
with merging this PR with this feature.
Yeah, but I would also like to get others' thoughts on this
if anybody has any concerns with moving
ahead with us.
Hello everyone.
I'm the author of the block action pulling.
And I introduced the feature from BSC.
As you all see, currently about 13% of the data is ancient VRISDB.
And I think this is just a trade-off.
And if someone wanted to run his own,
no, he needed to download all the ancient data.
And this data is really a large amount of disk.
And so for this reason, if we want to have a better data availability,
but since people want to run the node as a disk, the source is very huge. So I don't know which one is beta,
data-ability or ancient data.
Maybe you need to read more.
Thanks, Damweng.
And just to clarify as well,
this isn't, I i guess technically an upgrade
that we're going to a hard fall this is uh i guess more of an opt-in feature that you guys are
essentially supporting within the like official ball repository right so um yeah just want to
like clarify that one point and and and secondly i think one concern that i've seen within some of the discussions is that
you know we don't particularly want validators to rely on on archive nodes so um i don't know
if there's a way in which you can like uh ensure that you know this feature wouldn't be available for validators, or if there's any way to mitigate that one concern.
Yeah.
Manu, do you take that?
Yeah, sure.
I don't think there's a very simple way to make this feature optionally available for
the different kind of nodes.
I think even if we do so at a client level, people can easily bypass that
by just making the change in the code and building a new binary.
Yeah, I mean, there's nothing which we could do to enforce this particular thing,
but yeah, maybe if there are some other opinions of how to be listened to.
Okay, Sandeep, I don't know if you guys have 10 timeline for when you would want to potentially go forward with this um yeah we could in the meantime try and have some more async discussions on on like some of the drawbacks
yeah i think uh since the pr is a little old uh we would need to rebase it um
Since the PR is a little old, we would need to rebase it.
It is developed and if there are any merge conflicts, we might have to look at them and ensure the tests are running fine.
All the tests are passing.
So, yeah, we might need a couple of weeks.
Yeah, unless Manav, if you're having the results or delivering,
if you can help us with that as well.
Yeah, I can have a try, but I don't refuse a code for Polygon for a lot of time.
Maybe I need more time to refuse the changes.
OK, OK.
Yeah, maybe we can, Mano can also take a look.
It's pretty straightforward.
And if there are not any conflicts I think should be done
pretty quickly.
Else yeah we will have to see, we will have to evaluate.
So yeah yeah I think rebasing shouldn't be a like a major issue but but because we also have the PBSS feature, I'll have to give a second
look at the PR again to see if it kind of affects those things in any way.
I don't think it does at a high level, but yeah, I'll have to take a second look.
So, yeah, I think since there are no other concerns raised, I guess we will go ahead with this.
I'll go ahead with this, Hady, and we'll keep coming in the next PPGC also.
I think we'll be informed about the changes.
Okay. Yeah, sounds good, Salih.
All right. If there's no other closing thoughts on that one we can move on
okay right then okay so the next point on the agenda is
EIP 3074 so you know for those of you that have joined over the last couple of calls, this has been, you know, kind of the central topic,
I guess you could say.
You know, Daniel Gresko, who's on the call today,
he's kind of led those discussions,
produced reports that have been kind of discussed
at length with Ethereum researchers
on the Polygon forum.
So, Daniel, I don't know if you want to give
a quick summary of like how those discussions went like kind of the general consensus of
of yeah the direction you think is best to take based on those discussions and
and yeah any of the updates that you have yeah so uh since last pGC, we saw some activity in the forum post where there was debates going on over the different account abstraction proposals.
The delegation transaction type, EAP5806, received little to no attention.
And I think that it was also a bit influenced by 3074 coming up again in the
Ethereum all-core dev meeting. So there were basically two camps, 7560 and 3074
were the most vocal support or had the most vocal supporters. And generally speaking,
I would propose to go with EAP3074 for the following reasons. First of all, regarding RIP7560,
regarding RIP 7560, it greatly enhances ERC for 337 wallets. They already exist and they already
have an ecosystem on the Polygon network and they don't offer too much more benefits to those
smart contract wallets because a lot of the benefits would be making them cheaper to use on Ethereum, for example.
But while gas is already very cheap on Polygon, it doesn't make it so much better to use.
Additionally, it doesn't offer as much benefits to EOAs, which was the main reason
we actually wanted to go with some account abstraction
proposal because features like matching
were highly requested and are also not possible
with RIP 7560.
And the second big reason is also with the Polygon POS network
transitioning to zkVM at some point in the future using the zero approver stack. We need to be
sure that also these upgrades that we add, the EVPM plus upgrades that we add to Polygon POS,
should be able to be also proven.
And we have confirmation that 3074 could be proven,
but for RIP 7560,
it's a bit more complex implementation overall.
And that's why we don't know yet a timeline
or how long it would take to be able to prove this.
Lastly, there is a big kind of chicken and egg problem.
This was discussed in the previous calls as well at LYNX,
where a lot of integrators are hesitant
or even chains are hesitant to implement 3074 because of unknown risks.
But at the same time, no one wants to go first, but everyone would like to try it out.
So what I would propose is implement 3074 on the Amoy network, have a look at the risks or issues that come up. Also, not just from a user safety perspective,
but also client integration. So how does it affect block explorers, wallets, and so on and so forth.
And then start working with integrators, see how or even apps, how it would be useful to them what kind of safety measures
do they need um and from there kind of iterate on 3074 on testnet until we find a solution uh that
would we we either be comfortable um integrating into mainnet or we can always roll back uh without
and always roll back without any big problems.
Also, I would suggest working closely
with the original authors of EAP 3074.
There were some interesting suggestions for user safety.
So one of them, for example,
is having expiration dates for signatures
or also having inclusion lists so that off calls based on
a signature can only call smart contracts and also nested calls can only call smart contracts
that were authorized by the user in the signature. So we're exploring different options
how to maybe make the proposal itself also safer.
And obviously collaborating with the original author team
makes sense if this is something
that is not going to be only used on Polygon,
but also on other L2s
and eventually also hopefully on ethereum itself um
so yes that's why i propose um just deploying it on a moy because even if we don't end up
going with 3074 we can always roll it back without any harm
without any harm.
Cool. And this wouldn't be like, so for example,
the rollout on Amoy wouldn't particularly be with the view
of that being included in the next upcoming hard fork, right?
It would just be there mostly to trial that proposal specifically
to trial that proposal specifically and not like an entire upgrade?
and not like an entire upgrade.
We could add it to the next upgrade,
but I would wait for more feedback from users, integrators,
the community in general, also the entire L2 landscape.
Because hopefully this is not something that just enhances our network,
but the entire EVM ecosystem. And yeah, so if everything goes well,
if we deploy it to Amoy and everything just works fantastically,
no one has any issues with it,
we can also include it in the next hard fork.
Obviously, if we encounter big issues with it,
then we shouldn't include it in the next hard fork. If there are, obviously, if we encounter big issues with it, then we shouldn't include it.
Yeah, for sure. I mean, we're gonna finalize
like inclusion list for the next hard fork.
I believe either in the next call or the one after that.
So, you know, we do have time to like trial it on
on Moid before we finalize what's included um
uh sandeep manav i don't know if you guys have like a an implementation you've been working on
and like what the prospective timelines would be for for you know pushing it to this to amoy at point soon. Yeah, I can talk a bit about the current status of where 3074 is from RN.
So we were kind of initially reviewing the EIP and kind of going through some of the
initial audits which were done for this EIP.
I think Matt, which is like client from geth already has
like a poc um there in geth but yeah there are there are some recent additions to the eip
which are not included in that poc so yeah i think the first step is to simply
included in that POC. So yeah, I think the first step is to simply do that for Bore,
which is the client which we use. And we already have, I think, an invoker contract to probably
do the modifications required over there and like try to bring it to a DevNet where we
and probably other integrators
who are interested in testing can test it,
and then probably decide on adding it to a MOI.
JOHN MUELLER, William, did you have ..
ABHIJANDUV? WILLIAM HANGHAMY KANUVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGAVANIYAGA Yes, I just wanted to say that I'm fairly certain the EIP itself has not changed. As in, one of the things that's been done with 3074 is, 3074 itself, I believe the authors would like to try to keep as simple and frozen as possible.
But there is a potential for future EIPs to add features onto it.
EIPs to add features onto it. I think it would be worthwhile to look at 3074 as complete,
as in as something that can be implemented by itself, especially if we're talking about a
test in that level. And then considering future EIPs based off of 3074, doing things like adding
an A3074 specific nonce or anything like that expiry as a separate operation, like a separate hard fork
or something like that.
Yeah, I agree with that.
I also, yeah, you're right.
It wasn't changed in a while.
The original version of PIP included nonces,
but it required a precompile that had storage, which was
unheard of yet. So they removed the nonce part and basically added the nonces to the commitment.
But then obviously they are not required by the EIP. But I also agree with Will that we can just start with barebones 3074 and then see if there's room for improvement.
I see Zero in the chat saying expiry will probably be required.
I mean, obviously I'm not the ops guy who will have to clean this up.
But to some degree, if we're pitching a new test net, like a fresh test net on 3074,
there's a part of me that really wants to say what's the worst thing that could happen.
There's a part of me that really wants to say, what's the worst thing that could happen?
And I actually want to steal this argument for a second.
As in, to me, the worst thing that could happen would be a little bit of an ops nightmare.
You know, we finally convinced Circle to put their USDC implementation on the new testnet,
and these people just migrated this whatever over and all of that.
And now the chain is irreparably broken,
if that's even going to be possible.
There's a hassle there for sure.
But like the,
especially going in eyes open,
so to speak to a new test net saying we're embracing the chaos.
We are putting this in. Things might break.
Who knows?
That's why it's a testnet.
I kind of feel like this is almost an optimal opportunity
to try and see if some of these attack vectors
that people have been talking about with 3074 are possible.
Now, expiry to some degree isn't as a,
I don't think expiry very correctly is an attack vector so much as there's
a lot of amazing things you can do if expiry is there but at the same time just the idea of having
the basic raw 3074 eip on the chain and then literally just letting people go ape over it to
see if they can break it um you know let let Jovo try his DDoS factor,
everything.
To some degree, either we
prove that it's not a problem
or it actually is.
But of all the
production environments in the world,
I would like to say that to some degree
this actually seems to be the best outside
of a dedicated ephemeral net,
which is a little bit harder to coordinate around.
I mean, dedicated and ephemeral is a bit of an oxymoron.
I mean, the intent of the chain would be ephemeral.
Yeah, Daniel.
Yeah, I also went a bit into detail with that in the comparison.
Basically, implementation challenges for integrators and also the potential rollback consequences.
So for integrators, mostly nothing changes
because you can still use normal Solidity to deploy.
You don't need to use a specific Solidity
that supports the new off and off call update.
Everything would basically still operate as usual.
For block explorers, for example, maybe transaction tracking for like ethoscan could break in cases where an EAP 3074 signature or off call was used.
The smart contract verification tool,
like that would break if 3074 feature would be used.
But these are like small things that could be then fixed.
Wallet support would not be there from the start
because it's just a blind ECDSA signature.
So users would have to, like, to operate,
they would have to enable blind signature support
in their wallet security settings.
So I don't think that it's something that will break
anything out of the gate,
because it doesn't really change too much.
And also the consequences of rolling back the changes
and going back to the previous version,
basically where it's not supported,
is just that all EAP 3074 contracts would just stop working, and that's it.
There is no real consequences to it,
and because they don't hold any funds or state or anything,
the consequences are really minimal.
Also, just mentioning one thing with the expiry, it not only allows you to
have additional features, but one main concern associated with 3074 is that if you get compromised once, you basically sign away your rights to your account forever and you can never basically use it again. With an expiry, you would have the possibility to continue using your account after it has been compromised.
So that's, I think, what it's mainly targeted at. at
i take it everybody's silence means that we're doing this and that's going on right
i hope so.
Excellent.
Cool.
Okay, well I mean at least we agreed
you know on deploying on a Moai at some point soon
and then taking a view
on Mainnet afterwards. I think that's
the most sensible approach so
yeah I mean if
everyone's agreed i think we can we can go ahead with that plan awesome
yeah cool all right um i think that wraps up 3074 then so that's like the main discussion points out the
way there was just one final thing that parvez has kindly reminded me of um and that's the
sunsetting of mumbai um sad face that's not um so that'll be on the april 13th um i don't know, Parvez, if you have any other updates on that front,
kind of the process for Sunset In or anything of that nature.
But yeah, feel free to add that if you want to.
As of now, no other updates, but we will definitely share with Tenny
on Discord and Telegram and as usual on forum posts as well.
But nothing so far
okay cool
all right okay well that's everything then for this call guys um next meet will be on may 2nd
um yeah so i'll be sharing the the the agenda a week before that call.
Yeah.
Cool.
Yeah, thank you, everyone, for tuning in,
and see you on the next call.
Bye.
