# PIP-9 Consensus Rule Change – RC-0.8.0 **URL:** \ **Category:** Improvements\ **Tags:** approved\ **Created:** [December 13, 2021, 2:41pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351 "2021-12-13T14:41:26Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Andrew](https://forum.pokt.network/user_avatar/forum.pokt.network/andrew/32/7_2.png) [@Andrew](https://forum.pokt.network/u/Andrew)\ **Post date:** [December 13, 2021, 2:41pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/1 "2021-12-13T14:41:26Z")
# 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 ```auto 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 ```auto // 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 ```auto // Rules If Node Falls Below Minimum Stake -> Normal (21 Day) Unstake ``` ### Non-Deterministic Invalid Evidence Fix Protocol ```auto // Rules Validator Checks if Evidence is previously committed before adding it to the Proposal ``` ### Handling of ReplayAttack Error Protocol ```auto // 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](https://poktscan.com/public/explore?tab=netStats) or the equivalent “Node Versions for Staking Power” chart displayed [here](https://c0d3r.org/networkcharts)._ _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](https://creativecommons.org/publicdomain/zero/1.0/). ---
**Author:** ![Olshansky](https://forum.pokt.network/user_avatar/forum.pokt.network/olshansky/32/359_2.png) [@Olshansky](https://forum.pokt.network/u/Olshansky)\ **Post date:** [December 13, 2021, 7:16pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/2 "2021-12-13T19:16:32Z")
**+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](https://en.wikipedia.org/wiki/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. ---
**Author:** ![Jinx](https://forum.pokt.network/user_avatar/forum.pokt.network/jinx/32/433_2.png) [@Jinx](https://forum.pokt.network/u/Jinx)\ **Post date:** [December 14, 2021, 5:06am UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/3 "2021-12-14T05:06:59Z")
I support this proposal without reservation. ---
**Author:** ![Andrew](https://forum.pokt.network/user_avatar/forum.pokt.network/andrew/32/7_2.png) [@Andrew](https://forum.pokt.network/u/Andrew)\ **Post date:** [December 14, 2021, 7:34pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/4 "2021-12-14T19:34:41Z")
I think Output might be better - as it is safer from a legal perspective + is explicit about where the rewards ‘output’ to. ---
**Author:** ![Ming](https://forum.pokt.network/user_avatar/forum.pokt.network/ming/32/1021_2.png) [@Ming](https://forum.pokt.network/u/Ming)\ **Post date:** [December 15, 2021, 2:09am UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/5 "2021-12-15T02:09:11Z")
I love this proposal and fully support this. ---
**Author:** ![Olshansky](https://forum.pokt.network/user_avatar/forum.pokt.network/olshansky/32/359_2.png) [@Olshansky](https://forum.pokt.network/u/Olshansky)\ **Post date:** [December 15, 2021, 5:07pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/6 "2021-12-15T17:07:24Z")
Makes sense to me. Let’s stick with `Output` and +100 to the whole proposal. ---
**Author:** ![o\_rourke](https://forum.pokt.network/user_avatar/forum.pokt.network/o_rourke/32/10_2.png) [@o\_rourke](https://forum.pokt.network/u/o_rourke)\ **Post date:** [December 17, 2021, 9:31am UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/7 "2021-12-17T09:31:56Z")
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. ---
**Author:** ![luyzdeleon](https://forum.pokt.network/user_avatar/forum.pokt.network/luyzdeleon/32/423_2.png) [@luyzdeleon](https://forum.pokt.network/u/luyzdeleon)\ **Post date:** [December 22, 2021, 2:08pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/8 "2021-12-22T14:08:30Z")
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. ---
**Author:** ![desertislandtom](https://forum.pokt.network/user_avatar/forum.pokt.network/desertislandtom/32/536_2.png) [@desertislandtom](https://forum.pokt.network/u/desertislandtom)\ **Post date:** [January 17, 2022, 4:24pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/9 "2022-01-17T16:24:38Z")
I concur. removing this counterparty risk would be extremely beneficial to the project at large I support this without reservation. ---
**Author:** ![JackALaing](https://forum.pokt.network/user_avatar/forum.pokt.network/jackalaing/32/39_2.png) [@JackALaing](https://forum.pokt.network/u/JackALaing)\ **Post date:** [January 25, 2022, 5:48pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/10 "2022-01-25T17:48:05Z")
This proposal is now up for voting. [https://gov.pokt.network/#/proposal/0x5527a5aec65f0e7e708813f4d7b0376f68dcf986b0b88045bf0126d699a7a168](https://gov.pokt.network/#/proposal/0x5527a5aec65f0e7e708813f4d7b0376f68dcf986b0b88045bf0126d699a7a168) ---
**Author:** ![ArtSabintsev](https://forum.pokt.network/user_avatar/forum.pokt.network/artsabintsev/32/2654_2.png) [@ArtSabintsev](https://forum.pokt.network/u/ArtSabintsev)\ **Post date:** [January 27, 2022, 4:49am UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/11 "2022-01-27T04:49:39Z")
I love everything about this proposal! ---
**Author:** ![JackALaing](https://forum.pokt.network/user_avatar/forum.pokt.network/jackalaing/32/39_2.png) [@JackALaing](https://forum.pokt.network/u/JackALaing)\ **Post date:** [February 4, 2022, 2:10am UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/12 "2022-02-04T02:10:12Z")
This proposal has passed! [https://gov.pokt.network/#/proposal/0x5527a5aec65f0e7e708813f4d7b0376f68dcf986b0b88045bf0126d699a7a168](https://gov.pokt.network/#/proposal/0x5527a5aec65f0e7e708813f4d7b0376f68dcf986b0b88045bf0126d699a7a168) ---
**Author:** ![Desmond](https://forum.pokt.network/letter_avatar_proxy/v4/letter/d/e495f1/32.png) [@Desmond](https://forum.pokt.network/u/Desmond)\ **Post date:** [February 8, 2022, 2:09pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/13 "2022-02-08T14:09:32Z")
Any indication on the timeline for implementation? ---
**Author:** ![JackALaing](https://forum.pokt.network/user_avatar/forum.pokt.network/jackalaing/32/39_2.png) [@JackALaing](https://forum.pokt.network/u/JackALaing)\ **Post date:** [April 25, 2022, 10:35pm UTC](https://forum.pokt.network/t/pip-9-consensus-rule-change-rc-0-8-0/1351/14 "2022-04-25T22:35:40Z")
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.