Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TradableKitty piece #171

Open
wants to merge 16 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions tuxedo-template-runtime/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ money = { default-features = false, path = "../wardrobe/money" }
poe = { default-features = false, path = "../wardrobe/poe" }
runtime-upgrade = { default-features = false, path = "../wardrobe/runtime_upgrade" }
timestamp = { default-features = false, path = "../wardrobe/timestamp" }
tradable-kitties = { default-features = false, path = "../wardrobe/tradable_kitties" }
tuxedo-core = { default-features = false, path = "../tuxedo-core" }

# Parachain related ones
Expand Down
9 changes: 7 additions & 2 deletions tuxedo-template-runtime/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,7 @@ pub use money;
pub use poe;
pub use runtime_upgrade;
pub use timestamp;
pub use tradable_kitties;

/// Opaque types. These are used by the CLI to instantiate machinery that don't need to know
/// the specifics of the runtime. They can then be made to be agnostic over specific formats
Expand Down Expand Up @@ -169,7 +170,9 @@ pub enum OuterConstraintChecker {
/// Checks monetary transactions in a basic fungible cryptocurrency
Money(money::MoneyConstraintChecker<0>),
/// Checks Free Kitty transactions
FreeKittyConstraintChecker(kitties::FreeKittyConstraintChecker),
FreeKitty(kitties::FreeKittyConstraintChecker),
/// Checks tradable Kitty transactions
TradableKitty(tradable_kitties::TradableKittyConstraintChecker<0>),
/// Checks that an amoeba can split into two new amoebas
AmoebaMitosis(amoeba::AmoebaMitosis),
/// Checks that a single amoeba is simply removed from the state
Expand Down Expand Up @@ -204,7 +207,9 @@ pub enum OuterConstraintChecker {
/// Checks monetary transactions in a basic fungible cryptocurrency
Money(money::MoneyConstraintChecker<0>),
/// Checks Free Kitty transactions
FreeKittyConstraintChecker(kitties::FreeKittyConstraintChecker),
FreeKitty(kitties::FreeKittyConstraintChecker),
/// Checks Paid Kitty transactions
TradableKitty(tradable_kitties::TradableKittyConstraintChecker<0>),
/// Checks that an amoeba can split into two new amoebas
AmoebaMitosis(amoeba::AmoebaMitosis),
/// Checks that a single amoeba is simply removed from the state
Expand Down
214 changes: 183 additions & 31 deletions wardrobe/kitties/src/lib.rs
Original file line number Diff line number Diff line change
@@ -1,18 +1,48 @@
//! An NFT game inspired by cryptokitties.
//! This is a game which allows for kitties to be bred based on a few factors
//! 1.) Mom and Tired have to be in a state where they are ready to breed
//! 2.) Each Mom and Dad have some DNA and the child will have unique DNA combined from the both of them
//! Linkable back to the Mom and Dad
//! 3.) The game also allows Kitties to have a cooling off period inbetween breeding before they can be bred again.
//! 4.) A rest operation allows for a Mom Kitty and a Dad Kitty to be cooled off
//! An NFT game inspired by Cryptokitties.
//! In this game, Kitties can be created, bred or renamed.
//! In this game, Kitties can be created, bred or renamed.
//!
//! In order to submit a valid transaction you must strutucture it as follows:
//! 1.) Input must contain 1 mom and 1 dad
//! 2.) Output must contain Mom, Dad, and newly created Child
//! 3.) A child's DNA is calculated by:
//! ## Features
//!
//! - **Create:** Generate new kitties from scratch.
//! To submit a valid transaction for creating kitties, adhere to the following structure:
//! - **Create:** Generate new kitties from scratch.
//! To submit a valid transaction for creating kitties, adhere to the following structure:
//! 1. The input must be empty.
//! 2. The output must contain only the newly created kitties.
//! 2. The output must contain only the newly created kitties.
//!
//! **Note 1:** Multiple kitties can be created at the same time in the same transaction.
//!
//! - **Update Name:** Modify the name of one or more kitties.
//! To submit a valid transaction for updating some kitties' names, adhere to the following structure:
//! 1. The input must be the kitties to update.
//! 2. The output must contain the kitties with the updated names.
//! - **Update Name:** Modify the name of one or more kitties.
//! To submit a valid transaction for updating some kitties' names, adhere to the following structure:
//! 1. The input must be the kitties to update.
//! 2. The output must contain the kitties with the updated names.
//!
//! **Note 1:** All other properties, such as DNA, parents, free breedings, etc., must remain unaltered in the output.
//! **Note 2:** The input and output kitties must follow the same order.
//!
//! - **Breed:** Breed a new kitty using Mom and Dad based on the factors below:
//! - **Breed:** Breed a new kitty using Mom and Dad based on the factors below:
//! 1. Mom and Dad have to be in a state where they are ready to breed.
//! 2. The child's unique DNA combined from Mom's and Dad's, linkable back to them.
//! 2. The child's unique DNA combined from Mom's and Dad's, linkable back to them.
//! 3. The game also allows kitties to have a cooling-off period in between breeding before they can be bred again.
//! 4. A rest operation allows for a Mom Kitty and a Dad Kitty to cool off.
//!
//! In order to submit a valid breed transaction, you must structure it as follows:
//! 1. The input must contain 1 Mom and 1 Dad, in a `RearinToGo` state.
//! 2. The output must contain Mom, Dad, and the newly created Child. Mom and Dad's state must be updated to `HadBirthRecently` and `Tired`.
//! 1. The input must contain 1 Mom and 1 Dad, in a `RearinToGo` state.
//! 2. The output must contain Mom, Dad, and the newly created Child. Mom and Dad's state must be updated to `HadBirthRecently` and `Tired`.
//! 3. A child's DNA is calculated by:
//! BlakeTwo256::hash_of(MomDna, DadDna, MomCurrNumBreedings, DadCurrNumberBreedings)
//!
//! There are a only a finite amount of free breedings available before it starts to cost money
//! There are only a finite amount of free breedings available before it starts to cost money
//! to breed kitties.

#![cfg_attr(not(feature = "std"), no_std)]
Expand All @@ -36,6 +66,10 @@ use tuxedo_core::{
#[cfg(test)]
mod tests;

/// The main constraint checker for the kitty piece. Allows the following:
/// Create: Allows the creation of a kitty without parents. Multiple kitties can be created in the same transaction.
/// UpdateKittiesName: Allows updating the names of the kitties. Multiple kitty names can be updated in the same transaction.
/// Breed: Allows the breeding of kitties.
#[derive(
Serialize,
Deserialize,
Expand All @@ -50,8 +84,16 @@ mod tests;
Debug,
TypeInfo,
)]
pub struct FreeKittyConstraintChecker;
pub enum FreeKittyConstraintChecker {
/// Transaction that creates a kitty without parents. Multiple kitties can be created at the same time
Create,
/// Transaction that updates kitty names. Multiple kitty names can be updated. Input and output must follow the same order
UpdateKittiesName,
/// Transaction where kitties are consumed, and a new family (parents: mom, dad, and child) is created.
Breed,
}

/// Dad Kitty's breeding status.
#[derive(
Serialize,
Deserialize,
Expand All @@ -69,10 +111,14 @@ pub struct FreeKittyConstraintChecker;
)]
pub enum DadKittyStatus {
#[default]
/// Can breed.
RearinToGo,
/// Can't breed due to tiredness.
/// Can't breed due to tiredness.
Tired,
}

