In hindsight it’s obvious that my mid-month ETA for v2.0 was just too optimistic. At this point I think we’re still looking at at least a few weeks more (end of November?), to finish up. Forward momentum continues, however, and there’s a whack of new functionality that you can find on the GitHub repository.
Interestingly, during the period between CypherPoker updates the Ethereum Foundation decided to do a hard fork in order to mitigate problems caused by under-priced operations in the Ethereum virtual machine. In effect, they’ve now created a third Ethereum blockchain, the first one being Ethereum Classic followed by the DAO hack hard fork. And it won’t be the last is the current solution is a two-parter.
My understanding of the underlying problem suggests that the issue isn’t so much the integrity of the virtual machine but rather more along the lines of a DDOS attack — everything still works, it’s just heavily bogged down. As with Classic, I’m wondering if a pre-fork Ethereum bloatchain will continue and with the second hard fork “still being discussed“, is yet another one coming?
“… valid transactions can never be erased or forgotten.”
The Ethereum Classic moto
From the technical perspective this is not a problem for CypherPoker. Support for multiple clients and versions exists now. We can switch between multiple client versions and blockchains swiftly using nothing more than a pulldown option in the user interface. Judging by the comparison between Ethereum Classic and Ethereum now (or at least very shortly ago), stakeholders seem to be willing to jump in new directions with both feet so keeping up to date on hard forks seems like the direction to move in.
Personally I’m somewhat torn, though the reasons supporting the for camp (supporting forks, new version, etc.) far outweigh those against.
On the one hand, I agree with the purist ideology of the Classic people in ensuring that the blockchain must remain the final arbiter in its domain, namely programmable smart contracts. By forking to a new chain you are effectively breaking the trust that certain transactions can’t be reversed or manipulated.
On the other hand, however, CypherPoker contracts are intended to live on the Ethereum blockchain for only a small amount of time so they’re unlikely to be affected by any forking or splitting. In fact, since I can’t see any reason why players wouldn’t be able to select which blockchain they want to play on, arguing whether to embrace new versions, forks, splits, derivatives, etc. is a bit of a moot point anyway. As long as people are able to transfer (proof of) value between various blockchains then they should be supported.
Ultimately my duty is to CypherPoker and not providing as much support for multiple blockchains / cryptocurrencies is the exact wrong direction to head in. Multitudes of software settings can be hidden behind a clever UI and well thought-out presets but they should never not be accessible or available. At least that should be the goal.
With that bit of gavelling out of the way I’m going to jump into the current spate of changes:
Libraries upated (they’re now libraries!)
All of the helper CypherPoker smart contracts have now been converted to proper Solidity libraries. To accomplish this I needed to revisit the Solidity language which has gone through many iterations since I last worked on the smart contracts. Now that I know how they work the changes to the language make sense but they required considerable tweaking of the source code.
I’m not quite finished updating all of the smart contract code but it’s in pretty good shape at this point. If you look at the header comments found in the contract source code you’ll note that I’ve included their respective Morden testnet addresses. You can use tools such as Etherscan or Ether.camp to access them and, if you’re so inclined, try them out yourself.
Along with the library deployment I’ve been keeping records of gas and Ether requirements so that I’ll have a good idea of the costs of running the various contracts when it’s time to hit the mainnet; I’ll be posting the results as soon as I’ve gathered a complete set.
Check your client at the door
Between the last update and this one the Ethereum team decided to change the format of their client (Geth) ZIP files. To address this, CypherPoker now searches within the entire ZIP for the required file and while it’s at it the SHA256 signature of the archive is also optionally verified to make sure that we have the correct, untouched code.
In the Proof-of-Concept I hard-coded much of the contract code, interfaces, and interactions. This was okay at the time when all I wanted was just to demonstrate that it can all work together but this approach is entirely insufficient for real world usage. For example, in the POC I was using an exclusive no-limit poker hand contract which, ironically, imposed limits on the kind of game that can be played.
Under new management
It’s the management of smart contract and their states that has thus far taken up the bulk of my time and attention over the past few weeks and there are some good reasons for it.
To begin with, although CypherPoker clients communicate with each other they must ultimately defer to the smart contract for an authoritative game record. Unfortunately, Ethereum is able to process new actions only once every ten to fifteen seconds which makes game play far too slow if the game client relies solely on it.
The solution lies in an automated action queue and verification system that the game client can use to interact with the Ethereum blockchain. In other words, CypherPoker must be able to continue game play while publishing and verifying updates of past game actions in the background. It must be able to do so in a way that doesn’t allow cheating or provide advantages to other players.
Additionally, contract creation should be handled in a way that promotes fast game play. For example, new games should be able to simply access existing contracts on the blockchain without having to wait for them to be deployed or mined. This means that the CypherPoker client must be able to pre-deploy game contracts in a non-intrusive way and then keep a record of available ones for future use.
Finally, all of this has to be generic enough to support not only different types of contracts but also different configurations. For example, a player may have pre-deployed some contracts on the Ethereum mainnet, others on Morden, and others on an entirely private Ethereum network.
This has introduced a new layer of complexity to the game client which I didn’t fully appreciate until I started to work on it; certainly not insurmountable, but clearly not as straightforward as I’d imagined. Nevertheless, good progress has been made and I’m hoping to be able to start sharing some actual game play contracts with you from the Morden testnet soon. I imagine that most CypherPoker contracts will have their self-destruct functions activated when complete but it would be very useful to be able to point to existing ones for explanations.
In the meantime you’re welcome to browse the existing library contracts and even make use of them if you know your way around Solidity. A couple of the more interesting ones include CryptoCards which contains the core cryptographic functionality (found at 0x07a6864227a8b03943ea4a78e9004726a9548daa), and the PokerHandAnalyzer which produces numeric scores for poker hands (found at 0x1887b0571d8e42632ca6509d31e3edc072408a90).
Finally, please leave a comment or email me (patrick (at) patrickbay (dot) ca) if you’re interested in trying out CypherPoker on the Morden testnet. I’ll be happy to send you some instructions and test Ether so that you can get a feel for what playing CypherPoker will be like when it’s ready to go live.