Skip to content

Latest commit

 

History

History
67 lines (41 loc) · 8.5 KB

oip-0003.md

File metadata and controls

67 lines (41 loc) · 8.5 KB
Raw

Community voting for Order Providers

Obyte improvement proposal (under the rules of OIP1)

OIP: 0003
Title: Community voting for Order Providers
Author: Tony Churyumoff @tonych
Discussions-To: discord #tech
Comments-Summary: No comments yet
Comments-URI: https://github.com/byteball/OIPs/issues/6
Status: Active
Type: Standards Track
Created: 2023-11-10
License: BSD-2-Clause and CC0-1.0

Abstract

An extension of Obyte consensus protocol is proposed which allows users to continuously vote for their preferred list of Order Providers (OPs). The voting happens on-chain and vote weight is determined by user balance. With this update, the incumbent OPs and hubs will lose the power to influence the future list of OPs, and this power will belong to users.

Copyright

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

Motivation

Currently, any changes to the Order Provider list should still be accepted by the majority of the incumbent OPs. Users are currently allowed to make 1 mutation to their OP list relative to all unstable MC units. However, since some of these MC units were necessarily posted by the incumbent OPs, making any further mutations is impossible before the incumbent OPs adopt the 1st mutation. The OPs are expected to follow the community's desires about updating the OP list, however nothing can force them to do so, and if the majority of the current OPs decide to go rogue for any reason, they are able to lock themselves in as OPs forever and block all future changes to the OP list. Although this doesn't pose an immediate threat to the network as they already have little power (they, even as a majority, cannot censor transactions, unlike block producers in blockchains), still their ability to block changes that would unseat them is not a good thing.

Also, we rely on hubs to propagate changes of the OP list. Of course, people can change hubs, but we know that users are generally lazy and tend to stick to defaults, and this gives the hubs some outsized power. We want to avoid concentration of power as much as possible.

In light of this, it would be great to have a way to automatically update the OP list, a way that the incumbent OPs and hubs cannot interfere with.

Specification

  1. We introduce a new app type: system_vote. Anyone can send a transaction with a message of this type and include the list of 12 addresses of the user's preferred OPs within the message's payload, The payload is be formatted as {"subject": "op_list", "value": ["ADDRESS1", "ADDRESS2", ... "ADDRESS12"]}, where subject indicates what is being voted for (in the future, it can also take other values to enable voting for other variables). Such a message casts a vote for the included OP list. The addresses of the proposed OPs must not be AAs and must have posted at least once before the vote. As soon as the transaction reaches finality, the vote is recorded against all addresses that signed the transaction. The balances of the voting addresses are irrelevant at the time of voting. A new system_vote from the same address overwrites the address's previous vote. The votes are tagged with the timestamp of the voting transaction.
  2. We introduce another new app type: system_vote_count. Anyone can send a transaction with a message of this type to trigger a count of the previously cast votes for the subject indicated in the message's payload (for now, only OP list). The payload is simply the name of the subject, op_list for voting about the OP list. The count would be actually processed when the transaction reaches finality. To count the votes, we calculate the stable balances in Bytes of all addresses that voted for the said subject within the voting timeframe (see below). A stable balance of an address means that all unstable outputs to the address are ignored, and all unstable transactions spending from this address should be unspent for the purposes of the balance calculation. The number of votes for each OP candidate is calculated as the total balance of all voters who included the given OP address. All candidates are sorted by the total votes they got, and the top 12 are selected as the new network-wide OP list. In case of a tie, candidates are sorted by their address in ascending order.
  3. The timeframe for vote count is selected as follows. First, calculate the total balance of all voters who voted within the last year (between the timestamp of their vote and the timestamp of the system_vote_count transaction). If it exceeds or equals 10% of the total supply of Bytes, use the 1-year timeframe. Otherwise, expand the period to 2 years and if the total voted balance within 2 years exceeds or equals 10% of the total supply of Bytes, use the 2-year timeframe. Otherwise, continue expanding the timeframe in the same fashion, by 1 year per step, until the start of the tested period falls before the activation of this upgrade, in which case use this timeframe.
  4. The transaction that sends system_vote_count must pay a 1 GBYTE fee, which is burned.
  5. The fields witnesses and witness_list_unit are removed from the transaction format and the version field of the transactions formatted according to the new rules is 4.0 (4.0t for testnet). The 1-mutation rule stops applying for the new transactions.
  6. The stability point is evaluated against the system-wide OP list instead of the OP list of the last stable unit.
  7. The above rules start applying to units whose last ball MCI is after a specific upgrade MCI (which will be set to a value well in the future to give all nodes enough time to upgrade).
  8. The initial system-wide OP list after the activation of the upgrade is equal to the current OP list on the main hub at the moment when this OIP's implementation is finished. This list is hardcoded in the node code.
  9. Before the upgrade, all nodes are "pre-loaded" with votes of several high-value addresses in favor of the initial OP list. This means that their votes are recorded in favor of the initial OP list even though they didn't cast any vote transaction yet. They can override their votes after the upgrade is activated.

Rationale

The proposed change replaces off-chain coordination that we currently use to choose OPs with automatic, on-chain coordination. Distributed ledgers are generally good tools for coordination, and it is natural for a DLT to use its own capabilities to power its own governance.

The incumbent OPs lose the ability to block the OP list changes. They can still try to censor the transactions that vote against them or their friends, but, like censoring any other transaction, this attempt would lead to the OP censoring themselves if they are in a minority, or to sabotage of the entire network if they are in the majority.

The process of choosing OPs is similar to the process of choosing block producers in DPoS blockchains.

The rationale for paying a large (1 GBYTE) fee for the system_vote_count command in rule 4 is that vote count involves expensive computation and this command could be used to DoS the network. The fee introduces a significant cost to the attacker if they want to conduct a sustained attack. It is expected that the command will be rarely used and the fate of the spent fee is therefore of little importance. It is proposed that the fee is burned just because it is a technically simple solution.

It is important to ensure that the OP list can be practically changed when the community so desires and at the same time protect it from manipulation. That's why in rule 3 we first attempt to account only for the most recent votes. The problem with old votes is that their owners might die or lose access to their private keys, and their votes might still add weight to some outdated OP list, thus making it difficult to update the list down the road. Applying a 1-year long window solves this problem by excluding such votes. However, if voter activity was low during the past year, it opens the possibility of changing the OP list using a relatively small balance. To avoid that, we broaden the timeframe if the most recent votes don't represent a big enough share of the community.

The rule 9 protects against introduction of a new OP list supported by small balance immediately after the activation of the upgrade, before most users had a chance to vote. With rule 9, the attacker would need to command a balance that exceeds the total pre-loaded balance.

Backwards compatibility

It is a breaking change and all nodes will have to upgrade before the upgrade MCI as indicated in rule 7.