雷電網(wǎng)絡(luò)

基于以太坊的快速數(shù)字資產(chǎn)交易

以太坊上網(wǎng)絡(luò)支付通道
Raiden 利用鏈下網(wǎng)絡(luò)狀態(tài)技術(shù)給以太坊上的數(shù)字資產(chǎn)帶來了許多nice的屬性：

• 1.可擴(kuò)展性: 它與參與者的數(shù)量呈線性關(guān)系（每秒可能有1,000,000+次轉(zhuǎn)帳)。
• 2.快速： 轉(zhuǎn)賬在一秒鐘的時間內(nèi)被確認(rèn)和確定。
• 3.匿名性：單次轉(zhuǎn)帳不會顯示在全局分布式帳本中。
• 4.互操作性： 以太坊上任何實現(xiàn)了標(biāo)準(zhǔn)代幣的接口的代幣都可以互相交易。
• 5.低額交易費： 交易費比區(qū)塊鏈上的交易費低7個數(shù)量級。
• 6.小額支付： 低交易費允許有效的轉(zhuǎn)移小額資金。
  技術(shù)點
  該技術(shù)類似于比特幣的閃電網(wǎng)絡(luò)。
  基本思想是： 所有的交易需要記載到區(qū)塊鏈上的共享賬本上（這是區(qū)塊鏈的瓶頸），而該技術(shù)是通過交易雙方私下簽名交易信息， 不需要全部上鏈。Raiden 使用一個p2p支付通道網(wǎng)絡(luò)，并在以太坊的區(qū)塊鏈上存一定的押金。Raiden 是以太坊上的一個擴(kuò)展應(yīng)用。Raiden 節(jié)點和以太坊的節(jié)點互相聯(lián)通工作，作為交易的基礎(chǔ)設(shè)施， 并用以太坊上的鏈來管理通道的存證信息。Raiden 提供了簡單的API, 使得DApps 非常容易實現(xiàn)。
  應(yīng)用
• 為內(nèi)容分發(fā)做小額計費：Paywalls,廣告和訂閱。
• 去中心化的M2M市場： 特別是在物聯(lián)網(wǎng)中， 微小的帶寬， 存儲， cpu占有率， 能量， 傳感器數(shù)據(jù)等可以交易。
• 沒有交集的代幣系統(tǒng)： 游戲代幣， 獎勵代幣， 私有貨幣。
• API 訪問： 對于即將來臨的M2M經(jīng)濟(jì)，每次API 訪問計費。
• 快速去中心話交易。
  與以太坊相輔相成
  Vitalik Buterin 說：“ 狀態(tài)通道是一種重要技術(shù)， 有可能大大提高許多區(qū)塊鏈應(yīng)用程序的可擴(kuò)展性和隱私性； 結(jié)合分片和其他隱私秘密保護(hù)技術(shù)， 他們是一個重要的組合，可以實現(xiàn)去中心化的許多屬性，而這些屬性是圈內(nèi)人和機構(gòu)所期望，也應(yīng)該實現(xiàn)的“

Raiden 1.0 詳解：
Raiden 1.0 通過合約的方式實現(xiàn)了token 的線下狀態(tài)通道支付。
Registry 合約是系統(tǒng)注冊合約，以太坊上的每一種代幣都可以一次注冊， 然后會產(chǎn)生一個基于該token的狀態(tài)通道管理合約。每個有該token的用戶都可以選擇一個搭檔建立一個狀態(tài)通道合約，通過設(shè)置押金（會在鏈上存證）實現(xiàn)線下通道支付，線下交易都是雙方各自簽名確認(rèn)即可， 撤出時， 再雙方提供證據(jù)， 鏈上交易存證。合約如下：

image

Raiden 的類介紹：

ASSET

• a. 沒有特殊規(guī)范來規(guī)定哪樣的資產(chǎn)。
• b.只要是上鏈的一個簡單合約地址就可以（如Toke address）。

RAIDENPROTOCOL

• a.節(jié)點間的傳輸層交互
• b.RaidenService 的網(wǎng)絡(luò)事件通知。

RAIDEN SERVICE

• a.鏈下運行。
• b.Raiden 的根類。
• c.暴露Raiden 與Raiden的接口。
• d.需要直接訪問本地的Blockchain節(jié)點。
• e.管理所有的鏈上鏈下交互路由。
• f.維護(hù)AssetManagers列表。
• g.每個維護(hù)的AssetManagers只負(fù)責(zé)一個資產(chǎn)。

ASSETMANAGER

• a.鏈下運行。
• b.完全由RaidenService實例擁有。
• c.與一個單一資產(chǎn)相關(guān)聯(lián)。
• d.與鏈上的ChannelManagerContract相關(guān)聯(lián)，負(fù)責(zé)同一個資產(chǎn)。
• e.在單一資產(chǎn)上維護(hù)一組到其他節(jié)點的通道。
• f.從鏈上的ChannelManagerContract獲取通道初始化列表。

CHANNELMANAGERCONTRACT

• a.鏈上運行。
• b.關(guān)聯(lián)實實在在的一種資產(chǎn)。
• c. 維護(hù)鏈上的NettingChannelContracts列表。

NETTINGCHANNELCONTRACT

