1.6: Oracles, Identity, and the "Real World"
This high art of advanced cryptography and high assuruance programming sounds great, but who won the Knicks' game?
Currently, NBA.com or ESPN.com will tell you this crucial information, which in turn decides the fate not just of the individual teams, but of the massive sports betting market that pays out based on an increasingly complex list of metrics about the game. Point spread, obscure fantasy sports data like rebound percentages for each player, etc.
Just like the Registrar's office from our introduction, an opaque/trusted/centralized black box serves as the ultimate source of truth. Also like the Registrar's office, this isn't really a problem. We trust the NBA for our sports scores. But we also trust ESPN, and maybe even the local sports reporters actually at the game.
The NBA, ESPN, and the sports reporters are all "Oracles", a fancy term for providers of the truth.
Without a quality filter for data going into a distributed ledger, the data stored in a immutable distributed record is just as terrible as a corruptible centralized record. The only difference between DLT and centralized ledgers, is the garbage stored in DLTs is immutable, and will be wrong in a pristine form forever. That is unless we append the ledger to a new version of truth and agree on that, though the false information will be stored in a previous part of the chain forever.
(even if hidden by a user interface set to hide flagged information by default)
Distributed Sports Books
Two major use cases for distributed ledgers revolve around creating systems that:
- cannot be shut down by central authorities
- have drastically lower fees paid to corruptible middlemen by replacing them with automated distributed trust networks
Thus sports books are incredibly ripe for distributed ledger disruption. People love to gamble, but governments tend to frown on social ills. As an unfortunate by product, bookies are driven into the shadows which protect their high margins, and create an environment conducive to breaking knee caps when debts are not paid back.
Over the last few chapters, we have hopefully established that any two people can transact value by using a distributed ledger to settle the transfer of credits and debits.
The catch is, who is in charge of determining the winners and losers?
The logic to create an automated sports book which derives winners and losers is relatively simple:
- IF Arsenal beats Man U by at least 2 goals
- THEN debit Alice 50 dollars
- AND debit Bob 50 Dollars,
- THEN credit Charlie 99 dollars
- AND credit automated bookie 1 dollar
Granted in the real world order matching is much more complicated. Bets only work if equal amount of makers and takers can be found for each given event, and each type of bet.
However, inside of a globally liquid sports book full of thousands of betters, orders will get matched, and wagers will be made.
Say the worst case scenario happens and ESPN.com is hacked. An attacker infiltrates ESPN's servers and reverses the results, running off with millions by taking the long shot bet before the game.
In a centralized bookie system, the results are probably not catastrophic. There is a delay between when bets are placed, and when bets are settled after the game. Also the bookie can watch the game on TV and see what the score really was, or consult multiple sources of information to determine the ESPN feed was compromised. (E.g. the bookie has judgement and in effect arbitrates between the two betting parties to determine the proper outcome)
Things are not so easy in a distributed sports book.
A computer, not a human bookie, determines who won and who lost based on a feed of information from somewhere. If ESPN was the only oracle used to validate a sports score, an attacker could corrupt the ESPN feed long enough to run off with a massive payout.
Hence why distributed ledgers need oracles, and by extension "real" identities to function properly in the "real" world. Remember in the distributed ledger world, once tokens are gone, they are gone forever. If you send funds to a public key address you do not have the private key to, consider them lost unless you implicitly trust the smart contract.
Say in a hypothetical smart contract Alice, Bob, and Charlie, each put in a Bitcoin to initiate a bet. They each send their respective Bitcoin to a common smart contract (public key) address.
Thus the only way to ever see their Bitcoin again, is if the smart contract executes the bet properly, and the real winner is paid out back to a private key address they control
(or of course keep everything inside a centralized exchange which is no different than any existing online sports betting platform)
There are two main ways to mitigate a centralized data feed attack, and determine the real winner:
- Have multiple oracles reach a consensus about the truth
- Give (some) control of the smart contract over to an arbiter
Multiple oracles sound like a reasonable way to address the problem of truth. Just like we have multiple full nodes validate transactions, why not expand that logic to multiple oracles agreeing on the truth.
For instance, NBA.com, ESPN.com, five local sports reporters (and a image recognizing AI fed the live TV stream) can all agree on the details of the game.
Some dApps are being developed to flesh out the incentive mechanisms behind rewarding honest oracles, and punishing dishonest oracles. Simple examples are where oracles would "stake" (i.e. commit) a certain number of tokens to a staking address before judging the results of an event.
- IF other judges agree on the results
- THEN the judge staking tokens is rewarded with more tokens for providing honesty to the system.
Over time, "reputation systems" can develop which route to oracles with the best track records.
Of course, this chapter would be severely limiting if it only talked about a small use case like sports betting. Getting paid for writing honest reviews, or even voting in elections is possible with the same basic logic.
Today, non-monetized reputation systems exist on sites like Yelp and Trip Advisor where users with high reputation gravitate towards the top of the review page.
Even without monetary incentives, people happily contribute hard earned time to write reviews and participate in the system.
Unfortunately, people today being taken advantage of by giving away their data for free.
The concept of monetizing oracles must be handled with care.
Dismantling centralized systems to return the power to users over opaque black boxes is a net good, but only if implemented properly.
For these types of transactions, they might be so critical that an Arbiter might need to intervene to set things right.
To accomplish the functionality of a transaction reversing Arbiter without resorting to a centralized system, parties to a transaction can require multiple private key signatures before funds are sent.
In our dBay example in Chapter 1, we illustrated how an arbiter can intermediate a dispute between two parties on whether or not the beanie baby was in the condition the seller claimed it was in at the time of shipping.
Multi signature addresses can be setup in any possible configuration of M of N where M number of signatures out of N total signatures are required to unlock funds.
This multi signature system is key to many critical use cases.
- In our Arbiter example, we can set up a 2 of 3 multi signature transaction and give one key to Bob one key to Charlie and a final key to Arthur a contracted 3rd party Arbiter.
- In our sports betting example, if Bob and Charlie both agree on the results of the bet, 2 of the 3 needed password private keys are used, and the funds are transferred.
However, if there is a dispute, Arthur can step in with his key and resolve the issue by siding with one of the parties.
This system of multi-signature addresses has far reaching implications for the success of distributed ledgers in the real world.
Imagine the following situations:
- You lose your private key and instead of your funds being lost forever, you can entrust keys to a spouse and a for hire arbiter such as a traditional bank. With a 2 of 3 multi-sig account.
- On a decentralized social network you can entrust up to five keys to your five top contacts. If you lose access, getting 2 of 5 or 3 of 5 contacts to authenticate you will allow you back in.
- A board of directors wants to vote by proxy to decide whether to fund a proposed expansion of the business.
- IF 3 of 5 board members vote yes
- THEN funds are sent
- ELSE they remained locked
To succeed, these systems will need a good user interface plus smooth behind the scenes logic, as copy pasting lengthy private keys is not the way towards mass adoption.
Just because random string of letters and number X votes to unlock funds, how do we know this address represents of the 3 needed real world directors?
- Abababab (Alice) votes YES by sending vote to address 12341234
- Cdcdcdcd (Charlie) votes YES by sending vote to address 12341234
- Efefefefef (Edward) votes YES by sending vote to address 12341234
E.g. how do we know Alice is Abababab?
The tricky part when placing identity (or any piece of data) onto a distributed ledger is the very first step where the account is created.
If entered wrong in the first place, a fake identity can easily masquerade around as a real identity, even if all records of the fake identity are stored in an immutable record forever.
Thus we need to tie account Abababab to something in the real world like a Alice's legal name, date of birth, passport number, or even bio-metric identifiers like DNA or fingerprints.
Take fingerprints for example, as they are easy and intuitive to create an authentication system with. To a computer, a fingerprints are nothing more than a series of pixels in an image arranged in a particular order.
As this fingerprint file is a piece of data like any other, when creating account Abababab for Alice, we can simultaneously tie the data encoded in the unique physical fingerprint to Alice's account.
This makes it possible for Alice to vote with her thumbprint.
However (in the real world) there are serious complications to fingerprint based private keys as someone can easily steal fingerprints either if a copy of the print is stolen from a centralized police database, or even lifted from a wine glass. All biometric forms of authentication like facial vein scanning or even DNA scanning are vulnerable to physical attacks, so likely some form of PIN or password is needed in conjunction with biometrics to prove identity.
The point is, there are ways to tie authentication to distributed ledgers in more intuitive ways that hide the messiness of wonky private key passwords.
Once we solve the hurdles of:
- associating a public key address with a person
- making it secure and easy to authenticate people with better private key interfaces
We have unlocked a Pandora's box of sorts.
In a sense, our distributed sports book is a democracy of sorts. Voters (betters) place wagers (votes) on who they want to win.
In an actual democracy, we really don't need oracles as each vote counted directly determines the winner. (Unfortunately, with fallible centralized voting machines, we still have to put up with electoral colleges and other such non-sense in the meantime)
As we have built up to in Part I, use cases (dApps) like voting are only possible with all of the layers of the technology stack working in harmony. Starting at the bottom and moving up we have:
- The consensus mechanism that places transactions into a series of immutable distributed ledgers hashed together to guarantee authenticity (various ways of doing this explained in chapters 2 through 4)
- Bulletproof virtual machine environments where buggy code cannot execute contracts incorrectly (addressed in chapter 5)
- Very base level dApps like oracles and identity managers that allow us to trust that entries on the distributed ledgers are indeed representative of the real world (addressed in this chapter)
On top of this stack can finally rest true democracy. Not just in the sense of electing politicians, but in making it easy and provably secure to vote for anything that would benefit from being put to a vote.
This capability offered by DLT gets at Liquid or delegative democracy, a concept where users are incentivized to:
- vote directly if they are a subject matter expert
- or delegate their vote to subject matter experts who can vote in en masse on their behalf in areas where they are less familiar.
This topic brings us to the final technical piece of the puzzle we feel needs explaining to fully prepare the reader for part II: Privacy. In our last chapter of Part I we will try to square how a system that records things forever can possibly be congruent with privacy.
Voting systems where voters cannot cast their ballots in secret lead to the potential for persecution. As votes are data just like fingerprints are data, or money is data, we will need to fully investigate privacy to see how transmitting data in private through distributed ledgers will impact the larger socio-cultural landscape in part II.