Pieces coupling

[NadigerAmit]

I'm currently working on designing the "BuyKitty" functionality, I am investigating on how to handle transactions involving two independent runtime modules—MoneyPiece and KittyPiece.

The "Buy" operation involves the buyer sending money to the seller and, upon successful validation of constraints in Money piece, transferring the kitty to the buyer based on the successful validation of constraints in Kitty piece.
However, I'm faced with the challenge of incorporating both Money and Kitty transactions within the same transaction.

The structure of the transaction is

Tuxedo/tuxedo-core/src/types.rs

Lines 20 to 45 in 36d7bac

	/// A UTXO Transaction
	///
	/// Each transaction consumes some UTXOs (the inputs) and creates some new ones (the outputs).
	///
	/// The Transaction type is generic over two orthogonal pieces of validation logic:
	/// 1. Verifier - A verifier checks that an individual input may be consumed. A typical example
	/// of a verifier is checking that there is a signature by the proper owner. Other examples
	/// may be that anyone can consume the input or no one can, or that a proof of work is required.
	/// 2. ConstraintCheckers - A constraint checker checks that the transaction as a whole meets a set of requirements.
	/// For example, that the total output value of a cryptocurrency transaction does not exceed its
	/// input value. Or that a cryptokitty was created with the correct genetic material from its parents.
	///
	/// In the future, there may be additional notions of peeks (inputs that are not consumed)
	/// and evictions (inputs that are forcefully consumed.)
	/// Existing state to be read and consumed from storage
	#[derive(Serialize, Deserialize, Default, Debug, PartialEq, Eq, Clone, TypeInfo)]
	pub struct Transaction<V, C> {
	/// Existing pieces of state to be read and consumed from storage
	pub inputs: Vec<Input>,
	/// Existing state to be read, but not consumed, from storage
	pub peeks: Vec<OutputRef>,
	/// New state to be placed into storage
	pub outputs: Vec<Output<V>>,
	/// Which piece of constraint checking logic is used to determine whether this transaction is valid
	pub checker: C,
	}

Given that OuterConstraintChecker serves as the constraint checker for the entire transaction,
I'm exploring the best approach to include both Money and Kitty inputs and execute them atomically.

Approach with Separate Constraint Checkers:
One idea is to add the coin to the KittyPiece.
Maintain separate constraint checkers for Money and Kitty transactions.
This involves duplicating the Money spending constraint checker in the Buy constraint checker of KittyPiece.

I would greatly appreciate your insights on the following:

How would you recommend handling the "Buy" operation involving both Money and Kitty transactions?

What best practices should I consider ensuring atomic execution and maintain consistency during the transaction?

[NadigerAmit]

I got a couple of advice on the above issues:

Advice from @muraca :
One option might be to have a PaidKittyConstraintChecker<const ID: u8> that consumes Coin<ID> to produce a Kitty. This would require the Kitties crate to depend on the Money crate.

Advice from @JoshOrndorff :
Make a new crate that depends on money and kitties Ex: a "BuyableKittyPiece or TradableKittyPiece".