分叉（fork），或是分叉的威脅，似乎是加密貨幣領域的公認特徵。但分叉是什麼？為什麼分叉會有這麼大的影響？硬分叉與軟分叉的差異在哪？
“分叉”從程式設計術語來講，是一個開原始碼的修改。通常，分叉程式碼與原始程式碼類似，但經過重要的修改，兩個“叉”（prongs）和平共存。有時，分叉被用來測試過程，但在加密貨幣裡，它通常被用來實行基本面的更改，或使用與原有資產相似的（但不相等的）特徵來創造新資產。
並非所有分叉的發生都是刻意的。使用廣泛分散的開原始碼庫（open-source codebase），一旦當不是所有節點都能複製相同資訊時，分叉有可能意外地產生。然而，通常這些分叉都能被識別並解決，主要的加密貨幣分叉都源於對植入哪些特性所產生的意見分歧。
記住一點，這些分叉有著“共享的歷史”。每個鏈（舊的或新的）上在分叉之前的交易記錄都是完全相同的。
硬分叉
程式設計分叉主要有兩種型別：硬分叉與軟分叉。
硬分叉是對舊版本的無效協議進行更改。假如舊版本持續執行，它們最終將使用與新版本不同的協議與資料。這會導致嚴重的混淆與可能的錯誤。
在比特幣裡，需要硬分叉來更改像是區塊大小、解決加密難題的難度、新增額外資訊之限制等定義引數。任何對這些規則的更改，都可能造成區塊被新協議接受但被舊版本拒絕，並可能導致嚴重問題──甚至有可能造成資金的損失。
舉例來說，假如區塊的大小限制由 1 MB 增加到 4 MB，一個 2 MB 大小的區塊將能被執行新版本的節點所接受，但會被執行舊版本的節點所拒絕。
也就是說，2 MB 大小的區塊透過某一更新後節點的驗證並新增到區塊鏈中。假若下一個區塊是需要被執行舊版協議的節點所驗證的呢？該節點會試圖新增這個區塊，但它會偵測到最新的這個區塊並沒有透過驗證。因此，它將忽視該區塊，並將新驗證結果附加到前面一區塊。突然間，你有了兩個區塊鏈，其中一條同時含有舊與新版本協議的區塊，另一條僅包含舊版本協議的區塊。哪條鏈的增長較快取決於哪些節點可以獲得下一區塊的驗證，並且最終可能還會有額外的分裂。兩條（或更多的）鏈是可以無限平行增長的。
這是一個硬分叉，它可能是混亂的，也可能充滿著風險，因為在新區塊中花費的比特幣可能會再次花費在舊區塊裡（因為執行舊版本協議的商戶、錢包與使用者無法偵測到無效的新程式碼支出）。
唯一的解決方法是放棄其中一個分支轉而支援某一分支，這涉及一些礦工的損失（交易本身是不會丟失的，它們只會被重新分配）。或者，所有節點都需要在同時切換到較新的版本，而這在分散的、廣泛傳播的系統內是不容易達到的。
或者，比特幣會分裂，這已經發生了。（哈囉，比特幣現金）
軟分叉
軟分叉仍然可以與舊版本一同執行。
舉例來說，假如以限縮規則的方法更改協議，實現表層修改或新增不影響結構的功能，則舊版本的區塊將能接受新版本區塊。但反過來則行不通：新的、較為嚴格的版本將拒絕舊版本的區塊。
在區塊鏈中，理想狀態下，礦工發現它們的區塊被拒絕，就會自行升級。隨著越來越多礦工完成升級動作後，擁有主要新區塊協議的鏈會變得越來越長，會更加孤立舊版本的區塊，這又能讓更多礦工進行升級動作，並且系統會自動糾正。由於舊的和更新後的節點都接受新區塊，因此新版本的區塊協議最終將獲勝。
舉例來說，當社羣決定將區塊大小從現有的 1 MB 限制縮限到 0.5 MB。執行新版本區塊協議的節點將拒絕 1 MB 大小的區塊，並且會建構在前一個區塊上（如果它是使用新版本的程式碼進行挖礦），可能會導致暫時的分叉。
這是一個軟分叉，並且已經發生過好多次。最初，比特幣並沒有區塊小的限制，是透過軟分叉將 1 MB 的大小限制引入的，因為新規則比舊規則更為“嚴格”。而可以在不改變結構的情況下強化程式碼的 pay - to - script - hash 功能，也是透過軟分叉成功增加的。這型別的修正通常僅需要大部分的礦工進行升級，便可以讓該分叉變得更可行，也降低了破壞性。
軟分叉並不會帶來困擾硬分叉的雙花風險（double-spend risk），因為執行舊節點的商家與使用者將能同時讀取新舊版本的區塊協議。