/// Mom Kitty's breeding status.
#[derive(
Serialize,
Deserialize,
Expand All @@ -90,10 +136,14 @@ pub enum DadKittyStatus {
)]
pub enum MomKittyStatus {
#[default]
/// Can breed.
RearinToGo,
/// Can't breed due to a recent delivery of kittens.
HadBirthRecently,
}

/// The parent structure contains 1 Mom Kitty and 1 Dad Kitty.
/// The parent structure contains 1 Mom Kitty and 1 Dad Kitty.
#[derive(
Serialize,
Deserialize,
Expand Down Expand Up @@ -146,6 +196,12 @@ impl Default for Parent {
)]
pub struct KittyDNA(pub H256);

/// Kitty data contains basic information such as below:
/// parent: 1 mom kitty and 1 dad kitty.
/// free_breedings: Maximum free breeding allowed for a kitty.
/// dna: It's unique per kitty.
/// num_breedings: Current count of remaining free breedings.
/// name: Name of kitty.
#[derive(
Serialize,
Deserialize,
Expand All @@ -165,6 +221,7 @@ pub struct KittyData {
pub free_breedings: u64, // Ignore in breed for money case
pub dna: KittyDNA,
pub num_breedings: u128,
pub name: [u8; 4],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, I think the fields should follow a more logical order, such as:

  • DNA
  • Name
  • Parents
  • free_breedings
  • num_breedings

Copy link
Contributor Author

@NadigerAmit NadigerAmit Mar 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is generally better to add new members at the end of a struct. This practice aligns with the principle of maintaining backward compatibility. When we add a new member at the end of the struct, existing code that uses the struct won't be affected, as the layout of the existing members remains unchanged.

If you add a new member in the middle of a struct, it can break existing code that relies on the order and size of the struct members. This is because the memory layout of the struct may change, leading to potential issues with code that assumes a specific order or size.

By appending new members at the end, we follow a practice commonly referred to as "struct versioning" or "extensible struct pattern," where you ensure that new fields are added without affecting the existing layout. This helps in maintaining compatibility and minimizes the risk of introducing errors in the existing codebase.

As of now, I don't see any code which is relying on the layout of the structure.
If it is a strong request, I will update it. Otherwise, I want to keep it as it is.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is generally better to add new members at the end of a struct. This practice aligns with the principle of maintaining backward compatibility.

Although you are not wrong, at this stage of the development we don't need to care about this, and we should prioritize doing stuff that makes sense and is clear and understandable.

And sometimes, you do want to break compatibility.

Copy link
Contributor Author

@NadigerAmit NadigerAmit Mar 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I updated the struct as you suggested.

}

