 |
| Stock trading on the New York Curb Association market, 1916 |
Historically, most databases and ledgers have been maintained at a central hub. In order to get access to this information, users have had to walk into the building that houses the records, or sign into a server that stores them. Bitcoin, litecoin, Ripple, and other cryptocurrencies all demonstrate the possibility of distributing a database away from its center. Rather than a hub doing all the work, networks of independent nodes can store, maintain, and update the database. Bitcoin's ledger, the blockchain, is probably one of the best examples of a real living distributed database.
A few weeks ago I had some fun speculating that one of the worlds most important centralized ledgers, the Federal Reserve's Fedwire system housed in East Rutherford, New Jersey, might one day be converted into a bitcoin-style distributed ledger. The advantage would be redundancy. Take out a hub and the entire database disappears. Take out a node, and the database lives for another day. Here's some more speculative financial fiction: taking inspiration from cryptocurrencies like Ripple and Bitcoin, might all equity trading one day move from a central order book to a distributed order book?
A market's order book is made up of a list of buyers and sellers, the amounts that each are willing to transact in, and their desired price. It amounts to a supply and demand curve for a given equity.
When early financiers congregated on a curb or under a buttonwood tree to buy and sell stock, the demand and supply curves were visible to anyone who was close enough to see the action. Get too far from the buttonwood tree and the order book was no longer visible. Later on, trading migrated into cafés and special rooms. Only those directly on the floor could "see" the current demand and supply curves. Anyone on the edge of the action could get an indication of the order book by communicating with their floor trader via an odd array of hand gestures and signals. An investor outside the building, say Jesse Livermore, had to phone his floor broker for a quote, who in turn had to quickly sign to his trader and then relay the response back to Jesse Livermore. By the time Livermore had the data, the quote on the floor would already be different.
This is one of the defining features of a centralized order book. Access to the information contained therein is tiered. Those closest to the geographical centre have the most current information. Quality steadily deteriorates as one moves away from the hub. Having faster lines of connection into the hub—say a broker and trader who can gesture incredibly quick—can give one trader an informational edge over another.
The order books of modern electronic markets are centralized on powerful computers in suburban data centres. The NYSE's order book, for instance, no longer exists in New York. It can be found in a datacentre in Mahwah, New Jersey, about 30 kilometres from Wall Street. (See map below) One wonders if we shouldn't rename the exchange the NJSE.
View Larger Map
In fact, most of the US's major equity exchanges are run out of datacentres in New Jersey, including the Nasdaq in Carteret, BATS in Weehawken, and Direct Edge out of Secaucus. [See Google Map]
As in times past, it's still very important to be close to the geographic center of a centralized database. Evidence of this is that a large part of the NYSE's Mahwah datacentre is currently rented out to trading firms keen to install their hardware as close as possible to the exchange's own computers. When a new quote is added to the NYSE's order book for a given stock, say JPM, the first tier to receive this information will be those who are co-located next to NYSE's machines. The information will ripple outward from there through T1 fibre optic cables to successive tiers, beginning with those who have set up shop just across the street from the Mahwah datacenter and ending with those who are furthest away, typically retail clients and small institutions.
By the time retail clients and small institutions get to see the order book for JPM, the true order book back at Mahwah will have already been updated with new quotes. Despite not knowing the true book, those on the informational periphery will nevertheless base their trading on the stale quotes they see in their version of the order book. Colocated traders, already apprised of the changes to Mahwah's order book, can take advantage of their superior knowledge and put themselves in a position to profit from relatively uninformed trades flowing back to Mahwah. By virtue of being right next to the central ledger, colocated traders get to "see" the market a few milliseconds ahead of everyone else. Latency wars — the modern competition to decrease time delay over a digital network — is only the most recent chapter in a centuries' long battle to get as close to the central order book as possible.
A centralized order book is hardly democratic since those closest to the hub can consistently use their informational advantage to game those who are furthest away. But no one ever said markets were fair. Nevertheless, too much unfairness in a stock market can be destabilizing. Unlike say a grocery market, a stock market is only as good as its liquidity. If too many investors feel they are being pickpocketed they'll walk away from the market and liquidity will dry up. This hurts all actors in the market, including those at the center. It also hurts equity issuers, since reduced liquidity inhibits their ability to raise capital.
Which brings us back to bitcoin and the idea of a distributed ledger. Here we have a solution to the tiered nature of information reception from a central hub. Why not have a network of independent nodes store a stock's order book, listen for new quotes and trades, verify the identities of traders, and update the distributed order book? The neat thing about storing data in a distributed fashion as opposed to a hub is that information is freed from geography. Rather than sitting on a computer in Mahwah, New Jersey, the order book is everywhere. This would help to mitigate the unfairness issue that plagues central order book markets.
Exchanges like NYSE Euronext, NASDAQ, and BATS would suffer. These businesses make plenty of money by charging people to get as close to the order book as possible. Think fees for membership, seats, data access, and colacation. Put a stock's order book in a distributed database and the premium people are willing to pay for access no longer exists.
Distributed order books are not science fiction. If you do want to see one in action, head over to Ripple. The ripple client lets anyone see a distributed order book for claims denominated in multiple currencies including bitcoin, USD, and euros.
On inequalities caused by latency, read Latency Arbitrage: The Real Power Behind Predatory High Frequency Trading by Arnuk and Saluzzi and Latency Arbitrage, Market Fragmentation, and Efficiency by Wah and Wellman.
Here's an 2005 paper on Peer to Peer Securities Trading by Gehrke, Daldrup, and Seidenfaden
While decentralized ledgers are definitely interesting, I don't think they're quite up to the challenge of replacing exchanges. At least, not yet. There's quite a few technical problems that need to be worked out. While you're right that the latency wars are not ideal, I don't think there is any way to make them go away without resorting to a less efficient -- and ultimately more problematic -- form of tie-breaking. A distributed ledger would not necessarily make things much better, and if not well thought out, is likely to make them much worse.
ReplyDeleteJust think about some basic questions: How is the latest order book propagated to all participants? Who decides which orders actually get executed? And how often is this information updated?
In a centralized system the answers are easy, since there is a single node in charge of everything. This node maintain the the order book, broadcasts its state, and decides which orders are executed. But how does it decide, and is it fair?
Well, while many exchanges do have complex rules, such as giving parity to designated market makers, their matching algorithms are almost always based on either time-price priority or pro-rata allocation. These systems reward low latency and large order size, and seem to be the fairest methods of allocation. They are straightforward and incentivize rational trader behavior: place your orders quickly and honestly.
So how would everything work with a distributed ledger? In bitcoin, the miner who completes the proof of work picks the contents of the block. They pick which transactions to include based on their size, fee paid, and timing. Notice, this reduces to time-price priority and pro-rata allocation, so it doesn't help much. But let's they also use some other tie-breaker -- could this possibly be any fairer?
Even if they use a randomized process, think about what this does to incentives. Traders will just flood the network with transaction requests, since they know only a limited percentage of them will go through. Enterprising nodes will selectively broadcasts trades. Miners will only accept transactions with certain transaction fees, or they will hide themselves behind nodes that will block undesirable transactions from ever reaching them. I can't think of a constraint off the top of my head that can't be abused by constructing malicious network topologies.
Ripple attempts to get around this by re-introducing trust, deciding on the state of the ledger via consensus. Ripple also discourages orders from flooding the network by introducing variable transaction fees. This might work, but it still complicates the incentive structure, which could have unintended consequences. However, the consensus process involves quite a bit of network chatter, which slows down price discovery since ledgers can take a few seconds to close.
If the MtGox lag can serve as an example, this it not good for stability. Consider how the further discretization of trades affects market dynamics. Does it do anything to mitigate the latency wars? It might actually make them worse, since it encourages traders to broadcast their orders from multiple points in the network, in order to break ties with the highest probability.
With a dynamic network topology, geography becomes even more relevant! No longer does it suffice to have a server right next to the exchange. You have to be prepared for network changes, and adapt to them as they happen. You can no longer assume that your latency is relatively constant, or that your competitors' fiber cables are all the same length!
There are a few other issues to consider, but this comment is long enough already. :)
Clark, good comment.
DeleteI have no doubt that distributed order books introduce a whole new set of complications.
Centralized systems have a few centuries' head start. It'll be interesting to see how quickly those who are designing them are able to address some of the problems you highlight, if at all.
I don't have the ability to engage you on the architectural level -- I have no idea how tie-breaking works -- but if you're interested in distributed order books there are a number of projects grappling with these problems including Ripple, Open Transactions, and Buttercoin.
As someone who uses markets, I'd hesitate to use a distributed order book if there was any uncertainty over the rate at which trades and quotes are verified. Bitcoin takes 10 minutes, Ripple a few seconds. When they can cut this down to microseconds, even during wild markets in which billions of quoates are being submitted, then I'd consider trading on it.
Google Fiber to the rescue!
ReplyDeleteCame over from MR discussion.
ReplyDeleteI've used exchange-like systems as class projects, so I've spent a little time thinking about the concurrency and distributed-ness issues. Two particular problems come to mind:
1) Time ordering. As Clark alluded to, time ordering is troublesome in a distributed system. A consensus based system can agree on an ordering - which may or may not have any relation to any real world time sequence - but that happens at each ledger close, which just isn't going to be fast enough for quotes. Because of this, a distributed transaction system doesn't work well for queues (like a time priority order book), it does much better when the ordering of transactions is not very critical (payments are like this, since usually the end result is not affected by ordering). I saw a suggestion recently to tame HFT by using auctions every 5 seconds or so. A distributed ledger could probably handle that well.
2) Partitioning (aka split brain syndrome). Large distributed networks occasionally split. In such situations, one must choose to either shut down one side of the split or to run inconsistently - ie two separate ledgers. In a centralized system this is easy - the ledger side of the split continues and the other side loses access. In a peer-to-peer system you need an agreed mechanism for choosing a winner. In Ripple and payment like systems the two sides can both continue and figure out a merging later, but that won't work for an exchange.
Technically these can be resolved, but they would change the rules of the exchange.
-SqueekyWheel
Interesting. Have you had a look at how Ripple implements their distributed order book?
DeleteI've wondered whether the whole latency wars thing was actually a purposeful market inefficiency. In principle simply putting a randomized time delay on all of the orders (eg it gets delayed by between 10 and 200 seconds) would "solve" the latency wars. That would cause an even playing field and increased market efficiency and so wipe out the profits of elite traders not to mention avoid the billions squandered each year on ultra low latency trading systems.
ReplyDeleteI think its purposeful... tiered access has always been a way for exchange owners to make more money. In the old days, you had to buy a seat in order to get close to the action. You'd earn rents by front running whales phoning in huge orders from the outside. Now you pay to colocate in order to frontrun the whales. Delays would prevent this. But exchanges would lose a major revenue stream.
Delete