關於以太坊 "雷電網絡" 的思考

做者：林冠宏 / 指尖下的幽靈

掘金：juejin.im/user/587f0d…

博客：www.cnblogs.com/linguanh/

GitHub ： github.com/af913337456…

---

序

以太坊是我我的目前很看好的區塊鏈平臺。信仰之一。 ---LGH on 2019-3-28

PS：本人技術書籍：《區塊鏈以太坊DApp開發實戰》已經出版並能夠網購了

---

對以太坊稍微有些些深刻了解的人可能知道，目前它擁有的瓶頸點之一就是交易的完成速度略慢，即便在君士但丁堡版本發佈後，更新了的節點們，處理交易的速度依然不是很高。且每一筆交易伴隨着手續費。形象地，一筆交易要在以太坊上被打包成功並上鏈，它要通過下面的一些步驟：

如上圖所示，特別地，在整個過程當中，1' 和 5' 是所佔時間最多的，也是影響TPS的主要緣由。前者受限於共識算法，後者受限於P2P的分佈式網絡環境。

固然，交易速度慢，不只僅是以太坊所面臨的瓶頸，也是目前大部分著名公鏈所面臨的。這些問題在必定程度上致使了區塊鏈不能被普遍商用。在以太坊的分片擴容和卡斯帕PoS共識算法技術，它們被應用並落地以前，官方的解決手段能夠說是尚尚未。

最近我在寫好了一個本身的區塊鏈積分通證協議相關的項目白皮書時，感概在技術層面上，已經從用戶體驗的角度出發，充分地解決了大部分的問題，卻仍是受限於鏈上的積分兌換交易速度較慢。

區塊鏈的去中心化積分系統對比於中心化的積分系統，前者就不能在交易速度上接近或超事後者嗎？帶着這個問題，我與不一樣的區塊鏈技術朋友交流過想法，以及在互聯網上尋找過解決方案。

在不進行底層重構的前提下，我看到了一個相似於比特幣區塊鏈上所說起的閃電網絡，這麼一個‘鏈下交易，鏈上結算’的加速交易完成的方案，它就是：

雷電網絡

雷電網絡對應於以太坊，閃電網絡對應於比特幣。它的技術方案實例後簡述以下：

假設 A 和 B 要進行通證T的交易。

1. 在以太坊區塊鏈上建立一個與 T 通證相關聯的智能合約，且稱爲 T 的通道合約-- C。C 必須包含但不必定要限於下面的功能：

1 通道建立
2 通道關閉 (清算)
3 驗籤
複製代碼

2. 如今 A 要和 B 進行交易，首先，A 以交易的形式，將攜帶了雙方贊成創建通道的簽名信息數據，發到鏈上的C，調用鏈上 C 的通道建立方法，創建與 B 的通道，在創建通道的時候，會合約會執行一個通證抵押操做，抵押操做詳細描述見下文的懲罰機制。建立通道的緣由是要在鏈上先進行信息的保存，這樣在後面的通道關閉，清算各自所得的時候，纔有憑據。
3. 建立了通道後，A 轉 1 個 T 給 B。A 在應用本地使用私鑰簽名這筆交易，這筆交易明確地寫好了數值等參數。交易發給 B。或發送給中繼服務，由中繼服務進行第一步的驗籤再轉發給 B 客戶端。
4. B 在收到交易後，確認交易。隨後使用本身的私鑰簽名這筆交易。而後 B 保存這筆已經被雙重簽名了的交易到本身的客戶端本地，再發送回給 A，最後 A 也保存交易到本身的本地，一來一往，這算是一次完整的鏈下交易。要注意的是，這裏的每一次傳輸，交易雙方都是能夠驗籤對方信息的。以及，這條交易信息不須要發到區塊鏈上，只需 A 和 B 保留便可。
5. A 和 B 之間在鏈下的每一次雙方簽名的交易信息，都有一個序列號（Nonce），好比第一次是1，第二次是2，若是要結束通道，即發起清算（假如由A發起，固然B也能夠發起），那麼A能夠將最新的序列號，即MaxNonce對應的交易發送到智能合約，同時提供一個鎖定時間，合約驗籤經過後，併發出一個 Event。
6. 若是在鎖定時間到期前，B 提供了一個 Nonce 更大的清算交易，那麼說明 A 做弊（好比，A在倒數第二條信息時收到了B的1個以太幣，在最後一條信息發給B兩個以太幣，但A結束通道時，只提交倒數第二條信息），此時合約會懲罰A，懲罰手段有多種，好比有基於抵押機制的扣除抵押幣。若是到期時 B 沒有異議，合約根據最後這條信息的淨增減額計算雙方的最終餘額發還給雙方。

雷電網絡的懲罰機制，它的操做是要求在創建通道的時候，要求通道參與者，必需要抵押部分通證，好比鎖定以太，由通道合約地址暫爲保管。在通道關閉的時候，會歸還。對於在交易中出現做弊的一方，做爲懲罰，做弊方的通證將會被給到對方。這一操做意味着，交易雙方必需要有以太能夠被鎖，若是某一方沒有以太呢？這不免又會是另外一個用戶體驗的問題，甚至會影響到整個鏈下交易的可信任性。這也是要咱們借鑑了雷電網絡的思路後要解決的問題之一。

