ZClassic Update: Deep Reorg Protection-First Relase
The Crypto PowerPuff team is happy to announce our first release for the community. This release will help strengthen Zclassic blockchain in the following ways:
- Protect against Deep reorg in blockchain
- Finalize transactions in ~10 confirmations i.e faster transfer’s on exchanges
The blog below explains the detailed implementation of the concept. Our team has already submitted the update and would love community feedback on our work. We have adopted the solution from the BCH ABC team.
ZCL Update: Deep Reorg Protection
The above image shows the process of adding a Block in the proof of the work-based blockchain system. The entire decentralized network of the blockchain is maintained by Nodes. Nodes are programs which help in maintaining the connection across the network. Due to the immutable nature of the blockchain, the information included in the blockchain should be verified in order to maintain the ledger. The Node programs check these conditions so that only the right information is included in the network and false information is eliminated. Each Node software has the same consensus rules set from the genesis block of the chain and some policy rules. Consensus rule cannot be changed without an hard fork. Nodes can have different policy rules and can be changed without a fork.
A node completes series of the check based on the policy rules set by the developer in order to protect the blockchain from the potential harm. Some of the checks a node perform are
- Check the syntactic correctness of the transaction. Make sure neither in or out lists are empty
- Size in bytes < MAX_BLOCK_SIZE. The size should not be bigger than the block size
- Each output value, as well as the total, must be in the legal money range.
- Check inputs have hash=0, n=-1 (coinbase transactions)
- Reject “nonstandard” transactions
- Reject matching tx in the pool, or in a block in the main branch
- For each input, if the referenced output exists in any other tx in the pool, reject this transaction.
- For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.
- Reject if the sum of input values < sum of output values
- Reject if transaction fee (defined as the sum of input values minus sum of output values) would be too low to get into an empty block
- Add to the transaction pool
- Relay transaction to peers
Our update brings additions to the node policies. With the new release, all the nodes will have to manually shift to the new client. The new policies included in the node are
Auto Finalize Block
Auto finalizes the Block once they reach a depth of 10. This is done by implementing rolling checkpoints. Finalized blocks cannot be reorged, which protects the network against deep reorgs. The block will be finalized only once it fulfills 2 condition-
- The block to be finalized is at depth 10 from the tip
- The block to be finalized is known to the node for at least 30 mins
The finalization information is lost once the node is restarted.
Added Finalization delay
- Finalization delay is the minimum amount of time to wait between block header reception and the block finalization. This is added to check that the block to finalize is known for a long enough time. This will ensure that an attacker could not cause a block to finalize by forking the chain.
- The first auto-finalization will only start happening after finalization delay has expired since the node startup time.
Introduced 2x POW penalty and Parked Chain
Introduce a penalty to alternative chains based on the depth of the fork. This makes it harder for an attacker to do reorg before the next block finalization. The node implicitly parks the block if it causes deep reorg. If a block arrives that would trigger a reorg of 1 or more blocks, that block gets “parked”. Parking a block means that it is not considered as a candidate for the chain tip, but it is also not invalid, so peers don’t get banned for sending you parked blocks or blocks which build on parked blocks.
When a block arrives that builds upon a parked block, the total PoW for that chain is checked. If the parked chain’s added PoW exceeds a certain threshold, that parked chain is unparked and it becomes the new chain tip. The threshold depends on the reorg depth:
- The chain tip’s added PoW for the depth of 1 block
- The chain tip’s added PoW plus 0.5 blocks for the depth of 2 blocks
- The chain tip’s added PoW plus 1.0 blocks for the depth of 3 blocks
- 2x as much added PoW as the chain time for depth of 4 or more