@@ -3,3 +3,172 @@ sidebar_position: 8
33---
44
55# Reorg, Orphan, and 51% Attack
6+
7+ Key mechanisms for resolving conflicts and achieving consensus in POW.
8+
9+ In the POW process, miners compete to solve a mathematical problem to receive mining rewards. The process of solving
10+ this problem is random, so different miners might find different solutions simultaneously. When different miners find
11+ different solutions at the same time, a fork occurs.
12+
13+ To ensure the uniqueness of the blockchain, the consensus network will select one fork as the main chain and consider
14+ the other forks as orphaned forks.
15+
16+ ## Block Reorganization
17+
18+ Block reorganization (reorg) refers to the process where existing blocks in the blockchain are replaced by a new, longer
19+ chain. This phenomenon occurs when two or more miners almost simultaneously mine valid blocks, and these blocks are
20+ added to the end of the chain. However, due to network propagation delays, different nodes might receive different
21+ blocks, temporarily creating multiple forked chains.
22+
23+ POW follows the longest chain principle or the maximum work principle. Therefore, if multiple forks exist
24+ simultaneously, the consensus network will choose the fork with the largest workload as the main chain, and the other
25+ forks will be isolated, with all transactions in the isolated forks being rolled back (if a transaction exists in
26+ multiple forks, it will only take effect once in the final accepted chain).
27+
28+ ### Why Block Reorganizations Occur
29+
30+ Block reorganizations mainly occur due to the following reasons:
31+
32+ 1 . ** Simultaneous Discovery of New Blocks** : If two miners almost simultaneously find valid blocks, these blocks will be
33+ added to the end of the chain. However, due to network propagation delays, some nodes will receive one block, while
34+ other nodes will receive the other block, forming a temporary fork.
35+
36+ 2 . ** Network Delays** : Since the MVC network is distributed, network delays can cause different nodes to receive new
37+ blocks at different times, leading to temporary forks.
38+
39+ 3 . ** Network Attacks** : In some cases, malicious miners may attempt to reorganize the blockchain to execute
40+ double-spending attacks. The attacker will try to mine a forked chain and hope that this chain becomes longer than
41+ the original chain, thus becoming the main chain.
42+
43+ ### Block Reorganization Process
44+
45+ 1 . ** Forming a Fork** : Suppose after block height ` N ` , miners A and B almost simultaneously find two new valid
46+ blocks ` N+1A ` and ` N+1B ` . Some nodes will receive ` N+1A ` , while others will receive ` N+1B ` .
47+
48+ 2 . ** Propagation and Confirmation** : Over time, miners continue working and mining new blocks. Suppose miner C
49+ finds ` N+2A ` based on ` N+1A ` , and miner D finds ` N+2B ` based on ` N+1B ` .
50+
51+ 3 . ** Selecting the Longest Chain (Maximum Workload)** : According to MVC protocol, nodes will select the longest received
52+ chain as the main chain. If both ` N+1A ` and ` N+1B ` chains each generate a new block, both chains have the same length
53+ with no priority. Until a new block, say ` N+3A ` , is found on the ` N+1A ` chain, making it longer, nodes will consider
54+ the ` N+1A ` chain as the main chain.
55+
56+ 4 . ** Reorganization** : Once the ` N+1A ` chain is confirmed as the main chain, all nodes holding the ` N+1B ` chain will
57+ discard ` N+1B ` and ` N+2B ` and accept the ` N+1A ` chain and its subsequent blocks. This process is known as block
58+ reorganization.
59+
60+ ### Effects of Block Reorganization
61+
62+ 1 . ** Transaction Confirmation** : During reorganization, some transactions confirmed on the discarded chain may become
63+ invalid. These transactions will return to the memory pool and await re-confirmation on the new chain.
64+
65+ 2 . ** Network Security** : Frequent block reorganizations can affect network stability. However, MVC network's difficulty
66+ adjustment mechanism and mining reward maturity period help prevent frequent reorganizations and enhance network
67+ security.
68+
69+ In summary, block reorganization is part of the MVC network's normal operation. This mechanism helps the network
70+ maintain final consistency and security in the face of temporary forks.
71+
72+ ## Orphan Blocks
73+
74+ ### What are Orphan Blocks
75+
76+ Orphan blocks are blocks that are discarded by the blockchain. When a block is discarded, the transactions it contains
77+ are also rolled back. These transactions may be repackaged into the main chain or discarded due to conflicts.
78+
79+ Miners should avoid creating orphan blocks as they waste computational power and time.
80+
81+ ### Possible Causes of Orphan Blocks
82+
83+ Due to MVC's unlimited block size, orphan blocks are unavoidable under poor network conditions. Possible causes include:
84+
85+ 1 . ** Miner Network Delays** : After finding a block, a miner may not be able to propagate it promptly due to network or
86+ synchronization delays.
87+ 2 . ** Large Blocks** : Large blocks may prevent some miners from receiving them in time, resulting in orphan blocks.
88+ 3 . ** Inconsistent Memory Pool Fees** : Different miners use different fee strategies, leading to memory pool
89+ synchronization inconsistencies, increasing the difficulty of synchronizing blocks and causing orphan blocks.
90+
91+ ### How to Avoid Orphan Blocks
92+
93+ If miners or mining pools encounter orphan blocks, they can take the following steps to avoid them:
94+
95+ 1 . ** Enhance Connectivity** : Increase connections with other miners to reduce network delays.
96+ 2 . ** Increase Fee Rates** : Set higher packaging and relay fees to ensure transactions are more likely included in other
97+ miners' memory pools.
98+ 3 . ** Reduce Transaction Size** : Minimize transaction size to reduce block size and improve propagation speed.
99+
100+ ### Double-Edged Sword
101+
102+ While methods 2 and 3 reduce potential fee income for miners, only method 1 can balance network stability and miner
103+ profitability.
104+
105+ Therefore, orphan blocks are not just a network issue but also an incentive mechanism, encouraging miners to invest more
106+ in connectivity to earn higher fee income. This leads to a more interconnected small-world network, enhancing overall
107+ MVC network performance and throughput, supporting higher TPS and MVC's grand vision.
108+
109+ ## 51% Attack
110+
111+ ### What is a 51% Attack
112+
113+ A 51% attack occurs when a miner or mining pool controls more than 50% of the computing power (hash rate) in the MVC
114+ network, allowing them to manipulate the blockchain. By controlling the majority hash rate, attackers can execute
115+ malicious actions on the blockchain. This threat exists in any POW blockchain network.
116+
117+ ### How to Execute a 51% Attack
118+
119+ Steps to execute a 51% attack include:
120+
121+ 1 . ** Accumulate Computing Power** : Attackers need enough computing power to exceed 50% of the network's total hash rate,
122+ requiring significant resources and hardware.
123+ 2 . ** Fork the Blockchain** : With majority hash rate control, attackers can mine an independent fork without broadcasting
124+ new blocks to the network.
125+ 3 . ** Attack Moment** : When the attacker's fork becomes longer than the main chain, it is broadcast to the network. The
126+ MVC network accepts the longest chain as valid, causing nodes to adopt the attacker's fork and discard the original
127+ chain.
128+
129+ In practice, attackers may need more than 50% hash rate (e.g., over 90%) for a successful attack.
130+
131+ ### Risks of a 51% Attack
132+
133+ A 51% attack can cause double-spending and transaction rollbacks:
134+
135+ 1 . ** Double-Spending Attack** : Attackers can execute double-spending by making a transaction on the main chain and not
136+ including it on their fork. When their fork becomes the main chain, the original transaction is reversed, allowing
137+ attackers to spend the same funds again.
138+ 2 . ** Blocking Transaction Confirmation** : Attackers can prevent specific or all transactions from being confirmed by not
139+ including them in blocks.
140+ 3 . ** Obstructing Other Miners** : Attackers can reject other miners' blocks, monopolizing block rewards.
141+ 4 . ** Undermining Network Trust** : Frequent 51% attacks erode user trust, causing price drops and user attrition.
142+
143+ A 51% attack can only double-spend and rollback transactions, but cannot alter historical records, steal private keys,
144+ or unauthorized assets.
145+
146+ The primary targets of a 51% attack are exchanges and services sensitive to double-spending, such as asset bridges,
147+ allowing attackers to fake deposits and withdraw funds.
148+
149+ ### How to Avoid a 51% Attack
150+
151+ 1 . ** Increase Network Hash Rate** : A higher total hash rate makes it harder and costlier to control 51%. Attracting more
152+ miners enhances network security.
153+ 2 . ** Decentralize Mining Pools** : Encourage miners to use different pools to avoid centralization risks.
154+ 3 . ** Hard Fork and Consensus Mechanism Changes** : In extreme cases, developers and the community can hard fork or
155+ implement new security measures.
156+ 4 . ** Economic Incentives** : Maintain healthy economic incentives to make attack costs higher than potential gains,
157+ ensuring high MVC market value and transaction volume.
158+ 5 . ** Monitoring and Warning Systems** : Implement systems to monitor hash rate distribution and issue warnings if an
159+ entity's hash rate approaches or exceeds 50%.
160+ 6 . ** Increase Confirmation Counts** : Services like exchanges can increase confirmation counts to raise double-spending
161+ costs and reduce attack likelihood.
162+
163+ In summary, while a 51% attack poses a significant threat, increasing network hash rate, decentralizing pools, adjusting
164+ consensus mechanisms, and establishing monitoring systems can effectively reduce the risk.
165+
166+ ### Honest Miners
167+
168+ During a 51% attack, the attacker struggles to maintain sustained high hash rates, usually resulting in a temporary
169+ burst of power. If the MVC network suffers a severe double-spending attack, victims can join honest miners to mark the
170+ attacker's blocks as invalid and persistently mine the un-double-spent chain. Over time, the cumulative workload will
171+ surpass the attack fork, causing the attacker's fork to be reorganized, recovering losses.
172+
173+ These miners are known as honest miners, who monitor double-spending transactions, mark potential double-spending risks,
174+ and confirm double-spending transactions, effectively protecting MVC network security.
0 commit comments