refactor: update code blocks to use Aiken syntax highlighting in smart contract section

Author: 0xBora

docs/smart-contracts/lessons/03-aiken-contracts.md

@@ -109,7 +109,7 @@ Minting script validation logic is triggered when assets are minted or burned un
 
 Example: `/aiken-workspace/validators/mint.ak`:
 
-```rust
+```aiken
 use cardano/assets.{PolicyId}
 use cardano/transaction.{Transaction, placeholder}
 
@@ -135,7 +135,7 @@ This script compiles into a script with hash `def68337867cb4f1f95b6b811fedbfcdd7
 
 Upgrade the script to allow minting/burning only when signed by a specific key:
 
-```rust
+```aiken
 validator minting_policy(owner_vkey: VerificationKeyHash) {
   mint(_redeemer: Data, _policy_id: PolicyId, tx: Transaction) {
     key_signed(tx.extra_signatories, owner_vkey)
@@ -154,7 +154,7 @@ validator minting_policy(owner_vkey: VerificationKeyHash) {
 
 Extend the policy to include a redeemer specifying the transaction action (minting or burning):
 
-```rust
+```aiken
 pub type MyRedeemer {
   MintToken
   BurnToken
@@ -187,7 +187,7 @@ Spending script validation is triggered when a UTXO is spent in the transaction.
 
 Example: `/aiken-workspace/validators/spend.ak`:
 
-```rust
+```aiken
 pub type Datum {
   oracle_nft: PolicyId,
 }
@@ -226,7 +226,7 @@ Withdrawal script validation is triggered when withdrawing from a reward account
 
 Example: `/aiken-workspace/validators/withdraw.ak`:
 
-```rust
+```aiken
 use aiken/crypto.{VerificationKeyHash}
 use cardano/address.{Credential, Script}
 use cardano/certificate.{Certificate}

docs/smart-contracts/lessons/04-contract-testing.md

@@ -26,7 +26,7 @@ We will enhance the withdrawal contract from the previous lesson to include two
 
 ### Contract Code
 
-```rust
+```aiken
 use aiken/crypto.{VerificationKeyHash}
 use cardano/address.{Address, Credential}
 use cardano/assets.{PolicyId}
@@ -100,7 +100,7 @@ In the last line of `ContinueCounting` branch, you may notice the use of `?` ope
 
 We complete the contract by validating inputs and outputs:
 
-```rust
+```aiken
 use aiken/crypto.{VerificationKeyHash}
 use cardano/address.{Address, Credential}
 use cardano/assets.{PolicyId, without_lovelace}
@@ -206,7 +206,7 @@ In Aiken, we can build testing functions with `test` keyword, followed by runnin
 
 The vanilla example:
 
-```rust
+```aiken
 test always_true() {
   True
 }
@@ -220,7 +220,7 @@ With `aiken check`, we will see:
 
 In our complex withdrawal contract, we have a `publish` function that always returns `True`. We can write a test for it:
 
-```rust
+```aiken
 use mocktail.{complete, mock_utxo_ref, mocktail_tx}
 
 test test_publish() {
@@ -238,7 +238,7 @@ In this test, we call the `publish` function of our contract with mock parameter
 
 For the rest of script purposes, it will fallback to the `else` branch which always fails. We can write a test for it:
 
-```rust
+```aiken
 test test_else() fail {
   complex_withdrawal_contract.else(
     "",
@@ -263,7 +263,7 @@ You will notice the `withdraw` function is validated the `Transaction` mostly, t
 
 In `vodka`, the `mocktail` module provides a set of functions to create mock data for testing Aiken contracts. We can use `mocktail_tx()` to create a mock `Transaction` and then use various functions to modify the transaction to fit our test case.
 
-```rust
+```aiken
 const mock_oracle_nft = mock_policy_id(0)
 
 const mock_oracle_address = mock_script_address(0, None)
@@ -323,7 +323,7 @@ We can import all the `mock_...` functions from `mocktail` module to build up th
 
 Now we can write a test for `ContinueCounting` action:
 
-```rust
+```aiken
 test success_continue_counting() {
   complex_withdrawal_contract.withdraw(
     mock_oracle_nft,
@@ -338,7 +338,7 @@ test success_continue_counting() {
 
 In the mocktail transaction building methods, we can pass a boolean parameter to indicate whether we want the field to be present or not. This allows us to dynamically create failure cases by omitting certain fields.
 
-```rust
+```aiken
 type ContinueCountingTest {
   is_ref_input_presented: Bool,
   is_thread_input_presented: Bool,
@@ -395,7 +395,7 @@ fn mock_continue_counting_tx(test_case: ContinueCountingTest) -> Transaction {
 
 And we update the successful test accordingly:
 
-```rust
+```aiken
 test success_continue_counting() {
   let test_case =
     ContinueCountingTest {
@@ -418,7 +418,7 @@ test success_continue_counting() {
 
 And we can populate the failure cases at ease:
 
-```rust
+```aiken
 test fail_continue_counting_no_ref_input() fail {
   let test_case =
     ContinueCountingTest {

docs/smart-contracts/lessons/05-avoid-redundant-validation.md

@@ -122,7 +122,7 @@ Let's assume we have all the common logics checked in the lesson 4's withdrawal
 
 ### Spending
 
-```rust
+```aiken
 use aiken/crypto.{ScriptHash}
 use cardano/transaction.{OutputReference, Transaction}
 use cocktail.{withdrawal_script_validated}
@@ -150,7 +150,7 @@ validator spending_logics_delegated(
 
 ### Minting
 
-```rust
+```aiken
 use aiken/crypto.{ScriptHash}
 use cardano/assets.{PolicyId}
 use cardano/transaction.{Transaction}

docs/smart-contracts/lessons/07-vesting.md

@@ -30,7 +30,7 @@ The datum serves as the configuration for the vesting contract. It includes:
 
 First, we define the datum's shape, as this datum serves as configuration and contains the different parameters of our vesting operation.
 
-```rust
+```aiken
 pub type VestingDatum {
   /// POSIX time in milliseconds, e.g. 1672843961000
   lock_until: Int,
@@ -45,7 +45,7 @@ This datum can be found in `aiken-vesting/aiken-workspace/lib/vesting/types.ak`.
 
 Next, we define the spend validator.
 
-```rust
+```aiken
 validator vesting {
   spend(
     datum_opt: Option<VestingDatum>,

docs/smart-contracts/lessons/08-plutus-nft.md

@@ -23,7 +23,7 @@ The oracle NFT acts as the single source of truth for the system. It uses a stat
 
 The following code defines the minting policy for the oracle NFT:
 
-```rust
+```aiken
 pub type MintPolarity {
   RMint
   RBurn
@@ -66,7 +66,7 @@ The oracle validator holds the current state of the NFT index. It defines the da
 
 ### Datum Definition
 
-```rust
+```aiken
 pub type OracleDatum {
   count: Int,
   lovelace_price: Int,
@@ -76,7 +76,7 @@ pub type OracleDatum {
 
 ### Redeemer Types
 
-```rust
+```aiken
 pub type OracleRedeemer {
   MintPlutusNFT
   StopOracle
@@ -87,7 +87,7 @@ pub type OracleRedeemer {
 
 The validator ensures the state changes are valid:
 
-```rust
+```aiken
 validator oracle {
   spend(
     datum_opt: Option<OracleDatum>,
@@ -114,7 +114,7 @@ In this setup, we identified the own input with `find_input` function, which is
 
 We know that for state change, we will have exactly one input from current address, and one output to the same address. We can then perform below pattern matching:
 
-```rust
+```aiken
     let own_address = own_input.output.address
     when
       (
@@ -133,7 +133,7 @@ We know that for state change, we will have exactly one input from current addre
 
 Add in core checks for `MintPlutusNFT`:
 
-```rust
+```aiken
         let is_output_value_clean = list.length(flatten(only_output.value)) == 2
         let is_count_updated =
           only_output.datum == InlineDatum(
@@ -149,7 +149,7 @@ Notice there is a `is_output_value_clean` check here, which ensures the changed
 
 Complete with `StopOracle` logics:
 
-```rust
+```aiken
       (StopOracle, [_], _) -> {
         let is_oracle_nft_burnt =
           only_minted_token(mint, oracle_nft_policy, "", -1)
@@ -161,7 +161,7 @@ Complete with `StopOracle` logics:
 
 A complete oracle validator looks like this:
 
-```rust
+```aiken
 validator oracle {
   spend(
     datum_opt: Option<OracleDatum>,
@@ -221,7 +221,7 @@ The Plutus NFT minting validator ensures the NFT is unique and non-fungible.
 
 ### Code Explanation
 
-```rust
+```aiken
 pub type MintPolarity {
   RMint
   RBurn

docs/smart-contracts/smart-contract-languages/aiken/advanced-data-structures/linked-list.md

@@ -30,7 +30,7 @@ Each entry in the list comprises:
 
 #### EntryDatum Definition
 
-```rust
+```aiken
 data EntryDatum = EntryDatum {
   key :: BuiltinByteString,
   value :: Maybe SomeValue,
@@ -101,7 +101,7 @@ The Aiken Linked List implementation provides several functions to create and ma
 
 For a complete example, including tests and further explanations, reger to the provided sample validator:
 
-```rust
+```aiken
 use aiken/bytearray
 use aiken/dict
 use aiken/interval.{Finite, Interval, IntervalBound, is_entirely_before}
@@ -570,15 +570,15 @@ test mint_validator_remove() {
 
 #### Constants
 
-```rust
+```aiken
 pub const origin_node_token_name = "FSN"
 
 pub const set_node_prefix = "FSN"
 ```
 
 #### Linked List
 
