PIP-30: Consensus Rule Change – RC-0.10.0

Attributes

  • Author(s): @Olshansky
  • Implementer(s): Pocket Network Inc, Pocket Network Foundation
  • Category: Protocol Upgrade

Summary

A consensus breaking release consisting of:

  • Doubling the block size to double the network’s relay capacity
  • Fixing session rollover issues by allowing flexible session block height tolerance on the client side
  • Allowing output address owners to change the output address
  • DDoS protections at the P2P Tendermint layer
  • Patching a jailing-related caching issue

Motivation

Doubling the block size to double the network’s relay capacity
Increase the capacity of the network to serve relays by doubling the number of transactions that can be included in a block.

Fixing session rollover issue by allowing flexible session block height tolerance
Allow nodes to serve relays from previous sessions to mitigate the session rollover issue that can affect an app’s perceived QoS.

Allowing output address owners to change the output address
Improve the UX of non-custodial staking by allowing output address owners to modify the output address.

DDoS protections for P2P layer
Incorporate DDoS protections from post-fork Tendermint to enhance the security of the P2P layer.

Patching a jailing-related caching issue
Patch a low-likelihood bug.

Specification

The implementation details of each of these changes can be found in the release guide.

Rationale

The rationale for each feature implementation can be found in the release guide.

Viability

Functional, integration, unit, load, and simulation tests will be completed leading up to this upgrade. These will be found in the release guide, which node runners will be able to audit prior to upgrading their nodes.

Implementation

  • If this proposal is approved, and after testing has taken place for BETA-0.10.0 on Testnet, RC-0.10.0 will be published for node runner adoption. Anyone can monitor node runner adoption of RC-0.10.0 using the Servicers and Validators version pie charts displayed here or the equivalent “Staked Tokens by Node Version” chart displayed here.
  • Once ≥67% of validator power has updated to this version, an upgrade height will be selected by the Foundation Directors based on the preferences expressed by node runners (e.g. through Discord polls) and they will pass this height to the chain through the pocket gov upgrade transaction.
  • The upgrade height chosen by the Foundation Directors will be communicated in advance to ensure node runners are prepared to react if necessary. A time will be targeted that maximizes the availability of node runners, accounting for all time zones and working hours.
  • Once the network is upgraded, each of the new features will be enabled by the Foundation submitting the pocket gov enable txs and working with the protocol developers to ensure there are no issues
  • The new BlockByteSize parameter will be gradually increased from 4MB to 8MB depending on network traffic, according to the recommendations of the core protocol developers.

Dissenting Opinions

TBD

Audit

There will be no external audit, refer to Viability.

Copyright

Copyright and related rights waived via CC0.

10 Likes

Very excited for this amazing release!

2 Likes

Looking forward to this :slight_smile:

2 Likes

I have published the release in pocket-core [1] and tentative some potential last-minute tweaks being discussed on discord [2] (raised by @poktblade), it’s almost ready to go.

@JackALaing Could we submit this for a vote in the next couple of days? One thing to call out specifically is that while the Block Size is a governance parameter, we need the proposal to allow us to increase it gradually (depending on network traffic) from 4MB to 8MB.

[1] Release RC-0.10.0 · pokt-network/pocket-core · GitHub
[2] Discord

3 Likes

I have edited the proposal to add the following implementation detail at @Olshansky’s request

1 Like

This proposal is now up for voting

https://gov.pokt.network/#/proposal/0x5d22131965f02c6ee86fadb7acbd2962f923be95384b0cbb70f3701d5d0339df

3 Likes

This proposal was approved with 31 yays and 0 nays. Snapshot

The next step for implementation of the upgrade is for at least 67% of nodes to adopt the new RC, found here.

3 Likes