The previous article in this series introduced the concept of Data Proxies on Bookie. Data Proxies take care of Phase 1 of Bookie oracleization - they provide clean, normalized sports data to the Bookie ecosystem, using multiple external sources (third party data feeds).
Phase 2 of the Bookie oracle process is concerned with merging these multiple data sources into a single, trusted record of sports data that facilitate consensus-driven injection of verified sports data into the Bookie back-end (which sits on the Peerplays blockchain). Verified sports data is used by Bookie to:
- create new sports events and matches
- manage markets (e.g. turning markets in-play )
- resolving bets as winners (or losers) based on final results
Phase 2 is taken care of by what we call Bookie Oracle Software (or ‘BOS’ for short). Each of the block-producers of the Peerplays blockchain (called “Witnesses”) are required to run an instance of BOS. It’s easiest to understand BOS by looking at the three key functions it performs:
- Receive sports data from multiple Data Proxies
- Merge data from multiple Data Proxies
- Use this merged data to propose data entry and amendment for Bookie
Let’s take a closer look at each process.
1. Receive sports data from multiple Data Proxies
A Witness should ensure that their instance of BOS is receiving data from multiple Data Proxies. Currently, PBSA recommends that BOS is connected to a minimum of three Data Proxies. To connect to a Data Proxy, a Witnesses contacts the relevant Data Proxy operator, and they agree a kind of subscription where the Data Proxy adds that Witnesses BOS to a ‘data subscriber’ permission list.
2. Merge data from multiple Data Proxies
Once BOS is connected to an appropriate number of Data Proxies, it needs to merge these multiple streams of data into a single internal record of sports data specific to this instance of BOS. This merging is achieved by the application of simple rules that are similar to the consensus rules for the Peerplays blockchain proposal system. For example, BOS might merge data using the following rules:
New Event: data merge occurs when at least one connected Data Proxy reports New Event
Result Report: data merge occurs when a certain majority (e.g. 50%+1) of connected Data Proxies agree on Result.
3. Use this merged data to propose data entry and amendment for Bookie
Once a new piece of merged data is added to its internal record, BOS must next decide what actions (if any) to perform. To make this decision, BOS refers to a lookup table (which is distributed with BOS) called ‘bookiesports’.
bookiesports is essentially a set of rules and recommendations about the sports, leagues, competitions, and betting markets that should be offered on Bookie. bookiesports also provides configuration information regarding betting market formats and standardized team/competitor names. Use of bookiesports allows Bookie to provide a coherent product offering that meets the expectations of the sports betting consumer.
Based on the rules provided by bookiesports, BOS will use the newly merged piece of sports data to build a proposal that is submitted to the Peerplays blockchain. Other Witnesses signal their agreement by voting for the proposal (or abstaining if they do not agree with the proposal). Proposals must reach a consensus threshold of ‘for’ votes across all Witnesses before they are executed by the Peerplays blockchain and accepted as verified Bookie data. The consensus threshold is a simple majority of 50%+1.
BOS has been built to automate the three processes described. Automation of BOS is important, due to the huge amount of sports data being handled, and due to the 24 hour scheduling of global sporting events. For those edge cases where human intervention is required (due to issues with Data Feed Providers or Data Proxies, or due to novelty betting markets) BOS allows for manual intervention by Witnesses, using a sub-module called MINT (Manual Intervention Module).
More about MINT in the next article in the series.