CryptoKitties Development

Introduction

This article provides a comparative analysis for the development of a decentralised application similar to CryptoKitties, implemented on blockchains with UTXO and account-base paradigms. We compared a solution made on Ethereum (EVM), Cardano (eUTXO), Tuxedo/Polkadot (UTXO). The article highlights the distinct architectural features of each solution, identifying their pros and cons.
Particularly regarding the promising Tuxedo, we suggests potential improvements that could facilitate the solution's progress to full maturity.

CryptoKitties Architecture on EVM

The original CryptoKitties architecture combined Ethereum transactions and events with off-chain databases and queueing to create a responsive user experience, evolving over time to become more scalable and fault-tolerant. Key challenges included asynchronous transactions, event ordering, and balancing on-chain and off-chain concerns.

• Backend does the heavy lifting so frontend can focus on UI/UX
• Used RabbitMQ to queue and route smart contract events consumed by worker subscribers
• Replicated blockchain data to PostgreSQL to enable complex queries not possible on chain
• Later moved to Google Cloud Pub/Sub for scalable event ingestion across multiple projects
• Pub/Sub deliver events at least once without ordering guarantees, requiring idempotent subscriber handling
• Lack of ordering required application logic to handle out-of-order events and reconstruct intermediate states

• The smart contract allows for the creation of new kitties with unique attributes.
• Each kitty is assigned a unique identifier (ID) associated with an owner's Ethereum address.
• The contract maintains a mapping of kitty IDs to their corresponding data, such as genetic code, birthdate, and generation.

• The smart contract keeps track of the ownership of each kitty.
• Kitties can be transferred from one Ethereum address to another through the contract.
• The contract ensures that only the owner of a kitty can initiate a transfer.
• Ownership transfers are recorded on the Ethereum blockchain.

• The smart contract enables the breeding of two kitties to create a new offspring kitty.
• Each kitty has a unique genetic code that determines its appearance and traits.
• When two kitties are bred, the contract combines their genetic codes using a specific algorithm to generate the genetic code of the offspring.
• The resulting offspring kitty inherits traits from its parents based on the breeding algorithm.

• The smart contract facilitates the auction and sale of kitties.
• Owners can put their kitties up for auction or sale by specifying a price and duration.
• Interested buyers can place bids on the kitties during the auction period.
• The contract automatically transfers ownership to the highest bidder when the auction ends.

• The smart contract provides functions to retrieve information about individual kitties.
• Users can query the contract to get details such as the kitty's ID, owner, genetic code, birthdate, and generation.
• The contract may also store additional metadata about each kitty, such as its name or description.

• The smart contract enforces certain restrictions on breeding to maintain the scarcity and value of kitties.
• There may be limits on the number of offspring a kitty can produce or the frequency of breeding.
• The contract may also implement a cooldown period between breeding to prevent abuse and ensure fair participation.

• The smart contract keeps track of the generation of each kitty.
• Generation is determined by the number of breedings that occurred to create the kitty.
• Higher generation kitties may have increased rarity or unique traits.
• The contract may assign different probabilities to traits based on their rarity to create a diverse and valuable ecosystem.

• The smart contract maintains a record of the ownership history of each kitty.
• Each transfer of ownership is recorded on the Ethereum blockchain, creating an auditable trail.
• This provenance information adds value to the kitties and ensures authenticity.

CryptoKitties Architecture on Cardano

Cardano allows to leverage the benefits of its Extended UTXO (eUTXO) model and advanced smart contract system to handle various workflows encompassing kitty ownership, metadata updates, genetic breeding, sales, and auctions in a decentralized and trustless manner.

1. Kitty Representation and Ownership
   1. In Cardano, the ownership and metadata of a kitty can be handled separately by minting an NFT that can be freely transferred between the users of the platform and associating this NFT with a UTxO containing various attributes of the kitty such as name, genetic code, birthdate, generation, etc.
   2. Such an approach to handling NFT metadata is described in CIP-68 (Datum Metadata Standard). The core benefit of this method is that the metadata is inspectable from within Plutus on-chain scripts (validators and minting policies), which becomes particularly powerful with the use of reference inputs.
