HOPR Basics: Probabilistic Payments
This is the eighth episode in our series covering the basics of HOPR. Links to previous episodes can be found at the end of the article.
Incentivizing a private mixnet like the HOPR network allows it to scale and reward node runners for the important work they do to provide online privacy. Blockchains allow these incentives to be awarded in a trustless and decentralized way, but it’s essential that blockchain integration doesn’t compromise the metadata privacy of the underlying mixnet.
As we saw last time, HOPR uses tickets and payment channels to reduce gas costs and introduce a delay between when data is relayed and when the relay reward is claimed. But this still results in a blockchain transaction linked to every data packet relayed. To break this link, HOPR uses probabilistic payments.
The Power of Probability
When you successfully relay data as a HOPR node runner, you receive a cryptographic ticket for your efforts.
Previous explanations in this series simplified tickets by treating them as equivalent to payments. But they actually function more like lottery tickets. Instead of each ticket having a guaranteed reward, a few tickets can be redeemed for a large reward while most are useless. This is the basis for probabilistic payments.
It might not seem desirable to introduce randomness to a payment system, but with the right probability settings and given enough time, this is equivalent to a system where each ticket can be redeemed for a reward, with the added benefit of reduced gas costs and a reduced metadata footprint.
Imagine that relaying one packet one hop through the HOPR network had a guaranteed reward of 1 HOPR. If you relayed 100 packets, you’d receive 100 tickets which could be redeemed for 100 HOPR. But this would require one hundred blockchain transactions, and one hundred gas payments, significantly cutting into the reward (and maybe even making it worthless on an expensive chain like Ethereum). Those 100 transactions are also 100 opportunities for an adversary to gain important information about the underlying message layer.
Now instead imagine that each ticket has a 1% chance of being redeemed for 100 HOPR, and a 99% chance of being worthless. The expected return on 100 tickets is still 100 HOPR, but this time only one redemption transaction is required. It’s the same reward, but just 1% of the gas
costs and 1% of the on-chain data.
Of course, once you add randomness reality will deviate from theory. Those 100 tickets might include several winners, or none at all. In the very short run this introduces a certain amount of volatility to the incentives. But because nodes are expected to process millions of packets a day, the odds of the rewards meaningfully deviating from the expected values quickly drops to 0.
These probabilities are just an example, and indeed can be tweaked in the protocol as demand and gas prices require. Reducing the probability of each ticket being a winner reduces the number of on-chain transactions but also increases the volatility of the rewards. But as long as the winning probability of each ticket multiplied by the ticket reward is the same, the payout is equivalent to the case where each ticket can be redeemed.
This allows HOPR to provide low-cost data transfers at high rewards even on busy chains with high gas fees.
Sebastian Bürgel,
HOPR Founder
Website: https://www.hoprnet.org
Twitter: https://twitter.com/hoprnet
Telegram: https://t.me/hoprnet
Discord: https://discord.gg/dEAWC4G
LinkedIn: https://www.linkedin.com/company/hoprnet
Forum: https://forum.hoprnet.org
Github: https://github.com/hoprnet
HOPR Basics Episodes:
Episode 1: What is HOPR?
Episode 2: What is Metadata?
Episode 3: Anonymous Routing
Episode 4: Mixnets
Episode 5: Incentives
Episode 6: Proof of Relay
Episode 7: Tickets and Payment Channels
Episode 8: Probabilistic Payments
Episode 9: Cover Traffic
Episode 10: Cover Traffic Nodes
Episode 11: Balancing Cover Traffic
Episode 12: Intro to the HOPR DAO
