作者: Christian Decker
翻譯: 阿劍
編者注：原文發布于 2018 年，
不到一年前，三支閃電網路實現團隊齊心協力想為閃電網路的協議棧提出一份共同的規范，現在，這份規范和他們做出的三個實現都已穩定、可用，所以我們該繼續上路了：要進一步提升協議的功能、加入新的特性、進一步簡化其結構，并修補其缺陷。
在閃電網路的起步中，最核心的創新之一便是允許雙方商量通道內新狀態并保證舊狀態無法上鏈結算的鏈下狀態更新機制。現在，我們驕傲地公開我們的最新研究論文：我們為 layer 2 協議提出了一種新的、更簡潔的狀態更新機制，命名為 “eltoo”。
eltoo 的工作原理
我們可以把鏈下協商理解成在一定數量的參與方之間達成合約，而結算則是將這份合約提交給法庭、由法庭來決定參與方的最終得益 —— 在我們的案例中，區塊鏈就扮演著法庭的角色，因為所有的更新都在鏈下發生，我們需要一種辦法來讓鏈上的法庭在做出最終決斷前聽取各方的主張，在某個參與方啟動合約結算程式之時，我們需要一種延遲結算時間的機制，以允許對手方可提出一個更新的狀態（抗辯）。法庭必須時刻等待著新狀態，直至最終時限到來，以自己所獲得的最新狀態完成結算，而令人驚訝的是，比特幣區塊鏈已經滿足為實現這種區塊鏈特制的 layer 2 協議所需的大多數要求了。
– 圖 1. eltoo 協議運行的一個例子，展示了可以通過把更新交易重新綁定到更早的一筆交易或直接就是啟動交易，來跳過中間的狀態。只有最后的一筆結算交易能夠上鏈，-
在 eltoo 協議中，每個狀態都是由一對交易來表示的：一筆更新交易（update transaction），使用合約的輸出（output）并創建一個新的輸出；一筆結算交易（settlement transaction），它使用更新交易的輸出并根據雙方一致的意見將資金分割給雙方，這些輸出都有一個腳本，允許雙方立即附加一筆新的更新交易，或者在超出一定的時間后附加一筆結算交易，如果參與方能在超時之前對一個更新達成一致，他們就會創建一筆新的更新交易，用掉此前的輸出，對相應的結算交易來說這也意味著多重支付（因為它們所用的是同樣的輸出），因此同步地作廢掉了相應的結算交易，
（譯者注：”輸出“ 是比特幣交易的一個概念。一個輸出就代表著一定數量的比特幣及其所有權狀態，）
循環往復地作廢舊的狀態并對新的狀態達成共識，構筑了由更新交易前后相接形成的一個鏈條，并且鏈條的末尾是一筆最新結算交易，不過，這也意味著它有一個重大缺陷：當我們想要結算時，就只能在區塊鏈上重放整個交易鏈條，到那時我們只能在鏈上重新執行整個協議，
而 eltoo 的關鍵創新就在于，我們可以跳過中間的更新交易，直接把最后一筆更新交易與合約的創建交易（狀態）連接起來，為了支持這種短路功能，我們提出了一種新的 SIGHASH 標簽，叫 SIGHASH_NOINPUT，它允許將一筆交易的輸入綁定為任何帶有匹配腳本的交易輸出。因為此前的更新交易的所有輸出腳本都與后來輸入腳本相匹配，我們可以將后來的更新交易綁定到任何一筆之前的更新交易，因此可以跳過任意數量的中間更新交易。我們的論文包含了這個協議的完整建構，包括如何構建腳本的細節。
增強閃電網路
我們在上文提議的更新機制，允許支付通道的一個端點不斷調整自己的余額，并為狀態附加更加高級的結構（比如 HLTC “哈希時間鎖合約”）。
閃電網路最早論文的主要貢獻就是這樣一種更新機制，所以我們是想用 eltoo 來替代閃電網路嗎？絕對不是！
– 圖 2. 閃電網路子協議示意圖 –
閃電網路規范早已不是單個協議的規范，而是一整套協議的規范，組成這套協議的每個子協議都有各自的功能，eltoo 的目標不是替代這個閃電網路技術棧，而是對原始的更新機制的嵌入式替代，并且跟協議棧的其它部分也保持了后向兼容性。
與閃電網路最初論文所提議的機制（我們稱為 “LN-penalty”，以懲罰為后盾的更新機制）相比，eltoo 有完全不同的權衡：LN-penalty 使用一套懲罰系統來約束參與方，eltoo 則只執行鏈下合約最后一個雙方都同意的狀態。這個差別對建立在 eltoo 之上的協議的適用性和安全性有重要的影響。
形成這種差別的部分原因是，在 eltoo 更新機制中，所有參與方共享同一組交易，而在 LN-penalty 中，為了對不同參與方的不良行為作出懲罰，必須讓不同參與方不對稱地持有不同的交易，這一變化消除了在閃電網路領域我們所謂的 “toxic information（垃圾資訊）”，有一些資訊只跟舊狀態相關，但如果不保存它們我就有可能丟錢，這就是所謂的垃圾資訊，不僅對手方行為不軌可能讓我蒙受損失，某個節點忘了中間某筆更新交易（例如，從一個備份中恢復時）也有可能使對手方有機可乘，而在 eltoo 中，這是不可能的，因為只有雙方都同意的狀態才能拿去結算（即，eltoo 是沒有懲罰的）。
參與者的數據管理也在新的范式下得到了簡化：他們不再需要無效的狀態保存哈希原像，也不再需要保存已經無效的 HTLC 腳本，因為過時狀態所對應的結算交易永遠無法提交給區塊鏈。唯一需要保存的就是最新一筆更新交易，以及對應的結算交易，以及可能從這筆結算交易中支出的 HTLC 腳本，進一步地，結算也被簡化了，只需要將最新的更新交易綁定到起步交易的輸出，并設置超時期在結算交易廣播前結束，
我們可以將更新交易的輸出與 SIGHASH_SINGLE 結合起來，以支持為結算時候的更新交易附加額外的輸入和輸出。雖然這看起來沒什么大不了的，但它讓結算時候的更新交易可以附加手續費，這樣我們就不必提前支付固定費用了。在當前的實現中，我們必須提前對承諾的上鏈費用達成一致（可能離最后結算還有好幾個月呢），這迫使我們不得不去預測手續費市場的波動；用戶可能會為了安全起見而多付許多。延遲了手續費的選擇，我們就不必提前預測手續費了，甚至可以在手續費不夠高時提高支付。
而且，得益于使用新的特性標簽，節點可以在連接到對等節點時明白表示自己支不支持這個新特性，eltoo 可以增量部署到今天的網路上，無需另起爐灶。
閃電網路以外
作為一個通用的 Layer 2 更新機制，eltoo 也可以用在閃電網路以外任意數量的系統中，舉個例子，它支持創建高達 7 方參與的鏈下多方合約，結合 Schnorr 簽名方案，甚至支持無數個參與方，
這樣的鏈下多方合約的例子之一是 Burchert 等人提出的通道工廠，這是一種擴展方案，支持使用一筆鏈上交易為任意數量的支付通道充入資金，而且可以動態地再平衡和協商而無需動用區塊鏈。
實現 eltoo 的道路
在實現 eltoo 之前，我們需要對比特幣做一個微小的改動：為簽名引入 SIGHASH_NOINPUT 標簽，這個功能在幾個月以前有關使用瞭望塔來保護閃電網路通道的討論中提出過，但未有正式的提議，正式的提議可以在 eltoo 論文中找到。
我們希望社區考慮一下我們的方案并參與我們的討論，我們希望大家能對使用 SIGHASH_NOINPUT 達成共識，使得它能被包含在比特幣腳本功能的軟分叉中。如此一來我們可以獲得更可靠和簡潔的閃電網路，并且這套新的更新機制也可以為其它應用所用，
