簡而言之：當網路的標準鏈發生變化，且先前被視為主鏈一部分的區塊被另一組區塊取代時，便會發生區塊鏈重組（reorg，即 reorganization 的縮寫）。這可能導致已確認的交易消失、交易順序改變，以及應用程式狀態變得不一致。 由於網路延遲和並行區塊生成，重組在大多數區塊鏈上屬自然現象，但深度重組也可能源於攻擊或軟體錯誤。對於任何開發依賴已確認區塊鏈資料的應用程式的開發者而言，理解重組至關重要，因為若未能將重組納入考量，可能會導致雙花漏洞、幽靈交易以及資料庫損毀。
簡單的解釋
不妨將區塊鏈想像成森林中的一條路徑，其中每一步都是一個區塊。在正常情況下，所有人都會沿著同一條路徑前進。但偶爾，會有兩位開拓者同時發現不同的路徑，此時在短暫的一段時間內，會同時存在兩條有效的路徑。網路最終會決定哪條路徑是正確的（通常是先延伸得更遠的那條），而所有人都會切換到那條路徑。任何原本沿著另一條路徑前進的人，都必須回頭並切換到正確的路徑上。
當這種切換發生時，便稱為「重組」。被棄用的路徑上的區塊將被丟棄，而勝出路徑上的區塊則成為標準鏈。原先位於被棄用區塊中的任何交易，可能出現在勝出鏈的區塊中，也可能不會。有些交易可能會同時出現在兩條路徑的相同位置；有些則可能只出現在其中一條路徑，而未出現在另一條；若與勝出鏈中的交易發生衝突，少數交易可能會被完全捨棄。
對大多數終端使用者而言，淺層重組（深度為一或兩個區塊）經常發生，且完全不會被察覺。 您的錢包可能會短暫顯示某筆交易已確認，隨後在幾秒鐘內又顯示為待處理狀態，直到該交易在新標準區塊中重新確認為止。您可能甚至不會察覺到這一點。但對於大規模處理區塊鏈資料的應用程式而言，即使僅發生一個區塊的重組，也意味著根據舊區塊已寫入資料庫的記錄現在已不正確，並需要進行修正。
組織重組是如何發生的
重組最常見的原因是網路的自然延遲。當兩個驗證者幾乎在同一時間（在同一時槽內或同一區塊高度）產生有效的區塊時，網路的不同部分可能會暫時採用不同的區塊。節點 A 可能先看到區塊 X 並將其視為標準區塊，而節點 B 則先看到區塊 Y。根據共識規則，這兩個區塊都是有效的，但最終只有一個能成為主鏈的一部分。
網路透過其分叉選擇規則來解決此歧義。在Ethereum 上，分叉選擇規則（LMD-GHOST）會選擇獲得最多驗證者認證的區塊鏈。在Bitcoin 上，則由最長的區塊鏈（累積的工作量證明最多）勝出。 無論採用何種具體規則，結果都是一樣的：其中一個分叉被採納為標準鏈，另一個則被棄用。原本跟隨被棄用分叉的節點會偵測到此切換，回滾孤立區塊，並改採勝出的鏈。
在像Bitcoin 這樣的「工作量證明」（Proof of Work）區塊鏈上，區塊重組（reorgs）相對常見，因為挖礦過程本質上具有隨機性。 兩名礦工可能在幾乎同一時間找到有效的區塊，從而形成暫時性的分叉，但此分叉通常會在一個或兩個區塊內得到解決。在Bitcoin 上，單區塊重組經常發生，且被視為網路運作的正常部分。在誠信運作的條件下，更深層的重組雖屬罕見，但若攻擊者控制了網路中相當大比例的算力（這正是 51% 攻擊的基礎），則此類重組便有可能發生。
在Ethereum 的權益證明（PoS）系統中，基於時槽的區塊生成模式能降低自然重組的發生頻率，因為每個時槽都有指定的提議者。然而，若提議者的區塊因網路延遲而遲到，且下一位提議者改以之前的規範區塊為基礎進行構建，仍可能發生重組。 當指定提議者未能產出區塊（即「錯過時槽」）時，若多名驗證者基於區塊鏈的不同視圖進行構建，亦可能形成短暫重組的條件。
重組的類型
淺層重組的深度為一至三個區塊，且在大多數區塊鏈上都會自然發生。這是分散式共識的正常結果，並會在數秒內自行解決。大多數應用程式可透過在將資料視為最終結果之前，額外等待幾個區塊的確認，來處理淺層重組。
深度重組的深度超過三個區塊，通常是某種異常狀況的徵兆：可能是蓄意攻擊、共識漏洞，或是重大的網路分割。主要區塊鏈上的深度重組屬於嚴重事件，因為它可能會逆轉用戶和應用程式原本已視為確認的交易。在安全性較低（哈希算力或質押價值較低）的小型區塊鏈上，深度重組較為常見，且曾被用來執行雙花攻擊。
51% 攻擊（或在某些 PoS 鏈上稱為 34% 攻擊）是指蓄意製造深度重組。擁有多數共識權力的攻擊者會開採或驗證一條與公共鏈不同的私有鏈，然後將其揭露給網路。由於攻擊者的鏈較長（或擁有更多認證），網路會將其採納為標準鏈，導致公共鏈的近期區塊成為孤塊。 這使攻擊者能夠在被棄用的鏈上撤銷交易，進而可能對先前已發送並確認的資金進行雙重支付。
對應用程式的影響
對於處理區塊鏈資料的應用程式而言，區塊重組（reorg）會帶來資料一致性的挑戰。如果您的應用程式會在交易記錄一出現在區塊中，便立即將其寫入資料庫，那麼區塊重組意味著其中部分記錄現在是基於已不存在的區塊。這些交易可能會依然出現在新的規範區塊中（只是位置不同或區塊編號不同），也可能完全遺失。
DeFi 應用程式特別容易受到攻擊。如果某個 DEX 聚合器將一筆交換交易顯示為已確認並更新了用戶的投資組合，但後續因重組（reorg）導致該筆交易從標準鏈中被移除，那麼投資組合的資料便會出現錯誤。如果某個跨鏈橋樑偵測到來源鏈上的存款，並在目標鏈上釋出資金，但後續因重組導致該筆存款被移除，那麼該跨鏈橋樑便會針對一筆已不存在的交易發放資金。這是針對跨鏈橋樑的主要攻擊向量之一。
索引器與資料管線必須偵測重組操作、識別哪些區塊已被捨棄、回滾從這些區塊衍生的任何記錄，並重新處理正確的規範區塊。若缺乏此邏輯，索引資料庫將累積來自孤立區塊的幽靈記錄，造成隨時間推移而日益加劇的不一致性，進而損壞下游的分析結果、餘額及交易紀錄。
如何應對組織重整
防範重組的最簡單方法，就是在確認資料已最終確定之前，暫不將其視為已確認。 在Ethereum 上，最終性會在兩個紀元（約 12-13 分鐘）後達成，此後若要回滾區塊，必須銷毀至少三分之一的質押 ETH。在Bitcoin 上，六次確認（約 60 分鐘）是經濟最終性的普遍接受標準。在Solana 上，單時槽最終性意味著已確認的交易在約 400 毫秒內即具實質最終性。
對於無法等待完全最終性（因為使用者期望獲得更快的回饋）的應用程式，最佳做法是在獲得足夠確認次數之前，將資料標示為「未確認」或「待處理」；並實作回滾邏輯，以妥善處理因重組（reorg）導致近期已確認交易被撤銷的情況。
資料管道應盡可能依照區塊最終確定順序來處理區塊。與其在區塊一出現在鏈尖時就立即導入（這有風險會處理到日後可能成為孤兒區塊的區塊），資料管道應先將近期區塊緩衝儲存，並僅在這些區塊達到安全的確認深度後才進行處理。對於無法接受緩衝處理的即時應用場景，資料管道必須包含明確的重組偵測與回滾機制。
「重組（reorg）」與「分叉（fork）」有什麼區別？
重組（Reorg）與分叉（Fork）雖有關聯，但並非同一回事。所謂分叉，是指區塊鏈分裂成兩條相互競爭的分支的任何時刻，這種情況可能是暫時的（同一高度存在兩個有效的區塊），也可能是永久的（透過協議升級產生新的區塊鏈）。 所謂的「重組」，特指在暫時性分叉解決後，節點放棄其中一條分支並切換至另一條分支時所發生的現象。換言之，暫時性分叉是原因，而重組則是支持了失敗分支的節點所面臨的後果。
面向 | 組織重整 | Fork |
|---|---|---|
定義 | 節點將標準區塊替換為競爭分支 | 鏈條分叉成兩條或更多條支鏈 |
觸發器 | 臨時分支會優先合併至另一個分支 | 並行區塊、程式錯誤，還是協定升級？ |
恆常性 | 始終是暫時的；其中一個分支會被捨棄 | 可以是暫時的，也可以是永久的 |
若要更深入了解各種分叉類型，請參閱「鏈分叉」的說明。重組（Reorgs）也與交易排序密切相關，因為當規範分支切換時，交易的順序可能會發生變化。
需要多少筆確認才能防止重組？
安全的確認次數取決於區塊鏈的共識機制設計，以及涉及的價值多少。確認次數越多，要逆轉您的交易就必須進行更深層的重新組織（reorg），這對攻擊者而言，成本將呈指數級上升。下表彙總了將資料視為最終結果的常見指引。
鏈 | 共同最終性門檻 | 約實際時間 |
|---|---|---|
Bitcoin | 6 則確認 | 約 60 分鐘 |
Ethereum | 2 個 epoch（已完成） | 約 12 至 13 分鐘 |
Solana | 單槽最終性 | 約 400 毫秒 |
規模較小的 PoW 鏈 |
等待區塊鏈的最終確定性是最強有力的保障，而規模較小或安全性較低的網路則需要更深的確認深度，因為它們的重新組織風險較高。可靠的基础設施在此也至關重要：請參閱為何節點可靠性對於確保一致且能察覺重新組織的資料至關重要。
區塊鏈的重組會是一種攻擊嗎？
大多數重組都無害，且會在一個或兩個區塊內解決，但經刻意策劃的深度重組則是一種攻擊。擁有足夠共識權力的攻擊者，可透過私下建構一條競爭鏈並將其釋出，藉此使近期區塊成為孤兒區塊，並逆轉看似已確認的交易——這正是雙花攻擊與 51% 攻擊背後的運作機制。 區塊重組也與利潤提取策略有所重疊，因此了解何謂 MEV並檢視常見的區塊鏈故障模式，有助於團隊設計出當區塊重組屬惡意而非自然發生時，能安全失敗的系統。
常見問題
區塊鏈的重組是正常現象嗎？
一至三個區塊的淺層重組是分散式共識的正常現象，且經常發生，特別是在工作量證明（PoW）鏈上。此類重組通常在數秒內即可解決，多數使用者甚至不會察覺。另一方面，深層重組則屬異常情況，往往預示著攻擊或程式錯誤。
在重新組織過程中，已確認的交易會消失嗎？
確實可能發生。孤兒區塊中的交易可能會以不同的位置重新出現在新的標準鏈上，也可能因與勝出分支產生衝突而被完全刪除。正因如此，應用程式應在獲得足夠的確認次數後，才將交易視為最終確定。
哪些區塊鏈的重組次數最多？
基於工作量證明（Proof of Work）的區塊鏈，以及算力較低或質押價值較小的網路，會更頻繁地發生重組。Bitcoin 偶爾會出現單區塊重組，而安全性較弱的區塊鏈則更容易遭受更深層次、且可能帶有惡意意圖的重組。
索引器如何處理重組？
具備重組感知能力的索引器會偵測到分叉，識別出哪些區塊已被捨棄，回滾從這些區塊衍生的所有紀錄，並重新處理新的規範區塊。若缺乏此邏輯，資料庫會累積幻影紀錄，隨著時間推移，這些紀錄將導致餘額與分析結果失真。
等待最終確定性能否避免重組問題？
是的。一旦區塊達到最終確定性，若不付出極高的經濟成本，便無法撤銷，因此與已最終確定的區塊相關的資料不會受到區塊重組的影響。其代價是延遲，這也是為何某些應用程式會顯示未確認的資料，同時將不可逆的操作保留給已最終確定的資料。
Quicknode 如何處理重組
Quicknode Streams 其核心架構中已內建重組處理機制。Streams 會依照最終性順序傳遞區塊鏈資料，這意味著區塊必須在網路中達到安全的確認深度後，才會被處理並傳送。當發生重組時，Streams 會自動偵測分叉，識別哪些已傳送的區塊不再符合規範，並向您的目的地發送修正資料包，以確保您的資料與區塊鏈的真實狀態保持一致。
這項內建的重組處理功能，消除了區塊鏈資料處理中最複雜的工程挑戰之一。您無需在處理流程中建置自訂的重組偵測、回滾邏輯及區塊對帳機制，只需配置一個 Stream，其餘工作便由「Quicknode 」負責處理。無論您正在建置索引器、分析平台或即時監控系統，Streams 都能確保目標位置的資料與標準鏈一致，即使在網路重組期間亦然。
Quicknode其核心 API亦支援查詢各受支援網路中的最新區塊與已確認區塊資料，讓您的應用程式能針對每種使用情境選擇合適的確認等級。對於希望獲得即時回饋的用戶，可顯示最新區塊；但凡涉及財務決策或不可逆操作的邏輯，則應以已確認的區塊資料為依據。
延伸閱讀
什麼是區塊鏈最終性？-Quicknode 術語表
Streams 入門指南 - Quicknode 文件
為何節點可靠性至關重要-Quicknode 術語表
Quicknode 核心 API
