Skip to content

Latest commit

 

History

History
70 lines (45 loc) · 5.1 KB

oip-0003.md

File metadata and controls

70 lines (45 loc) · 5.1 KB
Raw

Community Voting for Order Providers

REChain Improvement Proposal

RIP: 0003
Title: Community Voting for Order Providers
Author: Dmitry Sorokin
Discussions-To: Matrix - https://matrix.to/#/#chatting:matrix.katya.wtf
Comments-Summary: No comments yet
Status: Draft
Type: Standards Track
Created: 2024-08-09
License: BSD-2-Clause and CC0-1.0

Abstract

This proposal suggests an extension to the REChain consensus protocol, enabling users to continuously vote for their preferred Order Providers (OPs) on-chain. The weight of each vote is determined by the user’s balance. With this update, the power to influence the list of OPs transitions from incumbent OPs and hubs to the users themselves.

Copyright

This RIP is dual-licensed under the Creative Commons CC0 1.0 License and BSD 2-clause license.

Motivation

Presently, any changes to the OP list require approval from the majority of the existing OPs. Although users can modify their OP list, further changes are contingent on the incumbent OPs adopting these initial changes. This dynamic could potentially lead to a situation where the current OPs, if they choose to act against the community's interests, could entrench themselves permanently. Even though OPs currently have limited power, their ability to block future changes to the OP list is concerning.

Furthermore, the reliance on hubs to propagate OP list changes gives these hubs significant, potentially outsized, power. To reduce centralization risks, it is essential to establish a mechanism for automatically updating the OP list, one that is immune to interference from current OPs and hubs.

Specification

  1. New app type: system_vote:
    Users can submit a transaction with a message of this type, including their preferred list of 12 OP addresses in the payload. The format is {"subject": "op_list", "value": ["ADDRESS1", "ADDRESS2", ... "ADDRESS12"]}, where subject denotes the voting topic. Upon transaction finality, the vote is recorded for all addresses that signed the transaction. A new system_vote from the same address overwrites any previous vote. The votes are timestamped with the transaction's timestamp.

  2. New app type: system_vote_count:
    Users can trigger a vote count by submitting a transaction with this message type. The payload should contain the subject name (e.g., op_list). The vote count occurs upon transaction finality. The stable balances of all voting addresses within the voting timeframe are used to tally votes. The top 12 OP candidates, sorted by the total votes received, form the new network-wide OP list. Ties are broken by sorting candidates by their address in ascending order.

  3. Voting Timeframe:
    The timeframe for counting votes starts with the past year. If votes within this period represent at least 10% of the total supply of Bytes, the 1-year timeframe is used. Otherwise, the timeframe expands in 1-year increments until it includes votes representing at least 10% of the total supply or until it extends to the beginning of the upgrade activation.

  4. Transaction Fee for system_vote_count:
    A 1 GBYTE fee is required to initiate the system_vote_count process. This fee is burned to prevent denial-of-service (DoS) attacks by imposing a significant cost on potential attackers.

  5. Transaction Format Update:
    The witnesses and witness_list_unit fields are removed, and the transaction version is updated to 4.0. The 1-mutation rule is no longer applicable to new transactions.

  6. Stability Point Evaluation:
    Stability points are evaluated against the system-wide OP list instead of the last stable unit's OP list.

  7. Upgrade Activation:
    The new rules apply to units whose last ball MCI follows a specific upgrade MCI, set far enough in the future to allow all nodes to upgrade.

  8. Initial System-Wide OP List:
    The initial system-wide OP list post-upgrade is derived from the current OP list on the main hub at the time of implementation. This list is hardcoded into the node code.

  9. Pre-loaded Votes:
    Prior to the upgrade, several high-value addresses are pre-loaded with votes favoring the initial OP list. These votes are automatically recorded even if the addresses have not yet submitted a vote transaction.

Rationale

The proposed changes shift the responsibility for selecting OPs from off-chain coordination to on-chain governance, leveraging the inherent strengths of distributed ledgers. This reduces the risk of incumbent OPs blocking changes that would unseat them and ensures that the OP list reflects the community's current preferences.

The requirement for a significant transaction fee to trigger vote counting is a protective measure against network abuse, ensuring that only serious and considered actions affect the network.

Pre-loading votes from high-value addresses ensures the initial OP list remains stable until the community has had ample opportunity to participate in the voting process, preventing premature or unrepresentative changes.

Backwards Compatibility

This is a breaking change, requiring all nodes to upgrade before the specified upgrade MCI as outlined in rule 7.