Cheshire: a CryptoKitties developer sandbox
In September 2017, Axiom Zen drafted ERC-721, the influential non-fungible token standard that, as CryptoKitties took off with over $20M USD in sales (and counting), proved to be the second major use case for smart contracts.
CryptoKitties’s success sparked an explosion of creative and entrepreneurial activity. We joined the fracas with KittyRace, a dApp that enjoyed a couple-week run at the top of the blockchain gaming charts.
Reflecting on our experience building KittyRace, we realized that a significant proportion of our engineering effort was spent mimicking CryptoKitties’s API and smart contracts in our local development environments. Setting up a realistic development environment is always worthwhile, but it can be a lot of work when a service provider doesn’t provide a sandbox — especially when that service provider is a dApp.
Why doesn’t CryptoKitties host a sandbox environment?
The short answer is that it’s just too early for CryptoKitties to invest in the build-out and operational overhead of maintaining a sandbox, a significantly more complex effort for a dApp than a traditional web service.
Unlike traditional web services, a dApp’s application state exists largely in an environment beyond its creator’s control: the Ethereum blockchain. Sandboxing a dApp like CryptoKitties would require CryptoKitties to:
- Maintain a private Ethereum testnet for each developer
- Keep the testnet in sync with a sandboxed version of the web app
- Build tools that let developers manipulate system state
Since the CryptoKitties developer community is still emerging, CryptoKitties understandably hasn’t yet needed to provide a hosted development sandbox. This meant we had to create our own.
The recipe for a CryptoKitties sandbox
KittyRace has several important flows we wanted to be perfect. With the amount of iteration it would take to fine-tune them, we knew it had to be fast and easy to:
- Provision Ethereum accounts with plenty of ETH
- Deploy the KittyRace contract alongside the CryptoKitties contracts
- Mine blocks on demand
- Import kitties from mainnet, including their genes (stored in the KittyCore smart contract) and metadata (names, bios, colors, images, etc., all stored in the web tier)
- Create kitties carrying specific genes, such as dominant Lucky Stripe
- Access the kitties we created locally with the same interfaces we’d use in production
- Scaffold specific scenarios and resources, such as a race with 0–10 entrants, or a user account owning 0, 1, 10, or 20 kitties
- Reset the entire system to a state with nothing more than the Genesis Kitty
What we ended up creating to meet these needs was our very own local implementation of CryptoKitties. Our system combined:
- A local Ethereum testnet running slightly modified versions of the CryptoKitties smart contracts (thanks to the excellent Truffle Framework)
- A local HTTP server running a minimal implementation of the CryptoKitties web API
- A simple framework for seeding the system and KittyRace with realistic data
These three ingredients let us simulate almost any possible KittyRace scenario with the same outcomes we would encounter in production. This was an enormous productivity gain and direct contributor to KittyRace’s polish.
Cheshire: a sandbox for CryptoKitties dApp developers
To spur the growth of CryptoKitties and other NFTs, and to spare other CryptoKitties dApp developers from duplicating our efforts themselves, we’ve extracted and open-sourced these tools and patterns into a standalone package.
We call it Cheshire.
Cheshire is what we wished existed when we started KittyRace: a local implementation of CryptoKitties with the flexibility and control you need to rapidly iterate on a dApp.
And early feedback is positive!
This is going to save me a lot of ETH now that I don’t have to test on the main net ❤️❤️❤️❤️— Jesse Buonanno
Cheshire has simplified and accelerated development at Endless Nameless, and we think it will do the same for the rest of the #kittyverse. We’re excited to share it.
