Based on the development of Ethereum, micro lightning is the second payment protocol of Ethereum. It is compatible with ERC20/ERC223 standard token interface, so the existing tokens deployed in the Ethernet workshop can be directly connected with the micro lightning protocol without migrating token data.
MicroRaiden is a payment channel specially optimized for N-pair 1 store mode, with the following functions:
In view of the above characteristics and the original design intention of micro lightning, it is suitable for the following application scenarios:
Scenario example: the receiver provides many network resources (jpg, url, txt, etc. ), and the unit price can be set for each resource. When a user accesses a resource, the channel is automatically created, and the price of the resource is automatically deducted from the deposit of the channel. In the future, you can access the resource many times through the channel, and the corresponding token will be deducted automatically for each visit.
MicroRaiden includes a client and a server. The client is the sender, each sender corresponds to a client, and the server is the receiver.
The micro lightning client includes various data structures such as session client channel, and the relationship is as follows:
The above picture is officially generated. As long as you know the main functions of the three main structures:
The main functions of the client are as follows:
Balance certificate means that the sender signs the latest payment data of the current channel to prove that the sender has paid for the purchased resources. Balance here actually refers to the number of tokens spent on this channel.
When initializing the client, the channel information on the chain needs to be synchronized locally. The synchronization process is as follows:
This interface can be used as the only entrance to obtain channels, including interface call encapsulation for querying existing channels and new channels.
Implement channel-related operations on the chain.
Bottom line: Token transmission automatically triggers the creation of a channel.
If the sender wants to establish a payment channel with the designated receiver and deposit 10token on the channel, he only needs to transfer the token of the deposit amount to the contract address of ChannelContract. Note: The balance of all addresses is kept in the token contract. The address here is not limited to the address of an individual account, but also the address of an ordinary contract.
Creating a payment channel is initiated by the micro lightning client, and the process is as follows:
For ERC20 standard token, the processing flow is as follows:
Two transactions are required: approval and channel creation.
Recharge is similar to create, except that data data becomes:
Similarly, the process of compatibility with erc20 is as follows:
Two transactions are required: approval and recharge.
Both the sender and the receiver can initiate a request to close the channel, but the processing flow is slightly different:
Session is the core of the client, through which you can complete the operation of purchasing resources.
Python's requests package is an excellent http operation package, which can facilitate http interaction, such as:
In order to be more convenient to use in micro lightning, the request interfaces such as get, options, head, post, put, patch and delete are extended and repackaged.
Xunlei's client includes an expansion package, which can make payment under the token chain while requesting resources by http.
For example, post interface:
Where url is the requested resource path;
Finally, it is executed by Session.request. This Session is an instance corresponding to each sender.
Wherein the resource (_request_resource) will be continuously requested from the server until the result returns or fails.
The above-mentioned action of requesting resources is the process of obtaining resources from the receiver and paying in the channel.
The process is as follows:
4.2.3 Signature algorithm is: form a list of types and names in the form of strings, execute keccak256, form a list of data, and execute keccak256 again.
4.2.4 Restore the signer's address according to the signature data and results.
4.3 If the verification is successful and the SENDER_BALANCE in the response.header is consistent with the sender balance saved locally, it means that the server tried to disguise the last unconfirmed payment as a confirmed payment and failed to return. If the balance is inconsistent, it means that the server has provided different evidence of channel balance, and the latest balance is used locally, and the balance and balance signature are updated locally.
4.4 If the verification fails and the server does not provide different evidence of the channel balance, the local balance will be updated to 0.
4.5 Whether the verification is passed or not, the following payment operations are required.
Update the sender's balance and balance signature in this channel.
Back-end services provide paid resource management and paid channel management. The following parameters need to be passed in before starting:
The startup process is as follows:
Paid resources include static resources and dynamic resources, and the adding method is as follows:
Define supported http methods for URI resources:
The price of resources is fixed.
Add resources:
Resources can be obtained through /echofix/foo, and the agent will return foo to the user only after paying 5 token, otherwise, it will return 402 Payment Required.
Define URL resources:
The domain parameter specifies the remote URL to get the content.