PIP-9 Consensus Rule Change – RC-0.8.0

Attributes

  • Author(s): @Andrew

  • Implementer(s): Pocket Network Inc.

  • Category: Protocol Upgrade

Summary

A consensus breaking release consisting of:

  • Non-Custodial Operator Address #1204
  • Removal of Force-Unstake ‘Burn’ #1369
  • Non-Deterministic Invalid Evidence Fix #1368
  • Handling of ReplayAttack Error #1372

Motivation

Non-Custodial Operator Address
Currently in the RC-0.7.0 generation, the ‘Operator’ private key and the private key that has custody over staked funds are required to be the same. This coupling poses a high level security risk for node runners as the custodial private key is required to be on the server the node is operating on.

Removal of Force-Unstake ‘Burn’
If any Pocket Network node falls below the minimum stake (due to slashing) the punishment is burning all of their staked funds and deleting the Validator from the state. Several node runners have fallen victim to this and in this case we feel the punishment does not fit the crime.

Non-Deterministic Invalid Evidence Fix
The evidence handling protocol in Tendermint is non-deterministic and occasionally causes invalid proposals. Historically, this symptom has caused blocks tens of minutes late.

Handling of ReplayAttack Error
Relay ReplayAttacks are stopped at the protocol level under the ProofTx verification. However, the protocol is specified to punish the attacker proportional to the probabilistic replays. Currently, it seems this functionality was not implemented. This oversight needs to be rectified.

Specification

Non-Custodial Operator Address

Structure

type Node struct {
    Operator                        Address
    OpPublicKey                     []byte
    Jailed                          bool
    Status                          int32
    Chains                          []string
    ServiceURL                      string
    StakedTokens                    BigInt
    UnstakingCompletionTime         time.Time

    Output                          Address // NEW custodial address
}

Protocol

// Rules
    The Operator Address is the only valid signer for blocks & relays
    The Output Address is where reward and staked funds are directed
    The Operator and the Output Address must be set when Staking
    Neither the Output nor the Operator Address may be edited once set
    Both the Operator and the Output Address are valid signers for 'Node Transactions'
      - (Stake, EditStake, Unstake, Unjail)
    Only the Operator may sign Claim Or Proof Transactions

// Legacy Migration
    Output is empty for legacy nodes and the current Address is the Operator
    If Output is empty -> the Operator may set it (once)
    If Output is empty -> the Operator is treated as the Output 

This means all existing nodes will be able to upgrade to a non-custodial arrangement by editing their stake to add an Output Address. No unstaking will be required.

Removal of Force-Unstake ‘Burn’

Protocol

// Rules
    If Node Falls Below Minimum Stake -> Normal (21 Day) Unstake

Non-Deterministic Invalid Evidence Fix

Protocol

// Rules
    Validator Checks if Evidence is previously committed before adding it to the Proposal

Handling of ReplayAttack Error

Protocol

// Rules
    MerkleProof.Verify() -> if ReplayAttack detected -> Return Code (83) so it may be handled

Rationale

Non-Custodial Operator Address
The specification provides a conceptually simple and minimal rule-set for protocol implementation while covering legacy migration, enabling cold storage security, and considering custodial, partial custodial, and full non-custodial user stories.

Removal of Force-Unstake ‘Burn’
The burning portion of this protocol response is disproportionate to the infraction committed and should be removed from the protocol.

Non-Deterministic Invalid Evidence Fix
The evidence handling protocol in Tendermint is not purposed for this behavior. This is a bug that needs to be patched to have true determinism in block production.

Handling of ReplayAttack Error
Though this functionality has existed since the beginning of mainnet in Pocket Core, the function is seemingly never called even though that was the intent of the developers.

Viability

Functional, integration, unit, load, and simulation tests will be completed leading up to this upgrade. These will be found in the release notes, 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.8.0 on Testnet, RC-0.8.0 will be published for node runner adoption. Anyone can monitor node runner adoption of RC-0.8.0 using the “Consensus by Version” chart displayed here or the equivalent “Node Versions for Staking Power” chart displayed here.
Once ≥67% of validator power has updated to this version, an upgrade height will be selected by the Foundation Directors 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.

Dissenting Opinions

Non-Custodial should enable revenue sharing by default

Non-custodial is a security feature to enable non-hot wallets to control validators. Anything that can be moved to L2 to assist the network should be. Adding a revenue share % field for rewards not only increases the complexity of development - it also grows the blockchain size by an entire other field per Service Node. This is an unacceptable trade off considering the position Pocket Network is currently in with state size and data duplication. As this feature was considered when Non-Custodial was specified, it was realized that it’s quite unrealistic to optimize for a single use-case revenue share model. If the feature optimizes for one - it must optimize for others (fee scheduling - stake splitting etc) it’s a very slippery slope.

Audit

There will be no external audit, refer to Viability.

Copyright

Copyright and related rights waived via CC0.

8 Likes

+1 to all of the improvements in this proposal. It’ll make the Pocket Network more resilient and secure, while also creating incentive for new members to join the network either as node runners or POKT owners.

The only point of discussion I wanted to raise is whether the new field in the Node struct should be called Output or Owner. The term owner-operator is common in different industries. In this specific situation, the Output address is not only the sink of rewards, but can also sign any transaction with the exception of Claims and Proofs. It is therefore the Owner of the staked funds, and the rewards, while the Operator operates the node.

2 Likes

I support this proposal without reservation.

2 Likes

I think Output might be better - as it is safer from a legal perspective + is explicit about where the rewards ‘output’ to.

1 Like

I love this proposal and fully support this.

1 Like

Makes sense to me. Let’s stick with Output and +100 to the whole proposal.

1 Like

Non-custodial staking and removing the force unstake are features many node providers have been asking for quite some time. Enabling this will allow for entire new set of node providers to come in that previously weren’t able to.

Absolutely support this proposal.

2 Likes

This upgrade will mark a before and after in node runner security and operations, allowing for more optionality and robustness on these operations. The fixes for Evidence Handling and the improvements on the ReplayAttack error keep strengthening the security of the protocol.

I concur. removing this counterparty risk would be extremely beneficial to the project at large

I support this without reservation.

This proposal is now up for voting. https://gov.pokt.network/#/proposal/0x5527a5aec65f0e7e708813f4d7b0376f68dcf986b0b88045bf0126d699a7a168

I love everything about this proposal!

This proposal has passed!

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

Any indication on the timeline for implementation?

We now have majority adoption of 0.8.2 and the upgrade has been set to activate at block height 57616, which should fall around 10-11am EDT tomorrow, Apr 26th.

Note that larger consensus-based features such as non-custodial staking will be activated at a later date.