Mainnet Upgrade Overview for RC-0.6.1

Announcements
, ,
1

:warning:

Update – April 14th, 2021

0.6.0 has been replaced by 0.6.1, which fixes a critical bug that was discovered during the testnet upgrade rehearsal. Refer to this announcement for details on the hotfix.

Relevant Docs

0.6.1 Release Notes
0.6.0 Release Notes

DAO Proposal (PIP-4)

Community Call Notes

Community Call Recording

Release Summary

This Release (0.6.1):

  • Offers a higher level of security (2 mission-critical patches in the Merkle tree)

  • Provides a higher level of network stability through the removal/patching of events

  • Switches from Amino to Protobuf encoding, allowing for much easier creation of SDK’s and network clients, which was pretty much impossible before due to Amino’s incompatibility with most programming languages

Benefits

To Nodes

We have successfully separated servicing and validation, which helps to resolve the issues discussed in PUP-4, in particular, the theoretical max node limit. For more details on this please read the entire PUP-4 thread.

In addition, with this release, there is now protection in place that will avoid slashing for double-signing actions such as restarting your validator while you are staked and online.

Protobuf will also lower transaction latency due to less resource demands on nodes. However, relay latency will be unaffected (improvements in relay latency will primarily come from the maturation of our node community’s configurations).

To Apps

The security and stability improvements mean a more reliable experience for apps.

With the migration to Protobuf encoding, which supports many more languages, SDK and client development is now a lot easier, which will unlock the potential for a larger variety of common SDKs and clients to be developed, ultimately leading to an all-round better developer experience.

The Process

  1. The release is now published, so nodes can upgrade immediately. The new consensus rules will be inactive, meaning the nodes will be operating according to the old consensus rules until the upgrade is activated in Step 5.

  2. We are doing a Testnet Network Upgrade rehearsal, with the testnet upgrade taking place on Monday 5th April. If you want to participate, read the details here.

  3. We’ll have a community call at 3pm EDT on Tuesday 6th April, to discuss the details of the upgrade. RSVP here or add all of our Discord events to your calendar using this link.

  4. If/when 67% of nodes have upgraded, reaching consensus for the new protocol version, PIP-4 will be amended to include an upgrade height (the height at which the new consensus rules will be activated and non-updated nodes will be left behind). PIP-4 will then be put to a vote. This gives the DAO the chance to veto the consensus rule change before it is executed.

  5. Voting on PIP-4 will last 7 days and pass with a 50% majority. If the vote passes, the Foundation will activate the upgrade at the specified height using the pocket gov upgrade transaction.

Beware of scammers throughout this process that might try to steal from you. The Pocket team will not ask you to send POKT, Cryptocurrency or Money.

Node Upgrade Guide

For details on how to upgrade your node, go to the Upgrade section of the release notes.

Community Call

Community Call Notes

To answer any questions you may have, we are holding a community call in our Discord at 3-5pm EDT on Tuesday 6th April.

To ensure that your questions get answered, try to post them in reply to this thread before the call takes place.

We’ll be using the new Discord Stages feature (Clubhouse for Discord), so if anyone has questions in the audience they will need to raise their hand and we’ll select them to speak.

The meeting will start with a 10-20 minute overview, referencing this document, then will turn focus to Q&A. For the call to go as smoothly as possible, we encourage everyone to read this doc in advance and reply with clarifying questions in this thread.

RSVP for the meeting at this link or add all of our Discord events to your calendar using this link.

FAQ

Nodes

Can I upgrade ahead of time?

Yes, now that the release is published, you can upgrade now. Find the release here.

What do I do If I am using a third-party service provider to run my nodes?

If you are using a third-party service provider it will be up to them to upgrade your nodes, but we do recommend that you contact them for their upgrade plan. We are also coordinating with the major third-party providers directly in order to ensure a smooth upgrade.

What happens if I do not upgrade in time?

Your node will not be able to continue. Full nodes will shut down and be unable to restart without an upgrade. Validators will be slashed and jailed and be unable to restart without an upgrade. If this happens to you, the only way to get your node back online will be to follow the directions outlined in the upgrade guides.

Note: if you manage to recover within 6 blocks of missing the upgrade time, you won’t actually be slashed. But why take that risk?

If I do not upgrade in time, will I lose my POKT?

As explained above, the upgrade force shuts down any node running older versions after the upgrade height. For Validators, the shutdown can result in standard offline slashing.

If I need more help, where do I go?

Reply to this post or message the #node-runner channel in Discord for community support

Apps

What should I do if I am using a Pocket Gateway Endpoint?

You will not need to do anything extra. But during the switch, we anticipate a slight outage for apps not connected through the Gateway. The Gateway has fallback mechanisms that will prevent protocol-level outages from affecting apps. These fallback mechanisms will have slightly higher latency which may be experienced throughout the upgrade.

If you have any questions or concerns, please reach out to our app solutions team through the #app-developer channel on Discord.

If I’m not using the Gateway, how should I upgrade?

Upgrade PocketJS to the latest version, which you’ll find here. For more details on getting started with PocketJs, check out this quickstart guide.

