This is going to be a long update, that, for the sake of convenience we have decided to break down in to a set of shorter articles. There will be a number of posts describing what technical specification we have opted for in designing the SP8DE protocol (which has changed a great deal in terms of the technology as compared to what is described in the whitepaper; the purpose, albeit is kept unchanged) along with the development milestones, and a number of articles detailing out technology and protocol within a broader context; showing its niche in the rapidly developing world of computer science and applied mathematics.
This article will be of general nature: we will present a high level overview of what SP8DE is right now as well as the rationale behind its design.
Sharpening the outlines of the protocol
On the development side we have been busy primarily with understanding what product SP8DE needs to become. In filtering what’s beneficial and what is not, we have been ultimately driven by token price considerations: in the end, it is the only most important quantitative and objective measure of the project success. So, an interesting choice that would have an uncertain or undefined effect on the general token utility would not be favored over a less inventive one that yet would have been sure to make SPX more valuable. We have worked on answering the following questions:
What is the goal the SP8DE protocol needs to fulfill? What is its general purpose?
What is the customer profile? Should we cater to the business or the retail segment? What makes more sense from a commercial perspective?
From time, technology, and general SPX utility perspectives, is the SP8DE whitepaper protocol design optimal? If not, what is?
What are the technologies needed for (2)? What are the technologies in the distributed ledger domain and outside it, that merit being used in developing the SP8DE protocol? What parts of the protocol really require the use of blockchain? What can be done off-chain and are there any sensible benefits of decentralization? We want to note here that many projects have entered the space claiming that blockchain is vital to their development nonetheless have failed to provide comprehensive explanation for its particular use in practice. We will make a separate post where we will elaborate on this point in length.
In light of (1), (2), (3) is there a need for re-evaluation of the project roadmap: are the technologies and timelines realistic? In particular, is there any additional utility from using ETC over opting for the ETH technological stack? What is the Cardano state of affairs? In general, can we make SP8DE blockchain-agnostic? If so, what are the options that are currently available for deploying SP8DE?
What are the scaling solutions currently available? What is the promise of sidechains, sharding, Plasma, Raiden, Callisto, etc.). How ready are these for an immediate use?
What is the experience of SP8DE’s major competitors and just other firms in the field? Can their experience be learned from? Can their codebase be of any help?
What is the minimum required functionality SP8DE needs to have for an MVP?
What is the development roadmap? What are the priorities?
What is the optimal way to shape the casino-player and player-SP8DE interaction?
What is the stack? Who can provide it?
The good news is that we have successfully answered all of them. More than that, we actually have a large part of the protocol developed. The bad news is that there is so much we haven’t clearly communicated. This set of reports is intended to do exactly that.
The evolution of the SP8DE thought
In this first part we have decided to lay down briefly the most important: what will the SP8DE protocol be from the technological perspective? What is the rationale behind it?
The Macao conference that we have been participating in has profoundly changed the views we held on what would constitute commercial success for SP8DE itself, and what would maximize the value of our SPX token.
So, what happened during that conference? In few words, we have been confronted with the brutal reality:
The incumbent firms comprising the heart of online gambling industry do not care about the disruptive potential of distributed ledger technologies: notwithstanding the ideological appeal, any tech is evaluated by them from a very quantitative cost-benefit perspective. Are there any sensible benefits that blockchain can bring in terms of decreased costs and/or increased potential revenues? What are the risks involved (reputational, technological, etc.)? Currently, any gaming tech built entirely using the blockchain tech is:
Raw (not ready for immediate deployment);
Expensive (calculations in the Ethereum blockchain are about 1,000,000,000 – yes, one billion - times more expensive as compared to e.g. AWS cloud);
Inefficient (the time required to create a new block is far from being arbitrary and represents an inherent infrastructural limitation of the contemporary internet; it is the technology weighted cost of decentralization);
Insecure (no established industry standards on security – when it comes to deploying new smart contract infrastructure with a unique purpose, it gets too complex far too quickly: pick an example you like of what happens when security flaws are not noticed and fixed in time);e.)
Not scalable (the TPS limitations and costs are currently and for the foreseeable future prohibitive).
Competing with these firms is hardly an option for any startup, blockchain or otherwise, given the gap in marketing budgets. An established user base, recognized and well positioned brand, and multi-million monthly marketing expenses [2], [3], that are a norm in conventional gambling currently are all absent or unachievable by the majority of young startups from the blockchain world. Add to this the obvious benefits from the user experience perspective that centralized (thus efficient) solutions offer over the decentralized alternatives and the resulting picture appears quite grim.
As a cherry on top of this already devastating experience was the CTO of one of the blockchain gambling projects (no names at this point) who was sitting with tired, empty I-saw-the-devil eyes and repeating “it doesn’t scale – there is no way, it simply does not scale” or something along these lines.
At the same time there have been also bright outlines to this exceedingly grim picture: SP8DE has received its fair share of attention from many firms, the providers, who are busy selling their whitelabel backends - the pre-built customizable engines. Any industry, in the absence of major structural inefficiencies (such as global monopolies), strives towards efficient resource allocation. Improving the resource allocation in the Adam Smith’s spirit is possible via deepening specialization. With the advent of the internet, this has become increasingly easier: some firms are specializing in providing the infrastructure; others are busy building the brand name and sharpening marketing efforts. This is exactly what the online gambling industry represents today. We will elaborate on this in the upcoming releases.
An ideal case
So, what are the characteristics of the protocol that we as a team have considered to be most optimal for the purpose of creating corporate value (as reflected in the price of SPX)? The dream protocol has to satisfy the following conditions:
Produce unbiased randomness in a decentralized manner. The algorithm that generates the randomness (pseudo or otherwise) has to have good statistical properties and pass all the tests, fulfill the required standards (Here’s a 131-page paper that describes the statistical requirements. Have fun. [4]). Furthermore, the way the random variates are acquired has to be decentralized, i.e. it has to be generated by someone else, but the casino itself.
The protocol has to be cryptographically perfect in the following sense: given that at least 1 party is honest, the outcome has to be unpredictable for everyone. In other words, one can control the outcome (or, in general, have any idea about it) only in case if he or she plays against oneself.
It has to be easy to integrate: no casino or gaming backend provider will start rewriting their tech stack, porting the existing infrastructure on smart contracts in order to integrate SP8DE, however perfect it might be. So, the SP8DE block has to be something simple and have flexible API requiring minimum efforts on the side of casino (or software provider) and yet contain the desired functionality (see above).
The randomness generation process must require the use of the SPX tokens. The economics of the process has to be simple with demand for the token being proportional to the popularity of the protocol.
This process has to be scalable far beyond the limitations of the contemporary blockchain technologies. Given the level of development of modern scaling solutions, this requirement implies that the generation itself has to go off-chain.
Finally, there must be an easy way for players to understand the workings of the protocol and verify its results. Relatively small fraction of the online gambling audience is adept in the cutting edge applied cryptography, so there needs to be an easy way for a layman to understand the benefits SP8DE offers, and to be able to check that it works as intended.
We are writing this report primarily to inform everyone that we have a detailed specification of a protocol that has all of the aforementioned characteristics. Furthermore, we even have a small demo, an alpha MVP, a super-concise implementation of the required functionality. In this vein, we would like to proudly announce that even from a conservative point of view we are moving in concert with the roadmap that we have planned out before the ICO commenced in early January, 2018.
High-level design
In this document we will disclose the high-level design. In the pieces that follow, we will elaborate extensively on the particular technologies involved and explore in detail what hides “under the hood” of SP8DE. The codebase will not be made entirely public as by doing so, we will destroy all the commercial value of the protocol: anyone will be able to copy it and use for their own purposes. We will make the code public only once we have firm commitments by several major gaming firms or when we patent it. Yet, we of course will also make sure that the community has firm reasons to believe that the codebase is being built and continuously expanded.
The following is the high-level overview of the SP8DE protocol:
The client (web or desktop) of a casino generates a private / public key pair for the player. The particular protocol used for doing so is not material - for example, we can use Ethereum. The private key is held only within the client and is not accessible by the casino.
The client generates a random number (using any, and we will elaborate further in a separate post, RNG [5]). If required, the client seed can be augmented with the user-specific session parameters (mouse movements, system information, etc.).
The seed is signed with the private key and is sent to the casino along with the public key and any additional metadata.
The casino performs an analogous operation and sends the data (public key, signed random number, metadata) to SP8DE. SP8DE does the same.
SP8DE creates the “game” object with the following parameters: (a) game id, (b) sign of the casino, (c) sign of player, (d) sign of SP8DE, (e) public keys. This data is sent to the casino. Casino sends it to player.
The random numbers are then sent to SP8DE. Out of them the seed is generated and is used as an input in a PRNG on the SP8DE side to generate a set of random variates required by a particular game. This operation can be verified by both, the casino and the player.
The information about the random numbers created is then published in some distributed database. Per se, it doesn’t have to be a blockchain: structures like IPFS can be used if they prove to be cheaper, more efficient or both.
The information is then (a) verified by the casino, and (b) the outcome of the game is determined accordingly. All the information can then be verified by all parties.
The core benefits of the protocol as described above are:
Easy to scale: compared to any on-chain design, the aforementioned protocol is much faster. The generation of randomness does not need the blockchain. At the same time, it does not compromise fairness and transparency.
Protocol design allows for an arbitrary frequency of generating random numbers.
Protocol is easy to integrate for casinos: no need to interact with the blockchain.
All the payment infrastructure remains with the casino: no need to adapt the payment channels, protocols. Also, there is no security risk taken by the casino: SP8DE cannot ‘steal’ any clients funds.
Generating randomness does not require SP8DE to know the rules of the game.
Transparency for all the participants facilitated by the absence of any economic incentive to attempt to manipulate the outcome of the generation process.
