Ongoing Chialisp Development

I’ve been working lately on implementing on-chain gaming in Chialisp. Since on-chain costs and latency are very high this requires optimization at all levels:

• Only two players are supported. Multiplayer creates problems in all aspects of implementation and practice.

• The games supported have very few turns total. It turns out Poker is a good fit because it’s designed to allow people to rage quit in the middle of sessions, so a cash game is a series of very short games instead of a single long one.

• Play on chain is inside of a ‘referee’ which accepts moves and states optimistically. When a player misbehaves the other player can provide evidence of their cheating and have the referee slash them. This is the only time the rules of the game are actually invoked on chain. Usually the evidence of cheating is just pointing out what rule was violated, but there are other things like invoking the dictionary in a word game.

• Instead of hands being played on chain they’re done over a payment channel. This way play can be done at very low latency and cost.

Combining all of those makes for a gaming experience which actually makes sense. It also involves making state channels, which is good because this exercise is partially an excuse to work on state channels with a real use case to see what functionality makes sense. The minimum viable product of a payment channel network involves quite a bit of real world infrastructure and relationships, but the MVP of gaming while it’s more technically complex only requires two people who want to play. If every session is done over an ephemeral channel that requires a minute to set up at the beginning (assuming it’s on Chia) which is no big deal. Later on a state channel network can be created to get rid of that start-up time.

In service of this I’ve put together an initial suite of games which is meant to hash out different edge cases of implementation details while being based on proven concepts mostly only changed to adapt them to the medium. Here is the current list:

• A game similar to closed Chinese Poker but which has fewer round trips and is a bit more of a real game. This is the simplest game and meant to test out the minimal edge cases along with forcing fleshing out of Chialisp itself with support for evaluating Poker hands.

• A two-player variant of Wordle where one player picks a word and the other tries to guess it. To make it more of a real game I’m throwing in something similar to a doubling cube. This requires pulling in of outside evidence from the dictionary which hits some very important edge cases. This has the gameplay benefit of play being extremely fast.

• A Poker variant. It turns out the hardest part of adapting it is getting a hidden permutation working. My current plan is the simple approach of changing the rules so duplicate cards are simply allowed. To keep the complexity down suits are then thrown out, resulting in no more flushes but five of a kind being possible. To get some of the gameplay involved in hole cards being suited back there’s an additional bit of hidden information which comes with hole cards which is whether they’re ‘boosted’, which has a one in three chance of being true and serves as the first tiebreak after hand type. Boosting has similar gameplay effects to cards being suited but is relevant in many more circumstances. Hopefully this is a net positive for gameplay but obviously is likely to be controversial. I may also change the play order so whoever was the last aggressor is out of position on each round, just because it reduces the total number of turns.

Usually people implement random permutations using zero knowledge stuff but that appears to be a poor fit here because it’s putting some very expensive stuff on chain. Much more expedient would be to have both players reveal their commits before a hand even starts then do a multi-party computation to determine if that results in a card collision and if so cancel the hand. Otherwise it’s played out and the cards magically don’t come out as duplicates. That adds literally zero on-chain costs and only results in cancelling about half the hands for Hold’em because it’s nine cards out of a 52 card deck. I’m currently researching what available libraries are and how to use them and it may be practical but is a bit of a project.

There may be other games worth supporting, for example Liar’s Poker, but that doesn’t seem to be played very often and there isn’t an obvious canonical set of rules, especially for only two people. Much as I like the game designer indulgence of getting people to play games which I make up I’m running a crypto company not a game company and need to be responsible about sticking as much as possible to proven formulas with justifiable tweaks to adapt them to the medium and (hopefully) enhance gameplay.

Having a bit more experience with Chialisp development now it’s becoming clearer how it compares to Solidity development. One very in-your-face aspect of it is that it forces the usage of the most reentrancy resistant design patterns possible. This is obviously a good thing. It forces a fair amount of pain up front but even total Solidity-heads are in favor of everyone being forced to do that properly. Another big change is how capabilities are handled. In Chialisp everyone carries around their certificates with them and proves their authenticity using backwards-pointing covenants. This requires some tricks which are currently quite unconventional to keep the certificates, but makes checking them trivial and super reliable. Solidity on the other hand requires checking capabilities with third party contracts, which is ugly and awkward and involves relying on an API with bespoke implementations instead of a standard audited piece of code. This is a much less clear tradeoff with obvious benefits and downsides, the main downside being that the techniques for maintaining certifications are currently not widely understood, but we’re working on that. That relates to the other big difference which is that the tooling and environment of Solidity is much more mature than Chialisp. That is improving rapidly and in not too long will be at the point where people who wish to do something can simply start writing code, but it isn’t there yet. On the plus side even today writing actually secure and auditable code in Chialisp is easier than in Solidity because mistakes tend to make things simply fail rather than having security problems. But we aspire to make it more convenient in all ways so there’s still much work to be done.