impl KittyData {
Expand All @@ -187,7 +244,7 @@ impl KittyData {
v,
)
.into()],
checker: FreeKittyConstraintChecker.into(),
checker: FreeKittyConstraintChecker::Create.into(),
}
}
}
Expand All @@ -199,6 +256,7 @@ impl Default for KittyData {
free_breedings: 2,
dna: KittyDNA(H256::from_slice(b"mom_kitty_1asdfasdfasdfasdfasdfa")),
num_breedings: 3,
name: *b"kity",
NadigerAmit marked this conversation as resolved.
Show resolved Hide resolved
}
}
}
Expand All @@ -207,6 +265,7 @@ impl UtxoData for KittyData {
const TYPE_ID: [u8; 4] = *b"Kitt";
}

/// Reasons that kitty opertaion may go wrong.
#[derive(
Serialize,
Deserialize,
Expand Down Expand Up @@ -261,9 +320,25 @@ pub enum ConstraintCheckerError {
TooManyBreedingsForKitty,
/// Not enough free breedings available for these parents.
NotEnoughFreeBreedings,
/// The transaction attempts to create no Kitty.
CreatingNothing,
/// Inputs (Parents) are not required for kitty creation.
CreatingWithInputs,
/// The number of inputs does not match the number of outputs for a transaction.
NumberOfInputOutputMismatch,
/// DNA mismatch between input and output.
DnaMismatchBetweenInputAndOutput,
/// Name is not updated
KittyNameUnAltered,
/// Kitty FreeBreeding cannot be updated.
FreeBreedingCannotBeUpdated,
/// Kitty NumOfBreeding cannot be updated.
NumOfBreedingCannotBeUpdated,
/// Gender cannot be updated.
KittyGenderCannotBeUpdated,
}

