Skip to content

oip-0004.md

Latest commit

 

History

History
45 lines (27 loc) · 3.62 KB

oip-0004.md

File metadata and controls

45 lines (27 loc) · 3.62 KB
Raw

Emergency Replacement of Order Providers

Proposal Identifier: REIP-0004
Title: Emergency Replacement of Order Providers
Author: Dmitry Sorokin Discussion: Matrix - https://matrix.to/#/#chatting:matrix.katya.wtf Comments Summary: No comments yet
Status: Draft
Type: Standards Track
Created: 2023-11-10
License: BSD-2-Clause and CC0-1.0

Abstract

This proposal extends the REChain consensus protocol to allow for the emergency replacement of Order Providers (OPs) if the network fails to advance its stability point for an extended period. This enhancement aims to improve network resilience against sabotage. It builds upon the principles established in REIP3.

Copyright

This proposal is dual-licensed under the Creative Commons CC0 1.0 License and the BSD 2-Clause License.

Motivation

In the unlikely event that the majority of OPs cease operations, the network's stability point could stagnate, preventing new transactions, including those voting for OP list changes (as per REIP3), from achieving finality. This scenario presents a risk of network sabotage, which could only be addressed by a disruptive hard fork, necessitating off-chain coordination and potentially resulting in competing forks or no resolution at all.

To mitigate this risk, the automatic OP replacement mechanism introduced in REIP3 should also function under conditions where transactions voting for a new OP list cannot reach finality.

Specification

  1. Emergency Count Transaction: Amend the processing of system_vote_count messages with app type and subject op_list (as introduced in REIP3). These messages will be handled immediately if the timestamp of the transaction differs by 3 days or more from the last stable unit. This will be termed an emergency count transaction. The vote count will include votes timestamped at least 1 hour before the emergency transaction, regardless of their stability. Only votes from transactions without conflicting ones will be considered. Upon counting, the new OP list will be applied immediately and used to advance the stability point.

  2. Post-Emergency Stability Handling: Once the emergency count transaction becomes stable, it will be processed as described in REIP3. This may result in a different OP list, which will then be applied through standard procedures.

  3. Upgrade Activation: Implement this upgrade concurrently with REIP3.

Rationale

This change ensures network recovery if the majority of OPs become inactive. The emergency count relies on unstable data, which might differ across nodes, potentially leading to network partitioning. However, this proposal minimizes the risk of such partitions.

The emergency count will only activate after 3 days of network inactivity, reducing the likelihood of accidental triggering. Balances from the last stable period will be used, with emergency votes considered if they are older than 1 hour to ensure broad propagation. Attackers could attempt to skew results, but their impact would be limited by their own balance and the network's existing safeguards.

If discrepancies arise, a subsequent standard vote count will reconcile results. Nodes will handle conflicting transactions with a fallback to ensure consistency. Attempts to undermine the network through shadow chains or other methods will be mitigated by the established protocols and the need for significant balances to affect outcomes.

Backwards Compatibility

This proposal introduces breaking changes; all nodes must upgrade before the specified upgrade MCI as per rule 3.