Blockchain micropayments in decentralised platforms
Jaro Šatkevič, firstname.lastname@example.org
Open and permissionless API
All transaction history have to be stored and synced among all network's full nodes
Each party have open channel to any other party
Alice can over promise = double spending problem
Payment via intermediaries
Alice -> Bob -> Carol -> Dave
How to ensure that Bob and Carol will resend payment?
Dave requests payments
(issues invoice by sending hashlock to Alice)
Alice sends locked tx to bob via opened channel
Bob resends locked tx to Carol and Carol to Dave
Dave reveals secret to Carol to unlock transaction
Carol reveals secret all way back to Alice
(final step of micropayment)
(all parties have to be on-line and have enough funds)
Problems of Lightning Network
- Channels cannot be created on-the-fly.
- Routing paths are much harder to find when values are considered.
- Users have to be online and use hot wallets.
- Hubs have to lock a lot of funds.
- Expensive to increase channel.
- Requires specialised software.
Lightweight solution for high throughput micropayments
Consumer to Provider
- Providers can aggregate promises
- Consumers can top-up via any wallet
- Settlement can be done at any moment
- Hermes is non-custodial party
settle multiple promises from many consumers via single on-chain tx
even from exchanges
can be each hour or once in a month
he can't stop a transaction or take users money
Request based communication with Hermes
Problems of payment channels
"Rich" hub problem
Accountant have to lock 40 own tokens
10 000 providers
200 000 locked tokens*
*1 token = 1 USD
Staking as way to insure incoming channel balance
Deposits 10 tokens stake
Consumer send promise
Accountant resend promise
Provider gets stake back
Ethereum will require ETH to pay for tx fees
Actual technical implementation
Payments go package
Hermes protocol - Lightweight solution for high throughput micropayments