English
28546
So far, most Ethereum projects requiring micropayments have focused on payment channels. Payment channels allow any number of transactions to be sent and require only two on-chain transactions:
One for initializing the payment channel
The other is used to close the channel and settle the total transaction amount
Between these two transactions, we can send any number of off-chain transactions. This is a huge improvement compared to regular on-chain transactions. Because services like online video and energy markets can charge ongoing fees for tiny amounts of their services.
Since two on-chain transactions are required, we cannot simply send 0.1 cents to someone for whom we have not yet established a channel, as the cost of channel initialization and settlement will be many times higher than the payment.
But what if we could send any amount of small amounts to any number of recipients, without having to initialize and settle the transaction?
Ethereum Probabilistic Micropayments can send any amount of payment to any number of recipients without requiring each recipient to initialize and settle transactions.
Sounds incredible, right? It's true - we always need at least one on-chain transaction to settle, but we can effectively receive payments without any on-chain transactions happening.
In the above description, please note the "every recipient" condition, which is a subtle but important difference. Ethereum probabilistic micropayments require each sender to perform an initial transaction and lock a certain number of tokens (which will later be used to send to any recipient). The recipient does not need to process each sender's payment. Let's look at an example to see how it works.
orchid protocol
At Orchid Labs, we are investigating how to eliminate surveillance and censorship from the internet through a new distributed overlay network. In an orchid network, bandwidth contributors (called node ) Share bandwidth with users accessing the network and forward traffic； Users continue to pay tokens to bandwidth contributors (automatic payment by the client).
A single Orchid node can serve thousands of other nodes, and users can use hundreds of nodes to connect different websites, and the transaction fees of establishing a payment channel between each node are prohibitively high (even using a channel network like Raiden Network).
Instead, we can use Ethereum probabilistic micropayments:
The sender can deposit the token (which can be Ethereum, ERC20 token or other equivalent) into an Ethereum smart contract shared by all senders, which is maintained for each sender. Pay the difference and Penalty Escrow。
The sender locally creates and signs a note, which is an encrypted data structure containing payment data such as recipient and total amount.
The sender does not need to publish any transaction on the Ethereum network and can simply send the ticket directly to the recipient.
The recipient verifies the note. If it is valid, then the recipient has cryptographic proof that they are receiving payment. Note that even if the ticket does not "win", the recipient still has conclusive proof that they received the money, because the randomness that determines whether the ticket "wins" is determined by both the sender and the receiver. In this way, neither party can single-handedly manipulate the outcome.
A valid ticket is a "win", in which case it can be obtained by publishing an on-chain Ethereum transaction.
The scheme is detailed (and somewhat formalized) in the Orchid Draft white paper, which discusses and draws on previous research on probabilistic micropayments and their applicability to blockchains.
While we can’t use this scheme for a single payment because the recipient has no way of ensuring that they will actually receive the payment, we can use it to cryptographically prove to the recipient that the note they received has the potential to yield a claimable payment.
Since we can gradually and accurately calculate the probability of winning, the winning amount, and the frequency of notes over time, we can reduce the difference (transaction balance) to a negligible level.
That is, as long as the service provided is continuous and granular enough that the difference in probabilities is negligible, then probabilistic payments are more efficient than payment channels.
Application scenarios of payment channels:
You are a video streamer who charges $1 per hour.
A new user connects to your service and looks at the cute kitten for exactly 10 seconds.
If a transaction can wait several blocks for confirmation, then a transaction without data currently costs $0.006. However, since we need to set up the channel before watching the online video (to avoid freeloaders), we may need faster confirmations, which will cost $0.026. Setting up a payment channel will cost more money because it requires smart contract execution. As a rough estimate, the price will be twice that, or $0.052.
In this case, the payment channel overhead is several times what you as the host charge your users. If the user ends up watching a lot, then the expense may be justified, but for new or sporadic users, it can cause some controversy.
Application scenarios of probabilistic payment:
You are an online video host who charges $1 per hour.
A new user connects to your service and looks at the cute kitten for exactly 10 seconds.
Every 4 seconds, the user will send you an off-chain ticket with a winning rate of 1/2500 and a winning amount of $2.78.
If you don't receive a payment ticket every 4 seconds (given more time to account for network latency), you can simply disconnect from the viewer.
If the viewer doesn't receive any video inflow, they immediately stop sending payment notes.
When you receive a winning ticket, you use an on-chain transaction to obtain it, which transfers the winning amount to you from the sender's locked token.
Even if the ticket doesn't win, you still have cryptographic proof that you were the one to collect the payment. Because neither the sender nor the receiver can manipulate the winning amount of the ticket. With this proof, you'll be happy to keep showing videos to your audience. When thousands of (new) viewers connect to you, there is no overhead for any one viewer - the only overhead is when you capture the winning ticket.
For a specific "average total payment", the odds of winning (and the frequency of tickets) determine the number of on-chain transactions. Therefore, the higher the winning amount, the less transaction fees the recipient will pay over time. The lower the winning amount, the fewer tokens need to be locked by the sender, thus also reducing their liquidity costs.
For online videos, a reasonable winning amount would be $2.78. For power or energy markets, it might be $27.
Prevent double spending
A crucial part of probabilistic payments is ensuring that a double-spend does not occur, or that a double-spend would be unprofitable for the sender. The “penalty escrow” mentioned earlier prevents senders from profiting from double spending. The correct way to do this is that the sender must lock (submit) a certain number of times the ticket winning amount before they are able to create the ticket. Recipients can verify that the sender not only has sufficient funds to pay the winning ticket, but also that there is sufficient balance after their fine is held in escrow.
In the event of a double-spend, an on-chain claim for a winning note will result in a significant reduction in the sender's penalty escrow account after the sender's balance is insufficient to cover the note. This effectively incentivizes the small deposits senders are required to post, creating an economic incentive for senders to double-spend. The number of fine escrows should be set appropriately, which is enough to prevent double-spending from happening, but not causing too much inconvenience to the sender.
in conclusion
As far as the system is concerned, Ethereum probabilistic micropayments have several advantages over payment channels. It can provide users with continuous and granular services. The reduction in transaction fees provides the possibility not only for effective micropayments, but also for actual nanopayments.
Online video, power/energy markets, and bandwidth sharing are excellent examples of applicable systems. We don’t need to incur the setup cost of each sender-receiver pair, nor do we need to use a complex payment channel network, we only require that each receiver has an on-chain transaction. The service provider can immediately start serving the user without the risk of someone freeloading. ； And users can quickly disconnect once they stop receiving service.
This allows the service to completely avoid the cost of a free service, while also immediately preventing service attacks, since we can request, even the first request for, additional micropayment services.
PS. Thanks to David Salamon, who independently derived the probabilistic micropayment model during our research, before we realized that the concept of probabilistic micropayments dates back to 1996 literature. (Please refer to our white paper).
Original link:
https://medium.com/@gustav.simonsson/ethereum-probabilistic-micropayments-ae6e6cd85a06
Author: Gustav Simonsson
Translation & Proofreading: Junying & Elisa
