近日，Babylon 在 Testnet-4 上推出了比特幣質押活動，引發社區對於比特幣質押的討論。今天，Chakra 研究團隊將帶領您瞭解最新的比特幣質押方案。

在 Babylon 最近的 Testnet-4 中，質押過程被分爲三種類型的交易：質押交易（Staking Tx）、解綁交易（Unbonding Tx）和懲罰交易（Slashing Tx）。這些交易分別生成三種類型的比特幣輸出：質押輸出（Staking Output）、解綁輸出（Unbonding Output）和懲罰輸出（Slashing Output）。轉換過程如下圖所示。

質押交易

質押交易必須包括兩個特殊的輸出。一個是持有質押資產的 Taproot 輸出，必須包含巴比倫定義的 BTC 質押腳本。另一個是零金額輸出，該輸出通過 OP_RETURN 保存巴比倫質押可識別的信息。

下圖顯示了一個質押交易的示例，其中第一個輸出是質押輸出，第二個是 OP_RETURN 輸出，第三個是找零輸出。

質押輸出

質押輸出是一個 Taproot 輸出，正如Chakra之前寫過的文章所提到：

Taproot 輸出有兩種支付方式，分別爲密鑰支付路徑和腳本支付路徑。巴比倫通過將內部密鑰設置爲“Nothing Up My Sleeve” (NUMS)點，禁用了密鑰支付路徑，使得質押輸出只能通過腳本支付路徑進行支付。

質押輸出可以通過三條腳本路徑花費，對應於過程圖：

1、時間鎖路徑

時間鎖路徑實現了質押功能，同時也作爲活性保證。

<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY

時間鎖腳本將質押者的 BTC 鎖定一定的區塊數量。定時鎖路徑不需要其他實體，因此爲質押者提供了活躍性保證。即使最終性提供者和契約委員會變得不活躍，質押者在鎖定期過後仍然可以取回他們的 BTC 資產。

2、解綁路徑

如果 BTC 被時間鎖鎖定，用戶如何提前結束質押？巴比倫通過引入解綁路徑來解決這個問題。

<StakerPk> OP_CHECKSIGVERIFY <CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD <CovenantThreshold> OP_GREATERTHANOREQUAL

這條路徑不僅需要質押者的簽名，還需要來自契約委員會超過

CovenantThreshold

數量成員的簽名。引入契約委員會的主要原因是人爲地創建一個解綁期，防止質押者通過解綁路徑逃避懲罰。

3、懲罰路徑

爲了確保 PoS 的安全，懲罰是必要的。如果最終性提供者行爲惡意，就有必要沒收其自有及委託資金以提供經濟安全。巴比倫通過引入懲罰路徑提供了懲罰功能。

<StakerPk> OP_CHECKSIGVERIFY <FinalityProviderPk> OP_CHECKSIGVERIFY <CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD <CovenantThreshold> OP_GREATERTHANOREQUAL

在質押狀態轉爲 Active 前，質押者必須預先簽署懲罰路徑交易，以防他們在最終性提供者行爲惡意時扣留簽名以避免 BTC 損失。在收到質押者的簽名後，契約委員會首先驗證簽名，一旦確認有效，將釋放他們自己的簽名。

BTC 質押中的可懲罰行爲是最終性提供者在同一高度上籤署兩個衝突的區塊，此時任何用戶都可以通過 EOTS 獲得惡意最終性提供者的私鑰。由於質押者和契約已經預先簽署了懲罰交易，獲得惡意最終性提供者私鑰的用戶可以簽署交易，通過懲罰路徑將部分質押資金髮送到燃燒地址作爲處罰。

OP_RETURN 輸出

雖然 Taproot 輸出以較小的 ScriptPubKeys 表達複雜的使用條件，但這也使得在比特幣網絡中區分質押交易和其他交易具有挑戰性。因此，有必要通過其他方式披露與質押相關的信息，以便用戶可以根據這些信息識別懲罰交易。

巴比倫序列化需要披露的信息，將信息嵌入 OP_RETURN 腳本中，並附加在質押交易的另一個輸出中。格式如下圖所示，數據必須與 Taproot 腳本中的數據相對應。

type V0OpReturnData struct { MagicBytes []byte Version byte StakerPublicKey []byte FinalityProviderPublicKey []byte StakingTime []byte }

根據以前的交易快照，OP_RETURN 輸出攜帶的有效數據確實總共爲 4+1+32+32+2=71 字節。在圖中，質押交易的 FinalityProviderPublicKey 爲 f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81，屬於 Chakra。

