translate some mining articles

docs/mining/concepts/mining-reward-maturity.md

@@ -3,3 +3,54 @@ sidebar_position: 6
 ---
 
 # Mining Reward Maturity
+
+How long it takes to spend rewards after a block is mined.
+
+The MVC mining reward maturity period refers to the time that newly mined MVC must wait on the blockchain network before
+it can be used for transactions or transfers. In the MVC network, this maturity period is typically 100 blocks. This
+means that after a miner successfully mines a block and receives an MVC reward, they must wait for approximately 100
+blocks before these MVCs are considered mature and usable.
+
+The reasons for setting the maturity period in MVC, like in other POW blockchain networks, are mainly to maintain
+network security and stability.
+
+## Why is there a Maturity Period
+
+The maturity period is established for the following reasons:
+
+1. **Network Security**: By setting a maturity period, it can prevent miners from executing double-spending attacks on
+   the network. If a miner tries to reorganize the blockchain (for example, attempting to reverse already confirmed
+   transactions), the maturity period makes such attacks more difficult because the attacker would need to re-mine a
+   large number of blocks.
+
+2. **Blockchain Stability**: The maturity period can increase the stability of the blockchain, preventing short-term
+   block reorganizations from affecting miner rewards and transaction confirmations.
+
+3. **Consistency**: During the maturity period, network nodes have time to confirm the legality of newly mined blocks
+   and transactions, ensuring consistency in the blockchain state across all nodes.
+
+## How to Calculate the Maturity Period
+
+Calculating the maturity period is relatively simple, involving the following basic steps:
+
+1. **Mine a New Block**: A miner successfully mines a new block and receives a reward, for example, at block height `n`.
+
+2. **Wait for 100 Blocks**: The miner needs to wait for 100 blocks to be mined after this block. This means that when
+   the blockchain reaches height `n+100`, the newly mined MVC rewards will mature and become usable.
+
+Assuming the MVC network mines a new block approximately every 10 minutes, the maturity period would be about 10 minutes
+multiplied by 100, which is approximately 1000 minutes (about 16.67 hours).
+
+## Example Explanation
+
+If a miner mines a block at block height `70000` and receives a reward, these reward MVCs must wait until the block
+height reaches `70100` before they can be used. During this period, the miner can see these rewards in their wallet but
+cannot perform any transactions with them.
+
+Through this process, the MVC network ensures that newly mined MVCs have sufficient time to be confirmed by the network
+before they are used, thereby maintaining network security and consistency.
+
+## Handling of the Maturity Period by MVCPool
+
+MVCPool will wait for the reward to mature before distributing it after the reward calculation is completed. During this
+period, the confirmation number of the maturity period will be displayed.

docs/mining/concepts/reorg-orphan-51attack.md

@@ -3,3 +3,172 @@ sidebar_position: 8
 ---
 
 # Reorg, Orphan, and 51% Attack
