As one of the largest industries in IT, online gaming is estimated to currently attract 1 billion users worldwide and generate USD 18 billion in revenue. However, as enticing and entertaining as these games are, the current model generally revolves around centralized servers controlled by the software companies that develop them. As such, users often invest an unbelievable amount of energy and time in these games, exposing themselves to be left in complete disarray if the company shuts the game down or changes the game’s rules in a way that is harmful to the player. For instance, users sometimes spend sizable amounts of money to acquire game assets, only to watch them become useless in the blink of an eye.
This situation has turned gaming into one of the great potential applications for blockchain technology. It is just natural to imagine decentralization as the solution to make people trust their money and time into a game without having to worry about getting skinned by a future unilateral decision from some company. One would imagine that such a scenario would bring even more people and money into the business.
Nevertheless, even with all this potential, in practice, the current limited conditions of blockchain technology have made it highly unattractive for the general mainstream gaming industry to invest in this space. Indeed, when closely inspected, the solutions presented so far for implementing complex blockchain games end up compromising in one way or another the very reasons for using a blockchain in the first place. In general, either the solution is actually still partially centralized, or it does not present the security guarantees needed for people to trust their money in it. In other words, with the current solutions, essentially either the game still breaks if a company shuts something down, or there is no robust mechanism to ensure players do not misbehave. Or else the game must be so simple that no one will be interested anyway!
The truth is that companies currently simply lack the tools and the scalability to develop real and complex decentralized games. But Cartesi is here to bridge this gap.
To better illustrate the scenario presented above, we will now more closely examine the concrete use case of a decentralized Poker game.
Online Poker is widely known as a gigantic industry attracting millions of players worldwide. On the flip side, it has also been widely criticized for being prone to all sorts of trust issues, spawning scandals such as a superuser account having access to players’ cards and using that information to benefit malicious users. Because of this shady track record, habitual players almost unanimously have some level of distrust towards centralized Poker platforms.
Now, decentralizing a Poker game, or any card game where the players need to keep some information private (namely their own cards), presents a non-trivial theoretical problem. Considering that all data is publicly available in a blockchain such as Ethereum, how can certain information be kept private to each player but still allow multiple players to agree on the final result? Fortunately, this problem has already been addressed in the academic literature, where the solution is commonly referred to as “Mental Poker”. Originally devised by the creators of the RSA encryption protocol to enable people to play Poker through the postal mail, it essentially consists of a set of cryptographic strategies using zero-knowledge proofs that allow two parties to shuffle a deck of cards so that none of them can know which card is which, unless they both collaborate. In a nutshell, the first player encrypts each card, shuffles the deck, and passes the encrypted and shuffled deck over to the second player, who will do the same. The game will thus start with this resulting doubly shuffled and encrypted deck, in which a card can only be revealed if one has the decryption keys generated by both players.
Even though Mental Poker provides the fundamentals for playing card games without a trusted centralized third-party, one serious issue remains: if there is no central server, how to control cheating or misbehavior by any one of the players? In other words, if a player sees that he is losing the game, what is to stop him from no longer collaborating to reveal the cards, sending bogus decryption keys instead of the real ones? Or even worse, a player could simply claim victory even though he lost the game, opening a dispute with regards to the final result.
The simplest solution to this problem would be to just fall back to some manual or centralized entity in order to verify and enforce the correct result, in case the players do not agree among themselves. Indeed, there are platforms currently being developed that use exactly this strategy, where essentially the players use a blockchain platform for regular gameplay but at some point a centralized authority will ultimately be called upon to resolve certain disputes. At first glance this solution may seem to minimize trust issues, but in practice it still relies on trusting some final authority who will be in the loop if the stakes are high enough or if a player is malicious and well connected enough.
As such, the clear real solution would be to run the logic of the game on the blockchain itself, in order to verify the true result and determine whether any player misbehaved. However, the cryptography involved in Mental Poker is undoubtedly way too complex to be performed on current Layer-1 blockchain platforms such as Ethereum. This way, it becomes imperative to run this computation off-chain, namely using a Layer-2 blockchain solution. Now, while there are numerous Layer-2 projects that could in principle provide the necessary scalability to perform these computations, it should be said that the cryptography required by Mental Poker also involves very specific and sophisticated software, which is simply not easily developed from scratch. As such, since most Layer-2 solutions cannot take advantage of existing mainstream software components and libraries, implementing such an application on any of those would amount to a very expensive, time consuming and even potentially insecure endeavor, since it would be hard to ensure the consistency and safety of newly developed software of such complexity. Luckily, Cartesi is not like other Layer-2 solutions, and real battle-tested existing software can be used for the task.
Finally, it should also be mentioned that there are existing gaming platforms where such computations are also taken off-chain, but without the use of a proper Layer-2 solution. This means that these platforms do not inherit the real security of the blockchain and can thus be considered prone to attacks and misbehavior if the stakes are high enough. And for games like Poker, or any other game involving relevant crypto economy or user asset management, they sure will be!
Now that the real use case of implementing a decentralized Poker game has been laid out, let us present Texas HODL’em, a fully working solution to the problem in the form of the classical Texas Hold’em variant of Poker. This solution has already been implemented by the Cartesi team, and showcases the power and potential that its unique technology brings to the blockchain application space.
First of all, as discussed in the previous session, the basic decentralization of the game is achieved by using a Mental Poker algorithm. Here, Cartesi allows us to take advantage of an existing well-known cryptographic library called LibTMCG, which is written in C++.and provides a toolbox of algorithms derived from advanced academic research.
Using Mental Poker, each user plays the game on his own device, sending their respective movements or turns to each other. For simplicity, this implementation uses the blockchain itself to send the data over, which thus serves not only for the players’ communication but also for recording the game’s log in an indisputable way. Here, we use Polygon’s PoS sidechain to ensure we have enough speed and low fees to make the solution minimally viable.
This communication mediation and game logging is performed in the blockchain by a set of TurnBasedGame smart contracts implemented by Cartesi. Even more importantly, these smart contracts also allow the state of the game to be challenged in case of any disagreement, such as refusal to send proper decryption keys or false claims concerning the final outcome of the game. As such, when a challenge is triggered, the entire game is replayed by the smart contracts using Cartesi technology, in order to verify the true result and enforce the correct outcome.
To better grasp how all of this works, let us take a look at the main building blocks of the solution:
On the client side, a Poker WebApp written in HTML/JS provides a UI for users to play the game in their own browsers. This application uses the WebAssembly build of the Poker Engine to perform the game’s logic, and uses ethers.js to communicate with the smart contracts in order to join a game and interact with it.
As described before, the TurnBasedGame smart contracts are responsible for mediating the interaction between the players. First of all, a Lobby contract allows users to be matched with each other in order to start a game. After that, all interactions within the game are mediated by the main TurnBasedGame contract.
If any player attempts to hack the client application to cheat in the game, for instance by claiming victory with a loser hand, his opponent’s application will automatically dispute the illegal move by submitting a transaction to the TurnBasedGame contract. That smart contract will then collect the entire record of player interactions, including the exchange of shuffled and encrypted decks, and send those over to the Descartes smart contract in order to trigger a computation that verifies the correct result of the game. At this point, a set of off-chain Descartes Validator Nodes will pick up the requested computation and execute it using the Poker Verifier Cartesi Machine, in such a way that an honest node is always guaranteed to enforce the correct result of the computation. This machine boots an entire RISC-V Linux OS and then executes a simple program that feeds the recorded player interactions into the Poker Engine in order to replay the whole game. It then analyzes the result to determine the final outcome to be enforced in the blockchain. In this sense, it can punish a player if he falsely claimed victory, or if an illegal move was submitted which raised an exception when replaying the game (e.g., trying to stay in the game without betting the required amount, or submitting invalid decryption keys when requested to reveal his cards).
At this point, it should be emphasized that the solution is capable of running the verification process using only the information that was already revealed during the normal course of the game, without requiring the players to disclose any additional data. This means that a player can never be forced to submit the decryption keys of his own private cards (known as “hole cards” in Texas Hold’em) in case a game is challenged. This is a crucial privacy feature for a Poker game, and is made possible by a special Mental Poker “Referee” design in which an additional deterministic participant is included in the game and used to run the verification. This will be further discussed in a later article, but the bottom line here is that the player’s private information never leaves the client’s device unless the player wants to show his cards to win the game.
If one takes a closer look at the architecture described above, it can be seen that this solution effectively decouples the logic that is specific to Poker from a more general framework that is capable of mediating and validating the results of any turn-based game.
Indeed, the only modules implemented specifically for the Texas HODL’em game consist of the Poker Engine itself and the front-facing web application used by the players. The Solidity smart contracts deployed to the blockchain are actually completely generic to any turn-based game, including the verification framework using Descartes. All that was needed to prevent misbehavior was to use the same game engine logic inside a RISC-V Cartesi Machine, which is capable of executing anything that can be run on Linux.
The direct consequence of this design is that it makes it possible to develop many other complex turn-based games by simply implementing the game’s logic (in C++, Python, or any other language of preference) and developing a corresponding UI, without having to write a single line of code in Solidity. This kind of generality is part of Cartesi’s vision to bridge the gap between blockchain applications and mainstream development practices, helping to bring millions of developers into the field, boost productivity, and open all kinds of new possibilities for decentralized apps.
First of all, it should be emphasized that Texas HODL’em is intended as a showcase of Cartesi’s technology and its potential, and is not a consumer-ready product at this stage.
The choice of implementing the client-facing front-end as a web application was done to make the game more accessible for people to experiment with, including during our MVP test event. No effort has yet been made to optimize the performance of the cryptographic algorithms in WebAssembly, and thus their performance in the browser is not ideal at this time. In that respect, it should also be noted that an alternative implementation could consider a native client application instead, which would trivially be able to run the same algorithms instantly, but would require the user to download and install software in order to play the game. In a similar spirit, we haven’t yet sharpened up the application’s UX to production level, such as minimizing interactions with Metamask when playing in the browser.
Aside from that, at the moment the Poker engine and UI are also restricted to only two players, in order to simplify the implementation process and avoid any debate about collusion among the players outside of the application. Nevertheless, it should be noted that the TurnBasedGame smart contracts do not have this limitation, already supporting games with any number of players.
Finally, a note should be made concerning the Descartes validator node topology chosen for this game. Considering the choice of having a web application with no requirements for users to install any software, the current application deployment strategy uses a quorum setup of validator nodes, in which the application itself defines the set of validators to use, and not the players. This means that when a game is challenged a set of nodes executed by third-party services will execute the computation to verify the results, taking advantage of Cartesi’s feature that if at least one of those service providers is honest then the correct outcome is guaranteed to be enforced. Alternatively, one could employ a user-centric topology setup for the game, in which the users themselves would install and run their own Descartes Validator Nodes. Although more cumbersome in some respects, this would make the solution independent of any third parties and provide full decentralization through local consensus. Cartesi’s technology is flexible enough to allow for both strategies, or even a combination of them in which users are not required to install a local node but can do so if they wish to secure the correct result themselves.
Texas HODL’em is the very first fully decentralized Poker game that runs on the Ethereum blockchain, and we believe this represents a real breakthrough achievement for blockchain applications in general. Moreover, specifically concerning the gaming industry, the proposed architecture opens up the possibility for the immediate development of a wide variety of decentralized turn-based games, from chess to complex battle strategy games, and often without needing to code a single line of Solidity. We believe this showcases the power and potential of Cartesi to help bridge the gap between blockchain development and real world applications, and bring decentralization to its full potential.
At the moment of writing, we are finalizing the integration of the Texas HODL’em web application with the other modules of the solution. Nevertheless, each part already runs by itself: the TurnBasedGame contracts trigger a verification using Descartes, the Mental Poker Engine and its cryptography can run a full game both in the browser and in a Cartesi Machine, and the application UI is ready. You can check it all out right now on Cartesi’s public repository on Github!
Furthermore, subsequent articles will present a developer-friendly deep dive into each of the solution’s modules. We will start covering the generic TurnBasedGame smart contracts, showing how one can use them to create and instantiate games — any turn-based games! Then we will follow up by exploring how the Mental Poker Engine’s cryptography works “under the hood”, including the design that allows for independent verification of a Poker game without disclosing private information. Finally, we will present the full solution in more detail, describing how one can compile and run everything locally or on Polygon’s Mumbai PoS Testnet. Stay tuned on our channels below and keep an eye out on our soon to be released landing page!
Cartesi is a multi-chain layer-2 infrastructure that allows any software developer to create smart contracts with mainstream software tools and languages they are used to while achieving massive scalability and low costs. Cartesi combines a groundbreaking virtual machine, optimistic rollups and side-chains to revolutionize the way developers create blockchain applications.