上面的簡單描述，明顯存在下面的細節問題：

1. 交易的付款方餘額不足時，鏈下交易如何保證付款方餘額是足夠的？

答：收款方，在每次通道建立前，接收到付款方的簽名交易時，能夠對付款方的鏈上資產進行一次檢查，餘額不足則拒籤。

2. 在鏈下的交易過程當中，若是出如今開始時付款方的餘額是充足的，而隨着後續的交易，最終付款超出了付款方實際的鏈上餘額，豈不是發生了錯誤交易？

答：是的，的確有這樣的狀況，它的解決方案和問題 1 是同樣的。固然，還能夠考慮利用上雷電網絡的抵押機制。

3. 在 A 和 B 的交易還沒清算以前。A 和 D 產生的新交易中所產生的餘額變化，交易對：（A和B）於（A和D）之間，如何感知各自的餘額變化，例如 A 做爲付款方在還沒超支鏈上餘額的時候，和B正常鏈下交易。但若是統計上了和D的交易中所產生的付出，就超支了。

答：解決這類問題，必需要依靠抵押機制。首先 A 和 D 會建立一個新的通道，會有新的抵押。每一次通道的建立，A 都會抵押部分通證在智能合約中。這樣的話，（A和B）或（A和D）它們之間以抵押值爲超支界限便可。付款方若是超出抵押值，那麼拒絕交易。

4. 不一樣 Nonce 對應的交易記錄，是怎樣關聯到上一個 Nonce 所對應交易記錄的？

答：每條交易的要記錄上一條交易中所發生的通證數量的增減量變化。閃電通道的是記錄餘額，雷電通道的是記錄淨增減，好比A原有9個幣，B有11個，A再發1個幣給B，閃電通道會記錄A還有8個，B有12個，但雷電通道會記錄A減小1個，B增長1個。

5. 對於小額通證持有量的雙方，是否適合使用雷電網絡這種鏈下交易模式？

答：不建議使用，但不影響使用。

6. 要是例子中的 B 用戶離線了，沒法在鎖定時間內接收到 A 發起的清算 Event 通知。會怎樣。

答：合約將會以 A 發的清算記錄，進行清算。B 存在虧損風險。

7. 鏈下交易是否變成了中心化？

答：不是，首先用戶的私鑰能夠本地保存便可。若是害怕交易記錄丟失，客戶端能夠提供和備份私鑰同樣的備份交易記錄的功能。不備份而丟了設備的，資產丟少。

8. 若是 A 備份了私鑰，沒備份交易記錄。而後丟了手機，交易記錄如何清算？

答：在 B 不感知的狀況下。能夠由 B 發起鏈上交易清算，考慮到懲罰機制，B 通常不會輕易去做弊。

雷電網絡 的其它技術點

• 通道複用。A --> B --> C --> D。
• 超時通道。打開有時間限制的通道。

綜上述雷電網絡的交易模式適用於：

• 含某通證數額值較高的交易雙方，小額交易使用。

對於鏈下通證對實物兌換的落地應用場景的應用改造

咱們必需要認可一個點就是：雷電網絡的確起到了加速交易的做用。

對於通證在鏈下對實物兌換的落地應用，還須要解決下面的一些問題：

1. 抵押機制的優化，讓 0 通證持有量的用戶也能參與進來。
2. 實物交易後的退貨 與 鏈上結算 的限制問題，以確保用戶不會在清算後，還發起退貨。
3. 通道創建 或 關閉時，用戶做爲發起方，必須含有 ETH 充當手續費的體驗問題。
4. 通證手續費抵扣機制的拓展。
5. ...

至此，雷電網絡 的完整實現應該是包含兩個核心部分的，即：鏈上智能合約 + 鏈下中繼服務端。若是想基於 雷電網絡的技術思想來一塊兒實現一個到必定時機開源的針對 合約通證在鏈下兌換實物 應用解決方案的項目。能夠申請加入咱們。

加入的說明與要求：

1. 在東西實現以前，不抱盈利之心。實現後，如有機會盈利，論貢獻獲利。
2. 參與開發時，無時間要求，無地域要求，純靠自覺。
3. 大約均分 Web與移動前端、後端、合約工程師和其它共 20 人。人滿則排隊。
4. 要對區塊鏈技術有熱衷之心。
5. 有過實際的區塊鏈相關應用的技術開發最佳，包含但不限於先後端。
6. 有經驗的後端開發請忽略第 3 條。
7. 加入後，若日漸厭煩無感 或 經久無任何建議性觀點或實操的。可自行離羣，於我亦如此。
8. 任何有實際貢獻者不管往後仍是否在項目團隊內，都會被列舉到貢獻列表中。

團隊現狀

現有來自一線技術互聯網公司的後端和安卓移動端開發人員。包含我在內，對於常見的區塊鏈常見的錢包、交易所、接口中繼和合約協議等應用都有豐富的開發經驗。

申請方式：

發郵件到: 913337456@qq.com ，郵件中必需要有我的的技術棧簡介。

項目設想線路圖

完