Principle and design goals

Technology implementation

Consensus mechanism

Accounts and transactions

Off-chain transactions¶

A visual description of the process can be found here.

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 transferred 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.

Smart contract system

Smart Contract¶

To be exact, there is a third party involved in µRaiden:

• the Enforcing or Smart Contract part

This is the part where the trustless nature of the Ethereum blockchain comes into play. The contract acts as the intermediary, that locks up the initial deposit from the Sender and enforces a possible payout of the funds based on the signed balance proofs, that the Sender sent out to the Receiver without the use of a blockchain.

Once the Receiver has a balance proof, it’s easy for the Receiver to prove to the contract that the Sender owes him some tokens. With the balance proof, the contract now can reconstruct the public key of the Sender and knows with certainty that the Sender must have agreed to the updated balance.

This means that there are only 2 transactions that have to happen on the blockchain:

• the initial opening of the channel with the prepaid amount the sender eventually wants to spend during the channel’s lifetime
• the final closing of the channel, where the sender’s initial deposit is paid out to the receiver and sender, based on the agreed on off-chain balances

If the channel runs low on funds before it is closed, the sender can increase the transferable amount of the channel with a topup transaction on-chain.

After a channel is closed, it can’t be used anymore. If the business-relationship between the same sender and receiver should revive again, a new channel has to be opened.

µRaiden uses its own token for payments which is both ERC20 and ERC223 compliant.

Cryptography

Distributed storage protocol

Cross-chain and exchange technology

Special technology

Economic model and incentive

Governance mechanism

Applications

This section covers the documentation of the individual parts of our µRaiden framework. We deliver Python implementations for the payment-receiver side in general as well as for the payment-sender side in a M2M (Machine-to-Machine) or IoT (Internet-of-Things) setup. For user-facing web applications, we provide a JavaScript implementation to directly serve the payment-senders logic to the customer.