+
+Key mechanisms for resolving conflicts and achieving consensus in POW.
+
+In the POW process, miners compete to solve a mathematical problem to receive mining rewards. The process of solving
+this problem is random, so different miners might find different solutions simultaneously. When different miners find
+different solutions at the same time, a fork occurs.
+
+To ensure the uniqueness of the blockchain, the consensus network will select one fork as the main chain and consider
+the other forks as orphaned forks.
+
+## Block Reorganization
+
+Block reorganization (reorg) refers to the process where existing blocks in the blockchain are replaced by a new, longer
+chain. This phenomenon occurs when two or more miners almost simultaneously mine valid blocks, and these blocks are
+added to the end of the chain. However, due to network propagation delays, different nodes might receive different
+blocks, temporarily creating multiple forked chains.
+
+POW follows the longest chain principle or the maximum work principle. Therefore, if multiple forks exist
+simultaneously, the consensus network will choose the fork with the largest workload as the main chain, and the other
+forks will be isolated, with all transactions in the isolated forks being rolled back (if a transaction exists in
+multiple forks, it will only take effect once in the final accepted chain).
+
+### Why Block Reorganizations Occur
+
+Block reorganizations mainly occur due to the following reasons:
+
+1. **Simultaneous Discovery of New Blocks**: If two miners almost simultaneously find valid blocks, these blocks will be
+   added to the end of the chain. However, due to network propagation delays, some nodes will receive one block, while
+   other nodes will receive the other block, forming a temporary fork.
+
+2. **Network Delays**: Since the MVC network is distributed, network delays can cause different nodes to receive new
+   blocks at different times, leading to temporary forks.
+
+3. **Network Attacks**: In some cases, malicious miners may attempt to reorganize the blockchain to execute
+   double-spending attacks. The attacker will try to mine a forked chain and hope that this chain becomes longer than
+   the original chain, thus becoming the main chain.
+
+### Block Reorganization Process
+
+1. **Forming a Fork**: Suppose after block height `N`, miners A and B almost simultaneously find two new valid
+   blocks `N+1A` and `N+1B`. Some nodes will receive `N+1A`, while others will receive `N+1B`.
+
+2. **Propagation and Confirmation**: Over time, miners continue working and mining new blocks. Suppose miner C
+   finds `N+2A` based on `N+1A`, and miner D finds `N+2B` based on `N+1B`.
+
+3. **Selecting the Longest Chain (Maximum Workload)**: According to MVC protocol, nodes will select the longest received
+   chain as the main chain. If both `N+1A` and `N+1B` chains each generate a new block, both chains have the same length
+   with no priority. Until a new block, say `N+3A`, is found on the `N+1A` chain, making it longer, nodes will consider
+   the `N+1A` chain as the main chain.
+
+4. **Reorganization**: Once the `N+1A` chain is confirmed as the main chain, all nodes holding the `N+1B` chain will
+   discard `N+1B` and `N+2B` and accept the `N+1A` chain and its subsequent blocks. This process is known as block
+   reorganization.
+
+### Effects of Block Reorganization
+
+1. **Transaction Confirmation**: During reorganization, some transactions confirmed on the discarded chain may become
+   invalid. These transactions will return to the memory pool and await re-confirmation on the new chain.
+
+2. **Network Security**: Frequent block reorganizations can affect network stability. However, MVC network's difficulty
+   adjustment mechanism and mining reward maturity period help prevent frequent reorganizations and enhance network
+   security.
+
+In summary, block reorganization is part of the MVC network's normal operation. This mechanism helps the network
+maintain final consistency and security in the face of temporary forks.
+
+## Orphan Blocks
+
+### What are Orphan Blocks
+
+Orphan blocks are blocks that are discarded by the blockchain. When a block is discarded, the transactions it contains
+are also rolled back. These transactions may be repackaged into the main chain or discarded due to conflicts.
+
+Miners should avoid creating orphan blocks as they waste computational power and time.
+
+### Possible Causes of Orphan Blocks
+
+Due to MVC's unlimited block size, orphan blocks are unavoidable under poor network conditions. Possible causes include:
+
+1. **Miner Network Delays**: After finding a block, a miner may not be able to propagate it promptly due to network or
+   synchronization delays.
+2. **Large Blocks**: Large blocks may prevent some miners from receiving them in time, resulting in orphan blocks.
+3. **Inconsistent Memory Pool Fees**: Different miners use different fee strategies, leading to memory pool
+   synchronization inconsistencies, increasing the difficulty of synchronizing blocks and causing orphan blocks.
+
+### How to Avoid Orphan Blocks
+
+If miners or mining pools encounter orphan blocks, they can take the following steps to avoid them:
+
+1. **Enhance Connectivity**: Increase connections with other miners to reduce network delays.
+2. **Increase Fee Rates**: Set higher packaging and relay fees to ensure transactions are more likely included in other
+   miners' memory pools.
+3. **Reduce Transaction Size**: Minimize transaction size to reduce block size and improve propagation speed.
+
+### Double-Edged Sword
+
+While methods 2 and 3 reduce potential fee income for miners, only method 1 can balance network stability and miner
+profitability.
+
+Therefore, orphan blocks are not just a network issue but also an incentive mechanism, encouraging miners to invest more
+in connectivity to earn higher fee income. This leads to a more interconnected small-world network, enhancing overall
+MVC network performance and throughput, supporting higher TPS and MVC's grand vision.
+
+## 51% Attack
+
+### What is a 51% Attack
+
+A 51% attack occurs when a miner or mining pool controls more than 50% of the computing power (hash rate) in the MVC
+network, allowing them to manipulate the blockchain. By controlling the majority hash rate, attackers can execute
+malicious actions on the blockchain. This threat exists in any POW blockchain network.
+
+### How to Execute a 51% Attack
+
+Steps to execute a 51% attack include:
+
+1. **Accumulate Computing Power**: Attackers need enough computing power to exceed 50% of the network's total hash rate,
+   requiring significant resources and hardware.
+2. **Fork the Blockchain**: With majority hash rate control, attackers can mine an independent fork without broadcasting
+   new blocks to the network.
+3. **Attack Moment**: When the attacker's fork becomes longer than the main chain, it is broadcast to the network. The
+   MVC network accepts the longest chain as valid, causing nodes to adopt the attacker's fork and discard the original
+   chain.
+
+In practice, attackers may need more than 50% hash rate (e.g., over 90%) for a successful attack.
+
+### Risks of a 51% Attack
+
+A 51% attack can cause double-spending and transaction rollbacks:
+
+1. **Double-Spending Attack**: Attackers can execute double-spending by making a transaction on the main chain and not
+   including it on their fork. When their fork becomes the main chain, the original transaction is reversed, allowing
+   attackers to spend the same funds again.
+2. **Blocking Transaction Confirmation**: Attackers can prevent specific or all transactions from being confirmed by not
+   including them in blocks.
+3. **Obstructing Other Miners**: Attackers can reject other miners' blocks, monopolizing block rewards.
+4. **Undermining Network Trust**: Frequent 51% attacks erode user trust, causing price drops and user attrition.
+
+A 51% attack can only double-spend and rollback transactions, but cannot alter historical records, steal private keys,
+or unauthorized assets.
+
+The primary targets of a 51% attack are exchanges and services sensitive to double-spending, such as asset bridges,
+allowing attackers to fake deposits and withdraw funds.
+
+### How to Avoid a 51% Attack
+
+1. **Increase Network Hash Rate**: A higher total hash rate makes it harder and costlier to control 51%. Attracting more
+   miners enhances network security.
+2. **Decentralize Mining Pools**: Encourage miners to use different pools to avoid centralization risks.
+3. **Hard Fork and Consensus Mechanism Changes**: In extreme cases, developers and the community can hard fork or
+   implement new security measures.
+4. **Economic Incentives**: Maintain healthy economic incentives to make attack costs higher than potential gains,
+   ensuring high MVC market value and transaction volume.
+5. **Monitoring and Warning Systems**: Implement systems to monitor hash rate distribution and issue warnings if an
+   entity's hash rate approaches or exceeds 50%.
+6. **Increase Confirmation Counts**: Services like exchanges can increase confirmation counts to raise double-spending
+   costs and reduce attack likelihood.
+
+In summary, while a 51% attack poses a significant threat, increasing network hash rate, decentralizing pools, adjusting
+consensus mechanisms, and establishing monitoring systems can effectively reduce the risk.
+
+### Honest Miners
+
+During a 51% attack, the attacker struggles to maintain sustained high hash rates, usually resulting in a temporary
+burst of power. If the MVC network suffers a severe double-spending attack, victims can join honest miners to mark the
+attacker's blocks as invalid and persistently mine the un-double-spent chain. Over time, the cumulative workload will
+surpass the attack fork, causing the attacker's fork to be reorganized, recovering losses.
+
+These miners are known as honest miners, who monitor double-spending transactions, mark potential double-spending risks,
+and confirm double-spending transactions, effectively protecting MVC network security.