Obyte improvement proposal (under the rules of OIP1)
OIP: 0004
Title: Emergency replacement of Order Providers
Author: Tony Churyumoff @tonych
Discussions-To: discord #tech
Comments-Summary: No comments yet
Comments-URI: https://github.com/byteball/OIPs/issues/7
Status: Draft
Type: Standards Track
Created: 2023-11-10
License: BSD-2-Clause and CC0-1.0
An extension of Obyte consensus protocol is proposed which enables users to change the Order Provider (OP) list in case the network didn't advance its stability point for a long time. This ability makes the network sabotage-resistant. This OIP depends on OIP3.
This OIP is dual-licensed under the Creative Commons CC0 1.0 License and BSD 2-clause license.
One problem, even if it is a remote possibility, is that if the majority of OPs stop posting entirely (for whatever reason), the stability point would stop advancing and all new transactions (including those that vote for changes to the OP list according to OIP3) would never reach finality. This means that the OPs have the ability to sabotage the network. Only a hard fork that would introduce a new OP list would unfreeze the network. A hard fork would require off-chain coordination, and as a messy process with uncertain outcomes and potential of having several competing hard forks (or none at all), it should be avoided as much as possible.
Hence, it would be great for the automatic replacement of OPs introduced in OIP3 to also work under such special circumstances when transactions voting for a new OP list cannot reach finality.
- We make a change to how a message with
apptypesystem_vote_count(introduced in OIP3) with subjectop_listworks. Normally, it is handled only when its transaction has become finalized. Now, it becomes also handled immediately if the difference between the transaction's timestamp and the timestamp of the last stable unit exceeds or equals 3 days. We call it emergency count transaction. In this case, the vote count takes into account all the votes whose timestamps are at least 1 hour older (even if they are unstable) than the transaction's timestamp. This includes the votes sent in transactions not included by thesystem_vote_counttransaction. The vote count is based on the stable voter balances, like in the regular vote count. Thesystem_vote_counttransaction itself must not have known conflicting transactions, otherwise it is ignored. After the votes have been counted, the new OP list becomes effective immediately and it is applied to advancing the stability point. - Once the emergency count transaction becomes stable, it is handled again, in the normal fashion described in OIP3. It might yield a different resulting OP list, which is again applied in the regular fashion.
- Activate this upgrade at the same time as OIP3.
The proposed change allows the network to recover from an event when the majority of OPs stopped posting for whatever reason.
The mechanism relies on the votes that have not stabilized yet. By its nature, any result based on unstable data can be different on different nodes as they can see different transactions or even see the same transaction differently depending on the presence and order of handling of a conflicting transaction, if any. This can lead to partitioning of the network when different nodes handle the emergency vote count differently (then we'll have two or more incompatible networks). However, the specification above tries to minimize the odds of such an event.
The emergency count becomes available only after 3 days of network freeze. This is a sufficiently long period to ensure that the emergency count cannot be triggered accidentally as a result of normal irregularity of finalization time. It's also long enough to ensure that all or most nodes converge on what they see as the last stable unit.
For the emergency count, we use the last stable balances, i.e. balances seen 3 days ago, just before the freeze. After the network gets frozen, it is very unlikely that any significant movements of funds between users will happen as the transactions don't get confirmed. Balances can still move within user wallets, e.g. to change addresses, which could empty an address that had a significant balance before the freeze. However, users can easily move the funds back to such addresses, and then vote from them.
For the emergency count, we use the votes received more than 1 hour ago to make sure that these transactions had enough time to propagate to all or most nodes. Attackers can still try to confuse the nodes (make them arrive at different results of the vote count) by sending a freshly created transaction just before the emergency count command while setting this transaction's timestamp to be older than 1 hour and attaching it to an older part of the DAG. However, the attackers can skew the total voted balance only by the amount of their own balance, and the attack has chances to succeed only if the current voting is in a near-tie condition such that the attacker's balance is enough to swing it.
Even if the emergency count command produced different results for different nodes, they might still arrive at the same result when this command's transaction reaches finality and is handled again.
We require that the system_vote_count transaction has no conflicts to ensure that the 1 GBYTE fee (OIP3) is paid and we don't expose the network to a possible DoS attack. However, an attacker could send a system_vote_count transaction along with a conflicting transaction at almost the same time and hope that some nodes don't see the conflicting transaction yet and handle the command, while other nodes do see the conflict and ignore the command. Thus, the latter nodes would not apply the new OP list and would think that the network is still frozen. To recover from this condition, anyone can send another system_vote_count command which would be successfully picked up by the latter nodes. The former nodes would handle it too and arrive at the same result as before (if no large votes were sent in between).
An attacker might also try to build a shadow chain, stop building it for 3 days, then send their own votes to this shadow chain, then send a system_vote_count command to replace the OP list, then try to merge it into the legitimate chain. However, to pull off such an attack, the attacker needs to have a sufficient balance to overcome the existing votes. Even immediately after activation of the upgrade, the votes are already seeded with pre-loaded votes according to OIP3. Waiting for 1 year for the old votes to expire would not help either as the voting period is automatically expanded as per OIP3. Assuming the attacker still had a sufficient balance to replace the OPs in their shadow chain, after the shadow chain is merged into the legitimate chain, the nodes on the legitimate chain would treat the system_vote_count command as a normal, non-emergency vote count. It would produce the same result as in the shadow chain (unless there were large votes on the legitimate chain in between), which is fair if the attacker did have a sufficiently large balance. The attacker could also vote on the legitimate chain in the first place. The shadow chain would not confuse newly syncing nodes as they are able to see the legitimate chain too.
It is a breaking change and all nodes will have to upgrade before the upgrade MCI as indicated in rule 3.