基於以太坊的發展，微閃電是以太坊的第二層支付協議。它兼容ERC20/ERC223標準令牌接口，因此以太網車間部署的現有令牌可以直接與微閃電協議連接，無需遷移令牌數據。
MicroRaiden是壹個專門針對N-pair 1商店模式優化的支付渠道，具有以下功能:
鑒於以上特點和micro lightning的設計初衷，適合以下應用場景:
場景示例:接收方提供很多網絡資源(jpg、url、txt等。)，而且每種資源都可以設置單價。當用戶訪問資源時，通道自動創建，資源的價格自動從通道的押金中扣除。以後可以通過通道多次訪問該資源，每次訪問自動扣除相應的令牌。
MicroRaiden包括客戶端和服務器。客戶端是發送方，每個發送方對應壹個客戶端，服務器是接收方。
微閃電客戶端包括會話客戶端通道等多種數據結構，關系如下:
上圖正式生成。只要知道三個主要結構的主要功能:
客戶端的主要功能如下:
余額證明是指發送方簽署當前渠道的最新付費數據，證明發送方已經為購買的資源付費。這裏的平衡實際上是指在這個通道上花費的令牌數。
初始化客戶端時，需要將鏈上的通道信息同步到本地。同步過程如下:
這個接口可以作為獲取通道的唯壹入口，包括查詢已有通道和新建通道的接口調用封裝。
在鏈上實現與渠道相關的操作。
底線:令牌傳輸自動觸發通道的創建。
如果發送者希望與指定的接收者建立支付通道，並在該通道上存入10token，他只需將存款金額的token轉移到ChannelContract的合同地址。註意:所有地址的余額都保存在令牌合同中。這裏的地址不限於個人賬戶的地址，也可以是普通合同的地址。
創建支付通道由微閃電客戶端發起，流程如下:
對於ERC20標準令牌，處理流程如下:
需要兩個事務:批準和創建渠道。
充值類似於創建，除了數據數據變成:
同樣，與erc20兼容的過程如下:
需要兩個事務處理:批準和充值。
發送方和接收方都可以發起關閉通道的請求，但處理流程略有不同:
會話是客戶端的核心，通過它可以完成購買資源的操作。
Python的requests包是壹個優秀的http操作包，可以方便http交互，比如:
為了更方便在微閃電中使用，用get、options、head、post、put、patch、delete等請求接口進行了擴展和重新打包。
迅雷的客戶端中包含了擴展包，可以在http請求資源的同時進行令牌鏈下的支付操作。
例如，post接口:
其中url是請求的資源路徑；
最後由Session.request執行這個Session是對應每個發送方的壹個實例；
其中資源(_request_resource)將不斷地從服務器請求，直到結果返回或失敗。
上述請求資源的動作就是從接收方獲取資源並在通道中付費的過程。
流程如下:
4.2.3簽名算法是:將類型和名稱以字符串的形式組成壹個列表，執行keccak256，將數據組成壹個列表，再次執行keccak256。
4.2.4根據簽名數據和簽名結果恢復簽名人地址。
4.3如果驗證通過，且response.header中的SENDER_BALANCE與本地保存的發送方余額壹致，則說明服務器試圖將最後壹筆未確認支付偽裝成確認支付，未能返回。如果余額不壹致，說明服務器提供了不同的渠道余額證據，本地采用最新余額，本地更新余額和余額簽名。
4.4如果驗證失敗，並且服務器沒有提供信道余額的不同證據，則將本地余額更新為0。
4.5無論驗證是否通過，都需要進行以下支付操作。
在此渠道中更新發送方的余額和余額簽名。
後端服務提供付費資源管理和付費渠道管理。啟動前需要傳入以下參數:
啟動過程如下:
付費資源包括靜態資源和動態資源，添加方法如下:
為URI資源定義支持的http方法:
資源的價格是固定的。
添加資源:
資源可以通過/echofix/foo獲得，代理只有在支付5 token後才會將foo返回給用戶，如果沒有，則返回402 Payment Required。
定義URL資源:
domain參數指定獲取內容的遠程URL。