為什麼承諾交易中的每個 HTLC 都需要自己的簽名？
從BOLT 02我們可以學到
當一個節點對遠端送出有更改時，它可以應用它們，簽署生成的事務（如 BOLT #3 中所定義），並發送一條
commitment_signed消息。1. type: 132 (`commitment_signed`) 2. data: * [`channel_id`:`channel_id`] * [`signature`:`signature`] * [`u16`:`num_htlcs`] * [`num_htlcs*signature`:`htlc_signature`]為什麼整個承諾交易的簽名還不夠？我知道每個 HTLC 都有自己的
htlc_pubkey，因此也htlc_secret需要在 HTLC 成功交易中籤名，但這種設計背後的基本原理是什麼？
為什麼整個承諾交易的簽名還不夠？
因為該
htlc_signature欄位包含從承諾交易的 htlc 輸出（接收或提供）支出的HTLC 交易的簽名。為了擴展一點，HTLC 腳本的某些路徑（提供的htlc 輸出的超時和接收的 HTLC 輸出的成功）支付 2of2，因此您需要在送出之前簽署從該輸出中花費的正確交易（否則無法使用此腳本路徑）輸出。
編輯：這個問題源於這個Github 問題，Olaoluwa Osuntokun (@Roasbeef) 今天對閃電網路中為什麼使用第二階段 HTLC 進行了詳細的高級解釋。
以下是他的答案的複制粘貼，任何路過的人都可能感興趣。
這是我對高級解釋的嘗試：
我們在系統中使用稱為兩級 HTLC 的東西。這使我們能夠將 CLTV（HTLC 的絕對時間鎖）與 CSV（承諾延遲以允許違規報復）分離。要了解為什麼這是一個問題，請考慮我們是否在頂級 HTLC 腳本中同時擁有這兩個。從這裡，可以想像這樣一種情況，我們有一個可以超時的 HTLC（絕對塊高度已通過），但在我們的 CSV 週期也到期之前，我們不能使用它（超時）。因此，在設置它們的 CSV 值時，還需要考慮絕對時間鎖 (CLTV) 值。至關重要的是，在使用者取消傳入的鏈下 HTLC（使傳出的鏈上超時）之前，他們需要等待這個 CSV 週期。但是，如果 CSV 大於時間鎖定增量（傳入和傳出 HTLC 之間的差異），則它們'
如果沒有 HTLC，CLTV delta 值和 CSV 值之間的依賴關係意味著如果想要擁有更高的 CSV 值（更多時間來懲罰惡意通道對等方），那麼他們還需要有更長的 CLTV delta 值。例如，使用 lnd 的常見設置是，對於超高價值頻道，我們的 CSV 值為 2016 個區塊（兩週）。如果沒有二級 HTLC，我們還需要使 CTLV 增量值（預設 atm 為 40 個塊）大於 2016 個塊。然後，此更改將在整個網路中傳播，從而導致很長時間的鎖定值。HTLC 的發送者吃掉了全時鎖定延遲，這意味著知道他們的絕對最壞情況要高得多，以換取更好的多跳 HTLC 安全性。
值得慶幸的是，我們找到了解決方案：兩階段 HTLC。請注意，我上面描述的 HTLC 腳本從未實際部署過。出於類似的原因，原始 LN 白皮書中實際上使用了兩階段 HTLC。上述有缺陷的設計是在開發人員試圖稍微壓縮腳本和鏈上佔用空間時創建的。
兩級 HTLC 將 CSV 週期與一個 CTLV 時間鎖定增量分離。為此，我們現在要求強制關閉的一方通過特殊交易花費其 HTLC。該事務在腳本中花費了一個 CLTV 子句，並且它本身也包含一個 nLocktime 值。然後，此特殊交易的輸出支付給我們計時或贖回 HTLC 的一方，但隨後強制執行 CSV 週期。我們稱它們為兩個階段，因為我們在聲明中強制執行兩種狀態：等待絕對超時值，然後等待 CSV 值。請注意，一旦絕對超時值過去，該方可以花費原始 HTLC 輸出，將 HTLC 聲明狀態機轉換為 CSV 等待期。此時，他們可以安全地取消任何鏈下 HTLC，因為此時對方無法使用原像來解決它。
我們強制執行此支出的方式是，我們使來自一個人的承諾交易（您在強制關閉期間廣播）中的任何 HTLC 支出實際上成為一個多重簽名輸出。我們使用此輸出來創建本質上是“鏈下多重簽名契約”。由於他們需要我們的簽名來花費這個輸出，我們使用預簽名的交易強制他們進行特定類型的花費。因此，每次我們要給他們一個新的承諾時，除了承諾簽名（multi-sig consumption tehfunding output）之外，我們還發送一系列簽名，每個 HTLC 一個，以祝福他們的花費HTLC 輸出。