It has taken many years to finally be able to put together a fully decentralized system for one of the most demanding usecases, realtime poker. The final piece is a decentralized cashier, which utilizes cryptographic proofs to deposit coins, issue coins, redeem coins. While the cashier is being created specifically for poker, it can actually be used by any game that has balances tied to a player on a “table”.
First, let us start with a bit of background. I have written about CHIPS using lightening network for instant payments, that enables realtime betting. Of course, we are all familiar with CC and what it can do and with a notarized chain for the cashier, we can use nSPV for dapps to interact with the cashier chain as it is also interacting with LN network and CHIPS. Make the chain that the cashier runs on a pegged chain, backed by KMD and in effect we are able to bet USD equivalents (which are actually variable amounts of KMD adjusted per block) in a trustless way to play realtime poker.
I realize the ingredients for the decentralized cashier has a lot of components, but that is the idea of having all these components so we can put them together to make otherwise hard (impossible?) to achieve solutions.
To add one more piece to the puzzle, the decentralized cashier will actually be an instance of the cashier FSM, within the context of the FSM CC. I would imagine that this entire system combines the most different blockchain tech into a single solution. CHIPS will be needed to make the CHIPS lightning payments, KMD is needed to create the pegged USD equivalent coin and a pegged chain with FSM CC enabled is needed to deploy the cashier FSM.
If you didnt understand all that, dont worry, each of the components has one or more blog posts explaining it and you can read up on those once you have the context of the entire system. Let us look at what the cashier needs to do.
- Accept payment in USDK for a specific player pubkey on a specific table. Each table will have a chipsize variable, so $100 would get you 100 chips at a $1 table, but only 1 chip at the $100 table. Since chipsize is a table specific abstraction, the cashier just needs to know the amount deposited and be able to provide proof of deposit for the player to use at the table. To avoid fractional chips issues, the cashier will need to be told about a tables chipsize and it would only accept funds in multiples of that. Maybe any excess becomes a donation.
- The player will present proof of deposit and obtain the proportional amount of playing chips. In reality, the user would need to have opened a CHIPS LN channel to the dealer and fund it with enough CHIPS to support the gameplay. Since the LN denominations can be set to very small amounts, the same 100 CHIPS would be enough for a lot of playing. CHIPS is designed to scale to a very large number of users. Care must be taken to not allow the same proof to obtain table chips more than once, but since each cashier deposit is tied to a specific table, that just requires that each table keep track of all the txid accepted for deposits.
- Each table needs to maintain a balance for each player that is allowed to be played. The amount of CHIPS will likely be many multiples of the actual amount deposited, so the table needs to reject any attempts to spend via LN the table chips that is in excess of what the player has! This list of table balances is a critical part of the cashier protocol. Whenever the balances changes, all the players and dealer need to update the player balances and attest to the correctness. In the event that consensus cannot be achieved on this, then all play at the table needs to stop and the last achieved consensus be used for withdrawals. This drastic step is needed to have a strong reason for all nodes to agree on the table balances and for non-consensus to arise only when there is a bona fide dispute.
- At the beginning of each game, all the players know the balances of all the players. A game specific sequence of signed events happens which creates a set of changes to the player balances. Given the set of signed events, anybody can deterministically determine the new balances and all the player nodes, along with dealer and other authorized nodes would validate the new balance and attest to it. This concept of players, dealers and other nodes being able to attest to a specific game implies that when creating the deposit, the list of approved pubkeys needs to be submitted. The table (this includes all current players, dealer, approved observers) would then make sure that the list of approved pubkeys is valid. To achieve this, a table needs to be able to be queried to obtain the current list of approved pubkeys. Now, it is possible that players come and go, which means that each player would need to be able to update the list of approved pubkeys. This would require attestation by a majority of existing approved pubkeys, say N/2 + 1. That will allow the active list of approved pubkeys to constantly evolve and it is a property of the table. Changes to the approved list of pubkeys is thus attested to by the table and given the starting list of approved pubkeys and all the changes to this list as the play has proceeded will allow proof of the current approved list of pubkeys at any given point in time.
- Each table is responsible for maintaining the list of approved pubkeys along with player balances. When a player decides to cashout, he must leave the table and get an attestation from the rest of the players that he left the table at a specific timestamp with a balance of X. It is possible for an evil table to try to cheat and say that players have more balance than they actually do, however, these games are zero sum games so the total balance deposited to the table is sufficient for paying any valid amount from that table. If a table will be colluding against a specific player with N/2+1, it is like a 51% attack and this will work. It could be that the threshold needs to be set to N, where N is the number of players, but that would open the case of funds being frozen in the event any player goes missing, ie. via rage quitting. There is no need to lock in the exact MofN needed as it can be a table parameter, along with external observers. For large stakes games, it is suggested to have a relatively large number of trusted members being observers, so there can be 7 independent observers to ensure 51% attacks are not being done.
- The last thing that needs to be done is to properly handle a withdraw. The player would request the table to leave the table and at that point, the player is not able to play anymore as his table chips balance is set to zero. In exchange, the players current attested balance is generated. This means signatures from the table. The player would submit that, along with the set of approved pubkey changes the table generated for the duration of playing. Combined, this allows the cashier to verify that the player has a peer validated balance that can be withdrawn. This is the only thing that can be done with the balance and it can only be withdrawn to the players pubkey. That eliminates using valid proofs to make an invalid destination address.
Notice that there isnt any game specific information in the above and it can be applied to any type of game where funds are at stake. The generalized concepts are: approved list of pubkeys, player balances, changes to approved list of pubkeys. How the player balances change is game specific, and to a large extent so it how the validated deposits are credited. Each game needs to be responsible to have a secure way of issuing ingame credits and managing wins and losses.
Now for the hard part…
The CHIPS LN along with the poker dapp is running independently to the pegged USDK chain where the cashier FSM is running as an instance of the FSM CC. How can the poker dapp know about any cashier transactions?
The answer is via nSPV! Given a transaction, using nSPV you can verify if it happened on a chain by checking the merkleproof of a transaction and that the merkleroot it is in appears in between two notarisations, along with all the blockheaders for each block containing the two notarisations. What this means is that a cashier FSM deposit raw transaction can be verified to have been done with a relatively small amount of queries to the nSPV fullnodes. This allows validating a cashier deposit and by looking at the authorized pubkeys and table id, it can be used as credits on a specific table.
The reverse direction of providing attestations of player balances and changes to pubkeys can be put into a transaction and submitted to the USDK chain via nSPV. The set of attestations for the pubkey changes and player balance is what allows the withdraw from the cashier.
This multichain architecture can be used for a large number of usecases, certainly within the gaming context, but also for many other that requires realtime performance that is blockchain enforced. Notice that scaling is primarily a function of the number of nodes running the dapps, the actual number of cashier transactions are very few compared to the table actions.
While it would be possible to integrate all this into a single chain, the advantages that has is outweighed by the scaling problem that having a single chain doing all this would incur. By having specialized chains doing specialized things, customized solutions can be rapidly put together. There is also the practical problem of getting any established chain to add such a large amount of new functionality.
In conclusion, the komodo multichain architecture is shown to solve a previously unsolved problem of decentralized realtime gaming. Additionally, even though KMD itself is not used directly, it is required to create a pegged USDK chain, so indirectly the demand for a smart stablecoin with a built in cashier, will create demand for KMD
