µRaiden is an off-chain, cheap, scalable and low-latency micropayment solution.
Current version: 0.1.0
. Verifiable with RaidenMicroTransferChannels.call().version()
.
Note that a new µRaiden release might include changing the Ethereum address used for the smart contract, in case we need to deploy an improved contract version.
The RaidenMicroTransferChannels
contract has been deployed on the main net: https://etherscan.io/address/0x4d6e0922e6b703f0fdf92745343a9b83eb656402
The following parameters were used:
token_address
:0x255aa6df07540cb5d3d297f0d0d4d84cb52bc8e6
challenge_period
:8640
(blocks, rough equivalent of 36 hours)
There have been internal and external audits of above contract. That being said: All contracts are WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Use at your own risk.
- CustomToken address is: 0x5a7f24e34adac43955de79c6be3a050e29d1f93e
- RaidenMicroTransferChannels address is: 0xe71269969cfd3c9c13c31c1caaf1ac4f242075ed
- CustomToken address is: 0xe3e546238cbadffb8d47b2a9b2a0205f0db6422c
- RaidenMicroTransferChannels address is: 0xe71269969cfd3c9c13c31c1caaf1ac4f242075ed
- CustomToken address is: 0x101e64900a7f283468ec7484691afca8385dc1d8
- RaidenMicroTransferChannels address is: 0x568a0d52a173f584d4a286a22b2a876911079e15
µRaiden is not part of the Raiden Network. However, it was built using the same state channel idea and implements it in a less general fashion focusing on the concrete application of micropayments for paywalled content.
The main differences between the Raiden Network and µRaiden are:
- µRaiden is a many-to-one unidirectional state channel protocol, while the Raiden Network is a many-to-many bidirectional solution and implies a more complex design of channel networks. This allows the Raiden Network to efficiently send transfers without being forced to pay for opening new channels with people who are already in the network.
- µRaiden off-chain transactions do not cost anything, as they are only exchanged between sender and receiver. The Raiden Network has a more complicated incentive-based off-chain transport of transaction information, from one user to another (following the channel network path used to connect the sender and the receiver).
µRaiden uses its own token for payments which is both ERC20 and ERC223 compliant.
In a nutshell, clients (subsequently called "senders") wanting to access a provider's payable resources, will open a micropayment channel with the provider ("receiver") and fund the channel with a number of tokens. These escrowed tokens will be kept by a third party contract that manages opening and closing of channels.
A visual description of the process can be found here.
However, the heart of the system lies in its sender -> receiver off-chain transactions. They offer a secure way to keep track of the last verified channel balance. The channel balance is calculated each time the sender pays for a resource. He is prompted to sign a so-called balance proof, i.e., a message that provably confirms the total amount of transfered tokens. This balance proof is then sent to the receiver's server. If the balance proof checks out after comparing it with the last received balance and verifying the sender's signature, the receiver replaces the old balance value with the new one.
A visual description of the process can be found here.
When a sender wants to close a channel, a final balance proof is prepared and sent to the receiver for a closing signature. In the happy case, the receiver signs and sends the balance proof and his signature to the smart contract managing the channels. The channel is promptly closed and the receiver debt is settled. If there are surplus tokens left, they are returned to the sender.
In the case of an uncooperative receiver (that refuses to provide his closing signature), a sender can send his balance proof to the contract and trigger a challenge period. The channel is marked as closed, but the receiver can still close and settle the debt if he wants. If the challenge period has passed and the channel has not been closed, the sender can call the contract's settle method to quickly settle the debt and remove the channel from the contract's memory.
What happens if the sender attempts to cheat and sends a balance proof with a smaller balance? The receiver server will notice the error and automatically send a request to the channel manager contract during the challenge period to close the channel with his latest stored balance proof.
There are incentives for having a collaborative channel closing. On-chain transaction gas cost is significantly smaller when the receiver sends a single transaction with the last balance proof and his signature, to settle the debt. Also, gas cost is acceptable when the sender sends the balance proof along with the receiver's closing signature. Worst case scenario is the receiver closing the channel during the challenge period. Therefore, trustworthy sender-receiver relations are stimulated.
Try out the µRaiden demo and build your own customized version, following our instructions below!
- install the Proxy component (more details here):
virtualenv -p python3 env
. env/bin/activate
git clone [email protected]:raiden-network/microraiden.git
cd microraiden/microraiden
pip install -r requirements-dev.txt
pip install -e .
- install the WebUI component for the paywall examples
Note that while the RaidenMicroTransferChannels
contract supports multiple open channels between a sender and a receiver, the WebUI component only supports one.
cd microraiden/microraiden/webui/microraiden
npm i && npm run build
- run the Proxy component (more details here):
For an overview of parameters and default options check https://github.com/raiden-network/microraiden/blob/master/microraiden/microraiden/click_helpers.py
For chain and contract settings change: https://github.com/raiden-network/microraiden/blob/master/microraiden/microraiden/config.py This is where you integrate custom contract & token deployments.
cd microraiden
python -m microraiden.examples.demo_proxy --private-key <private_key_file> start
- Go to the paywalled resource pages:
You can use the configuration for the above default example for creating your own payment channel service.
- µRaiden Paywall Tutorial:
- Proxy: /docs/proxy-tutorial.md
- Web Interface: soon
- Various paywall examples
- Components Overview: /docs/dev_overview.md
- µRaiden Service Setup: /microraiden/README.md
- Smart Contracts Setup: /contracts/README.md
- JS/TS client library: NPM package README.md