Update AEIP-14.md

AEIP-14.md

@@ -56,14 +56,14 @@ stateDiagram-v2
 
 ### Data structure
 
-To implement this new UTXO model we will need to declare a new field in the UTXO structure to support the state.
+To implement this new UTXO model we will need to declare a type of UTXO like UCO, token or Smart Contract call. Here the type will be dedicated to support the state.
 
 ```jsonc
 {
    "from": "0f1d....",
-   "type": "...",
-   "amount: "...","
-   "state": "03cd..." // Encoded and compressed state transmitted over the chain
+   "type": "state",
+   "state": "03cd" // Encoded and compressed state transmitted over the chain
+   "amount": 0
 }
 ```
 
@@ -134,6 +134,35 @@ Because the stateful UTXO will allow to set data on-chain a particular fee shoul
 The fee should have some mechanism to incentize developers to optimize the data stored within the chain. 
 The compressed size would be used to determine the price of the state.
 
+### Mining
+
+This UTXO will be generated by the nodes during the transaction's valdiation and mining.
+Hence only during smart contract execution the state will be filled.
+
+As the state is based on the inputs due to the smart contract execution, we could have two strategy during the validation:
+- **By replay**
+
+   This approach takes the previous inputs and with previous code compute the new state and therefore validate the pending transaction.
+
+   This would be easy with trigger transaction, however for trigger interval, we need to avoid to calculate state
+of the previous intervals. Hence, we could enforce a new rule (as discussed ad-hoc), to mitigate this problem to create a new transaction when the action is self-triggered, resulting in a new state in any cases. 
+
+  In that scenario, the validation nodes would be able to compute it.
+
+  This could also be seen as a proof of history/proof of time to reach a certain state (as in Solana), as X operations are needed to retrieve the final state. 
+
+
+- **By request**
+
+  This approach might be the finest one - even if the first have interesting concepts in terms of decentralization of trus. This one would
+  be more distributed and lightweight.
+
+  When the validation nodes will request the previous storage nodes, as they are returning the UTXOs, they would have to return the final state being an aggregation from the UTXO state and the pending state.
+  In any cases, the state of the smart contract will be a combination of previous input (meaning state of previous contract) + pending state of the transaction (aggregated into memory until a transaction is created, but reproducible by the UTXO)
+
+  Because it's based on the ARCH consensus, it can mitigate malicious storage nodes which might deliver invalid or false calculated state.
+
+
 ### Explorer
 
 Because the explorer allow to see all the information regarding the transaction and the UTXO attached, it should also render the state by decoding its compressed form.