It’s a wonderful bit of irony that the Fiddler on the Roof character singing the above is named ‘Hodel’.
Regardless of how her name resonates with the current cryptocurrency market, Hodel and her sisters are well aware of how dependent they are on the services & goodwill of the village matchmaker. While they may have preferences for a future husband, they know that, ultimately, they will likely need to accept whatever mate the matchmaker finds for them.
We are similarly at the mercy of 3rd party matchmaking services like Airbnb & Uber, both of which exist to find matches between owners/renters & drivers/passengers respectively. While they are motivated to find good matches for us to encourage us to come back, ultimately, they are in control (and charge accordingly!).
This dependence is motivating startups like Bee Token to build a decentralized version of matchmakers. Specifically, Bee Token matches homeowners and prospective renters on a distributed ledger, not on the servers of a single provider, such as Airbnb.
Bee Token is covered in this Fast Company piece On This Blockchain-Based Version Of Airbnb, There’s No Middleman, where the CEO of Bee Token acknowledges the current reality of blockchain scaling:
From an engineering point of view, creating a blockchain version of Uber is a harder task than an Airbnb or freelance-matching network like Upwork. Uber needs to match up drivers and passengers in an almost instantaneous manner. Airbnb can do its match-making at a more leisurely speed, placing fewer demands on the underlying system.
Usage numbers suggest that Airbnb performs 1 match per second, while Uber is approximately 20 matches per second, but peaking much higher based on time of day in busy locations.
As Ethereum currently scales to approximately 17 tps (transactions per second), Bee Token’s statement that you can’t currently build an Uber on it seems reasonable — there would be insufficient tolerance to deal with the inevitable peaks. And of course, matching driver & rider is only the first step — Uber also tracks the location of the driver in (somewhat) real time and displays that to the rider while they wait.
Ethereum has indicated a long-term roadmap that promises to address this scaling challenge — through sharding or perhaps Layer 2 solutions like state channels. This may allow Ethereum to stretch in the future to the sort of throughput required by Uber and similar applications.
But there is another aspect of matchmaking beyond mere speed. More fundamental to the matchmakers services in Fiddler on the Roof than how many brides she could match, is the quality that she would perform her services fairly; that is, without undue bias against (or for) particular clients in the village.
A blockchain-based ledger can’t truly guarantee that sort of fairness. Whether based on Proof-of-Work or the planned evolution to the Economy-based Proof-of-Stake, Ethereum consensus presumes that a single miner or staker unilaterally decides on the most recent block. When creating that block, that node decides on which transactions will be added, and in what order. Consequently, the node empowered with creating the block can, if desired, act unfairly against particular transactions.
In an Ethereum-based Uber clone, perhaps that potential for unfairness would manifest as me getting your ride, even though you submitted the request first. I’m warm & dry in the car, yet you remain wet & cold in the rain.
Ultimately, any distributed ledger-based matchmaking application (whether for cars, rooms, or equities), must be both fast & fair (secure is also nice). While public blockchains may scale in the future to meet the speed requirements, as currently designed they cannot be fair.
Hashgraph is a consensus algorithm that is both fast (100,000s tps) and fair (as there is no leader who can unduly influence consensus order).
P.s., on March 13, we will be making an announcement.
