How to understand the ActionState?

[lost tusk]

I don't quite understand the ActionState, who can help me clarify the following questions?

1. Can ActionStates be used as the IDs of Actions for querying Action data?

2. If a smart contract publishes an Action, can it immediately obtain the corresponding ActionState?

3. Is it possible to obtain all ActionStates of a smart contract from a blockchain explorer?

4. If a smart contract only publishes an Action without changing its state, will the ActionState be recorded on the blockchain?

5. Can the address of a smart contract that publishes an Action and a specific ActionState be used for proof, such as being used as private parameters in another smart contract to prove that the Action data meets certain requirements?

Thanks!

[valid hare]

1. Yes, the actionStates can be used as inputs to getActions .

2. The final action state is not available until reduce is called, and getActions will not succeed if given the return value of reduce until after the zkapp transaction is included in a block.

3. Yes, and as time passes hopefully more explorers will be available. See https://docs.minaprotocol.com/zkapps/o1js/fetch-events-and-actions#fetching-events-from-an-archive-node

4. No. I assume by this you mean call dispatch without calling reduce.

5. I think you'd need something more than this, but the idea of "publishing" an action isn't so clear. Proving transaction inclusion in an arbitrary point in the past is very challenging (mina does not yet provide this primitive), but if you had that, additionally proving something about the actions should be feasible.

[lost tusk]

Thanks, Ember!

I had read the actions-and-reducer document again and it says "you can process previous actions in a smart contract! Under the hood, this is possible because a commitment is stored to the history of dispatched actions on every account -- the actionState".

Can the actionState value in a account be used as the formActionState or endActionState parameter of the Reducer.getActoins() to get a subset of Action data?
But it doesn't seem to be possible, as you said that an actionState is the intermediate state of the reduction.

Furthermore, I do want to prove transaction inclusion, similar to recording data hashes on the Bitcoin blockchain. However, I also want this data (or its hash) to be involved zero-knowledge proofs in later.

Does Mina support using historical account data (such as a certain Field value) instead of current account data in zero-knowledge proofs? Additionally, can archive nodes retrieve account historical data based on block height or transaction ID?

[valid hare]

Apologies for the confusion @lost tusk , but I misunderstood actionState yesterday. It is in fact the current root of a hash list, representing which actions contributed to the computation of state.

Let me go back and edit my answers :)

[valid hare]

To answer your follow up question: Yes! that is the ideal use for actionState.

I don't know off the top of my head a good way to prove that a previous action + actionState can be fast forwarded to the lastest values stored in the chain- maybe a separate recursive ZkProgram could produce that proof on-demand using getActions?

[rancid kindle]

@valid hare we built Protokit to make recursive processing of actions as easy as writing a ‘solidity contract’, check out our docs preview to learn more: https://deploy-preview-1--aesthetic-beijinho-ea3a52.netlify.app

[valid hare]

https://deploy-preview-1--aesthetic-beijinho-ea3a52.netlify.app/docs/advanced/state-proofs

looks very easy to use! nice.

[rancid kindle]

would love to know what you think about the ergonomics of the state/runtime API, overall architecture and also our settlement contract design:

https://github.com/proto-kit/framework/blob/8d40b3e9b5bfe8712d9449a14fb6474754c5db12/packages/protocol/src/settlement/SettlementContract.ts#L124

we support private mempools, ‘messaging model’ - where we utilize action state for deposits/withdrawals or other actions. This means you can use action state as a mempool, making a protokit appchain ‘l1 mempool based’. we support proving/inclusion of failed transaction execution - thanks to our runtime architecture

[valid hare]

whoa, so protokit appchains can call each other thru mina L1?

[rancid kindle]

yep! thats the base premise for interoperability at the current stage, not perfect - but we have more coming!

eg you can do a state proof of chain A within chain B, and during settlement doublecheck you used the right root hash cross chain

state proofs of self within the appchain are a lot easier since we offer historical state root hash tracking on a block to block basis, thanks to this leveraging privacy techniques such as append only trees becomes super easy

and account updates dont have historical state preconditions (like action state does), so thats a lot harder to do with the L1 protocol

[lost tusk]

Thanks @valid hare and @rancid kindle! Protokit is great and I will try it.

Can the address of a smart contract and the actionState of its actions be used as private inputs in my smart contract? I want to check whether a data hash is included in an existing action while keeping the action itself secret. If the hash is included, I will dispatch a new action from my smart contract. Is this possible?

[sick urchin]

@lost tusk if you use those values only as private inputs you can't prove their connection to the actual values. By making them public (putting them in a precondition) you enable the Mina node to verify their correctness

[lost tusk]

@sick urchin Maybe I didn't express my question well. I want to prove that a certain piece of data is included in an action, but I don't want to disclose the action itself or its dispatcher (a specific smart contract). Is this possible?

[sick urchin]

Yes and this would be the default when you use actions and reducer

EDIT: didn't read everything before anwering - it's true that not revealing the specific action is the default, but it's not possible to hide the dispatcher

[lost tusk]

According to my understanding, reducer can only access the actions of the smart contract it belongs to and not the actions dispatched by other smart contracts. I want to use the address and actionState of a specific smart contract as parameters in my smart contract, then call Mina.fetchActions() to retrieve the actions of that smart contract, and prove that my data is included in an action dispatched by a smart contract. Similarly, I cannot disclose the address or actions of that smart contract to the public.

BTW, I have asked a related question. Could you please help me clarify each point of this question? https://discord.com/channels/484437221055922177/1210437491530928158

[undone elbow]

Can you call reduce in your SmartContract with actions to add the actions to the MerkleMap and store the root of this Merkle Map on-chain?
In this case, you can check that your data is included in the Merkle Map:
Examples:
https://github.com/o1-labs/o1js/blob/f39d4612c7104f2ef394a5fb7348d62b1612c12f/src/examples/zkapps/merkle-tree-and-actions.ts
https://github.com/dfstio/merkle-map-demo/blob/main/src/multiple-choice/contract.ts#L121

Alternatively, you can load all actions and do provable calculations of the actionState based on your data, something similar to the
https://github.com/dfstio/merkle-map-demo/blob/main/src/lib/hash.ts#L25

[sick urchin]

@lost tusk

According to my understanding, reducer can only access the actions of the smart contract it belongs to and not the actions dispatched by other smart contracts. I want to use the address and actionState of a specific smart contract as parameters in my smart contract, then call Mina.fetchActions() to retrieve the actions of that smart contract, and prove that my data is included in an action dispatched by a smart contract.
this is in fact possible with reducer, as its purpose is just processing any list of actions. you just have to turn off the precondition it automatically sets on the contract, useActionStatePrecondition: false, and set that precondition manually on an account update for the other contract instead.

example for processing actions on another account is here:
https://github.com/o1-labs/o1js/blob/64a4bebb8538565d62374551b9df95c2503b41bf/src/examples/zkapps/dex/dex-with-actions.ts#L260-L288

in general, anything you can assert in a smart contract about your own state, you can also assert about the state of other accounts

Similarly, I cannot disclose the address or actions of that smart contract to the public.
@lost tusk this is where what I wrote fails - including an account update of that other contract to set a precondition on it would reveal its address