1. Since there are many region and zone, do you think each region/zone would have active nodes, miners and users? IMO with current Bitcoin state, i'm sure many region/zone would have empty block (no transaction).
The idea of BlockReduce is that the protocol would be able to adjust the block size and the number of region and zones such that the system operates near capacity say 80% fill. This will ensure that transaction fees are non-zero, but also that there is economic incentive to balance transaction demand evenly amongst the zones. This also will help to create transaction revenue to incentivize miners to continue to secure the chain when inflation block rewards move towards zero.
2. In 4.4, it mentions that region and zone have lower mining difficulty. If so, what stopping attacker from 51% hash rate attack to prevent transaction from confirmed or double-spend transaction? I've read 4.11, but IMO it's not good enough since :
Attacker might pretend as honest 40%/miner with minority hash rate
Human intervention is required (move to different zone)
The zone is only a mechanism in which incremental work ensures valid transaction processing without necessarily requiring other nodes validate all transactions. This does not mean that other nodes don't need to verify the transactions. If they have enough hash power they will be economically incentivized to validate a greater number of transactions from further removed zones to ensure they never lose work. Additionally, even light nodes could validate transactions of adjacent zones without necessarily having to keep canonical state. Large miners will keep the entirety of state as well as verify all transactions just because they do not want to lose hash working on bad blocks. Even if a bad block is added in a zone, it will eventually be found and thrown out as it propagates up into regions and zones. Ideally, it will be found out quickly in a zone, but if it is not, eventually all hash power in the network will work on it, which means that to get included persistently in PRIME it would be a 51% attack of all network hash.
3. In 4.5, it mentions "If multiple inputs are used in a transaction, they must reside within the same scope, meaning inputs must be taken from the same zone". Is it possible to treat it only as region/PRIME transaction scope?
Originally, I thought that this could be done. However, I don't think it is a good idea because if a UTXO had PRIME scope, a user could initiate conflicting transactions in many zones. This would take some time to be discovered and would cause significant waste of hash power. If the PRIME transaction was sufficiently expensive to make this type of SPAM attack unreasonably expensive, it could be done.
4. Since both nodes with PRIME and region scope require more resources. IMO, centralization or control will happen since there's less group or nodes that needs to be attacked/hijacked.
There could potentially be some amount of centralization, but the fact that nodes can have a continuum of different resource requirements is decentralizing. Additionally, the fact that overlap of verification and processing is not prescriptive, but rather variable based on a nodes economic incentives, it will create a diverse overlapping set of miners.
5. With region and zone scope, this will make bitcoin less pseudonymous since this would make transaction tracking analysis far easier
There will be some decrease in anonymity, however this is likely small and can be managed by the user if they desire better privacy. If a user is in a set of 1/4 of bitcoin transactions rather than all bitcoin transactions there is less anonymity. That user could choose to operate throughout all zones which would cost slightly more, but would provide the same amount of anonymity as bitcoin.
Your idea is interesting, but i seriously doubt Bitcoin community will accept idea since :
1. Increase bitcoin development complexity a lot
This is actually an incredibly simple change to the bitcoin code base. It only requires a change in the block header, transaction header, peer management, and the chain database.