Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Polygon Protocol Governance Call #31
Recorded: April 3, 2025 Duration: 0:22:51Space Recording
Short Summary
Polygon is gearing up for significant upgrades with the upcoming Heimdall V2 migration and the VLI hard fork, which will introduce new features, improve gas efficiency, and enhance overall network performance. Key developments include a migration script for seamless transitions and adjustments to EIP parameters to mitigate gas spikes.
Full Transcription
so so Thank you. Thank you. so so Thank you. Hello. Thank you. um
Okay, awesome. Yeah, so welcome everyone to PPTC number 31. In terms of the agenda today,
there are too many buckets really. So for a little bit of wider context, there's a lot of
things in flight at the minute, both on the BOR and Heimdall side. So there's like a pretty big
refactoring of Heimdall that we'll discuss today. That's been in the works for some months now.
So we've got some updates with regards to that.
I think he's at audit stage.
So we'll discuss the playbook for the actual migration itself
to Heimdall V2, which is quite a complicated migration
involving some downtime of the bridge.
So yeah, we have Marcelo and Nicole,
who's going to do a
high level run through of that and then there'll be some more details to follow on the forum and
as well as that we have an upcoming hard fork on board so it'll be called bill i um i hope i
pronounced that correctly sandy um but that's going to include a lot of the compatible pector
inclusions um and then as as well as, some other kind of gas improvements and optimizations
as well that are kind of more specific to Polygon POS.
So yeah, without further ado,
I know you're in the airport right now, Marcelo,
but I'm gonna hand it over to you.
And if you wanna do a run through of Handle V2,
I'm happy to share screen and we you. And if you want to do a run through of Handle V2, I'm happy to share screen,
and we can run through some of the details there.
So, thank you, Eddie.
Hi, everyone.
Yeah, as I said, apologies for the background noise.
I'm at the airport, so I hope you enjoy the music at least.
So yeah, we got a quick update from the protocol team,
right, from the MW2 migration.
So at the moment, the development is completed,
and we are currently working on adapting Bore,
so it comes run without depending on Emdel,
which means that Bore will continue producing blocks
even while Emdel is being upgraded.
And also, we are making Bore compatible with Bore version as Emdel,
so it won't experience any pause during the transition phase. while Amidl is being upgraded. And also we are making more compatible with both versions of Amidl.
So it won't experience any pause
during the transition phase.
And same of course with Solve for Eragon soon after.
And in parallel, the Amidl V2 code,
then its dependencies like Cosmos and Comet
are undergoing the security audit,
which we expect to wrap up with Amidl Vaprint.
And to support the approach,iser, as I mentioned, we have developed a migration script and the runbook.
And the purpose of the script is basically to walk the operator step by step through
the upgrade process.
And it includes stopping endl, even though it should be stopped already because we are
leveraging the file type in the binary itself.
Then it will export the state from NLv1, backing everything up and installing NLv2
with all the migrated configuration, and then patching the system to be ready for v2 init.
It also includes some rollback capabilities, safety check validation at each stage.
And we have a rollback strategy under development
in case something goes wrong.
It will be another V1 version without the outside restriction,
which will basically force V1 to keep running
after the temporary stop.
We also written this detailed guide for operators who may want to follow the process manually,
because maybe on custom environments, the script may not be usable out of the box, like
unfair about Docker or Windows, even though by some estimation we should be supporting 85% of validators currently.
And a quick note on the downtime.
During the migration, as I already mentioned,
the handle breach will go kind of offline,
which means that no intracain messaging
will happen during that window.
However, this is important.
Bored and Eragon, as I said before, will continue to run.
So the Polygon chain will not experience any downtime
or halting block reductions.
Only the cross-chain operation will be post that we're doing our best
to ensure the downtime is minimal.
At the moment, we're testing the scripts and the process on webnets.
Soon we will do the same on Mumbai, which we have internalized for this purpose,
because the huge state it holds is a great test for the migration.
And then we're focusing on optimization, streamlining the steps,
making the process as efficient as possible, basically.
The script will be signed and checks out for your information,
so every node operators can verify they're using bumper-proof version.
And we will be using some official channels for communication.
It seems to be defined, but it's going to be a combination
of foreign posts and the rightful itself.
And maybe one final point to note is that once the migration is
complete, MWV1 blocks history will be gone.
So unless someone like RPC providers explicitly keeps it
around for our panel purposes, basically.
With regards to timeline, end of April, as I said,
we should have an audit completion.
We are testing on DevNet and we will be performing a Mumbai migration test.
By end of May, if everything goes fine, we are planning for Amoy.
And then a tentative for June, end of June, I think, for mainnet,
unless delays surface during this testing or audit response.
Yeah, that is basically it from my side.
Peter will take any questions.
Thank you. thank you
all right thanks marcelo i just wanted to add so um for those that aren't aware there's like an
offsite for a lot of the polygon developers next week um so in terms of like when the runbook is going to be published
um i'm assuming it will be like a couple of weeks time right because it's a pretty like beefy
document and i'm sure there's probably still some dependencies we're not fully um we don't like have
in hand yet so yeah just wondering a couple of weeks is that that a reasonable timeline, or will it be a little bit further down the road?
It also depends on the audit reports.
I would say two weeks is reasonable,
but we need to wait for the end of April reports
from the auditing company in case we need to make any adjustments.
Okay, cool. Nice. So yeah, that will probably be going out on the forum uh so yeah keep your eyes
peeled for that any validators listening um and yeah if you have any questions um yeah feel free
to jump in on the forum uh you can comment under pip 43 44 um or also under the handle v2 pip as well. So, yeah, there's no good questions on that.
I think we can move on.
Okay, cool.
So there are a couple of things on the bore side.
Let me share this tab. So pip63, this kind of specs out the Bore side. Let me share this tab.
So PIP 63, this kind of specs out the inclusions.
You know, a lot of it's downstream from GIF.
So the Pectra upgrade that's scheduled on Ethereum.
So there's a lot of kind of compatible
and incompatible things within the upgrades.
If you check out PIP 61,
it just has all the compatible things that
we'll be integrating within our own client um and yeah it also has the other two pictures as well
i don't know sandeep if you want to um do like a high level run through of this um kind of timelines
and and how things are looking there as well um and then we can go into the change in pip60 afterwards.
Yeah, sure. Hello.
Hey, everyone.
So, yeah, VLI hard fork, like Harry was saying, this is the next BOR hard fork.
And we plan to release, you know, all the PECRA changes, PECRA EIPs, or most of the PECRA E eips that we've been working on um so this is still under
development currently uh where we are you know getting the changes uh from like the code uh
merging the code from upstream uh get and um there are a few inclusions, I think you can, Harry, if you can go into the 61, just
quickly cover the inclusions.
Yeah.
So, yeah, we'll be enabling EIB 2537, that's pre-compiled for VLS 2381 curve operations,
29357623 and the biggest one 7702. The others like the second
section you see that they have been included but they will not be activated or supported within the
working client implementation and that that includes CIP 7549, 7840 and 7691.
And the third section which you see is not really relevant to Polygon POS
because those are mostly to do with the consensus here of Ethereum.
So, yeah, if you can go back Harry.
Yeah, if you can go back, Harry.
So those are the PECRA EIPs.
The other PIP that we have, you know, which will go live with the BILI hard fork is PIP 58,
where we are adjusting one of the EIP 1559 parameters to smoothen the gas spikes
when there is very high network activity.
So currently, like I think around two years or three years ago, after we implemented EIP 1559 on POS, there was one hard fork where we also increased the base fee change denominator from 8 to 16.
So, yeah, this is already a well tested out change.
So, there's not too much work to be done on that.
you know work to be done on that so we are actually increasing it to 64 now
so that the rate of change of base fee is lesser you know and when there is you know the blocks
are full or even when the blocks are empty so basically what what this does is the increase also becomes slower and the rate
of decrease also becomes slower so yeah that's a double-sided thing so currently i think it
increases by 6.25 percent and after this change it's slightly over one and a half percent so
slightly over one and a half percent.
So because it's four times the denominator.
So yeah, that's the major change.
I think this would give a lot of relief
to some of the dApps, which have been affected
when there is very high network activity.
So it's not gonna affect the users too much.
It's like it takes a much longer time to probably become 2x or 4x and so on.
But I think earlier it used to, you know, like within a few hundred blocks,
a few hundred blocks, we could see a thousand percent increase.
So it won't be as drastic as it is currently.
Yeah, I think if you can go back Harry.
So, yeah, the last one which is included is PIP 60.
So we are basically, yeah, just some background on this. We have been
working on a lot of impactful changes over the last year or year and a half. I think all of you
are also aware of the block HDM or parallel EVM work that we have done and also pbss the part based storage scheme
which i think most of the validators have already rolled out and some of them are still in the
process um yeah and and we also added a few features which did not require a hard fork like
commit interrupt which ensures that you know transactions which are taking too long are preempted and the block is propagated so that we maintain the block time of two seconds.
So with all of these improvements that we have made over the last couple of years, we also did some experimentation with increasing the gas limit.
with increasing the gas limit and we are confident that we can easily increase it by 50% without
putting too much load on the network or the infra. So yeah, that's the big change here.
So we are increasing the block gas limit from 30 million to 45 million. Yeah, I guess this number was more conservative.
I guess we had initially proposed to be 40 million.
But yeah, we are confident enough now to make it even higher
and raise it by 50% more.
Yeah, those were the big changes. Any questions so far?
No questions from my side. I'm not sure if you mentioned like some kind of rough timelines for when we look to deploy in Amoy.
I know some of the picture things might be contingent on Ethereum L1,
but yeah, I don't know if we have any kind of rough timelines we can look at.
Yeah, so I think on GETs, most of the changes are already in and because they also rolled it out on the testnet, right?
So we should be pretty good there.
But like I said, we are still getting the upstream changes.
So we are merging one version at a time because there are too many changes since the last merge that we took from upstream.
So I think we are currently at 1.14.11 which has already been released and it's just a stable tag. 1.14.13 from git is being tested right now and hopefully will be released very
soon, maybe the next week. And then we're also going to start working on the 1.15.x
versions of git which will actually contain the petra e. So yeah, that's going to take a couple of weeks at least
and a few more weeks of testing because they actually
include all the EIPs from PECRA.
So yeah, probably I think we are looking at around mid-may uh to end of may uh when we could release or roll
out uh the bly hard fork on my destiny and maybe a few weeks later on main if everything was well
awesome thanks and yeah so it sounds like it's gonna be a busy summer
um yeah like i was saying
before there's a lot in flight um i think after this this coming off site um yeah there'll be
it'll be time to start kind of you know um executing on all this stuff um as we as we get
into the summer so i'm expecting these calls to probably start ramping up a little bit um towards
then i know they've been a little bit quiet um over the last couple calls so yeah i appreciate that sandeep
and thank you as well uh marcelo for running through the handle v2 things um i don't know
if anyone else has any agenda points they want to discuss quickly before we wrap it up um but
if not i'll give you guys a little bit of your day back.
All right, awesome.
Well, thank you all for joining.
Next call will be May 1st,
currently tentatively scheduled for May 1st.
So, yeah, hope to see you guys there and enjoy the rest of your day, guys.
Thank you for joining.
Thanks everyone.
