Orchid protocol and micro-payment on blockchain

Shi Yan
6 min readDec 9, 2017

My friends recently got interested in censorship fighting systems based on blockchain, so we read about the orchid protocol. What interested me more, however, is the micro-payment ideas being explored by blockchain systems like orchid.

As we have all noticed, current generation blockchains suffer from scalability issues . A transaction, for example, needs to take several hours to settle. And this will only get worse, as transaction history accumulates and will become the burden that everyone will carry forever. This is a fundamental trade-off blockchain designers played in order to achieve decentralization. If we don’t do anything about it, it seems our only hope is that the efficiency of our network/compute infrastructures can outgrow the blockchain, but it doesn’t seem to be the case.

So naturally, people are thinking how to cope with this by moving some data off the blockchain. Afterall, after a while, it makes little sense to carry very ancient transaction history. One proposed idea is having off chain payment channels. High frequency private transactions between a stable group of users can be carried out offline. Only the final results will be written back to the blockchain and thus reduce the size of historical data. For example, A gave B $5 first, and then B gave A $4. These transactions are equivalent to A gives B $1. If A and B do these payments a lot, then they don’t need to tell others about the transaction details, they just need to tell others about the final result of all transactions between them. One such a technique is called lightning network. Its protocol is quite complex, I don’t fully understand it at the moment.

I knew about payment channels since a while back. Every time, I read articles talking about how significant payment channels are, I always saw the same kind of example being used: Say you need to pay your landlord monthly rent, you can do this with your landlord off the blockchain, as you only need to settle your transactions once a while. But how many real life transactions are like this? Other than the monthly rent case, all I can think of is the membership card of, say, Starbucks or certain gym. On what scale can payment channels solve the scalability issues of blockchain? I failed to understand the value of it until I read about the orchid protocol.

Imagine the typical movie scene where a person wants to hire an assassinator to carry out an assassination. The conversation must go like this: “I will pay half upfront. And once the job is done, I will pay the rest.” Why will it be always like this? Because assassination is of high risk. To reduce the risk, you want to break the trade down into smaller granularity. In case shit happens, you lose only half of your money right? And in fact, if efficiency allows, you would want to break the trade into even smaller pieces, rather than dividing the payment into just 2 parts. For example, if I want to sell a bag of rice to an untrusted friend. I’d like to sell the bag one grain at a time, and he will pay me only a small amount of money for each grain. We repeat this till we are done with the whole bag. At anytime, if one of us becomes dishonest, one of us will only lose either one grain of rice or a small amount of money that is worth one grain of rice. However it would be too tiresome to trade this way in real life. But in the virtual world, computers can do millions of transactions quickly, so it is feasible.

For example, many cryptocurrency exchanges have been hacked. People are now trying to create unhackable p2p exchanges. Such an exchange won’t hold your money as a middle man. Instead, it will only find you a match who is willing to trade with you, and you and your match will trade in a p2p fashion. But this match isn’t necessarily honest. Therefore to guarantee safety, it’s wise to break down the transaction into micropayments. Hence the real value of micropayment channels is serving as a safety mechanism in an untrusted setting.

Orchid protocol tries to solve the censorship problem by creating an anonymous routing system, somewhat similar to Tor, the onion router. In case you are not familiar with Tor, basically when you visit a website via Tor, your network requests and responses will hop between few Tor users before reaching the server. The censors will have harder time to figure out which website you are visiting. The more users, who can access the internet freely, participate in the Tor network to provide traffic relay for other people, the more robust the system will become. But currently, Tor relies on volunteers in the free world to become relay nodes, they are not paid for what they do. And people are less likely to become a node without a financial incentive.

Orchid tries to provide such an incentive by adopting blockchain, so that you get proper cryptocurrency reward proportional to the amount of network traffic you have helped relay. Accounting is the biggest challenge of this system, as millions of network packets can be sent in a small period of time. And charging money for each packet isn’t practical with blockchain.

The micropayment idea they use came from this paper, which turns high frequency small payments into a series of raffle tickets. Taking the case of selling a bag of rice as an example, suppose for each grain of rice, you want to charge $0.01. And there are 100 grains of rice in total. So in the end, 100 transactions of $0.01 are needed for this deal to close. But with this micropayment idea, instead of paying 100 bills of $0.01, the buyer would give $1 to a third party, a computer program, beforehand. And then during the trade, the buyer will issue a raffle ticket for each grain of rice he receives. As a seller, you gather those raffle tickets. Only one of them will be the lucky ticket and that ticket will be able to claim the reward of $1 from the third party. Because you will have to gather all tickets to claim the reward, you have to close the deal first. As soon as you have all tickets, you give them to the third party who holds the prepaid $1 and that money will be yours if the third party can verify the authenticity of your raffle tickets. Again, this third party is a trustworthy computer program, not a dishonest human. This way, only 2 transactions will be written to the blockchain, the first being the buyer prepay money to the escrow and the second being you, the seller receive the money from the escrow when the deal is closed. Therefore relatively less data is needed to be kept on blockchain, versus 50 times more data if the micropayments were carried out naively.

Related to this, another blockchain platform, called Theta tries to create a distributed twitch. It has this idea of letting advertisers to bribe content viewers for watching their commercials. It would be to too costly to bribe all content viewers, so they designed this raffle system. Raffle tickets are distributed with the video streams. Viewers receive those raffle tickets while watching the advertisements. And they need to outrun each other to claim their rewards. Only one of them will be the lucky guy.

To sum up, micropayment is a very useful tool to ensure safety and reduce risk in an untrusted environment. Therefore, having efficient micropayment methods on blockchain is of importance. Blockchain, however, wasn’t designed to handle micropayment well, it prefers large infrequent transactions for they generate less data. One simple but smart idea of turning small frequent transactions into a large infrequent transaction, as used by the Orchid protocol, is turning transactions into raffle tickets.

--

--

Shi Yan

Software engineer & wantrepreneur. Interested in computer graphics, bitcoin and deep learning.