Reducer map example

[Trivo25]

This contract emulates a "mapping" data structure, which is a key-value store, similar to a dictionary or hash table or new Map<K, V>() in JavaScript.
In this example, the keys are public keys, and the values are arbitrary field elements.
This utilizes the Reducer as an append online list of actions, which are then looked at to find the value corresponding to a specific key.

[emlautarom1]

This looks extremely promising. I have a couple of questions tough:

• Could you comment on the possible issues this approach has?
• How big can the k constant be?
• Are all actions stored in archive nodes? Or do these nodes eventually "prune" old actions?

[Trivo25]

Could you comment on the possible issues this approach has?

This is a relatively naive implementation that demonstrates how Actions/Reducers can be used as on-chain data structures. Without more work, the amount of elements k is limited to a relatively small number (mainly limited by the circuit size, can be extended by using recursive proofs). It's also not trivial to update already set key/value pairs. But for a set-once mapping structure, this should be enough.

How big can the k constant be?

For this particular example, around 1024 entries.

Are all actions stored in archive nodes? Or do these nodes eventually "prune" old actions?

Yes they are stored in archive nodes. I am not aware of archives pruning old state.

[mitschabaude]

Maybe we could get larger maps by having very large actions and storing multiple key-values in them! And when we reduce we only prove that the actions hash is in the list so we don't have to hash all of the big actions

[dfstio]

As I understand, this example uses storage in the archive node that is not part of the proved state and does not use at all on-chain 8 Fields storage for keeping the Merkle Map root.

If we are speaking about possible designs for updating big Merkle Trees on-chain, one of the possible designs that would allow proving inclusion to the Merkle Tree is using the Sparse Merkle Trees that can calculate new root on-chain, then be fully reconstructed off-chain to get the witness.

An example of such an approach is the Ethereum deposit contract
https://github.com/ethereum/consensus-specs/blob/34fc0a5d09fae6649e0c6ac7a0cb09ff5a999957/solidity_deposit_contract/deposit_contract.sol#L80

I was thinking about combining this approach with a Token contract, where we can mint tokens to several addresses and use several 8-field contract states to get a total of 32 or 64 Fields to store Sparse Merkle Tree branches.

The new sha256 hash in o1js probably opens the possibility of porting this Solidity code to the Mina protocol.

This way, we can update on-chain Sparse Merkle Tree branches and root and use on-chain witness verification based on the proved state.

The other possibility is to keep branches in the last action storage and keep the root on-chain in one of 8 Fields. This way, we should limit the ability to post actions to the contract but allow us to calculate the root using the last action. It would require attaching to the actions new branches and some proof that the branches have been updated correctly.