Current blockchain networks (Bitcoin, Ethereum, etc.) do not scale efficiently: their per transaction cost is ~O(N), where N is the number of full nodes. Several recent proposals provide restricted fast O(C) transactions using combinations of payment channels, probabilistic payments, and either cross channel routing (Lightning Network), or surety bonds/deposits to deter double-spending. I propose a new delegated arbitration mechanism wherein payees predetermine third party arbiters who quickly resolve double-spending disputes instead of predetermining the payee as in payment channels. Arbiters can prove honesty through penal bond precommitments and compete to earn small transaction fees in exchange for their services. Delegated arbitration eliminates the need for most users to lock up money in numerous channel deposits or bonds, more effectively allocates the net savings of the network, and in combination with unbound probabilistic payments allows for a high throughput and minimal latency micropayment network.
Note: I wrote up an earlier version of this in 2014, but didn’t finally get around to publishing it here until now. This blog post is a informal precursor to a research paper and will be light on details.
Background
Blockchain scalability was a primarily a theoretical problem that was mostly ignored by the non-technical community up until recently. Bitcoin and all other blockchain based cryptocurrency networks are simple full replica systems: each transaction is processed redundantly by all full network nodes. Thus the per transaction cost is O(N), which does not scale efficiently (the bandwidth cost per transaction increases as the network grows). However, in theory blockchain networks can effectively be O(C) if almost all network agents run “light clients” and the number of full nodes is constrained to a reasonable constant. In practice, this still works out to a prohibitively large O(C) constant.
Payment channels are a simple technique that can solve double-spending for the restricted payment stream setting. If Alice anticipates sending some large unknown number of small micropayments to Bob in the future, Alice can lock up some money into a channel that either pays only to Bob or refunds back to Alice after some reasonable timeout. Double spending is prevented because … the channel locks the payee field to a set of size one. The disadvantage is Alice must anticipate future spending and lock up sufficient funds. The timeout mechanism can also be complex.
Probabilistic payments are a micropayment mechanism investigated for decades preceding the arrival of Bitcoin. Each probabilistic payment uses a lottery ticket which has the same expected value as a larger regular macropayment, but that value is concentrated in a few rare tickets. Most tickets have zero value and are discarded, greatly reducing transaction tracking overhead. Probabilistic payments require a secure multi-party RNG. If a public RNG is available (such as hashes of the future bitcoin blockchain state itself), then generic lottery tickets can be used which pay to any holder and don’t require locking up funds in a channel with a particular payee. These more generic lottery tickets are essentially prediction market shares where the bet is on an RNG value. Conceptually the setup transaction is something like “if (rng % K == B), pay to Alice.Temp[B], else pay to Alice”. Then to pay Bob a lottery ticket, Alice just sends Alice.Temp[B] to Bob. The setup transaction divides a deterministic coin into K unique probabilistic coins (lottery tickets).
Probabilistic payments can alternatively involve a local RNG where the payer and payee use a two-party crytpo random number protocol to setup a lottery ticket. However there is no way in general to overcome the fundamental limitations of multi-party computation: one party can always gain some edge by defecting from any step in the exchange of secrets. There are various complex ways to mitigate this like splitting the secrets up into many small bits, or using a third party, but at that point you might as well just rely on the third party RNG variant in the first place. On the other hand, in a micropayment setting where parties are conducting large numbers of consecutive small transactions game theory works in our favour and small defections may not matter.
Note that probabilistic payments alone do not solve double spending; the generic multi-party variant can easily be double-spent, and the two party channel variant can prevent double-spending only through the channel lock mechanism. But if you are already using payments channels, you could just consolidate stream transactions (a sequence of A->B transactions for different amounts later get replaced with a single larger transaction). This provides the same benefits as channel bound probabilistic payments with perhaps less complexity.
The Lightning Network is an offchain micropayment protocol that adds a routing network layer on top of payment channels. Each payment channel forms a node in a network. Arbitrary payments between any two agents can then be routed across this network in a vaguely onion routing like fashion. Channel transactions are O(C), which is great, but all channel setup transactions, dispute transactions, timeouts, etc all still require full transactions (on-chain) which are still O(N) when using a blockchain network as the underlying foundation. So the lightning network is not really O(C) in expectation unless the average ratio of on-channel (off-chain) transactions to full (on-chain) transactions is O(N), which seems dubious. Furthermore, multi-hop routing in the lightning network adds latency similar to onion routing in TOR, which is potentially a significant disadvantage for latency-sensitive applications. The lightning network also requires all parties to lock up funds in channels for micropayments, essentially tying the economic network and the physical communication network together.
Penal bonds (aka security deposits) are a simple game-theoretic mechanism that allow honest agents to credibly signal their honesty by precomitting to an economic penalty for dishonest behaviour. Bonds themselves are a proposed potential solution for double-spending, and more recently Chiesa et all propose using a combination of bonds(deposits) and probabilistic payments in “Decentralized Anonymous Micropayments” (DAM).
To guarantee a negative payout for any double-spending attack the bond/deposit must be larger than the integral of the network’s entire GDP over the length of time required to detect double spending. In the worst case the payout for an optimal double spend is bound by the maximum value the network can ‘produce’ in the time window of detection (in other words, the optimal double-spending attack generates effectively infinite but very temporary wealth that can only purchase the very finite amount of services or stuff the network offers for the time period). For the case of a hypothetical network that produces $1 billion a year of various compute services and a 10 minute double-spend detection window, the safe bond/deposit size is on order $20,000 – fairly prohibitive. A double-spend detection window of just 3 seconds still works out to a $100 bond/deposit value. The situation worsens considerably when we consider external exchanges and short-timescale fluctuations.
Unfortunately “detecting double-spends” is itself not something that can easily be done in O(C) per transaction. So any bond/deposit solution that still requires payees to monitor all micropayments on the underlying blockchain network obviously can not actually be a solution itself. However, combinations of bonds (to deter double spending) and probabilistic payments (to reduce the overhead of detecting double-spending) are a viable micropayment solution. DAM uses bound two-party probabilistic payments + bonds + stuff (for anonymity), Arbiter Networks uses unbound probabilistic payments + bonds + delegated arbitration. Making arbiter networks natively anonymous is beyond the scope of this post, and perhaps unimportant given future improvements to off-chain mixing protocols.
Method Overview
Arbiter networks provide O(C) scalable micropayments sans channels through delegated arbitration: the task of resolving double-spending disputes is delegated to third party arbiters who otherwise have no actual transaction authority (no multi-sig and thus no counterparty risk if the arbiter fails). Arbiters use sufficiently sized penal bonds to provably signal honesty and can charge small transaction fees for their services. Essentially arbiters rent out the economic utility of their bond, allowing more agents to participate without investing in bonds (as compared to pure bond/deposit schemes). In essence, delegated arbitration is an add-on improvement to any bond/deposit mechanism.
A payer first sends money into a special account/contract that specifies a third party arbiter who resolves any equivocation/fraud (ie double-spending) disputes for those funds, but does not lock up the payee (unlike channels). Subsequent transactions involve only the payer, any arbitrary payee, and the predetermined arbiter. The payer sends payment information directly to the payee and arbiter, the arbiter checks for double-spend/fraud/errors then forwards the payment confirmation information to the payee. Upon receiving confirmation from the arbiter the payee can trust that the payer has not double spent so long as the arbiter’s penal bond is valid and of sufficient size to provably deter any double-spending from a hypothetical payee/arbiter collusion.
A timeout mechanism allows return of funds for the case of a non-responsive arbiter, as in payment channel timeout in Lightning Network. Payment channels lock the payee field, but delegated arbitration only locks the arbiter of disputes without locking the payee. Thus all the headaches of locking up funds into various channels in Lightning is avoided, and more importantly, transactions are routed through a near minimal 2 hop path for low latency and high throughput.
Arbiter Networks and Lightning Network both provide a constant speedup in transaction throughput and reduction in transaction cost. The Arbiter Network speedup is determined by the average factor (K/2): the number of probabilistic micropayments per macropayment (which is ultimately bound only by payee volatility tolerance). Only macropayments hit the full underlying network. The constant speedup for Lightning Network is some other factor (R/T): where R is the ratio of micropayments across a channel to macropayments to setup or refund a channel and T is the average number of hops in a route. I expect that (K/2) > (R/T), and moreover that K > R, but showing this will require some rather detailed thought experiments or simulations to substantiate.
Multi-Party Secure RNG
Any underlying blockchain can be used as an approximately ideal secure RNG. The hash value of some future block (T+C) are essentially unknowable to any party at block time T under realistic conditions. The situations where this condition fails are those where one party effectively has far more hash power than the rest of the network combined, and can afford to sit on a long extended chain for a time period of C.
A disadvantage of using a blockchain as the RNG is naturally that it does require monitoring the underlying blockchain network, but even this cost could be mitigated by having “blockchain summarizers” who monitor the blockchain network and publish the vastly smaller hashes of blocks in exchange for some small fee. These summarizers could naturally be kept honest through penal bonds, as the work they perform is easily verifiable.
Consider an example worker agent that sells one high end GPU worth of compute services. This agent could expect to earn perhaps $5 per day. Current transaction fees in both bitcoin and ethereum average around $1 (which does not include the miner subsidy). Thus a realistic value of K (the number of lottery tickets per coin, or micro to macro) should be balanced to have at most one macropayment per day on average. For an average rate of about 10 microtransactions per second (which seems reasonable for many applications), this works out to a K value of roughly 1 million. In practice a typical worker agent will probably have more than one GPU, although a fee overhead of 20% is also perhaps unrealistically high.
Market Arbitration Rates
There is an interesting connection between interest rates and the fees which arbiters can expect to charge. An arbiter is essentially renting out the utility of their penal bond. This locks up money that could otherwise be spent or invested in some computation, or could be lent out at interest. Curiously, the presence of penal bonds itself creates a need or niche for loans: bond holders may find themselves short of free cash but they have the bond as collateral. Loan repayment could be contractually automated such that the only risk a lendee undertakes when loaning to a bond-holder is the risk of bond default in the interim due to malfeasance. Normally this risk should be very low for adequately sized bonds, so the loan rate for these secured loans should be close to the risk free interest rate. So now there are actually at least two options for coin holders to earn low risk return: they can lock up coins in a bond and earn transaction fees or rent out their coins. (Financial markets provide another market for coin loans for instruments such as short contracts).
As the various uses of cash compete, the rate of return should normalize between the various uses. Thus the rate of return on a bond should be similar to some sort of natural low-risk interest rate. Transaction fees could be estimated from this if one knew the typical velocity of money: ie R = r^V, where R is the rate of return per year or time period, r is the average rate of return per transaction, and V is the transaction rate (per time period). For example, if we assume R is 1% per year (reasonable), and V is 32 transactions per second or about 1 billion transactions per year, then r is about 10^-9. For a bond of size $1,000 (reasonable from earlier analysis), this works out to fixed transaction fees of about 1 millionth of a dollar. In simpler terms, agents who lack bonds should expect to pay transaction fees on order of the interest rate for renting the bond for the equivalent time period of their transaction volume. In this fictional example the arbitration fees are on order similar to the macropayment transaction fees, which seems vaguely reasonable.
As the arbitration fees depend on the bond sizes which depend crucially on the double spend detection window time, a faster double-spend detection mechanism could be important (faster than just checking the macro-payments on the blockchain). I leave that to a future work.
Conclusion
The world altering decentralized applications of the future all involve a computational economy: a sea of autonomous machines bidding, contracting, and competing to perform useful computations. All economies require a currency as their lifeblood; crypto-currency is the natural choice for a future virtual compute economy, but sadly current crypto-currency systems are simply not up to the task. However, a rather straightforward combination of simple mechanisms can probably get us most of the way there. This Arbiter Network proposal is a potential piece of a larger vision I hope to explore soon in subsequent posts.
Enter the Singularity 