trait Breed {
pub trait Breed {
/// The Cost to breed a kitty if it is not free.
const COST: u128;
/// Number of free breedings a kitty will have.
Expand Down Expand Up @@ -500,28 +575,105 @@ impl TryFrom<&DynamicallyTypedData> for KittyData {

impl SimpleConstraintChecker for FreeKittyConstraintChecker {
type Error = ConstraintCheckerError;
/// Checks:
/// - `input_data` is of length 2
/// - `output_data` is of length 3
///

fn check(
&self,
input_data: &[DynamicallyTypedData],
_peeks: &[DynamicallyTypedData],
output_data: &[DynamicallyTypedData],
) -> Result<TransactionPriority, Self::Error> {
// Input must be a Mom and a Dad
ensure!(input_data.len() == 2, Self::Error::TwoParentsDoNotExist);

let mom = KittyData::try_from(&input_data[0])?;
let dad = KittyData::try_from(&input_data[1])?;
KittyHelpers::can_breed(&mom, &dad)?;

// Output must be Mom, Dad, Child
ensure!(output_data.len() == 3, Self::Error::NotEnoughFamilyMembers);

KittyHelpers::check_new_family(&mom, &dad, output_data)?;
match &self {
Self::Create => {
// Ensure that no inputs are being consumed.
ensure!(
input_data.is_empty(),
ConstraintCheckerError::CreatingWithInputs
);

// Ensure that at least one kitty is being created.
ensure!(
!output_data.is_empty(),
ConstraintCheckerError::CreatingNothing
);

// Ensure the outputs are the right type.
for utxo in output_data {
let _utxo_kitty = utxo
.extract::<KittyData>()
.map_err(|_| ConstraintCheckerError::BadlyTyped)?;
}
Ok(0)
Comment on lines +586 to +605
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we somehow check that a Kitty with the same DNA does not exist?
cc @JoshOrndorff

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one of the reasons I didn't like minting kitties from scratch

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I raised this question earlier with Joshy and found that no need to check for duplicate DNA check since there can be twin kitties with duplicate DNA. So I removed the duplicate DNA check.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we state in multiple parts of the documentation that DNA is unique 😄

As far as I remember, the twins use-case was not initially part of Kitties, what's the reason behind adding it?

Moreover, twins in my opinion should not have the exact same DNA, as it is also in real life

Copy link
Contributor Author

@NadigerAmit NadigerAmit Mar 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@muraca
Please see the discussion here: #171 (comment)
Earlier I implemented the DNA check for create operation and other operations also.
There were 2 options from Joshy either "universal creator pattern" or allow duplicate DNA : I chose the 2nd option i.e allow duplicate DNA kitties.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a call recently, I encouraged @NadigerAmit to design the game fully before trying to build it and get a PR approved. Specifically I encouraged him to consider:

  1. Who is going to be able to mint in production? Only a centralized team? Or any rando? How will minting be sybil resistant?
  2. Should every kitty have unique DNA? If so implement a universal creator pattern as shown in NFT with Royalties piece #185 .

I don't think there are right vs wrong answers. But you need a design and you need to be consistent about it. I worry we reached a point where Amit feels very "close" to getting this PR merged, but I feel the design work isn't even done to compare the code against.

}
Self::Breed => {
// Check that we are consuming at least one input.
ensure!(input_data.len() == 2, Self::Error::TwoParentsDoNotExist);

let mom = KittyData::try_from(&input_data[0])?;
let dad = KittyData::try_from(&input_data[1])?;
KittyHelpers::can_breed(&mom, &dad)?;
// Output must be Mom, Dad, and Child.
ensure!(output_data.len() == 3, Self::Error::NotEnoughFamilyMembers);
KittyHelpers::check_new_family(&mom, &dad, output_data)?;
Ok(0)
}
Self::UpdateKittiesName => {
can_kitties_name_be_updated(input_data, output_data)?;
Ok(0)
}
}
}
}

Ok(0)
/// Checks if input and output contain a list of KittyData in the same order.
/// The KittyData in the output list can have different names from the inputs, but other properties must be unmodified.
pub fn can_kitties_name_be_updated(
input_data: &[DynamicallyTypedData],
output_data: &[DynamicallyTypedData],
) -> Result<TransactionPriority, ConstraintCheckerError> {
ensure!(
input_data.len() == output_data.len() && !input_data.is_empty(),
{ ConstraintCheckerError::NumberOfInputOutputMismatch }
);

for (input, output) in input_data.iter().zip(output_data.iter()) {
let utxo_input_kitty = input
.extract::<KittyData>()
.map_err(|_| ConstraintCheckerError::BadlyTyped)?;

let utxo_output_kitty = output
.extract::<KittyData>()
.map_err(|_| ConstraintCheckerError::BadlyTyped)?;

check_kitty_name_update(&utxo_input_kitty, &utxo_output_kitty)?;
}
Ok(0)
}

/// Checks if only the name is updated, and other basic properties remain the same.
/// Checks if only the name is updated, and other basic properties remain the same.
fn check_kitty_name_update(
original_kitty: &KittyData,
updated_kitty: &KittyData,
) -> Result<TransactionPriority, ConstraintCheckerError> {
ensure!(
original_kitty.dna == updated_kitty.dna,
ConstraintCheckerError::DnaMismatchBetweenInputAndOutput
);
ensure!(
original_kitty != updated_kitty,
ConstraintCheckerError::KittyNameUnAltered
);
ensure!(
original_kitty.free_breedings == updated_kitty.free_breedings,
ConstraintCheckerError::FreeBreedingCannotBeUpdated
);
ensure!(
original_kitty.num_breedings == updated_kitty.num_breedings,
ConstraintCheckerError::NumOfBreedingCannotBeUpdated
);
ensure!(
original_kitty.parent == updated_kitty.parent,
ConstraintCheckerError::KittyGenderCannotBeUpdated
);
Comment on lines +658 to +677
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoshOrndorff do you think we should encourage this approach of multiple errors and verbosity?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it is preferable to provide a more granular error message, specifying the reason for the issue. High-level errors like 'BasicPropertiesAltered' may not offer sufficient information to developers, especially when dealing with multiple properties, making it challenging to discern the exact nature of the problem.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not necessarily against this, but I think there should be some clear guidelines in Tuxedo, as sometimes we did the opposite

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have an opinion. I'm fine to try it out this way and see what is better for downstream devs and end users.

Ok(0)
}
Loading