作者：林冠巨集 / 指尖下的幽靈
GitHub ： github.com/af913337456…
序
以太坊是我個人目前很看好的區塊鏈平臺。信仰之一。 ---LGH on 2019-3-28
對以太坊稍微有些些深入瞭解的人可能知道，目前它擁有的瓶頸點之一就是交易的完成速度略慢，即使在君士但丁堡版本釋出後，更新了的節點們，處理交易的速度依然不是很高。且每一筆交易伴隨著手續費。形象地，一筆交易要在以太坊上被打包成功並上鏈，它要經過下面的一些步驟：
如上圖所示，特別地，在整個過程中，1' 和 5' 是所佔時間最多的，也是影響TPS的主要原因。前者受限於共識演算法，後者受限於P2P的分散式網路環境。
當然，交易速度慢，不僅僅是以太坊所面臨的瓶頸，也是目前大部分著名公鏈所面臨的。這些問題在一定程度上導致了區塊鏈不能被廣泛商用。在以太坊的分片擴容和卡斯帕PoS共識演算法技術，它們被應用並落地之前，官方的解決手段可以說是尚還沒有。
最近我在寫好了一個自己的區塊鏈積分通證協議相關的專案白皮書時，感概在技術層面上，已經從使用者體驗的角度出發，充分地解決了大部分的問題，卻還是受限於鏈上的積分兌換交易速度較慢。
區塊鏈的去中心化積分系統對比於中心化的積分系統，前者就不能在交易速度上接近或超過後者嗎？帶著這個問題，我與不同的區塊鏈技術朋友交流過想法，以及在網際網路上尋找過解決方案。
在不進行底層重構的前提下，我看到了一個類似於比特幣區塊鏈上所提及的閃電網路，這麼一個‘鏈下交易，鏈上結算’的加速交易完成的方案，它就是：
雷電網路
雷電網路對應於以太坊，閃電網路對應於比特幣。它的技術方案例項後簡述如下：
假設 A 和 B 要進行通證T的交易。
- 在以太坊區塊鏈上建立一個與 T 通證相關聯的
智慧合約，且稱為T 的通道合約-- C。C 必須包含但不一定要限於下面的功能：
1 通道建立
2 通道關閉 (清算)
3 驗籤
複製程式碼- 現在 A 要和 B 進行交易，首先，A 以交易的形式，將攜帶了雙方同意建立通道的簽名資訊資料，發到鏈上的C，呼叫鏈上 C 的通道建立方法，建立與 B 的通道，在建立通道的時候，會合約會
執行一個通證抵押操作，抵押操作詳細描述見下文的懲罰機制。建立通道的原因是要在鏈上先進行資訊的儲存，這樣在後面的通道關閉，清算各自所得的時候，才有憑據。 - 建立了通道後，A 轉 1 個 T 給 B。A 在應用本地使用
私鑰簽名這筆交易，這筆交易明確地寫好了數值等引數。交易發給 B。或傳送給中繼服務，由中繼服務進行第一步的驗籤再轉發給 B 客戶端。 - B 在收到交易後，確認交易。隨後使用自己的
私鑰簽名這筆交易。然後 B 儲存這筆已經被雙重簽名了的交易到自己的客戶端本地，再傳送回給 A，最後 A 也儲存交易到自己的本地，一來一往，這算是一次完整的鏈下交易。要注意的是，這裡的每一次傳輸，交易雙方都是可以驗籤對方資訊的。以及，這條交易資訊不需要發到區塊鏈上，只需 A 和 B 保留即可。 - A 和 B 之間在鏈下的每一次雙方簽名的交易資訊，都有一個序列號（Nonce），比如第一次是1，第二次是2，如果要結束通道，即發起清算（假如由A發起，當然B也可以發起），那麼A可以將最新的序列號，即
MaxNonce對應的交易傳送到智慧合約，同時提供一個鎖定時間，合約驗籤通過後，併發出一個Event。 - 如果在鎖定時間到期前，B 提供了一個 Nonce 更大的清算交易，那麼說明 A 作弊（比如，A在倒數第二條資訊時收到了B的1個以太幣，在最後一條資訊發給B兩個以太幣，但A結束通道時，只提交倒數第二條資訊），此時合約會懲罰A，懲罰手段有多種，比如有基於抵押機制的扣除抵押幣。如果到期時 B 沒有異議，合約根據最後這條資訊的淨增減額計算雙方的最終餘額發還給雙方。
雷電網路的
懲罰機制，它的操作是要求在建立通道的時候，要求通道參與者，必須要抵押部分通證，比如鎖定以太，由通道合約地址暫為保管。在通道關閉的時候，會歸還。對於在交易中出現作弊的一方，作為懲罰，作弊方的通證將會被給到對方。這一操作意味著，交易雙方必須要有以太可以被鎖，如果某一方沒有以太呢？這難免又會是另一個使用者體驗的問題，甚至會影響到整個鏈下交易的可信任性。這也是要我們借鑑了雷電網路的思路後要解決的問題之一。
上面的簡單描述，明視訊記憶體在下面的細節問題：
- 交易的
付款方餘額不足時，鏈下交易如何保證付款方餘額是足夠的？
答：收款方，在每次通道建立前，接收到付款方的簽名交易時，可以對付款方的鏈上資產進行一次檢查，餘額不足則拒籤。
- 在鏈下的交易過程中，如果出現在開始時付款方的餘額是充足的，而隨著後續的交易，最終付款超出了付款方實際的鏈上餘額，豈不是發生了錯誤交易？
答：是的，的確有這樣的情況，它的解決方案和問題 1 是一樣的。當然，還可以考慮利用上雷電網路的抵押機制。
- 在 A 和 B 的交易還沒清算之前。A 和 D 產生的新交易中所產生的餘額變化，交易對：（A和B）於（A和D）之間，如何感知各自的餘額變化，例如 A 作為付款方在還沒超支鏈上餘額的時候，和B正常鏈下交易。但如果統計上了和D的交易中所產生的付出，就超支了。
答：解決這類問題，必須要依靠抵押機制。首先 A 和 D 會建立一個新的通道，會有新的抵押。每一次通道的建立，A 都會抵押部分通證在智慧合約中。這樣的話，（A和B）或（A和D）它們之間以抵押值為超支界限即可。付款方如果超出抵押值，那麼拒絕交易。
- 不同 Nonce 對應的交易記錄，是怎樣關聯到上一個 Nonce 所對應交易記錄的？
答：每條交易的要記錄上一條交易中所發生的通證數量的增減量變化。閃電通道的是記錄餘額，雷電通道的是記錄淨增減，比如A原有9個幣，B有11個，A再發1個幣給B，閃電通道會記錄A還有8個，B有12個，但雷電通道會記錄A減少1個，B增加1個。
- 對於小額通證持有量的雙方，是否適合使用
雷電網路這種鏈下交易模式？
答：不建議使用，但不影響使用。
- 要是例子中的 B 使用者離線了，無法在鎖定時間內接收到 A 發起的清算 Event 通知。會怎樣。
答：合約將會以 A 發的清算記錄，進行清算。B 存在虧損風險。
- 鏈下交易是否變成了中心化？
答：不是，首先使用者的私鑰可以本地儲存即可。如果懼怕交易記錄丟失，客戶端可以提供和備份私鑰一樣的備份交易記錄的功能。不備份而丟了裝置的，資產丟少。
- 如果 A 備份了私鑰，沒備份交易記錄。然後丟了手機，交易記錄如何清算？
答：在 B 不感知的情況下。可以由 B 發起鏈上交易清算，考慮到懲罰機制，B 一般不會輕易去作弊。
雷電網路 的其它技術點
- 通道複用。A --> B --> C --> D。
- 超時通道。開啟有時間限制的通道。
綜上述雷電網路的交易模式適用於：
- 含某通證數額值較高的交易雙方，小額交易使用。
對於鏈下通證對實物兌換的落地應用場景的應用改造
我們必須要承認一個點就是：雷電網路的確起到了加速交易的作用。
對於通證在鏈下對實物兌換的落地應用，還需要解決下面的一些問題：
- 抵押機制的優化，讓 0 通證持有量的使用者也能參與進來。
- 實物交易後的退貨 與 鏈上結算 的限制問題，以確保使用者不會在清算後，還發起退貨。
- 通道建立 或 關閉時，使用者作為發起方，必須含有 ETH 充當手續費的體驗問題。
- 通證手續費抵扣機制的擴充。
- ...
至此，雷電網路 的完整實現應該是包含兩個核心部分的，即：鏈上智慧合約 + 鏈下中繼服務端。如果想基於 雷電網路的技術思想來一起實現一個到一定時機開源的針對 合約通證在鏈下兌換實物 應用解決方案的專案。可以申請加入我們。
加入的說明與要求：
- 在東西實現之前，不抱盈利之心。實現後，若有機會盈利，論貢獻獲利。
- 參與開發時，無時間要求，無地域要求，純靠自覺。
- 大約均分 Web與移動前端、後端、合約工程師和其它共 20 人。人滿則排隊。
- 要對區塊鏈技術有熱衷之心。
- 有過實際的區塊鏈相關應用的技術開發最佳，包含但不限於前後端。
- 有經驗的後端開發請忽略第 3 條。
- 加入後，若日漸厭煩無感 或 經久無任何建議性觀點或實操的。可自行離群，於我亦如此。
- 任何有實際貢獻者無論日後還是否在專案團隊內，都會被列舉到貢獻列表中。
團隊現狀
現有來自一線技術網際網路公司的後端和安卓移動端開發人員。包含我在內，對於常見的區塊鏈常見的錢包、交易所、介面中繼和合約協議等應用都有豐富的開發經驗。
申請方式：
發郵件到: 913337456@qq.com ，郵件中必須要有個人的技術棧簡介。
專案設想線路圖