2. Kitty Metadata Evolution
   1. Each kitty has their kitty metadata state token, requiring that it is sent to the kitty metadata validator address along with the valid metadata UTxO locked at the address of a not parameterised metadata validator. This validator enforces different requirements for metadata state transitions which may vary depending on the specific implementation.
   2. For instance, a metadata record can include fields such as a limit on the number of offspring a kitty can produce. This number can be updated as part of the breeding transaction and verified by the corresponding branch of the metadata validator. Additionally, the validator can verify that the DNA of a newly born kitty was generated according to the predefined set of rules, ensuring the integrity of the breeding process.
3. Kitty Discoverability and Retrieval
   1. To keep track of the valid metadata entries, it’s essential for each metadata UTxO to include a state token indicating the current metadata state of the respective kitty. The presence of these state tokens is crucial for identifying valid metadata entries and distinguishing them from other UTxOs that might be arbitrarily put under the validator by anyone.
   2. To enable fast retrieval of kitties and their metadata, we can leverage Oura to build a custom indexer and serve up-to-date information regarding kitty ownership and metadata. Oura is a high-performance tool used for monitoring Cardano events and filtering them based on a set of rules. It can be used to maintain a database with relevant information about kitties, which should be made accessible to the users through a public API.
4. Auctions and Sales
   1. Given that kitty NFTs are not locked under an escrow contract and can be freely exchanged among platform users, with their metadata being detached and handled separately, it is possible to utilize existing on-chain protocols to conduct auctions and sales involving kitty NFTs.
5. Backend Services
   1. Indexer backend service for efficient kitty data retrieval.
   2. Since metadata is stored on-chain and accessible from within Plutus scripts, users can interact with smart contracts directly. This eliminates the need for a centralized oracle, making the entire protocol trustless. While the oracle backend service can still be utilised for posting regular metadata updates, it does not compromise security in any way, as smart contracts do not have branches that can only be executed by some centralized authority.
6. Onchain scripts
   1. Kitty minting policy:
      1. Mints new kitty NFT.
      2. Mints kitty metadata state token, requiring that it is sent to the kitty metadata validator address along with the valid metadata entry datum.
      3. Validates initial kitty attributes.
      4. Parameterized by a nonce UTxO to generate a unique currency symbol for kitty NFT, also requires spending of the nonce UTxO. Since Cardano does not allow double spending, it is impossible to create multiple kitty tokens sharing the same currency symbol. Consequently, this currency symbol acts as a unique identifier of a kitty and its metadata.
      5. Also parameterized by kitty metadata validator hash to be able to verify that metadata entry is sent to the right address.
   2. Kitty metadata validator
      1. Validates metadata state transitions.
      2. Contains multiple validation branches that can be selected by the user depending on the purpose of the spending transaction.
      3. Unparameterized.

CryptoKitties Architecture on Tuxedo