• a.鏈上運行。
• b.和一種資產(chǎn)相關(guān)聯(lián)。
• c.知道同一通道的兩個參與方(鏈上 地址）
• d.持有雙方存款
• e.在鏈上執(zhí)行一個通道的結(jié)算。

TRANSFERMANAGER

• a.鏈下運行。
• b.負(fù)責(zé)處理TransferTasks，它們代表了脫機通道中雙方之間的單一轉(zhuǎn)移。
• c.在沒有直接目標(biāo)通道打開的情況下，會產(chǎn)生TransferTask 作為中介轉(zhuǎn)移。
• d.如果具有接收到的轉(zhuǎn)移目標(biāo)的通道打開，則可以啟動到目標(biāo)的轉(zhuǎn)移。

TRANSFERTASK(UML: TRANSFER_ACTIVITY, TRANSFER_STATE)

• a.鏈下運行。
• b.異步運行， 通過網(wǎng)絡(luò)事件觸發(fā)。
• c.和AssetManager, TransferManager 和RaidenService 相關(guān)聯(lián)。
• d. 和transfer完全相關(guān)聯(lián)。
• e.負(fù)責(zé)找到與之相關(guān)聯(lián)的傳輸路徑。
• i. 路徑是活躍的。
• ii.路徑有足夠的資金用于轉(zhuǎn)移。
• f.如果找不到路徑，則啟動CancelTransfer。

TRANSFER

• a.包含nonce, 資產(chǎn), 金額，參與方，locksroot[, secret]。
• b. nonce: 跟蹤消息序列的計數(shù)器。Transfers的nonce 在通道中更新, 參與方的nonce在參與方的本地鏡像中更新。
• c.是一個merkle樹的樹根。它記錄了他們的hashlocks的最精簡locked_ammounts。

LOCKEDTRANSFER

• a. 如果收款人知道hashlock的secret, 那么他就可以聲明locked_amount。 locked_amount不是余額的一部分，而是在locksroot中隱含。

CHANNEL

• a.鏈下運行。
• b.被本地或者伙伴節(jié)點初始化。
• c.在鏈上有一個相對應(yīng)的NettingChannelContract。
• d.在每個資產(chǎn)的對端節(jié)點中最多有一個通道。也就是說，（目前）最多兩個(不同的)節(jié)點可以為每個資產(chǎn)設(shè)置一個通道。
• e.和伙伴節(jié)點維護(hù)最終的交易賬本。
• f.執(zhí)行創(chuàng)造和取消transfers。
• g.維護(hù)LockedTransfers列表。
• h. 執(zhí)行LockedTransfers的聲明。
• i.更新自己和伙伴的賬目（接受或者發(fā)送）。

各模塊關(guān)系圖如下：

concept_relationships.png

核心步驟。

TRANSFERS IN A CHANNEL

• a.類型: Transfer, LockedTransfer (Parent class for): MediatedTransfer, CancelTransfer。
• b.Trasfers 接收到一個RaidenProtocol實例化的消息，并轉(zhuǎn)發(fā)給RaidenService,由TransferManager來真正的處理。
• c.TransferManager 從AssetManager中獲得相關(guān)聯(lián)的通道。
• d.任何通道可以追蹤Transfers和LockedTransfers。
• e.Transfers 可以通過通道發(fā)送給參與方的節(jié)點， 也可以注冊本地通道。因此，通道中的transfer既可以是用于發(fā)送的， 也可以是用于接收的。
• f.一旦接收到transfer, 由通道注冊。
• i.Transfer 接收者必須要有正確的nonce。這個nonce是當(dāng)每次接收到伙伴節(jié)點transfer而增加。這個nonce 在本地伙伴節(jié)點維護(hù)。參與雙方維護(hù)相同的增加。保證參與transfer雙方的序列一致性。
• ii.收到的transfer包含secret, 解鎖secret得到金額, 并相應(yīng)更新余額。
• iii.如果我們收到了LockerTransfer，LockedTransfer將被注冊。
• iiii.最后，自己的余額和合作伙伴的余額根據(jù)allowance（= transfer.balance - self.balance）進(jìn)行更新。如果轉(zhuǎn)讓包含secreted, 余額則根據(jù)步驟ii中觸發(fā)的聲明進(jìn)行。
• g.如果Transfer被發(fā)送， 則由Channel注冊：
• i.對于接收方，是對稱的。
• ii.我們不需要驗證lockroots是否正確。
• h.只有節(jié)點的當(dāng)前余額超過傳送的額度并且未達(dá)到到期的塊高度(后者僅與LockedTransfers相關(guān))，Transfers才能被初始化。

選擇多條Transfer的場景

正常的TRANSFER

A 通過B 轉(zhuǎn)帳給C：
A： 初始化secret
A： MediatedTransfer -> B
B：MediatedTransfer ->  C
C：secretRequest -> A (證明收到的transfer是有效的)
A：Secret -> C
C：Secret -> B

CANCELTRANSFER:

A： 初始化Secret
A： MediatedTransfer -> B
B： MediatedTransfer -> C(失?。?C 不能和D建立路經(jīng))
C：CancelTransfer -> B
B：MediatedTransfer -> C2
C2：MediatedTransfer -> D

TIMEOUTTRANSFER

A： 初始化Secret
B： MediatedTransfer -> B
B： MediatedTransfer -> C (失敗：沒有接收到C的ACK消息)
B: TransferTimeout -> A
決議：A不會透露secret，嘗試新的transfer，B禁止C