If you want to stake with the new version of PocketJS before the upgrade has been activated in Step 5 above, you can use the legacy codec flag to stake with AminoJS.

@param {boolean} useLegacyTxSignature - (optional) If True the legacy tx signer will be used (AminoJS), false will use the new ProtoBuf encoding.

After the upgrade has been activated in Step 5 above, you will not need to use the legacy codec flag anymore.

2 Likes
2

Community Call Summary: RC-0.6.0

Recording here.

During the community call event, many attendees have had the chance to ask questions related to the main topic of the community call which was the releasing of RC-0.6.0.

In turn, our lead protocol engineers have enjoyed receiving those questions and going in full detailed explanations that we tried to capture in this post.

Here are the most relevant questions that have been raised and their answers respectively.

Can on-the-bench validators be slashed for providing bad info?

Yes, absolutely. The bad info here being particularly the rogue challenge transaction whose rogueness everyone reached consensus over.

With the changes in 6.0, will the 5,000 validators get the rewards as before?

While we had the servicer/validator separation, we are unsure about QoS at large counts. Therefore PUP-4 was modified with the intention of still limiting nodes below 5,000. We proceeded with using an adjustment curve to gradually move rewards from validators to DAO as we approach 5,000. The DAO can undo this whenever it wishes.

How can we update the validator limit parameter?

This can be updated like any parameter, by the DAOowner account submitting the pocket gov change_param transaction. Before this transaction can be submitted, the DAO would need to vote to approve a PUP specifying the change.

Does this release improve the network performance and quality of service/quality of nodes?

We’ve been able to notice a drop of latency but we are not entirely sure whether it is this particular release, although we expect it to do so thanks to the removed overhead of Amino by introducing Protobuf which is a significantly lighter codec.

Will this release force the old revs off or is it the gateway?

Yes, 6.0 will force old revs off.

If I understood correctly, 0.6.0 will not use the recent (unstable?) refactors/reworks in P2P Tendermint’s area, does this imply we’ll likely continue to see some stuck nodes from time to time?

The occurring p2p issues seem to come from the older versions that are still running that use the older versions of Tendermint which still has some faulty behaviors when it comes to p2p, so to your point, until we are safe about Tendermint’s updates to their p2p module, the current behavior relative to the currently used version will likely stay the same.

Can we talk about 7.0?

If you’ve peaked into our unofficial roadmap, starting from 7.0, releases will only include features, in hopes no bugs arise. But there are two main features we are looking to release:

  • Jailing Offline Nodes: through events and reports aggregations from the client-side
  • Targeted Servicing & Quality of Service Metrics: Basically implementing on-chain quality of service control while deprecating that feature off of the gateway layer.
  • 7.0 is going to come with a specific set of “Dials” to adjust quality SLAs, you can call that the first social SLA that is configurable and adjustable. i.e: We can set the SLA to a different value based on node count in the network and adjust to reach the desired behavior.
  • Andrew: This is going to look like a Darwin Hierarchy where the best servicers are going to be on top whilst the bad servicers are going to continually go down and get dis-incentivized to continue servicing.

Are there a lot of config changes in 0.6? The upgrade notes mention to migrate existing configs using pocket util update-configs

The current changes only concern the p2p configuration, feel free to polish your config files and make sure it is up to date.

Is there anything that the new/fresh node runners might have to know that is not mentioned in the current documentation?

The upgrade will be seamless due to the simple fact of having no legacy node to deal with or upgrade, it’s a fresh start. In either case we will be coming with a quick documentation to cover every detail in case we missed it with the current document.

Can we stake with legacyCodec set to false right now?

Mainnet legacyCodec has to be true, but for testnet it will be false since it already has the upgrade.

Is the quality metric cumulative? as in, does the system forget past performance? or does it increasingly reward nodes that achieve 100% service over a longer period of time?

Absolutely, we are rewarding the nodes with the best history. Our mission is to reward the nodes that maintained higher quality of service and maintained their identity. The system does not forget past performance. Also the reward will definitely increase for the services that achieve 100% over a longer period of time.

Does 7.0 cover the update stake functionality?

We haven’t talked about it yet, we however strongly encourage you to submit a proposal for this feature.

Does it (the upgrade) use cosmovisor or similar to switch the daemon at upgrade height?

There is no daemon switching, it is just a flag to flip.

When you say open v1, do you mean opening the p2p ports (26656?)

Not just the RPC port 8081

A question about automation, how can I automate the update from the legacyCodec?

As a disclaimer, Internally, we are having a lot of discussion about orchestration for the pocket node so make sure you follow the news, but to quickly answer your question, the best way is to use the RPC endpoint to check on the current parameters, and specifically watch for a particular parameter key change: the ‘upgrade’ parameter, then automatically detect when there is an upgrade and therein push the correct codec as a transaction.
As a side note, the legacyCodec is a temporary measure, it won’t be necessary post-upgrade.

Shouldn’t we do these calls 6 hours earlier so it’s not so late for most of the world?

We had to accommodate for the fact that we wanted some of our Australian node runners to attend since they were keen to do so.

2 Likes