Tuxedo demonstrates the flexibility and adaptability of Polkadot technology by implementing UTXO as one of its paradigms. To test its performance and interact with the Polkadot ecosystem, we implemented TuxedoDapp, a full implementation of a Cryptokitties DApp. Due to the youth of Tuxedo, we had to extend its CLI wallet and integrate the web wallet Talisman (which doesn't support UTXO).
TuxedoDapp follows a layered architecture consisting of a front-end user interface, a back-end web service with a database and the Tuxedo blockchain as the underlying infrastructure. This architecture allows for a clear separation of concerns and enables scalability and maintainability of the application.

Front-end

The front-end layer is responsible for providing a user-friendly interface for interacting with the application using the Talisman Wallet. It communicates with the back-end web service to fetch and display relevant data, such as kitty details, ownership information and breeding options.

Back-end Web Service

The back-end web service acts as an intermediary between the front-end and the Tuxedo blockchain. It exposes APIs that the front-end can consume to retrieve and modify data related to kitties. The web service is responsible for handling business logic, data validation, signing, and communication with the Tuxedo blockchain.

The back-end web service maintains an embedded database that stores relevant information about kitties, such as their unique identifiers, ownership details, genetic data, and breeding history. This database is regularly synced with the latest events from the Tuxedo blockchain to ensure data consistency and provide a fast and efficient way to query and retrieve kitty data.

In addition to data management, the back-end web service also handles the creation and signing of transactions that are submitted to the Tuxedo blockchain. It securely manages the keystores associated with each user's account, allowing for the signing of transactions without exposing the private keys to the front-end or any external parties.

Tuxedo Blockchain

Tuxedo is a UTXO based blockchain platform that provides the underlying infrastructure for the application. It serves as the immutable and decentralized ledger where all kitty-related transactions and events are recorded.

The kitty data is stored as UTXOs on the Tuxedo blockchain. Each UTXO represents a specific state of each kitty, including its unique identifier, ownership, genetic data, and other relevant attributes. When a kitty is created, transferred, or bred, new UTXOs are created to reflect the updated state, while the previous UTXOs are marked as spent.

Transactions on the Tuxedo blockchain are used to perform various actions related to kitties, such as creating new kitties, transferring ownership, and breeding. These transactions are constructed by the back-end web service based on user actions and are signed using the appropriate keystores. Once signed, the transactions are broadcasted to the Tuxedo network, where they are validated and included in blocks by the consensus mechanism.

Event Syncing

To keep the back-end database in sync with the latest state of the blockchain, a regular syncing process is employed. This process involves monitoring the blockchain for relevant events, such as the creation of new kitties, ownership transfers, and breeding outcomes.

When new events are detected, the back-end web service retrieves the associated data from the blockchain and updates its local database accordingly. This ensures that the database always reflects the most up-to-date information about kitties and their ownership.

Scalability and Performance

By utilising a back-end database that is regularly synced with the Tuxedo blockchain, the application achieves better scalability and performance. The database serves as a cache layer, allowing for fast querying and retrieval of kitty data without the need to constantly interact with the blockchain network directly. The separation of concerns between the front-end, back-end, and blockchain layers also promotes scalability. The front-end can be scaled horizontally to handle increased user traffic, while the back-end can be optimized for efficient data processing and transaction management. The Tuxedo blockchain itself is designed to handle a high volume of transactions and maintain the integrity of the kitty data.

Security

Security is a critical aspect of your application's architecture. The back-end web service plays a crucial role in ensuring the security of user accounts and transactions. It employs secure key management practices, such as storing keystores in encrypted form and using secure algorithms for signing transactions.

The Tuxedo blockchain provides an immutable and tamper-proof record of all kitty-related events, making it difficult for attackers to manipulate or forge data. The decentralized nature of the blockchain ensures that the application is resistant to single points of failure and censorship.

Demo

This video shows the basic look and functionalities of TuxedoDApp.

Ethereum Account-based model
vs
Tuxedo UTXO model

Ethereum (Account-based Model)

State Management

In Ethereum, the state of each kitty is stored in a smart contract, typically as a mapping between a unique identifier and the kitty's data.
The state is updated directly in the smart contract when a kitty is created, transferred, or bred.

• The account-based model provides a more intuitive way to manage state, as each kitty has its own dedicated storage.
• State transitions are easier to reason about, as they are explicitly defined in the smart contract.

• The account-based model may face scalability issues as the number of kitties grows, as all the kitty data is stored in a single smart contract.

Transactions

In Ethereum, transactions are sent to the smart contract to perform actions like creating, transferring, or breeding kitties.

• Transactions in Ethereum are straightforward, as they directly interact with the smart contract.
• The smart contract has full control over the state transitions and can enforce complex logic and rules.

• Transactions in Ethereum can be costly in terms of gas fees, especially when the smart contract performs complex operations.

Concurrency

Ethereum follows a sequential execution model, where transactions are processed one by one in a deterministic order.

• The sequential execution model simplifies the reasoning about state transitions and helps avoid race conditions.

• The sequential execution model may limit the throughput of the application, as transactions are processed one at a time.

Tuxedo (UTXO Model)

State Management

In Tuxedo, the state of each kitty is represented as a UTXO (Unspent Transaction Output).
Each UTXO contains the kitty's data, such as its unique identifier, ownership, genetic data, and other attributes.
When a kitty is created, transferred, or bred, new UTXOs are created to represent the updated state, while the previous UTXOs are marked as spent.

• The UTXO model provides a more scalable approach to state management, as each kitty's state is independent and can be processed in parallel.
• UTXOs are immutable, making it easier to track the history and lineage of kitties.

• In the UTXO model, state transitions involve creating and consuming UTXOs. This requires careful management of input and output UTXOs to ensure the correct state is represented. Developing the logic to handle these state transitions can be more complex compared to the account-based model, where state updates are performed directly in the smart contract.

Transactions

• Transactions in the UTXO model are more lightweight and can be processed in parallel, leading to higher throughput.
• UTXOs provide a clear and auditable trail of ownership and state changes.

• Constructing transactions in the UTXO model involves selecting the appropriate input UTXOs and creating the correct output UTXOs to represent the updated state. This process can be more complex compared to the account-based model, where transactions directly interact with the smart contract.
• Developers need to ensure that the input UTXOs are correctly spent and the output UTXOs are created with the right data and ownership information.

Concurrency

• The ability to process transactions concurrently can lead to higher throughput and better scalability.

• On the application side, specifically, front-end and back-end, there can be issues with managing conflicts and ensuring data consistency. When a user interacts with the application to perform actions like breeding kitties, the front-end needs to select appropriate input UTXOs to construct the transaction. If the front-end selects incorrect or outdated UTXOs, it may lead to invalid transactions that incur unnecessary gas fees for the user or unintended state transitions. If multiple users are interacting with the same inputs, the front-end needs to handle concurrent actions and ensure that the selected input UTXOs are still valid and available. It's important to note that these challenges are not inherent to the Tuxedo blockchain itself but rather to the application layer built on top of it. Proper design and implementation of the front-end and back-end components are crucial to mitigate these challenges and ensure a consistent and reliable user experience.

Tuxedo CryptoKitties Improvements

While Tuxedo is effective, it has not yet reached the maturity required for the adoption in production.
We are eager to observe enhancements in these directions:

1. Signing - Due to the mismatch between Talisman raw signing implementation and Tuxedo Core signature verification logic, we were not able to sign in the front-end and signing is performed in the back-end with a local keystore. The DApp could be improved by resolving this issue by adding the appropriate verifier in the Tuxedo Core.
2. Light client - Right now, syncing of the blockchain state is performed in the back-end periodically every minute. This could be further improved by creating a light client in the front-end that fetches and keeps track of the blockchain state on the client side, this would also aid in the decentralization aspect of the project.
3. Indexer for efficient kitty data retrieval - Implement an indexer that listens to the Tuxedo blockchain and captures relevant events and data related to kitties. This allows the dApp to provide fast and responsive user experiences, as it can fetch kitty data from the indexed database instead of directly querying the blockchain. We could also add a caching layer for faster lookup to avoid db lookup lag, caching can be invalidated when receiving an event that indicates such.
4. The breeding and genetic algorithm could be optimised to create more diverse and interesting kitty offspring. Adding new traits and attributes could enhance the breeding experience while maintaining the desired level of rarity and uniqueness.
5. User experience and engagement could be improved with the introduction of transaction tracking. Right now, the DApp has no way to know when a transaction has been processed or finalised and there’s no feedback to the user.
6. Build a smart contract functionality into Tuxedo Core - rules and constraints for kitty creation, ownership transfer, breeding and other actions can be moved into the smart contract. If Tuxedo had a smart contract capability, the DApp would be a lot leaner and we would no longer need to have a separate back-end that submits transactions to the blockchain. Instead, we would just need an indexer to keep track of UTXO inputs and kitties.
7. UTXO metadata standard - Introduce a comprehensive standard describing how UTxO metadata should be handled. The approach presented in the Cardano section involves maintaining two separate UTxOs: one for tracking kitty ownership and another for metadata, as described in CIP-68 (Cardano Improvement Proposal 68: Datum Metadata Standard). A comparable standard could be developed for Tuxedo, offering a robust framework for handling metadata uniformly within the UTxO model.
8. Reference Inputs - Add support for a special kind of transaction inputs that are accessible to smart contracts but not spent as part of the transaction. This feature can be particularly useful to make kitty UTxOs inspectable from within smart contracts without unnecessarily recreating UTxOs in each transaction, facilitating proof of ownership for breeding and other actions.