-```rust
+```aiken
 use aiken/bytearray
 use aiken/interval.{Interval}
 use aiken/list
@@ -692,7 +692,7 @@ pub fn remove(
 
 #### Types
 
-```rust
+```aiken
 use aiken/hash.{Blake2b_224, Hash}
 use aiken/transaction.{OutputReference}
 use aiken/transaction/credential.{Address, VerificationKey}
@@ -748,7 +748,7 @@ pub type NodeAction {
 
 ### Utilities
 
-```rust
+```aiken
 use aiken/bytearray
 use aiken/dict.{has_key}
 use aiken/interval.{Interval}

docs/smart-contracts/smart-contract-languages/aiken/advanced-data-structures/merkle-tree.md

@@ -89,7 +89,7 @@ The Aiken Merkle Tree implementation provides several functions to create and ma
 
 ## Validator Logic
 
-```rust
+```aiken
 // /**
 //  * This file contains the implementation of a spend_validator function that validates a spend transaction
 //  * using a Merkle tree. It also includes a test case for the spend_validator function.
@@ -146,7 +146,7 @@ test spend_validator_1() {
 
 ### Library
 
-```rust
+```aiken
 // This code is sourced from https://github.com/aiken-lang/trees/blob/main/lib/aiken/trees/mt.ak
 //
 // A purely functional implementation of MerkleTrees that is suitable for

docs/smart-contracts/smart-contract-languages/aiken/advanced-data-structures/trie.md

@@ -66,7 +66,7 @@ This visual representation helps understand how Tries optimize space and search
 
 ## Validator Logic
 
-```rust
+```aiken
 use aiken/dict
 use aiken/list
 use aiken/transaction.{