swarms/ideas/095-les-service-model/micropayment.md

113 lines
3.4 KiB
Markdown

## Micropayment
### Existing Solutions
#### Raiden
##### Concept
- Off-chain solution for ERC20-compliant token transfers on Ethereum
- Designed for many-to-many solutions
- Transfer of tokens without global consensus
- Previously setup on-chain deposits and *balance proofs*
- Payment channels for bidirectional transfers between two participants as long as deposit isn't exceeded
- Transfers require no fees
- Funds can be added to existing channels
- Blockchain isn't involved during transfers, only for channel creation and potential closing
- As binding as on-chain due to smart contract containing tokens only accessable to both participants
- Closing leads to payments to both participants based on balance
- *Network* of channels with routing allow transfers between all peers, secured by *hash-locks*
- Scaling with the number of peers
- RESTful API
##### Links
- https://raiden.network/
- http://raiden-network.readthedocs.io/en/stable/
- https://medium.com/@raiden_network/
#### µRaiden
##### Concept
- Like Raiden but only between two parties: *sender* (client) and *receiver* (service provider)
- Designed for many-to-one solutions
- Creation of channel and settling leads to µRaiden Smart Contract and a *deposit*
- Smart Contract enforces payment of deposit
- Signing payments with balance-proofs between sender and receiver allows off-chain transactions
- Once channel gets closed deposit is payed to receiver based on *balance proofs* and rest to sender
- Typically only two on-chain transactions for opening and closing
- If deposit of sender gets low it can increase it with an on-chain transaction
- Own ERC20 and ERC223 compliant token
- RESTful API
##### Links
- https://raiden.network/micro.html
- https://github.com/raiden-network/microraiden
- https://microraiden.readthedocs.io/en/docs-develop/
#### SWAP
##### Concept
- Swarm Accounting Protocol
- Generic *peerwise* accounting
- Long-term exchange of data chunks balanced by data chunks preferred
- Relies on reputation system
- Open for payment systems with issue and receive function
- Issue results in a 3rd party proveable promise of payment
- Issued *cheques* will be accumulated in *cheque book*
- Only last one will be cashed in
- Peer decides how often to cash in
- Transactions costs motivate to minimize their number
- Trust to peers grows with good behavior
- SWAP^2 provides API to set triggers for automatic payments
- SWAP^3 reduces transaction cost by debt swap
##### Links
- https://github.com/ethersphere/swarm/wiki/Swap
- https://github.com/ethersphere/swarm/wiki/Swap-demo-instructions
### API
#### Client
##### Query Conditions
Ask service provider about pricing and model (bandwidth, CPU, etc.).
##### Establish Business Contract
Establish a payed connection with an initial deposit.
##### Check Balance
Check balance of the deposit to increase fund early enough before
connection potentially is dropped.
##### Increase Fund
Increase fund to keep connection with higher quality level. If
fund is spent connection may not be dropped but changed into
free connection. That may be dropped later.
##### Close Contract
Close contract so that used deposit is spent service provide and
rest is refunded.
#### Service Provider
##### Book Token
Book a token based on provided service. If all tokens of deposit
are used with a booking then close contract.
##### Close Contract
Close contract to retrieve used deposit and transform connection
into a free connection.