Lightweight solution for Mysterium Network micropayments
I’d like to share research on micropayments solution which we on Mysterium team are currently building to meet needs of decentralised VPN, CDN or streaming solutions.
The ultimate goal of Mysterium Network is to become fully decentralized, peer to peer and anonymous by design. The nature of such networks is that parties (consumers and providers) are anonymous which leads to lack of trust of each other by default, such trust have to be provided by protocol and math.
Considering trustless nature of the network, and aiming to reduce any risk of loosing money or providing service without being rewarded, the consumer isn’t going to pay a large amount up-front and the service provider will unlikely offer their services without prepayment.
From this above mentioned scenario arises a need to split the service into chunks — provided in exchange for micropayments — meaning that each party risks only tiny amounts.
This would mean that a user will pay a node a couple of times a minute, sending a tiny amount of tokens in exchange for the bandwidth they are renting.
Blockchain payments are secure, censorship resistant, trustless and have open and permissionless API. Unfortunately they’re also relatively expensive and slow (ethereum transaction may cost up to dollar and took up to couple of hours to be included into block).
Situation with centralised payment solutions like PayPal or Stripe isn’t much better. Despite many legal limitations (not accessible in some countries, requires to have credit cards and pass KYC procedures even for getting small amounts) they are also quite expensive — PayPal charges $0.05 and 5%, Stripe charges about $0.25 and 2.9% of transaction value.
1tx/s * 60 sec * $0.05 = 3$ per hour for transaction fees! :(
Solving blockchain scalability problems
Scalability is a network’s ability to grow and handle more users. Blockchain networks can be slow and clogged up by all the transactions being processed.
While ethereum core team is working on main layer upgrade (Ethereum 2.0), many teams across the industry are working on Layer 2 solutions — independent networks or chains running “on top” of the original blockchain to avoid it becoming too crowded and slow.
The two most popular Layer 2 solutions being developed are Plasma and State Channels. Plasmas are more complex and suffer from issues related to their centralised operators, while State Channels are arguably more decentralised. State Channels also better serve our use case because they are P2P and scale well with micropayments. As the core foundation of the widely-used Lightning Network they are well tested and are simpler to implement.
He have analysed couple of solutions (see our whitepaper) on the market but unfortunately either they were not mature (in early development) either didn’t had some needed properties. The’re trying to solve much harder problem that we needed, but in same time, the price of flexibility is complexity and usability.
To be able to deliver user friendly, fast and easy to maintain payment solution we have researched own L2 protocol called “Accountant pattern” and will introduce additional actor in the network — Mysterium Accountant.
Our solution is based on state channels (somehow similar to Lightning Network, Raiden Network or Connext) but is simplified. It avoids routing and two-way payment channels complexity. In same time it provides high transaction throughput (thousands tx/sec), prevention against double spending and usability.
While working on protocol design we had to set our requirements and point places where we can cut complexity.
Setting requirements
- High throughput and scalability — the payment solution should be able to process as many transactions per second as there are active sessions between providers and consumers. We’re talking about thousands transactions per second.
- Support for MYST token — and ideally possibility to avoid using any other tokens.
- Secure — Anonymity, and the permissionless nature of decentralized systems, means we need additional layers of protection against bad actors. We need a system which enables identity registration, staking and punishment mechanisms.
- Decentralized — it should maintain at least a decent level of decentralization and should not be controlled by any single party.
- Low complexity — solution should have low level of complexity when it comes to implementing it, as well it have to be cheap to operate and maintain.
- Good user experience — The technical aspects do not necessarily make it successful. If users experience friction of any kind when making a payment, that platform will not be geared towards adoption. (e.g. consumers should be able to deposit funds using any popular crypto wallet, or directly from exchanges; payments should not slowdown starting using service).
Reducing complexity:
- Perishable product — because digital services such as video/audio streaming or VPN could be named as perishable (they’re selling traffic which if not used, is “gone” forever), small amounts can be lost/not paid (e.g. payment for couple or minutes of service).
- Uni-directional payments — all payments are made by consumers and received by providers. Never vice versa.
Technical intro into Mysterium payments solution
The main components of protocol are: uni-directional, hashed time-locked contract (HTLC) based state channels, identity registry, and new party in the network called “Mysterium Accountant”.
State Channels and Payment Promises
Instead of consumers constantly paying providers on-chain, consumers can make “promises” to providers, similar to IOUs. These payment promises later can be settled on-chain by adding them as parameters into transaction sent to state channel smart contract. Smart contract will verify them and send appropriate amount into receiving party.
Mysterium Accountant
Payments using payment promises over state channels are elegant and efficient. Unfortunately they require to maintain channels between each consumer/provider pair. This means a lot of deployed smart contracts. Additionally, to get paid, providers would need to do at least one settlement per consumer (which is expensive).
Alternatively there could be single top-up smart contract per consumer (see “2.2. Initially proposed payment solution” in our white paper).
This solved problem of having many smart-contracts and multiple top-ups. Unfortunately provider’s problem of doing settle transaction per consumer is still there. Additionally this approach would introduce potential double-spending possibilities.
To circumvent such issues we propose to introduce a new party into the network called the “Mysterium Accountant”. The Accountant will not have any authority over transactions themselves, but instead have an overview of and verify promised payments by consumers.
The Accountant has a record of each consumer’s actual balance and funds, as well as a record of all of the promises made. When providers decide they want to settle the account, the final tallied record is executed on the blockchain and sent as a single transaction.
Our network can be made secure and trustless by utilising these Accountants (we expect to have at least couple of accountants run by independent players) and two types of payment channels:
- Paying channels, from consumers to Accountant;
- Receiving channels, from Accountant to providers.
In this way, Mysterium Accountant plays a similar role as an intermediary or hub between consumers and providers.
As these micropayment channels transact in “promises” rather than on-chain payments, we significantly reduce the amount of transactions sent to the blockchain. The network can then handle much larger volumes of users and transactions, allowing our network to be fast and scalable.
To make sure we still honour decentralization, there can be multiple accountants existing in the network. In our case consumers and providers can refer to multiple, different accountants. A specific Accountant is chosen by consumers during VPN session establishment. All Accountants are non-custodial, meaning they never are able to steal funds stored in their smart-contracts. They’re just managing off-chain balances so they can’t steal or cooperate with consumers to cheat providers.
Step-by-step
To make our proposal even more clear, let’s explain all the steps will be done inside our payment protocol.
- Consumer top-up his channel smart contract address (deterministically calculated and provided by dVPN app in a form of QR code and plain text).
- Once in a selected period (e.g. each 20 seconds), consumer sends payment promises to provider for provided services.
- At any time (e.g. each 3rd promise) provider is going to exchange promise given by consumer into Accountant’s promise. Provider needs to keep only last such promise.
- Consumer can issue promises to multiple providers, but only last such promise (with biggest value) will be settled by provider. All settled coins will be transferred from consumer’s channel into accountant smart-contract.
- When provider is happy with amount of tokens promised to him, he can settle last Accountat’s promise and get coins into his wallet or exchange account.
The Registry
The last important component of this protocol is a registry where all identities — consumers, providers and accountants will be registered. Payment channels will be created between consumers, providers and accountants during their registration.
Differently than in Lightning Network (when channel is destroyed after each on-chain settlement / channel closing), our channels will be reused for multiple transactions, top-ups and settlements (funds withdrawals).
What does this mean for our node runners?
We’re currently working on implementation of this payment solution. After it will be up and running, all the payments in the network will be done using tokens. Also provider node runners will be get paid on minute bases (in comparison to weekly bonuses we’re doing right now) and will be able to withdraw to personal wallets their rewards at any time they like.
We will not have any limitation of type of wallets consumers and providers are using. Also VPN session establishment should be as easy and fast as it is now (without any lag caused by payments).
Between now and fully working solution we’re expecting couple of testing phases. About detailed plan and exact steps of introducing payments into the Network will be informed on Mysterium blog.
