聯盟鏈專案失敗，多半不是技術選錯，而是治理沒想清楚。台灣中小企業近幾年被供應鏈溯源、碳權、票據數位化這類題目吸引，想導入聯盟鏈；但真正卡關的地方，通常在鏈下——誰有權寫入、資料錯了怎麼修、節點斷線誰負責。
這篇整理五個我們在報價前一定會請客戶回答的問題。如果這五題答不出來，通常代表現在還不到寫智能合約的時候。
上線前必須先想清楚的五件事
一、誰是節點營運方，出事誰扛？ 聯盟鏈的價值來自「多方共同見證」，所以節點不能只有你一家跑。要找上下游、公協會、或第三方公正單位共同維運。這裡的關鍵不是技術，而是合約：SLA、故障排除責任、硬體升級費用怎麼分攤，都要在專案啟動前談好。
二、鏈上放什麼，鏈下放什麼？ 把整份合約、整張發票塞上鏈是新手最常見的錯。合理做法是：鏈上只放雜湊值與必要索引，原始檔留在各方自己的資料庫或 IPFS。這樣既保有不可竄改的稽核性，又不會讓敏感資料公開給所有節點。
三、資料錯了怎麼辦？ 區塊鏈不可竄改，但現實世界的資料經常需要更正——打錯的品號、輸錯的數量。設計時要預留「補償交易」的機制：不是刪除錯誤紀錄，而是新增一筆更正紀錄並互相參照。智能合約要能表達「這筆已作廢，請參考 tx_xxx」這種語意。
四、爭議如何裁決？ 程式碼即法律（code is law）在企業場景幾乎行不通。當兩方對鏈上狀態有爭議，你需要一個鏈下的仲裁流程：可能是公協會、可能是預先指定的第三方。這個流程要寫進商業合約，並且在智能合約中保留「凍結」或「管理員介入」的後門——當然，這個後門本身也要多方簽章才能觸發。
五、退場機制是什麼？ 如果聯盟解散、或某個成員退出，資料如何遷移？私鑰如何處理？這題常被跳過，但沒想清楚會讓成員不敢加入。
智能合約的安全底線
就算上述都想清楚，合約本身還是要守幾條原則。
第一，權限分層。不要用單一 owner 地址，改用多簽或角色權限（例如 OpenZeppelin 的 AccessControl）。金鑰遺失或內部人員異動時才不會整條鏈失控。
第二，可升級但要有煞車。用 Proxy pattern 保留升級能力，但升級動作要多簽 + timelock，避免單點作惡或誤操作。
第三，外部呼叫要防重入。凡是會呼叫其他合約或轉帳的函式，遵守 checks-effects-interactions 順序，或直接引用成熟的 ReentrancyGuard。
以下是一段示意骨架，不是可直接部署的程式碼：
// 示意：實際請搭配 OpenZeppelin 並經過稽核
contract SupplyChainRecord is AccessControl {
bytes32 public constant WRITER_ROLE = keccak256("WRITER");
struct Record {
bytes32 dataHash;
uint256 timestamp;
bytes32 supersedes; // 指向被作廢的紀錄
}
mapping(bytes32 => Record) public records;
function submit(bytes32 id, bytes32 dataHash, bytes32 supersedes)
external onlyRole(WRITER_ROLE)
{
records[id] = Record(dataHash, block.timestamp, supersedes);
}
}
重點不在這幾行寫得多漂亮，而在部署前有沒有第三方稽核、有沒有測試網跑過完整業務流程、有沒有想好升級路徑。
我們的觀察
區塊鏈在企業場景的成敗，八成決定在治理設計，兩成在技術實作。我們在報價時通常會建議客戶：先花時間把上面五個問題跟聯盟夥伴談完，再進工程階段。倒過來做的專案，最後往往變成一套昂貴的、只有一方在寫入的資料庫——那還不如用傳統系統。