At a very high level, smart contracts are essentially validators to either allow or reject certain transactions (state transitions). These validations + policies essentially encode the logic of the application.
States & state transitions are encoded by Datum and Redeemer. Of course, the validator validates this state transition.
New currency and assets can be minted or burned. The minted and the burned values are part of the transaction whose validity is checked by the associated policy (Currency hash ~ Minting policy hash).
The foundational datatype of the smart contract is essentially just the validator. Everything else is just data that the validator requires to check the validity of the transaction.
There are 2 levels of validation:
- Core validation - Rules of the blockchain
- Custom validation - Smart contract
We are more interested in custom validation, IE. validators, minting policies, etc.
The job of the application writer is to define the rules of the application and write validators such that there is no way to exploit those rules.
The job of the auditor is essentially code-review. Essentially, check if the validators written are proper and flag the validators that allow transactions that don't follow the rules.
Given my current knowledge, this is probably how I would write an application on the blockchain.
For simplicity, we can assume there are no transaction fees.
Casino where users can:
- Buy X coins for a Y Ada
- The exchange ratio is governed by the casino on a daily basis.
- Stake their coins for an on-chain guessing game with some off-chain logic
- The game is always between 2 users who choose a random number between 0 and 9
- The casino reveals the number
- The closest guess wins the entire stake
- Exchange their coins back to Ada for the same rate they purchased them.
The casino would own 1 UTXO with a datum that contains the exchange rate.
There would be a script address attached to it that validates if:
- Input:
- Reference UTXO owned by the Casino
- UTXO with a datum that has
exchange_rate - Redeemer action UPDATE_BALANCE
- Output
- New UTXO with a datum that has
exchange_rate
This ensures that the casino can always dictate the exchange rate.
Minting:
- Inputs:
- Reference UTXO owned by the Casino that dictates the
exchange_rate - User UTXO with X Ada
- Redeemer action BUY B where B is the amount of Ada the user wants to spend. (Can this action be signed by the user?)
- Output:
- Casino UTXO with B Ada
- User UTXO with Y coins respecting the exchange rate (Y coins minted)
- User UTXO with (X - B) Ada
Burning:
- Inputs:
- Reference UTXO owned by the Casino that dictates the
exchange_rate - User UTXO with Y coins
- Casino UTXO with X + K Ada
- Redeemer action SELL S where S is the amount of Coins the user wants to sell.
- Outputs:
- Casino UTXO with K Ada
- User UTXO with X Ada
- User UTXO with (Y - S) Coins. (S coins burned)
Both Alice and Bob would stake K coins at the casino. Ie. Both Alice and Bob would transfer K Coins to the Casino. Casino would then create a UTXO having "2 * K" coins for running the game.
Inputs:
- Casino UTXO with "2 * K"
- Reference Casino UTXO corresponding to Game Script Redeemer action: RUN_GAME rand_num Outputs:
- Alice UTXO with
2 * Kcoins
NOTE:
- Add limitations to the escrow - the coins should be redeemable if the game isn't played within a certain time.
- Casino acts as an escrow.
- Involving Alice and Bob (non-coordinating parties) in the game requires the transaction to be signed by both.
This is a dumb albeit a complete representation of a casino and a game.
I would like a review on how you might have done things differently, and if my understanding in general is correct.
I'm aware that there are obvious centralization issues and power imbalance between the casino and the users but writing up a better specification may take up a lot more time and effort.
The goal is to currently validate my ideas about some core concepts.
An auditor would probably bring up these centralization issues.
In hindsight, I can see that this is an ambitious example to begin with :-)
It's really hard to give a proper definition of a smart contract. From our perspective of auditors, they can be seen as a set of scripts (each of them possibly with different modes of usage) piloting the acceptance, or refusal, of any transaction involving one (or more) of those scripts in the phase 2 of the validation process.
They encode the logic of the application from the partial point of view of the UTxOs that are consumed and the tokens that are minted/burned. There is a crucial difference between the high level logic of the smart contract (the set of transactions involving at least one script of the contract that should be accepted) and the logic of the scripts themselves involved in the transaction, which, combined together, should amount to the former.
I think this is close to correct when thinking about validators (as in, scripts used in Spending purpose) but more questionable for other kinds of purposes. Also, the notion of state and transition need to be defined here.
They are indeed part of the balancing equation of the transaction, which involves a lot of things but, as a first approximation, can be expressed as:
input value + minted value = output value + burned value.That's correct smart contract on-chain are just reduced to a hash until the corresponding code is given to a transaction using it (either directly, or though a reference script), alongside a redeemer in all case, and a datum when the script is used in Spending mode. Additionally, the script also receives the full script context (which, actually, contains the datum and the redeemer) which contains all the information there is to know about the transaction being validated.