# Architectural Patterns for Blockchain Systems and Application Design
## 4 Pattern Description
### Transactional View Patterns
#### 4.3.4 Chain Fork Pattern  
**Summary:** This pattern addresses concerns regarding structuring on-chain data in conflict.  
**Context:** A software application utilizes blockchain services as a distributed ledger.  
**Solution:** To create a blockchain, the chain of blocks receives information from the blocks that preceded them. The block relationship can be viewed as a parent-child relationship, where each parent block has one child. The hash of the parent block is included in the header of the child block. Blockchain participants must follow common rules to maintain the history of the blockchain. When the participants are not in agreement or the rules are changed, alternative chains may emerge as chain forks. A chain fork occurs by splitting a chain of blocks into two paths. There are two main methods for such a split, as shown in Figure 10.  
The first occurs unintentionally at the consensus level when different blockchain participants disagree on the block validity. For example, when two blocks are mined simultaneously, they include the hash of their parent block and produce two different hashes for their blocks' data. This affects the validity of the chain. Therefore, only one block must be integrated into the chain. To decide which child block to include, the participants are allowed a temporary split with both conflicting child blocks. The miners then continue producing blocks based on each conflicting block. The conflicting block with the longest chain is then accepted. The other conflicting block becomes a stale/ommer block, and all its dependent blocks are discarded and returned to the pending transaction pool for validation to be included in the chain. The effect of a consensus-level chain fork on a blockchain application is that it affects referential integrity with transaction finality.  
The second occurs intentionally at the protocol level when the blockchain is upgraded or changes its rules. This change causes a permanent split in the chain. When a blockchain changes its rules, the existing chain is considered invalid in the new network. Thus, an alternative chain should be created according to the new rules. Therefore, the validator nodes must be upgraded to the new network. If some validator nodes insist on following the old rules, a permanent divergence version of the chain is created. One path follows the new version of the blockchain, and the other follows the old one. The effect of a protocol-level chain fork on a blockchain application is that the application may remain on the old chain or move completely to the forked chain, or it can be available on both chains.  
**Known uses:** Ethereum was forked into Ethereum Classic (old) and Ethereum (new) as a protocol-level split. Hive is forked from Steem as a protocol-level split. Dtube is a  
Figure 10: The chain fork pattern for blockchain applications.  
Steem-based video-sharing application that runs on both blockchains: Steem and its forked chain, Hive.  
**Related patterns:** The forked chain is a chain of blocks synchronized between the network participants as a replicated repository pattern.