Stateful UTXO - AEIP 14

[samuelmanzanera]

This is a discussion for the AEIP14 located at: https://github.com/archethic-foundation/aeip/blob/main/AEIP-14.md

[Neylix]

I have few questions of the representation of this state in the blockchain:

• You explained that UTXO will have a new field state, but is this state filled on all UTXO or only a specific one ?
• Also how can we distinguish a state UTXO than an other UTXO ? Currently there is 3 type of UTXO (:UCO, {:token, token_address, token_id} and :call), will this new UTXO having it's own type like :state ?
• Also I don't understand the part where the state UTXO can be updated and stored in memory if an action block updates it without creating a transaction. For the node that create the transaction after the state has been updated, it will know the current state of the SC, but how validation nodes will know this state ? Will the trigger node send all the triggers that updated the state without creating a transaction ?
  Also if the state is updated locally by the storage node, then we cannot rely only on the UTXO to know what is the state of the SC, but we need to calculate it based on all passed triggers since the last transaction (could be easy for trigger transaction, but what for trigger interval ?).
  Also I think you don't rely only on UTXO to have the state but you also need to maintain a calculated state like in account based model

Also there is a little inconsistency, the AEIP spec mention it to be a standard track (AERC) but the list of AEIPs in readme mention it's a Core AEIP

[samuelmanzanera]

The thing is with this proposal in theory any UTXO could leverage a state.
However, only the node are able to create them. Hence only during smart contract execution the state will be filled.
So by definition the UTXO with state will be the main UTXO of the chain (aka UCO UTXO).

As the state is based on the inputs due to the smart contract execution, we could have two strategy during the validation:

• Replay the inputs with previous code to compute the new state and therefore validate the pending transaction
• By requesting the UTXO the state can be computed by the storage nodes and sent to the validation nodes

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), as described in the pending transactions in YP

The main difference with account model is that the anchored states are passed across transactions and shards within the transactions making the transition easier and smoother and introspection more transparent and secure.

[Neylix]

Replay the inputs with previous code to compute the new state and therefore validate the pending transaction

This is possible for trigger transaction, but for trigger interval the validation nodes has to calculate each trigger interval since the previous transaction timestamp
This also means that if the contract receives 1000 calls, the validation nodes has to replay 1000 contract execution ? This would be painfull an could take a lot of time

By requesting the UTXO the state can be computed by the storage nodes and sent to the validation nodes

I think this cannot happen because we cannot ensure the storage node is not malicious and respond with a false calculated state.
But this will be mitigated with atomic commitment so I think this is the solution

So by definition the UTXO with state will be the main UTXO of the chain (aka UCO UTXO)

What if the contract does not have UCO, will we create a UTXO of type :UCO with an amount at 0 ?

[Neylix]

However, only the node are able to create them. Hence only during smart contract execution the state will be filled.
So by definition the UTXO with state will be the main UTXO of the chain (aka UCO UTXO).

By requesting the UTXO the state can be computed by the storage nodes and sent to the validation nodes

This should be explained in AEIP I think.

Also it means that the UCO UTXO will not be fixed but will evolve every time the contract update its state. For example in explorer the state is 1 but tomorrow the state could be 7 on the same UTXO

[samuelmanzanera]

This is possible for trigger transaction, but for trigger interval the validation nodes has to calculate each trigger interval since the previous transaction timestamp

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.
Hence, 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.
But clearly the second approach might be the finest one - even if the first have interesting concepts in terms of decentralization of trust.

I think this cannot happen because we cannot ensure the storage node is not malicious and respond with a false calculated state.
Yes this is the point of the consensus ARCH and in addition to it we could have a quorum conflict resolver which could ensure all the same nodes produces the same state

What if the contract does not have UCO, will we create a UTXO of type :UCO with an amount at 0 ?

If the contract have 0 UCO meaning no pre-funding or not interacting transaction, then it would not able to make any transaction.
Like any transfer, if your balance is just the fee, then you would have 0 UCO as UTXO.

Also it means that the UCO UTXO will not be fixed but will evolve every time the contract update its state. For example in explorer the state is 1 but tomorrow the state could be 7 on the same UTXO

It could indeed update the state of the final UTXO in the explorer.
For this approach I haven't any particular takes, both tactics would work:

• Single UTXO: UCO + State
• Multiple UTXO: UCO, State, Token, etc.

Any particular takes @Neylix , @bchamagne ?

[samuelmanzanera]

Everything considered after discussion, the multiple UTXO approach will be taken.
Meaning a new type of UTXO will be created dedicated to the state making the UI and network discovery of inputs easier.

[samuelmanzanera]

A new version is available at c57cb93

[Neylix]

I'm wondering if we should also have a size limitation on the state.
Since this is actually not calculated and could be huge depending of what users put in

[samuelmanzanera]

The fee is one way to prevent huge size of state across the chain, maybe the algorithm should be design in that way, logarithmic ?

[Neylix]

Fee could prevent this, but if someone has enough found to pay for huge state, it could create a state of hundred of Mb.
So I think in any case we should have a hard limit as for the transaction data

[samuelmanzanera]

Hard limit can be ok (at least for a first implementation), but the problem with hard limit is that it's always subjective without relying on good explanation of reason about the specific amount of size allowed. Whereas a right pricing policy can theoretically be unlimited but the price to store Mb will be prevented a pain point or very costly point. So developers would have to optimize it, a bit like in Ethereum to make the fees attractive for users.

[Neylix]

I understand that having no limit but high fee for high size is good to prevent it, but the problem is that a non limited state size can make the validation fail.
Since nodes have 3 sec to retrieve validation context, they need to download the state in less than 3 sec. But a state of 50 Mb could take more time to be downloaded, especially on low connection nodes.
Also if we don't limit the state size, why do we limit transaction size so ? It could be the same thinking with transaction data size with high fee

[samuelmanzanera]

Yes, sure it can be the same logic for transaction data. We could definitely have some tricks to enhance in that area to make the timeout adaptive based on the number of inputs or inputs size, but as said in first implementation, hard limit size might be the solution to take.

The question would be how many ? ;)