MagicBytes 用於快速定位質押交易，而 Version 是爲未來更新保留的字段，以便區分。

根據以前的交易快照，OP_RETURN 輸出攜帶的有效數據確實總共爲

4+1+32+32+2=71 Bytes

字節。在圖中，質押交易的 FinalityProviderPublicKey爲 f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81，屬於 Chakra。

MagicBytes

用於快速定位質押交易，而 Version是爲未來更新保留的字段，以便區分。

解綁交易

當質押者想要提前解鎖其質押的 BTC 時，他們可以通過在質押輸出中花費解綁路徑，提交解綁交易。解綁交易要求它只接受單個質押交易作爲輸入，並輸出單個承諾到解綁腳本的 Taproot 輸出。

下面是解綁交易的截圖，對應於之前的質押輸出。

其中，以 ’20’ 爲開頭的倒數第二段字段爲解綁路徑的 tapscript，以 ‘c1’ 爲開頭的則是 Taproot 內部密鑰與解綁路徑的 Merkle Proof，其中可以很明顯的觀察到 NUMS point

0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0

。在解綁交易的 Witness 字段中，我們可以觀察到質押者的簽名與契約委員會的簽名。

解綁輸出可以在兩種條件下花費：定時鎖路徑和懲罰路徑，這兩者與質押輸出中的路徑相同。在更高層面上，解綁輸出是一箇中間狀態，旨在防止質押者立即撤回他們的股份並逃避懲罰，最終導致提款交易的穩定狀態。

懲罰交易

懲罰交易以一個質押交易或解綁交易爲輸入，通過 Taproot 腳本中的懲罰路徑花費，併產生兩個輸出。一個輸出將部分質押的 BTC 發送到一個燃燒地址，而另一個將剩餘的 BTC 返回給質押者。

更嚴格地說，巴比倫實施了對不當行爲的部分沒收，而不是一次性焚燒所有由質押者質押的 BTC。這種方法提供了更高的容錯率，並保護了質押者的利益。

懲罰交易只能在質押者、契約委員會和最終性提供者的聯合簽名下發生。因此，即使個別方被破壞，也不會導致整個質押系統的崩潰。懲罰交易充當威懾作用，經濟上阻止參與者惡意行爲。只要不當行爲的懲罰超過任何潛在收益，參與者就可能遵守規則。

安全分析

與巴比倫相關的安全有兩種類型：

第一種安全關乎質押者，確保只要質押者及其委託的最終性提供者不進行任何惡意行爲，他的質押資產就永遠不會被懲罰。

第二種安全涉及 PoS 系統本身，保證如果參與者行爲惡意，則協議必須能夠識別並懲罰他們。

質押者的視角

對於質押者來說，一旦通過巴比倫的質押交易質押了 BTC，資金只有三種轉移方式。

第一種是定時鎖路徑，只需要用戶自己的簽名即可支出。這確保了即使 FP 和巴比倫停止運營，質押者在質押期結束後仍然可以取回原始 BTC。

第二種是解綁路徑，作爲中間狀態，創建一個解綁輸出並允許更短的解鎖時間。這爲質押者提供了提前取回其質押資金的功能。

第三種是懲罰路徑，這是唯一可能損害質押者利益的路徑。如果外部人員試圖攻擊懲罰路徑，他們必須同時提供質押者的簽名、最終性提供者的簽名和超過門檻的契約委員會的簽名，這是極其困難的。即使契約委員會惡意，只要最終性提供者誠實，質押者的 BTC 就是安全的。

PoS System's Perspective

從 PoS 系統的角度來看，其安全來源於在最終性提供者惡意行爲時能夠懲罰他們的能力。

巴比倫採用 EOTS 機制，如果最終性提供者對一個區塊雙重簽名，任何用戶都可以從這兩個不同的簽名中提取最終性提供者的私鑰。這使他們能夠簽署並提交一個懲罰交易，部分懲罰對應於最終性提供者持有的所有投票權的 BTC。

這種懲罰措施阻止了最終性提供者的惡意行爲，從而使他們的激勵與爲與巴比倫連接的 PoS 共識服務提供最終性保持一致，確保了具有大量質押 TVL 的 PoS 系統的安全。

未來，Chakra 將繼續與巴比倫合作推出一系列質押活動，爲用戶提供多重收益，同時解決流動性和互操作性挑戰，釋放比特幣在所有加密生態系統中的巨大價值。