Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Polygon Protocol Governance Call #29
Recorded: Jan. 16, 2025 Duration: 0:22:58Space Recording
Full Transcription
so Thank you. Thank you. I'm going to go ahead and get started. Thank you. so so Thank you. I okay welcome everyone to ppgc number 29 um in terms of the agenda for today we've got a couple
of buckets so the first being some upgrades to polygon pos's system smart contracts so
label contracts on ethereum um being pit 54 and also pit 57 and then we also have some points to cover on the
heimdall side as well so on the last couple calls we've been discussing jovic there's a follow-up
hard fork um that we need to need to go over today called danelaw um and then the contents
of that hard fork being 55 um as well uh So those are the two main buckets.
And at the end, we'll probably just briefly recap
on the STB follow-up, which was the idea
to introduce Polygon feature requests.
So yeah, we'll probably finish off with that.
Okay, cool.
So without further ado, first thing on the agenda,
so system smart contract stuff
um so we discussed uh on the last call about pit 54 chris kind of went through the spec as well as
as matthias as well um so that's progressing um kind of on the development side and we're now
at a point where we could start to discuss a little bit more about the execution plan and how things are looking in terms of timeline as well.
So, yeah, Chris, I don't know if you want to dive in there,
if you've got any updates.
Yeah.
Cool.
Thanks, Ari. Hi, everybody.
So, as we discussed, just to recap,
this is regarding moving the current Polygon multi-sig that has been there
for i don't know how many years definitely before i started a polygon into you know changing those
ownerships to the new protocol council uh that is a much needed change in order to improve the
security the stability and obviously the decentralization of the whole chain.
We discussed a little bit about what this encompasses. It is actually a very simple change because the only thing that we really have to do
is basically call a function to change the ownership of those contracts
to be either the time lock or the emergency council.
Now, in the PIP itself, we have mapped all the different contracts
and where do they have to go or who are their new owners.
So we have done all that in research work already.
And right now, what we're going to start doing is preparing the payload
to actually get this done.
So we plan to start preparing the payload next week for all the changes.
No, it's a lot of changes, but it's always the same simple change. So the mistake is
going to be more on the operational side of things. If it ever happens, we're going to
make sure it doesn't than on the complexity of the transaction itself. So our plan for doing this without making any mistakes
is actually we're going to prepare the payload,
then we're actually going to create a fork.
We're going to apply the payload to that fork of mainnet,
and then we're going to actually send the battery
of huge amount of tests.
So we're going to actually try to simulate Mainlet,
just if it was going.
So everything that is going on in Mainlet at the same time,
we're going to actually apply that to what is happening
in the simulation in the fork that we created.
And therefore, with that, trying to bring a little bit of reality
to that fork and trying to understand like, hey, has anything broken?
Is there any problem? Have we missed anything?
No, that should probably run for a couple of days,
if not a couple of weeks to ensure that nothing is wrong.
And if everything works out perfectly well,
then we will actually start moving into the deployment
or the proposing of the payload
with the previous council and with the new council that needs to accept the roles.
This will all be batched, so I expect that this is only going to be one transaction
for the protocol council that will include all the acceptance of the ownerships,
let's say like that.
And it's not going to have to be multiple ones,
but we will actually know that better when we have the payload prepared.
Yeah, we've also diagrammed a couple of the worst-case scenarios
or what could go wrong or what could be missing.
And we feel that the only thing that could be missing is that we
have missed a contract no ownership or contract role no some were hidden in some of the contracts
we've absolutely checked everything but you know there could be something that is missing over
there and obviously in case that happens we will always retain ownership of the previous
multi-sig now the the previous council will still be here part of the people that are in that council
are in the new council so you know it's more or less the same people and that multi-sig is not
going to disappear we're not going to close it it's going to remain as it is in case that we need to
make use because there is something that was missed or one role or transaction that was not included.
So again, we still have a couple of days, if not a couple of weeks,
actually, until we actually will be executing this transaction,
but we want to start moving fast from now on and really just get this done.
It's a much needed upgrade to the security decentralization of the whole network and of Polygon itself.
I don't know if anybody has any questions.
Be happy to answer them.
Nice. Yeah, thanks, Christopher. nice uh yeah thanks christopher uh so i'll link the forum posts uh like to the pip in the chat so you guys can check it out if you want to um if you have any longer form thoughts that you want
to share so um yeah awesome thank you for the update christopher i think one thing it might be worth
touching on is that this upgrade basically bolts the pos chain into the new governance framework so
the whole kind of uh pillar the whole pillar two system smart contracts uh framework which which involves token voting using delegates and dynamic quorums.
So, yeah, that's another kind of angle to this.
So it kind of, yeah, it bolts our new governance framework
into the POS chain, which is obviously nice.
So, yeah, another thing to be aware of there.
Okay, cool. I don't know if anyone else has any thoughts they want to add if not we can we can move on to
PIP57
Okay, cool
Yeah, so PIP57 pretty recent PIP
Yeah, so PIP57, pretty recent PIP. Yeah, that's a very handy function to the migration contracts.
I don't know if we have Simon on the call who can walk us through the spec a little bit.
But yeah, I can see you're on Simon.
So over to you, sir.
Thanks, Harry.
Yeah, if you want, you can click on the perfect...
Yeah, exactly.
That's that one. Yeah, if you want, you can click on the perfect, yeah, exactly.
That's that one.
So this is quite a simple addition to the polygon migration contract.
You can already use the normal migrate function
to convert Matic to pole here.
We didn't have this in the initial implementation
because we thought it might be used to scam people
or like have them use somehow sign this function.
So we thought it might be easier at the beginning to just have the migrate function where you
can really only, you know, migrate Matic to yourself.
But unsurprisingly, we got a lot of requests from some exchanges and from some other
platforms to have this function as a convenience in the migration contract. So with this, you would
be able to send MATIC and then the poll would be received by a different address than yourself and
the recipient you can see in this function here.
So that is pretty much it.
I took the liberty of writing this into the bib
and we're proposing to add this function
into the polygon migration contract by upgrading it
and bumping the version to, it would be 1.2, I think.
That also means the event gets a little update
to include the recipient.
And that is it.
So pretty easy stuff, but a nice addition
to the migration contract, I believe.
Yeah, thanks, Simon.
Also, yeah, I don't know if anyone has any questions just one thing i wanted
to add there is that uh it will be the protocol council that will need to ultimately execute this
so if we have any council members on the call um yeah we'll appraise you a little bit more down
the line but yeah as simon was saying it's like pretty pretty lightweight but effective features so um
yeah I haven't seen any pushback today um but yeah thank you Simon
okay
awesome okay so moving on then then to the second bucket,
which is everything on the handle side.
So, yeah, on the previous call, we kind of discussed this in some length
about the Jovic hard fork, which went out on a Moai last year.
So there were some issues observed on a Moai.
So effectively, some of the nodes were falling out of sync um and this requires an
other upgrade to kind of rectify the issue that that needs to be forked in again so another hard
fork um so yeah kind of want to clarify that you know there's two hard forks right there's jovic and there's danelaw
um jovic is the kind of seed randomness uh upgrade and then the danelaw upgrade is a follow-up one to to patch to patch a kind of bug that was created there um so yeah danel will probably roll out uh
in a couple of weeks i'll have more details on that after rinit's kind of gone through
55 but um yeah i just wanted to clarify that when these two go out on mainnet um they will be kind
of labeled the jovic upgrades and not the danelaw jovic upgrades um yeah just just to make that clear
uh it's just kind of because of the way the code needs to be labeled we need to create two naming two namings for the for the fork so um yeah that's a little bit of context on on damel um i don't know
if we have runny on who's able to walk us through pip 55 but yeah if so then then over to you really
yep sure thanks harry um hey all um um harry could you PIP55 once? Yeah do you want me to share screen on PIP55?
Yeah no you can you can just directly go to the PIP. Yeah okay.
Yeah yeah thanks for the intro Harry. So I think we briefly touched upon this on the last
Harry, so I think we briefly touched upon this on the last edition of the PPGC.
So to recap, essentially the Yorvik hard fork was rolled out in Amoy and we saw a couple of
issues occurring on some external nodes where we found the root cause to be a slight non-determinism,
non-deterministic bug in the Heimdall logic, in the span committing logic to be precise.
And that was because, so with the Jovic hard hard fork we amended the parameters required to um propose a span
span being a range of board blocks which would be produced eventually so and and the seed
essentially of that uh of that span message uh would be used to essentially determine the list of validators who would be the
producers for those range of blocks. So and that seed would be picked would be a bore block essentially.
So when committing a span on one node, if that node's bore process fell out of sync or were to crash or something were to happen,
something non-deterministic were to happen, it would fail to validate that span
and would essentially produce an inconsistent application state.
And hence, I mean, it would break the consensus.
So we figured out the fix would be rather simple.
And that would be just amending the span message transaction type to also include the seed author,
which is needed at one stage of committing the span.
And we could validate that statelessly.
So without having to commit to the state database,
we could validate the seed and the seed authorizing
the block producer of that block,
which is being used as the seed.
So yeah, that's essentially the core of this PIP 55,
which is a hard fork, excuse me me a hard fork inducing change um which
will go with the day in law uh and uh yeah this would uh on on a moid we are planning to roll it
out uh yeah exactly one week from today so that would be 23rd of Jan. And some point in mid-February, I think, for Mainnet.
So yeah, as Harry already mentioned earlier,
Jorvik and Dane Law on Mainnet would go on the same block.
So these both changes would be activated
on the same block on Mainnet.
But on Amoy, as Jorvik hard fork has already been activated,
we would have to do this on a higher block number for download.
So yeah, that's mostly it.
I'm open for questions, if any.
Awesome. Yeah, thank you, René.
Just looking on the forum for the pips.
Here we go. Yeah, so if anyone has any longer form thoughts,
particularly validators, then yeah,
feel free to take a look and let us know what you think.
Awesome, okay, well, if there's no questions there,
then we are 90% through the agenda,
90% through the agenda, so it's going to be a fairly quick call.
so it's gonna be a fairly quick call.
So, yeah, the next thing on the agenda is just a small item.
Obviously, we touched on the last call about the whole STB situation,
and then a piece of feedback that was received from that was that the name,
like Repip, makes it almost feel as though it's on some preordained path
to being executed at some point,
which we kind of felt was a bit of a mismatch
to what that proposal intended
or what the authors intended with that proposal.
So, yeah, what we've done is basically followed up
with something we're calling Polygon Feature Requests
so in the future if anyone has any
things they want to
suggest from a high level
perspective about the
Polygon POS Chain or
the Polygon protocols in general
it can be directional things or
low level things or just
feature requests
then yeah this this provides like a template
and just like a little bit of guidance
that you can either take or leave
to try and help like formulate your thoughts
and yeah, just kind of assist you
in kind of doing that type of thing.
So yeah, that's out on the forum.
So yeah, if you're interested,
then feel free to take a look.
Okay.
Well, that's all I have on the agenda for today.
I don't know if anyone else has any updates
they want to add.
Yeah, anyone on the POS team,
contracts team, security team,
if there's anything else,
then yeah, I guess we've got
a little bit of time.
Then, yeah, feel free to
jump in, but if not, we can probably
wrap it up.
All right, okay.
In that case, thank you, everyone, for joining.
The next call is on February the 13th.
So, yeah, all be well.
I'll see you guys there.
Thanks again for joining the call.
